Compatibility with different s3 models #4

macearl · 2018-01-06T18:11:02Z

Would it be trivial to adapt this method to the i9305, iirc the only difference between the i9300 and i9305 was the modem and the additional ram.

Im not sure for example if I could just flash the i9300 sboot and firmware onto my i9305.

Any information on how to proceed would be appreciated.

oranav · 2018-01-07T23:45:34Z

@macearl The working device has XXSFQA1, and the bricked one has XXUENH1.
I will check if it's close enough and let you know later.

macearl · 2018-02-26T15:56:12Z

Did you have a chance to take a look at the files yet?

oranav · 2018-04-08T21:50:04Z

I did, however after struggling with multiple sboot versions I just decided to try writing a generic shellcode which doesn't rely on any sboot address. I just pushed it, please let me know if it worked for you.

macearl · 2018-04-09T16:29:30Z

I gave the new version a go but im not able to dump the firmware and the log does not contain any useful hints where it goes wrong. I dont have my working S3 at hand right now, i'll try dumping the firmware there later and then flashing that one to the bricked one.

# exploit/sboot_exploit.py --shellcode shellcode/dump_fw_bootrom.bin -o 0xf1.bin --verbose
DEBUG:root:Opening session
DEBUG:root:Session opened with result 100
[...]
DEBUG:root:Opening session
DEBUG:root:Session opened with result 100
DEBUG:root:Setting isdump=1
DEBUG:root:Reading buf part -1
DEBUG:root:First chunk header pointer: 0x44fefe90
DEBUG:root:Dumping some sboot code
DEBUG:root:Setting isdump=1
DEBUG:root:Reading buf part -37617
DEBUG:root:Setting isdump=1
DEBUG:root:Reading buf part -37616
[...]
DEBUG:root:Setting isdump=1
DEBUG:root:Reading buf part -37355
DEBUG:root:sleep() found at 0x43e03d70
DEBUG:root:display() found at 0x43e14fc0
DEBUG:root:clk1() found at 0x43e17220
DEBUG:root:clk2() found at 0x43e1724c
DEBUG:root:mmc_startup() found at 0x43e19bcc
DEBUG:root:Searching for arena ptr...
DEBUG:root:Setting isdump=1
DEBUG:root:Reading buf part -1
DEBUG:root:Setting isdump=1
DEBUG:root:Reading buf part -1966
DEBUG:root:Setting isdump=1
DEBUG:root:Reading buf part -31187
DEBUG:root:Arena is at 0x44111024
DEBUG:root:Setting isdump=1
DEBUG:root:Reading buf part -31187
DEBUG:root:Setting isdump=1
DEBUG:root:Reading buf part -31186
DEBUG:root:Function pointers are at offset 0x00000014
DEBUG:root:Setting isdump=0
DEBUG:root:Writing buf (16400 bytes)
DEBUG:root:Fake chunks are set up. Triggering absolute write...
DEBUG:root:Opening session
DEBUG:root:Session opened with result 100
DEBUG:root:Setting isdump=0
DEBUG:root:Writing buf (8064 bytes)
[...]
DEBUG:root:Opening session
DEBUG:root:Session opened with result 100
DEBUG:root:Setting isdump=0
DEBUG:root:Writing buf (8064 bytes)
DEBUG:root:Shellcode is running!
[+] Shellcode started
ERROR:root:Shellcode failed
ERROR:root:Status code: -1

For a short amount of time "Shellcode started" is readable on the screen in the top left corner and then the phone reboots again into download mode

When trying the helloworld shellcode the log looks similar up to the Shellcode is running!

...
DEBUG:root:Shellcode is running!
[+] Hello, world!
[*] sboot exploit by @oranav
INFO:root:Shellcode is done. Device should be restarting soon

And the output appears in the top left corner and after a second or so the device reboots into download mode

edit:
Trying to dump the Firmware with the working S3 results in:

