Related
Presently we're running a little short on kernel exploits, with the following being the only one that looks remotely plausible:
http://xorl.wordpress.com/2010/01/14/cve-2009-4141-linux-kernel-fasync-locked-file-use-after-free/
Big hold-up? For all that we have a trigger, we don't have an exploit. I believe it's up to us at this point to make that happen.
If I'm reading it right, it looks like the bug initially rears its head right here:
Code:
void __kill_fasync(struct fasync_struct *fa, int sig, int band)
{
while (fa) {
struct fown_struct * fown;
if (fa->magic != FASYNC_MAGIC) {
printk(KERN_ERR "kill_fasync: bad magic number in "
"fasync_struct!\n");
return;
}
[B]fown = &fa->fa_file->f_owner;[/B]
/* Don't send SIGURG to processes which have not set a
queued signum: SIGURG has its own default signalling
mechanism. */
if (!(sig == SIGURG && fown->signum == 0))
send_sigio(fown, fa->fa_fd, band);
fa = fa->fa_next;
}
}
... as fa_file now points to invalid memory (having been free'd earlier). The f_owner member gets shot out to send_sigio, which look like this:
Code:
void send_sigio(struct fown_struct *fown, int fd, int band)
{
struct task_struct *p;
enum pid_type type;
struct pid *pid;
int group = 1;
read_lock(&fown->lock);
type = fown->pid_type;
if (type == PIDTYPE_MAX) {
group = 0;
type = PIDTYPE_PID;
}
[B]pid = fown->pid;[/B]
if (!pid)
goto out_unlock_fown;
read_lock(&tasklist_lock);
do_each_pid_task(pid, type, p) {
send_sigio_to_task(p, fown, fd, band, group);
} while_each_pid_task(pid, type, p);
read_unlock(&tasklist_lock);
out_unlock_fown:
read_unlock(&fown->lock);
}
... in which we see the f_owner member being dereferenced. Also it gets pushed through several other functions which may be exploitable.
There are several questions to be answered before we can start attacking this:
Can we resolve the address of the fa_file data structure so we can overwrite the f_owner value?
Can we do anything with it once we've done that? (Presumably we can set it to zero to cause a null-pointer dereference, but we're mmap_min_addr = 32768 on the most recent versions, so unless we can flag the mmap region to grow down and apply memory pressure to reach page 0 this will do us no good.)
Failing the plan above: are any of the functions that f_owner gets pushed into vulnerable? I evaluated this over the weekend, but without the help of a trained kernel dev I'm not going to get very far.
While I studied a lot of this in uni, I'll admit I'm green when it comes to actually writing these exploits. I'm hoping that this will get the creative juices flowing, and perhaps provide a more comprehensive resource in case any hard-core kernel hackers want to take a look at what we're doing or give us pointers (harhar) in the right direction.
Thanks, guys. Great work up to this point.
In the original POC if you change /bin/true to /system/bin/sh you can get a new shell to open just not as root. So I'm guessing that their needs to be more added to the POC to make it a full exploit.
Right, the fork()'s in the PoC exist only to cause the file descriptor's fasync_struct to be erroneously killed, not start a root session. The root session would need to be started (presumably) by the kernel doing something to our maliciously crafted fown_struct.
The tough part is figuring out exactly where and what that fown_struct needs to be.
Well I definetly agree with you that this seems to be our best best bet I am some what of a newbie when it comes to linux allthough i am learning as i go. Do you know of any good sites to read up on kernel hacking?
Sorry Guys just got the word that this one is dead for us.....
Here is the explantion i got.
some_person said:
Nope, the bug didn't exist in 2.6.27. That's why they say >= 2.6.28 are vulnerable.
As far as how the bug works, there are 2 other issues. 1) our kernel probably wasn't compiled with AT_RANDOM 2) we don't have an elf executable.
The exploit you found does not give us root access, it crashes the system. Basically, you open the "random number generator" file, lock it, and close it... but the lock release when you close it. Then you have to call an elf executable because that generates a random number (running an elf executable) provided the kernel was compiled AT_RANDOM. you continue to call that executable (and generating random numbers) until the the lock is released on the "random number generator" file... then it's your program's turn... the kernel tries to send your program notification that the file is available, but your program has moved on. BLAM the kernel stops (or "oops").
Click to expand...
Click to collapse
Sorry to dredge up an old thread:
This exploit *will* work. According to Zanfur, the hole is in our kernel. We need to use it without AT_RANDOM (which I dont know how to do).
http://sourceware.org/ml/libc-alpha/2008-10/msg00016.html
I am pretty sure we do have elf executables, here is proof:
% file m6
m6: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), not stripped
If our kernel is susceptible to this bug then it should work, as long as there is a way to do it without at random.
Though I do not in any way represent my self as a hacker or developer I was wondering if I could throw in my 2 cents. I notice that this bug/exploit won't work because it requires AT RANDOM. I was wondering if it s possible to write code that does what the function does and insert it in. Is root required to do this (i.e. insert code into the kernel that wasn't there before) or is this a matter of know-how? Just some brainstorming I thought that I would throw in.
jballz0682 said:
Though I do not in any way represent my self as a hacker or developer I was wondering if I could throw in my 2 cents. I notice that this bug/exploit won't work because it requires AT RANDOM. I was wondering if it s possible to write code that does what the function does and insert it in. Is root required to do this (i.e. insert code into the kernel that wasn't there before) or is this a matter of know-how? Just some brainstorming I thought that I would throw in.
Click to expand...
Click to collapse
This won't get us root. Even zanfur said it. Moving on....
Framework43 said:
This won't get us root. Even zanfur said it. Moving on....
Click to expand...
Click to collapse
To clarify, even if we get AT_RANDOM functionality working, we can't use this to exploit our kernel. All we can do with this is get data from a file that was recently closed. The point of this exploit is to send a signal to a process, but there are no processes we could send a signal to that would give us root.
Our kernel seems practically invulnerable, it appears that almost all exploits are patched
Ok, in this thread I will describe one problem that I have faced with my Iconia and that was also reported by one other user on a forum.
Basically, Iconia uses Atmel mxt1386 touchscreen controller. The same controller is used in Asus EEE Transformer and Motorola Xoom and even Samsung Galaxy Tab 10.1. So far, there are a lot of reports of EEE Transformer's and Xoom's touchscreens suddenly stopping working and starting working after a full battery discharge.
One day after a reboot my Iconia stopped booting - it keeped hanging on the Acer logo and when I tried entering recovery it was hanging at "booting recovery kernel image". However, that only happened with Acer kernels. With my own kernel, ported from EEE Transformer, the tablet could boot. I have recompiled the acer kernel with framebuffer console and found out it got stuck at the touchscreen interrupt handler while EEE's driver just printed an error and stopped working.. Basically, the response I got from from the touchscreen was [1, 0x80, 0, 0, 0, 0, 0, 0]. And it was not detected with i2cdetect
At first, I thought my touchscreen cable was damaged. I have disassembled the tablet and tried twisting the cable to see if it gives any result. My result was that if I disconnect and reconnect the cable, an interrupt comes. Btw, the cable has sharp 'teeth' and you can crimp it pretty much like ethernet.
Ok, so then I added some printks to the driver. Turns out, when some data coming from the touchscreen was incorrect, the driver hanged (deadlocked) because the semaphore was pushed down two times and never upped. So, I have commented out semaphores and bingo - it continued booting. Although there were a lot of warn_slowpath errors and CRC error, it reported correct coordinates. I flashed Acer's kernel after it and it booted fine. Looks like a proper init by Acer driver reset the controller.
The archive in the link contains tegra i2c driver from the chromium tree (in case it finds i2c errors like nak, it retries the transmission several times) and the touchscreen driver. You need to comment out "#define USE_SEMA" to disable semaphores and build the kernel with it in case you encounter the problem..
http://www.mediafire.com/?jt6b19nr7rsy70s
I do not have another 'brick' to test if my solution works in all cases but I'm just leaving the stuff here in case anyone faces the trouble. To flash when your tablet is not booting you'll probably some help from sc2k..
What's the moral of the story? The moral is that as touchscreen is not used in recovery, it may be a good idea to add the 'hacked and buggy' driver to the recovery kernel to allow to recover the device by just booting recovery in case anyone faces the problem.. Of course it's better to fix the driver properly or even use the driver from mainline linux and patch it.
EDIT 29-oct-2011:
here is a link to the cwm recovery image with the 'hacked' driver. Boots just fine.
http://www.mediafire.com/?39jk1j15wkpr57o
So just to clarify this is a software/recovery problem not a hardware problem?
This is a combined problem. It is a hardware problem as the touchscreen stops getting recognized by i2cdetect, probably due to firmware bugs.. It is a software problem because the driver behaves incorrectly when the hardware fails.
Ok, I will post the reply from sc2k who investigated the issue a bit. Let's keep it here for reference. I think it will be nice to patch the mainline driver (from chromium or mainline linux) and use it instead of acer's driver but I won't probably do it unless I hit the issue again or make some progress with my chromium kernel
sc2k said:
Ok.. I finally understand the issue:
Your tochscreen always responded with [1, 0x80, 0, 0, 0, 0, 0, 0]
buffer[1].bit7 seems to be some kind of "message incomplete" bit. As this is always transmitted, the worker thread never releases the semaphore which causes the ATMEL_Initial to stop at ATMEL_SyncWithThreadToReadMsg.
After you disabled the semaphore, ATMEL_Initial continues. ConfigError is probably 0, so next function to be called will be ATMEL_CheckConfig.
This function first calls ATMEL_SendCMDgetCRC. As semaphores are disabled, this will probably not be able to receive the checksum (due to timing) so that ConfigChecksumError=1.
If ConfigChecksumError==1, ATMEL_CheckConfig will call ATMEL_WriteConfig and ATMEL_Backup that will probably be successful and thus fixes the configuration issue. Even if it does not complete succesfully, the whole recovery process is repeated until all conditions are satisfied.
Conclusion:
- Somehow the configuration in your touchscreen controller got messed up.
- Removing the semaphores triggered ATMEL_WriteConfig + ATMEL_Backup which probably fixed the issue.
I believe, a good fix would be to add a check "if (counts > 20) { up(&mxt->sema); goto fail; }" or similar to mxt_worker for irq_type == ATMEL_ReadResponseMsg_Noaddress. This would prevent these endless interrupt loop and allow the driver to fix the configuration.
Really nice bug that you have found in this driver
Click to expand...
Click to collapse
Link to cwm recovery image invalid
Hi sp3dev,
sorry to ask but could you pls reupload your cwm recovery image? Mediafire says the file is not available any more.
I am not an expert in ROMs and I know nothing about cooking them or kernels. But I think I am having a problem similar to that described in your thread: after a sw update the touchscreen became unsensitive. Shutdown, reset, factory reset do not solve the problem. When I flash a new ROM to try and "reset" the screen controller, I get stuck at the "ACER" logo after flashing with CWM and rebooting the system. If I shut down and restart again, the machine starts but the touchscreen is still unresponsive. Luckily enough, I can use a USB mouse to interact with the device.
I am currently running HC 3.1 (stock), rooted. I took a full nandroid backup with CWM. Do you think it is safe to flash your recovery with the modified touchscreen driver (that is, if you are kind enough to re-upload it for me...)?
Thanks a lot for any advice you can provide.
Best, Andrea
I see that thor2002ro has seen this thread, but will we see the driver implemented in the next CWM release?
If it can help people recover from a known brick and if the stack does not introduce problems then I hope that we see something, at least a recovery instruction for the touchscreen added to CWM or the whole stack. aferall this could be something that ends up happening to alot of us :S
I had this problem with my Galaxy Tab and tried the fixes mentioned but it just didn't work for me. I have, however, figured out what's really going wrong.
I always had this failure showing up in dmesg:
[ 1.707677] tegra-i2c tegra-i2c.1: I2c error status 0x00000008
[ 1.707913] tegra-i2c tegra-i2c.1: no acknowledge from address 0x4c
[ 1.708080] tegra-i2c tegra-i2c.1: Packet status 0x00010009
[ 1.709363] Warning: To wake up touch-ic in deep sleep, retry i2c communication!
[ 1.748037] tegra-i2c tegra-i2c.1: I2c error status 0x00000008
[ 1.748355] tegra-i2c tegra-i2c.1: no acknowledge from address 0x4c
[ 1.748523] tegra-i2c tegra-i2c.1: Packet status 0x00010009
[ 1.749788] sec_touch 1-004c: Failure accessing maXTouch device
So, it can't read from the touchscreen controller at address 0x4c. The fix mentioned in this thread was to re-write the configuration, with the assumption that the device was somehow wedged. That doesn't work either, since you can't write to 0x4c - same lack of acknowledgement.
I tried adding a reset. No change. Disconnected the battery overnight. Also no change.
Then, I realized what's going on. The MXT1386 has a "Firmware Update" mode. When you put it into update mode, the device address changes from 0x4c to 0x26! Once it gets into that mode, it doesn't respond to the original address. Since I don't have the docs for the device, I just called the driver function that updates the firmware. Once that process is complete and the chip reset, it reverts to its original address. At that point (after a final reboot), all is well.
I have a replacement kernel that you can install and boot which re-enables the touchpad. I'd suggest making a nandroid backup first, installing my kernel, then restoring the nandroid once it's fixed.
http://www.rickmurphy.net/mxt1386_fixer.zip. While this is a p4wifi (Gtab 10.1 Wifi-only) it'll probably fix the problem on a 3G tablet as well as long as you restore the correct kernel once it's done..
Whew. It's good to have the toy back working.
k1mu said:
I had this problem with my Galaxy Tab and tried the fixes mentioned but it just didn't work for me. I have, however, figured out what's really going wrong.
I always had this failure showing up in dmesg:
[ 1.707677] tegra-i2c tegra-i2c.1: I2c error status 0x00000008
[ 1.707913] tegra-i2c tegra-i2c.1: no acknowledge from address 0x4c
[ 1.708080] tegra-i2c tegra-i2c.1: Packet status 0x00010009
[ 1.709363] Warning: To wake up touch-ic in deep sleep, retry i2c communication!
[ 1.748037] tegra-i2c tegra-i2c.1: I2c error status 0x00000008
[ 1.748355] tegra-i2c tegra-i2c.1: no acknowledge from address 0x4c
[ 1.748523] tegra-i2c tegra-i2c.1: Packet status 0x00010009
[ 1.749788] sec_touch 1-004c: Failure accessing maXTouch device
So, it can't read from the touchscreen controller at address 0x4c. The fix mentioned in this thread was to re-write the configuration, with the assumption that the device was somehow wedged. That doesn't work either, since you can't write to 0x4c - same lack of acknowledgement.
I tried adding a reset. No change. Disconnected the battery overnight. Also no change.
Then, I realized what's going on. The MXT1386 has a "Firmware Update" mode. When you put it into update mode, the device address changes from 0x4c to 0x26! Once it gets into that mode, it doesn't respond to the original address. Since I don't have the docs for the device, I just called the driver function that updates the firmware. Once that process is complete and the chip reset, it reverts to its original address. At that point (after a final reboot), all is well.
I have a replacement kernel that you can install and boot which re-enables the touchpad. I'd suggest making a nandroid backup first, installing my kernel, then restoring the nandroid once it's fixed.
http://www.rickmurphy.net/mxt1386_fixer.zip. While this is a p4wifi (Gtab 10.1 Wifi-only) it'll probably fix the problem on a 3G tablet as well as long as you restore the correct kernel once it's done..
Whew. It's good to have the toy back working.
Click to expand...
Click to collapse
Though I don't have this problem, and hope never to, it is a scary scenario. Thanks for investing your time to come up with a fix for ppl who have this problem.
Sent from my GT-P7510 using xda app-developers app
OTAw said:
Though I don't have this problem, and hope never to, it is a scary scenario. Thanks for investing your time to come up with a fix for ppl who have this problem.
Click to expand...
Click to collapse
Thanks. I've also sent a patch to the person who I thing maintains the driver. If they'll accept the fix, it'll automatically correct this problem regardless of the type of device being used. That'd be a good thing.
I have the common problem with my Acer Iconia A500.
The tablet's touchscreen suddenly stopping working. And didn't start working after reset, shutdown, deattaching the battery, or any firmware upgrades/downgrades.
Custom bootloaders and restores also didn't help.
It is starting working only when I shutdown the tablet and don't use it for a while.
When I turn on the tablet after 2-3 hours, the touchscreen works. But after 10-15 minutes of usage(or even idle), touchscreen stop working again.
I tried many ways to solve this problem, but nothing works for me.
When I tryed to figure out this issue, I found only a few topics in the internet, but all of them was leading to this thread.
So, tell me please, is there any workaround to this touchscreen problem?
I suggest, this is the hardware problem. But if there is any software fix, it would be good.
DIZAZTER said:
I have the common problem with my Acer Iconia A500.
The tablet's touchscreen suddenly stopping working. And didn't start working after reset, shutdown, deattaching the battery, or any firmware upgrades/downgrades.
Custom bootloaders and restores also didn't help.
It is starting working only when I shutdown the tablet and don't use it for a while.
When I turn on the tablet after 2-3 hours, the touchscreen works. But after 10-15 minutes of usage(or even idle), touchscreen stop working again.
I tried many ways to solve this problem, but nothing works for me.
When I tryed to figure out this issue, I found only a few topics in the internet, but all of them was leading to this thread.
So, tell me please, is there any workaround to this touchscreen problem?
I suggest, this is the hardware problem. But if there is any software fix, it would be good.
Click to expand...
Click to collapse
Well, if you have done a rollback using TD's V4 rollback tool, and the problem still persists, then it's likely a hardware issue.
If it were software, the TS would either work, or it wouldn't. The fact there's a time limit involved, indicates some component heating up and causing the issue.
I would suggest, if you are no longer under warranty, to pop off the cover, and start checking connections. More than likely a connection is failing. (cold expands, heat contracts). Might explain why it works when it's cool. (this is why we put old HDD's in the freezer, sounds strange, but can't deny physics)
You can google for 500 breakdown videos. Plenty of them out there.
As a test in the temp theory, just play with the tab till it fails. Toss it in the fridge for 15 minutes or so. If it works, then it's mechanical.
I'd bet on the connectors. Then check the board with a magnifying glass.
MD
Moscow Desire said:
Well, if you have done a rollback using TD's V4 rollback tool, and the problem still persists, then it's likely a hardware issue.
If it were software, the TS would either work, or it wouldn't. The fact there's a time limit involved, indicates some component heating up and causing the issue.
I would suggest, if you are no longer under warranty, to pop off the cover, and start checking connections. More than likely a connection is failing. (cold expands, heat contracts). Might explain why it works when it's cool. (this is why we put old HDD's in the freezer, sounds strange, but can't deny physics)
You can google for 500 breakdown videos. Plenty of them out there.
As a test in the temp theory, just play with the tab till it fails. Toss it in the fridge for 15 minutes or so. If it works, then it's mechanical.
I'd bet on the connectors. Then check the board with a magnifying glass.
MD
Click to expand...
Click to collapse
You're right about the temp.
Actually, I put the tablet in the fridge even before I saw you reply.
After that procedure, touchscreen works fine for a while. And after freezing it works much longer period. I guess, it works just before getting warm.
I wanted to mention about the temperature dependence, but you did it first.
My warranty is expired. So I'm already has disassembled and taken the tablet apart. But I saw nothing noticeably wrong there.
I guess, there is some kind of connection failure, but it's microscopically small. Or it's situated inside of a board or a chip.
Anyway, thanks a lot.
At least I figured out that this is only hardware issue and there is no way to fix it with software patch.
Moscow Desire said:
If it were software, the TS would either work, or it wouldn't. The fact there's a time limit involved, indicates some component heating up and causing the issue.
..
I'd bet on the connectors. Then check the board with a magnifying glass.
Click to expand...
Click to collapse
I agree. Your problem has nothing in common with the issue that was causing my touchscreen to not work. That was a software problem with a reliable software fix.
I have seen a Galaxy Tab with a flaky touchscreen, but when I took it apart to look at what was wrong I found that the connector for the touchscreen had been ripped completely off the motherboard. The induhvidual responsible tried to fix it by taping the touchscreen connector to the motherboard! Needless to say, that wasn't a very reliable fix. :laugh:
I've pulled the kernel that had my patch off of my web site because it's only usable on the P7510 (WiFi) device and caused a 3G tablet to hang.
Could someone please explain what went wrong?
I use a acer a700 and get everytime i make display on such errors:
mXT1386E: mxt_late_resume
<4>[ 1641.027524] tegra-i2c tegra-i2c.1: I2c error status 0x00000008
<4>[ 1641.027938] tegra-i2c tegra-i2c.1: no acknowledge from address 0x4c
<4>[ 1641.028178] tegra-i2c tegra-i2c.1: Packet status 0x00010009
<4>[ 1641.045244] tegra-i2c tegra-i2c.1: I2c error status 0x00000008
<4>[ 1641.045398] tegra-i2c tegra-i2c.1: no acknowledge from address 0x4c
<4>[ 1641.045670] tegra-i2c tegra-i2c.1: Packet status 0x00010009
<4>[ 1641.069140] mXT1386E i2c write 3 time
<4>[ 1641.069539] mXT1386E: ATMEL_Resume OK!
Any idea?
Why?
On boot, dmesg write this:
mXT1386E: reenter_count: 0
mXT1386E: Config has errors
mXT1386E: The status is 0x90
mXT1386E: reenter_count: 1
mXT1386E: Config status is ready
How can we fix it?
Please devs!Help us!!!
djsven said:
Could someone please explain what went wrong?
I use a acer a700 and get everytime i make display on such errors:
mXT1386E: mxt_late_resume
<4>[ 1641.027524] tegra-i2c tegra-i2c.1: I2c error status 0x00000008
<4>[ 1641.027938] tegra-i2c tegra-i2c.1: no acknowledge from address 0x4c
<4>[ 1641.028178] tegra-i2c tegra-i2c.1: Packet status 0x00010009
<4>[ 1641.045244] tegra-i2c tegra-i2c.1: I2c error status 0x00000008
<4>[ 1641.045398] tegra-i2c tegra-i2c.1: no acknowledge from address 0x4c
<4>[ 1641.045670] tegra-i2c tegra-i2c.1: Packet status 0x00010009
<4>[ 1641.069140] mXT1386E i2c write 3 time
<4>[ 1641.069539] mXT1386E: ATMEL_Resume OK!
Any idea?
Why?
On boot, dmesg write this:
mXT1386E: reenter_count: 0
mXT1386E: Config has errors
mXT1386E: The status is 0x90
mXT1386E: reenter_count: 1
mXT1386E: Config status is ready
How can we fix it?
Please devs!Help us!!!
Click to expand...
Click to collapse
That "no acknowledge from address 0x4c" means that your touchscreen chip is not responding. It's possible that it's just dead, or possible that it's stuck in firmware update mode (in update mode, the address changes to 0x26). If you can point me to kernel source for your A700, I can modify it try to recover the touchscreen. (Of course, I'm assuming that it's just dead and that the touchscreen never works. If it works some of the time but fails later, it's probably just a hardware problem.)
k1mu said:
That "no acknowledge from address 0x4c" means that your touchscreen chip is not responding. It's possible that it's just dead, or possible that it's stuck in firmware update mode (in update mode, the address changes to 0x26). If you can point me to kernel source for your A700, I can modify it try to recover the touchscreen. (Of course, I'm assuming that it's just dead and that the touchscreen never works. If it works some of the time but fails later, it's probably just a hardware problem.)
Click to expand...
Click to collapse
Hi @k1mu got a question regarding this discussion. Would there also be benefits from this fix if it's only a unresponsiveness in runtime? I assume also djsven has it within runtime and the ts recovers itself... what I get from this thread is that it's regarded to the tab being unrecoverably stuck on firmware update mode? If not and it could fix hangs for some seconds in runtime it would be awesome if you could make a patch for this driver or just point me to a diff...
Thanks in advance
Elibl said:
Hi @k1mu got a question regarding this discussion. Would there also be benefits from this fix if it's only a unresponsiveness in runtime? I assume also djsven has it within runtime and the ts recovers itself... what I get from this thread is that it's regarded to the tab being unrecoverably stuck on firmware update mode? If not and it could fix hangs for some seconds in runtime it would be awesome if you could make a patch for this driver or just point me to a diff...
Thanks in advance
Click to expand...
Click to collapse
If it's just slow to respond, then the touchscreen is basically working and isn't going to be helped by this fix.
That (slow, jerky response to screen input) is caused by CPU hogging processes keeping the tablet too busy, or too many applications running at once, keeping the OS busy shuffling memory around (that's called thrashing).
k1mu said:
If it's just slow to respond, then the touchscreen is basically working and isn't going to be helped by this fix.
That (slow, jerky response to screen input) is caused by CPU hogging processes keeping the tablet too busy, or too many applications running at once, keeping the OS busy shuffling memory around (that's called thrashing).
Click to expand...
Click to collapse
Sure that's only system hangs... I ment does your fix help for input lags/death regarding 0x4c address/firmware update mode... If you show me the diff I could just test it... Would be highly appreciated
Elibl said:
Sure that's only system hangs... I ment does your fix help for input lags/death regarding 0x4c address/firmware update mode... If you show me the diff I could just test it... Would be highly appreciated
Click to expand...
Click to collapse
No, the system doesn't hang, it works just fine if you plug in a keyboard.
Here's the diff:
Code:
diff -c drivers/input/touchscreen/orig/atmel_mxt1386.c drivers/input/touchscreen/atmel_mxt1386.c
*** drivers/input/touchscreen/orig/atmel_mxt1386.c 2012-10-10 08:11:10.543325982 -0400
--- drivers/input/touchscreen/atmel_mxt1386.c 2012-10-10 08:35:30.545044039 -0400
***************
*** 22,27 ****
--- 22,29 ----
* Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
*/
+ #define FIX_CHIP_HANG
+
#define DEBUG_INFO 1
#define DEBUG_VERBOSE 2
#define DEBUG_MESSAGES 5
***************
*** 2539,2544 ****
--- 2541,2550 ----
/* Initialization of driver */
/******************************************************************************/
+ #ifdef FIX_CHIP_HANG
+ extern int mxt_do_firmware_load(struct mxt_data *mxt, const char *fn);
+ #endif
+
static int __devinit mxt_identify(struct i2c_client *client,
struct mxt_data *mxt)
{
***************
*** 2559,2564 ****
--- 2565,2585 ----
msleep(30);
goto retry_i2c;
}
+ #ifdef FIX_CHIP_HANG
+ /* If we tried twice and no response, maybe it's in firmware
+ * load mode. Try to upload firmware.
+ */
+ if (mxt->read_fail_counter == 2) {
+ printk(KERN_DEBUG "Trying firmware reload.");
+ mxt->last_read_addr = -1;
+
+ mxt_do_firmware_load(mxt, MXT1386_FIRMWARE);
+
+ reset_chip(mxt, RESET_TO_NORMAL);
+ msleep(300);
+ goto retry_i2c;
+ }
+ #endif
dev_err(&client->dev, "Failure accessing maXTouch device\n");
return -EIO;
}
diff -c drivers/input/touchscreen/orig/atmel_mxt1386_cfg.c drivers/input/touchscreen/atmel_mxt1386_cfg.c
*** drivers/input/touchscreen/orig/atmel_mxt1386_cfg.c 2012-10-10 08:12:43.773952501 -0400
--- drivers/input/touchscreen/atmel_mxt1386_cfg.c 2012-10-10 08:36:55.704576439 -0400
***************
*** 408,417 ****
return 0;
}
- int mxt_load_firmware(struct device *dev, const char *fn)
- {
- struct mxt_data *mxt = dev_get_drvdata(dev);
unsigned int frame_size;
unsigned int pos = 0;
unsigned int retry;
--- 408,416 ----
return 0;
}
+ int mxt_do_firmware_load(struct mxt_data *mxt, const char *fn)
+ {
unsigned int frame_size;
unsigned int pos = 0;
unsigned int retry;
***************
*** 518,520 ****
--- 517,526 ----
return ret;
}
+ int mxt_load_firmware(struct device *dev, const char *fn)
+ {
+ struct mxt_data *mxt = dev_get_drvdata(dev);
+
+ return mxt_do_firmware_load(mxt, fn);
+ }
+
I know that there are many guides about unlocking bootloader and things have been posted a million times.
From what i've learned from various sources all over the web there's still a lot of confusion,
if and how a device could be unlocked and what is really happening under the hood.
In fact i didn't want to create yet another unlocking bootloader thread, but hopefully a collection of facts,
already known about the process and if it's safe or could be done this way or the other.
Another thing i'd like to put some light on, are some details about the boot process in general.
Please refer to this older thread as well:
http://forum.xda-developers.com/showthread.php?t=1429038
Noob's posting will never end, unless we lift some secrets and make more clear how the processes are basically working.
This should as well cover some basics on how the bootloader/kernel are protected by the manufacturers.
Would be better to use the term security locked/unlocked bootloader anyway.
See this nice page (also referenced in the thread above), which describes the whole boot process on Qualcomm CPU's:
http://www.anyclub.org/2012/02/android-board-bring-up.html
You'll find a link to the original document in the 2 post.
Please prepare for some boring technical details, but as well for some essential guidelines,
how to proceed with your device. Anyway, consider this as a starter...
Enough talking, let's define some headlines or topics to be discussed.
Bootmodes and Protocols
Just to sum up three known modes residing in different stages of bootcode:
- QDL
(PBL loader, lowest level, entered by powering up without battery and testpoint pulled to GND)
- QHUSB_LOAD
(a.k.a. SEMC USB Flash, a.k.a green LED mode, entered by powering up with back button pressed)
- FASTBOOT
(a.k.a blue LED mode, entered by powering up with menu button pressed)
unlocking security vs. SIM-lock
Description:
Locked/unlocked security of the bootloader and SIM-lock are different tracks,
though there's an important dependency between them.
Your device is SIM-locked if service menu gives "bootloader unlockable: no"
or simply refuses SIM-cards from another carrier.
What we know:
- fastboot is disabled on SIM-locked phones
- without removing the SIM-lock there's no way to unlock these phones for free
- normally you may purchase SIM unlock code from your provider
- removing the SIM-lock seems to give access to the fastboot option (confirmed by gen_scheisskopf, thanks!!)
- some devices seem to have restrictions here, result: no fastboot even after removing SIM-lock (this was pointed out once in another thread)
What we need to know:
Please confirm, if bootloader unlock is working after SIM-lock is removed!
In other words will you get fastboot feature after removing SIM-lock?
See the feedback from gen_scheisskopf:
http://forum.xda-developers.com/showpost.php?p=36783582&postcount=8
Result:
As long as you're able to remove the SIM-lock and your phone is old security you would be able to unlock bootloader as well!
old security vs. new security
Description:
Old/new security is independent of the EROM version (e.g. 1241-3656 R9B031) but relates to certain manufacturing dates,
or better the CPU types.
I got trustworthy reports about R9B031 getting unlocked with s1tool.
This date code may vary between the device models, but it seems to be proven,
that devices manufactured in Q2 2012 and later (~12W11..12W16) are new security.
I found out as well, that the manufacturing date of the device and the mainboard may be different.
This might explain why there are some diverging reports for devices in this period.
From what i got so far, the chain of trust includes the secondary bootloader (SBL) on all devices.
In other words SBL is signed code in any case.
At least the fuse setup for this feature is common on most of the Xperia 2011 series.
On a new security device patching or replacing the SBL (s1boot) will fail because OTP ROM could not be cheated.
If you got the "qcreceivepacket" error, your device is new security or at least not supported by s1tool (e.g. MSM8255T models seem not to work).
Only known method to unlock new security is Sony official method (grey market may work as well...).
What we know:
- testpoint method does not work on new security
- it should be safe to try the testpoint method because it won't break anything (if it is done correctly)
- right now there's only one way to check for new security (try and error)
- breaking new security would take ages or is impossible
What we need to know:
Perhaps someone needs to confirm that official Sony method works without flaws on new security.
Result:
Testpoint method should not result in a bricked device.
Official method should do it in these cases.
SEMC patch (testpoint method) vs. Sony official (oem key method)
Description (need some feedback though):
Sony official method to unlock security in the bootloader is done by flashing a generated key to a certain region of NAND.
The keys are device specific and the IMEI is part of the key generation (maybe serial number as well).
The fastboot command oem with the valid key certifies the unlock process and device specific key gets written in the TA section.
Unpatched SBL (s1boot) will always scan for a valid key in this section of NAND.
If there's a valid key, routine will report success and security checks of kernel code will be overriden.
The testpoint method seemse to make use of a bug inside the chips primary bootloader (OTP PBL).
It had been found out that this bug existed in the early Xperia 2011 series and could be used to rewrite parts of NAND flash.
This opened the door to patch parts of the NAND bootcode (s1boot) or even replace the bootloader code.
As a result, the bootloader leaves further security checks aside and continues booting even with an unsigned kernel.
So how could we apply a patch to the bootloader?
By setting the testpoint to GND (force WE# of NAND to GND) external NAND is blocked and the phone gets started on the bare metal.
Only PBL is running at that point.
Though the procedure is not 100% understood, it is for sure that a tiny loader is transfered to the SoC's IRAM and gets executed.
This loader then allows to overwrite first blocks of external NAND memory and replace or at least patch the bootloader.
What we know:
Sony way:
- Sony official method works well with fastboot enabled devices
- DRM get's lost with Sony official method and could not be reverted (it's gone... and yes: no way back!!!)
- If using Sony official method, bootloaders could be re-locked by deleting the key
S1tool way:
- testpoint method does not work on new security (and will never work!)
- By pressing the restore button in S1tool everything is virgin again
- OS is not aware of the patched bootloader
- FOTA will cause bricks
What we need to know:
Basically we need so more details about bootloaders on Xperia 2011 from the cracks here...
Result:
Better understanding of "black box" procedures.
Debugging features at boot level
Description:
Parts of the boot code could still be dumped from memory with Android up and running.
We could dump the specific memory areas by reading the content with tools, such as viewmem.
The areas of interest are accessible in RAM area at:
Code:
0x00000000 - ~0x000023a0
0x00090300 - ~0x000ab190
By disassembling these dumped areas or simply extracting the strings of that region you may get a clue of the bootloaders secrets.
For the geeks and kernel developers its even more interesting to follow the startup procedure of the bootloader and early kernel inits,
with a console hooked up on a serial interface.
In fact we got this debug UART on most of the Xperia 2011.
This interface is present as dev/ttyMSM2 in the Android base system as well and is attached to UART3 of the MSM8255 SoC.
See this post for details:
http://forum.xda-developers.com/showpost.php?p=37660319&postcount=76
The debug UART was at least identified on the MK16i mainboard.
If you need more details, please ask!
We got the testpoints confirmed to be working on lt18i as well.
See here for the location:
http://forum.xda-developers.com/showpost.php?p=37701777&postcount=82
... and the logs:
http://forum.xda-developers.com/showpost.php?p=37983019&postcount=109
Thanks a lot for contribution!
See this beautiful hack for the X8/10 as well:
http://forum.xda-developers.com/showthread.php?t=2064108
What we know:
- parts of NAND could only be accessed with some "evil" tricks (e.g. kexec method)
- there are extensive debugging features available in our bootcode
What we need to know:
It would be nice to find a way to activate a cmdline interface at bootlevel.
Result:
Get some insights of the implemented functions in bootcode.
O.k. i'll stop writing for now.
If this thread will draw some attention, i'll continue
You're always welcome to correct me or leave a comment here.
If you like more technical reading tell me as well.
Opinions and discussion welcome!!!
P.S:
If anyone could point me to some code to write a NAND mtd mapper for 2.6.32-9 stock kernel, you're welcome!
Background: I'd like to get mtdblock4 & 5 access on rooted but security locked device.
CREDITS (no particular order):
Dilesh Perera (for s1tool logs, which helped a lot to draw some conclusions)
gen_scheisskopf (for very useful discussion all over this thread)
hillbeast (for confirmation of UART3 testpoints on LT18i and logs)
...all others who helped to get a better understanding of the fuse registers!
Hugh thanks!!!
TBC
Cheers,
scholbert
Hi,
in the meantime i was able to identify some of the OTP registers used on MSM8255(T), a.k.a. fuse registers.
There's another interesting factory register which identifies the type of CPU.
Though it seems that of "old" and "new" security chip could not directly identified using these registers, it is a nice journey to the internals.
We need a tool to dump these values from userland.
Check out viewmem:
http://blog.maurus.be/index.php/2011/01/samsung-i9000-irom-dump/
Grab the viewmem tool from http://blog.maurus.be/wp-content/uploads/viewmem
Copy to /data/local on your device and execute the tool as root.
HW_REVISION_NUMBER
I started some investigation again and made some dumps using this tool.
./viewmem 0xabc00270 0x4 | hexdump -C
As an example given my device got this ID:
HW_REVISION_NUMBER 0xabc00270 = 0x205720e1
This equals to the JTAG Core ID of the Qualcomm chip.
The other one used for JTAG is the TAP ID = 0x27B360E1
I found these Core ID values of derivates in the web:
CPU: Qualcomm MSM8255
Core ID: 0x205700E1
and
Core ID: 0x205720E1
There's this one as well:
CPU: Qualcomm MSM8255T
Core ID: 0x2057A0E1
If someone likes to contribute, please run the viewmem command given above and post it here.
This way we might get an idea which chip revisions are floating around.
MSM_TCSR_CONF_FUSE
I stumbled over the MSM_TCSR register set by looking into bootloaders and disassembled parts of s1_boot as well.
These gave the same offset in some code snippets.
So here we go...
Code:
MSM_TCSR_PHYS 0xab600000
TCSR_CONF_FUSE_0 0xab60005c // TCSR_CONF_FUSE_0 register (base security setup)
TCSR_CONF_FUSE_1 0xab600060 // TCSR_CONF_FUSE_1 register (enhanced debug)
TCSR_CONF_FUSE_2 0xab600064 // TCSR_CONF_FUSE_2 register (feature setup)
TCSR_CONF_FUSE_3 0xab600068 // TCSR_CONF_FUSE_3 register (unique serial#)
TCSR_CONF_FUSE_4 0xab60006c // TCSR_CONF_FUSE_4 register (L1&L2 clocking)
TCSR_CONF_FUSE_5 0xab600070 // TCSR_CONF_FUSE_5 register (not used)
These are the values i dumped from my device:
Code:
0xab60005c = 0x00716d4b
0xab600060 = 0xc8041447
0xab600064 = 0x28040815
0xab600068 = 0x695888c0 (unique serial number of CPU)
0xab60006c = 0x200001b0
0xab600070 = 0x00000000
MSM8255 based:
Xperia pro (MK16)
FUSE(0-5): 00716d4b c8041447 28040815 695888c0 200001b0 00000000
Which looks very similar to these (found on the web over various forums):
MSM8255 based:
Xperia arc (LT15)
FUSE(0-5): 00716d4b c8041447 28040815 fe53ed80 200001b0 00000000
MSM8255 based (according to GSM forum this is a new security device):
Sony Walkman (WT19i)
FUSE(0-5): 00714b6d c8041447 28040815 14b248a0 200001b0 00000000
MSM8255 based (security unknown):
Xperia neo V (MT11)
FUSE(0-5): 00714b6d c8041447 28040815 13789bc0 200001b0 00000000
MSM8255T based (security unknown):
Xperia arc S (LT18)
FUSE(0-5): 00714b6d e8041447 28040815 e99f59a0 200001b0 00000000
MSM8255T based (new security):
Xperia arc S (LT18)
FUSE(0-5): 00714b6d c8041447 28040815 c25cf0a0 200001b0 00000000
MSM8655 based (security unknown):
Xperia acro (IS11S)
FUSE(0-5): 00714b6d 08041447 28000816 5244e280 200001b0 00000000
We need to confirm if this is true...
Copy viewmem to /data/local on your device and execute the tool as root.
Read out the value of TCSR_CONF_FUSE_0:
./viewmem 0xab60005c 0x4 | hexdump -C
result: 4b 6d 71 00
which is LSB first so please rearrange to get MSB first...
result: 00 71 6d 4b
This is one of the things that still need some clarification:
value = 0x00716d4b old and newsecurity
value = 0x00714b6d definitely new security
This is not proven and maybe it's not the correct register to look at.
Anyway this will be mostly guessing because i'm missing documents.
It's still unknown at which position the trusted boot bit is located and if it play a role for "old" vs "new" security setup.
I will need some more dumps of these registers. So i really would appreciate any help here...
At least dumping that register of:
one device successfully unlocked with s1tool
and
one from a device giving that packet error.
EDIT:
There's no difference here... as far as we got it right now.
How to participate?
First i need information about your device:
- model
- manufacturing date form the sticker under the battery
Second you need root, busyboy installed (with hexdump feature) viewmem tool (see 2nd post) and Android terminal or working adb.
- grab viewmem from the link in 2nd post
- put the viewmem binary on your device in /data/local
- type:
cd /data/local
chmod 0755 ./viewmem
- post the output of your Hardware ID, type:
./viewmem 0xabc00270 0x4 | hexdump -C
- post the output of your TCSR_CONF_FUSE_0..5
./viewmem 0xab60005c 0x14 | hexdump -C
Additionally you might give some details if you already tried to unlock with s1tool and if you got the paket error.
Thanks for all the fish :laugh: !!
MARM_ANY_MODE_DEBUG_DISABLE
Apart from the location of the trusted boot bit this is another very interesting fuse bit.
More to come on this topic soon!
Any help would be appreciated to shed some light on this!
Please join in :victory:
To get a better idea of all this stuff you might have a brief look into the application note attached to this post.
To the admins:
I know that some confidential data could be found all over in this forum, but please tell me if you see conflicts with the forum rules.
Geek stuff link collection:
If you like engineer stuff, check out this comprehensive thread:
http://forum.xda-developers.com/showthread.php?t=1856327
This as well:
http://www.anyclub.org/2012/05/qpst-emergency-download-support.html
EDIT:
This document will give you a good idea what happens on bootup and how parts interact with each other:
http://dl.dropbox.com/u/69550833/Android_Board_Bringup - 80-VM984-1-B.pdf
Hugh thanks to Antagonist42 for this beautiful document collection!!
I may add some referals to the parts used on the Xperia 2011 series...
I will clean up here from time to time and write down conclusions in the first post.
TBC
Regards,
scholbert
Nice post, would put a few more spaces between sentences to make for easier reading though.
Sent from myushi
i dont understank
Thanks for this. It would be good if you could add info on how device owners can determine whether they have a device with "old security" or "new security".
Kris-lam said:
i dont understank
Click to expand...
Click to collapse
What?
Whole world?
Life?
... or the reason why i wrote this thread?
pelago said:
Thanks for this. It would be good if you could add info on how device owners can determine whether they have a device with "old security" or "new security".
Click to expand...
Click to collapse
That would be on of the goals... see my comment in the first post again:
We need the register offset for the security efuse bank on MSM7x30 (MSM8255 as well) devices!
Click to expand...
Click to collapse
Once we got the offset, we may try to dump this region and look for different bits on same models.
If my conclusions are correct, old & new security hardware differ by a single efuse bit and as a result using different signatures and stuff inside NAND.
EDIT:
As an example, here's a driver implementation for LG device using APQ8064:
https://android.googlesource.com/ke...f6e/arch/arm/mach-msm/lge/lge_qfprom_access.c
These are the values on that platform:
Code:
...
#define QFPROM_HW_KEY_STATUS 0x702050
#define QFPROM_SECURE_BOOT_ENABLE 0x700310
#define QFPROM_OEM_CONFIG 0x700230
#define QFPROM_DEBUG_ENABLE 0x700220
#define QFPROM_SECONDARY_HW_KEY 0x7002A0
#define QFPROM_READ_PERMISSION 0x7000A8
#define QFPROM_WRITE_PERMISSION 0x7000B0
#define QFPROM_OVERRIDE_REG 0x7060C0
#define QFPROM_CHECK_HW_KEY 0x123456
...
Little further in that code...
Code:
...
/* addr LSB MSB */
//{ QFPROM_SECURE_BOOT_ENABLE, 0x00000020, 0x00000000}, /* SECURE ENABLE */
//{ QFPROM_OEM_CONFIG, 0x00000031, 0x00000000}, /* OEM ID */
//{ QFPROM_DEBUG_ENABLE, 0xC1000000, 0x0000006F}, /* JTAG DISABLE */
//{ QFPROM_CHECK_HW_KEY, 0x0, 0x0},
//{ QFPROM_READ_PERMISSION, 0x0C000000, 0x00000000}, /* READ PERMISSION */
//{ QFPROM_WRITE_PERMISSION, 0x54100000, 0x00000000}, /* WRITE PERMISSION */
...
Regards,
scholbert
Hi again,
though this thread is drawing less attention, i'd like to inform you about my process.
In the meantime i reviewed some low level code for the MSM7x30 (e.g. AMSS bootcode, moboot bootloader repository) to get a hint how to identify security level on the Xperia 2011 platforms.
As far as i got it the MSM7x30 is the base for the MSM8255 devices as well and i assume that most register offsets and peripheral I/O maps are equal.
First i found an interesting offset definition in the moboot bootloader:
Code:
#define HW_REVISION_NUMBER 0xABC00270
I compiled a little tool for my Xperia, which could be used to read back the content from memory mapped registers (a.k.a. memdump).
By addressing 0xabc00270 some mechanism got triggered and my device rebooted immediately.
My guess is that this is offset belongs to the security area and accessing this area is simply prevented by causing a reboot.
No output here at Android userland...
Next i had a look into the AMSS sources for the Hisense TS7008 development platform.
This seems to be reference code for the modem bootloader (baseband processor) which is a previous step before we boot the oem bootloader ( application processor) in our phones.
Anyway, the interesting part is, that i found another offset address, which is included in the moboot sources as well:
Code:
#define MSM_CRYPTO_BASE 0xA8400000
There are many references to this address and the related registers inside the routines for the crypto stuff (e.g. validate hash values).
I'm gonna try to read some content in this area this afternoon.
EDIT:
O.K. just tried to access these areas... seems like a no go from userland.
My phone freezes, after a while something like a watchdog timeout comes in and resets the device.
This is different to accessing the HW_REVISION_NUMBER, which caused an immediate reset.
Anyway, i guess i give up on this issue...
No discusssion, less interest, no comments from the cracks... the_laser is far away as well...
Cheers,
scholbert
scholbert said:
What we need to know:
Please confirm, if bootloader unlock is working after SIM-lock is removed!
In other words will you get fastboot feature after removing SIM-lock?
Click to expand...
Click to collapse
Yes, bootloader unlock is working after removing SIM-lock.
My ArcS was SIM-locked and I had to remove the lock in order to use the phone. Unlock was done using a code generator. I didn't touch the bootloader in case phone is somehow damaged (bought it as "unused second-hand")
Later I unlocked the bootloader using Wotan server (testpoint method)- no problems during the process, phone works fine.
One question regarding s1boot comes to my mind- how it manages partitioning (and would it be possible co create custom partition layout)?
Flashing official ICS using flashtool changed default (Gingerbread) partition sizes
Hey gen_scheisskopf,
it's a pleasure to meet you again over here :highfive:
How are things rollin' ?
gen_scheisskopf said:
Yes, bootloader unlock is working after removing SIM-lock.
Click to expand...
Click to collapse
Thanks for the feedback.
Just to make it clearer, after applying removing the SIM-lock, the fastboot feature got available... is this right?
gen_scheisskopf said:
My ArcS was SIM-locked and I had to remove the lock in order to use the phone. Unlock was done using a code generator. I didn't touch the bootloader in case phone is somehow damaged (bought it as "unused second-hand")
Later I unlocked the bootloader using Wotan server (testpoint method)- no problems during the process, phone works fine.
Click to expand...
Click to collapse
Mmmh, do you know what's behind this Wotan server method?
Is the bootloader patched as well (real bypass like s1tool) or is there a key generated and flashed to the phone (like official method)?
Just for the statistics... could you please tell me the date code of your phone?
gen_scheisskopf said:
One question regarding s1boot comes to my mind- how it manages partitioning (and would it be possible co create custom partition layout)?
Flashing official ICS using flashtool changed default (Gingerbread) partition sizes
Click to expand...
Click to collapse
This is very interesting indeed and i guess it's possible... someone should spend some time on investigating.
Will require to tweak TA sections or something. BTW i'm not sure if the TA parts are covered by certificates or something.
Anyway it would be required to get a good understanding of this process, otherwise this would cause bricks
Best regards,
scholbert
scholbert said:
Hey gen_scheisskopf,
it's a pleasure to meet you again over here :highfive:
How are things rollin' ?
Click to expand...
Click to collapse
Thanks, everything is OK. Still messing around with my devices (tweaking Toshiba ac100 Froyo now, got usb gamepad+GamepadIME working without any need for chmod-ing )
scholbert said:
Thanks for the feedback.
Just to make it clearer, after applying removing the SIM-lock, the fastboot feature got available... is this right?
Click to expand...
Click to collapse
Honestly I didn't check fastboot availability before removing SIM-lock. For sure it worked after removing the lock
scholbert said:
Mmmh, do you know what's behind this Wotan server method?
Is the bootloader patched as well (real bypass like s1tool) or is there a key generated and flashed to the phone (like official method)?
Click to expand...
Click to collapse
I'm not sure but it's possible that it flashed a patched bootloader- some files were downloaded in order to make the unlock but I didn't investigate what's inside. Client software was "unpack when executed then clean up" exe.
scholbert said:
Just for the statistics... could you please tell me the date code of your phone?
Click to expand...
Click to collapse
11W51 (December 2011?)
scholbert said:
This is very interesting indeed and i guess it's possible... someone should spend some time on investigating.
Will require to tweak TA sections or something. BTW i'm not sure if the TA parts are covered by certificates or something.
Click to expand...
Click to collapse
For sure we can investigate tft files themselves (GB vs ICS). Maybe for repartitioning it would be enough to prepare and flash custom .sin images? Official update seems to work this way, it was reported to work also for Arc using ArcS files
EDIT:
Correction- loader.sin flashing is also required for partition layout modification- original topic
However loader.sin provided in the mod is the same file as the one found in ArcS's baseband 70 and 72
gen_scheisskopf said:
Thanks, everything is OK. Still messing around with my devices (tweaking Toshiba ac100 Froyo now, got usb gamepad+GamepadIME working without any need for chmod-ing )
Click to expand...
Click to collapse
Cool!!
Once thought to buy one, there are many cool hacks floating around.
... off-topic though
gen_scheisskopf said:
Honestly I didn't check fastboot availability before removing SIM-lock. For sure it worked after removing the lock
Click to expand...
Click to collapse
Again thanks for this feedback, will add it to the first post soon...
gen_scheisskopf said:
I'm not sure but it's possible that it flashed a patched bootloader- some files were downloaded in order to make the unlock but I didn't investigate what's inside. Client software was "unpack when executed then clean up" exe.
Click to expand...
Click to collapse
O.k. it's not that important... i'd really like to know a little more about this low level stuff of the unlocking procedure on Xperia 2011, that's why i asked.
gen_scheisskopf said:
11W51 (December 2011?)
Click to expand...
Click to collapse
So s1tool would have worked as well...
gen_scheisskopf said:
For sure we can investigate tft files themselves (GB vs ICS). Maybe for repartitioning it would be enough to prepare and flash custom .sin images? Official update seems to work this way, it was reported to work also for Arc using ArcS files
EDIT:
Correction- loader.sin flashing is also required for partition layout modification- original topic
However loader.sin provided in the mod is the same file as the one found in ArcS's baseband 70 and 72
Click to expand...
Click to collapse
Great, thanks a lot for the link... i'll have a look what's up with it.
Regards,
scholbert
fuse register dump
Hey geeks,
still not giving up... i have a clue now
Just to remember...
I am looking for a way to identify "old" and "new" security chipsets on the Xperia 2011 series.
Few days ago i posted that i could not read the some parts of the internal
register space.
Seemed to be an issue with the tool i used (perhaps wrong flags) which caused system resets.
EDIT:
Updated second post http://forum.xda-developers.com/showpost.php?p=36264032&postcount=2
I'd really find some indication for security level...
If you need some explanation, please ask...
Cheers,
scholbert
My result: 0x00716d4b
Arc S 11w51, unlocked using Wotan server (tespoint method, most likely s1tool-like)
I'll check other registers tomorrow
scholbert said:
Please i need some help here...
At least dumping that register of:
one device successfully unlocked with s1tool
and
one from a device giving that packet error.
Would be very helpful to shed some light on this!
Please join in :victory:
If you need some explanation, please ask...
Cheers,
scholbert
Click to expand...
Click to collapse
Sadly, I have an Arc S 12W16 (edit: Sorry, I was mistaken: it was 12W14 and I'm unlocked via testpoint today), so S1 doesn't work AFAIK (and I read that people that can unlock with SETool doesn't touch any 12W16, so I didn't checked the unlock possibilities/prices). Anyway, I dunno if I did it right but, here's a screen: http://s1.postimage.org/wujbqrs5r/2013_01_25_14_50_41.png - looks like the result is 4b 6d 71 00
Amazing work, btw. I always asked to myself if there was a way to check the type of security (old X new).
Hi,
just to make it clear again... right now i'm still trying to sort things out, that's why i need little help :fingers-crossed:
gen_scheisskopf said:
My result: 0x00716d4b
Arc S 11w51, unlocked using Wotan server (tespoint method, most likely s1tool-like)
I'll check other registers tomorrow
Click to expand...
Click to collapse
Thanks!
So i guess we could definitely mark this as old security fuse setting.
The other values should be similar to the ones i already listed (apart form your unique serial of course).
panda0 said:
Sadly, I have an Arc S 12W16, so S1 doesn't work AFAIK (and I read that people that can unlock with SETool doesn't touch any 12W16, so I didn't checked the unlock possibilities/prices). Anyway, I dunno if I did it right but, here's a screen: http://s1.postimage.org/wujbqrs5r/2013_01_25_14_50_41.png - looks like the result is 4b 6d 71 00
Amazing work, btw. I always asked to myself if there was a way to check the type of security (old X new).
Click to expand...
Click to collapse
Thanks as well... looks O.K. for me. So this is the same value.
Did you try the testpoint method already?
If my assumption is correct, then you might be lucky and got old security as well. BTW, i don't want to be responsible for bricked devices
At least this was my intention to get a real indicator for old security and give a clear statement:
Yes, it's safe to try the testpoint method.
So maybe you just be a little patient...
Some words on the production date:
I found out that the sticker on the back gives the production date of your phone.
There's another one on the processor under the shield on the mainboard.
This one is more related to the series of processors used for your mainboard.
My device is marked as 12W11 (sticker under the battery), while the sticker on the processor states 11W44.
See the pic attached.
In other words, they produced an amount of mainboards back in 2011, but the phone itself got assembled in 2012.
Thanks a lot for helping out, i really appreciate this!
Regards,
scholbert
hi i have a arc s 12w28 i i tryed to execute the viewmem but got nothing
Code:
[email protected]:/data/local # ./viewmem 0xab60005c 0x4 | hexdump -C
sh: hexdump: not found
[INFO] Reading 4 bytes at 0xab60005c...
am i doing something wrong ??
scholbert said:
Hi,
just to make it clear again... right now i'm still trying to sort things out, that's why i need little help :fingers-crossed:
Click to expand...
Click to collapse
:fingers-crossed:
scholbert said:
Thanks as well... looks O.K. for me. So this is the same value.
Did you try the testpoint method already?
If my assumption is correct, then you might be lucky and got old security as well. BTW, i don't want to be responsible for bricked devices
Click to expand...
Click to collapse
Not yet. But if everything works as we're expecting, indeed, I might be a lucky one. I'll see this question ASAP to give some feedback.
Re: [REF]Booting/Unlocking Xperia 2011 series: What's under the hood?
danielgek said:
hi i have a arc s 12w28 i i tryed to execute the viewmem but got nothing
Code:
[email protected]:/data/local # ./viewmem 0xab60005c 0x4 | hexdump -C
sh: hexdump: not found
[INFO] Reading 4 bytes at 0xab60005c...
am i doing something wrong ??
Click to expand...
Click to collapse
Partly... the tool hexdump is used to get a formatted output for console.
You'll need at least a version of busybox with the hexdump feature installed.
Maybe your missing some symbolic links.
Try again with this command:
./viewmem 0xab60005c 0x4 | busybox hexdump -C
If the error persists, your version of busybox is missing that feature.
Would be very interesting to get your output though...
Good luck,
scholbert
scholbert said:
Partly... the tool hexdump is used to get a formatted output for console.
You'll need at least a version of busybox with the hexdump feature installed.
Maybe your missing some symbolic links.
Try again with this command:
./viewmem 0xab60005c 0x4 | busybox hexdump -C
If the error persists, your version of busybox is missing that feature.
Would be very interesting to get your output though...
Good luck,
scholbert
Click to expand...
Click to collapse
Code:
[email protected]:/data/local # ./viewmem 0xab60005c 0x4 | busybox hexdump -C
[INFO] Reading 4 bytes at 0xab60005c...
00000000 4b 6d 71 00 |Kmq.|
00000004
its an arc s 12w18 loked bootloader and sim loked
Re: [REF]Booting/Unlocking Xperia 2011 series: What's under the hood?
danielgek said:
Code:
[email protected]:/data/local # ./viewmem 0xab60005c 0x4 | busybox hexdump -C
[INFO] Reading 4 bytes at 0xab60005c...
00000000 4b 6d 71 00 |Kmq.|
00000004
its an arc s 12w18 loked bootloader and sim loked
Click to expand...
Click to collapse
Mmmh, still the same value... if we trust the statements about date code i would say that this should be new security...
but as i tried to point out already, this could not be taken for granted.
Anyway, locked or unlocked doesn't matter, because i'm looking for security bit in fuse registers.
Did you ever try testpoint method on your device?
Guess we need someone, who already tried the s1tool procedure and got the paket error with his device.
If this phone would give different value on FUSE0 register, it would prove that i'm on the right way.
Thanks for contributing!
Regards,
scholbert
Hey guys,
I finally built omni 4.4 for Gtab2 10.1
My wifi is turned On, but can't find any network.
I used latest blobs from samsung stock rom 4.2.2 to be sure.
logcat:
http://pastebin.com/xm6un9Tg
During the build process i faced an error :
Code:
out/target/common/obj/APPS/framework-res_intermediates/src/com/android/internal/R.java
out/target/common/obj/APPS/framework-res_intermediates/src/android/R.java
expected "}"
public static final class string-array{ }
^
this is not the exact error code but it was almost this.
To bypass this error i just comented both class, i wonder if this can be related?
thanks
I'd suggest looking at other device bringup commits first.
4.4 requires wifi configuration changes and storage configuration changes.
Entropy512 said:
I'd suggest looking at other device bringup commits first.
4.4 requires wifi configuration changes and storage configuration changes.
Click to expand...
Click to collapse
mmhh still no luck.
I don't have any error message in logcat now but still scanning for network and can't find any.
I based my change on aries bring up commit.
Now my ext sdcard work if i'm root, i may need to change some permission in fstab,
and i add edit this line in init.espresso10.rc
Code:
service wpa_supplicant /system/bin/wpa_supplicant \
-Dnl80211 -iwlan0 -e/data/misc/wifi/entropy.bin [email protected]:wpa_wlan0 \
-c/data/misc/wifi/wpa_supplicant.conf -O/data/misc/wifi/sockets
and if I try to add an ssid by hand i got this error in logcat:
Code:
E/WifiConfigStore( 441): failed to set SSID: "mywifi"
E/WifiConfigStore( 441): Failed to set a network variable, removed network: 0
E/WifiStateMachine( 441): Failed to save network
thanks.
Did you add it, or change the one that was already there?
Entropy512 said:
Did you add it, or change the one that was already there?
Click to expand...
Click to collapse
I add it to try, there is no wifi network, it loop on "searching network"
I wonder if my error can be related to what i said earlier
sevenup30 said:
During the build process i faced an error :
Code:
out/target/common/obj/APPS/framework-res_intermediates/src/com/android/internal/R.java
out/target/common/obj/APPS/framework-res_intermediates/src/android/R.java
expected "{"
public static final class string-array{ }
^
this is not the exact error code but it was almost this.
To bypass this error i just comented both class, i wonder if this can be related?
thanks
Click to expand...
Click to collapse
Do you face this error while building omni? can it be because of my java version? i'm on java 6
finally got it working, it was related in init conf file like you said.
Does someone just know how can I disable hardwar keyboard at first boot?
Because of that keyboard never show up so i have to skip the first settings and disable it in language & input.
sevenup30 said:
finally got it working, it was related in init conf file like you said.
Click to expand...
Click to collapse
Could you precise which mod you did in init conf file ?
Because I've the same problem with a build for Acer A200 : loop on AP scan, no results, no possibilities to configure an AP manually....
Thanks
sevenup30 said:
finally got it working, it was related in init conf file like you said.
Does someone just know how can I disable hardwar keyboard at first boot?
Because of that keyboard never show up so i have to skip the first settings and disable it in language & input.
Click to expand...
Click to collapse
Fix or remove the broken kernel driver that's reporting a keyboard as being present when it's not.
Another possibility is you're missing KL/IDC files for some input device that is being treated as a hardware keyboard when it's not. (See the galaxys2-common family - the sii9234 or whatever it is IDC file was needed to keep that input device from being detected as a HW keyboard)
---
---
---
---
---
For owners of Xiaomi Air 12 or 13 that are facing static sound in Audio cause of Windows 10 please update your Realtek driver from their own website and not use windows update or general update. You need to download the latest 64bit driver dated ' 14-Jun-17 - 6.0.1.8186 '
@Wootever, sorry for my unrelated question. But, I have a Xiaomi Air 13 2016 and I've set a supervisor password when I changed to Linux. I then removed the password when I changed back to Windows 10, but it's still asking me for one...
Do you happen to know a way on how to remove the BIOS password on this laptop? I've extracted the executable from Insyde H20 A06 updater and changed the platform.ini, so it does a force flash of the password area (Password=1), however, it's still asking for one.. Any help would be greatly appreciated! Thanks in advance
@r00tPT
Try to set the password again and then set it to blank.
Wootever said:
@r00tPT
Try to set the password again and then set it to blank.
Click to expand...
Click to collapse
Thanks, but I cannot set the a new password, as when I try to access the BIOS, it asks me for a password..
I wanted to reset this password altogether, so I can access my BIOS and set a new one =/
@r00tPT
You can try to flash this default BIOS A06 Package, it will overwrite all device specific data (Serial, Windows Key, NVstore).
All settings should be set to default (including the password), but i haven't tested this (no guarantee and at your own risk).
Edit:
Don't forget to create a backup using the Backup.cmd file, it should be possible to restore the Serial number on the "empty" default BIOS.
Wootever said:
@r00tPT
You can try to flash this default BIOS A06 Package, it will overwrite all device specific data (Serial, Windows Key, NVstore).
All settings should be set to default (including the password), but i haven't tested this (no guarantee and at your own risk).
Edit:
Don't forget to create a backup using the Backup.cmd file, it should be possible to restore the Serial number on the "empty" default BIOS.
Click to expand...
Click to collapse
Thank you, Wootever! I think it's worth a try.
Would it make sense to create the backup, flash the default package, confirm if there's no password and then flash back the original Xiaomi BIOS to restore the Serial number?
Sorry, as I have near to none experience related to bios. thanks once again
@r00tPT
The backup includes all current settings (including the password), restoring it would also re-enable the password protection.
I made a little script to restore the device serial from the backup.bin file.
This is necessary because the Windows Activation seems linked with the device serial number.
Edit:
Updated the script.
Wootever said:
@r00tPT
The backup includes all current settings (including the password), restoring it would also re-enable the password protection.
I made a little script to restore the device serial from the backup.bin file.
This is necessary because the Windows Activation seems linked with the device serial number.
Edit:
Updated the script.
Click to expand...
Click to collapse
Wouldn't it be best to make a backup of the current bios with a flash programmer? I still haven't done this, as I'm trying to figure out what password I put.. (I basically set a supervisor password when I disabled secure boot, but then when I tried to set a new blank password it didn't change it back)
I have a friend who has the exact same laptop. Would it be fine if I made a backup of his bios and restore it into mine?
Could there be an issue or some missing information? Probably only the device serial number, which I could write again using your script? Would that be feasible?
By the way, sorry for asking these questions here/to you, but it's hard to find some guidance regarding this topic. Thanks once again
@Wootever, it worked!! You're the greatest man! I'm now able to access my BIOS again!
Is there any way to re-enable the flash protected range register again, just in case?
Wootever said:
I just got my hands on a Xiaomi Air 13 (2016 version) and wanted to share my findings.
The BIOS version of this device is A07, which is not yet made available by Xiaomi and originally, BIOS updates can only be flashed with the Insyde tools.
However, those require a valid certificate to correctly sign the binary file, thus a provided backup of version A07 won't be applicable as a update.
Intel Flash Programming tool is another alternative which allows to flash unsigned/customized versions, but in practice FPT can't access the BIOS region due to the protected range register which prohibits write access.
Code:
Error 316: Protected Range Registers are currently set by BIOS, preventing flash access.
Please contact the target system BIOS vendor for an option to disable Protected Range Registers.
Fortunately there is an undocumented variable switch that i found by coincidence which deactivates the flash protected range register.
For this i made a little tool which automatically patches the variable to allow BIOS update via FPT.
Note: modifying your BIOS is at your own discretion, i am not responsible for any damage caused by this procedure.
Download my variable patcher, extract it and execute Patcher.cmd
Reboot your device.
Download BIOS A07 for the Xiaomi Air 13 (2016)
Execute Backup.cmd to create a backup of your current BIOS.
Then execute Update.cmd to install version A07.
Use Serial.cmd to restore the device serial number from the backup BIOS.
Reboot your device.
I also made a few changes for this BIOS:
Updated microcode to 0xBA
Increased PWM frequency to 5000 Hz
Click to expand...
Click to collapse
I tried but I have this problem with patcher, any suggestion?
@Wootever
1) after upgrading the bios, how do i re-activate the flash protected range register?
2) do you have the default clean A07 bios (without the microcode and PWM changes)?
thank you!
May I ask if there is an easy way to unlock BIOS totally on Xiaomi Air 13? Because previously I opened a topic about it in biosmods.com , someone reached to me and told that due to write protection it needs quoting from him: "Bios mod can be flashed using SPI-programmer+SOIC8 clip only". That requires opening laptop up and connecting clip on chip physically. I love to tinker things in my laptop but that is a bit scary for me. So is there another way to do it, anyone knows??
THANK YOU!! This is pure gold! By the way, does the flag you found also unlock the ME region?
Update: nevermind. The answer is no unfortunately
bigorbi said:
May I ask if there is an easy way to unlock BIOS totally on Xiaomi Air 13? Because previously I opened a topic about it in biosmods.com , someone reached to me and told that due to write protection it needs quoting from him: "Bios mod can be flashed using SPI-programmer+SOIC8 clip only". That requires opening laptop up and connecting clip on chip physically. I love to tinker things in my laptop but that is a bit scary for me. So is there another way to do it, anyone knows??
Click to expand...
Click to collapse
No, you can flash any bios mod with the flag found by @Wootever. However, you may want to get a programmer (Altera USB blaster has cheap Chinese clones supported by flashrom) and a SOIC8 clip anyway just in case. They're dirt cheap and allow for recovery when things go wrong.
As a bonus, an external programmer enables you to get rid of the management engine.
CARLiCiOUS said:
THANK YOU!! This is pure gold! By the way, does the flag you found also unlock the ME region?
Update: nevermind. The answer is no unfortunately
Click to expand...
Click to collapse
It might be possible if the variable for ME Image Re-Flash is set:
Code:
Me FW Image Re-Flash, Variable: 0xD08
Disabled, Value: 0x0 (default)
Enabled, Value: 0x1
Variable to unlock protected range register:
Code:
BIOS SPI Lock:, Variable: 0x258
Enabled, Value: 0x1 (default)
Disabled, Value: 0x0
Edit:
Here is another variable patcher that also enables the ME Re-Flash variable.
(Note: not tested, use with caution)