[WIP] Unlocking NAND

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

theillustratedlife said:

(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).

Click to expand...

Click to collapse

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.

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?

Click to expand...

Click to collapse

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.

theillustratedlife said:

Could you drop the ENG hboot into a hex editor and change the version & modification dates appropriately?

Click to expand...

Click to collapse

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

joeykrim said:

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.

Click to expand...

Click to collapse

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.

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?

Click to expand...

Click to collapse

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.

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 ?

Click to expand...

Click to collapse

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.