yashsingh1/xdaforums huggingface dataset:
[Hardware Hacking General] b4dg3r:
This is going to sound silly and I'll probably get flamed for it: the more I look at the irom dump the less I believe it's actually the real bootloader. Please bare with me I'm going to try and explain my doubts.

I'm making the assumption that the irom is designed into the silicon.

The irom is supposed to be the trust anchor for the AP's secure boot proceess. Although our 'phones don't use this security it is a documented feature of the AP. I can't understand why it would have unreachable / redundant sections. For the irom to achieve secure boot functionality it would need to be highly secure, well-scrutinised and un-circumventable. The best information we have so far indicates that it's full of irrelevant and unreachable code. :confused:

Also, although the efuse bits are not set in the majority of our 'phones, according to the data sheet the irom supports authentication of the subsequent boot loader. There are 160 OTP efuse bits which apparently we can read. That rules out them being used as a symmetric cryptographic key or shared secret. To me it indicates that the efuse bits are the public half of an asymmetric crypto key pair. Probably ECDSA-160 - elliptic curve digital signature algorithm with a 160-bit curve.

I can find no crypto code in the irom at all. Algos like ECDSA are quite complicated and would take up a signifcant amount of the irom. As far as I can tell, there's nothing of the sort in there. Assuming the irom is generic, where is the code the can authenticate the PBL?

I wonder if the irom dump is actually the real contents of the irom. IIRC When the first Xbox was hacked it appeared to be booting from a flash device which contained an initially plausible but flawed bootloader. I believe it was actually booting from a rom buried in one of the ASICS. Perhaps a security feature of the AP is that it doesn't present the real irom contents to the outside world?

;)
[Hardware Hacking General] AdamOutler:
I'm working on the SIM card... In order to do that, I needed to view several serial lines at once.

Here's what the output was of the two lines. IO is the one with the KZKZKZ and only a 0 was output on the clk line.

|0
SERIAL2:
|4B|5A|4B|5A|4B|5A|4B|5A|4B|5A|4B|52|4B|5A|4B|5A|4B|5A|4B|5A|4B|5A|4B|5A|4B|5A|4B|52|4A|5A|4B|5A|4B|5A|4B|5A|4B|5A|4B|5A|4B|5A|4B|5A|4B|52|4A|5A|4B|5A|4B|5A|4B|5A|4B|5A|4B|5A|4B|5A|4B|5A|4B|52|4A|5A|4B|5A|4B|5A|4B|5A|4B|5A|4B|5A|4B|5A|4BB
SERIAL1:

SERIAL2: K Z K Z K Z K Z K Z K R K Z K Z K Z K Z K Z K Z K Z K R J Z K Z K Z K Z K Z K Z K Z K Z K R J Z K Z K Z K Z K Z K Z K Z K Z K R J Z K Z K Z K Z K Z K Z K Z K Z K R J Z K Z K Z K Z K Z K Z K Z K Z K R J Z K Z K Z K Z K Z K Z K K

The new version of the Arduino program I wrote utilizes ALL 4 serial ports on the arduino. It's also able to switch between hex and standard output with a press of the "`" button on the keyboard. It starts in hex mode (seen above) and you can switch to the standard, more familiar output with a press of the button. I'll publish the Arduino code after I tidy it up a bit. It would be embarrassing to publish it as is.
[Hardware Hacking General] TheBeano:
I haven't analysed it and I'm no crypto expert, but I think the main integrity checking code starts at D00A924. According to the boot process description the efuse bits are an RSA key hash, and that only takes a few K for a simple implementation. It would be awesome if they had put 64k of dubious code in the silicon just to trick us though. :)
[Hardware Hacking General] TheBeano:
What baud rate is this, and do you have any resistor on the USB port ID pin? I didn't get any data on the SIM pins. If the hookup is the same as the S8500, the SIM RST pin could be the TXD.
[Hardware Hacking General] lilstevie:
iROM will be like the sROM in the apple cpu's, while yes this does sound plausible, we can dump the srom code from the equivalent (a4). It remains in sram until it is overwritten by the next stage of the boot process. it is possible that iROM does not copy PBL over itself in ram thus leaving it there intact for us. other than that unless samsung shutdown the piece of the silicon that has iROM on it, we will be always able to find it

also, having the shared secret doesn't mean compromised, we have the shared secret for the xbox360 but we still can't sign the CB for it, that is the beauty of asymmetric cryptography
[Hardware Hacking General] b4dg3r:
I should have read the boot process section of the manual better. I stupidly assumed the efuse to be a public key and not a hash of it.

