yashsingh1/xdaforums huggingface dataset:
[Captivate Android Development] AdamOutler:
here is an excerpt from S5PC110 manual describing boot sequence.

The booting sequence in internal ROM is as follows:
1. Disable the watchdog timer.
2. Initialize the instruction cache controller.
3. Initialize the stack and heap region.
4. Check secure key.
5. Set Clock divider, lock time, PLL (MPS value), and source clock.
6. Check OM pin and load the first boot loader (The size of boot loader depends on S/W) from specific device
(block number 0) to iRAM.
7. If secure booting is successful, execute integrity check
8. If integrity check passes, then jump to the first boot loader in iRAM (0xD002_0010)
The booting sequence in internal SRAM is as follows:
1. Load the second boot loader from boot device to iRAM.
2. If secure booting is successful, execute integrity check.
3. If integrity check passes, then jump to the second boot loader in iRAM (The jumping address depends on
user's software)
4. If integrity check fails, then stop the first boot loader.
5. The second boot loader Initializes the DRAM controller.
6. Load the OS image from specific device (block number 1) to DRAM.
7. Jump to OS code in DRAM (0x2000_0000 or 0x4000_0000)
The booting sequence in DRAM is as follows:
1. If S5PC110 is powered on from SLEEP, DEEP_STOP, or DEEP_IDLE modes, then restore the previous
state.
2. Jump to OS code.

here's another excerpt showing what is defined as "Secure Boot"

The secure booting sequence is as follows:
The iROM code
1. Checks the integrity of RSA public key using E-fuse RSA key hash value.
2. Loads the first boot loader to iRAM.
3. Checks the integrity of first boot loader using trusted RSA public key.
The first boot loader
1. Loads security software to iRAM.
2. Checks the integrity of software using trusted RSA public key.
3. Loads second boot loader to iRAM.
4. Checks the integrity of second boot loader using trusted RSA public key.
The second boot loader
1. Loads security software to iRAM.
2. Checks the integrity of software using trusted RSA public key.
3. Loads OS kernel and applications to DRAM.
4. Checks the integrity of OS kernel and application using trusted RSA public key

now here's the results from my phone

-----------------------------------------------------------
Samsung Primitive Bootloader (PBL) v3.0
Copyright (C) Samsung Electronics Co., Ltd. 2006-2010
-----------------------------------------------------------

+n1stVPN 2688
+nPgsPerBlk 64
PBL found bootable SBL: Partition(3).

Set cpu clk. from 400MHz to 800MHz.
IROM e-fused - Non Secure Boot Version.

It's NON-secure boot. Not Secure boot. The fact that it says "IROM e-fused Non Secure Boot Version." says to me that its fused non-secure and it cannot be changed from non-secure because it's efused.

I don't understand how "Non-Secure boot" could mean "Secure Boot".
[Captivate Android Development] Rebellos:
It is secure boot init only on level 0 (iROM), then secure boot context is abandoned by IBL and it becomes non-secure boot, e-fuse means that CPU contains information used to validate IBL and begin secure boot sequence, IBL can continue it, by checking integrity of next stage, but it doesn't.

from uboot sources, God bless them

stage2PubKey is always zero in IBLs of Wave, SGS and Odroid I've checked.

code_SignedData always differs, its checked by iROM, I'm still looking for way how to reproduce it

PubKeyInfo is exactly the same, in S8500, S8530, SGS, Captivate, Odroid releases I've checked, it's nonzero. Rest is filled with zeroes or 0xAA.
[Captivate Android Development] AdamOutler:
That's good then.. we want to use the IROM to load the software then pass to our new PBL/SBL combo right? We can't fight the IROM, we need it to load our program.
[Captivate Android Development] Rebellos:
Exactly, but now I'm stuck. After reading this http://odroid.foros-phpbb.com/t320-uboot-sequence I think Samsung may had not release e-fusing tool, and did just e-fused IBL for Odroid developers. :(

Please try to send it through UART: http://dmarszk.w.interia.pl/c110.rar

Thats IBL of uboot, I assume it'll load, pass security checks and hang. But always good to try. ;d
[Captivate Android Development] AdamOutler:
The GalaxyS Hack Pack contains two variations of fusing tools. Do you have the hack pack? Its in a thread of its own I created. Its for fusing sdcard images.

Will try when I get home.
[Captivate Android Development] Rebellos:
Do you mean AttachHeader and moviNand fusingtool? First one is to attach 16bytes of checksum and some info at the beggining (useless, dnw does it by itself during transfer)

moviNand fusing tool is to get together all binaries in one image, it has nothing to do with e-fuse signing :(

Challenge of the year​

- factorize 1024bit RSA private key that fits public key

key

exponent

HMAC-SHA1

Havent switched any endianess, its raw data from IBL sign. (e = 3)

Anybody? :D

//edit:

I think there are 2 possibilities to get our code loaded and executed through iROM:

-get private rsa key (as far as I know not very possible to crack, maybe get it from samsung) so we can sign any code

-find security hole in iROM
[Captivate Android Development] midas5:
Is the e really only 3 ?

I am asking because there is a particular cryptographic weakness when using e = 3.

Just google for rsa e = 3

No such good news if the key is 1024 bits.

Where is the irom did you find that?

The "is it a secure rom" test in the irom only checks the first 128 bits.
[Captivate Android Development] AdamOutler:
Well, that's no good... 1024-bit RSA would require about 500 million years to brute force.. because we're only testing 128 bits, the collision rate would be extremely high at 1 collision out of every 16384.. no way jose...

We aren't playing around with cracking RSA keys. Don't even mention it. We need to obtian the RSA key, or we need to utilize the power of presigned uboot/odroid/Samsung PBL/something else.

Can someone read the PBL code again and see what it does to verify the SBL? Seems it would be possible to rewrite a SBL easier then a IBL/PBL.
[Captivate Android Development] Rebellos:
Exponent surprised me too, thats odd but seems to be true. It is in IBL sign of all firmwares and also in UBOOT_BL1 I posted. In I9000 its usually at 0x1800 file offset of boot.bin, in UBOOT BL1 its 0xE00, S8500/S8530 its usually at 0x800 offset, data I posted are always the same. I've got structure of sign from odroid uboot sourcecode, posted eariler also.

Haven't been going deeper into validating sign, but basically it checks public rsa key hash (must match data in SECKEY+0x18) and then does SHA1 on part of code, or whole code and compare it with code signature using public rsa key, or something like that.

It does nothing, or almost nothing to verify SBL (I think checksum only generated by odin during flash, or maybe no checksum at all), but what would it give? SBL isn't signed/locked anyway, we in badadroid had been modifying it many times, cutting out big pieces of code and it was still flashing and working well after flash.

Still, what would it give, if we've got IBL brick? Or even SBL brick, that's still no access to oneNAND without JTAG, if there is no hidden download mode in PBL.
[Captivate Android Development] AdamOutler:
I can't seem to get around "Uart Length Over" with my Arduino.....

r0xAA ª| s0xAA| s0xCC| r0xAA ª| r0xCC Ì| r0xCC Ì| r0xD
| r0xA
| r0x55 U| r0x61 a| r0x72 r| r0x74 t| r0x20 | r0x44 D| r0x61 a| r0x74 t| r0x61 a| r0x20 | r0x4C L| r0x65 e| r0x6E n| r0x67 g| r0x74 t| r0x68 h| r0x20 | r0x4F O| r0x76 v| r0x65 e| r0x72 r| r0xD
| r0xA
| r0xD
| r0xA
| r0x49 I| r0x6E n| r0x73 s| r0x65 e| r0x72 r| r0x74 t| r0x20 | r0x61 a| r0x6E n| r0x20 | r0x4F O| r0x54 T| r0x47 G| r0x20 | r0x63 c| r0x61 a| r0x62 b| r0x6C l| r0x65 e| r0x20 | r0x69 i| r0x6E n| r0x74 t| r0x6F o| r0x20 | r0x74 t| r0x68 h| r0x65 e| r0x20 | r0x63 c| r0x6F o| r0x6E n| r0x6E n| r0x65 e| r0x63 c| r0x74 t| r0x6F o| r0x72 r| r0x21 !| r0xD
| r0xA
| r0x0

I did not try to send software so that could be a generic error.. Just wanted to document it

Here's the arduino code I am using...

boolean SequenceInitiated=false;
void setup() {
// initialize both serial ports:
Serial.begin(115200);
Serial1.begin(115200);
}

void loop() {
// read from port 1, send to port 0:
if (Serial1.available()) {
int inByte = Serial1.read();
Serial.print(" r0x");
Serial.print(inByte,HEX);
Serial.print(" ");
Serial.print (inByte, BYTE);
Serial.print ("|");
if (SequenceInitiated==false && inByte == 0xAA){
Serial1.print (0xAA, BYTE);
Serial.print(" s0xAA| ");
Serial1.print(0xCC,BYTE);
Serial.print (" s0xCC|");

Serial1.print(0x00,BYTE);
Serial1.print(0x00,BYTE);
Serial1.print(0x1F,BYTE);
Serial1.print(0x40,BYTE);
SequenceInitiated=true;
}

}
// read from port 0, send to port 1:
if (Serial.available()) {
int inByte = Serial.read();
Serial1.print(inByte, BYTE);
}
}

I'll try with another tool...
[Captivate Android Development] AdamOutler:
All I was able to do with DNW tool is make double the ammount of 0xAA's come up and sometimes it would display a page of the 0xCC's.... Not really much to look at... Could it be looking for another file to be sent?

My phone locked up a few times... I can't explain it, but I can't say "that's the BL1 I flashed" either.
[Captivate Android Development] midas5:
That is still wrong.

Do wait for AA

Send AA

loop1:

Do wait for AA or CC.

If AA send AA. Goto loop1

If CC send CC followed by 4 length bytes.

If get another CC send CC followed by 4 length bytes.

Then follow it with lots of 0x00
[Captivate Android Development] AdamOutler:
I made it like that for simplicity. it's acknowledging that it received CC because it stopped sending them. I will try again tonight with an additional CC before the length.

I think that's the first time I've heard i'm supposed to send

xAA xCC xCCx00x00x20x00
[Captivate Android Development] AdamOutler:
Interesting....

---irom stuff---
8. If integrity check passes, then jump to the first boot loader in iRAM (0xD002_0010)

0xD002_0010

This is where we need to upload a custom bootloader.
[Captivate Android Development] mijoma:
Public exponent equal to 3 does not introduce significant risk for authentication. It's rather problematic in confidentiality cryptographic services implementation.

I think I've seen some UART code in PBL when I looked at it some time ago, so it's pretty much possible there is something we could possibly use. I'll try to analyze that later to see whether the code is being called and on what conditions it's accessible.
[Captivate Android Development] AdamOutler:
I think the UART code in PBL is simply for reporting status. The download mode we are interested in is IROM located at 0xD000_0000-0xD000_FFFF.

Not saying there's not something there, but I don't understand how PBL could help.. The IROM should contain everything required to load data. Once we have a general purpose PBL, we need it to reference an SBL of our choice.

0x0000_0000 0x1FFF_FFFF 512MB Boot area Mirrored region depending on
the boot mode.
0x2000_0000 0x3FFF_FFFF 512MB DRAM 0
0x4000_0000 0x7FFF_FFFF 1024MB DRAM 1
0x8000_0000 0x87FF_FFFF 128MB SROM Bank 0
0x8800_0000 0x8FFF_FFFF 128MB SROM Bank 1
0x9000_0000 0x97FF_FFFF 128MB SROM Bank 2
0x9800_0000 0x9FFF_FFFF 128MB SROM Bank 3
0xA000_0000 0xA7FF_FFFF 128MB SROM Bank 4
0xA800_0000 0xAFFF_FFFF 128MB SROM Bank 5
0xB000_0000 0xBFFF_FFFF 256MB OneNAND/NAND
Controller and SFR
0xC000_0000 0xCFFF_FFFF 256MB MP3_SRAM output buffer
0xD000_0000 0xD000_FFFF 64KB IROM
0xD001_0000 0xD001_FFFF 96KB Reserved
0xD002_0000 0xD003_FFFF 128KB IRAM
0xD800_0000 0xDFFF_FFFF 128MB DMZ ROM
0xE000_0000 0xFFFF_FFFF 512MB SFR region

the PBL is loaded from IRAM. This is where we need to strike in with a signed bootloader. Then, our signed bootloader can load an unsigned second bootloader.
[Captivate Android Development] mijoma:
It's always the question what happens if you damage the SBL only. If it's possible to get to IROM download mode always (even with a working system) then we don't need to discuss the rest - we'll always have a rescue option. But if IROM does not run download code when it finds proper PBL in OneNAND (I haven't checked yet), then we should check what PBL can do and whether we can rescue the unit without hardware intervention if we have working PBL left. I've seen many systems checking for specific magics on UART on startup with such a small timeout that you couldn't tell there was additional step in the booting process. The host system for such repeatedly sending something in 5ms intervals made it go in specific boot mode. That's only one example, but the point is to look for the features that might help us in the development and unbricking. I feel like checking that after I finalize some RL job stuff.
[Captivate Android Development] AdamOutler:
The IROM is a true ROM. It cannot be rewritten. The PBL is device/version speciffic. If we focus on the IROM it would be possible to write something for the S5PC*** platform. If we focus on the PBL, we will be writing a SBL for each device. The IROM download mode will be availalbe on all devices with this modification applied. The IROM is the mode we should be focusing on.
[Captivate Android Development] AdamOutler:
I just got a device in for repair, so I must take care of this before I work on my own phone... I may not be able to try adding in another CC tonight. DNW and AttachHeader+DNW did not work last night when I tried and I tried multiple times. I will continue probly tomorrow.
[Captivate Android Development] Rebellos:
No, deeper iROM analyse shows that bootloader should be uploaded at 0xD002_0000 and contains 16byte of e-fuse header. Code of bootloader should start at 0x10 offset.
[Captivate Android Development] AdamOutler:
What is efuse header? I understand efuse. What is header and why would I be able to write to that area if its fused? Please explain in detail.
[Captivate Android Development] Rebellos:
iROM requires BL1 to have 4 words at the beggining, before code. It is something like

Then comes code section

sign_position isn't direct position of sign, it's somewhat moved offset in IBL, iROM does add 0xD001FE00 to sign_position and the real position comes out.

These are most common sign_position values I've met in various IBLs:

0x600

0x800

0xA00

0x1000

in case when sign_position is lower or equal to 0x4000, code_end and sign_position2 are not used (haven't seen sign position higher than 0x4000 yet in any IBL)

code_end is always equal to (address (not offset) of last OPcode in IBL+4)

sign_position2 is some kind of offset from code_end, it doesn't seem to be valid in case when sign_position <= 0x4000

code_checksum is my assumption, I haven't found any reference to it from iROM yet.

//edit:

Also, comparing to THIS definition, I don't think Samsung understand efuse the same way...
[Captivate Android Development] AdamOutler:
Wait, so... I'm putting 2+2 together here and comming out with 3.

Ok, so we have 4 int32s in a row. that's 128 bits. the first 128 bits are checked for compliance with RSA signature. The first 128 bits contain signature checksum and code end position..

This does not add up... What do the first 1000 bytes contain starting at 0xD002_0000?

Samsung defines eFused as it is written and cannot be written again. Once it is written, the fuse is blown and it will never be able to be written again.
[Captivate Android Development] midas5:
Don't worry. None of that applies to BL1 code loaded by the IROM over serial.

It does apply to BL1 code loaded by the IROM from the OneNand.

I am not sure about the USB to IROM method yet.
[Captivate Android Development] AdamOutler:
the 0xaa and 0xCC come out of the phone at 88 Characters per second... Does this mean anything? It's much slower then the standard 115200bps. I assume it's sending a character, then waiting for a response, sending a char, waiting for a response.. Just a bit slow.
[Captivate Android Development] Rebellos:
Okay then, to clarify:

these 4ints are just header, which leads to code sign which is 512bytes big, and this sign is validated using eFuse bits, thats why I called it "efuse header", wrong as it comes out. Sorry.

After these 4 bytes header BL1 code starts, after code end, there is some empty space and 512byte code sign, iROM is able to locate sign because its location is stored in first int of BL1 header.

Code checksum in header isn't used anywhere, it seems to just exist there, or I just haven't found its purpose yet. The checksum from sign (code_SignedData from the structure i posted before) is used to check bl1 integrity.

Sorry, but you are wrong. It always applies to code loaded from UART, also I'm not sure about usb. Exactly here PC lands when xOM5 = 1, there is no booting tries before that.

as you know, debug_mode_boot starts from UART booting try, if it succeed, it returns and PC lands here

if UART or USB code went with no errors, this CMP always set equal (zero) flag (uart and usb loading functions are setting 0x12345678 magic in desired area if succeed)

Then R6 is begin checked, it is always equal to 1 on e-fused CPU, which means secure boot (iROM is secure booting, but BL1 does not continue this process) this cause following instructions being executed (posted before already, now I just changed symbolic names, to match better functions purpose)

And small update, I'm sure that the third int in header is code checksum. Still not sure about condition when is it validated, probably when we are dealing with not e-fused CPU.

Adam, 0xCC sending is so slow, because after every sent 0xCC function recv_byte is being called, it is checking exactly 1000 times if something appeared on UART RX FIFO, if it did, it reads RX buffer and returns value.

Analysed whole uart protocol code. And here also comes some clarification, which I'm sure about, on PC it should be like (pseudo c++):

During code transmission, iROM waits infinitely until it get enough amount of bytes (equal to size)
[Captivate Android Development] AdamOutler:
I'm not a programmer by trade. I'm a hobbiest. I've learned everything in my spare time. I do Java, Arduino, Bash, old python, basic, pascall, and a few others. I'm not good with C.

This makes no sense to me because I don't understand the operators.

Java and Arduino both share the same syntax, but I don't recognize the operators.. I read >> as a redirect and & as a background operation...

I think I understand most of it. Stages makes more sense then boolean gates. Does the package have to be 4096 in length?
[Captivate Android Development] Rebellos:
a >> n is bit shift a to right by n bits

a << n is bit shift a to left by n bits

& is bit AND

I don't think it have to be 4096B in lenght, but usually is.

Btw, have you tried to load uboot bl1 I linked before?
[Captivate Android Development] AdamOutler:
I tried with dnw and attachHeader+dnw.. nothing...

I have more luck with my arduino program above. It would be better for me to convert that to a Java/bash app eventually... there's no synchronization in dnw so its difficult to time it.

For tonight I'm troubleshooting my RIFF JTAG box.... reflowing about 400 pins and they're tiny.
[Captivate Android Development] midas5:
Operators can mean different things in different languages.

Just Google C language operators.
[Captivate Android Development] Rebellos:
What does "nothing" means? Please notice that the desired result is in fact "nothing", it should appear to hang after loading uboot BL1 (it does not produce any UART output, and does not find BL2, so it hangs)

Oh yea, bitwise operators are there only to parse 16 and 32bit ints into 8bit (byte) pieces.

If size is unsigned short (16 bit int) and its equal to 4096 then its

0001000000000000

We want to split it into 2 bytes, first goes high byte (first from left)

So its 0001000000000000 shift right by 8 = 0000000000010000

0000000000010000 AND 11111111 = 00010000 (conjunction operation is to mask out eventual "noise" and make sure we're getting pure 1 byte value)

0001000000000000 AND 11111111 = 00000000

Then we've got 2 bytes ready to send:

00010000 00000000
[Captivate Android Development] :
Does anybody think this is possible on the Epic?
[Captivate Android Development] Rebellos:
Yes, its the same CPU. But resistor location may differ. Also as you can see this mod is still useless until we find out BL1 signing walkaround.
[Captivate Android Development] midas5:
The phone has a rsa public key in the seckey memory space.

I am thinking that there must be a way to replace the key with another one, for example, if someone leaked it.

If we find a way to replace the key, we could replace it with all zeros!

Problem solved.

I cannot find any docs regarding the seckey area. Can anyone find any?
[Captivate Android Development] Rebellos:
It does not contain rsa public key in SECKEY. It does contain validation data (probably 4 bytes of SHA-1 hash of HMAC-SHA1 of RSA) of public key. Public key is included in sign, and is validated against its HMAC (also included in sign), which is validated against SECKEY+0x18, there are few rounds of SHA-1 used on HMAC. So far I see few (all of them not very likely possible) points where false, valid sign can be created:

- create SHA-1 collision of BL1 with samsung's IBL (with no luck few years of calculation on modern pc)

- factorize private RSA used to sign IBL (same as above, or even worse)

- find new RSA that does match SECKEY (even if only 4bytes of SECKEY are used to validate RSA it may not exist, or be also very time-eating to generate)

According to all infos we have already, we can assume SECKEY is not fully writable (this may be the real e-fuse area, or who knows what else), have been looking for any documentation about it for long time, with no results.
[Captivate Android Development] abuthemagician:
Have you guys tried contacting Samsung directly? Talk to Supercurio as he has a lot of contacts there that might give you some inclinations as to where to find things even if they can't give you all the info you want.
[Captivate Android Development] Rebellos:
I think I've just found a bypass method. Using uboot bl1. All I have to know is does it load without error and hang? If it hang - I'm nearly sure we've got unbricking method. :]

Analyzed uboot signed bl1 and its in fact only stage1 of bl1, it has got integrity check option for stage2, if only stage2PubKey is not-null, but in this case, it's null. :)

Waiting for Adam's feedback.
[Captivate Android Development] AdamOutler:
That's great! Can you copy the file to me? I'll try downloading it.... I've got about 30 different files on my desktop.

I'm pretty sure it hung once or twice using DNW UART.

I could not get it to do it reliably though.. we need a script or program to monitor the UART and perform the intialization sequence. The problem is that DNW does not have a buffer... as soon as you hit transmit, it transmits. It did hang once or twice. I just can't do it every time with the DNW utility.

How do we go on from there?
[Captivate Android Development] Rebellos:
http://dmarszk.w.interia.pl/c110.rar

The next step is attaching our code to it. Now uboot sd card fusing makes sense to me. I'll post my previous code fused to this in 30-60minutes. :)

I wrote you full pseudocode, the rest belongs to you when you get time to implement it in some environment.

If you need some help in porting my bit operations:

http://download.oracle.com/javase/tutorial/java/nutsandbolts/op3.html

http://www.cprogramming.com/tutorial/bitwise_operators.html

http://www.functionx.com/objectpascal/Lesson09.htm
[Captivate Android Development] jmtheiss:
Rebellos, Adam,

Watching you two talk to each other is like watching Santa and Jesus argue over who gets to give me my Christmas present.

Good luck to both of you in this - I really hope it works.
[Captivate Android Development] Rebellos:
Made my night. :D

Me too ;p

Please try it and look for output on debug uart (UART2, the same you use to upload code)

Took little longer, sorry. ;d