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

[fapsi]

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..

[fapsi]

Hey, I did some further research, bought some further devices, but currently I'am stuck here..

Whatsoever, what I found out: There are different emmcs in the N7100 out there (this could also relate to the i9300 and i9500 from my research):

1. VTU00M (VHX0-Controller)
2. V3W00M (VMX0-Controller)

To find out, just look at the controller-description at the beginning of the firmwares. ~ (0x2009C)

For the V3W00M I dumped only one Firmware "FwRev:0x00; Date 05/1997". And with this controller I've got one defect device (SDS, sample1) and one working device (sample2). I compared the firmwares and interestingly only the bytes from 20000-3C000 are invariable over the different devices. If I dump the firmware from one device the bytes from 20000-3E000 stay fixed independent of reboots.

Then I wanted to try the exploit and rewrite the firmware. (Unfortunately I choose the sample2..) But anyway I managed to wipe the firmware and write the firmware descriptor (I adapted the fw-descriptor and the address based on my fw-dumps). But thereafter the write command fails (cmdidx = 25 in the firmware upgrade mode). Additionaly I'm not really sure about the firmware descriptor. So if somebody could help me out here, I would be very glad. Is the manual firmware descriptor write really needed? (It seems the cmdidx = 28 does the job). And why I cannot write the new firmware? It seems, that the other commands working as suspected.

