Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.
Sign upMissing header.bin for creation of recovery sd card #1
Comments
This comment has been minimized.
This comment has been minimized.
|
I think it should work if you use a 512 bytes file full of zeros ( Having said that, I'll upload the header.bin that I used in a few hours, so the script works out of the box. |
This comment has been minimized.
This comment has been minimized.
|
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
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? If it is that just leaves the header.bin for me. Do you have any other ideas? |
This comment has been minimized.
This comment has been minimized.
|
Yes, this is the correct sboot version. It seems that the exploit fails. |
This comment has been minimized.
This comment has been minimized.
|
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:
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. |
This comment has been minimized.
This comment has been minimized.
|
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:
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? |
This comment has been minimized.
This comment has been minimized.
|
Sorry for the delay.
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. |
This comment has been minimized.
This comment has been minimized.
|
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: (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.) |
This comment has been minimized.
This comment has been minimized.
|
I just added an option to dump sboot using the exploit in c996d61. Please use 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. |
This comment has been minimized.
This comment has been minimized.
|
Wow, thanks a lot for the quick commit! I just sent you an e-mail with more details. |
This comment has been minimized.
This comment has been minimized.
|
I would also be interested in how to change the addresses in the shellcode.h file. However both i9305 (one bricked, one working) i have do not have the XXELLA sboot version. (if that even exists for the i9305) sha256sums:
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:
|
This comment has been minimized.
This comment has been minimized.
|
@macearl Try to run |
This comment has been minimized.
This comment has been minimized.
|
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 |
This comment has been minimized.
This comment has been minimized.
|
Please try the latest version, it should work with your XXUGNG3 (if I recall correctly). |
This comment has been minimized.
This comment has been minimized.
|
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. |
This comment has been minimized.
This comment has been minimized.
|
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:
|
This comment has been minimized.
This comment has been minimized.
|
Okay, this seems related to the mmc_dev heuristic I added. I'll take a look later today. |
This comment has been minimized.
This comment has been minimized.
|
@dibas I just increased the sboot area that is being searched for mmc_dev. Please try it now. |
This comment has been minimized.
This comment has been minimized.
|
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. |
This comment has been minimized.
This comment has been minimized.
|
@dibas Yes, there was another problem with the heuristic. Try it with the latest version pushed now? |
This comment has been minimized.
This comment has been minimized.
|
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! |
This comment has been minimized.
This comment has been minimized.
|
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? |
This comment has been minimized.
This comment has been minimized.
|
This is actually great news. Your eMMC is back alive :-) |
This comment has been minimized.
This comment has been minimized.
|
Yeah, it's pretty amazing, thank you for your work again! |
This comment has been minimized.
This comment has been minimized.
|
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). |
This comment has been minimized.
This comment has been minimized.
|
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. :) |
This comment has been minimized.
This comment has been minimized.
|
Cool! Glad to hear |
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!