[Galaxy S III General] scholbert:
eMMC hacking.... SD card boot... remove KNOX bootloader... finally?

Hi again,

i'd like to refer to a software package which seems to have leaked from a service center or similar some time ago.

Please refer to this thread, which explains how to revive hard bricked S3 devices and other Exynos devices:

http://xdaforums.com/galaxy-s3/general/samsung-s3-i9300-note2-n7100-i9500-s4-t2647558

I found this package at several other places in the web as well, and it might be useful for some smart experiments :angel:

Here's what i got from it...

S3 repair contains a test suite for low level tests and tasks to setup up S3 from scratch.

You'll have to prepare a MicroSD card with a low-level tool (similar to dd command in linux).

The write script gives an idea about the offsets used on the SD card (multiples of 512 bytes), so i translated those to hex values:

emmc_auto.sbl.bin:1:499OFF: 0x00000200 LEN: 0x0003e600

E4412_S.TN.bl1.bin:9500:16OFF: 0x004a3800 LEN: 0x00002000

S5E4412_asb.bin:20000:40000OFF: 0x009c4000 LEN: 0x01388000

asb.ramfs:80000:97000OFF: 0x02710000 LEN: 0x02f5d000

From what i got by investigating the hex data of these binaries, the functions should be:

- emmc_auto.sbl.bin -> a bootloader suitable to start from SD card only

- E4412_S.TN.bl1.bin -> trustzone binary which sets up this part of the SoC for SD card boot

- S5E4412_asb.bin -> a standalone tool and testsuite compiled as a ready to run binary (no elf format here!)

- asb.ramfs -> a proprietary RMFS formatted ramdisk which carries some test files (e.g. test pattern, test videos, etc.)

A quite interesting piece of code is the S5E4412_asb.bin file.

So grepping some strings in this binary file gave this section, which is responsible for

vendor boot size change with CMD62 (refer to the eMMC datasheet as well) and seems to restore the bootloaders:

0x093DB6 0x2B APP STEP] Step 1. BL Download Address Set
0x093DE6 0x2D APP STEP] Step 2. DRAM Download Address Set
0x0943CA 0x0A NA,\NA0\NA
0x0943D6 0x0A NA$\NA(\NA
0x0943FE 0x2D APP STEP] CMD 0xEFAC62EC : RESPONSE 0x%08x %
0x094432 0x2B APP STEP] CMD 0xCBAEA7 : RESPONSE 0x%08x %
0x094462 0x32 APP STEP] Boot Partition Size : RESPONSE 0x%08x %
0x09449A 0x32 APP STEP] RPMB Partition Size : RESPONSE 0x%08x %
0x09472A 0x24 APP STEP] CMD 6 : RESPONSE 0x%08x %
0x094756 0x2B APP STEP] BL1 & BL2 loading Address : 0x%x
0x094786 0x2C APP STEP] Dram Image loading Address : 0x%x
0x0947B6 0x34 APP STEP] BL1 & BL2 compare address for Read : 0x%x
0x0947EE 0x35 APP STEP] Dram Image compare address for Read : 0x%x

As user Oranav pointed out in the eMMC sudden death research thread, there might be commands

which should initiate low level formatting of the eMMC chip:

CMD62 (ARG: 0xEFAC62EC)

CMD62 (ARG: 0xFAC0021)

This might probably delete all the chip metadata (incl. wear leveling state and bad block info)

and if these commands are correct, it will also reset KNOX counters and stuff.

In other words this is a full factory wipe of eMMC cells.

These are some snippets in S5E4412_ASB.bin located at:

0x8A41C0:

A5 A2 04 00
80 22 06 00
EC 62 AC EF = CMD62 (ARG: 0xEFAC62EC)
00 00 04 12
31 0C 62 00
71 1F 04 00
AB C2 9E FF
5A 7B B6 F0
83 68 AE 0F
CD 12 04 00
21 00 AC 0F = CMD62 (ARG: 0xFAC0021)
EE CC DE 00
A9 40 35 FF
BD AE 33 F1
80 97 72 00
1D 28 04 00

...and again at:

0x8C43F0

2D A2 04 00
CD A4 04 00
80 22 06 00
EC 62 AC EF = CMD62 (ARG: 0xEFAC62EC)
00 00 04 12
31 0C 62 00
AB C2 9E FF
5A 7B B6 F0
9F 1B 04 00
83 68 AE 0F
47 0F 04 00
21 00 AC 0F = CMD62 (ARG: 0xFAC0021)
EE CC DE 00
A9 40 35 FF
BD AE 33 F1
80 97 72 00

This could be some approval for the usage of these commands at least, because these sections are pure ARM assembly and seem to be associated with eMMC low level setup.

I'll have to find out some offsets for this machine code to try a disassembly.

Maybe this will lighten things up even more.

EDIT:

BTW, found one of the main return addresses which is at 0x40008000 (physical address at the beginning of DRAM). Let's see if this is correct.

EDIT2:

Bingo... just had a look in my boot logs i once grepped during UART session:

Starting kernel at 0x40008000...

Conclusion:

The ASB test suite (S5E4412_asb.bin) is booted/started at the same offset as the linux kernel does.

Let's see what this may give us :)

Another thing to mention is, that included in S5E4412_asb.bin there's a M0 test bootloader (GT-I9300).

Have a look at offset 0x08d8fe8 inside the binary :D

So in the end i wonder, if someone has ever used this "Service" card together with a real UART connection to the board.

Apart from the automated test and setup process, my guess is, that there should be some command line or some kind of a test menu which may give alternative choices to proceed certain tasks.

P.S.: Maybe it's hard to understand what i like to point out here... but imagine we use the following:

- emmc_auto.sbl.bin -> a bootloader suitable to start from SD card only

- E4412_S.TN.bl1.bin -> trustzone binary which sets up this part of the SoC for SD card boot

- recovery.img -> kernel + recovery to start completely from SD card (eMMC not touched here!!!)

P.P.S: Let's see if the SD card boot files look for a signature here.....

Stay tuned!

scholbert