Attend XDA's Second Annual Developer Conference, XDA:DevCon 2014!
5,730,529 Members 40,274 Now Online
XDA Developers Android and Mobile Development Forum

[WIP] Unlocking NAND

Tip us?
 
maejrep
Old
#1  
Senior Member - OP
Thanks Meter 1
Posts: 227
Join Date: Jun 2007

 
DONATE TO ME
Default [WIP] Unlocking NAND

Breaking this discussion off from the EVO root thread, as it's a separate beast entirely..

Quote:
Originally Posted by theillustratedlife View Post
(Incidentally, if they would have given us engineering SPLs in the I/O phones, it probably would have delayed the root issue on general-release phones a while longer).
True, but truth be told, there's a separate ENG SPL, which would actually fix the NAND protection by default, if it would flash. But because it's an older release than what came on the phone, it won't let you flash it (even tried with a goldcard, and no go). This version matches the stock version, which means it can be flashed back and forth with no complaints.

Quote:
Can you explain NAND protection a bit further, please? Are the changes being overwritten on startup, or are they being blocked before they occur? Is NAND protection being implemented at the firmware level?
Firmware, yes (aka radio). But it's actually the bootloader (aka hboot) that sends a command to the radio to say lock it or unlock it. There's even a linux API in the "mtd" driver to allow an ioctl() call to unlock a NAND ... IF it's supported (the source code we have shows that the msm_nand_unlock() code is missing, thus it's not supported). When booting into Android, hboot says "lock NAND", and when booting to recovery, it says "unlock". When it's locked, you get a "not enough memory" error when trying to do any writes to the /system partition (even after remounting it as read-write).

The fixes are ..

1) ENG hboot. I've tried unsuccessfully to flash just the hboot.img from the engineering RUU, using our custom recovery ... it goes through the motions like it's supposed to (writes hboot.img into a section of the nand, sets a flag in the bootloader, then reboots; then the bootloader finishes the flash and reboots again back to recovery), but it doesn't take effect .. seems as if it's doing some kind of version check and it fails that version check, so it rejects the hboot.img update.

2) reverse engineer the msm_nand_unlock() API by disassembling hboot and seeing what it does to lock/unlock the NAND, then try to do the same thing from Android. In theory, that would allow it to unlock the NAND from userspace.

I haven't given up on either of these options, I just haven't had the time necessary to devote to it yet.
by popular demand: Donate
 
theillustratedlife
Old
#2  
Senior Member
Thanks Meter 1
Posts: 101
Join Date: Jun 2009
Also from that thread:

Quote:
Originally Posted by theillustratedlife View Post
Could you drop the ENG hboot into a hex editor and change the version & modification dates appropriately?
 
maejrep
Old
#3  
Senior Member - OP
Thanks Meter 1
Posts: 227
Join Date: Jun 2007

 
DONATE TO ME
Quote:
Originally Posted by theillustratedlife View Post
Could you drop the ENG hboot into a hex editor and change the version & modification dates appropriately?
I've gone over it in IDA for a couple hours now It may well be that simple, but it's not just the "0.79.0000" version part, since I did try changing that and it didn't help. But it could be a different version that's read from some other byte in the image. Like I said, still investigating.. :x
by popular demand: Donate
 
Aphax
Old
(Last edited by Aphax; 3rd June 2010 at 10:40 AM.)
#4  
Junior Member
Thanks Meter 1
Posts: 23
Join Date: May 2010
I just wanted to point out that a HTC Desire demo model was found to have S-OFF and had its NAND unlocked, while having the same SPL as normal locked Desires. The S-OFF was triggered by the SuperCID (1111111) I believe which is set somewhere in the radio and also in the 'misc' nand partition (but just changing the CID there had no effect).. not sure if this is helpful but I felt like mentioning it since I guess the NAND locking is similar on both devices. Also I may have gotten some details wrong here since I'm not really involved in mobile phone hackery, but would really love to have a completely unlocked phone
 
joeykrim
Old
(Last edited by joeykrim; 3rd June 2010 at 09:11 PM.)
#5  
Recognized Developer
Thanks Meter 1260
Posts: 1,929
Join Date: Jan 2009
Quote:
Originally Posted by maejrep View Post
When booting into Android, hboot says "lock NAND", and when booting to recovery, it says "unlock".
to clarify, when booting into the bootloader with the userdebug RUU PC36IMG.zip, hboot says unlock NAND and this only applies to /system and the location for hboot.img (SPL?) currently? /recovery remains locked.

you said you're able to flash the engineering hboot.img from recovery? to flash it, you're using the flash_image binary loaded by the EVO-recovery.zip?

i know this is explained above but not 100% clear on how the userdebug RUU PC36IMG.zip unlocks /system and the location for hboot.img ?

sorry if the questions are n00bish, still tryin to get up to speed and its hard w/o the actual phone!
 
