Database Users

universal bootloader 1.0 decrypted

After banging my head with the update utility and a bootsplash stuck universal for like hours, I did decrypt the bootloader 1.0... Will do some reverse engineering and post what I find... :lol:
Update: decrypted Bootloader 1.0 is attached...

ady,
if this is true... congratulations!!!
you may want to share your knowledge with buzz and the other specialists ;-)
have a good success
peter

hi ady,
GREAT!
could you please tell me how you did it?
thanx
buzz

By hacking the ruu.dll and running the upgradeut. I'm away at the moment. Will post it later

ady said:
By hacking the ruu.dll and running the upgradeut. I'm away at the moment. Will post it later
Click to expand...
Click to collapse
very interesting approach... )))
buzz

Thanx buzz.
something which I observed earlier while looking at the string table:
It has multilevel password protection and the password for each level i.e update, erase, dump, debug is calculated at runtime.
Moreover the access level resets to lowest after a certain time which makes it almost unhackable
There are strings related to CID meaning there might be a method to change CID

updated first post to attach the decrypted bootloader 1.0 for those who are interested.
Also I succesfully flashed the 1.0 bootloader on a device which was previously updated with 1.01...
Of course if was after hacking the RUU.dll. By default it doesn't let you update to an older bootloader

ady I have been looking at the bootloader of the prophet and the interaction between the romupdate utility and the phone with a software logic analyzer which has revealed a lot of information including the commands that romupdate runs while upgrading the rom.
I am in the process of compiling a list of bootloader commands which may be usefull.
Did you dump the commands while downgrading the bootloader.
Pete

you can find a list of commands very easily. just look at the string table. however not all commands are allowed and that is the callenge

Some commands do not appear to be secured correctly.
For example the rbmc command.
If I run it without a password it says no pemission enter any password and then it will run fine.
The password issued by the romupdate tool seem to be based partly upon the results of the info 2 command as far as I can tell.
The main command I am struggling to figure out is the r2sd command which reads a key/password from the SD Card.

Rymez2K said:
The main command I am struggling to figure out is the r2sd command which reads a key/password from the SD Card.
Click to expand...
Click to collapse
hi,
did you mean d2s command?
buzz

r2sd command runs well when u hv CID unlocked..works for Prohet,wizard and charmer..typhoon

hdubli said:
r2sd command runs well when u hv CID unlocked..works for Prohet,wizard and charmer..typhoon
Click to expand...
Click to collapse
;o))) I thought, this is about Universal 1.00 bootloader...
buzz

According to some source of information there are 2 types of Universal. One with G3 and another with G4 chips. G3 bootroms have string "HW Version : 1.40h" in bootloader and its version is 1.xx, G4: "1.40j" and version numbers are 2.xx. Your ROM is for G3.
And bootrom can be decoded from nk.nbf with alpinenbfdecode.pl script

ady said:
By hacking the ruu.dll and running the upgradeut. I'm away at the moment. Will post it later
Click to expand...
Click to collapse
If this is correct , i hope, ...the nk.nbf of JASJAR bootloader can be decoded from bal66 tool and one can get.nba file.But I was not able to decode further with imgfs tools...it simply fails to do that....

@hdubli
bootloader image - nk.nba - is not an imgfs. you cannot use mamaich's imgfs_tools on it.
bal66's tool cannot decode bootloader nk.nbf to nk.nba either.
buzz

Attached is the file...pls check

hdubli said:
Attached is the file...pls check
Click to expand...
Click to collapse
yes, that file looks to be OK...
buzz

another thing:
lnb command doesn't work on 1.0 or 1.01. Another command wdata is used instead to update.
the difference between the two commands is that lnb needs to have an nb image i.e. lnb lnbtemp.nb whereas wdata transfers the image directly from host computer memory (more hack safe)

Polaris ROM Dump in bootloader mode [HELP]

