Missing header.bin for creation of recovery sd card

[dibas]

Hi! I already hit you up on Twitter, but I came to the conclusion that it probably makes more sense to talk about issues with the toolbox on the issue tracker here rather than on twitter in case anyone else stumbles upon it later on. I'm guessing header.bin contains some magic bytes? Would be great if you could clarify.

Thanks again for the project and the talk, you gave me hope for a phone that's been dead for years now!

[oranav]

I think it should work if you use a 512 bytes file full of zeros (dd if=/dev/zero of=header.bin bs=512 count=1). If I recall correctly, the Exynos 4412 boot ROM doesn't check anything in the header (it just skips the header).

Having said that, I'll upload the header.bin that I used in a few hours, so the script works out of the box.

[dibas]

Thanks for the response. I just tried dumping the bootrom with the sd card prepared with a 512-byte null header like you suggested. My guess is that it doesn't get loaded (I can't really tell because the device is still able to boot into download mode normally), because exploit/sboot_exploit.py shellcode/dump_fw_bootrom.bin -o 0xf1.bin --verbose gives me this result (only pasting the last few lines here):

DEBUG:root:Session opened with result 100 DEBUG:root:Setting isdump=0 DEBUG:root:Writing buf (8072 bytes) DEBUG:root:Read 8 bytes failed WARNING:root:Cannot write buffer DEBUG:root:Opening session Traceback (most recent call last): File "exploit/sboot_exploit.py", line 269, in if not e.open_session(): File "exploit/sboot_exploit.py", line 52, in open_session self.write(BeginSessionPacket()) File "exploit/sboot_exploit.py", line 26, in write self._odin.write(buf) File "/home/x/samsung/i9300_emmc_toolbox/exploit/odin.py", line 59, in write self.handle.bulkWrite(self.outEndpoint, buf, self.TIMEOUT) File "/usr/lib/python3/dist-packages/usb1/init.py", line 1438, in bulkWrite return self._bulkTransfer(endpoint, data, sizeof(data), timeout) File "/usr/lib/python3/dist-packages/usb1/init.py", line 1417, in _bulkTransfer self.handle, endpoint, data, length, byref(transferred), timeout, File "/usr/lib/python3/dist-packages/usb1/init.py", line 133, in mayRaiseUSBError raiseUSBError(value) File "/usr/lib/python3/dist-packages/usb1/init.py", line 125, in raiseUSBError raise __STATUS_TO_EXCEPTION_DICT.get(value, __USBError)(value) usb1.USBErrorTimeout: LIBUSB_ERROR_TIMEOUT [-7]

I'm assuming the exploit fails because the wrong sboot is loaded. I extracted the sboot.bin from the update you mentioned so I hope this is the correct image? SHA256(sboot.bin)= 47e0950cfac2e29556dfe6a6ce04d34731bcfb642ce9bc331aa99ddfa01aa694

If it is that just leaves the header.bin for me. Do you have any other ideas?

[oranav]

Yes, this is the correct sboot version. It seems that the exploit fails. Are you sure that you're booting from the external SD card and not an internal sboot that is saved on the eMMC's boot partition? If you see some noise on the screen (e.g. white "stripes") it's an indicator that you indeed boot from external SD. Can you also post the full dump with --verbose?

[dibas]

I do see a completely bugged screen with white stripes and everything, but that also happens when I boot into download mode without an sd card, so I don't know if it's actually booting from sd card. Is there any way to tell?

The whole dump of the session with verbose on

Could you tell me what the SHA256 hash of the complete recovery image should be? (Still looking for error possibilities on my end) For me it is:

SHA256(recovery_sdcard.bin)= e4aa80dd4792cb83283a9c17ddc032a0517d23a9d61c6d010ef1bb66ef336d85

Thanks again for looking into this. Would be great if I get this running!

EDIT: I am 99% sure that for some reason the device does not boot from sd card because the output log is exactly the same when disconnecting the sd card. The problem seems to be there.

[dibas]

So, after some more research I did today, is it possible that the Exynos CPU does not even look for anything on the SD card as long as the download mode on the eMMC is not bricked? That might explain why I can't get it working. This blog post mentions the following:

