Anyone have any luck running [the poc exploit](https://forum.xda-developers.com/ga...ompiled-executed-zero-day-exploitcve-t3978059) for CVE-2019-2215 on an Oreo LG V20? It's listed as one of the affected devices in the news reports. I'd love to get even a temp root.
For me (LS997) the poc stops with writev returning 0x1000 (it should return 0x2000 if the poc is working).
I have played around with the poc.c source code and noticed that if I change WAITQUEUE_OFFSET to 0x90, the device crashes and reboots. Since an untrusted app isn't supposed to be able to reboot a device, this suggests that there may be an exploitable thing around there somewhere.
Looking at the kernel source on the LG site (at least for the LS997), the LGV20 does have the bug in the kernel. However, the LGV20's kernel has a different layout of struct binder_thread than the version of the kernel the poc is designed for. And unfortunately it's not just a trivial fix, because the poc assumes the waitqueue field is 16-byte aligned, while on the LGV20 it's only 8-byte aligned (because there is one less field in the struct). There is probably a way around this, but I am not good at this sort of stuff: I don't really understand how the poc works. If anybody here does, maybe we can pool our minds and work together.
arpruss said:
Looking at the kernel source on the LG site (at least for the LS997), the LGV20 does have the bug in the kernel. However, the LGV20's kernel has a different layout of struct binder_thread than the version of the kernel the poc is designed for. And unfortunately it's not just a trivial fix, because the poc assumes the waitqueue field is 16-byte aligned, while on the LGV20 it's only 8-byte aligned (because there is one less field in the struct). There is probably a way around this, but I am not good at this sort of stuff: I don't really understand how the poc works. If anybody here does, maybe we can pool our minds and work together.
Click to expand...
Click to collapse
what is the waitqueue offset in the binder_thread struct in your kernel?
chompie1337 said:
what is the waitqueue offset in the binder_thread struct in your kernel?
Click to expand...
Click to collapse
0x98=152, assuming the kernel source I downloaded is correct and assuming I counted all the fields right. Here is my count (counting 64-bits at a time):
Code:
struct binder_thread {
struct binder_proc *proc; // 1
struct rb_node rb_node; // 4
struct list_head waiting_thread_node; // 6
int pid;
int looper; /* only modified by this thread */ // 7
bool looper_need_return; /* can be written by other thread */ // 8
struct binder_transaction *transaction_stack; // 9
struct list_head todo; // 11
struct binder_error return_error; // 15
struct binder_error reply_error; // 19
wait_queue_head_t wait; // spinlock_t + list_head
struct binder_stats stats;
atomic_t tmp_ref;
bool is_dead;
struct task_struct *task;
};
hmm. i see what you mean by alignment now.
this define
Code:
#define IOVEC_ARRAY_SZ (BINDER_THREAD_SZ / 16) //25
makes me believe that the size of iovec_array[ IOVEC_ARRAY_SZ] defined on line 75, has to equal size of struct binder_thread this is because somehow, the contents iovec_array overwrites the contents of a binder_thread structure. which means, that iovec_array[IOVEC_INDX_FOR_WQ] should contain the contents of binder_thread->wait.
wait_queue_head is defined as:
Code:
struct wait_queue_head {
spinlock_t lock;
struct list_head head;
};
meaning you have to make sure that the values in iovec_array[IOVEC_INDX_FOR_WQ] correspond correctly to the wait_queue_head but also line up so the writev works. there's definitely some trickery you could do to make this work. my first thought is you know that &iovec_arrary[9].len (offset 0x98) should point to values that make sense for a wait_queue_head struct. i'm working on understanding this better, though.
don't you guys think that 0xDEADBEEFs should go away before this so-called poc start working? any ideas on that one?
GoofMan69 said:
don't you guys think that 0xDEADBEEFs should go away before this so-called poc start working? any ideas on that one?
Click to expand...
Click to collapse
that's where the use after free bug should come in.
Code:
ioctl(binder_fd, BINDER_THREAD_EXIT, NULL);
when this is called, the binder_thread structure is freed in the kernel.
immediately after the parent process calls,
Code:
b = writev(pipefd[1], iovec_array, IOVEC_ARRAY_SZ);
in the kernel, memory is allocated to copy over iovec_array from userspace. this poc depends on the pointer from this allocation, to be the same as the recently freed binder_thread memory.
then, when the child process exits, the EPOLL cleanup will use the waitqueue in the binder_thread structure, that has been overwritten with the values in iovec_array. when EPOLL cleanup unlinks the waitqueue, 0xDEADBEEF will get overwritten by a pointer in kernelspace. this has to happen just before the writev call in the parent process starts to copy over the second buffer, which gets us a kernel space memory leak.
if writev is returning 0x1000 it means the timing is off, the wait queue offset is off, the kmalloc allocation in the writev function isn't the same as the freed binder_thread, or your kernel isn't vulnerable.
One simplifying issue is that with Kernel 3.18, we don't have KASLR, so we don't need to leak the kernel address. Hence the first part of the poc is unnecessary, assuming we can get the addresses.
Are there any rooted LGV20 variants using the 3.18 kernel? If so, it might help if someone with one of these were to post a copy of /proc/kallsyms
try
lg q710 kernel 3.18
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
chompie1337, thank you for such detailed description.
So, child must exit and epoll-cleanup code should be done to the time when parent's writev() starts to copy 2nd buffer (as you say, 0xdeadbeef will be replaced by that time). But there's a sleep(2) in the child. Do you think it is appropriate? Hardly it'll take writev 2s to copy first buffer, maybe 2ms or smth?
Also, why does child call epoll_ctl(EPOLL_CTL_DEL)? Isn't it a thing, that we should NOT do for the bug to come in?
From reading the poc, it looks like deleting the event from the epoll queue, after the binder thread has terminated, (somehow) causes the pointer wq->task_list->prev to have the value &(wq->task_list->next). If the kernel allocates its copy of the iovec array in the same place as the old binder_thread structure was, the wq->task_list->prev pointer will fall in an iov_base location in the array, and hence an iov_base will get overwritten. Moreover, the poc ensures this happens AFTER the kernel has checked that the iovec is one the user has permission to use for reading or writing. In the clobber function, then, the epoll event deletion makes the iov_base point to a position in the kernel heap--indeed, inside the kernel's pre-checked copy of the iovec array--which the poc leverages to write data to any location the kernel has access to (by first rewriting the next little bit of the pre-checked iovec array).
Unfortunately, with the 3.18 kernel, the event deletion causes a value to be written to an iov_len location in the iovec array, which allows one to change the amount of data being written but not the location being written to. This is good enough for crashing the device and probably for leaking a lot of data, but I have not been able to figure out how to use it for rooting.
If the kernel could be manipulated to allocate its copy of the iovec array 8-bytes further down in the heap, that would solve the problem, but I don't know if it can be done: I don't think the kmalloc-512 allocator will do that. But I could be wrong. Otherwise, I think one needs some other technique than the readv/writev trick used in the poc.
I am, unfortunately, quite new to this kind of thing. An experienced kernel hacker can probably see in an instant what to do.
I'm not sure the PoC crash is entirely because of the kernel version. My device (not the V20, just here to cooperate to develop the exploit) has kernel version 4.4 but it crashes at the first EPOLL_CTL_DEL. Where does the V20 crash when you change the WAITQUEUE_OFFSET?
Oh, I see... So writev would block after writing first dummy_page_4g_aligned of length 0x1000, because pipe's queue is full (pipe size is also 0x1000). So there isn't actually any timing tweak required, right?
Btw, i've managed to get some memory from kernel (from my device, not the V20) and non-null curent ptr, but kernel_read fails, even when reading 4 bytes from cur_ptr without any offset
Can anyone comment on line 119:
current_ptr = *(unsigned long *)(page_buffer + 0xe8);
What is 0xE8? Where does it come from?
Another strange thing: if i run poc with wd offset like for ex. 0xb0 right after reboot - i get another reboot right away, repeatability 100%. but if i run at first with offset like 0xc0 - of course i get writev 0x1000 and poc exits, but if i rerun poc with 0xb0 right after that - it will not cause reboot, but correct leak of mem happens
GoofMan69 said:
Oh, I see... So writev would block after writing first dummy_page_4g_aligned of length 0x1000, because pipe's queue is full (pipe size is also 0x1000). So there isn't actually any timing tweak required, right?
Click to expand...
Click to collapse
The sleep(2) is needed to make sure the THREAD_EXIT, which frees the binder_thread object, as well as the subsequent allocation of the iovec buffer in kernel memory take effect before the EPOLL_CTL_DEL. The pipe blocking happens only after the the EPOLL_CTL_DEL.
Can anyone comment on line 119:
current_ptr = *(unsigned long *)(page_buffer + 0xe8);
What is 0xE8? Where does it come from?
Click to expand...
Click to collapse
I'm guessing that 0xe8 comes from the author's looking at a hexdump of the page to find where there is a pointer to kernel stuff to help figure out where the address limit is held in memory, so it can be clobbered.
GoofMan69 said:
Oh, I see... So writev would block after writing first dummy_page_4g_aligned of length 0x1000, because pipe's queue is full (pipe size is also 0x1000). So there isn't actually any timing tweak required, right?
Btw, i've managed to get some memory from kernel (from my device, not the V20) and non-null curent ptr, but kernel_read fails, even when reading 4 bytes from cur_ptr without any offset
Can anyone comment on line 119:
current_ptr = *(unsigned long *)(page_buffer + 0xe8);
What is 0xE8? Where does it come from?
Another strange thing: if i run poc with wd offset like for ex. 0xb0 right after reboot - i get another reboot right away, repeatability 100%. but if i run at first with offset like 0xc0 - of course i get writev 0x1000 and poc exits, but if i rerun poc with 0xb0 right after that - it will not cause reboot, but correct leak of mem happens
Click to expand...
Click to collapse
page_buffer + 0xe8 should point to the current thread's thread_info structure, where the addr_limit is held
---------- Post added at 08:35 AM ---------- Previous post was at 08:19 AM ----------
arpruss said:
From reading the poc, it looks like deleting the event from the epoll queue, after the binder thread has terminated, (somehow) causes the pointer wq->task_list->prev to have the value &(wq->task_list->next).
Click to expand...
Click to collapse
yes, you are correct. i believe it is because remove_wait_queue is called for the wait_queue_head found in the binder_thread structure which eventually results in a call to __list_del where this happens:
http://androidxref.com/kernel_3.18/xref/include/linux/list.h#87
I can now leak data on my LGV20 with the 3.18 kernel using this modified poc: https://github.com/arpruss/cve2019-2215-3.18
The key is to realize that the following happens during the after-free cleanup at least on my 3.18.71 kernel:
1. The spinlock appears receive the value 0x10001
2. The prev and next pointers in the queue head point to the queue head.
If everything works, you will have a bunch of hex data, which starts with two 8-byte pointers with equal values.
This may or may not get us closer to actually elevating privileges, but I thought I'd share it to help others.
Code:
1|elsa:/data/local/tmp $ uname -a
Linux localhost 3.18.71-perf+ #1 SMP PREEMPT Tue Jul 17 14:44:34 KST 2018 aarch64
elsa:/data/local/tmp $ ./poc98
Starting POC
PARENT: Calling WRITEV
CHILD: Doing EPOLL_CTL_DEL.
CHILD: Finished EPOLL_CTL_DEL.
CHILD: initial page
CHILD: dummy data
CHILD: leak data
writev() returns 0x12001
CHILD: Finished write to FIFO.
PARENT: Done with leaking
00000000 a0 f8 c4 f3 c0 ff ff ff a0 f8 c4 f3 c0 ff ff ff |................|
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
arpruss said:
I can now leak data on my LGV20 with the 3.18 kernel using this modified poc: https://github.com/arpruss/cve2019-2215-3.18
The key is to realize that the following happens during the after-free cleanup at least on my 3.18.71 kernel:
1. The spinlock appears receive the value 0x10001
2. The prev and next pointers in the queue head point to the queue head.
If everything works, you will have a bunch of hex data, which starts with two 8-byte pointers with equal values.
This may or may not get us closer to actually elevating privileges, but I thought I'd share it to help others.
Code:
1|elsa:/data/local/tmp $ uname -a
Linux localhost 3.18.71-perf+ #1 SMP PREEMPT Tue Jul 17 14:44:34 KST 2018 aarch64
elsa:/data/local/tmp $ ./poc98
Starting POC
PARENT: Calling WRITEV
CHILD: Doing EPOLL_CTL_DEL.
CHILD: Finished EPOLL_CTL_DEL.
CHILD: initial page
CHILD: dummy data
CHILD: leak data
writev() returns 0x12001
CHILD: Finished write to FIFO.
PARENT: Done with leaking
00000000 a0 f8 c4 f3 c0 ff ff ff a0 f8 c4 f3 c0 ff ff ff |................|
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
Click to expand...
Click to collapse
Nice work. Now without the spinlock issue crashing, the kernel write is failing. This is because the recvmsg implementation for the 3.18 kernel checks each address right before it's copied over to the buffer. In the writev/readv the access check for addresses are all done at once at the beginning of the call, so that's why the leaking works. Working now on trying to use readv instead of recvmsg
chompie1337 said:
Nice work. Now without the spinlock issue crashing, the kernel write is failing. This is because the recvmsg implementation for the 3.18 kernel checks each address right before it's copied over to the buffer. In the writev/readv the access check for addresses are all done at once at the beginning of the call, so that's why the leaking works. Working now on trying to use readv instead of recvmsg
Click to expand...
Click to collapse
It was tricky to get it working, but I can now write to an arbitrary kernel address using: https://github.com/arpruss/cve2019-2215-3.18/blob/master/poc98-overwrite-pipe.c
Unfortunately, one more ingredient is needed: I need the address of the thread_info structure in order to modify addr_limit. On 4.4+, this is easy, as it's part of the task_struct, which the leaked current_ptr points to. On 3.18, thread_info is at the beginning of the kernel stack. So what we need to do is to leak the kernel stack location. If you know how to do that -- e.g., extracting it in some way from the big kernel heap leak -- let me know.
Or one use some other method. For instance, one can heap spray with a bunch of struct file objects, use the big kernel heap leak to find one of the sprayed objects (e.g., one can seek to a unique random location in a sparse file, and search for that offset in the leaked kernel heap), and modify its ops pointer to point to a doctored list of ops that calls a user function. I think this should work, unless we're unlucky and the binder_thread object is not anywhere near one of the sprayed file objects.
Or else if someone has the exact same kernel on a rootable device, they could send me the output of cat /proc/kallsyms, and one could modify some syscall to call a user function.
Now that I have a big kernel heap memory leak plus arbitrary address writing it's just a matter of time before we have a full exploit, I expect.
arpruss said:
It was tricky to get it working, but I can now write to an arbitrary kernel address using: https://github.com/arpruss/cve2019-2215-3.18/blob/master/poc98-overwrite-pipe.c
Unfortunately, one more ingredient is needed: I need the address of the thread_info structure in order to modify addr_limit. On 4.4+, this is easy, as it's part of the task_struct, which the leaked current_ptr points to. On 3.18, thread_info is at the beginning of the kernel stack. So what we need to do is to leak the kernel stack location. If you know how to do that -- e.g., extracting it in some way from the big kernel heap leak -- let me know.
Or one use some other method. For instance, one can heap spray with a bunch of struct file objects, use the big kernel heap leak to find one of the sprayed objects (e.g., one can seek to a unique random location in a sparse file, and search for that offset in the leaked kernel heap), and modify its ops pointer to point to a doctored list of ops that calls a user function. I think this should work, unless we're unlucky and the binder_thread object is not anywhere near one of the sprayed file objects.
Or else if someone has the exact same kernel on a rootable device, they could send me the output of cat /proc/kallsyms, and one could modify some syscall to call a user function.
Now that I have a big kernel heap memory leak plus arbitrary address writing it's just a matter of time before we have a full exploit, I expect.
Click to expand...
Click to collapse
Amazing work! Going to try it out now. How do you know that current_ptr points to task_struct? On my Pixel (3.18 kernel) current_ptr points to thread_info. Wondering why that's different?
edit: nvm, i see now. it's in an offset of the binder_thread structure.
arpruss said:
It was tricky to get it working, but I can now write to an arbitrary kernel address using: https://github.com/arpruss/cve2019-2215-3.18/blob/master/poc98-overwrite-pipe.c
Unfortunately, one more ingredient is needed: I need the address of the thread_info structure in order to modify addr_limit. On 4.4+, this is easy, as it's part of the task_struct, which the leaked current_ptr points to. On 3.18, thread_info is at the beginning of the kernel stack. So what we need to do is to leak the kernel stack location. If you know how to do that -- e.g., extracting it in some way from the big kernel heap leak -- let me know.
Or one use some other method. For instance, one can heap spray with a bunch of struct file objects, use the big kernel heap leak to find one of the sprayed objects (e.g., one can seek to a unique random location in a sparse file, and search for that offset in the leaked kernel heap), and modify its ops pointer to point to a doctored list of ops that calls a user function. I think this should work, unless we're unlucky and the binder_thread object is not anywhere near one of the sprayed file objects.
Or else if someone has the exact same kernel on a rootable device, they could send me the output of cat /proc/kallsyms, and one could modify some syscall to call a user function.
Now that I have a big kernel heap memory leak plus arbitrary address writing it's just a matter of time before we have a full exploit, I expect.
Click to expand...
Click to collapse
Isn't thread_info pointed by the stack field of task_struct?
Related
Okay, so I've tried everything. PDOCREAD, DUMPROM, pget, grab_it, testdump.exe, FiziFetch. I need help with getting at all of the files and doing a complete ROM dump of the device. The only ROM Dump I have is the one that ETEN provides for upgrading the phone, I have attached that here. EUU.exe is the exe you run on the pc, and normally the rom file is called temp.dat, and it uses the other .exe which is compiled for windows ce to the phone to do the updating process.
Any help here would be greatly appreciated. In particular I want btagext.dll in the /Windows directory and full instructions on how to do it myself for other protected files.
The ROM can be obtained by going to updates.eten.ch and downloading the latest English ROM file for the M600. The direct link is here:
ftp://support.com:[email protected]/Download/Updates/M600/ENG/EUU_M600_WWE_R01_100_0171.EXE
To get the ROM file and the update file, goto your documents and settings/profile name/local settings/temp folder and clear out all the files.
Run the .exe you downloaded from above, and then look in the temp folder you just cleared. You should see a temp.dat which is the ROM file, EUU.exe which is the file that facilitates the transfer of the file to the ETEN M600 and another file USBDLUpdate_Console.exe which is a windows CE compiled file that facilitates the flashing process in some way.
Pdocread part of the itsutils is able to read see some of the information on my device:
pdocread –l lists the following:
122.19M FLASHDR
| 1.03M Part00
| 1.52M Part01
| 33.98M Part02
| 85.47M Part03
1.89G DSK1:
| 1.89G SD
STRG handles: a34cc21e
0 partitions, 0 binary partitions
customerid=00000000 uniqueid= 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
( 1.89G) e3b41b8a
0 partitions, 0 binary partitions
customerid=00000000 uniqueid= 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
( 85.47M) e3b4153e
0 partitions, 0 binary partitions
customerid=00000000 uniqueid= 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
( 33.98M) 83b41436
0 partitions, 0 binary partitions
customerid=00000000 uniqueid= 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
( 1.52M) a3b412be
0 partitions, 0 binary partitions
customerid=00000000 uniqueid= 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
( 1.03M)
However it is not able to do anything other then that. All attempts at trying to access those partitions or device (flashdr) fail with errors such as these (this is just a small list of commands command options i've tried):
C:\itsutils\build>pdocread -d DSK1
ERROR: ITTFFSGetInfo - The handle is invalid.
C:\itsutils\build>pdocread -d DSK1:
ERROR: ITLogDiskInfo - An exception occurred in the service when handling the co
ntrol request.
0 partitions, 0 binary partitions
customerid=00000000 uniqueid= 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
C:\itsutils\build>pdocread 0x0 0x200 foo.bin
0 partitions, 0 binary partitions
customerid=00000000 uniqueid= 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
CopyTFFSToFile(0x0, 0x200, foo.bin)
ERROR: ITReadDisk - An internal error occurred.
C:\itsutils\build>pdocread -o -p part03
ERROR: ITTFFSGetInfo: outbuf==NULL
WARNING: using default 512 bytes for sectorsize
C:\itsutils\build>pdocread -d FLASHDR -w
ERROR: ITTFFSGetInfo - The handle is invalid.
Re: Need help extracting files from ETEN M600 ROM will pay $
I don't think that you'll be able to get a working dump of btagext.dll or any other system DLL. It does not have relocation information.
temp.dat in eten upgrade is in some strange format, it seems that data blocks are mixed.
What is the result of testdump.exe? I've attached the WM5 build of this program.
Re: Need help extracting files from ETEN M600 ROM will pay $
I've tried that before. That just dumps some information that is in memory. You can see calendar information, contact information, etc. If you put in 128mb which is the ROM size, it says DUMP OK this time (it had filesys errors the time I tried it a couple weeks ago) See here:
http://www.eten-users.net/topic1085
Anyways, in the end it dumps a 64 meg file instead of the 128 you specified, which is just the stuff in memory the 64 megs of RAM that this thing is suppose to have. If you use romdump on that file it doesn't get to many files, just about 30 or so and none of them are very important (most you can get via windows explorer and activesync)
FB
Re: Need help extracting files from ETEN M600 ROM will pay $
why do you think that eten has 128Mb OS ROM? It has only 48Mb ROM, other is left to persistent storage. So these tools would never dump full 128Mb, only 64Mb max.
You should upload somewhere the output of testdump tool, so I can look at it. It should produce _correct_ ROM dump. You just cannot extract files from it correctly. "dumprom" is for older oses, and with "-5" switch it would extract only files from XIP section (about 20 files). Use my "viewimgfs" tool to get everything from IMGFS.
I looked in the control panel, you are right it appears that the system part takes up about 48 mb, with the rest of the 128mb as user storage. It's kind of wierd though that testdump would stop at 64mb, wouldn't it stop at 48mb instead? If not why is it not doing the full 128 mb.
I tried what you had suggested and unfortunately that doesn't work either. I dumped a 64mb image, and a 48mb image. viewimgfs.exe didn't work on those images. I tried prepimgfs on the 48mb one and it couldn't find imgfs start location. I tried it on the 64mb one and it found it but the resulting file was about 256kb with a 4kb "removed_data" file which is definately not right.
I tried it without first running prepareimgfs and it just says "unable to load compress .dll".
I can't send a rom dump of what I have yet as it contains all of my contacts and calender information in looking at the memory dump in a hex editor, I'll have to whip the device clean again and I can send one but that may take awhile, i've got a lot of stuff setup right now.
Any other suggestions?
I found another bit of information. I played around with MTTY, which I know is for HTC devices, just to see what it would do though I thought I would try. It connects to the bootloader, however you never get to a command prompt. It appears that i can send a command, but then it trys to just download a file (the updated ROM). So I'm not sure if anything else can be done with this, I was hoping I could do something like "d2s" but it appears that with MTTY that doesn't seem possible.
I'm wondering if there is some way to map a USB port to a COM port so I can use regular hyperterminal. Does anyone know how to do this as Hyperterminal only supports COM ports...
MTTY is identical to hyperterminal
Ahh okay, it must be that they haven't implemented a nice interface like HTC devices where you can issue all of those commands
Hi!
Until now can you dump it? I can help you dump....
PM me,OK?
Okay, so i've finally been able to get these files from Vijay, however I'm still running into issues as describe here:
http://www.eten-users.net/topic1500
Anyone have any information on how to reconstruct PE files?
Hi, Weather Database Editor doesnt work with my Girlfriends Touch 3G (german).
Is there any Solution to manually add Cities?
Thanks. =)
Same problem here
Try this one..
http://forum.xda-developers.com/showpost.php?p=2488224&postcount=73
Thanks but it does no show any cities...
yepp, seems that the database has another filename...
i try investigating this...
Ok, found the Database. =)
Its HH_0407_WeatherCities.xml (for German Users i think).
Bad news:
Its hidden/system/in rom
Any ideas how to rename it?
I copied it to the PC and edited the Cities in but i cant copy it back to the phone...
You can easily overwrite the file with resco explorer after disabling touchflo from the today screen but I have yet to find a way to copy the file to the pc. Could you share your xml please?
Ok I am getting nearer.
Disable touchflo
Copy HH_0407_WeatherCities.xml from the /windows folder to your pc.
Edit the xml to include your new city.
Copy it back to the phone into somewhere like "My Documents" then use resco explorer to move it to /windows and overwrite the original file.
Copy manil2d.exe from windows to your pc,
download XVI32 from http://www.chmaas.handshake.de/delphi/freeware/xvi32/xvi32.htm
download sign code from N2A's site http://weather.not2advanced.com/files/SignCode.zip
Open manila2d.exe in XVI32 and do a search for "weather.manila1.htc.com" ( make sure Unicode check box is checked )
You will see the update URL in unicode , which means that if you want to replace it , there has to be a hex 00 between every letter !
It needs to be changed to something like weather.not2advanced.com/htcweather/forecastdata.php?locCode=%s%s%s
save manila2d.exe and sign it using N2A's batch file
Copy it back to the phone into somewhere like "My Documents" then use resco explorer to move it to /windows and overwrite the original file.
Now I have the new city listed but when I update, all the temperatures = 0
I'm not sure what I have done wrong but I think the URL is wrong.
Any ideas?
Ok, the URL was different for me.
Done that but without the %s%s%s.
Still not working.
I can select the cities but i cant see them in the tab.
Update says that it cannot get updates for the selected city.
Hi Vibez
I reply here instead of the PM , so the others can read it aswell
I don't have a touch 3G so I cannot experiment for you , but 1 thing is sure ,
people had the same issue on the Diamond ( cities not updating after hex-edit ) when the hex-edit was not done 100% correctly ...
So 2 questions :
1) Did any of you try the reigistry hack from the diamond ?
In stock ROM, the URL used to update the weather is a specific Accuweather URL. WDE change it to point to N2A'website ( http://weather.not2advanced.com/ ).
Registry key=HKEY_CURRENT_USER\Software\HTC\Manila
String value Name=Weather.ServerURLOverride
Click to expand...
Click to collapse
2) when u tried patching , did the replacement weather string have EXACTLY the same length as the original ? On the diamond , it was an absolute no-go when the length was different
Open manila exe in XVI32 and do a search for "weather.manila1.htc.com" ( make sure Unicode check box is checked )
You will see the update URL in unicode , which means that if you want to replace it , there has to be a hex 00 between every letter !
I then replaced : http://weather.manila1.htc.com/widget/htc/forecast-data_v3.asp?locCode=%1s&?ac=TR2cra9U
with : http://weather.not2advanced.com/htcweather/forecastdata.php?locCode=%1s&ac=XDADevs1234
Those two lines have exactely the same length upto there ( That's why i added 1234 to the XDAdevs , thankfully that's ok with N2A's site ) so the rest of the URL ( &device=innovation etc.. ) can remain unchanged !
Click to expand...
Click to collapse
If that fails to work , send me a copy of the manila app ( modded and original maybe so I can see what u did ) , I'll look at it , patch it & send it back for you to try ...
I can't promise anything of course , but I'm on holidays this week , so I've got a little time to spare ;-)
cheers,
Claude
Thanks for the info!
Unicode-Strings should be NULL-terminated to, so all i've done was to zero out the remaining chars.
I give it a try and answer here asap.
//edit:
Ok, works but Temps are at 0°C.
Seems that the XML-Format has been changed.
BTW: String used for Patching Mainila2D.exe was:
000D8858 68 00 74 00 74 00 70 00 3A 00 2F 00 2F 00 77 00 65 00 61 00 74 00 68 00 h.t.t.p.:././.w.e.a.t.h.
000D8870 65 00 72 00 2E 00 6E 00 6F 00 74 00 32 00 61 00 64 00 76 00 61 00 6E 00 e.r...n.o.t.2.a.d.v.a.n.
000D8888 63 00 65 00 64 00 2E 00 63 00 6F 00 6D 00 2F 00 68 00 74 00 63 00 77 00 c.e.d...c.o.m./.h.t.c.w.
000D88A0 65 00 61 00 74 00 68 00 65 00 72 00 2F 00 66 00 6F 00 72 00 65 00 63 00 e.a.t.h.e.r./.f.o.r.e.c.
000D88B8 61 00 73 00 74 00 64 00 61 00 74 00 61 00 2E 00 70 00 68 00 70 00 3F 00 a.s.t.d.a.t.a...p.h.p.?.
000D88D0 6C 00 6F 00 63 00 43 00 6F 00 64 00 65 00 3D 00 25 00 31 00 73 00 00 00 l.o.c.C.o.d.e.=.%.1.s...
Ahw F...!
Tested the original URL:
first, city in original database:
http://htc.accuweather.com/widget/htc/forecast-data.asp?ac=TR2cra9U&locCode=EUR|DE|GM011|AACHEN
second, city manually added:
http://htc.accuweather.com/widget/h...ac=TR2cra9U&locCode=EUR|DE|GM017|SCHMALKALDEN
second URL does NOT give any information back in the XML...
Seems that the database is also online and it trys to find the city there...
OK, tried the not2advanced URL, XML Format has changed heavily...
*sniff*
Garfield1970,
Thanks for helping out.
The registry trick did not work.
I did find a patched version of manila2d.exe from another rom that works perfect on our phone, but ideally I would like to see how to patch the original version that our phone ships with. The hex surrounding the URL string in our manilla2d.exe looks a little different. I'm not 100% there is enough room to fit the full N2A url in!
I will post all 3 versions later for you to play with.
Weltherrscher said:
Ahw F...!
Tested the original URL:
first, city in original database:
http://htc.accuweather.com/widget/htc/forecast-data.asp?ac=TR2cra9U&locCode=EUR|DE|GM011|AACHEN
Click to expand...
Click to collapse
Ok
second, city manually added:
http://htc.accuweather.com/widget/h...ac=TR2cra9U&locCode=EUR|DE|GM017|SCHMALKALDEN
second URL does NOT give any information back in the XML...
Seems that the database is also online and it trys to find the city there...
Click to expand...
Click to collapse
That's normal as that city is unknown to the HTC Server
OK, tried the not2advanced URL, XML Format has changed heavily...
*sniff*
Click to expand...
Click to collapse
Indeed , I just compared the XML Outputs for Aachen from HTC & N2A , they changed the format .... But if you ask N2A very very nicely and if he has some time to spare , he might eventually adapt a version of his script to reflect the other XML format
You can clearly see the differences between the following two outputs :
http://weather.not2advanced.com/htc...hp?locCode=EUR|DE|GM011|AACHEN&ac=XDADevs1234
is the Diamond compatible format
http://htc.accuweather.com/widget/htc/forecast-data.asp?ac=TR2cra9U&locCode=EUR|DE|GM011|AACHEN
is the format the touch 3g seems to need ....
I'll crosspost the URL's to N2A's main thread so he can maybe have a look
Claude
Just for info the XML format that ships with our ROM works fine with N2A.
To me it seems N2A provides extra elements which I assume is for compatibility with HTC home.
So no need as far as I can tell to ask him to change anything.
Unless i'm getting confused in what you are saying?
vibez said:
Just for info the XML format that ships with our ROM works fine with N2A.
To me it seems N2A provides extra elements which I assume is for compatibility with HTC home.
So no need as far as I can tell to ask him to change anything.
Unless i'm getting confused in what you are saying?
Click to expand...
Click to collapse
Are you sure that the N2A output works for you ?
Because if you look at the XML's , what your device expects is to see includes blocks titled :
Today
Tonight
Tomorrow
and then the following weekdays
whereas on my Diamond it's just current and the different Weekdays being reported
Claude
I'm 100% sure it works with this version of manila2d.exe that i'm using. Now it may be that this version I have uses the old format.
We don't have
Today
Tonight
Tomorrow
we just have current temp, and hi, lo for each day
You mean using the patched manila from the other rom that you mentionned earlier ?
Might be that the format switch has happened between differen Rom versions ?
Claude
Garfield1970 said:
You mean using the patched manila from the other rom that you mentionned earlier ?
Might be that the format switch has happened between differen Rom versions ?
Claude
Click to expand...
Click to collapse
Yes it could be that. Although the end result is the same. The original version only showed Current and hi/lo temps
Ok i've attached the files
Manila2D_original.exe
This is the original unpatched file
Manila2D_original_patched_not_working.exe
This the original file I tried to patch without success
Manila2D_patched_ok.exe
This is the patched file from another rom that works ok.
Dear Hardware Hackers, Geeks and Modders,
it always takes some time for me to switch over to a "new" device
Recently i bought a GT-I9305 for cheap, to be more exactely bought two; a broken and a working one.
Anyway, as always i need to disassemble my toys, see what's inside and investigate how things work out on the hardware base.
To follow my descriptions and findings in this thread it is recommended to grab the service manual, e.g. at cpkb.org.
As usual there are already many technical threads covering some of the hardware issues.
It's time to put some light on the unknown details here.
Starting a few weeks ago there'd been some time for reverse engineering, study documents, read posts and draw some conclusions.
I hope you'll enjoy my discoveries and give some feedback.
It might take some time though to write down everything even more detailed and get it little bit structured to post it here.
SD-card mode or complete brick recovery by re-write internal bootloader:
The sboot bootloader is capable to start from external SD-card as well and detects the media it has been started from.
To re-write the bootloader in the internal eMMC, we need an external boot media and block the internal boot process at power up.
The SD-card needs a special structure with the sboot binary right in place.
There's already a detailed thread about this procedure (see the reference links below).
Anyway, as you might have read elsewhere, replacing KNOX bootloader with an older one will not work.
The first time a KNOX bootloader is installed on the device,
some hardware protected blocks on the eMMC become active to meet the requirements of the KNOX function.
This process could not be reverted by simply overwrite the sboot section.
We need other tools for this. This might be covered later.
Prevent booting from internal eMMC by blocking MMC_CMD:
GT-I9300:
eMMC44_CH4: MMC_CMD is blocked by shorting the pull-up resistor R313
GT-I9305:
eMMC44_CH4: MMC_CMD is blocked by shorting the pull-up resistor R634
Please refer to the service manual for the correct position of the components.
Bootloader recovery will need some proof of concept, to be 100% certain that it works in the same way, as it does on GT-I9300.
SD-card booting by changing the CPU boot mode (permanently):
The boot code is set at power up by reading the logic level at special IO pins (XOM6:0).
These logic levels are set by a bunch of resistors and could be tweaked.
The boot modes for Exynos 4412 known so far:
Code:
XOM[5:1] : 1st device : 2nd device
5b'00010 : SDMMC_CH2 : USB
5b'00011 : eMMC43_CH0 : USB
5b'00100 : eMMC44_CH4 : USB
5b'10011 : eMMC43_CH0 : SDMMC_CH2
5b'10100 : eMMC44_CH4 : SDMMC_CH2
GT-I9305 (default, might need some approval by reading the registers):
Code:
XOM[5:1]
5b'10100 : eMMC44_CH4 : SDMMC_CH2
XOM0 : R612 10K PU
XOM1 : R614 100K PD
XOM2 : R615 100K PD
XOM3 : R609 10K PU
XOM4 : R616 100K PD
XOM5 : R610 10K PU
XOM6 : R617 100K PD
GT-I9305 (SD-card boot mode, needs testing!!!):
Code:
XOM[5:1]
5b'00010 : SDMMC_CH2 : USB
XOM0 : R612 10K PU (no change here)
XOM1 : R614 100K PD (no change here)
XOM2 : R615 10K PU (changed from PD to PU)
XOM3 : R609 100K PD (changed from PU to PD)
XOM4 : R616 100K PD (no change here)
XOM5 : R610 100K PD (changed from PU to PD)
XOM6 : R617 100K PD (no change here)
This relationship had been partly reverse engineered and concluded from other designs.
May need some approval though.
Same here, external booting from SD-card will need some proof of concept, to be 100% certain that it works without flaws.
There's a uncertainty concerning standard sboot, to allow a complete boot into system level (e.g. recovery) using a non default boot mode.
Maybe the code is bound to the device (internal eMMC only) in some way, or external SD-card is not fully supported as boot media.
Anyway, it is straight forward to build up a SD-card for testing.
The kernel boot parameter and parts of recovery image will need some tweaks to use the right device to boot from.
Direct access to Exynos 4412 debug UART:
The debug UART is permanently accessible on connector HDC401 (no need to block the USB port for this feature).
AP_TXD : HCD401, pin 11 (LVTTL 1.8V)
AP_RXD : HCD401, pin 17 (LVTTL 1.8V)
Please refer to the service manual for the position of connector HCD401.
These signals are fully tested and working.
The best would be to get the counter part of Panasonic AXE620124AW1 for a direct connection,
but this parts seems tobe hard to find.
As an alternative you'll need some very fine soldering iron and some tiny wires.
This way you could solder the wires directly to the pins of the connector.
You'll need some 1.8V level converter (+ USB UART) as already to be found in many projects.
Set up your terminal to 8N1 at 115200Bit/s and there you go.
E.g. enter S-Boot command line by hitting enter at boot up:
Code:
PMIC rev = PASS2(4)
cardtype: 0x00000007
SB_MMC_HS_52MHZ_1_8V_3V_IO
mmc->card_caps: 0x00000311
mmc->host_caps: 0x00000311
mmc_initialize: mmc->capacity = 30777344
Samsung S-Boot 4.0-1153417 for GT-I9305 (May 29 2013 - 17:22:39)
EXYNOS4412(EVT 1.1) / 2047MB / 15028MB / Rev 2 / I9305XXBME3
initialize_ddi_data: usable! (0:0x0)
PARAM ENV VERSION: v1.0..
init_fuelgauge: fuelgauge power ok
get_battery_detect: battery is missed
init_fuelgauge: battery is not detected, vcell(3858), soc(59)
init_fuelgauge: POR status
fuelgauge_por: POR start: vcell(3858), vfocv(3871), soc(59)
fuelgauge_por: update SDI M0 parameter
fuelgauge_por: RCOMP(0x0063), TEMPCO(0x0930)
fuelgauge_por: POR finish: vcell(3856), vfocv(3901), soc(55)
get_table_soc: vcell(3855) is caculated to t-soc(62.486)
init_fuelgauge: start: vcell(3855), vfocv(3898), soc(55), table soc(62)
init_fuelgauge: finish: vcell(3855), vfocv(3898), soc(55), table soc(62)
init_microusb_ic: MUIC: CONTROL1:0x00
init_microusb_ic: MUIC: CONTROL1:0x00
init_microusb_ic: MUIC: CONTROL2:0x3b
init_microusb_ic: MUIC: CONTROL2:0x3b
PMIC_ID = 0x02
PMIC_IRQSRC = 0x00
PMIC_STATUS1 = 0x10
PMIC_STATUS2 = 0x00
PMIC_PWRON = 0x02
PMIC_IRQ1 = 0x0c
PMIC_IRQ2 = 0x00
s5p_check_keypad: 0x0
s5p_check_reboot_mode: INFORM3 = 0 ... skip
s5p_check_upload: MAGIC(0xc0c0c0c0), RST_STAT(0x10000)
microusb_get_attached_device: STATUS1:0x38, 2:0x00
s5p_check_download: 0
microusb_get_attached_device: STATUS1:0x38, 2:0x00
check_pm_status: chargable jig, LPM boot
AST_CHARGING..
cmu_div:1, div:7, src_clk:800000000, pixel_clk:57153600
s6e8ax0_read_id :: retry: 1
s6e8ax0_read_id :: 0xd1
<start_checksum:373>CHECKSUM_HEADER_SECTOR :4096
<start_checksum:375>offset:50, size:6296
<start_checksum:379>CHECKSUM_HEADER_INFO : NeedChecksum:0 PartNo:20
Not Need Movinand Checksum
Movinand Checksum Confirmation Pass
autoboot aborted..
S-BOOT #
S-BOOT # help
Following commands are supported:
* chipinfo
* help
* log
* reset
* boot
* load_kernel
* printenv
* setenv
* saveenv
* findenv
* checksum_need
* usb
* upload
* keyread
* readadc
* usb_read
* usb_write
* sdcard
* mmcdtest
* fuelgauge
To get commands help, Type "help <command>"
S-BOOT #
That's it by now!
Consider this as a starter, i'll try to add, correct or change some things from time to time and i hope it's human readable
Please give me some feedback or tell me your thoughts
I will add pics as soon as possible and further details if there's some interest.
I will also give some credits soon, because some of these findings are based on information from the curious around here
Credits:
AdamOutler
E:V:A
References:
GT-I9300 hard-brick-fix
http://forum.xda-developers.com/galaxy-s3/general/galaxy-s-iii-gt-i9300-hard-brick-fix-t1916796
Totally Revolutionary SDCard Bootloader For Galaxy S III
http://forum.xda-developers.com/galaxy-s3/general/totally-revolutionary-sdcard-bootloader-t2061437
Port SDCard Recovery to Other Exynos4412 Devices
http://forum.xda-developers.com/showthread.php?p=34732948
Knox reset
http://forum.xda-developers.com/showthread.php?t=2504258
eMMC sudden death research
http://forum.xda-developers.com/showthread.php?t=2096045
NOTE:
I am not responsible for any damaged devices.
The technical information may need some verification by experiments!
It would be nice to add a remark and refer to this post, if you use the pics and information from this thread :highfive:
Cheers,
scholbert
technical info, datasheets... stuff
eMMC function, structure and usage
1. Basic info
The onboard eMMC is the mass storage of our device.
There's much more under the hood, than you might expect and notice during normal usage within the OS.
The area we may access from within Android OS is called USER area (all partitions belong to this area).
This part could be easily accessed and you may back up all data of this area to a disk image.
Apart from that, the eMMC is used as secure boot media.
On some of the ICS kernels there was a block device called /dev/mmcblk0boot0 (protected by ro-flag).
This device node is missing on most of the S3 devices and hence it is not possible to access this part.
Anyway, it is hidden area where Samsung placed the bootloader and stuff, the BOOT area.
If you are using still ICS bootloader it consists of at least 2 parts:
2MB area for BL1 (s-boot+TZSW+ddi-data)
2MB area for BL2 (not used, zeroed out)
If you upgraded to JB/KK bootloder another part is setup up and configured:
RPMB (KNOX counter, etc.)
I found no information about the size, but it's a multiple of 128K and may be set up between 128-512K.
Once activated the information stored in this area is controlled by internal security mechanism of eMMC.
Only trusted code is granted access and even worse, from a users sight it acts like OTP memory.
To get some info about the eMMC built in your device the sysfs entries are a good place to start.
We could grep the type of device form here, e.g. the eMMC in my GT-I9305 gives this output:
Code:
# cd /sys/class/block/mmcblk0/device
# cat name
MAG4FB
# cat manfid
0x000015
# cut -b 19,20 cid
f7 // this is the firmware revision in hex
# cat date
09/2012
See the datasheet attached (this is the exact part)
2. EFI partition and GPT
The first block of USER area of starts with traditional MBR.
Next block starts with the header for the EFI partition which is the base container for all other parts.
Code:
[SIZE="2"]45 46 49 20 50 41 52 54 Signature "EFI PART"
00 00 01 00 GPT version 1.0
00 02 00 00 header size 512 Bytes
5B DF 6D 84 CRC32 of header
00 00 00 00 reserved
01 00 00 00 00 00 00 00 Current LBA (location of this header copy)
FF 9F D5 01 00 00 00 00 Backup LBA (location of the other header copy)
22 00 00 00 00 00 00 00 First usable LBA for partitions (primary partition table last LBA + 1)
DE 9F D5 01 00 00 00 00 Last usable LBA (secondary partition table first LBA - 1)
41 4E 44 52 4F 49 44 20 4D 4D 43 20 44 49 53 4B ANDROID MMC DISK
02 00 00 00 00 00 00 00 Starting LBA of array of partition entries (always 2 in primary copy)
80 00 00 00 Number of partition entries in array
80 00 00 00 Size of a single partition entry (usually 128)
28 53 B2 A4 CRC32 of partition array
00 00 00 00[/SIZE]
The rest of this block is the GPT.
Reference:
http://en.wikipedia.org/wiki/GUID_Partition_Table
Other useful reading:
http://forum.xda-developers.com/showpost.php?p=31254495
3. PIT
This is another essential part of the USER area of eMMC and defines all partitions used by the OS.
Here's the definition of the internal structure:
Code:
[SIZE="2"]typedef int __s32;
typedef unsigned int __u32;
#define PARTITION_MAGIC 0x12349876
typedef struct _partition_header {
__u32 dwMagic; /* MAGIC CODE */
__s32 nCount; /* PARTITION (OneNAND + MOVINAND) */
/* PIT Option. */
__s32 dummy[5];
} __attribute__((packed)) partition_header;
typedef struct _partition_info {
__s32 nBinType; /* BINARY_TYPE_ (AP or CP?) */
__s32 nDevType; /* PARTITION_DEV_TYPE_ */
__s32 nID; /* PARTITION ID */
__s32 nAttribute; /* PARTITION_ATTR_ */
__s32 nUpdateAttr; /* PARTITION_UPDATE_ATTR_ */
__u32 dwBlkSize; /* BLOCK SIZE / OFFSET IN BLOCKS */
__u32 dwBlkLen; /* BLOCK LENGTH */
__u32 dwOffset; /* FILE OFFSET (obsolete) */
__u32 dwFileSize; /* FILE SIZE (obsolete) */
char szName[32]; /* PARTITION NAME */
char szFileName[32]; /* FILE NAME */
char szDeltaName[32]; /* DELTA FILE NAME FOR BOOTLOADER FOTA */
} __attribute__((packed)) partition_info;[/SIZE]
Example:
Code:
[SIZE="2"]BOOTLOADER:
00 00 00 00 nBinType; /* BINARY_TYPE_ (AP or CP?) */
02 00 00 00 nDevType; /* PARTITION_DEV_TYPE_ */
50 00 00 00 nID; /* PARTITION ID */
02 00 00 00 nAttribute; /* PARTITION_ATTR_ */
01 00 00 00 nUpdateAttr; /* PARTITION_UPDATE_ATTR_ */
00 00 00 00 dwBlkSize; /* BLOCK SIZE / BLOCK OFFSET */
C6 06 00 00 dwBlkLen; /* BLOCK LENGTH */
00 00 00 00 dwOffset; /* FILE OFFSET (in TAR) */
00 00 00 00 dwFileSize; /* FILE SIZE */
szName[32]; /* PARTITION NAME */
42 4F 4F 54 4C 4F 41 44 45 52 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
szFileName[32]; /* FILE NAME */
73 62 6F 6F 74 2E 62 69 6E 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
szDeltaName[32]; /* DELTA FILE NAME FOR BOOTLOADER FOTA */
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00[/SIZE]
4. Complete partition table (GT-I9305)
Code:
[SIZE="2"]Block Size = 0x200
BOOT AREA:
Partition Image Name OFFSET LEN in BLK LEN OS Partition Physical Partition
BOOTLOADER sboot.bin 0x00000000 0x06C6 0x000D8C00 0x50 0x50
TZSW tz.img 0x000D8C00 0x0138 0x00027000 0x51 0x51
DDI-DATA (DATA) - 0x000FFC00 0x0001 0x00000200
USER AREA:
Partition Name Image Name OFFSET LEN in BLK LEN OS Partition Physical Partition
eMMC MBR (MBR) - 0x00000000 0x0001 0x00000200
EFI PART (GPT) - 0x00000200 0x0001 0x00000200
PIT m3.pit 0x00004400 0x0010 0x00002000 0x46 0x46
MD5HDR md5.img 0x00006400 0x0800 0x00100000 0x47 0x47
BOTA0 - 0x00400000 0x2000 0x00400000 0p1 0x01
BOTA1 - 0x00800000 0x2000 0x00400000 0p2 0x02
EFS efs.img 0x00C00000 0xA000 0x01400000 0p3 0x03
m9kefs1 m9kefs1.bin 0x02000000 0x2000 0x00400000 0p4 0x04
m9kefs2 m9kefs2.bin 0x02400000 0x2000 0x00400000 0p5 0x05
m9kefs3 m9kefs3.bin 0x02800000 0x2000 0x00400000 0p6 0x06
PARAM param.bin 0x02C00000 0x4000 0x00800000 0p7 0x07
BOOT boot.img 0x03400000 0x4000 0x00800000 0p8 0x08
RECOVERY recovery.img 0x03C00000 0x4000 0x00800000 0p9 0x09
RADIO modem.bin 0x04400000 0x2c000 0x05800000 0p10 0x0A
TOMBTONES tombstones.img 0x09C00000 0x80000 0x10000000 0p11 0x0B
CACHE cache.img 0x19C00000 0x200000 0x40000000 0p12 0x0C
SYSTEM system.img 0x59C00000 0x300000 0x60000000 0p13 0x0D
HIDDEN hidden.img 0xB9C00000 0x118000 0x23000000 0p14 0x0E
OTA - 0xDCC00000 0x4000 0x00800000 0p15 0x0F
USERDATA userdata.img 0xDD400000 0x0000 0p16 0x10
[/SIZE]
5. DDI-DATA
In the hidden boot0 partition the values like the flash count are stored.
Triangle away is able to modify this data.
It's stored at 0x000FFC00 on the boot0 partition of emmc.
Code:
struct ddi_data {
int magic; // must be 0x12340012
int custom_flash_count;
int odin_count;
int binary_type; // 0 = samsung official, 1 = custom, 2 = "Unknown"
char model_name[16];
int rom_type; // this is the first 4 bytes of the decrypted 16 bytes
in the param partition. 0xFF000000 = samsung, 0xEE000000 = custom }
For details please refer to this post:
http://forum.xda-developers.com/showthread.php?p=28953690#post28953690
Further useful reading:
http://wiki.cyanogenmod.org/w/EMMC_Bugs
Thesis:
Remove KNOX bit by eMMC low level format command:
With KNOX activation at booloader level, there's an area which stores the KNOX bit information called RPMB.
During research of the eMMC sudden death, some firmware files for the eMMC controller had been reverse engineered and some of the custom commands had been discovered.
Read this and follow ups:
http://forum.xda-developers.com/showpost.php?p=49548099&postcount=121
By changing the boot mode and boot up completely from SD-card into special recovery, it might be possible to send this command with a tool called mmc-utils:
https://github.com/BenGardiner/mmc-utils
Because this will wipe out everything, it would be a great adventure and you'll need a proper backup of all significant parts from the internal eMMC. Otherwise device specific parameters will be lost forever.
See this remark as a reference as well:
http://forum.xda-developers.com/showpost.php?p=51297844&postcount=135
I'll spent some time to think about a useful SD-card layout... :laugh:
TBC
scholbert
All this looks knowledgeable
How are you at ROM/Kernel building?
Hi f0xy!
f0xy said:
All this looks knowledgeable
Click to expand...
Click to collapse
Thanks for this feedback!
I know these experiments are only for the fearless with good eyes.
For the average user there's no need to hack boot mode or stuff, unless there's some evil bricked device
I guess folks need pix
f0xy said:
How are you at ROM/Kernel building?
Click to expand...
Click to collapse
Depends...
On a hobbyist level i build many kernels, tweaked drivers and kernel code for personal use over the years.
Little less if we speak about building ROMs.
I might help out on some issues, but don't count on me for bigger projects.
Time is always lacking and often i'm too lazy to clean up the code for git
Cheers,
scholbert
Hi,
just added the complete partition table for GT-I9305 and some other stuff in the second post...
I try to sum up facts floating around as well and put it in the context of GT-I9305, so some info here is no breaking news
Anyway, enjoy the tech ride!
Regards,
scholbert
@mad_ady I seen your post in boeffla, some info here may be of help? Or maybe the @op can provide some help for you?
Regards
Thanks for the references. It helped me better understand where the partitioning information is kept. I didn't know our devices (I own a GT-9300) had a MBR/GPT table. I wonder, do other (non-samsung) devices use similar partitioning schemes? Or are there also other ways of keeping the partition layout that are in use?
Hi mad_ady!
mad_ady said:
Thanks for the references. It helped me better understand where the partitioning information is kept. I didn't know our devices (I own a GT-9300) had a MBR/GPT table. I wonder, do other (non-samsung) devices use similar partitioning schemes? Or are there also other ways of keeping the partition layout that are in use?
Click to expand...
Click to collapse
Yeah i guess other devices with onboard eMMC use GPT tables as well.
Though it is not completely clear at which level these are accessed.
I assume that the bootloader or even kernel is able to read this table during start up and is also aware of the sizes and boundaries.
The PIT table plays another role in this game.
AFAIK this is the reference for Odin/Heimdall and should match GPT boundaries.
Some experts are needed to confirm this or i'll have to dig a little deeper myself
Regards,
scholbert
Hi there,
i made a comparison between the cmdline passed to the kernel by "old" and "new" bootloaders.
Just started some investigation to fix "offline charging" with KK stock running on devices which still got the old bootloader.
Here's the default cmdline "old" vs. "new":
Code:
[SIZE="2"]JB 4.1.2 (I9305XXBME3) KK 4.4.4 (I9305XXUFNJ1)
console=ram console=ram
loglevel=4 loglevel=4
androidboot.baseband=mdm androidboot.baseband=mdm
sec_debug.level=0 sec_debug.level=0
sec_watchdog.sec_pet=5 sec_watchdog.sec_pet=5
androidboot.debug_level=0x4f4c androidboot.debug_level=0x4f4c
[email protected] [email protected]
- [email protected]
- [email protected]
s3cfb.bootloaderfb=0x5ec00000 s3cfb.bootloaderfb=0x5ec00000
lcdtype=96 lcdtype=96
consoleblank=0 consoleblank=0
lpcharge=0 -
lpj=3981312 lpj=3981312
vmalloc=144m vmalloc=176m
oops=panic oops=panic
pmic_info=67 pmic_info=67
cordon=<32-Byte hash value> cordon=<32-Byte hash value>
- connie=GT-I9305_OPEN_EUR_<32-Byte hash value>
androidboot.emmc_checksum=3 androidboot.emmc_checksum=3
- androidboot.boot_salescode=
- androidboot.odin_download=1
androidboot.bootloader=I9305XXBME3 androidboot.bootloader=I9305XXUFNJ1
- androidboot.selinux=enforcing
- androidboot.warranty_bit=1
- androidboot.sec_atd.tty=/dev/ttySAC2
androidboot.serialno=<16-Byte serial> androidboot.serialno=<16-Byte serial>
snd_soc_core.pmdown_time=1000 snd_soc_core.pmdown_time=1000[/SIZE]
As you might see there's the keyword lpcharge, which is not present on the "new" bootloaders.
On the new bootloaders there's the additional parameter android.bootmode=charger, if you start up with a charger plugged in.
On KK stock some proprietary binaries identify this keyword to activate offline charging.
Some kernel drivers (battery) react to this string as well and there's a patch already.
There'd been some attempts to fix this in initial ramdisk by hi-jacking cmdline present in /proc/cmdline and replace lpcharge=1 with android.bootmode=charger .
My first idea was, to make use of a similar function at kernel level and append android.bootmode=charger to the "old" bootloader cmdline, if lpcharge is set to 1 (similar to a conditional CONFIG_CMDLINE_EXTEND function).
The kernel itself will put this in /proc/cmdline afterwards and user space tools will be satisfied.
Some years ago i tweaked some kernel code for Archos tablets, which made use of custom ATAG keys to hand over some device specific parameters. Maybe i'll get something out of it
For my personal reference:
http://forum.xda-developers.com/galaxy-tab-3/general/kitkat-t31x-t2892792/post55863790#post55863790
TBC
Cheers,
scholbert
Hello.
Thanx for your Thread. For some summary about I9300 and I9305.
:good:
Please I need some input for my low brain...
I'm playing with I9300 and Tizen RD-PQ stuff...
My questions.
How to dump whole mmcblk0 ? Without direct eMMC Hardware...
Maximum 11 GB I can dump in internal sdcard...
http://forum.xda-developers.com/showpost.php?p=59503847&postcount=14
If I try to dump to external SD... I can only dump 4 GB...
RD-PQ sboot seems to work with I9300...
RD-PQ dump shows uboot at address 0x10000 and Tizen PIT is at 0x8000...
Tizen 32 MB dump for study...
http://forum.xda-developers.com/showpost.php?p=55514573&postcount=36
My theory... sboot is maybe at end of eMMC...
I can only check if I dump whole eMMC...
Thanx for every input.
Best Regards
The 4GB is a FAT32 limitation. You can try to format your external SD to ext3 or you can try to mount (via CIFS/NFS) a remote storage on which to dump.
Or, you can dump the device in blocks, starting with a specific offset and having a specific length:
http://superuser.com/questions/3807...m-the-specified-offset-but-not-dd-bs-1-skip-n
Hi!
adfree said:
My questions.
How to dump whole mmcblk0 ? Without direct eMMC Hardware...
Maximum 11 GB I can dump in internal sdcard...
http://forum.xda-developers.com/showpost.php?p=59503847&postcount=14
If I try to dump to external SD... I can only dump 4 GB...
Click to expand...
Click to collapse
See mad_ady's comment:
mad_ady said:
The 4GB is a FAT32 limitation. You can try to format your external SD to ext3 or you can try to mount (via CIFS/NFS) a remote storage on which to dump.
Or, you can dump the device in blocks, starting with a specific offset and having a specific length:
http://superuser.com/questions/3807...m-the-specified-offset-but-not-dd-bs-1-skip-n
Click to expand...
Click to collapse
From kernel level it is only possible to dump user area (unless you use a specific kernel with mmcblk0boot0 and mmcblk0boot1 enabled).
Read again this quote form my second post:
The area we may access from within Android OS is called USER area (all partitions belong to this area).
This part could be easily accessed and you may back up all data of this area to a disk image.
Apart from that, the eMMC is used as secure boot media.
On some of the ICS kernels there was a block device called /dev/mmcblk0boot0 (protected by ro-flag).
This device node is missing on most of the S3 devices and hence it is not possible to access this part.
Anyway, it is hidden area where Samsung placed the bootloader and stuff, the BOOT area.
If you are using still ICS bootloader it consists of at least 2 parts:
2MB area for BL1 (s-boot+TZSW+ddi-data)
2MB area for BL2 (not used, zeroed out)
Click to expand...
Click to collapse
adfree said:
RD-PQ sboot seems to work with I9300...
RD-PQ dump shows uboot at address 0x10000 and Tizen PIT is at 0x8000...
Tizen 32 MB dump for study...
http://forum.xda-developers.com/showpost.php?p=55514573&postcount=36
Click to expand...
Click to collapse
Interesting geek stuff... did you made any progress here, e.g. booting with RD-PQ?
adfree said:
My theory... sboot is maybe at end of eMMC...
I can only check if I dump whole eMMC...
Click to expand...
Click to collapse
Nope... it's at the very start of eMMC in a seperate area, normally hidden from user (see my comments above).
See datasheet attached, maybe this helps to understand how eMMC works.
EDIT:
Found the exact part which is soldered on my GT-I9305 mainboard.
See second post for reference as well:
http://forum.xda-developers.com/showpost.php?p=56747098&postcount=2
I'll leave this older datasheet her as well... this is at least a similar part.
Good luck and best regards,
scholbert
Interesting geek stuff... did you made any progress here, e.g. booting with RD-PQ?
Click to expand...
Click to collapse
I have problems to check my progress... because broken/damaged Display...
I see only black...
In Android I can use ADB stuff to see something...
Writing 32 MB RD-PQ dump not kill I9300... (no idea if this could kill IMEI, EFS or other Security stuff)
But I can't see where it hangs or if something is on Display...
Writing only s-boot-mmc.bin (200 KB sboot) from RD-PQ...
I have no idea yet, how to check if really written or ignored by I9300 sboot...
Code:
getprop ro.bootloader
Gives no anwser...
And this feature looks like Kernel related stuff...
Example why I am unsure if 200 KB sboot is accepted...
In I9300 you can find easily string ODIN in sboot...
But in RD-PQ is no ODIN text string... then why my I9300 works without problems with Odin...
I need some time to buy cheap working Display...
So I can see "visual effects" on Display...
1 goal would be this:
SDCARD MODE
COPY BINARY FROm SDCARD..
COPY BINARY TO EMMC..
SDCARD DOWNLOAD COMPLETED.
Click to expand...
Click to collapse
In Tizen world it seems mandatory to restore uboot... it contain the THOR string for THOR Downloader...
https://lists.tizen.org/pipermail/general/2013-November/002707.html
For me it is not clear enough... if RD-PQ sboot loads uboot...
sboot AND uboot is executed...
OR it is or feature...
Only uboot could be enough to executed...
About dump mmcblk0...
Code:
dd if=/dev/block/mmcblk0 skip=0 count=10000000 of=/sdcard/dump_v1.bin
dd if=/dev/block/mmcblk0 skip=10000000 count=10000000 of=/sdcard/dump_v2.bin
dd if=/dev/block/mmcblk0 skip=20000000 of=/sdcard/dump_v3.bin
This seems to work... but last 1 is again 11 GB + big...
It starts after with beginning...
I need proper count value... need some time and calculator...
I hope next week I have working Display for my testdevice...
Best Regards
eMMC hacking.... SD card boot... remove KNOX bootloader... finally?
Hi again,
i'd like to refer to a software package which seems to have leaked from a service center or similar some time ago.
Please refer to this thread, which explains how to revive hard bricked S3 devices and other Exynos devices:
http://forum.xda-developers.com/galaxy-s3/general/samsung-s3-i9300-note2-n7100-i9500-s4-t2647558
I found this package at several other places in the web as well, and it might be useful for some smart experiments :angel:
Here's what i got from it...
S3 repair contains a test suite for low level tests and tasks to setup up S3 from scratch.
You'll have to prepare a MicroSD card with a low-level tool (similar to dd command in linux).
The write script gives an idea about the offsets used on the SD card (multiples of 512 bytes), so i translated those to hex values:
emmc_auto.sbl.bin:1:499OFF: 0x00000200 LEN: 0x0003e600
E4412_S.TN.bl1.bin:9500:16OFF: 0x004a3800 LEN: 0x00002000
S5E4412_asb.bin:20000:40000OFF: 0x009c4000 LEN: 0x01388000
asb.ramfs:80000:97000OFF: 0x02710000 LEN: 0x02f5d000
From what i got by investigating the hex data of these binaries, the functions should be:
- emmc_auto.sbl.bin -> a bootloader suitable to start from SD card only
- E4412_S.TN.bl1.bin -> trustzone binary which sets up this part of the SoC for SD card boot
- S5E4412_asb.bin -> a standalone tool and testsuite compiled as a ready to run binary (no elf format here!)
- asb.ramfs -> a proprietary RMFS formatted ramdisk which carries some test files (e.g. test pattern, test videos, etc.)
A quite interesting piece of code is the S5E4412_asb.bin file.
So grepping some strings in this binary file gave this section, which is responsible for
vendor boot size change with CMD62 (refer to the eMMC datasheet as well) and seems to restore the bootloaders:
Code:
0x093DB6 0x2B APP STEP] Step 1. BL Download Address Set
0x093DE6 0x2D APP STEP] Step 2. DRAM Download Address Set
0x0943CA 0x0A NA,\NA0\NA
0x0943D6 0x0A NA$\NA(\NA
0x0943FE 0x2D APP STEP] CMD 0xEFAC62EC : RESPONSE 0x%08x %
0x094432 0x2B APP STEP] CMD 0xCBAEA7 : RESPONSE 0x%08x %
0x094462 0x32 APP STEP] Boot Partition Size : RESPONSE 0x%08x %
0x09449A 0x32 APP STEP] RPMB Partition Size : RESPONSE 0x%08x %
0x09472A 0x24 APP STEP] CMD 6 : RESPONSE 0x%08x %
0x094756 0x2B APP STEP] BL1 & BL2 loading Address : 0x%x
0x094786 0x2C APP STEP] Dram Image loading Address : 0x%x
0x0947B6 0x34 APP STEP] BL1 & BL2 compare address for Read : 0x%x
0x0947EE 0x35 APP STEP] Dram Image compare address for Read : 0x%x
As user Oranav pointed out in the eMMC sudden death research thread, there might be commands
which should initiate low level formatting of the eMMC chip:
CMD62 (ARG: 0xEFAC62EC)
CMD62 (ARG: 0xFAC0021)
This might probably delete all the chip metadata (incl. wear leveling state and bad block info)
and if these commands are correct, it will also reset KNOX counters and stuff.
In other words this is a full factory wipe of eMMC cells.
These are some snippets in S5E4412_ASB.bin located at:
0x8A41C0:
Code:
A5 A2 04 00
80 22 06 00
EC 62 AC EF = CMD62 (ARG: 0xEFAC62EC)
00 00 04 12
31 0C 62 00
71 1F 04 00
AB C2 9E FF
5A 7B B6 F0
83 68 AE 0F
CD 12 04 00
21 00 AC 0F = CMD62 (ARG: 0xFAC0021)
EE CC DE 00
A9 40 35 FF
BD AE 33 F1
80 97 72 00
1D 28 04 00
...and again at:
0x8C43F0
Code:
2D A2 04 00
CD A4 04 00
80 22 06 00
EC 62 AC EF = CMD62 (ARG: 0xEFAC62EC)
00 00 04 12
31 0C 62 00
AB C2 9E FF
5A 7B B6 F0
9F 1B 04 00
83 68 AE 0F
47 0F 04 00
21 00 AC 0F = CMD62 (ARG: 0xFAC0021)
EE CC DE 00
A9 40 35 FF
BD AE 33 F1
80 97 72 00
This could be some approval for the usage of these commands at least, because these sections are pure ARM assembly and seem to be associated with eMMC low level setup.
I'll have to find out some offsets for this machine code to try a disassembly.
Maybe this will lighten things up even more.
EDIT:
BTW, found one of the main return addresses which is at 0x40008000 (physical address at the beginning of DRAM). Let's see if this is correct.
EDIT2:
Bingo... just had a look in my boot logs i once grepped during UART session:
Starting kernel at 0x40008000...
Conclusion:
The ASB test suite (S5E4412_asb.bin) is booted/started at the same offset as the linux kernel does.
Let's see what this may give us
Another thing to mention is, that included in S5E4412_asb.bin there's a M0 test bootloader (GT-I9300).
Have a look at offset 0x08d8fe8 inside the binary
So in the end i wonder, if someone has ever used this "Service" card together with a real UART connection to the board.
Apart from the automated test and setup process, my guess is, that there should be some command line or some kind of a test menu which may give alternative choices to proceed certain tasks.
P.S.: Maybe it's hard to understand what i like to point out here... but imagine we use the following:
- emmc_auto.sbl.bin -> a bootloader suitable to start from SD card only
- E4412_S.TN.bl1.bin -> trustzone binary which sets up this part of the SoC for SD card boot
- recovery.img -> kernel + recovery to start completely from SD card (eMMC not touched here!!!)
P.P.S: Let's see if the SD card boot files look for a signature here.....
Stay tuned!
scholbert
... further experiments
Hi,
i made further progress with my attempts to boot my GT-I9305 completely from external MicroSD.
As proposed in my last post i prepared a card with the following commands:
Code:
echo "Exynos4412 FWBL1+BL2"
dd if=./emmc_auto.sbl.bin of=/dev/sda bs=512 seek=1
echo "Exynos4412 TZSW"
dd if=./E4412_S.TN.bl1.bin of=/dev/sda bs=512 seek=9500
Next is to prepare the board.
You'll need Anyway JIG or a dedicated UART connection as described in my first post.
To block access to internal eMMC the resistor R634 on the GT-I9305 mainboard got shorted.
Insert the MicroSD with the proprietary boot files into the socket.
Connect to a terminal and attach supply voltage of 3.8-4.0V to the battery connector.
Press the power button and hold it.
Here's the output so far:
Code:
TN default
<OK>
<OK>
[DVFS] INT(1) : 0
DRAM Type : LPDDR2 16G
[DVFS] MIF(3) : 0
[EPLL][VPLL][CLK_DIV] OK
<OK>
[LOCK SW/HW]ARM:0/0 INT:0/0 G3D:0/0 MIF:0/0 SHIFT:0/0
[DVFS] ARM(0) : 5
[DVFS] INT(1) : 0
[DVFS] G3D(2) : 0
[DVFS] MIF(3) : 0
[SD_INIT
SDMMC_HighSpeed:DONE]
SD_READ: 20000 20000 0x40008000 -> 422650 usec
<OK>
Inp32(uAddr) : 0x0
LINUX Bootingøq!ñ¥¡Õ
At this point there are no further outputs, as there's nothing to be executed.
Like known from the sboot, hitting enter on your terminal from the very beginning gives a commandline interface.
Unfortunately, it seems that the watchdog is not stopped at this point and maybe the PMIC is not fully initialized.
This leads to repeated resets.
Anyway if you're fast enough, you may get this command list from the proprietary bootloader:
Code:
BL>help
CMD LIST
LOG
WAIT
USB
GET
JUMP
RUN
RUN2
INIT
INIT2
DMC
CLK
DVFS
ASV
DVFSQA
EMA
PMIC
SD
EMMC
ZIP
ABB
RESET
DUMP
MEMCPY
MEMCMP
MEMSET
OUTP32
INP32
SETBITS
GETBITS
COPYRUN
MEMCPY_RUN
PATTERN
BOOT
CTA
ASB
COM
HELP
H
TEST
TN
<OK>
BL>
Some of these commands play an important role for starting up the ASB test suite if present.
These command are included in BL2 and they seem to be interpreted by ASB:
Code:
TN M0|PMIC
INIT2 3|init2|TEST
EMMC
0x10020800 1|TEST RUN
I started to mod these, but as far as i did not start the ASB image yet there's nothing to observe.
By looking at other logs from brick recoveries, i found a relationship between the first output of ASB and these commands.
My idea is that by changing these we could influence the behaviour of the ASB code for educational purpose.
As described above, without parts of ASB the PMIC seems not to be fully initialized,
because i found out that you need to hold the power button to keep the board alive.
This is little strange, as i am pretty sure that this was not the case in the begining, but maybe i'm wrong.
Anyway as far as i observed it, the board starts normally from internal eMMC after my experiments had finished.
At least nothing indicates that something got damaged...
Just to check out what happens i put a raw recovery image at position 20000 (0x9c4000) on the card.
This is the beginning of kernel code.
Afterwards i started a new terminal session and i saw that the first command of kernel code got printed,
but unfortunately after the bootcode jumps to this code there's no further output.
Something is still missing.
Could be something obvious (e.g. missing TAGS at 0x40000100) or could be not.
Maybe it would be a good idea to compile a version of u-boot and try again.
Let's see
scholbert
....grrrr
Hi again!
First of all, nice to see that at least two guys follow my binary surgery.
Second, i must admit that the platform is not that responsive as i first thought.
Due to all this signing stuff, it is easy to break something and CPU simply stops executing code.
So for now there's nothing, than further logging outputs from the console.
1. I removed some of the start up commands from BL2, which leaves TN M0|PMIC & INIT2 3|init2|TEST for ASB code.
This is what i got then:
Code:
TN default
<OK>
<OK>
[DVFS] INT(1) : 0
DRAM Type : LPDDR2 16G
[DVFS] MIF(3) : 0
[EPLL][VPLL][CLK_DIV] OK
<OK>
[CHIPID] E4412 EVT1.1
LOTID WNO X Y IDS HPM ASV_GRP FUSE SHIFT
[LOG]N571A 18 201 195 22 22 8 -1 100000 80
There's no auto booting anymore at this point.
2. I put anything back, apart from the RUN command.
During this test i used a modified ASB binary with sboot from I9305XXALI4 put in the right place.
Unfortunately the output stops after "FW Booting"
The device kept being powered though. Which is a good thing from my guess.
Here's the log:
Code:
TN default
<OK>
<OK>
[DVFS] INT(1) : 0
DRAM Type : LPDDR2 16G
[DVFS] MIF(3) : 0
[EPLL][VPLL][CLK_DIV] OK
<OK>
[LOCK SW/HW]ARM:0/0 INT:0/0 G3D:0/0 MIF:0/0 SHIFT:0/0
[DVFS] ARM(0) : 5
[DVFS] INT(1) : 0
[DVFS] G3D(2) : 0
[DVFS] MIF(3) : 0
[SD_INIT
SDMMC_HighSpeed:DONE]
SD_READ: 20000 20000 0x40008000 -> 422818 usec
<OK>
Inp32(uAddr) : 0xea00007e
FW Booting
Right now it's a bit to early for further conclusions, but maybe the signing stuff got broken at some point in both cases.
It could also be that some of the signatures is especially for GT-I9300, or in other words the CPU on GT-I9305 uses a different key set.
That's it by now, but i won't give up yet
Cheers,
scholbert
Wow, that's one of the most insightful threads about 4412 I've seen for a while.
Replying here on OP's PM for further reference:
* At LenovoK860 uboot sources:
These seem to contain private keys for some batch of 4412 - that's the first time I see private signing keys of any Exynos to leak. Previous leaks were just wild security-dropping bootloader stages signed with private keys, but no keys included.
These keys can either match batch customized for Lenovo or match all 4412 (Exynos4 public key hash fuses, in theory, meant to be factory/OEM customizable) - I'd say the latter since neither GS3 or any common device built on S5PC2xx I've seen was expected to have any grade of real security, so probably neither Lenovo or Samsung cared to customize any of Exynoses used around.
There is a way to check it by comparing dumps from 0x10100000 area between GS3 and LenovoK860 CPUs (I'm uncertain, as I'm really rusty). Probably there's also other way by comparing Lenovo stage1 public keys with GS3 0x1010_0000 dumps, considering how pubkey is validated against these bits (no idea, don't remember).
* At My and Adam's tries:
We were quite succesfull in running UBoot on I9300 and GalaxyCam GC100.
What we couldn't achieve was kernel booting - Exynos4 kernels require TZSW to be fully operating and communicating with it. I couldn't get it to load up properly.
There's quite of history of our tries under https://github.com/Rebell/exynos4_uboot/commits/master
Another option is, of course, disabling TZSW support in kernel and not booting it at all - it doesn't seem to work out-of-the-box either, and would make impossible to boot any non-modded kernels.
AFAIR (and boy, was it while ago), referenced sources were building and fusing to the SD card flawelessly and supporting both fastboot and UART terminal with most (all?) of the commands working (yes, it can do raw R/W to eMMC and whatnot in SVC mode without TrustZone supervisor interfering, because it's not loaded at all yet). Just kernel wouldn't boot. I'd say you should give it a try (if you didn't already).
The crucial part we used there was FWBL1 (there https://github.com/Rebell/exynos4_uboot/tree/master/sd_fuse) - first, already signed, stage of bootloader hat's doing nothing but loading another stage of bootloader without any security (kudos to Odroid).
We couldn't find any equivalent of signed FWBL1 for Exynos4210 (GS2 CPU) that would allow us booting eMMC hardbricked GS2 devices.
* At ASB:
First time I hear of it. Never seen this stuff before.
... just an update
Hi,
it's been a while now that i found some time to fiddle around with one of my i9305 mainboards.
In the meantime there'd been some nice conversation via PM with Rebellos as well.
u-boot on Galaxy S3
Find the sources here:
https://github.com/Rebell/exynos4_uboot
So i finally gave it a try, jumped on his work and compiled a version of u-boot for Galaxy S3 devices.
As a prerequisite you'll have to block eMMC and to make it short...
It just works!!!
Attached you'll find a log from external sdcard boot.
Maybe i'll do some tweaks in the near future, e.g. remove the annoying "pmic_s5m8767_init" messages,
as there is no such device on our S3.
s-boot for Tizen on Galaxy S3
On the Tizen Wiki (https://wiki.tizen.org/wiki/Flash_Tizen_2.2.1_Image_to_Reference_Device)
there's a link to a tar with image files (Tizen_RD-PQ_System_20131107_1.tar), which contains a s-boot file.
Unfortunately the signature of BL1 inside the s-boot image seems not fit the mass production units.
In other words no boot message here at all... at least while trying to boot from sdcard.
mass production sboot on external SD-card
On the other hand the mass production units sboot images are ready to boot from sdcard as well.
Find the second log attached below.
The error messages are normal, because i blocked eMMC all the time, to prevent bricking during my experiments.
security key validation
As you'll see in the logs i dumped the region at 0x10100000 for the security key values.
Here's a snippet of the secure boot function header in the u-boot sources:
Code:
#define MAX_EFUSE_DATA_LEN 16
typedef struct
{
unsigned char rsa_n[128]; /* RSA Modulus N */
unsigned char rsa_e[4]; /* RSA Public Exponent E */
} RawRSAPublicKey;
typedef struct
{
RawRSAPublicKey rsaPubKey; /* RSA PublicKey */
unsigned char signedData[20]; /* HMAC Value of RSA PublicKey */
} PubKeyInfo;
/* Secure Boot Context */
typedef struct
{
RawRSAPublicKey stage2PubKey; /* Stage2 RSA Public Key */
unsigned char code_SignedData[128]; /* RSA Signature Value */
PubKeyInfo pubKeyInfo; /* Stage1 RSA PublicKey and it's HMAC value */
unsigned char func_ptr_BaseAddr[48]; /* Function pointer of iROM's secure boot function */
unsigned char test_eFuse[MAX_EFUSE_DATA_LEN];
unsigned char reservedData[36];
} SecureBoot_CTX;
If i assume S3 still uses V1.1 security with 1024Bit RSA (BL1.bin is 8192Byte) the efuse key would be 128Bit, which results in 4 registers with 32Bit length.
Exported to a hex dat file this is 16Byte of Hex data.
Dump at 0x10100000 gives:
Code:
10100000: 0d19a391 2a0502af 1576987a 212121bc .......*z.v..!!!
We'll have to re-arrange the bytes for little endian order:
Code:
91a3190d af02052a 7a987615 bc212121
... use a hex-editor and put these into a file named: eFuseData.dat
Next i took codesigner_v21 and tried to validate stock BL1 files if they match.
codesigner_v21 -v1.1 <BL1.bin> <eFuseData.dat> -VERIFY
Unfortunately no succes yet... signature verification always failed.
This is a mistery, because the position of the key should be correct and i used valid bootloader files as well.
Anyway this had been only a proof of concept if we got the right tool and the right efuse values.
TBC
Cheers,
scholbert
@scholbert
Please, need collection of GT-I9305 Bootloader....
Something like this:
http://forum.xda-developers.com/galaxy-s3/general/guide-extract-bootloader-make-flashable-t2864264
http://forum.xda-developers.com/galaxy-s3/general/ref-galaxy-s3-stock-kernel-bootloaders-t2189063
For now I was only able to find
RESTORE_BOOTLOADER_I9305XXALI4.zip
http://forum.xda-developers.com/showpost.php?p=32760677&postcount=1
I need few more for stupid tests.
For now my test GT-I9300 PCB is able to start this sboot.bin from GT-I9305... with tweezer.
sboot.bin is copied successfully... but not start in "normal mode"...
Here I can see other method... sboot.bin is not copied to eMMC but fully executed from eMMC, with Boot menu:
http://forum.xda-developers.com/showpost.php?p=64664423&postcount=278
I will check if GT-I9305 has similar Bootloader and if it will executed on my GT-I9300 test PCBs.
Thanx in advance.
Best Regards
I found this:
I9305XXUFNL1-DBT.zip
Here is sboot.bin from GT-I9305 inside... I have attached.
Search for text String THOR... you can find:
Code:
- Thor is connected!
This could mean... I9305 is Tizen enebled... not only this...
Chance to play with U-Boot.
Tried on I9300 with no luck...
Volume + or Volume - do nothing... maybe Hardware Keys different...
I hope to find something working for my I9300...
Btw.
First time I saw THOR string also in Note 4 N910C:
http://forum.xda-developers.com/showpost.php?p=64663039&postcount=65
Best Regards
Hey guys, Honestly Annoying here! I worked on rooting the G5 for about 9 months last year, and finally got it after receiving a userdebug kernel.
I spent a lot of time researching and talking with tons of different devs, and here is a list of all of the information I have collected.
UNLOCK.BIN
First of all, this is ONLY for the devices that LG officially unlocks. It is processed by fastboot (aboot partition) and unless LG unlocks it officially, it will not recognize the "fastboot flash unlock unlock.bin" command. At this point there is no point in talking about this because the T-Mobile variant does NOT accept an unlock.bin to unlock, it accepts the oem fastboot command.
TL;DR: The unlock.bin is useless for any American G6. Don't waste your time trying to spoof it.
If you still want to attempt and spoof it (for some reason), it isn't possible. Some great explanations on how it is coded and works are posted in this thread here, make sure to leave those guys a thanks.
TOT INJECTING
For the G5, this was the only way T-Mobile users could achieve root before dirtyc0w. Unfortunately, this is not a liable option for the G6 (or v20) anymore, as LG is now signing the TOTs and the LAF partition will brick the device if an unsigned TOT is flashed. I have a theory on why this is the case, but don't want to accuse anyone of something if I am wrong (if you do a bit of research about this you will understand). I would not recommend trying this out as it will brick your device.
LG LAF BACKDOOR
If you have been with the LG scene for a while, you may know about the LAF backdoor. It has been documented publicly here (PLEASE leave him a thanks!), and there are a few other things that I have discovered with this as well that are not public as of now as I am not exactly sure what to do with them (PM for details). LG did patch this tool, but part of the code still works and with some work we could possibly figure out the new code. At this point I believe this is the most likely way to flash TWRP (use the dd command), but I have not been able to look at the new LAF commands as I do not own the G6.
TL;DR: LF LAF Backdoor probably still exists, it will just take work to find it out. If someone does figure out the new codes TWRP is easily flashable
DIRTYC0W
This was patched in December/November. Don't waste your time trying this out, as it has been confirmed not to work.
This is all of the information I can think of right now, I will continue to update this thread as I can think of other things to not waste time testing.
man, good thing i didn't sell my 3t , i kind of , sort of, can't live without molesting my device.
what are the chances the at&t version will be rooted? just got mine today, really like it but no root ill be taking it back.
I believe we are on the same page of why the tot files are being signature enforced now...
Sent from my LG-H918 using XDA-Developers Legacy app
fix-this! said:
what are the chances the at&t version will be rooted? just got mine today, really like it but no root ill be taking it back.
Click to expand...
Click to collapse
I think you will be taking it back...unless you dont mind waiting for a long time.
I really like the G6. i think LG nailed it this time but for me its a paperweight since it was likely to be BL locked.
Sent from my Note 7, S7 Edge or S6
Just a heads up, carrier locked LG G5's are still unrooted. I would imagine that the G6 would follow a similar fate.
henryjumbo said:
Just a heads up, carrier locked LG G5's are still unrooted. I would imagine that the G6 would follow a similar fate.
Click to expand...
Click to collapse
I couldn't agree more. T-Mobile is the only one that allowed oem unlock in the us of all carriers so naturally it was eventually rootable.
This thread shows how to enable disabled fastboot commands on the Alcatel OneTouch Idol 3, maybe we could also use this method: https://forum.xda-developers.com/idol-3/development/6039-guide-how-to-return-fastboot-t3201077
nima0003 said:
This thread shows how to enable disabled fastboot commands on the Alcatel OneTouch Idol 3, maybe we could also use this method: https://forum.xda-developers.com/idol-3/development/6039-guide-how-to-return-fastboot-t3201077
Click to expand...
Click to collapse
Link doesn't work
Josh McGrath said:
Link doesn't work
Click to expand...
Click to collapse
Just clicked on it and it worked, you might have to go back to the first page though.
nima0003 said:
Just clicked on it and it worked, you might have to go back to the first page though.
Click to expand...
Click to collapse
That's weird, it still doesn't work for me :/ oh well, no biggie
Honestly Annoying said:
LG LAF BACKDOOR
If you have been with the LG scene for a while, you may know about the LAF backdoor. It has been documented publicly here (PLEASE leave him a thanks!), and there are a few other things that I have discovered with this as well that are not public as of now as I am not exactly sure what to do with them (PM for details). LG did patch this tool, but part of the code still works and with some work we could possibly figure out the new code. At this point I believe this is the most likely way to flash TWRP (use the dd command), but I have not been able to look at the new LAF commands as I do not own the G6.
TL;DR: LF LAF Backdoor probably still exists, it will just take work to find it out. If someone does figure out the new codes TWRP is easily flashable
Click to expand...
Click to collapse
Thank you for the information. I'd be open to trying to flash TWRP using lglaf. But too much, including my job, depends on my having a functional, non-bricked phone. If I were to give this a shot and it turns out that my phone decides it wants to punch me in the eye, would I be able to use LGUP and flash the stock KDZ and have a functioning phone again? Obviously, nobody can really give a certain "Yes" to such a question, but I'd be happy with something along the lines of, "Unless you shoot yourself in the foot and/or your phone gets struck by lightning during the flash process, you should be good."
That said, I have another question. To be honest, I don't really care if my phone is rooted or not. In fact, I like using Android Pay. All I really want to do is have a usable phone in my home, where I have almost zero mobile signal. Unfortunately, that requires making a few small changes to /system/etc/wifi/WCNSS_qcom_cfg.ini.
Last time I was in LG Land, I don't think there was yet an "lglalf" utility. There was the "send_command" utility instead. Regardless, I seem to recall using this utility to mount /system/ RW, making the changes I wanted to /system/etc/wifi/WCNSS_qcom_cfg.ini, rebooting, and having an unrooted V10 that even took OTA updates, retained my changes to that file, and had working WiFi as a result.
Any thoughts on using the same methodology with the lglaf utility on the G6? My concern is that the bootloader or some other process may be doing some kind of checksum and, if the hash doesn't match what it expects to see, it will basically crap itself and tell me my phone is not safe, etc.
P.S. I spend many work days staring at wireshark captures trying to find the source of spanning tree goofiness on networks that are /20 and /21 in size. So, staring at USB packet dumps to try to make heads or tails out of what is going on would not bother me in the slightest, should you wish to give me a push in the right direction.
I spent some time messing around with the lglaf tool today. The normal version doesn't work, most commands give error code 0x8000010a. Apparently, that is the result of some additional security LG added to the process, in the form of a handshake. I found a pull request that adds an --unlock option here: https://github.com/Lekensteyn/lglaf/pull/12 - note that the code in the pull request is not compatible with python 3, so you'll need to be on python 2 to run it. The --unlock switch is not a bootloader unlock, but it triggers the authentication handshake. Unfortunately, neither of the keys provided along with that worked with the G6. So, if there are no other changes to the laf other than a new key, figuring out the new key might be enough to make some additional progress.
any peoples out there have access to:
extra G6 boards...
or broken G6..
or bad esn/imei G6..
or bricked G6.. etc?
Would love to start poking this device but I'm still paying off my G5.
Every now n then a repair tech or service center worker comes along.. and sometimes they have access to damaged/broken devices that are just collecting dust. I'm not looking for donations or anything like that.. just need a G6 board to work with.
Hit me up on my Twitter or something if you might have access to these things... https://twitter.com/@utoprime
autoprime said:
any peoples out there have access to:
extra G6 boards...
or broken G6..
or bad esn/imei G6..
or bricked G6.. etc?
Would love to start poking this device but I'm still paying off my G5.
Every now n then a repair tech or service center worker comes along.. and sometimes they have access to damaged/broken devices that are just collecting dust. I'm not looking for donations or anything like that.. just need a G6 board to work with.
Hit me up on my Twitter or something if you might have access to these things... https://twitter.com/@utoprime
Click to expand...
Click to collapse
Autoprime, after you pay off that G5, you can call T-Mobile or contact them from Twitter and they can do JOD. 3 upgrades a year. I just paid off my G4 and am doing that now and got the S8+. Then I can jump to the V30, then jump to the Pixel 2 possible all this year.
Sent from my SM-G955U using Tapatalk
MicroMod777 said:
Autoprime, after you pay off that G5, you can call T-Mobile or contact them from Twitter and they can do JOD. 3 upgrades a year. I just paid off my G4 and am doing that now and got the S8+. Then I can jump to the V30, then jump to the Pixel 2 possible all this year.
Sent from my SM-G955U using Tapatalk
Click to expand...
Click to collapse
not a bad idea.. it's a great way to get multiple phones in a year. the only thing keeping me from hopping on JOD is that I'd probably regret giving the phones back.. never know when you need to revisit an old phone to test something. But doing something like JOD may be the only way I can get multiple phones.. we shall see when it comes time to pay off my G5
I don't even use these phones as my main device.. they never leave my desk and often never even have a sim card put in them. So if I could get my hands on just a board.. or broken phone or something that'd be most ideal for my situation. But.. we can't always get what we want now can we? :crying:
hendusoone said:
I spent some time messing around with the lglaf tool today. The normal version doesn't work, most commands give error code 0x8000010a. Apparently, that is the result of some additional security LG added to the process, in the form of a handshake. I found a pull request that adds an --unlock option here: - note that the code in the pull request is not compatible with python 3, so you'll need to be on python 2 to run it. The --unlock switch is not a bootloader unlock, but it triggers the authentication handshake. Unfortunately, neither of the keys provided along with that worked with the G6. So, if there are no other changes to the laf other than a new key, figuring out the new key might be enough to make some additional progress.
Click to expand...
Click to collapse
Yeah, I ran into some of the same error message. Check out the thread for Issue #7. (Sorry, too "new" to post a link, but it's here: https://github.com/Lekensteyn/lglaf/issues/7 ) This provides some clues as to how to possibly go about getting the right keys. I will mess around with this tomorrow.
I also noticed something about the HELO command. The protocol documentation states that arg1 is the protocol version and states, "(resp must match req.)" without further details being provided. As the documentation states, lglaf is sending a value of 0x01000001 (\1\0\0\1), but the response does not match. The response that is being sent back by the device is (little-endian) 0x01000005 (\5\0\0\1). Yet, neither the lglaf utility nor the device balk, as noted by the ability to subsequently run '!INFO GPRO \x08\x0b\0\0' and/or '!CTRL RSET'
Also, the second argument is minimum version. The device is sending a response that indicates the minimum version is 0x10000001 (\1\0\0\10). It would appear that the device is saying its minimum version is higher than our version, which is 0x01000001.
And again, not sure if it means anything at all since it does seem to be working, but for science, at least:
host to 2.2.2 (request): HELO version 0x01000001
Code:
0000 48 45 4c 4f [COLOR="Blue"][B]01[/B] 00 00 01[/COLOR] 00 00 00 00 00 00 00 00 HELO............
0010 00 00 00 00 00 00 00 00 5c b1 00 00 b7 ba b3 b0 ........\.......
2.2.3 to host (response): HELO version 0x01000005 min version 0x10000001
Code:
0000 48 45 4c 4f [COLOR="DarkOrange"][B]05[/B] 00 00 01[/COLOR] [COLOR="Red"]01 00 00 [B]10[/B][/COLOR] 00 00 80 00 HELO............
0010 02 00 00 00 00 00 00 00 9e 3c 00 00 b7 ba b3 b0 .........<......
ariesgeek said:
Yeah, I ran into some of the same error message. Check out the thread for Issue #7. (Sorry, too "new" to post a link, but it's here: https://github.com/Lekensteyn/lglaf/issues/7 ) This provides some clues as to how to possibly go about getting the right keys. I will mess around with this tomorrow.
I also noticed something about the HELO command. The protocol documentation states that arg1 is the protocol version and states, "(resp must match req.)" without further details being provided. As the documentation states, lglaf is sending a value of 0x01000001 (\1\0\0\1), but the response does not match. The response that is being sent back by the device is (little-endian) 0x01000005 (\5\0\0\1). Yet, neither the lglaf utility nor the device balk, as noted by the ability to subsequently run '!INFO GPRO \x08\x0b\0\0' and/or '!CTRL RSET'
Also, the second argument is minimum version. The device is sending a response that indicates the minimum version is 0x10000001 (\1\0\0\10). It would appear that the device is saying its minimum version is higher than our version, which is 0x01000001.
And again, not sure if it means anything at all since it does seem to be working, but for science, at least:
host to 2.2.2 (request): HELO version 0x01000001
Code:
0000 48 45 4c 4f [COLOR="Blue"][B]01[/B] 00 00 01[/COLOR] 00 00 00 00 00 00 00 00 HELO............
0010 00 00 00 00 00 00 00 00 5c b1 00 00 b7 ba b3 b0 ........\.......
2.2.3 to host (response): HELO version 0x01000005 min version 0x10000001
Code:
0000 48 45 4c 4f [COLOR="DarkOrange"][B]05[/B] 00 00 01[/COLOR] [COLOR="Red"]01 00 00 [B]10[/B][/COLOR] 00 00 80 00 HELO............
0010 02 00 00 00 00 00 00 00 9e 3c 00 00 b7 ba b3 b0 .........<......
Click to expand...
Click to collapse
I have the KILO commands here... this is the work of @FluffyMittens and our findings by using a serial port sniffer while running a word generator that sent different commands through a serial connection.
KILOCENT (this is the handshake, cleaned up)
Code:
4B 49 4C 4F 43 45 4E 54 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 BE E3 7B 00 00 BE B4 BE B6 BE B3 BE B0
RAW HEXIDECIMAL
Code:
0x4B 0x49 0x4C 0x4F 0x43 0x45 0x4E 0x54 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 (insert byte) 0xE3 0x7B 0x00 0x00 (insert byte) 0xB4
(insert byte) 0xB6 (insert byte) 0xB3 (insert byte) 0xB0
KILOMETR (cleaned up)
Code:
4B 49 4C 4F 4D 45 54 52 00 00 00 00 02 00 00 00 00 00 00 00 10 00 00 00 00 00 00 00 BE B4 BE B6 BE B3 BE B0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
RAW HEXIDECIMAL
Code:
0x4B 0x49 0x4C 0x4F 0x4D 0x45 0x54 0x52 0x00 0x00 0x00 0x00 0x02 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x10 0x00 0x00 0x00 0x00 0x00 0x00 0x00 (insert byte) 0xB4 (insert byte) 0xB6 (insert byte) 0xB3 (insert byte) 0xB0
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
KILOGRAM (key)
Code:
dqoev)ohnsWu\\bk`oiicmZ_lpqe\\ealp
I don't exactly know how to use these. I know that these are supposed to be "secret" but since the LG scene has gone down recently here they are. Hopefully this helps, if anyone needs anything more I have some more commands as well.
So... I tried lglaf.py with that new kilogram key, but it didn't work. Then, I went back and took another stab at updating the version with --unlock to be compatible with python 3. I was a bit more successful this time, and it is able to complete the handshake and execute commands (like ls) without erroring out. It's using the old key - the new one you provided errors out. I don't know of a safe way to test writing data to the G6, so I will leave that to someone a bit more experienced.
I have attached my updated lglaf.py to this post. Extract it to your lglaf directory overwriting the existing lglaf.py. If you don't have lglaf yet, get it here first: https://github.com/Lekensteyn/lglaf
Requirements:
Install python3, then run: pip install pycryptodomex
Once that's done, you should be able to execute commands like this:
python lglaf.py --unlock --debug -c "!EXEC ls -l /system/\0"
Note that partitions.py is not working.
hendusoone said:
So... I tried lglaf.py with that new kilogram key, but it didn't work. Then, I went back and took another stab at updating the version with --unlock to be compatible with python 3. I was a bit more successful this time, and it is able to complete the handshake and execute commands (like ls) without erroring out. It's using the old key - the new one you provided errors out. I don't know of a safe way to test writing data to the G6, so I will leave that to someone a bit more experienced.
I have attached my updated lglaf.py to this post. Extract it to your lglaf directory overwriting the existing lglaf.py. If you don't have lglaf yet, get it here first: https://github.com/Lekensteyn/lglaf
Requirements:
Install python3, then run: pip install pycryptodomex
Once that's done, you should be able to execute commands like this:
python lglaf.py --unlock --debug -c "!EXEC ls -l /system/\0"
Note that partitions.py is not working.
Click to expand...
Click to collapse
Can it run any other commands besides "ls"? Try out "id" and "whoami"
Browsing through the kernel source, I got very curious about the flag "qcom,mdss-dsi-panel-inverted" being commented out in this file:
https://github.com/OnePlusOSS/andro...qcom/dsi-panel-samsung_s6e3fa5_1080p_cmd.dtsi
Could an experimented kernel builder create a kernel with this flag enabled, and check if the refresh direction of the panel changes, or the jello effect is diminished ?
I don't want to unlock my bootloader just yet
Hmmm.... Interesting...
maybe we will end up with a 180° inverted display.
Watching the thread
paratox said:
maybe we will end up with a 180° inverted display.
Click to expand...
Click to collapse
That is easy to fix in software though The HW is a *****
This flag is not in the documentation, it is not mentioned anywhere else in the kernel source, only oneplus devices have it in their source. For the prop to actually be readable it needs to be recognized in other parts of the kernel like this.
So, at best, the device will boot with no changes because the flag won't be recognized.
Flar2 mentioned that this change doesn't impact jelly affect...
ram4ufriends said:
Flar2 mentioned that this change doesn't impact jelly affect...
Click to expand...
Click to collapse
nah he just said "It doesn't seem to make any difference"
and the second response is "I'm not sure. I think if it was easily fixed, OnePlus would fix it in an update."
thats all
dukat0s said:
nah he just said "It doesn't seem to make any difference"
and the second response is "I'm not sure. I think if it was easily fixed, OnePlus would fix it in an update."
thats all
Click to expand...
Click to collapse
Which means that flag fix didn't work, isn't it?
ram4ufriends said:
Which means that flag fix didn't work, isn't it?
Click to expand...
Click to collapse
? what " flag fix" u talking about ? : >
ram4ufriends said:
Which means that flag fix didn't work, isn't it?
Click to expand...
Click to collapse
I know what you mean and no, it didn't work.
ZakooZ said:
This flag is not in the documentation, it is not mentioned anywhere else in the kernel source, only oneplus devices have it in their source. For the prop to actually be readable it needs to be recognized in other parts of the kernel like this.
So, at best, the device will boot with no changes because the flag won't be recognized.
Click to expand...
Click to collapse
Fair enough, I didn't check whenever this symbol is further referenced. Moreover, in MIPI DCS language, 'inverted' refers to 'color-inverted' display, not 'orientation-inverted'.
So I got curious, and took the DTSi file for the panel and the patch to enable the closely related S6E3FA0 panel on Exynos (never made it upstream), and decoded the `qcom,mdss-dsi-on-command` sequence, since it seems the best place to insert a command to rotate the display, if it exists; my decoding is below (references https://www.tonylabs.com/wp-content/uploads/MIPI_DCS_specification_v1.02.00.pdf)
Code:
.1 .2 .3 .4 .5 .6 .7 .8 .9 # decode of byte .8
#=============================================
05 01 00 00 14 00 02 11 00 # DCS exit_sleep_mode
15 01 00 00 00 00 02 35 00 # DCS set_tear_on
39 01 00 00 00 00 03 F0 5A 5A # MCS_KEY_LEV1
39 01 00 00 00 00 02 B0 04 # MCS_GLOBAL_PARAMETER
39 01 00 00 00 00 04 B4 06 0C 12 # ?? undocumented
39 01 00 00 00 00 03 F0 A5 A5 # MCS_KEY_LEV1
15 01 00 00 00 00 02 53 20 # ?? undocumented
15 01 00 00 00 00 02 55 00 # ?? DCS_WRITE_CABC
39 01 00 00 00 00 03 F0 5A 5A # MCS_KEY_LEV1
39 01 00 00 00 00 02 C3 01 # ?? undocumented
39 01 00 00 00 00 02 B0 18 # MCS_GLOBAL_PARAMETER
39 01 00 00 00 00 02 C3 00 # ?? undocumented
39 01 00 00 00 00 03 F0 A5 A5 # MCS_KEY_LEV1
05 01 00 00 00 00 02 29 00 # DCS set_display_on
In the MIPI DCS specification, one can control the Device Line Refresh Order:
1155 Bit B4 – Display Device Line Refresh Order
1156 This bit controls the display device’s horizontal line refresh order. The image shown on the display device
1157 is unaffected, regardless of the bit setting.
1158 ‘0’ = Display device is refreshed from the top line to the bottom line
1159 ‘1’ = Display device is refreshed from the bottom line to the top line
Click to expand...
Click to collapse
Things I would try:
Find Samsung references for the display controller so we can find the undocumented commands below
Use command DCS set_address_mode 36h to flip the display: insert before the last line:
Code:
15 01 00 00 00 00 02 36 10
or
Code:
15 01 00 00 00 00 02 36 00
and see what we get on display and if we can change the refresh direction. In worst case, we need to try all values from 00 for FF for the last byte in the command.
Anybody with a unlocked bootloader and time to recompile the kernel to test this ?
ddalex said:
Fair enough, I didn't check whenever this symbol is further referenced. Moreover, in MIPI DCS language, 'inverted' refers to 'color-inverted' display, not 'orientation-inverted'.
So I got curious, and took the DTSi file for the panel and the patch to enable the closely related S6E3FA0 panel on Exynos (never made it upstream), and decoded the `qcom,mdss-dsi-on-command` sequence, since it seems the best place to insert a command to rotate the display, if it exists; my decoding is below (references https://www.tonylabs.com/wp-content/uploads/MIPI_DCS_specification_v1.02.00.pdf)
In the MIPI DCS specification, one can control the Device Line Refresh Order:
1155 Bit B4 – Display Device Line Refresh Order
1156 This bit controls the display device’s horizontal line refresh order. The image shown on the display device
1157 is unaffected, regardless of the bit setting.
1158 ‘0’ = Display device is refreshed from the top line to the bottom line
1159 ‘1’ = Display device is refreshed from the bottom line to the top line
Things I would try:
Find Samsung references for the display controller so we can find the undocumented commands below
Use command DCS set_address_mode 36h to flip the display: insert before the last line:
Things I would try:
Find Samsung references for the display controller so we can find the undocumented commands below
Use command DCS set_address_mode 36h to flip the display: insert before the last line:
15 01 00 00 00 00 02 36 10 or
and see what we get on display and if we can change the refresh direction. In worst case, we need to try all values from 00 for FF for the last byte in the command.
Anybody with a unlocked bootloader and time to recompile the kernel to test this ?
Click to expand...
Click to collapse
Interesting. I could only recommend you to try to get in touch with @flar2 - Dev of the EX kernel. He might be eventually able to do some experiments (as he already did with "inverted" command).
ddalex said:
Fair enough, I didn't check whenever this symbol is further referenced. Moreover, in MIPI DCS language, 'inverted' refers to 'color-inverted' display, not 'orientation-inverted'.
So I got curious, and took the DTSi file for the panel and the patch to enable the closely related S6E3FA0 panel on Exynos (never made it upstream), and decoded the `qcom,mdss-dsi-on-command` sequence, since it seems the best place to insert a command to rotate the display, if it exists; my decoding is below (references https://www.tonylabs.com/wp-content/uploads/MIPI_DCS_specification_v1.02.00.pdf)
Code:
.1 .2 .3 .4 .5 .6 .7 .8 .9 # decode of byte .8
#=============================================
05 01 00 00 14 00 02 11 00 # DCS exit_sleep_mode
15 01 00 00 00 00 02 35 00 # DCS set_tear_on
39 01 00 00 00 00 03 F0 5A 5A # MCS_KEY_LEV1
39 01 00 00 00 00 02 B0 04 # MCS_GLOBAL_PARAMETER
39 01 00 00 00 00 04 B4 06 0C 12 # ?? undocumented
39 01 00 00 00 00 03 F0 A5 A5 # MCS_KEY_LEV1
15 01 00 00 00 00 02 53 20 # ?? undocumented
15 01 00 00 00 00 02 55 00 # ?? DCS_WRITE_CABC
39 01 00 00 00 00 03 F0 5A 5A # MCS_KEY_LEV1
39 01 00 00 00 00 02 C3 01 # ?? undocumented
39 01 00 00 00 00 02 B0 18 # MCS_GLOBAL_PARAMETER
39 01 00 00 00 00 02 C3 00 # ?? undocumented
39 01 00 00 00 00 03 F0 A5 A5 # MCS_KEY_LEV1
05 01 00 00 00 00 02 29 00 # DCS set_display_on
In the MIPI DCS specification, one can control the Device Line Refresh Order:
Things I would try:
Find Samsung references for the display controller so we can find the undocumented commands below
Use command DCS set_address_mode 36h to flip the display: insert before the last line:
Code:
15 01 00 00 00 00 02 36 10
or
Code:
15 01 00 00 00 00 02 36 00
and see what we get on display and if we can change the refresh direction. In worst case, we need to try all values from 00 for FF for the last byte in the command.
Anybody with a unlocked bootloader and time to recompile the kernel to test this ?
Click to expand...
Click to collapse
This looks correct. I wondered about this but couldn't find a DCS spec sheet.
Could you specify what 15 01 does? Put the device into command mode or something?
Looking at the command documentation these bytes '#9' could be useful:
0x10 - scan from bottom to top (top to bottom in reality)
0x04 - latch from right to left (left to right in reality) (reverses tilt of the active scan line)
0x14 - combine previous 2
There are 2 problems that can come out of this:
1. The panel itself just doesn't support setting these bits and will just ignore them
2. "qcom,mdss-dsi-panel-orientation" might actually call that same command after qcom,mdss-dsi-on-command and override the settings we added in. This would show the same symptoms as problem 1), nothing would change in the display. I've been looking at the dsi panel init source code but it's a bit of a rabbit hole so I don't know if this is the case. Luckily the code is full of debug prints, so it is relatively easy to enable them and see what is actually happening in the dmesg.
who's gonna try this then ?
ZakooZ said:
This looks correct. I wondered about this but couldn't find a DCS spec sheet.
Could you specify what 15 01 does? Put the device into command mode or something?
Click to expand...
Click to collapse
Each line in there is a MIPI DCS packet - first byte is the packet type, with the defines below
Code:
/* dcs read/write */
#define DTYPE_DCS_WRITE 0x05 /* short write, 0 parameter */
#define DTYPE_DCS_WRITE1 0x15 /* short write, 1 parameter */
#define DTYPE_DCS_READ 0x06 /* read */
#define DTYPE_DCS_LWRITE 0x39 /* long write */
The complete header definition is:
Code:
struct dsi_ctrl_hdr {
char dtype; /* data type */
char last; /* last in chain */
char vc; /* virtual chan */
char ack; /* ask ACK from peripheral */
char wait; /* ms */
short dlen; /* 16 bits */
} __packed;
After the header, the payload follows directly.
ZakooZ said:
Looking at the command documentation these bytes '#9' could be useful:
0x10 - scan from bottom to top (top to bottom in reality)
0x04 - latch from right to left (left to right in reality) (reverses tilt of the active scan line)
0x14 - combine previous 2
Click to expand...
Click to collapse
Yep, we need to test these - the problem is that we don;t know if there is another piece of code that resets this flag after the initial init, you correctly touch on this below.
ZakooZ said:
There are 2 problems that can come out of this:
1. The panel itself just doesn't support setting these bits and will just ignore them
2. "qcom,mdss-dsi-panel-orientation" might actually call that same command after qcom,mdss-dsi-on-command and override the settings we added in. This would show the same symptoms as problem 1), nothing would change in the display. I've been looking at the dsi panel init source code but it's a bit of a rabbit hole so I don't know if this is the case. Luckily the code is full of debug prints, so it is relatively easy to enable them and see what is actually happening in the dmesg.
Click to expand...
Click to collapse
Or, possible but not probable outcome no. 3: the HUT (Hardware Under Test) is damaged by this testing
:victory:
That flag is shipped in this commit: https://github.com/MoKee/android_ke...mmit/7ca61f58d8b59a4ae716e08405df8368a45407fb
As I am a Chinese, this commit message indicates the screen is upside-down. This flag is not as others say, only see in Oneplus devices. It is a flag introduced by CAF, to support
upside-down screens: https://github.com/MoKee/android_ke...mmit/63203b502ef862f756535e080c4261031eb4110f. Further research shows that it actually does is to make the display oriented: https://github.com/MoKee/android_ke...f9e1a022ef5/include/uapi/linux/msm_mdp.h#L254.
Oneplus seems to take entire CAF solution in kernel. But actually it is something besides than kernel. But I doubt there is something in closed-source vendors as well (third-party roms still have this effect).
aviraxp said:
That flag is shipped in this commit: https://github.com/MoKee/android_ke...mmit/7ca61f58d8b59a4ae716e08405df8368a45407fb
As I am a Chinese, this commit message indicates the screen is upside-down. This flag is not as others say, only see in Oneplus devices. It is a flag introduced by CAF, to support
upside-down screens: https://github.com/MoKee/android_ke...mmit/63203b502ef862f756535e080c4261031eb4110f. Further research shows that it actually does is to make the display oriented: https://github.com/MoKee/android_ke...f9e1a022ef5/include/uapi/linux/msm_mdp.h#L254.
Oneplus seems to take entire CAF solution in kernel. But actually it is something besides than kernel. But I doubt there is something in closed-source vendors as well (third-party roms still have this effect).
Click to expand...
Click to collapse
Yes, but we don't need to reverse the screen, we need to set the inverse refresh.
Inviato dal mio ONEPLUS A5000 utilizzando Tapatalk
robertogl said:
Yes, but we don't need to reverse the screen, we need to set the inverse refresh.
Click to expand...
Click to collapse
I referenced above the Display Line Refresh Order option on the MIPI DCS standard set_address_mode option, that maybe could inverse the refresh. We need somebody to build the kernel with the command added in the DTSi file, and test it. Maybe @Sultanxda ?
Someone really should try this :0
Sent from my SM-A510M using Tapatalk