(By the way, 1) here is a method for killing sboot, even on KNOX devices (https://forum.xda-developers.com/showthread.php?t=2028469&page=6). This could also be an alternative for I9300 with a wrong sboot installed. Of course hereto one needs a customized, running kernel and root for accessing mmcblk0boot0(https://forum.xda-developers.com/galaxy-note-2/development/rom-t3746481 for n7100). And be sure to make a backup of (EFS, etc..)!! 2) If I magically could get an VTU 0xF7 it would also be really helpful)

[arcaine2]

This could also be an alternative for I9300 with a wrong sboot installed.

If your device is working you can just flash XXELLA sboot with Odin and it'll be enough to make exploit working. If you, for some reason corrupt sboot that way phone will still boot from SD card and if not, testpoint can be used. If eMMC is already bad and you stucked only with working sboot but can't flash anything then adapting shellcode might be the only option. I'm actually looking for some tutorial on how to do that. I do have a board with I9300XXUGND5 in such condidion, forcing booting from SD doesn't help and exploit doesn't work.

If I magically could get an VTU 0xF7 it would also be really helpful

I can provide you with 0xFC (VTU00M_rev_0xFC[164F2643]_fw(00040000-00080000).bin) firmware, which is the last one available as far as i know. Firmware was dumped directly from desoldered eMMC and tested on another board using method described here.

[fapsi]

If your device is working you can just flash XXELLA sboot with Odin and it'll be enough to make exploit working. If you, for some reason corrupt sboot that way phone will still boot from SD card and if not, testpoint can be used. If eMMC is already bad and you stucked only with working sboot but can't flash anything then adapting shellcode might be the only option.

Ah sorry, I was imprecise on this point. In case of the N7100 there is a KNOX installed. So firmwares above (and included) 4.3 prevent downgrading the sboot (don't remember the error code). With the method I described above you can go around this issue. I was not aware, that the KNOX doesn't exist for the I9300 firmwares... Anyway yes for your problem this doesn't help.

I'm actually looking for some tutorial on how to do that. I do have a board with I9300XXUGND5 in such condidion, forcing booting from SD doesn't help and exploit doesn't work.

I adapted the shellcode for the N7100XXDME6 firmware (4.1.2, see the above link to my fork) which was relevantly similar to XXELLA. As far as I could see the firmware you need (4.3) changed a lot compared to the 4.1.2 at least for the N7100, maybe when I have time I could also have a look, but there are for sure people around here, who are much more competent :D

But here some tips from my experience: I used the Hopper Disassembler v4 (freeware, 30min opened restriction), but there are for sure better options out there (e.g. IDAPro, Retargetable Decompiler). Then I opened the two sboots (base-address: 0x43E00000; entry-point: 0x0; file-offset: 0x6000; armv7 little-endian) and tried to identify the similar functions (was not that hard). Then the tricky part was to identify "mmc_host" and "mmc_dev", which are lying somewhere behind sboot, so you would need to obtain a dump for this sboot including the data behind (see also comments). Another option would be to reverse engineer "s5c_mshc_init" or "emmc_poweron", but I wasn't really able to find the concrete instantiation of mmc_dev/host, altough there are some pointers in this functions in their direction..

[Tostis]

On my I9300 is installed XXUGND5 so i would like to port shellcode to my firmware version. I tried to find similar functions using Hopper by i couldn't manage it. I hope someone can teach me how to port shellcode or give me a dumped 0xF7 firmware.

[arcaine2]

Have you tried current version of shellcode? I noticed there were some changes made to "heuristic find mmc_dev address". I haven't got much time to try this myself just yet.

[Tostis]

It does not work. Here is the stacktrace: WARNING:root:Cannot write buffer Traceback (most recent call last): File "exploit/sboot_exploit.py", line 375, in exploit.run_shellcode(args.shellcode.read()) File "exploit/sboot_exploit.py", line 275, in run_shellcode if not self.open_session(): File "exploit/sboot_exploit.py", line 57, in open_session self.write(BeginSessionPacket()) File "exploit/sboot_exploit.py", line 31, in write self._odin.write(buf) File "/home/tostis/Desktop/SIII/i9300_emmc_toolbox-master/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]

[arendtio]

@Tostis during the last 3 hours I played around with this stuff and I saw a lot of LIBUSB_ERROR_TIMEOUT errors too. Basically, the only command that worked was --dump. But as my firmware version is XXUGNG3 that wasn't very surprising.

Sadly I wasn't able to find the required zip file. The one closest was hosted on Google Drive https://docs.google.com/file/d/0B6lFDKRNiZ4jUUtpUHluNHpOc0k/edit but the sha256 doesn't match any from the readme :-/

[Tostis]

I already have I9300XXELLA_I9300OXAELLA_BTU firmware but it can't be flashed from odin in download mode. I am missing something? I think sha256 is referred to firmware dump and that's what i need to restore my device.

[arcaine2]

In general, for exploit to work you need XXELLA boot (it's an old boootloader from 4.1.2 based firmware). This will work if you still have a working phone and want to upgrade your eMMC firmware to prevent bug from happening as you can then just flash it and shellcode will work. If you already have a broken device that is yet still able to enter download mode but was on more recent firmware (4.3 based most likely) then often you're no longer able to flash anything, including older bootloader which is why shellcode would need to be adapted for your bootloader. If you have a bricked device that no longer enters download mode, then you should be able to boot from microSD with old, exploitable bootloader, use the shellcode to upgrade eMMC firmware and restore the device.

You can still try to prepare yourself a microSD with older bootloader and forcing to boot from it by shorting resistor on the PCB. Maybe in your case this will work, on mine it did not when bootloader was still alive.

[Tostis]

So the only viable solution is to boot from microsd. I've found the resistor to short circuit but it's too little... That's too far for me. I think i'll throw it away.

[arcaine2]

You don't have to remove the screen from the frame. Display flex is long enough for this to work. It's a bit tricky, but can be done with screen still connected. In general, you don't need display attached at all but then it's hard to say if you succeed to boot from SD card or not.

[oranav]

@Tostis, I just pushed a new version which theoretically removes all dependencies on XXELLA. Please try it and let me know if that works for you.

@fapsi, Thanks for the great work! Could you send me the V3W00M firmware? I'll look into the MMC_WRITE_MULTIPLE_BLOCK (25) issue. From my experience, the firmware descriptor had to be updated since I erase the whole chip right before, and otherwise firmware won't boot (it actually tells the boot ROM where to load the firmware from logically IIRC). Note that I write it to the eMMC's RAM right before, and I rely on it being at 0x60194. This could be different for V3W00M and it might explain why the write operation fails.

[Tostis]

@oranav, thanks for your effort. I've just tried your last code but it doesn't work. It prints "Shellcode started" on the phone then restarts in download mode. The shell says: exploit/sboot_exploit.py --shellcode shellcode/dump_fw_bootrom.bin -o 0xf1.bin [+] Shellcode started ERROR:root:Shellcode failed ERROR:root:Status code: -1

Is there an option to increase log verbosity?

[arendtio]

@Tostis AFAIK the --verbose flags only increases the verbosity of the python part (not the shellcode).

So far this looks very similar to what we have in #4 and #9.

[oranav]

@Tostis What about now? I refined the mmc_dev heuristic using a dump @arendtio provided.

[fapsi]

@oranav Thanks so much for your help!, that makes sense. I was already wondering about that part, but I wasn't able to find out the way to determine that location. Additionally, it seems that writing the descriptor also failed at some locations, but I'am not sure about that.. I'll soon send you an email with the V3W00M-fw. Also I will test the heuristics for the N7100-sboot and report the results.

[Tostis]

Last code version fails printing:

[+] Shellcode started [*] Found MMC device address ERROR:root:Shellcode failed ERROR:root:Status code: -19

EDIT: Sorry, it worked running with root privileges!

[oranav]

@Tostis Worked as in the whole process worked?

[Tostis]

Firmware dump and low level format worked well. Now I'm stuck because i can't boot in dowload mode using microsd.

[raipat]

Thanks for sharing this awesome progress on the Note 2! I would like to dump the content of a damaged Note 2 eMMC instead of wiping it. Do you think that is doable? I have a working test device and the broken one.

[fapsi]

@Tostis Now you can follow steps 5-7 in the instruction. @raipat Since I've done that I would say yes, but it depends upon whats corrupt with your emmc-chip. If it's a meta-data corruption I would say yes. The instructions are the same as for the i9300 (refer step Obtaining a firmware dump -> Obtaining the firmware from your bricked device (0xF1)) Unfortunatly I didn't test the heuristics yet for the n7100 fw XXDME6 ( maybe next weekend). Generally you should never wipe anything before backing up, also because there are different emmcs in the devices. @oranav did you receive my email with the dumps? Thanks in advance and no hurry!

[arcaine2]

Heuristics doesn't seem to work for N7100XXDME6. I have a device that doesn't boot at all without microSD. I flashed XXDME6 to SD so the phone enters download mode but with current version of shellcode, i only get "Exception: Could not find mmc_startup() in this boot". Nothing works really works, dumping eMMC firmware, helloworld etc. With verbose i see that it's finding sleep(), display(), clk1() and clk2() but fails on mmc_startup(). Dumping sboot still works.

I tried your version of shellcode adapted to N7100XXDME6 and this one works. It seems this device also has a VMX0 controller inside. Most likely KMV3W000LM-B310 chip as only this VTU00M and a Toshiba chip were used in N7100. Toshiba is a no go, VTU00M uses different controller. Writing firmware with your version of shellcode doesn't work. Last message is "rebooted eMMC into bootrom mode", then shellcode fails and phone reboot into download mode with shellcode texts piling up on the screen.

Funny thing is, with XXDME6 bootloader in microSD i can flash everything but sboot.bin and possibly tz.bin (it fails) but with the most current bootloader on microSD (from 4.4, with Knox) i always get re-partition failed no matter what i try to write with Odin.

[oranav]

Did you manage to dump the eMMC firmware? If this is the case, I can take a look to see if anything interesting is going on

[fapsi]

Hi oranav, I sent you an email with the dump.

[fapsi]

@oranav how did you determine the fw-descriptor address? I think for the N7100 it should be 0x60AB8 with a slightly modified descriptor: (see https://github.com/fapsi/emmc_toolbox/blob/master/shellcode/write_fw.c ). But it don't work; (I did send you the firmware(0x00000-0x20000) and (0x40000-0x80000) but I am not sure if you receive my emails.) Could the data parameter in cmdidx 25 be a problem? Maybe the format for mmc_data struct has changed? Very strange is that the same Problem occurs with a VTU00M in the N7100. So it must be a change in the ROM part(0x00000-0x20000) regarding fw-descriptors, other preconditions or calling the cmd25 after the emmc-format. Unfortunately I am not as good in decompiling. Anyway could send someone the 0x00000-0x20000 part of an i9300(VTU00M)? Thanks in advance!

[raipat]

I'd like to bump this issue. Has there been some update or progress since 2018?