Hi,
I open this thread in the hope that this might help other people in the future (I found it quite time-consuming to find out the relevant information).
Motivation: My Polaris (actually from O2) had lately a servere graphics error which disappeared after a soft reset, but the day after it refused booting:
after pressing the power button, the provider-logo is shown (appearing with some minor graphics errors) and after 30 seconds the device reboots again. Before doing a hard reset or sending it to HTC, I wanted to backup the NAND-Memory, from which I can - hopefully - restore some data, especially Notes, Short Messages and some contacts.
I spent a lot of time finding out the possible ways of ROM dumping. To summarize what is not possible:
Dumping to MicroSD-card is not possible, since "r2sd" (or "d2s") is not available on the Polaris
Dumping via "itsutils" and "pdocread" is not possible, because it requires a properly running Windows Mobile on the Polaris
Please correct me, if I am wrong.
The only available method seems to be:
Start the Polaris in bootloader mode and connect it to the PC via USB
With HTCFlasher (great tool btw! Alternatively mtty/ttermpro) issue the commands
password BsaD5SeoA
set 1e 1
rbmc
I know that rbmc can be told a start-address and length, but I do not know these addresses. In the first moment this seems to work, even though it is quite slow (~8 KB/s, at the moment the dump is at 71 MB). However, after a first peek into the dump, I noticed that the dump might be partially corrupted, due to some seemingly randomly inserted bytes (mostly with value 0x00). For example: at offset 0x39110 there seems to be a Delivery Confirmation of a Short Message: Instead of "Systemadministrator" it reads "Sys.temadmin.i.rator" (the dots are 0x00, 0x82, 0x81). Or again at offset 0x3D1C0 it reads "Sy.stemadmi.ni.rator" (dots are 0x00, 0x04, 0x81).
I use the latest version of HTCFlasher on linux-2.4.32 with the usb-serial-source of linux-2.4.28.
My questions:
Is there something to keep in mind when using rbmc on the polaris?
...probably regarding usb host buffer sizes? In in this thread pof suggests to use two rbmc's to dump the splashscreen.
Is there another way to perform the dump?

Yeah me too
Yeah I wanted to do something similar with my Kaiser. I wanted to dump the various winCE partitions from bootloader.
I started two threads
http://forum.xda-developers.com/showthread.php?t=481964
and
http://forum.xda-developers.com/showthread.php?t=480410
As you will see the only advice I got was "try using QMAT".
Unfortunately, QMAT is an extremely complicated piece of software and only runs for ten minutes at a time unless you are willing to pay for it.
IMO there should be a simple answer to this but nobody cares enough to read our threads...

Tab SBK burning logic in boot loader and other thoughts

After stupidly doing OTA update and getting SBK flashed on my tab I have been analyzing what how it happened. I figured I would put info here in hopes it might help someone else. Now this is basically my theories based on analysis of the bootloader code. I could be 150% wrong, Caveat emptor.
Useful resource was the Uboot git repository that has some Tegra 2 support:
git.denx.de/?p=u-boot.git;a=summary
Also Ac100 kernel tree gave some insight into fuse logic:
gitorious.org/ac100/kernel/trees/cd81507c9c1075b363f5af1222fa93deee09a13e/arch/arm/mach-tegra/include
Onto the boot loader itself. Even on the unlocked tablet (First thing I did is copied everything using nvflash) the bootloader has logic to burn the fuse settings from FOTA mode. There seem to be 3 modes:
1. Static Key hardcoded in the bootloader
2. Production key that is passed through some parameters area
3. Random key
Now if I am understanding the code right. If the last case is what is used then ultimate unlock does not seem likely as every unit would have its own key.
I am still hoping it is the case #2 that is usually used.
Another avenue of getting SBK I was thinking is getting an unlocked tab to get to fetch update but not let it install. If it is case #2 and key is shared by tablets this could be the way to get hands on it.

I spent some time looking into this a few months ago and came to more or less the same conclusion. My feeble attempt at throwing the bootloader into IDA didn't pan out, especially since I'm a tightass and was trying to trick the free version into letting me load it, and messing around in objdump got nowhere. There's a lot to be gathered from the strings and looking at the Android-side FOTA code though. It seems that one of the partitions (can't remember which) holds a structure used to send messages back to the bootloader, one of which can contain the SBK and other keys. However, some people managed to get their SBK burned by asking to be repartitioned in ODIN, so in that case either a random or predefined SBK must be used. I have my doubts that the FOTA mechanism is being used, and was likely left in for possible future use.
I am curious to see how options 1 & 3 are determined. One possibility is that the SBK may be hashed from the emmc's CID (a unique 128-bit key hardcoded into the onboard flash chip), as that's checked and printed early on in the serial output of the bootloader. (on the other hand, my GS2 does the same thing, it may just be force of habit for Sammy).
The SBK flash code in the bootloader appears to print the SBK to burn during the burning process. IF someone were to still have an unlocked tablet AND they were willing to lock it in the name of science, someone could capture the serial output during the process. One of four things will result: No useful output at all and the tab gets locked, an SBK is printed and it doesn't work on that tab, an SBK is printed and it works on that tab and no others, or an SBK is printed and it's valid for all tabs.
In all likelihood it is completely random. There are probably very few Tabs that come back to Sammy for service that validly need a complete reflash under warranty. In that case it would be most secure to lock the door and throw away the key, and just bite the bullet on the few boards that need to be trashed and replaced.

