I9300 with Firmware XXUGNG3

[arendtio]

I just tried the new version which should not rely on XXELLA anymore, but had no luck. I have two S3 (I9300) phones here, one working fine, the other one is broken. Judging from the dumped firmwares, both are running XXUGNG3 (strings SBOOT | grep I9300).

When I take the broken phone, start it in download mode, it takes about 40 seconds with a black screen until I can see sprinkles on the screen and the following line in lsusb:

Bus 003 Device 090: ID 04e8:685d Samsung Electronics Co., Ltd GT-I9100 Phone [Galaxy S II] (Download mode)

Up to that point I think everything is working fine and running the --dump command worked yesterday just fine. But when I try any other command than the --dump command I end up with the following:

# exploit/sboot_exploit.py --shellcode shellcode/dump_fw_bootrom.bin -o 0xf1.bin
WARNING:root:Cannot write buffer
Traceback (most recent call last):
  File "exploit/sboot_exploit.py", line 470, in <module>
    exploit = Exploit()
  File "exploit/sboot_exploit.py", line 30, in __init__
    self._odin.open()
  File "/home/myuser/Local/S3-Recovery/i9300_emmc_toolbox/exploit/odin.py", line 39, in open
    self.write(b'ODIN')
  File "/home/myuser/Local/S3-Recovery/i9300_emmc_toolbox/exploit/odin.py", line 59, in write
    self.handle.bulkWrite(self.outEndpoint, buf, self.TIMEOUT)
  File "/usr/lib/python3.6/site-packages/usb1/__init__.py", line 1501, in bulkWrite
    return self._bulkTransfer(endpoint, data, sizeof(data), timeout)
  File "/usr/lib/python3.6/site-packages/usb1/__init__.py", line 1480, in _bulkTransfer
    self.__handle, endpoint, data, length, byref(transferred), timeout,
  File "/usr/lib/python3.6/site-packages/usb1/__init__.py", line 133, in mayRaiseUSBError
    __raiseUSBError(value)
  File "/usr/lib/python3.6/site-packages/usb1/__init__.py", line 125, in raiseUSBError
    raise __STATUS_TO_EXCEPTION_DICT.get(value, __USBError)(value)
usb1.USBErrorTimeout: LIBUSB_ERROR_TIMEOUT [-7]

Any ideas?

[oranav]

Protocol initialization failed - it's even before anything interesting happened. You probably tried to run the exploit twice and the protocol is already initialized... Reboot the phone and try again. Also, do you have an SD card inside the slot or do you boot the on-board sboot?

[arendtio]

I got a similar result when I ran --dump twice without rebooting yesterday. Since then, I am rebooting the phone before every try. I tried it with SD card and without, but the result is similar, which makes me think that the sboot on the phone should be intact. I also diffed the dumped firmwares and the differences (which cause the different hashes) seem to occur very late within the files.

One thing I am not so sure of is the micro-usb cable (tried already different ones), but as the dump worked and the phone is listed within lsusb I think that should be ok too.

Is there a fundamental difference in the protocol between --dump and the other commands? Is it possible I did a mistake during the installation?

[oranav]

No, there's no fundamental difference. This is the normal Odin protocol initialization. Did you press volume up once after sboot showed something on the screen? If not, try it, but I doubt it'll make a difference. Please do check the Micro USB cable. Sometimes it can cause issues. Also try another USB port on your PC (use a motherboard built-in one, without any extenders / hubs, and avoid ports on the front of the chassis).

[arendtio]

I am not sure what caused it, but it seems after you latest commit the script progresses a step further. Meanwhile, I double checked the cable and tried the procedure with different Linux distributions (Arch, Exherbo and Kubuntu Live CD). I doubt that my USB-Ports are related to the issues I had yesterday, as I use the same for flashing ROMs.

Anyway, when I start a similar command as yesterday, I get the following output now:

./exploit/sboot_exploit.py --shellcode shellcode/dump_fw_bootrom.bin -o 0xfx.bin --verbose

exploit.log

Judging from the output I would say that the connection works now, but it looks to me as if the function mmc_dev_init fails to find what it is searching for.

Fun fact: After the script fails, the phone reboots and when it is back again, the download mode screen actually draws a normal download mode image ;-)

[Badel2]

Hi @arendtio, the same think happens to me (mmc_dev_init fails). That's probably because your emmc chip is not VTU00M, which means that your device is not affected by the brick bug. So in theory you should be able to unbrick the phone the usual way (flashing with odin or heimdall).

[arendtio]

Hi @Badel2, do you know an easier way to find out which chip the phone actually uses than to open it? So far I didn't check which version of the chip my phones use.

