oranav/i9300_emmc_toolbox

Samsung Galaxy S3 GT-I9300 eMMC toolbox

i9300_emmc_toolbox's Issues

dump_fw_bootrom.bin runs into LIBUSB_ERROR_TIMEOUT [-7]

When I run sudo exploit/sboot_exploit.py --shellcode shellcode/dump_fw_bootrom.bin -o 0xf1.bin

I get the following output:

WARNING:root:Cannot write buffer
Traceback (most recent call last):
  File "exploit/sboot_exploit.py", line 364, in <module>
exploit.run_shellcode(args.shellcode.read())
  File "exploit/sboot_exploit.py", line 264, in run_shellcode
if not self.open_session():
  File "exploit/sboot_exploit.py", line 54, in open_session
self.write(BeginSessionPacket())
  File "exploit/sboot_exploit.py", line 28, in write
self._odin.write(buf)
  File "/Users/jakob/Downloads/i9300_emmc_toolbox-master/exploit/odin.py", line 59, in write
self.handle.bulkWrite(self.outEndpoint, buf, self.TIMEOUT)
  File "/usr/local/lib/python3.6/site-packages/usb1/__init__.py", line 1501, in bulkWrite
return self._bulkTransfer(endpoint, data, sizeof(data), timeout)
  File "/usr/local/lib/python3.6/site-packages/usb1/__init__.py", line 1480, in _bulkTransfer
self.__handle, endpoint, data, length, byref(transferred), timeout,
  File "/usr/local/lib/python3.6/site-packages/usb1/__init__.py", line 133, in mayRaiseUSBError
__raiseUSBError(value)
  File "/usr/local/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]

I tried extending the TIMEOUT in odin.py to 10000 but no change.
Since I work on macOS High Sierra and use homebrew I also tried the whole process on a Linux ThinkPad but run into the same problem.

Output from lsusb:

      Gadget Serial:
      Product ID: 0x685d
      Vendor ID: 0x04e8  (Samsung Electronics Co., Ltd.)
      Version: 2.1b
      Speed: Up to 480 Mb/sec
      Manufacturer: SAMSUNG
      Location ID: 0x14100000 / 2
      Current Available (mA): 500
      Current Required (mA): 50
      Extra Operating Current (mA): 0

Tried it on yet another Linux machine (ubuntu 16.04 LTS) but run into the same problem. Interestingly lsusb recognizes the device as Galaxy S2 in Download Mode despite same product and vendor ID and seemingly could not open it(?).

Output lsusb -v -d 04e8:685d

Bus 002 Device 006: ID 04e8:685d Samsung Electronics Co., Ltd GT-I9100 Phone [Galaxy S II] (Download mode)
Couldn't open device, some information will be missing
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            2 Communications
  bDeviceSubClass         2 Abstract (modem)
  bDeviceProtocol         0 None
  bMaxPacketSize0        64
  idVendor           0x04e8 Samsung Electronics Co., Ltd
  idProduct          0x685d GT-I9100 Phone [Galaxy S II] (Download mode)
  bcdDevice            2.1b
  iManufacturer           1 
  iProduct                2 
  iSerial                 0 
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           67
    bNumInterfaces          2
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0xc0
      Self Powered
    MaxPower               50mA
    Interface Descriptor:
    bLength                 9
  bDescriptorType         4
  bInterfaceNumber        0
  bAlternateSetting       0
  bNumEndpoints           1
  bInterfaceClass         2 Communications
  bInterfaceSubClass      2 Abstract (modem)
  bInterfaceProtocol      1 AT-commands (v.25ter)
  iInterface              3 
  CDC Header:
    bcdCDC               1.10
  CDC Call Management:
    bmCapabilities       0x00
    bDataInterface          1
  CDC ACM:
    bmCapabilities       0x00
  CDC Union:
    bMasterInterface        0
    bSlaveInterface         1 
  Endpoint Descriptor:
    bLength                 7
    bDescriptorType         5
    bEndpointAddress     0x83  EP 3 IN
    bmAttributes            3
      Transfer Type            Interrupt
      Synch Type               None
      Usage Type               Data
    wMaxPacketSize     0x0010  1x 16 bytes
    bInterval               9