[...]
DEBUG:root:Arena is at 0x44105028
DEBUG:root:Setting isdump=1
DEBUG:root:Reading buf part -33381
DEBUG:root:Function pointers are at offset 0x00000014
DEBUG:root:Setting isdump=0
DEBUG:root:Writing buf (16400 bytes)
Traceback (most recent call last):
  File "exploit/sboot_exploit.py", line 479, in <module>
    exploit.run_shellcode(args.shellcode.read())
  File "exploit/sboot_exploit.py", line 333, in run_shellcode
    self.write_buf(data)
  File "exploit/sboot_exploit.py", line 176, in write_buf
    self.write(data)
  File "exploit/sboot_exploit.py", line 39, in write
    self._odin.write(buf)
  File ".../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 · 2018-04-09T18:07:30Z

Yes, other people encounter it as well - it seems that my mmc_dev heuristic has false negatives. I'll take a look into it today.

oranav · 2018-04-10T06:57:57Z

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

macearl · 2018-04-10T16:16:49Z

I gave the bricked one a go, the output did not change it still fails with

ERROR:root:Shellcode failed
ERROR:root:Status code: -1

Again i dont have the working one on hand right now (that's the problem with working phones, they are usually used daily ;), i'll try to steal it away again later)

Is there anything i could try to debug this further?

oranav · 2018-04-10T20:56:40Z

@macearl I debugged it using a memory dump @arendtio provided. Pushed a fix, could you try it again?

macearl · 2018-04-11T19:06:23Z

I just gave it a go.

It looks like i have the same problem as arendtio in #9

[+] Shellcode started
[*] Found MMC device address
DEBUG:root:Read 2 bytes failed
[*] Rebooted eMMC into bootrom mode
DEBUG:root:Read 2 bytes failed
[*] Reading eMMC firmware to eMMC RAM
DEBUG:root:Read 2 bytes failed
[*] Enter eMMC RAM reading backdoor
[*] Reading eMMC firmware...
[+] Shellcode is done! Rebooting...
INFO:root:Shellcode is done. Device should be restarting soon

the dumped file has the sha256sum: 9a171aca6a556121461d09b76d3ba6da0d98e46dfb4e971ae9790fb61e4eb419
(so im guessing a different chip or some unknown firmware?)

trying to write fw:

# exploit/sboot_exploit.py --shellcode shellcode/write_fw.bin -e 0xf1.bin
[+] Shellcode started
[*] Found MMC device address
[*] Rebooted eMMC into bootrom mode
[*] Firmware upgrade mode!
[+] Got firmware from host
[*] Following process might take a few minutes
[*] Erasing all blocks on eMMC (low-level format)...
[*] Upgrading firmware, hold tight...
[*] Writing new firmware descriptor...
ERROR:root:Shellcode failed
ERROR:root:Status code: -19

After this the phone does not boot into download mode without a SD card anymore, but hey now im able to boot XXELLA

Just to make sure i tried the remaining steps and change_boot_partition_size does not throw any errors, however when im trying to restore sboot from the recovery sd (as mentioned in the xda thread) it is stuck on COPY BINARY TO EMMC...

edit:
just tried dumping the fw from the working S3 however that still fails:

