Porting the approach to a i9100?

[olifre]

I am not sure the github issue tracker is the correct place, but at least this gives the idea a prominent place for others to chime in.

Are you aware of any effort to port the "repair approach" to the Galaxy S2?

It seems the bug, or at least its effects, are almost exactly the same, and Samsungs "Fix", judging from personal experience and complaints in forums, has also led to freezes for this device. Interestingly, the only "fix" I find online is to disable MMC_CAP_ERASE in the kernel.

I have such a device with me here (which is "fully" bricked, i.e. also does not show sboot anymore),
but I'm not really up to replicate the full procedure (including re-creating the boot partition etc.)
and I also don't have good contacts to ask for the fixed firmware for the eMMC chip in this device.

For starters, I have downloaded a firmware release for S2, but sadly only found a boot.bin inside (not sboot.bin), so I am unsure whether this is correct.
Also, I'm not sure the hardkernel files can just be re-used for the device.
Any pointers / hints to related projects are much appreciated.

[oranav]

For starters, I have downloaded a firmware release for S2, but sadly only found a boot.bin inside (not sboot.bin), so I am unsure whether this is correct.

You must obtain sboot.bin for this device. I never owned an i9100 but I guess it uses the same boot process, so there must be an sboot.bin somewhere. The firmware you downloaded probably did not intend to upgrade sboot, so just try to obtain something like a "stock" firmware.

The hardkernel files will probably not be suitable. Does your S2 boot to download mode, or is it a complete brick?

[olifre]

Does your S2 boot to download mode, or is it a complete brick?

It's a complete brick.

The firmware you downloaded probably did not intend to upgrade sboot, so just try to obtain something like a "stock" firmware.

I have by now downloaded several versions of stock firmwares. Some contain boot.bin and Sbl.bin, some only Sbl.bin, but I have not found a stock firmware with sboot.bin yet.
Checking the strings inside binaries, I would deduce boot.bin" appears to be the Pbl= Primary Boot Loader, andSbl` is the Secondary Boot Loader.
Should sboot be there in addition, or is just the naming different?

[oranav]

It's a complete brick.

So you must use an external SD card to load sboot. This is of course assuming that Exynos 4210 resorts to external SD card in case eMMC boot fails - otherwise, this method won't work.

According to this link, it seems that ODROID also released a method for booting U-Boot on Exynos 4210, so this does look promising.

Should sboot be there in addition, or is just the naming different?

If I recall correctly, boot.bin is just the Linux kernel + initrd which is only used later in the boot process. Even though it sounds different, it resides in the eMMC's user partition (i.e. not in the boot partition).
I would guess Sbl.bin is the same as sboot.bin in i9300, and that the naming is just different. Can you post some strings from Sbl.bin? Does it contain "S-BOOT" or "S-Boot"?

[olifre]

According to this link, it seems that ODROID also released a method for booting U-Boot on Exynos 4210, so this does look promising.

Nice!

Can you post some strings from Sbl.bin?

Here you go, first Sbl.bin (I did a grep -i boot of the output, and selected a subset of the output):

Secondary Bootloader v3.1 version.
boot
Autoboot (%d seconds) in progress, press any key to stop 
Autoboot aborted..
[...]
boot
BOOT
boot.bin
emmc boot partition open failed.
emmc boot partition close failed.
invalid boot binaries..
BOOTLOADING
fsr_lld_write_bootloader
phone completed: size=%d, efs=%d, boot=%d, final=%d
%s: JIG cable was attached. reboot!!!
%s: JIG On. reboot!!!
[...]
Reboot system
boot [kernel options]
Boot Linux with optional kernel options

No S-Boot string in there...

And boot.bin:

Welcome to Samsung Primitive Bootloader.
build time: %s %s
Jul 18 2012
00:05:36
There is no pit binary.
sbl verification failed.
jump to sbl 0x%x.
can't find the sbl.
pbl found bootable sbl in #%d.
default sbl jump. #%d
[...]
 Total Card Size: %d MByte
(SDHC)
Command is NOT completed1
ReadBuffer NOT Ready
[%s] MMC card is detected
[%s] SD card is detected
0 MB
Product Name : %c%c%c%c%c%c
Command NOT Complete
%s: card initialization failed.
%s: card initialization completed!
mmc_init
hsmmc_init