Interface Descriptor:
  bLength                 9
  bDescriptorType         4
  bInterfaceNumber        1
  bAlternateSetting       0
  bNumEndpoints           2
  bInterfaceClass        10 CDC Data
  bInterfaceSubClass      0 Unused
  bInterfaceProtocol      0 
  iInterface              4 
  Endpoint Descriptor:
    bLength                 7
    bDescriptorType         5
    bEndpointAddress     0x81  EP 1 IN
    bmAttributes            2
      Transfer Type            Bulk
      Synch Type               None
      Usage Type               Data
    wMaxPacketSize     0x0200  1x 512 bytes
    bInterval               0
  Endpoint Descriptor:
    bLength                 7
    bDescriptorType         5
    bEndpointAddress     0x02  EP 2 OUT
    bmAttributes            2
      Transfer Type            Bulk
      Synch Type               None
      Usage Type               Data
    wMaxPacketSize     0x0200  1x 512 bytes
    bInterval               0

Porting to S3 AT&T SAMSUNG-SGH-I747

I did sent you a couple emails. In general I like to port to S3

Phone SPECS
Chipset Qualcomm MSM8960 Snapdragon S4 Plus
CPU Dual-core 1.5 GHz Krait
ro.product.model=SAMSUNG-SGH-I747
ro.product.device=d2att
ro.product.board=MSM8960

MMC model type is MAG4FB nor VZL00M
1|root@d2att:/ # cat /sys/devices/platform/msm_sdcc.1/mmc_host/mmc0/mmc0:0001/fwrev
dcc.1/mmc_host/mmc0/mmc0:0001/fwrev < 0x0
root@d2att:/ # cat /sys/devices/platform/msm_sdcc.1/mmc_host/mmc0/mmc0:0001/hwrev
cc.1/mmc_host/mmc0/mmc0:0001/hwrev < 0x0
root@d2att:/ # cat /sys/devices/platform/msm_sdcc.1/mmc_host/mmc0/mmc0:0001/name
cc.1/mmc_host/mmc0/mmc0:0001/name <MAG4FB
root@d2att:/ # cat /sys/devices/platform/msm_sdcc.1/mmc_host/mmc0/mmc0:0001/oemid
cc.1/mmc_host/mmc0/mmc0:0001/oemid

I understand that your procedure was designed for Exynos devices. But it does not hurt to learn from you.

What I had done:
*I do own both broken and working donor device.
*I had patched and build kernel with your mmc.patch. I place inside TWRP recovery, it boots but "cat /proc/devices | grep mmcram” produce no output.
*I had browse /dev, /dev/blocks, /proc & /sys looking for mmcram. I can supply any data you ask.
*I Even added extra lines to patch hopping mmcram show up:

• MMC_FIXUP("MAG4FB", CID_MANFID_SAMSUNG, CID_OEMID_ANY, add_quirk_mmc,
• MMC_QUIRK_MOVINAND_SECURE),

Here the specs for MAG4FB for your comparison.

KLMAG4FEJA-A001.zip
https://forum.xda-developers.com/attachment.php?attachmentid=3220445&d=1426867305
Can you give me Ideas? Thanks ahead.

Check that emmc chip is supported

This exploit only works with emmc chip VTU00M, which is the only one affected by the i9300 brick bug. If your device can boot into android you can check the chip model with

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

Otherwise here is some example code that searches for the chip name in the device memory, UNTESTED FOR VTU00M but works for my 016G92.