maejrep
Old
(Last edited by maejrep; 4th June 2010 at 04:03 AM.)
#6  
Senior Member - OP
Thanks Meter 1
Posts: 227
Join Date: Jun 2007

 
DONATE TO ME
Quote:
Originally Posted by joeykrim View Post
to clarify, when booting into the bootloader with the userdebug RUU PC36IMG.zip, hboot says unlock NAND and this only applies to /system and the location for hboot.img (SPL?) currently? /recovery remains locked.
The "userdebug" part of it doesn't matter: even the stock ROM has its system partition unlocked *while in recovery*. But because the stock recovery has adb disabled, there's not much we can do with it, and because the stock recovery requires HTC-signed update.zip's only, we can't flash anything with it. So whenever the bootloader (hboot) starts loading recovery, as part of that, it tells the radio to unlock the system partition. We just happen to have a userdebug RUU that gives us adb & root while in recovery, thus we can leverage the unlocked /system partition where with the stock recovery we can't.
Quote:
you said you're able to flash the engineering hboot.img from recovery? to flash it, you're using the flash_image binary loaded by the EVO-recovery.zip?
I'm able to *attempt* to flash it, via an update.zip, which has has update-script that says "flash hboot with hboot.img". It is *not* the standard flash_image, because you can't flash the bootloader from something that comes after the bootloader. The bootloader doesn't live in any of the mtd partitions that are accessible from linux kernel space. Basically how it flashes firmware (that includes both hboot and radio images) is it trashes the /cache mtd partition, and shoves the hboot.img (or radio.img) data into the section of NAND that should be the cache partition. Then it reboots. The radio/bootloader sees the special magic header in the cache partition, and understands that it has to take that data and flash it over its current hboot. That step is what is currently failing (with no log or explanation why, yet). Regardless of success or failure, it will reboot back to recovery, because the last step is that recovery has to reformat the /cache partition to make it usable again.
Quote:
i know this is explained above but not 100% clear on how the userdebug RUU PC36IMG.zip unlocks /system and the location for hboot.img ?
The userdebug RUU does not unlock /system. /system is unlocked automatically by the radio and bootloader any time you enter recovery: whether it is on a stock ROM or a userdebug ROM. We simply can't use that to our advantage when using the stock (locked down) recovery, because that recovery only gives us access to certain things. In that sense, it works similar to how /system used to work on older Android devices: Android used to have full access to the /system partition, but couldn't be utilized until it was unlocked by having access to something else (e.g., "root" access). Back then, once you became root, you had the keys to the kingdom: you could delete apps, add apps, reconfigure the system, flash a new recovery image, etc ... and at that point, root could never be taken away from you, because you would just have a rooted recovery image that would let you take over the next system image.

Now that /system is completely locked while not booted in recovery (and "recovery" partition isn't writable, period), having root access means less, because you can't write to /system from Android (or to recovery while in recovery). If we find a way to unlock the NAND, we'll essentially be able to regain those keys to the kingdom. Flashing an engineering SPL would just be the easiest way (once we find out how to make it accept the image), definitely not the only way.
by popular demand: Donate
 
Neotelos_com
Old
#7  
Senior Member
Thanks Meter 61
Posts: 317
Join Date: Jul 2008
Location: Seattle

 
DONATE TO ME
Thread bump, I was sad it got buried as you can see here...
http://forum.xda-developers.com/show...48#post6705148
 
timothydonohue
Old
#8  
timothydonohue's Avatar
Senior Member
Thanks Meter 75
Posts: 1,440
Join Date: Oct 2007
Location: Portland, Maine
dumb question here, but if the flash hboot hboot.img isn't working, wouldn't that imply that there is something left over from the original/stock hboot.img that simply isn't being overwritten? wouldn't was isn't being overwritten be the bit telling everything else to lock up the house later? can that be determined, and either overwritten with an empty bit, or a 'leave the door open' code?

just throwing things out there, because i have no idea what i'm talking about
If you need help, try IRC #Cyanogenmod in freenode.net
Someone may be able to help you there. I will try, if I'm on.
 
theillustratedlife
Old
#9  
Senior Member
Thanks Meter 1
Posts: 101
Join Date: Jun 2009
How does the Qik update work? It comes preinstalled in the system partition, but there's a Market update available for it.

It looks like there's an APK in both app folders:
Code:
#in /system/app
-rw-r--r-- root     root       815870 2010-04-28 22:51 Sprint_Qik.apk

#in /data/app
-rw-r--r-- system   system    4514646 2010-06-04 15:24 com.qikffc.android.apk
Is the new APK telling Launcher to ignore the old APK? I tried looking in com.qikffc.android.apk/AndroidManifest.xml, but it seems to be encoded in something other than text/xml.

I was hopeful that this would be a clue to defeating NAND protection from userland, but the presense of Sprint_Qik makes me think they've left /system alone and tweaked something on /data to hide the old build.
 
Neotelos_com
Old
#10  
Senior Member
Thanks Meter 61
Posts: 317
Join Date: Jul 2008
Location: Seattle

 
DONATE TO ME
Quote:
Originally Posted by maejrep View Post
1) ENG hboot. I've tried unsuccessfully to flash just the hboot.img from the engineering RUU, using our custom recovery...
Are you able to get just the custom recovery onto any ROM without breaking it?
Usermode root with nand access would be great, but right now I'm looking for a custom recovery mode on an official ROM at minimal.

THREAD CLOSED
Subscribe
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes


XDA PORTAL POSTS

Hide Numbers on Your SMS and Call Logs with Reflection

How many times have you given your device to someone else in order to show them a … more

Implement Split View in Your LG G2 KitKat Rom with Automated Installer

Some of you may have remembered a story on the Portal a few weeks back … more

Cast Your Device Screen the Way it Was Meant to be with Second Screen

Not too long ago here on the XDA Portal, we covered how Google had made … more

Samsung Gear Live Unboxed the XDA Way – XDA Developer TV

XDA Developer TV Producer AdamOutleris known for his XDA Unboxingseries where … more