I'd interpret the strings as if "Pbl" from boot.bin is a "Primitive" first loader chainloading Sbl, a secondary boot loader, and then Sbl in turn appears to chainload a linux kernel (the firmware also contains a zImage file which should be the kernel).

[pali]

Hi! I have Samsung Galaxy Tab 7.7 P6800 which is complete brick too and has Exynos 4210 processor, like S2. And firmware for this device does not have sboot.bin too, just boot.bin and Sbl.bin like S2.

For illustration here is content of XEU-P6800XXLQG-20130306101431.zip firmware for Tab 7.7 (it has Android 4.0.4).

size      filename       type
131072    boot.bin:      data
20308140  cache.img:     Android sparse image, version: 1.0, Total of 25600 4096-byte output blocks in 12 input chunks.
772579964 factoryfs.img: Android sparse image, version: 1.0, Total of 212992 4096-byte output blocks in 1416 input chunks.
95388096  hidden.img:    Android sparse image, version: 1.0, Total of 114688 4096-byte output blocks in 35 input chunks.
12582912  modem.bin:     data
610304    param.lfs:     data
5188340   recovery.img:  Linux kernel ARM boot executable zImage (little-endian)
1310720   Sbl.bin:       data
8387840   zImage:        Linux kernel ARM boot executable zImage (little-endian)

New version of firmware (e.g. THL-P6800DXMD3-20130424182140.zip with Android 4.1.2) is missing two files boot.bin and param.lfs.

I tried to use sboot.bin from S3 on my device but did not worked (nothing happened).

It is expected that S2 and Tab 7.7 could use same bootloader binaries as they have same CPU?

[pali]

Some information what boot.bin and sbl.bin is can be found there: https://android.stackexchange.com/a/142423

boot.bin This is the Primitive Bootloader. Seems to make some basic initializations and finally loads the secondary bootloader.

Sbl.bin The Secondary Bootloader. It loads the PIT, the Linux kernel, params.lfs and the modem. It also is responsible when the device is charging while it's off. This file contains the picture you see when in Download-mode. So it's also responsible for the flashing stuff and getting into recovery.

 The Sbl.bin seems to be there twice. The second one may be for backup, if something bad's going on.

[pali]

Maybe this could help: Benjamin-Dobell/Heimdall#90 (comment) According to that dump from S3, sboot.bin is stored on partition BOOTLOADER starting at sector 0 with size 1734 bytes. Can be get a dump from working S2 device (or any other which use boot.bin & sbl.bin) to know which partition starts at sector 0 and which file is flashed there?

[dmarszk]

As far as I remember (I've done this research some time ago already), the main issue with completely bricked I9100 devices was a lack of presigned BL1 Exynos4210.
For I9300 (Exynos4412 based), bootloading a completely bricked device is possible in 2 different ways:

1. Using FWBL1 from Odroid. It breaks out of a secure-boot chain by just jumping to the next BL stage, without validating it.
2. Using a leaked S-Boot SD-Card, manufactured by Samsung to recover S-boot.

In case of I9100, none of the above was available. We even asked Samsung if they could just sign a binary for us, but they refused.

If nothing has changed, the 2 technical possibilities I see is either:

1. Finding a memory-write vulnerability in the 4210 boot-ROM download mode (it also does signature check on whatever is uploaded through USB).
2. Creating Exynos4210 public key collision. AFAIR, the e-fuses inside the SoC contain a fingerprint hash of the Samsung Exynos 4210 public key. I might be making this up, but I think in some Samsung S5P-xxx bootROM, the fingerprint is shortened to 32-bit only.

@olifre does your ROM enter the download mode? If you boot it up with USB connected, you should briefly see a new USB device appear. I think it only stays attached for couple of seconds, if no USB download is started on the PC side.

PS: It is wonderful to see this project revived, @oranav! Congratulations on the CCC presentation.

[pali]

@dmarszk when I connect Samsung Galaxy Tab 7.7 P6800 (it has Exynos 4210 too) via USB to PC, there is no boot ROM device detected at USB bus. Nothing in dmesg.

[dmarszk]

@pali Then it's likely it gets stuck somewhere after iROM execution, but before SBL (edit: there's no S-Boot) can initialize the download mode. The only way to trigger iROM fallback to other boot sources (including iROM download mode) in that case would be by preventing the SoC from accessing the eMMC. We have had success in doing just that by shorting one of the eMMC pull-up resistors with pliers during the device power-up.