#  exploit/sboot_exploit.py --shellcode shellcode/dump_fw_bootrom.bin -o working.bin --verbose
DEBUG:root:Opening session
DEBUG:root:Session opened with result 100
[...]
DEBUG:root:Setting isdump=1
DEBUG:root:Reading buf part -1
DEBUG:root:First chunk header pointer: 0x450efc90
DEBUG:root:Dumping some sboot code
DEBUG:root:Setting isdump=1
DEBUG:root:Reading buf part -39714
[...]
DEBUG:root:Setting isdump=1
DEBUG:root:Reading buf part -39451
DEBUG:root:sleep() found at 0x43e04cf4
DEBUG:root:display() found at 0x43e16e38
DEBUG:root:clk1() found at 0x43e190c0
DEBUG:root:clk2() found at 0x43e190d4
DEBUG:root:mmc_startup() found at 0x43e1b78c
DEBUG:root:Searching for arena ptr...
DEBUG:root:Setting isdump=1
DEBUG:root:Reading buf part -1
[...]
DEBUG:root:Arena is at 0x44105028
DEBUG:root:Setting isdump=1
DEBUG:root:Reading buf part -33381
DEBUG:root:Function pointers are at offset 0x00000014
DEBUG:root:Setting isdump=0
DEBUG:root:Writing buf (16400 bytes)
Traceback (most recent call last):
  File "exploit/sboot_exploit.py", line 479, in <module>
    exploit.run_shellcode(args.shellcode.read())
  File "exploit/sboot_exploit.py", line 333, in run_shellcode
    self.write_buf(data)
  File "exploit/sboot_exploit.py", line 176, in write_buf
    self.write(data)
  File "exploit/sboot_exploit.py", line 39, in write
    self._odin.write(buf)
  File ".../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 · 2018-04-11T20:04:11Z

@macearl I once encountered sboot being stuck on COPY BINARY TO EMMC... but after multiple times it worked. With bricked devices it should write FAILED afterwards. Can you try it a couple more times?

In any case, can you send me the eMMC firmware you dumped? And can you send the sboot dump from the working device?

macearl · 2018-04-11T20:21:31Z

I'll try it again a few times, how long should i wait for it to finish? I let it sit for ~20 minutes the first time. And the second attempt is running for roughly 5 minutes now.

Sure i'll send you the dump and the sboot of the working device (would be the same file i sent you last time or should i do a redump with the newest version?)

oranav · 2018-04-11T21:12:00Z

It should take about 10-20 seconds actually. Can you try running change_boot_partition_size again? if it works then the eMMC isn't bricked.
The old sboot dump is enough... I forgot about it.

macearl · 2018-04-12T15:31:48Z