The irom performs a cryptograpic hash of the RSA public key and compares it to the efuse bits. If they match, the public key is considered valid and is then used by the irom to validate the first bootloader.

So, the irom must contain the following:

1. a cryptographic hash function which presumably produces a 160-bit output (to match the number of efuse bits). SHA-1 would be a logical choice and I think I've found part of a SHA-1 implementation at 0D00AA64. Compare the magic numbers in the SHA-1 init function here: http://kerneltrap.org/mailarchive/git/2005/9/20/193853

with the magic numbers at 0D00AA64.

That's one heck of a coincidence ;)

2. big number functionality. The RSA algorithm involves raising a very large number to the power of a very large number modulo another very large number. The numbers are unsigned and likely to be at least 1024 bits long (32 x 32-bit words). There should definately be a sub for large number multiplication in the irom. Modular reduction might not be present as tricks exist to avoid it. I think I may have found part of the large multiplier; the subs at 0D00C304, 0D00C320 and 0D00C358 look promising.

The irom looks fairly plausible in that regard although the apparently unreachable code is still odd.
[Hardware Hacking General] midas5:
Fortunately we don't have to worry about the rsa bits because the efuse bits are all zero and therefore not used on the i9000.
[Hardware Hacking General] b4dg3r:
I agree, the e-fuse bits are not relevant in our case.

I think anything we can find out about the irom is useful though. At least if we can positively identify the purpose of more of the irom code it could be beneficial. Even if that code isn't directly relevant we can at least exclude it from further analysis. I find it interesting too ;)
[Hardware Hacking General] AdamOutler:
There was a good article on reverse engineering embedded arm firmware on hackaday.com today. http://www.devttys0.com/2011/05/reverse-engineering-firmware-linksys-wag120n/
[Hardware Hacking General] midas5:
Can someone point me to the correct instruction set manual for the specific cpu in the i9000. To get my reverse engineering tool working, i need to be able to write my own dissassembler.
[Hardware Hacking General] b4dg3r:
It's a ARM Cortex A-8 core which uses the ARMv7 instruction set. There might be some coretex-specific instructions but I think any ARM or ARM7 instruction set reference documentation would be a good start.

I don't think thumb mode is used becase, from the disassembly, the instructions seem to be 4 bytes wide and aligned on 4-byte boundaries.

This looks like a good start:

http://www.ece.wisc.edu/~morrow/ECE353/arm7tdmi_instruction_set_reference.pdf

The quick reference card is useful too

http://infocenter.arm.com/help/topic/com.arm.doc.qrc0001l/QRC0001_UAL.pdf
[Hardware Hacking General] TheBeano:
Anyone want to check their IROM code for me please?

@Odia which Galaxy S variants have you tried this trick on? I have an early GT-I9000, does it definitely work on this model?
[Hardware Hacking General] AdamOutler:
Here is my irom dump. I followed the directions in the post you linked to, then I zipped and uploaded here. I don't know how to analyze it. This is from a GalaxyS SGH-i897

http://xdaforums.com/attachment.php?attachmentid=611772&stc=1&d=1306795949

adam@Adam-Desktop:~/Desktop$ strings iromdump
Insert an OTG cable into the connector!
""""
* @
*@ @
* @
*@ @
wwff
OM setting Error
""""
Nor Check Sum Error
Uart negotiation Error
Uart Check Sum Error
Uart Data Length Over
Nand RnB Detect Error
Nand ECC Error
Nand Check Sum Error
OND Check Sum Error
NO Boot Image
SD Init Error
SD checksum Error
Secure Fail Error
eSSD Init Error
Enumeration TimeOut Error
No input Clock Error
Non Device Mode Error
eSSD Check Sum Error
DDDD
PIODMA
UDMA
MDMA
NONE
( R"
aB@02
adam@Adam-Desktop:~/Desktop$

here is the hex dump http://pastebin.com/fYMgmvBk

adam@Adam-Desktop:~/Desktop$ binwalk ./iromdump
ERROR: Failed to load magic file '/etc/binwalk/magic': could not find any magic files!
[Hardware Hacking General] AdamOutler:
Alright, I'm calling bull**** on Odia. I'm raising the bull**** flag.

There is no serial communications at boot up on the SIM card. I wasted the last 4 days to prove this. I have tried every standard baud rate on all lines of the sim card. There is nothing but random noise and no change in the boot sequence. The SIM card is not even active until ROM loads. No changes at all in boot, no OM=, no change in any message. I even tried holding down the 3 available keys on the unit. I've received NO data during the IROM/PBL sequence and I've not been able to affect anything by sending data during that part of the boot sequence.

Hey, Odia.. Remember when you told me that BSI was the answer over PM? I spent a week trying to figure out how to communicate with that. I performed countless hours of research looking for an answer of communication with that pin guy.

So, I recommend that everyone take anything Odia says with a grain of salt... I know I won't be doing this again on his recommendation:
[Hardware Hacking General] TheBeano:
Thanks, that is identical to mine. Anyone else? You don't have to upload it, just check whether the md5sum is 5360adb4e2f6f62cb6d00a4068ccbd52 .
[Hardware Hacking General] lilstevie:
I9000 and P1000 here both identical
[Hardware Hacking General] xpcomputers:
Adam,

What about shorting sim terminals at boot or running them with different value resistors? Are we sure we were looking for a serial port in the sim connector?

I picture if Sim connector is used by Samsung, it most likely they have a "special dumb sim card" which they slip in the sim socket... then use a resistored usb cable in the micro usb connector too to do the actual communications. That special sim probably just shorts two terminals or puts a resistor between two terminals.

Did your tests rule that out?

Lots of respect for what you guys are doing. Hope you get to the bottom of it!

Mike

Garbled meaning induced by swype when posting from XDA app on SGS I9000. ;)
[Hardware Hacking General] androcheck:
Identical on my GT-I9000.