(Add this to sboot_exploit.py, run_shellcode, after "searching for arena pointer")

        # Somewhere near the arena there should be the emmc chip name
        logging.debug('Dumping some arena memory')
        end = arena + 0x20000
        chunk_size = 0x1f0
        _arena = b''

        for addr in range(arena, end, chunk_size):
            sz = min(chunk_size, end - addr)
            chunk = exploit.read_memory(addr - exploit.buf_ptr, sz)
            _arena += chunk

        target_chip_name = b"VTU00M"
        #target_chip_name = b"016G92"
        if target_chip_name in _arena:
            logging.debug('Ok, emmc chip supported')
        else:
            raise Exception('EMMC chip not supported')
            # or just warn and continue anyway?

Of course this check could also be added to the shellcode itself, perhaps to the mmc_dev_init function.

Porting the approach to a i9100?

I am not sure the github issue tracker is the correct place, but at least this gives the idea a prominent place for others to chime in.

Are you aware of any effort to port the "repair approach" to the Galaxy S2?

It seems the bug, or at least its effects, are almost exactly the same, and Samsungs "Fix", judging from personal experience and complaints in forums, has also led to freezes for this device. Interestingly, the only "fix" I find online is to disable MMC_CAP_ERASE in the kernel.

I have such a device with me here (which is "fully" bricked, i.e. also does not show sboot anymore),
but I'm not really up to replicate the full procedure (including re-creating the boot partition etc.)
and I also don't have good contacts to ask for the fixed firmware for the eMMC chip in this device.

For starters, I have downloaded a firmware release for S2, but sadly only found a boot.bin inside (not sboot.bin), so I am unsure whether this is correct.
Also, I'm not sure the hardkernel files can just be re-used for the device.
Any pointers / hints to related projects are much appreciated.

"Read 2 bytes failed" when tryng to dump 0xF1

Hello.
Im trying to revive a bricked i9300, but i cannot dump the eMMC firmware, it starts and shows text on the phone screen, but gets stuck saying "Read 2 bytes failed" (i have --verbose in the parameters).
The "hello world" works, also dumping the SBOOT. I have the UBUGNK1 bootloader.
I can describe more if someone can help me.

Missing header.bin for creation of recovery sd card

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!

valid link for the ROM I9300XXELLA_I9300OXAELLA_BTU.zip please

I9300 with Firmware XXUGNG3

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?

Makefile

Had to modify the Makefile slightly, to allow asm and C11 specific syntax:
CFLAGS += -fno-stack-protector -fno-common -fomit-frame-pointer -fPIE -static -O0 -std=gnu11

Just in case someone needs it also.

Any chance to recover data

Hi there,

is there any chance to get the data off the user partition once the EMMC chip hit that bug?
The instructions read like after applying the fix, the chip is logically blank. So even if I would flash an original os image, pictures and the like would still be inaccessible?

Hope I just didn't understand it right :)

Best
Martin

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

I am also not sure, if the github issue tracker is the correct place, [as said previously,] but maybe someone wants to join..

I managed to adapt the shellcode for my N7100 (XXDME6,sboot_sha256=0bd4729f53c4719109a35a2ad9ab310b3b8c0ce146cfaa39176fbcf0c9f542ab see this fork). (Again, thanks a lot Oranav for your research.)

So far, I could extract the emmc-firmware, but it seems, that this device has a different firmware size ( changed from 0x20000 to 0x1E000 ). To confirm this, I am currently searching for another test-device (maybe I will create a thread on xda as well or I can sell one with a display damage). If anyone has one, let me know..

n7105 sd card mode

Hi!

I have a Note II (N7105) that is currently only booting from microsd card as documented here:
https://forum.xda-developers.com/showthread.php?t=2586604
I've tried the XXAELLA firmware documented in this fork but haven't had much luck at getting it to respond,
is the rom from fapsis fork compatible with my device? It would be great to get it working somehow, I'm happy to do anything required to try to recover it. Currently it doesn't turn on at all without themicrosd card in with n7105_boot2.img flashed to it.

