dump_fw_bootrom.bin runs into LIBUSB_ERROR_TIMEOUT [-7]

DC4JG commented 6 years ago

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

DC4JG commented 6 years ago

Got some more informations due to --verbose flag and maybe part-success.

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

8x

DEBUG:root:Opening session
DEBUG:root:Session opened with result 100

then

DEBUG:root:Setting isdump=1
DEBUG:root:Reading buf part -1
DEBUG:root:First chunk header pointer: 0x44eefe90
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 -29425
DEBUG:root:Arena is at 0x440e8090
DEBUG:root:Setting isdump=1
DEBUG:root:Reading buf part -29425
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...

122x

DEBUG:root:Opening session
DEBUG:root:Session opened with result 100
DEBUG:root:Setting isdump=0
DEBUG:root:Writing buf (8072 bytes)

then

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 366, in <module>
exploit.run_shellcode(args.shellcode.read())
File "exploit/sboot_exploit.py", line 266, in run_shellcode
if not self.open_session():
File "exploit/sboot_exploit.py", line 56, in open_session
self.write(BeginSessionPacket())
File "exploit/sboot_exploit.py", line 28, in write
self._odin.write(buf)
File "/home/akafunk/i9300_emmc_toolbox/exploit/odin.py", line 59, in write
self.handle.bulkWrite(self.outEndpoint, buf, self.TIMEOUT)
File "/home/akafunk/.local/lib/python3.5/site-packages/usb1/__init__.py", line 1501, in bulkWrite
return self._bulkTransfer(endpoint, data, sizeof(data), timeout)
File "/home/akafunk/.local/lib/python3.5/site-packages/usb1/__init__.py", line 1480, in _bulkTransfer
self.__handle, endpoint, data, length, byref(transferred), timeout,
File "/home/akafunk/.local/lib/python3.5/site-packages/usb1/__init__.py", line 133, in mayRaiseUSBError
__raiseUSBError(value)
File "/home/akafunk/.local/lib/python3.5/site-packages/usb1/__init__.py", line 125, in raiseUSBError
raise __STATUS_TO_EXCEPTION_DICT.get(value, __USBError)(value)
usb1.USBErrorTimeout: LIBUSB_ERROR_TIMEOUT [-7]

Some more observations:

my device is with and withouth prepared microSD card visible via lsusb
WARNING:root:Cannot write buffer does not always occur
extending the Timeout may result in more calls
DEBUG: Messages only show up on first run after device reboot and connect to computer

Another thing I did but have no idea if it has an impact: I added a file /etc/udev/rules.d/42-galaxys3.rules with the following content: SUBSYSTEM=="usb",ENV{DEVTYPE}=="usb_device",SYSFS{idVendor}=="04e8",SYSFS{idProduct}=="685d",MODE="0666" (Googled around and stumbled upon https://ubuntuforums.org/showthread.php?t=901891 and decided to give it a try since I am stuck)

macearl commented 6 years ago

Are you sure you boot into the right sboot? If the one on your phone is still functionally it seems there is no way to boot from a sd card

Try: exploit/sboot_exploit.py --dump -o sboot.bin and check the sha256sum of the dumped sboot the needed XXELLA should have 47e0950cfac2e29556dfe6a6ce04d34731bcfb642ce9bc331aa99ddfa01aa694 sboot.bin

DC4JG commented 6 years ago

Not booting from microSD sounds like a good explanation and gives me new ideas to poke around. Great, thanks a lot! :) The problem with sboot dumping is that i get another result each time:

original one from first try ever

d46204e89db359c6f7fc035aa6d3bd6f1911189b1a98ebff5a8eb0546e66e170  SBOOT

other dumps from just now

a15dd543b58d3084b38007c62228fc58d4d2d6436f025591aa605e581d4f55b6  sboot.bin
0b332a0b6948d16dd8e336298f2636b9537677efec362929e03e505acf37256f  sboot2.bin
8aa1eb264bf17dce6f2e279ed03974be057e3ccfe7b75c5e76a897d0cadff63f  sboot3.bin

And yes, the command yields the correct hash for the downloaded XXELLA sboot.bin ... so Apple ain't broke shasum

Now onwards to a closer look into #1 and more experiments while singing Funkytown with my eMMC \(^-^)/

oranav commented 6 years ago

This is due to the fact that I dump a part of the data segment as well. You'll never have matching hashes. Try running strings and grep for I9300, you'll see something like I9300XXELLA.

DC4JG commented 6 years ago

This explains a lot, things start to make sense now :]

strings did not gave me XXELLA but i found I9300XXUGNH4 (german 4.3 Jelly Bean firmware from 2014-08-18) finally i know which version to deal with, hooray!

Thus i need to change the addresses in shellcode/shellcode.h for the exploit to work or force my device into booting from microSD despite seemingly working sboot?

Also if i want to verify my sboot.bin i first need to split it from the data part of the dump before shasum-ing it?

oranav commented 6 years ago

Sorry for being absent for the past time! I just pushed a new version which should theoretically work on any sboot version. Please try it with XXUGNH4 and report.

DC4JG commented 6 years ago

sudo exploit/sboot_exploit.py --shellcode shellcode/dump_fw_bootrom.bin -o 0xf1.bin
[+] Shellcode started
[*] Found MMC device address
[*] Rebooted eMMC into bootrom mode
[*] Reading eMMC firmware to eMMC RAM
[*] Enter eMMC RAM reading backdoor
[*] Reading eMMC firmware...
[+] Shellcode is done! Rebooting...
INFO:root:Shellcode is done. Device should be restarting soon

DC4JG commented 6 years ago

New roadblock:

sudo ./exploit/sboot_exploit.py --shellcode shellcode/change_boot_partition_size.bin
[+] Shellcode started
[*] Found MMC device address
...
DEBUG:root:sleep() found at 0x43e03aa4
DEBUG:root:display() found at 0x43e11bac
DEBUG:root:clk1() found at 0x43e13e0c
DEBUG:root:clk2() found at 0x43e13e38
DEBUG:root:mmc_startup() found at 0x43e167b8
DEBUG:root:Searching for arena ptr...
...
DEBUG:root:Arena is at 0x440e8090
...
DEBUG:root:Function pointers are at offset 0x00000014
...
DEBUG:root:Fake chunks are set up. Triggering absolute write...
...
DEBUG:root:Shellcode is running!
ERROR:root:Shellcode failed
ERROR:root:Status code: -19

Maybe helpful information: I have a 32GB model and never rooted it

oranav commented 6 years ago

@1342 Did you write firmware 0xf7? Also, if you have never rooted it I'm guessing you don't have an EFS dump, and sadly this method will erase your device completely, therefore be advised that your baseband information (e.g. IMEI) will be erased.

DC4JG commented 6 years ago

I don't have 0xf7 so i wrote the 0xf1 i got from the device. I know about the EFS problem but since the device is considered 'dead' i appreciate a working device without baseband :)

As far as i understand the procedure i am now stuck at step 5.

DC4JG commented 6 years ago

Retried with 0xF7.bin

booted into download mode
run step 3
device rebooted and was still visible under lsusb
run step 5 and got the same error code -19

oranav / i9300_emmc_toolbox

dump_fw_bootrom.bin runs into LIBUSB_ERROR_TIMEOUT [-7] #6