There seems to be a trigger file written to EFS partition with parameters of what to write to the fuse from a quick look at some strings.
On a separate note. I was thinking on how to tell which option Samsung chose. If the same version of boot loader in encrypted with the same key would it not result in the same encrypted partition? If so then collecting bootloader version with say first 32 bytes of encrypted partition from users should tell if same encryption key is used. Unless some sort of per machine is combined with SBK.

We know the encryption is AES, so it's symmetrical and therefore any keys won't be randomly salted. However, like you said it's likely that the encryption key includes the device serial number or something else that would keep partitions on identically keyed devices from matching. A quick test of this would be to compare bootloader partition dumps from two devices locked with the same SBK, i.e. two Transformers. What's important to realize is that the decryption of the bootloader is driven by firmware built into the Tegra2 that's identical for all chips, so what applies to one Tegra2 device applies to the rest.

[Q] N7 APX mode only - full recovery?

Hi all,
Has anyone followed Rayman's excellent article the-inner-workings-of-secure-boot-key-and-nvflash and fully recovered a N7 from APX only mode?
I have this situation which I think resulted from the battery dying during the 4.4.2 update - Doh I know, but thought I had enough juice to complete the update.
Rayman says the required files will be made available but I cannot find them anywhere

Since every motherboard has a unique key, there is no generic blob. To be able to recover your N7, you will need a backup of it, but it's impossible to make if your device is dead.
Try to send it to Asus/Google.

Erovia said:
Since every motherboard has a unique key, there is no generic blob. To be able to recover your N7, you will need a backup of it, but it's impossible to make if your device is dead.
Try to send it to Asus/Google.
Click to expand...
Click to collapse
Did you read the article? Sounds like you can use the sbk which is a hash of the cpuid...

Nope, but why don't you ask around in the flatline topic?