The Galaxy S3 tries to boot from eMMC (internal memory) first and if that fails, it attempts to boot from other possible boot devices like the SD card. In order to force booting from SD card, Adam corrupted the data transfer between CPU and eMMC by attaching a thin wire to one of the data lines that shortens the data line.

Shortening a small resistor on the board is mentioned as an alternative way to enable SD mode. Did you manage to do a successful recovery on a device with working download mode?

EDIT: After reading through your readme again, I think I got it wrong the first time and the recovery SD card obviously only works when the eMMC's sboot is broken, so sorry for the misunderstanding.

I assume that means I need to adapt shellcode.h offsets to the sboot version that's installed on my device. Is there any way to find out which version of sboot is installed on the eMMC of the device?

[oranav]

Sorry for the delay.

I assume that means I need to adapt shellcode.h offsets to the sboot version that's installed on my device. Is there any way to find out which version of sboot is installed on the eMMC of the device?

Yes, I once encountered this problem myself. I will upload in the next few days an exploit version which dumps sboot from the eMMC using the read vulnerability.

[dibas]

Ah, it's alright, thanks for your response! I'm looking forward to the dumping method!

I already tried reversing the XXELLA sboot.bin to replicate the way you found the offsets in case I get my hands on the sboot version installed on my device. Unfortunately I did not get very far thanks to my pretty limited knowledge of ARM and especially because of the odd binary format. It would be great if you could point me to a rough direction on how to find the offsets after I have my sboot dump.

Here's what I have for now: ARM Little-Endian First segment starting at address: 0x6000 (-> 0x43E00000 as base starting from here)

(Fun fact: I also tried shortening the previously mentioned resistor to force the device to boot the prepared SD card payload, but the device still tried to boot into the broken eMMC. Apparently a USB JIG is also required. I was thinking of retrying it but if I get the sboot exploit working it's clearly the better option, so it's on hold for now.)

[oranav]

I just added an option to dump sboot using the exploit in c996d61e70c254106c61b76e4acb971bfb452739. Please use exploit/sboot_exploit.py --dump -o sboot.bin. As for finding the correct function addresses, my best solution right now is to manually reverse the firmware (while comparing to XXELLA -- since the names in shellcode.h are my own, thus these functions are only identifiable by their XXELLA addresses). I might add some heuristic for automatically finding these addresses in the future but unfortunately it must be done manually right now.

If you'd like, you can send me your sboot.bin and I'll adapt a shellcode.h for you. You can find my contact info in my website.

[dibas]

Wow, thanks a lot for the quick commit! I just sent you an e-mail with more details.

[macearl]

I would also be interested in how to change the addresses in the shellcode.h file. As i mentioned in https://github.com/oranav/i9300_emmc_toolbox/issues/4 im trying to resurrect a dead i9305. (not sure if this is at all possible with this toolbox, i just thought id give it a shot)

However both i9305 (one bricked, one working) i have do not have the XXELLA sboot version. (if that even exists for the i9305)

sha256sums:

bricked: 6a504d3e7e7ca9c11d74656b528462debe7f9b66f26ea0b79d9420641f82f97c
working: 1b467f486ff51d94278dbb5f82e21371999d5484ae3b1b27d58ddbd6b7c19385

i dont know how to extract the sboot version from them. (The working one should have I9305XXSFQA5 installed)

I tried flashing the XXELLA sboot onto the bricked i9305 as i dont really have anything to loose with that one but im not able to flash it because heimdall always fails to download the PIT File from the Device or is not able to verify the upload of the local PIT File if i tell it to repartition the device.

As i dont want to risk bricking the running i9305 i did not try to flash the XXELLA sboot there.

My error also looks a bit shorter but it does end the same:

00:24 $  exploit/sboot_exploit.py --shellcode shellcode/dump_fw_bootrom.bin -o 0xf1.bin --verbose
Traceback (most recent call last):
  File "exploit/sboot_exploit.py", line 355, in <module>
    exploit = Exploit()
  File "exploit/sboot_exploit.py", line 20, in __init__
    self._odin.open()
  File "/home/macearl/Git/i9300_emmc_toolbox/exploit/odin.py", line 39, in open
    self.write(b'ODIN')
  File "/home/macearl/Git/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]

[oranav]

@macearl Try to run exploit/sboot_exploit.py --dump -o sboot.bin. Does it work? If so, the vulnerability is there, and there's at least some hope. Send me the file using my contact info. I don't have an I9305 to experiment with, but if it's close enough it might work.