Seems to still work, however it took a lot longer than before and the S3 is not automatically rebooting (but i think it didn't the first time)

DEBUG:root:Shellcode is running!
[+] Shellcode started
[*] Found MMC device address
DEBUG:root:ACK
DEBUG:root:ACK
DEBUG:root:ACK
DEBUG:root:Read 2 bytes failed
DEBUG:root:Read 2 bytes failed
DEBUG:root:Read 2 bytes failed
DEBUG:root:Read 2 bytes failed
DEBUG:root:Read 2 bytes failed
DEBUG:root:Read 2 bytes failed
DEBUG:root:Read 2 bytes failed
DEBUG:root:Read 2 bytes failed
DEBUG:root:Read 2 bytes failed
DEBUG:root:Read 2 bytes failed
DEBUG:root:Read 2 bytes failed
DEBUG:root:Read 2 bytes failed
DEBUG:root:Read 2 bytes failed
DEBUG:root:Read 2 bytes failed
DEBUG:root:Read 2 bytes failed
DEBUG:root:Read 2 bytes failed
DEBUG:root:Read 2 bytes failed
DEBUG:root:Read 2 bytes failed
DEBUG:root:Read 2 bytes failed
DEBUG:root:Read 2 bytes failed
DEBUG:root:Read 2 bytes failed
DEBUG:root:Read 2 bytes failed
DEBUG:root:Read 2 bytes failed
DEBUG:root:Read 2 bytes failed
DEBUG:root:Read 2 bytes failed
DEBUG:root:Read 2 bytes failed
DEBUG:root:Read 2 bytes failed
DEBUG:root:Read 2 bytes failed
DEBUG:root:Read 2 bytes failed
DEBUG:root:Read 2 bytes failed
DEBUG:root:Read 2 bytes failed
DEBUG:root:Read 2 bytes failed
DEBUG:root:Read 2 bytes failed
DEBUG:root:Read 2 bytes failed
DEBUG:root:Read 2 bytes failed
DEBUG:root:Read 2 bytes failed
DEBUG:root:Read 2 bytes failed
DEBUG:root:Read 2 bytes failed
DEBUG:root:Read 2 bytes failed
[+] Shellcode is done! Rebooting...
INFO:root:Shellcode is done. Device should be restarting soon

oranav · 2018-07-10T20:40:30Z

Looks like it's working though. Any luck using SD CARD mode?

macearl · 2018-07-11T00:24:02Z

I havent tried again since april, back then i was stuck on copy binary to emmc

now i just tried again and all the commands finish ok

exploit/sboot_exploit.py --shellcode shellcode/write_fw.bin -e 0xf1.bin
...
[*] Writing new firmware descriptor...
[+] Shellcode is done! Rebooting...

exploit/sboot_exploit.py --shellcode shellcode/change_boot_partition_size.bin     [0]
[+] Shellcode started
[*] Found MMC device address
[+] Shellcode is done! Rebooting...
INFO:root:Shellcode is done. Device should be restarting soon

However now no matter what i try im not able to enter SDCARD MODE with the recovery sd again (im not 100% sure but i think i actually did not have to short the resistor back in april, now im not able to boot into anything with the recovery sd card, and even when i try to short the mentioned resistor (actually r634 for my gt i9305) nothing happens.

For this to work would i actually need to short the resistor?

edit:
I reread the whole thread about the recovery SD Card and found this post: https://forum.xda-developers.com/showpost.php?p=47234165&postcount=220

which was how i entered the sdcard mode back in april i think (Vol UP + Vol DOWN + Home + Power), i was able to enter SDCARD mode again and it did copy the binary this time, i am now able to boot into download mode again with no sd card inserted, however i am not able to repartition (or flash) the device with odin or heimdall.

heimdall fails with:

Uploading PIT
ERROR: Failed to confirm end of PIT file transfer!
ERROR: PIT upload failed!

and odin with:

<ID:0/003> Set PIT file..
<ID:0/003> DO NOT TURN OFF TARGET!!
<ID:0/003> FAIL!
<ID:0/003> 
<ID:0/003> Re-Partition operation failed.

I was able to dump the now installed sboot, in case that could help in any way.

Also there are a couple of "GT-I9300" Strings in the dumped sboot, not sure if that affects anything given that my device is a GT-I9305, i also wasn't able to find any version number in it (only had a quick glance at it though, there are also some rather weird strings in there such as "Adobe Photoshop CS4 Windows"

markheng8 · 2019-06-25T13:32:36Z

I have an S3 LTE (GT-I9305) which mysteriously died a week ago. After much searching on YouTube, I chanced upon the talk Oranav gave and came here :)

Any update on whether a dead I9305 can be recovered, as previously asked by macearl in this thread?

Also, can someone be kind enough to post a zip for the shell cross-compiled bins? I'm on Windows and severely "handicapped" without those Linux tools :(

Managed to figure out after half a day of struggling with making an sboot SD card that I can't just store the sboot.bin file to the (formatted) SD but must save the binary image to it -- luckily I found the WinDiskImager utility to do this :)

I'm a noob at GitHub and very desperate in wanting to revive my S3. Please pardon my ignorance on how my request can be accommodated as such; would really appreciate some help with those shell bin files before I tear my hair out trying to cross-compile on Windows, and that's provided I can find the right tools for that!

Toomoch · 2019-06-26T08:22:49Z

Hi, I have a guide here that has precompiled binaries and is compatible with windows. BE CAREFUL AS IT IS FOR i9300. Don't flash anything yet, just try to dump your own firmware. https://github.com/theandroid02/i9300-EMMC-GUIDE

markheng8 · 2019-06-27T07:33:27Z

Thank you @theandroid02 for your help with the compiled bins... sure gives me hope on resurrecting my S3 :)

At first I downloaded the zip and those bins weren't there! Then I realized there had been 4 releases and I hadn't gotten the latest lol.

Went ahead to make the preparations you outlined and managed to execute the eMMC erase code to some extent, but the code kept stopping at the same point complaining about the USB1 thingy. Googled for help and found out the libusb-1.0.dll file was missing.