Erovia said:
Nope, but why don't you ask around in the flatline topic?
Click to expand...
Click to collapse
too much of a noob to post on the forum, but thanks for the pointer.
FYI Raymans article. It does sound possible to bring it back, but there was no follow up with the required files;
What is Secure Boot Key and how does it work?
I've been getting lots of questions about this, so here is some simple background:
The secure boot key is an AES128 encryption key that can used to encrypt various data on the flash memory. It's a generic nvidia tegra2 thing, that the manufacturer can optionally use to make their device more "secure".
When the SBK is set, it's stored in a one-time-programmable "fuse". This also means that now that the key is out, they can't change it on already released devices, only new devices.
When the tegra2 starts up, the AES key is available to the hardware AES engine only. E.g. not even the bootloader can read it back! However, the bootloader can *use* the key to encrypt whatever data it wants through the hardware AES engine. And here is the explanation why the blob flashing method actually works! The bootloader checks for the blob in the staging partition and encrypts and flashes it as needed.
Once the bootloader is done, it clear the key from the AES engine which makes it impossible to encrypt or decrypt things from within the OS.
So what happens when it boots into APX/Nvflash mode?
The basic APX mode is stored in the BootROM and hence can never be changed. It appears to accept only a very limited range of commands, and each command needs to be encrypted using the SBK to be accepted. If it receives a command that's not properly encrypted, it disconnects the USB and appears to be off. This is the dreaded "0x4" error that people have been getting when attempting to get nvflash working.
It should be noted, that even with the SBK inputted into nvflash, most regular nvflash commands won't be available. I'm still not entirely sure why (and I can't rule out it will change).
What *is* available, is the nvflash --create command. What this command does is repartition and format all partitions, set bct and odmdata and send over all needed partitions to the device (and encrypt them as needed). This means a full recovery is possible, but regular ability to flash e.g. just boot.img or read partitions off of the device is not possible at this point.
So what do we need for nvflash?
In order to get a working (e.g. --create) nvflash, we need a few bits of information as well as some files:
◦Secure Boot Key
◦BCT file (boot device setup, ram configuration and a bit more)
◦ODM data (board-specific bit-field specifying various board settings. *Needs* to be correct
◦flash.cfg (e.g. list of settings and names/identifiers of partitions.
On top of these files, we also need all the partitions, e.g. bootloader.bin, boot.img, recovery.img and system.img. Luckily, these partition files are available in official ASUS updates and can be extracted from the blob file using my blob tools
The first four peices aren't readily available, but through lots of effort and a good deal of luck, we have managed to recreate the needed files. Secure Boot Key has already been released (note that this was by far the hardest!) and the rest will most likely follow over the weekend. Keep in mind that we want to keep this legal, so don't expect us to release any ready-made packs for unbricking! We will however make the recreated files available. Since these are recreated and not actual ASUS files, there should be no problems with them.
I hope this helps give a better understanding of how and what secure boot key is and what it gives us.

Where I can find EDL mode programmer file for TB-X605M

Hello everyone, I need help. As English is not my native language, please forgive me for grammar and spelling errors if there is any. I am a Chinese student and our school uses a modded version of the Lenovo TB-X605M for teaching, which has restricted recovery (unable to mount any storage device) , no recovery mode (you have to scan a QR code provided by the service provider to enter) and no developer options (which means I cannot use ADB).
Now I’d like to use it for more purposes, so I decided to flash it through EDL mode (9008).
I read from online that this tablet uses the programmer file “prog_emmc_firehose_8953_ddr.mbn”, but I can’t find this file, and I also can’t find ROM for fastboot flashing (where I can extract the file).
Does anybody have the programmer file or the ROM for fastboot flashing? In addition, will it be OK to use programmer files for the same SoC but designed for other OEMs? I need your help. Please comment below. Thank you very much.

Did you try all these? https://github.com/bkerler/Loaders/tree/main/qualcomm/factory/msm8953
You might have a chance.
In any case, you need to start trying an EDL client (before you find a loader) to get the HWID and Hash.

Renate said:
Did you try all these? https://github.com/bkerler/Loaders/tree/main/qualcomm/factory/msm8953
You might have a chance.
In any case, you need to start trying an EDL client (before you find a loader) to get the HWID and Hash.
Click to expand...
Click to collapse
Thank you for replying.
No. I'd like to try it later as I don't want to risk too much.
For EDL Clients , will "QPST Tool" be OK? And does HWID and Hash do? I never read about them on Chinese Android forums. Anyway, I am going to check out if I can connect to it and try to find them in QPST Tool and write them down.

I've never mixed it up with any of those tools.
I keep it simple, just a bare EDL client.
With them it's not likely you can click a button and accidentally flash all the partitions on your device.
Finding a loader will be the toughest part. You should start now instead of waiting for something to flash.
Just querying for HWID/Hash has zero risk.
Trying out random Firehose loaders has a very small risk.

Renate said:
I've never mixed it up with any of those tools.
I keep it simple, just a bare EDL client.
With them it's not likely you can click a button and accidentally flash all the partitions on your device.
Finding a loader will be the toughest part. You should start now instead of waiting for something to flash.
Just querying for HWID/Hash has zero risk.
Trying out random Firehose loaders has a very small risk.
Click to expand...
Click to collapse
Thank you for your advice.
As I have said before, I have never heard of what is HWID and Hash and I don't know what they do. What I am going to do is to wipe userdata , and I have no idea whether I need to know about HWID and Hash to do this. I am going to try some loaders I found on a Chinese forum. I will start trying from some other Firehose files for the same SoC.
Moreover, I viewed the link in your first reply and found all these files are with the extension name .bin , instead of .mbn . Are they loaders? If they are , how should I use them?
I am just an ordinary student and I am not familiar with command lines. I seldom use it unless I can't do it with GUI.

The HWID tells your processor, the Hash tells you who signed it.
To get a loader to work the two must be compatible.
I am not responsible for the content on Chinese forums.