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.