Found that dll online and saved it to 3 places: windows/system32; the folder where python.exe resides; and the project folder -- it wasn't clear where this dll should be placed so I put it in locations which were mentioned by others...

Now the execution went further, making things look exciting. Until it stopped at the odin.py part as shown below:

Traceback (most recent call last):
File "exploit/sboot_exploit.py", line 470, in
exploit = Exploit()
File "exploit/sboot_exploit.py", line 30, in init
self._odin.open()
File "E:\Fix Dead S3 June2019\i9300_emmc_toolbox-master\exploit\odin.py", line 38, in open
self.handle.claimInterface(self.interface)
AttributeError: 'NoneType' object has no attribute 'claimInterface'

Please help me check what has gone wrong -- it looks like we're close to getting this to work :) Much thanks in advance!

markheng8 · 2019-07-16T12:34:41Z

Still hopeful to get some help here, before I throw the S3 away for good :)

markheng8 · 2019-07-30T08:54:17Z

Hmm, doesn't look like anyone's looking at this thread anymore? Alright then, the S3 is going to the dumps :)

Toomoch · 2019-07-31T17:51:43Z

Hey, I might be able to help. Better email me at ggmaget@gmail.com or join this telegram group
@S3bois

macearl mentioned this issue Jan 7, 2018

Missing header.bin for creation of recovery sd card #1

Closed

arendtio mentioned this issue Apr 10, 2018

Port the approach to N7100 (Samsung Galaxy Note 2) - V3W00M - (VMX0-Controller) #7

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Compatibility with different s3 models #4

Compatibility with different s3 models #4

macearl commented Jan 6, 2018

oranav commented Jan 7, 2018

macearl commented Feb 26, 2018

oranav commented Apr 8, 2018

macearl commented Apr 9, 2018 •

edited

Loading

oranav commented Apr 9, 2018

oranav commented Apr 10, 2018

macearl commented Apr 10, 2018

oranav commented Apr 10, 2018

macearl commented Apr 11, 2018 •

edited

Loading

oranav commented Apr 11, 2018 •

edited

Loading

macearl commented Apr 11, 2018 •

edited

Loading

oranav commented Apr 11, 2018 •

edited

Loading

macearl commented Apr 12, 2018

oranav commented Jul 10, 2018

macearl commented Jul 11, 2018 •

edited

Loading

markheng8 commented Jun 25, 2019

Toomoch commented Jun 26, 2019

markheng8 commented Jun 27, 2019

markheng8 commented Jul 16, 2019

markheng8 commented Jul 30, 2019

Toomoch commented Jul 31, 2019

Compatibility with different s3 models #4

Compatibility with different s3 models #4

Comments

macearl commented Jan 6, 2018

oranav commented Jan 7, 2018

macearl commented Feb 26, 2018

oranav commented Apr 8, 2018

macearl commented Apr 9, 2018 • edited Loading

oranav commented Apr 9, 2018

oranav commented Apr 10, 2018

macearl commented Apr 10, 2018

oranav commented Apr 10, 2018

macearl commented Apr 11, 2018 • edited Loading

oranav commented Apr 11, 2018 • edited Loading

macearl commented Apr 11, 2018 • edited Loading

oranav commented Apr 11, 2018 • edited Loading

macearl commented Apr 12, 2018

oranav commented Jul 10, 2018

macearl commented Jul 11, 2018 • edited Loading

markheng8 commented Jun 25, 2019

Toomoch commented Jun 26, 2019

markheng8 commented Jun 27, 2019

markheng8 commented Jul 16, 2019

markheng8 commented Jul 30, 2019

Toomoch commented Jul 31, 2019

macearl commented Apr 9, 2018 •

edited

Loading

macearl commented Apr 11, 2018 •

edited

Loading

oranav commented Apr 11, 2018 •

edited

Loading

macearl commented Apr 11, 2018 •

edited

Loading

oranav commented Apr 11, 2018 •

edited

Loading

macearl commented Jul 11, 2018 •

edited

Loading