I have the sboot file from the device I managed to get VIA exploit/sboot_exploit.py --dump -o SBOOT before the emmc got formatted but other than that I wasn't able to dump anything else as it resulted in errors

I'm wondering if their would be a way to re-partition, format, and flash the emmc from this mode

Cheers,
Henry

SPI MMC CMD List / Reverse

hi oranav

really nice works you did here
can i contact you directly over mail or whatsapp?

i really interest at how you got all this CMD62,, and if it is possible to use it over MMI/SD SPI connection.

Compatibility with different s3 models

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.

Error when trying to dump 0xf7

https://imgur.com/a/ZnUSdoj

Need a Samsung S4 with the same problem?

hi, i just saw your presentation at 34C3and it's such a pity we didn't met. Because i got a bricket S4 which behaves exactly like a bricked S3: Weird OTA update, no bootloader on screen, the owner bricked it while I was talking to him. I got it now, if you want it, you can have it.

How to find the sboot version from a dump

I hope this helps somebody:

If you dump your sboot into a file and want to know its version you can just run

$ strings SBOOT | grep I9300

This should print a line like I9300XXUGNA5, which means the version is XXUGNA5, so this phone is not compatible with this exploit, which requires XXELLA.

(Of course you could also grep XXELLA but that won't tell you which version do you have)

Towards a 100% libre bootloader for Exynos4412 based Galaxy S3 and Note II devices

Hello Galaxy S3 hackers,

The GT-I9300 eMMC toolbox is an excellent hack, but it likely would have never been needed had there been a way, years ago, to compile and flash a fully working bootloader to the eMMC that respects the four software freedoms. The fact is though, that wasn't an option previously, so the eMMC toolbox was very much needed and I very much appreciate @oranav providing us all with this great piece of code. As it turns out, some recent work by Samsung, LineageOS, and Replicant has turned the dream of a libre bootloader into a potential reality. You can read about some of this work here: https://blog.forkwhiletrue.me/posts/u-boot-on-galaxy-s3/ and here: https://blog.forkwhiletrue.me/posts/an-almost-fully-libre-galaxy-s3/

If you'd rather jump right into the code, @fourkbomb's downstream u-boot git repo can be found here: https://github.com/fourkbomb/u-boot

Samsung's recently upstreamed u-boot git repo for a dev board that is fairly similar to the S3 and N2 can be found here: https://gitlab.denx.de/u-boot/u-boot/blob/master/arch/arm/dts/exynos4412-trats2.dts

We have progressed to the point where we can boot u-boot with only one 8KB proprietary binary is left: https://github.com/fourkbomb/u-boot/blob/midas-2019.04/p4412_s_fwbl1.bin

One of the exciting things about this is that we can currently boot these devices without running the proprietary TrustZone blobs and can instead run Android without TrustZone or one of the free software TrustZone alternatives. Additionally, we can now run other GNU+Linux distributions with an upstreamed kernel on these devices with relative ease.

At Replicant, we have been researching how to replace this last remaining BL1 proprietary blob with libre code. Some of @GNUtoo's notes related to this are here: https://redmine.replicant.us/projects/replicant/wiki/Exynos4Bootrom

Within the last couple of weeks we found what looks to be a free software implimentation of the Exynos4412 BL1 code here: https://github.com/xboot/xboot/tree/master/src/arch/arm32/mach-exynos4412 We have yet to be able to get it to boot, but have opened a ticket and are talking with the author of the code here: xboot/xboot#21

Much of the Exynos based S3 and N2 kernel is now in upstream, but this last proprietary bootloader blob is preventing us from being able to upstream all of our patches in u-boot and the kernel. Some of the issues and potential solutions are outlined here: https://redmine.replicant.us/projects/replicant/wiki/Upstream#PATCH-ARM-decompressor-Flush-tlb-before-swiching-domain-0-to-client-mode

If anyone is interested in joining us as we try to liberate this last remaining blob, please be in touch.