This, however, won't get you anywhere if you do not have a proper payload to upload.

[dmarszk]

I dug out some brief notes from my research done on SGS2 family in 2011/2012, if you want to play with it.
The boot order seems to be:

• iROM
• IBL (has 16 byte header, starts at 0x02021400, signature is at 0x02023800)
• PBL
• SBL
• Linux

SBL implements mostly the same download protocol (ODIN) as SGS1-3. AFAIR SGS3 was the first one to use S-Boot (essentially rewritten and renamed SBL).

There are SecureBoot 2.0 data types that I think I took from Odroid U-boot:
https://gist.github.com/dmarszk/e0d7c83812624fc001af774f22532650

I also have some dumps. Let me know if you need them.

[olifre]

there is no boot ROM device detected at USB bus. Nothing in dmesg.

Same here for the dead SGS2 I have. Completely "dead", i.e. neither USB jig does anything, nor do I see anything in dmesg.

[oranav]

@dmarszk Gaining code execution on the 4210 iROM sounds like a fun and interesting project :-) Even though the attack surface is probably limited.
You mentioned public key collision. Do you mean that you supply both the signature and the public key (i.e. the iROM does not have the public key hard-coded in it)?
If this is the case, the solution (as you implied) would be to generate 2 ** 32 RSA keys until you hit the correct fingerprint (but it could be somewhat intensive), or maybe even 2 ** 32 random numbers (which will later be treated as RSA parameters), then you have random RSA parameters and n should be easily factorizable, right?

I don't own an I9100 however, and I believe I won't have any spare time soon, but in any case - do you know if its iROM has been leaked somewhere? Maybe I'll take a look at the weekend or something like that.

[dmarszk]

@oranav I dropped you an email with what I could dig up.
I don't think the chip actually has RSA pub-key stored in e-fuses. AFAIR it is some kind of hash/HMAC that the RSA provided in PBL image signature is validated against.
See excerpt from subsection 3.2.1 of Exynos 4210 Manual:

[oranav]

@dmarszk Cool, thanks!

[dmarszk]

I found some very interesting (and very recent) blog post - https://www.fredericb.info/2018/03/emulating-exynos-4210-bootrom-in-qemu.html

[pali]

From that description in blog it looks like it is needed to find collision in SHA1 for specified OTP key or breaking included RSA public key. Or rewrtie OTP memory. Any of those options do not seem to be easy...

[oranav]

@pali This is actually worse - it's not a collision, but more like a second preimage ;) I think that without any code execution vulnerability this will be basically impossible, unless Samsung did something very stupid with their RSA key generation.

[pali]

Yes, preimage :-( Anyway, looking at it again and description of verification seems strange

verify HMAC of rsaPubKey : signedData == HMAC(Key, rsaPubKey)

Key = signedData ⊕ OTP_key

How can be signedData generated if it is input for HMAC itself?

[oranav]

rsaPubKey is given. Calculate HMAC using some constant predefined key: HMAC(constantKey, rsaPubKey) = signedData. Set OTP_key = signedData ⊕ constantKey. Then everything works.

[pali]

Ok, now I see it. Samsung first generated RSA key and signed with it bootloader (generated signedData) and after then it generated OTP key and wrote it into devices. (I was in impression that OTP key was there first...)

If there is not any vulnerability for rewriting OTP memory it is really impossible to generate new valid signedData.

[herbsmn]

sounds like we need to h4x0r iROM.

on the verizon version of the Galaxy Note II, which I think is a slightly different Exynos SoC, there was a claim that people had an iROM exploit. dmarszk/exynos4_uboot#4

i wonder what their method was and if it can be reused on the i9100.

[herbsmn]

There's some incredible work going on related to porting the i9300 and n7100 to uboot based on the iROM exploit that I linked to in April. https://blog.forkwhiletrue.me/

Does this work rise to the level of being worthy of being mentioned on the README of this project?

[pali]

@herbsmn: I guess that does not help with booting on i9100 with Exynos 4210.