[macearl]

yes i was able to dump booth sboot versions (thats how i got the sha sums ;) )

I'll be sure to send you an email

[oranav]

Please try the latest version, it should work with your XXUGNG3 (if I recall correctly).

[dibas]

Hi! Great to hear from you again! I just tried the helloworld payload and it worked, so thank you very much for staying on this! I'm going to try the recovery process now and will report back on the results.

[dibas]

Update: While the hello world payload works just fine, the write_fw payload apparently fails on my device. I attached the verbose log here. As you can see the shellcode's actually running on the device, so it's a new problem unrelated to the exploit itself and probably something with the shellcode that's being run. After running the exploit the device just restarts into an unusable download mode without any labels. That also happens when running the hello world payload, so I think it is expected behaviour.

EDIT: Just for achival purposes here are the important lines from the pastebin log:

DEBUG:root:Writing buf (8064 bytes) DEBUG:root:Shellcode is running! [+] Shellcode started ERROR:root:Shellcode failed ERROR:root:Status code: -1 Exception ignored in: <bound method Odin.del of <odin.Odin object at 0x7f24c5f24a90>> Traceback (most recent call last): File "/home/dibas/samsung/new_bootless/i9300_emmc_toolbox/exploit/odin.py", line 26, in del File "/home/dibas/samsung/new_bootless/i9300_emmc_toolbox/exploit/odin.py", line 53, in close File "/usr/lib/python3/dist-packages/usb1/init.py", line 2128, in close File "/usr/lib/python3.5/threading.py", line 362, in notify_all File "/usr/lib/python3.5/threading.py", line 345, in notify TypeError: 'NoneType' object is not callable Segmentation fault

[oranav]

Okay, this seems related to the mmc_dev heuristic I added. I'll take a look later today.

[oranav]

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

[dibas]

Thanks for the update! I recompiled the shellcodes with the new commit, but I'm still getting the same error as attached above. Still seems to be something with the mmc_dev heuristic as there's no other log line being printed.

[oranav]

@dibas Yes, there was another problem with the heuristic. Try it with the latest version pushed now?

[dibas]

I can confirm write_fw.bin just ran through without any problems! Nice work!! Didn't see any errors in the output and it finished with a "shellcode is done, rebooting" message. I will now attempt the sd card recovery. Will keep you updated on the results!

[dibas]

Good news first: Resizing and downloading the bootloader from sd card worked just fine! I am not really sure how to proceed from here though. I just tried flashing a i9300 pit file (I still had it on my hard drive, not sure where it came from) using heimdall in combination with TWRP-Recovery and heimdall just reported a failed PIT upload. Do the stock firmware files contain a PIT?

[oranav]

This is actually great news. Your eMMC is back alive :-) I couldn't flash the PIT with Heimdall as well; I resorted to a Windows VM and Odin and it worked. PIT can be found here.

[dibas]

Yeah, it's pretty amazing, thank you for your work again! Thanks for telling me, flashing with Odin worked for me, too. I also flashed a stock firmware I still had on my drive, and lo and behold: the Samsung i9300 logo popped up, a sound played and it changed to the glowing Samsung logo. Not much happened since then, though. I assume the files I flashed are incomplete, I will try to get my hands on a complete stock rom and reflash tomorrow, but I am pretty sure we are on a very good way already!

[oranav]

Did you format all the partitions correctly? Install some recovery (e.g. TWRP) and mkfs everything. This includes /data, /cache, efs and /sdcard (maybe I forgot one or two more). Your eMMC is pretty much all FFs so no partition is valid (except the ones you flashed, i.e. system, boot, recovery and modem).

[dibas]

Success!!! Installing TWRP worked, but after wiping pretty much everything I still could not get neither the stock rom nor Lineage OS past the boot animation. TWRP kept complaining about /efs obviously not being mountable for the reasons you mentioned, but I luckily still had a reaally old nandroid backup of this device including all partitions. I just restored all of them and well, the image speaks for itself I hope. What a journey! Again, thank you very much for making this available and staying on it after all this time! I still can't quite believe it, but I guess I now have another development device again. :)

[oranav]

Cool! Glad to hear :smiley: Now let's just hope that the generic implementation works on every sboot version :-)