[SimpleData]

Hi,
I am fairly experienced with low-level programming languages and how an operating system boots itself on a device. However, I am curious how the bootloader can be protected. The bootloader is just a set of ARM instructions that loads the operating system onto the memory and then goes onto executing the operating system code.

Since the bootloader is encrypted, there must be an unencrypted code that decrypts the bootloader so that it can be understood and executed by the processor. Since this code is existent, it should be modifiable. The question is that why aren't we modifying this decryption routine so that we can load Android and it's bootloader on Playbook?

[Thachoc1]

Yes i'm sure you'll get an answer to this!

[Sith_Apprentice]

Here is a good starting point, and I am sure RIM layered security on top of it.

OMAP� 4 Platform - OMAP4430/OMAP4460

[SifJar]

Just because code exists doesn't mean it can be modified. They can easily place a ROM chip in the device with a low level bootloader on it, designed solely to decrypt, verify and then boot the "real" bootloader. ROM can't be re-written (hence it's ROM), so you can't change that code. I dunno if that's how it actually happens in the PB or not.

I know for example on the Nintendo Wii, the bootloader has several stages. "boot0" will read a hash from OTP (One Time Programmable) memory [boot0 is also stored here I believe]. It will check this hash against "boot1". If it is verified, boot1 will be loaded, and will then in turn check the signature of "boot2" and load it. boot2 is the only stage that can be updated by Nintendo, because OTP can't be changed, so the hash of boot1 cannot be changed, so boot1 cannot be changed. boot2 can be changed, but only to a newer signed version by Nintendo (except on older Wiis were there is a bug in boot1 which allows custom fake signed versions of boot2 to be installed).

I'm not saying this is anything like how RIM does it with the PB, but I am just showing an example of how a bootloader can easily be "locked down".

[SimpleData]

So, basically, the vendor is trusting the fact that the chip is read-only and that not everybody would go the extra mile to read the contents of the ROM, modify and then write it to another chip, and then replace the physical ROM module with a new chip that contains the modified code.

[Pete6]

If RIM do not want you to get at a part of a device then you cannot do it. Having spent a part of my career in systems security, I point you to the password file in Linux. This is encrypted one way only. There is no system decryptor.

Passwords are encrypted, placed in the file and when a user's password is entered, this too is encrypted and the two encryped strings are compared. If they are the same then the user is granted access. This demonstrates a simple example of a non-decryptable system.

RIM's system security is done partly by encryption (TES), partly by unpublished access codes and also by internal programs that only access parts of the hardware when these access codes are invoked.

All this is overlaid with the non-rewritable ROM.

Remember the Indian governemtn was unable to crack BIS over their own networks.

I doubt that you can crack this.

[SimpleData]

If RIM do not want you to get at a part of a device then you cannot do it. Having spent a part of my career in systems security, I point you to the password file in Linux. This is encrypted one way only. There is no system decryptor.

Passwords are encrypted, placed in the file and when a user's password is entered, this too is encrypted and the two encryped strings are compared. If they are the same then the user is granted access. This demonstrates a simple example of a non-decryptable system.

RIM's system security is done partly by encryption (TES), partly by unpublished access codes and also by internal programs that only access parts of the hardware when these access codes are invoked.

All this is overlaid with the non-rewritable ROM.

Remember the Indian governemtn was unable to crack BIS over their own networks.

I doubt that you can crack this.

I neither have the time nor necessary experience in the field to do it myself. I am just trying to wrap my head around the underlying security measures.

When it comes to the passwd example:
Your analogy was on trying to decrypt the saved passwords. However, a better suiting analogy would be modifying the binary that compares the saved encrypted password with the encrypted input. In the most basic level, changing JZ to JNZ.

Back to the topic...I am not talking about decrypting anything. I am talking about replacing the lowest level of unencrypted system instructions that the PlayBook contains (probably in read-only memory) and then replacing it with a code that loads our bootloader into the memory, and changing the instruction pointer (EIP equivalent) to that memory address so that our code will be executed.

[Sith_Apprentice]

You can also check here
http://forums.crackberry.com/playboo...s-boot-720576/

[xsacha]

It's quite easy.
They just signed it.

The bootrom only accepts signed bootloaders (signed with RIMs signature). It is fool-proof.
Core OS needs to be signed too.
sys.* apps also require a RIM signature.


This is nothing new. Many Android tablets also have secure bootloaders. They provide a tool for users that wish to unlock the bootloader but otherwise it wouldn't be possible for users (without years of time on their hands ).
Also, Blackberry handsets had secure bootloaders.