Android OS Forum banner
1 - 2 of 2 Posts

·
Registered
Joined
·
2 Posts
Preamble
I present you the results of hours of many people research.
Special thanks to:
Adam Outler
mijoma
TheBeano
midas5


I, nor anybody except you take no responsibility for the things you do to your PC, phone, family, neighbours, dog, cat or fish in the result of reading this and/or using any materials linked and included from here.

What is it?
Bootloader used to bypass Secure Booting process in S5PC110 (well known as Samsung's Hummingbird) CPU and executing any unsecure code.

Okay, how useful is it?
It allows fastbooting ANY code on S5PC110 CPU using USB - which means resurrecting bricked devices, booting another OS, custom bootloaders and so on.
It is already been used by several SGS series resurrectors by Adam Outler.

Some additional, technical info and history
S5PC110 - the powerful CPU, heart and brain of many great handsets (like Samsung I9000, S8500, S8530, SGH-897, Google Nexus S, Odroid T, while last one is hard to be called HANDset, nvm) has got few booting levels before loading operating system:

-BL0/iROM, non-writable (not-brickable), written during CPU production process, execution starts here on every machine start, executed straight in iROM, using iRAM(iRAM is 96KB big, there is a spelling error in CPU manual), it does select booting source depending on xOM CPU pins (different types of flash memory/UART/USB), loads BL1 from it and validate its integrity using electronic sign attached to BL1 (iROM doesn't check BL1 integrity if CPU's SECKEY registers are null, there was some misunderstanding of these, but as far it appear that most or all S5PC110 units has got SECKEY not-null, and its always equal in Samsung's phones)
Execution begins from 0xD0000000

-BL1/IBL, writable (brickable), executed in iRAM, it does memory controllers setup, loads BL2 and, depending from info in BL1 electronic sign, it does or does not check BL2 integrity, BL1 is usually splitted to 2 stages, separated in iRAM by few KB of 0x00
Entrypoint of stage 1 = 0xD0020010 (while it should be loaded under 0xD0020000, as it does have 16 bytes of header)
Entrypoint of stage 2 during normal oneNAND boot = 0xD0020800 (this is already platform-dependant but doesn't seems to vary between mainboards)
Entrypoint of stage 2 during external usb/uart boot = 0xD0022010 (here we insert our custom code, sticked to the end of stage1, it must have dummy header)

-BL2/PBL, writable (brickable), executed in RAM (external DRAM or SRAM), it isn't in fact unneeded, God one knows why Samsung's developers decided to add one additional stage
Entrypoint = platform&version-dependant, it's usually 0x40204000 on I9000

-BL3/SBL, writable (brickable), executed in RAM, it does platform init, support LCD output, download mode and usually few additional functions, it does load OS image into RAM, prepare hardware to execute it and jumps into OS entrypoint
Entrypoint = platform&version-dependant, it's usually 0x40244000 on I9000

for more info about booting sequence and OM pins please reffer to section 02, chapter 6 of S5PC110_EVT1_UM.pdf in [6]

//editnotes on that:
This is my own interpretation of bootloaders levels splitting, it haven't been clearly stated in CPU user manual, but it can be also said that IBL is in one part, and PBL is splitted into 2 stages, one executed in iRAM and second executed in DRAM, that's the matter of thinking. Odroid developers seems to use terminology of the second possiblity.
Confirmed from SGS/Captivate boot.bin reversing - Samsung is dividing and calling bootloaders as I wrote in previous points (2nd stage of IBL, which could be aswell 1st stage of 2-stage PBL does contain "IBL" string) Uboot devs got different calling convention. Well... who cares.

After many (even more than many) research [1] we found out that there is no ther way to change iROM primarey booting source than changing OM pins setup, which are hardware soldered through pullup and pulldown resistors to give 5b'001001 (0x9) which means that primary booting source is OnenandMux(Audi) using X-TAL(USB) oscillator (to be honest I still don't hell get what does it means
)
AdamOutler sacrificed Captivate mainboard to locate the pullup and pulldown resistors [2], and in result he modified board to have xOM5=1 instead of 0 which enables UART/USB as primary booting source. This booting method is normally tried only when IBL on oneNAND has been damaged, usually bricked is PBL or SBL, and iROM successfully completes its task, but phone hangs somewhere in the middle.

This enabled Adam to load various data through iROM download mode straight into iRAM. And here comes disappointment - all data we tried to load were validated by iROM code against SECKEY and rejected with "Secure Fail Error", BL1 code loaded by iROM must contain 512 bytes of e-sign, consist of 2 public rsa keys and few sha-1 hashes.

Here comes again days and night of deep code analyze, we found BL1_stage1 in Odroid T U-Boot [4] sourcecode signed by Samsung with stage2 security turned off.
That means any BL1_stage2 can be created and joined to BL1_stage1 in proper way, it will pass all integrity tests and be executed - bingo!

Base code
In the result of research above I've created HIBL, already well known for resurrecting many phones - refer to [8] and [9].
All you need to build it is FASMARM (downloadable from [5], its really everything except SVN directory content and ASM knowledge) and you can compile any code basing on HIBL.ASM.

It does NOT produce output to screen nor widely used UART hidden in Micro-Usb slot. It does produce output to UART2 channel, which is hidden in JTAG pads in SGS/Captivate mainboard or in special pads under battery in S8500/S8530. It can also generate output into usb-UART or LCD, or anything you want, but this needs driver.

If you want some reference, follow [3] and [7] (also in previous revisions), there you can find alot of FASMARM code written for S5PC110 (S8500/S8530 to be precise).

How to run it?
Here comes the problem, it is unable to run if you have no IBL brick or no OM5 modification (reffer to [2]), there you will also find more instructions. It is also able to run by JTAG.

What does it output?
Normal S5PC110 resurrecting procedure of damaged IBL/PBL/SBL produces following output to UART:
����
Uart negotiation Error

-------------------------------------------------------------
Hummingbird Interceptor Boot Loader (HIBL) v2.0
Copyright © Rebellos 2011
-------------------------------------------------------------

Calling IBL Stage2 ...OK
Testing DRAM1 ...OK
iRAM reinit ...OK
cleaning OTG context ...OK
Chain of Trust has been successfully compromised.

Begin unsecure download now...
0x00000000BL3 EP: 0x40244000
Download complete, hold download mode key combination.

Starting BL3 in...

Set cpu clk. from 400MHz to 800MHz.
OM=0x29, device=OnenandMux(Audi)
IROM e-fused - Non Secure Boot Version.

-----------------------------------------------------------
Samsung Secondary Bootloader (SBL) v3.0
Copyright © Samsung Electronics Co., Modified by Rebell
Build On: Jun 8 2011 21:44:47
-----------------------------------------------------------
All lines till first "-" character comes out of iROM, then comes HIBL output, till "Set cpu clk" which is already printed by SBL uploaded through USB.


Postamble
If you want to write something bigger, I'd recommend switching from FASMARM to Codesourcery ARM Crosscompiling environment - everything for S5PC110 is already in Odroid's U-Boot and many Android kernel sources (I9000 for example), ready to compile under Codesourcery. I used FASMARM because it's tiny and simple to create small ASM codes, but doesn't support many functions which are speeding up creating larger code. (In fact I've got no slightest idea how to use CodeSourcery toolkit)

Further reading
[1] Where it all has began - Lets save some bricks
[2] First practical results - The Captivate Development Platform
[3] First S8500/S8530 BL3 hacking - FOTA development thread
[4] What has been used here, and what can be easily ported to any S5PC110 device - Odroid's U-Boot
[5] FASMARM homepage
[6] Samsung Galaxy S (and many similiar devices) Hack Pack by Adam Outler
[7] Badadroid FOTA source tree
[8] Final practical results - Ultimate UnBricking guide of SGS phone
[9] HIBL sourcecode
[10] Clint Eastwood

Note1: Post above may change without further notice if I decide to explain something better.

Note2: Please post any questions and mistakes you found. I'll be happy to answer it if it helps anybody.

Note3: Yes, this thread is in half copy paste from XDA, refreshed it a bit.

Note4: If you are interested, I can create fastbooting guide using HIBL./

//edit:
Forgot to add, here is the list of devices with already developed UnBrickable Mod (allowing to boot HIBL), the tested ones are marked green - http://forum.xda-developers.com/showthread.php?t=1236273
 

·
Developer
Joined
·
34 Posts
Great explanation.

I thought I should add that you can find the OM register in memory using the following command from a device with viewmem and busybox installed
Code:
viewmem 0xE010E100 0x4|hexdump
this will produce an output like this:

Code:
bash-4.1# viewmem 0xE010E100 0x4|hexdump<br />
[INFO] Reading 4 bytes at 0xe010e100...<br />
0000000 0029 0000<br />
0000004
Using this method, today I was able to locate all xOM resistors by analyzing the value change from each one and assigning a proper xOM to it while shorting it high or low.
xOM0=1
xOM1=2
xOM2=4
xOM3=8
xOM4=16
xOM5=32
This post is generally useful for devices with xOM value of 0x29 (41 decimal).. That's xOM0, 3 and 5 high.
 
1 - 2 of 2 Posts
This is an older thread, you may not receive a response, and could be reviving an old thread. Please consider creating a new thread.
Top