(altough I seem to have a different SBL installed, as discussed here, but that's of course unrelated to the IROM code)
[Hardware Hacking General] Odia:
Well its at least nice to see someone thinking and not just calling someone a BShitter because they do not understand how to interpret the hints they are being given.

Stick with TheBeano, I am sure he will come up with something, because when AdamOutler comes out with comments like this:-

http://xdaforums.com/showpost.php?p=13968840&postcount=391

Classic :D

Sorry guys your on your own, AdamOutler has somewhat annoyed me and I am not helping any further.
[Hardware Hacking General] AdamOutler:
Yeah... like I didn't try that.. why does your story keep changing?
[Hardware Hacking General] Odia:
My storey as you call it does not change, only your lack of understanding to interpret my hints, not 1 of my hints is the key, they have to be used in combination with each other.

Just because you can stick an over priced USB to TLL converter (when the FTDI reference board is enough) on your USB port and read the results in a terminal window it does not make you a Dev.

Maybe you would care to take a look at some of my work:-

http://xdaforums.com/showthread.php?t=1064978

http://xdaforums.com/showthread.php?t=1101671

http://xdaforums.com/showthread.php?t=1104139

http://xdaforums.com/showthread.php?t=1103357

and if that is not enough:-

http://forum.gsmhosting.com/vbb/f311/

now does that look like someone who needs to BS anyone?

Now just FO and leave me alone before I open up a can of whooping ass on you.
[Hardware Hacking General] AdamOutler:
You've claimed to have a piece of software which you have not released... and not really helped out much other then saying "yeah, continue on... it's possible". Quite frankly, you havn't backed anything up. What's going on with that.. You said you want community involvement in order to release that code. I've brought that.. Got the captivate guys reading here. Raised interest in several forums... Heck, I've even twittered this to people at samsung.

I don't like being jacked around, you ass.

I've put countless hours into this project. I've researched communications standards. I've obtained "confidential and proprietary" un-cut datasheets which I am not able to release here. I've designed software for this project. I've attempted to help out in every way possible. I've linked similar platforms. I've started threads on other sites. I've worked with other forum member's bricks to see what kind of information I can get out of them. I've I also publish results as they are discovered in the appropriate forums... Usually this one.

Just because you hex edited a bin file and compiled a kernel, does not make you a dev.

I read every post you have ever made on 15 april and I keep an eye on you.

Here's my work. http://code.google.com/u/adamoutler/ My stuff generally is large enough to require revision control. I recently removed this from my private SVN server to google code for public access. http://obd-twoner.googlecode.com/svn/trunk/src/ This is 100% my work.

I believe it's someone who wants to save face.

You started by saying it's possible with JTAG http://xdaforums.com/showpost.php?p=12664462&postcount=2

Then you changed your story to BSI. Then the SIM card. Now it's JTAG, BSI and SIM? Really?

Sounds like a threat. Believe me when I say I have defensive resources.

Odia, if you have information, you need to give it up. I've got a logic analyzer and a bus pirate on order for this project. According to you, they're needless expendatures because you already have the answers. I've put alot of time and alot of money into this. It sounds like you just happened upon the information you have... Which also seems to be unable to be backed by any research into hardware or IROM.

So, why not get on the level, instead of being such a shadey character?
[Hardware Hacking General] Odia:
You must think I am stupid, do you think you can anger me into releasing the solution and save you a few U$D in the process.

That sticks, I am out of here.
[Hardware Hacking General] AdamOutler:
Quite the contrary. I think it was cleaver of you to keep us on a wild goose chase to save face.
[Hardware Hacking General] nmcc89:
Let's stop this

It's pretty disappointing to see an argument flame up like this. From what I gather this forum is all about the community, this is why it's been around for so long and so many great devs have produced so much over the years. I think this disagreement is detracting from the original purpose of this thread; to find some alternative (hopefully open source) way to recover an otherwise fully bricked phone other than via JTAG and a RIFF Box.

@Odia I don't think Adam stands to profit personally from any of this, and he has put a lot of work in over the last few months and done a lot of investigation, all at personal expense. I thank him, and everyone else who has put time into this project, since if anything comes out of this then many people (including myself) stand to gain from what seems like a hopeless situation. What is frustrating is that you have some information that you aren't willing to share with the community, and what compounds this further is the fact that this could result in someone spending their own hard-earned cash to find out something that is already known. Maybe you could give us some indication as to why you can't share what you know? There's evidently a lot of smart people here, and if this information was public I think a solution would be reached very quickly.

What isn't helpful is letting personal disagreements get in the way; it isn't productive, I don't want to read it, and I'm sure other people don't either. So can we get this back on topic, keep the arguments to PM and work together?
[Hardware Hacking General] midas5:
Regarding the sim card interface. I have extensive knowledge of smart cards, and they all have different, non standard baud rates. The baud rate used will the clk rate divided by a fixed amount. It would be helpful to find out what rate the sim clk pin has on it. The clk rate is generated by the phone. It is normally between 3mhz and 8mhz.
[Hardware Hacking General] b4dg3r:
Can you post a binary for viewmem? I can't install the tools on my work laptop and I won't be back home for ages :(
[Hardware Hacking General] AdamOutler:
http://blog.maurus.be/index.php/2011/01/samsung-i9000-irom-dump/
[Hardware Hacking General] Rebellos:
iROMs from one S8500 and one S8530 are 100% the same (dumped 0x0-0xFFFF of S5PC110 mem area in different way)

Sad to see that Odia seems to know something but appears to know nothing at all.
[Hardware Hacking General] AdamOutler:
Nevermind... keeping it to myself.
[Hardware Hacking General] b4dg3r:
Don't know how I misssed the binary on that blog. It's been a long day.

$ md5sum iromdump

5360adb4e2f6f62cb6d00a4068ccbd52 *iromdump

Mine's the same as the others. I've a i9000.
[Hardware Hacking General] TheBeano:
Thanks everyone, so much for that theory then. :)
[Hardware Hacking General] AdamOutler:
Well, I'm in a hospital room.. I'm bored. I have my uart setup here and it will be a week or two before my bus pirate and logic analyzer show up. I can send it out for JTAG and it should get back before my new tools. Would it be valuable to anyone for me to SBL> format and SBL> eraseall then see what usb identifies, and if the UART proto is active?
[Hardware Hacking General] midas5:
I think the best way forward is to understand the irom and ibl code more fully. With a fully bricked phone, both remain. Only the pbl and sbl get corrupted. So, we need to understand the path through the code. My efforts will be trying to get my decompiler working with the arm platform. Analysing the code is the only way we will get to a 100% right/wrong answer as to if this is actually possible or not.
[Hardware Hacking General] midas5:
I think that if you spend your spare time helping us to understand the irom and ibl code better, it would probably be the most useful. It is clear to me that that is how odin obtained his answers.
[Hardware Hacking General] midas5:
Has anyone tried running the irom in qemu? qemu can run arm7 code. I do not know how well it simulates the phone hardware though.
[Hardware Hacking General] Rebellos:
Just one thought: I think we should keep right terminology, iROM code is BL0, some people call it iROM BL or BL0 or IBL, others call first stage of PBL IBL(few KB, copied to iRAM from oneNAND and executed there - it can get corrupted too), maybe lets call iROM - BL0 or iROM, there can be no doubt, the first stage of PBL - BL1, as described in Samsung's manual, then comes BL2 (PBL) and BL3(SBL).

iROM code is quite clear and short, running in ARM emulator won't help anything as this code is 100% static (cannot change during runtime), doesn't store much values in iRAM and the most important - is very specific and dependant on S5PC110 architecture, I don't think there exist such emulator.

Deep static analyse can show some iROM weakness, but as for now it doesn't look like we can run UART routines without method to manipulate OM pins/JTAG writing to oneNAND/hardware damaging oneNAND circuits.

I'm totally out of ideas and tools how to modify OM pins, last hope in AdamOutler.

//important edit:

There is NO way to change OM pins, at least in S8500. I'm sure of that. Pins 0 and 3 are by default set to HIGH and rest is grounded, over.

It is hard circuit setting, no gate, no muxer, nothing on their way.
[Hardware Hacking General] AdamOutler:
Are you sure the IBL is the same as the IROM? The IBL shares the same partition as the PBL on our phones... Is this where bada diverges?

==== PARTITION INFORMATION ====
ID : IBL+PBL (0x0)
ATTR : RO SLC (0x1002)
FIRST_UNIT : 0
NO_UNITS : 1
===============================
ID : PIT (0x1)
ATTR : RO SLC (0x1002)
FIRST_UNIT : 1
NO_UNITS : 1
===============================
ID : EFS (0x14)
ATTR : RW STL SLC (0x1101)
FIRST_UNIT : 2
NO_UNITS : 40
===============================
ID : SBL (0x3)
ATTR : RO SLC (0x1002)
FIRST_UNIT : 42
NO_UNITS : 5
===============================
ID : SBL2 (0x4)
ATTR : RO SLC (0x1002)
FIRST_UNIT : 47
NO_UNITS : 5
===============================
ID : PARAM (0x15)
ATTR : RW STL SLC (0x1101)
FIRST_UNIT : 52
NO_UNITS : 20
===============================
ID : KERNEL (0x6)
ATTR : RO SLC (0x1002)
FIRST_UNIT : 72
NO_UNITS : 30
===============================
ID : RECOVERY (0x7)
ATTR : RO SLC (0x1002)
FIRST_UNIT : 102
NO_UNITS : 30
===============================
ID : FACTORYFS (0x16)
ATTR : RW STL SLC (0x1101)
FIRST_UNIT : 132
NO_UNITS : 1146
===============================
ID : DBDATAFS (0x17)
ATTR : RW STL SLC (0x1101)
FIRST_UNIT : 1278
NO_UNITS : 536
===============================
ID : CACHE (0x18)
ATTR : RW STL SLC (0x1101)
FIRST_UNIT : 1814
NO_UNITS : 140
===============================
ID : MODEM (0xb)
ATTR : RO SLC (0x1002)
FIRST_UNIT : 1954
NO_UNITS : 50
===============================

This is where the terminology we use derives from.

I noticed while reading the BADA logs, that there was no properly laid out ID... maybe this will help you too?
[Hardware Hacking General] midas5:
I understand the terminology differently.

IROM is a ROM, stored inside the S5PC110 chip. It is fixed at the factory, and nothing can modify it.

The IROM then loads the IBL from the oneNAND flash chip.

The IBL loads the PBL from the oneNAND flash chip.

The PBL loads the SBL from the oneNAND flash chip.

Although the IBL is located in the oneNAND flash chip, no matter how many times you flash boot-loaders with ODIN, it never ever touches the IBL. It only ever changes the PBL and the SBL.

Regarding running in an emulator, I suggested that because it is sometimes easier to understand what the code is doing if you execute it and single step through it.
[Hardware Hacking General] Rebellos:
Manipulation of OM pins falls out (I don't really believe that there is difference between I9000 and S8500). It really starts too look like there is no way to revive S8500/I9000 sometimes with other way than JTAGing.

Are you sure IBL always persists there? That can open new possibilities, I'm not familiar with ODIN flashing but isn't it erasing whole partition before rewriting it? Also please keep in mind that boot.bin file seems to contain both IBL and PBL. (or, at least it contains 3+ different bootloader stages, this one I confirmed)
[Hardware Hacking General] TheBeano:
Samsung released a specific version of qemu for the s5pc110: http://www.spinics.net/lists/arm-kernel/msg90061.html

It didn't build for me and I don't really have time to look at it, but if you feel like trying it might prove something. I don't know if it emulates OneNAND though.
[Hardware Hacking General] midas5:
Well, using ODIN or HEIMDALL to flash the boot.bin file never makes any changes to bytes 0 - 0x3FFF in the oneNAND flash.

If you do a MD5SUM of the boot.bin file and the BML1, they never match, but if you do MD5SUM starting at offset 0x4000 in the boot.bin and at offset 0x4000 in the BML1, they match.

I call the 0 - 0x3FFF area the IBL.

0x4000 to end of BML1 I call the PBL.