[Badel2]

Yes, I'm working on it right now. You need to dump the memory arround the arena (0x440e8090 in my case), and grep for the chip name. For example, my chip is a 016G92 and I find its name at 0x440f4380.

and 0x44ef0ecc, but I also find the VTU00M string at 0x44ef0ec0, so I guess that the "active" chip is at 0x440..., and there is a list of all chip names at 0x44e... Ignore that, the shellcode is loaded at 0x44e and I was using shellcode to search for the string, so it "found itself".

(that's assuming the device doesn't boot, if it works just run this command as root using a terminal app or adb):

cat /sys/class/block/mmcblk0/device/name

[oranav]

@arendtio I just increased the sboot area that is being searched for mmc_dev. Please try it now.

[arendtio]

@oranav Thanks :-) with my good/working phone it seems to work now :+1:

[+] Shellcode started
[*] Found MMC device address
[*] Activated eMMC RAM reading backdoor. Reading RAM...
[+] Shellcode is done! Rebooting...

That phone has a VTU00M according to /sys/class/block/mmcblk0/device/name.

However, my broken phone still doesn't work:

[+] Shellcode started
ERROR:root:Shellcode failed
ERROR:root:Status code: -1

I still haven't found out which chip it actually uses. I tried reading a very large dump by modifying the count in sboot_exploit.py. That way I can read about 17MB of data. In the large_dump_good from my working phone I can find VTU00M but when I look at the same place in the large_dump_broken from my broken phone, there are zeros while the context looks similar to some extend :-/

# hexdump -C large_dump_good | grep VTU00M
002f4380  56 54 55 30 30 4d f1 00  32 01 27 d0 ff 03 59 0f  |VTU00M..2.'...Y.|

# hexdump -C large_dump_good | grep -C 2 002f4380
002f4360  00 00 00 00 00 00 00 00  1c 81 e1 43 ec 7c e1 43  |...........C.|.C|
002f4370  3c 7a e1 43 00 00 00 00  00 00 00 00 15 00 00 00  |<z.C............|
002f4380  56 54 55 30 30 4d f1 00  32 01 27 d0 ff 03 59 0f  |VTU00M..2.'...Y.|
002f4390  ff ff db f6 6d 40 40 8e  56 00 01 15 30 30 55 54  |....m@@.V...00UT|
002f43a0  d1 af f1 4d bb 5f 06 71  00 00 00 00 00 00 00 00  |...M._.q........|

# hexdump -C large_dump_broken | grep -C 2 002f4380
002f4360  00 00 00 00 00 00 00 00  1c 81 e1 43 ec 7c e1 43  |...........C.|.C|
002f4370  3c 7a e1 43 00 00 00 00  00 00 00 00 3c 00 00 00  |<z.C........<...|
002f4380  00 00 00 00 00 00 00 00  00 00 5a 5a 00 00 00 00  |..........ZZ....|
002f4390  00 00 00 00 e9 00 00 00  00 00 3c 3c 00 00 00 00  |..........<<....|
002f43a0  00 00 00 00 b7 01 00 01  00 00 00 00 00 00 00 00  |................|

Maybe I should just open the broken device. Any advice on that?

[oranav]

AFAIK zeroes usually mean the eMMC is bricked, i.e. can't boot into normal mode, since only after the eMMC boots it tells the host which chip it is. The error you encounter is still related to the mmc_dev heuristic. However it is strange that it works on one device but not on the other. Can you send me your 17MB dump?

[arendtio]

@oranav I sent you both large_dump files via email.

Just to clarify: the 'working' phone doesn't have any emmc issues, which might explain why it reports its chip name. It just runs as it should on Lineage OS.

[oranav]

@arendtio Thank you, I did find an issue with the mmc_dev heuristic. Please try it again now?

[arendtio]

I tried your new version and it looks like the heuristic works now :-)

Sadly something else seems to be broken. Short version:

# ./exploit/sboot_exploit.py --shellcode shellcode/dump_fw.bin -o 0xfx_brokenphone_1.bin --verbose
[+] Shellcode started
[*] Found MMC device address
ERROR:root:Shellcode failed
ERROR:root:Status code: -19

# ./exploit/sboot_exploit.py --shellcode shellcode/dump_fw_bootrom.bin -o 0xfx_brokenphone_1.bin --verbose
[+] Shellcode started
[*] Found MMC device address
DEBUG:root:Read 2 bytes failed
DEBUG:root:Read 2 bytes failed
[...]
DEBUG:root:Read 2 bytes failed
[*] Rebooted eMMC into bootrom mode
DEBUG:root:Read 2 bytes failed
[*] Reading eMMC firmware to eMMC RAM
ERROR:root:Shellcode failed
ERROR:root:Status code: -19

# ./exploit/sboot_exploit.py --shellcode shellcode/write_fw.bin -e SBOOT --verbose
[+] Shellcode started
[*] Found MMC device address
DEBUG:root:Read 2 bytes failed
DEBUG:root:Read 2 bytes failed
[...]
DEBUG:root:Read 2 bytes failed
[*] Rebooted eMMC into bootrom mode
DEBUG:root:Read 2 bytes failed
ERROR:root:Shellcode failed
ERROR:root:Status code: -19

Full log: failed_attempts.log

I am not quite sure what this is supposed to mean, but all those failed reads are certainly not a good sign. Do you have an idea what status -19 is about?

[arendtio]

I just took a look at the shellcode for dump_fw.bin and there it looks like mmc_enter_read_ram fails which is probably a bad sign, as if I remember your talk correctly, that is the key part to having access to the memory :-/

[oranav]

Yes, it means timeout. Seems that for some reason your chip isn't responding to the eMMC BootROM knock sequence :-( It may be bricked in a hardware sense, and it may not be the same chip I've researched. I'll try to think if there's anything else to do, but I don't have high expectations... Sorry.

[arendtio]

There is one thing I am wondering: If it is a timeout, is there some way to control the duration until the timeout occurs? As I wrote earlier, the broken phone takes about 40 seconds to boot into download mode, which I find kinda odd too and maybe it just takes a few seconds or so to acknowledge the knock sequence.

[oranav]

It should be possible by patching sboot's implementation. I actually did not implement the eMMC stack but instead just reused the sboot one (out of pure laziness :wink:). I will look into it in the next few days. But please be advised that if it takes about 40 seconds to boot into download mode, I suspect something else is going on (and not the usual eMMC brick bug I know about).

[arcaine2]

Semi worked on mine with I9300XXUGND5 sboot. I get:

./exploit/sboot_exploit.py --shellcode shellcode/write_fw.bin -e ../../VTU00M_rev_0xFC.bin 
[+] Shellcode started
[*] Found MMC device address
[*] Rebooted eMMC into bootrom mode
[*] Firmware upgrade [mode!]
[+] Got firmware from host

and apropriate messagess on phone screen but it hangs on "erasing all blocks on eMMC (low-level format)" for couple minutes now. Previous board i tried (that i bricked intentionally and booted from SD) didn't take that long.

It timed out eventually and with -v i see this, continuing:

[+] Got firmware from host
DEBUG:root:Read 42 bytes failed
DEBUG:root:Read 42 bytes failed
DEBUG:root:Read 42 bytes failed
DEBUG:root:Read 42 bytes failed
DEBUG:root:Read 42 bytes failed
DEBUG:root:Read 42 bytes failed
DEBUG:root:Read 42 bytes failed
DEBUG:root:Read 42 bytes failed
DEBUG:root:Read 42 bytes failed
DEBUG:root:Read 42 bytes failed
DEBUG:root:Read 42 bytes failed

I repeated the process, used different firmware file and eventually bricked the phone so it doesn't boot into download mode anymore. This allowed me to boot from SD with XXELLA sboot and use older toolbox to upgrade eMMC firmware with same firmware as in first try. Phone flashed fine and seems to be working when previously had "re-Partition operation failed".

What's still missing is an option to backup EFS before firmware update. EFS can be rebuilt but without proper certificate phone is doomed to have a patched modem to work properly.

[oranav]

@arcaine2 Did everything in the shellcode feel "slower" than usual when you tried with I9300XXUGND5? This could be explained if I misidentify the sleep() function (it's also done by a simple heuristic).

[arcaine2]

A bit, compared to earlier version that worked only with XXELLA but not by much. I also think that i bricked it by unplugging the phone while it was on "erasing all blocks". I may have not waited long enough second time when i saw more messages like "read 2 bytes failed" (this time 2 bytes instead of 42).

[oranav]

Unplugging during "Erasing all blocks" should generally be fine (take it with a grain of salt), since I should be able to recover every phone (as long as the hardware is still intact). Having said that, I'm not sure what is going on in your case, and it's hard to debug it remotely, so unless someone comes up with an idea, I'm not sure what to do...

[Toomoch]

If you have a s3 that doesn't work with the shellcode try my fork, i have a solution, I have a full website guide with windows instructions also. https://theandroid02.github.io/i9300-EMMC-GUIDE/