Hi XDA,
so basically i bought a Velocity Cruz T301 recently and followed the known procedures for rooting, flashing ClockworkMod Recovery and custom rom (SJHill Rom v0.3).
before the full brick my device was at ClockworkMod 5 and rooted with SJHill Rom v0.3.
i installed CWM by flashing the zip in stock recovery, then succesfully rooted the device, finally wiped and flashed my custom rom
after major dissapointment in this tablets performance i decided i wanted to get rid of it.
So i downloaded the stock rom, wipe and flashed it onto the tablet...
the tablet turned off when it was finished (i think it was attempting to reboot) and never turned back on again...EVER! :good:
i cant even get to recovery
i tried flashing with adb and fastboot but the device is never even presents itselft to the computer.
i found out that you can boot the device into USB boot mode where you hold the "VOL -" (Volume Down) button and press the reset button and while connected to the computer (windows only) a "JZ4760 USB Boot Device" appears.
i did some googling and also found out that the T301 is based on similar tech to a bunch of tablets and they can all be modified by some software released by Ingenic called USBBootTool.exe
the tool is written in chinese and i cant decypher it all, though i found out how to use it based on its usage for other Ingenic based tablets
1.) you will need to disable driver signature verification (press F8 on boot of windows and toggle the setting, i hate rebooting too but it has to be done)
2.) boot your tablet into USB Boot Mode (hold down Vol - and press Reset button)
3.) install the driver for your device (included in the files below)
4.) with the tablet disconnected you would open the USBBootTool.exe
5.) select your tablet in the options and fill each box with the files needed to flash (files included below)
6.) reconnect the tablet while still in USB Boot Mode and the software will flash your device on detection
everything goes fine for me except when i get to the flashing part in the end.
when USBBootTool detects my tablet, it attempts to flash and gives me a stream of errors and never flashes my device.
i dont know what to do at this point. i have provided direct links to all the software im using and also links to where i got them.
any help would be appreciated, thank you to the XDA community in advance
>------------------- DOWNLOADS ------------------------<
USBBootTool.exe / Tablet Drivers (4725 / 4725B / 4740 / 4750 / 4755 / 4760 / 4770)
http://dl.dropbox.com/u/79196608/burn_tools_3.0.16.rar
obtained from - http://forum.xda-developers.com/showthread.php?t=1720621
Velocity Cruz T301 Update.zip (contains the system.img / data.img / mbr-xboot.bin files)
http://www.cruztablet.com/T301update.zip
obtained from - http://www.cruztablet.com/Article_861.php
SJHill Rom v0.3
http://www.androidfilehost.com/?fid=9390362690511176486
obtained from - http://www.slatedroid.com/topic/27583-rom-t301-sjhill-rom-17-feb-2012-download-link-updated/
ClockworkMod 5
http://files.androtab.info/ingenic/cwm/20120514/T301-recovery-signed.zip
obtained from - http://androtab.info/mips/ingenic/clockworkmod/
I have the same situation. I have gone through every menu in the USB Boot tool and to no avail am I able to recover my T100.
gmick is redoing the software because the coding is set up wrong. Once he gets that figured out there should be a fool proof unbricking method that we can follow. He is posting information over on Slate Droid if you want to take a look.
feyerbrand said:
gmick is redoing the software because the coding is set up wrong. Once he gets that figured out there should be a fool proof unbricking method that we can follow. He is posting information over on Slate Droid if you want to take a look.
Click to expand...
Click to collapse
ok post the link to the thread, and ill add it to the first post as a solution if its found to be a working one
JustSayTech said:
ok post the link to the thread, and ill add it to the first post as a solution if its found to be a working one
Click to expand...
Click to collapse
*Cross Post from SlateDroid* (but I can't post the link because XDA won't allow it)
I found out why the USB boot isn't working. Well, more appropriately I know where it fails but not exactly "why".
The USB Boot tool works like this:
1) Send x00 command (Get CPU Info)
2) Device responds with "JZ4760V1"
3) Host sends two binaries, stage1 and stage2. Stage 1 sets up memory stuff, and Stage 2 sets up USB flashing functions.
4) Host checks that the binaries executed by issuing another x00 command (Which serves as an "Are you still there?" function)
5) If the response is good, the host will flash the images, if the response is bad, it will abort.
Our devices are failing at step 4. The linux usb boot tools (xburst-tools) fail in an identical fashion.
I know that the first stage binary transfers and executes fine because if it didn't the device would be limited to 16k. The second stage is 120K and is transferred successfully. Once the second stage "execute" command is sent, the device crashes.
The second stage is also unique to the CPU type. I've used all of the binaries for JZ4760 I could find on the net and when that failed I cross compiled my own binary from source and it still crashed.
At this point I highly doubt I'll ever be able to fix it, and this completely explains why no one could get any usb recovery tool to work while others using similar devices could. I guess our board is modified just enough for ingenic's stock binaries to fail. Without knowing what's changed (getting Velocity Micro's source) we're SOL.
I can open it up again and solder on the serial header but I'm betting it's going to give me some generic "couldn't execute" message that isn't going to help me. I'll probably do this anyway though because I've come this far so what's the loss.
wow, i learned alot from that post, seems like writing a usbboottool-like application that can send the commands but also log and possibly bypass security checks etc but that def would take sometime. thank you for your insight, seems youve come the closest to cracking the case, actually you found the fault, hopefully your methods can eventually bring about a fix
JZ 4770
gmick said:
*Cross Post from SlateDroid* (but I can't post the link because XDA won't allow it)
I found out why the USB boot isn't working. Well, more appropriately I know where it fails but not exactly "why".
The USB Boot tool works like this:
1) Send x00 command (Get CPU Info)
2) Device responds with "JZ4760V1"
3) Host sends two binaries, stage1 and stage2. Stage 1 sets up memory stuff, and Stage 2 sets up USB flashing functions.
4) Host checks that the binaries executed by issuing another x00 command (Which serves as an "Are you still there?" function)
5) If the response is good, the host will flash the images, if the response is bad, it will abort.
Our devices are failing at step 4. The linux usb boot tools (xburst-tools) fail in an identical fashion.
I know that the first stage binary transfers and executes fine because if it didn't the device would be limited to 16k. The second stage is 120K and is transferred successfully. Once the second stage "execute" command is sent, the device crashes.
The second stage is also unique to the CPU type. I've used all of the binaries for JZ4760 I could find on the net and when that failed I cross compiled my own binary from source and it still crashed.
At this point I highly doubt I'll ever be able to fix it, and this completely explains why no one could get any usb recovery tool to work while others using similar devices could. I guess our board is modified just enough for ingenic's stock binaries to fail. Without knowing what's changed (getting Velocity Micro's source) we're SOL.
I can open it up again and solder on the serial header but I'm betting it's going to give me some generic "couldn't execute" message that isn't going to help me. I'll probably do this anyway though because I've come this far so what's the loss.
Click to expand...
Click to collapse
for my JZ4770 Earlier USB tool was flashing .img without any problem but for now it is saying "load cfg failed". "API downlaod failed' like dialogues and doesnt flash anything. Any idea? Thanks in advance!!
First restart your computer (actually restart it) then redownload the USB boot tool and save it in a completely new directory and use a different USB port
Sent from my Pokeball
Yes, I did
JustSayTech said:
First restart your computer (actually restart it) then redownload the USB boot tool and save it in a completely new directory and use a different USB port
Sent from my Pokeball
Click to expand...
Click to collapse
Yes, I tried with this suggestion. Rather I reinstalled xp and the tried again. But the dialogues are same. The history is like this. Was having ICS on JZ 4770. Formatted with usb tool and put JB updates. It was not sensing touch so reflashed another JB updates. Now the tab boots, it reaches to boot logo for around 12 seconds and restarts in stock recovery. While it is in booting stage it get detected by windows and adb also. In stock recovery mode it get detected by windows and in turn by adb also. If I tried to install updates through SD card it shows it had installed and reboots after completion. But again the same way it goes to boot logo and then back to stock JB recovery. It also boots in ingenic boot device mode and gets detected by USB burn tools. But when try to flash any of the ROM it gives the same dialogues "check cfg failed" "api download failed" "boot. fw failed" and cant flash anything.
Is there any tool which can be flashed or a script which can be used from SD card for completely formatting flash memory so that USB burn tool can flash required ROM?
can you flash the stock rom in recovery?
Managed using USB BOOT TOOL for ingenic JZ 4770 board in English
JustSayTech said:
can you flash the stock rom in recovery?
Click to expand...
Click to collapse
thanks man but I managed to boot the device. I used following USB BOOT TOOL for ingenic 4770 boards. The goodness with this tool, this is completely in English. You will know what you are doing. Even after opening the main window of the tool you can right click and then get another options(yes again in English). My problem with this device was bad blocks at 1024. In the options there is chance to force erase whole the nand partitions which I used and erased all the partitions thereby made all the partions available for flashing and readable by the tool. Then from File option selected stock rom files and flashed them. While flashing selected JZ4770 iNanad.ini file in manual configuration. This tool has really helped me to come out of the issue and will be useful for guys using JZ 4770 board.
http://www.4shared.com/rar/m1BUV5r2/USBBurnTool_20120401_for_relea.html
Got USBBootTool.exe kind of working.
1. Download the following file from Ingenic.
ftp * ingenic * cn/3sw/01linux/tmp/jz4770-20110610.rar
2. Download Applocale from Microsoft.
www * microsoft * com/en-us/download/details.aspx?id=13209
3. Extract the jz4770-20110610.rar and find the folder. (Using 7zip should keep the UTF encoding in Chinese)
20110610\04burn\20110524_4770_Programmer
4. Copy the folder 20110524_4770_Programmer to location you want to use it in.
5. Install Microsoft Applocale (Just in case, I don't think it is required)
Now Start Applocale and create a shortcut to USBbootTool.exe inside 20110524_4770_Programmer
中文(简体) is simplified Chinese option and should let you view the GUI correctly.
6. Now with the Applocale Shortcut created for USBbootTool.exe you can start the application with correct fonts.
Now this is where is breaks down.
TABLET-8 NAND FINAL BSP(S3 TEST) will allow you to read from it and write to it, but the CFG is off.
\tool_cfg\tablet-8-nand-final.ini is the configuration for it.
DO NOT CONNECT THE DEVICE WITH ANY OPTIONS CHECKED OR LOAD ANY FILES.
See Attached Images.
Next to the Read button is some Boot Option menu. I am not fulling aware of what this does.
What I need is a someone to help me fix/correct the ini/cfg files in
\20110524_4770_Programmer\tool_cfg\.ini
\20110524_4770_Programmer\4760\
to correctly match the files of the NAND.
Also if anyone has a copy (dd to img) or (cat to img) of the block devices.
That would help a ton.
# cat /proc/partitions
# cat /proc/mtd
I would also love another T10x Tablet for cheap.
I want to start building things like new bootloader, kernel, system image,
performance libraries to take full use of the Ingenic JZ4760 (www * ingenic * cn/product.aspx?CID=11)
I also bring Christmas gifts
2 APKS. You can place them in /system/app or /data/app.
Google Play will crash now and again, but it will load and work. (Vending.apk)
Secondly I bring the gift of performance increase, just by a slight bit.
edit the line of the heapsize in /system/build.prop dalvik.vm.heapsize=96m
Remember to make sure the permissions are set back to 666 or 644.
Original Vending.Apk before updates came from here: (Incase you are paranoid)
code * google * com/p/ics-nexus-s-4g/source/browse/trunk/system/app/Vending.apk?spec=svn20&r=18
ics-nexus-s-4g * googlecode * com/svn-history/r18/trunk/system/app/Vending.apk
To prevent spam on the XDA forums, ALL new users prevented from posting outside links in their messages. After approximately 10 posts, you will be able to post outside links. Thank you for
Click to expand...
Click to collapse
Stupid. how do you expect real people to help post Tech Docs? That is bad Moderating and Administrating.
Make sure to replace the Asterisk's with spaces to normal dots.
Requesting Block Images.
Does anyone have a copy of it they can send me for a T10x?
block images......
IceGryphon said:
Does anyone have a copy of it they can send me for a T10x?
Click to expand...
Click to collapse
Which block images do you want?
...also is there a way to rip the stock images off the jz4760 in the t301.
Such as:
Can i usethe ingenic uboot tool?
Anybody find the jtag pins?
Is the 4 pin conn next 2 the batt for serial?
.......i guess ill try to take a look this weekend
Ics would be really nice, but probably slower than stock..... especially with the limited ram
I unpacked the stock rom. I also unpacked an ics rom for a jz4770, and repo sync'd the aosp and mips 3.0.8 android kernel.
I'm still trying to figure out specs for the processor though. I know that its mips32 - el- fp- r1, but i cannot figur out the dsp version ... if it has one?
Error in erasing nand
nanachitang420 said:
thanks man but I managed to boot the device. I used following USB BOOT TOOL for ingenic 4770 boards. The goodness with this tool, this is completely in English. You will know what you are doing. Even after opening the main window of the tool you can right click and then get another options(yes again in English). My problem with this device was bad blocks at 1024. In the options there is chance to force erase whole the nand partitions which I used and erased all the partitions thereby made all the partions available for flashing and readable by the tool. Then from File option selected stock rom files and flashed them. While flashing selected JZ4770 iNanad.ini file in manual configuration. This tool has really helped me to come out of the issue and will be useful for guys using JZ 4770 board.
http://www.4shared.com/rar/m1BUV5r2/USBBurnTool_20120401_for_relea.html
Click to expand...
Click to collapse
I used english ingenic tool to erase bad blocks but m nt able erase bad blocks live suit is giving eror id=0x4848
Problem solved -- lessons learned posted on page 2 - in short, use Linux to do this and do the soldering right the first time. Still this experience may be helpful to some who try and come across similar hurdles. Thanks to all who helped.
So I was successful last year rooting and putting a new firmware on this phone. I cam back to try something new but made the bonehead move of grabbing a GB loader for the Vibrant and hard bricked the phone. Nothing worked of course so I got brave and tried the Unbrickable mod. I've worked under a microscope before and after some trial and error modified my tools to manage the task (I think!?).
Up front I want to thank Adam and everyone else who put effort into the Unbrickable mod - that's simply amazing work and I wAs so fascinated I had to try it too.
So I now nothing about linux so all around this has been a huge learning experience and I'm hoping my problem is software but I fear not. I'm running Ubuntu over VirtualBox and used the links provided in Adam's Development thread for the the T959V - of course I'm new here so couldn't comment there. There was no Detector download so I just downloaded the Resurrector. Upon hooking up the phone I got a huge smile because the phone was recognnized by the computer and finally by the resurrector when I figured out how to get Ubuntu to see the USB. I ran the device and everything went apparently well HOWEVER I could not follow on with Heimdall One-click as it would not recognize the phone.
Here's the Output from the ReSurrrector
**********************************************************
Begin Resurrection Sequence
Requesting Permission to access device
Please wait.... Uploading..
-------------------------------------------------------------
Hummingbird Interceptor Boot Loader (HIBL) v2.1
Copyright (C) Rebellos 2011
-------------------------------------------------------------
SMDK42XX,S3C64XX USB Download Tool
Version 0.20 (c) 2004,2005,2006 Ben Dooks <[email protected]>
S3C64XX Detected!
=> found device: bus 001, dev 004
=> loaded 24576 bytes from /tmp/TempHeimdallOneClick99719EDC/UnBrickPack/HIBL.bin
=> Downloading 24586 bytes to 0xd0020000
=> Data checksum d8dc
=> usb_bulk_write() returned 0
failed to write 24586 bytes
Interceptor Injection Complete. Injecting modified SBL
*****************************************************************
I assumed all was good and went forward. I got no display from the phone but the navigation lights did come on. However as said, Heimdall said phone disconnected. The phone is recognized in Windows as well however Odin does not recognize it. I tried Resurrector again and again. In looking at the Resurrector output I noticed there is a fail to write so I'm not sure where to go from here.... is there something wrong wtih my solder job? is one of the adjacent resistors disturbed?
I feel so close and yet so far... any direction is appreciated
sounds like a driver issue. here's a link for heimdall suite 1.3.2 for windows. unzip and make sure your phone is connected to a usb port in back of your pc first. front side usb ports can cause some problems. when phone is plugged into pc via usb, run the zadig.exe in the drivers folder. when open, options>list all devices. then from the drop down menu, select the one for samsung (mine now says galaxy s 4g) and then click install drivers. should be good to go with heimdall after that is done.
http://cdgfx.me/hEiMdaLL
Yep. Driver issue. Its better to use a Heimdall one-click if you can find one for your device. Linux also requires no drivers.
Again - please let me thank all in advance for looking at this problem.
So I've cleared all instances of USB installation before and the result is that I can now see "SCE S5PC110 Test B/D" show up in Zadig however - The drop down box shows only "USB Input Device (Interface 0) and another for (Interface 1)" and of course the S5PC110. I have "list all devices selected" however this devices only shows as the S5PC110 and thus Samsung is not selectable in the drop down box.
Driver reads as (NONE)
WInUSB (v6.1.7600.16385)
USB ID 04E8 1234
WCID shows a red "X"
There is no option to select Samung s4sg I suspect because the bootloaders are still not corrected and the Unbrickable mod is present?
Anyway, I pressed the install drivers button and indeed a usb driver installed with the following output.
******************************************
ini file 'zadig.ini' not found - default parameters will be used
default driver set to 'WinUSB'
0 devices found.
libwdi:info [detect_version] Windows 7
1 device found.
1 device found.
3 devices found.
Using inf name: SEC_S5PC110_Test_BD.inf
Succesfully extracted driver files.
Installing driver. Please wait...
libwdi:info [extract_binaries] successfully extracted driver files to C:\usb_driver
libwdi:info [wdi_prepare_driver] succesfully created 'C:\usb_driver\SEC_S5PC110_Test_BD.inf'
libwdi:info [wdi_prepare_driver] Vista or later detected - creating and self-signing a .cat file...
libwdi:info [ScanDirAndHash] added hash for 'C:\usb_driver\amd64\wdfcoinstaller01009.dll'
libwdi:info [ScanDirAndHash] added hash for 'C:\usb_driver\amd64\winusbcoinstaller2.dll'
libwdi:info [ScanDirAndHash] added hash for 'C:\usb_driver\sec_s5pc110_test_bd.inf'
libwdi:info [ScanDirAndHash] added hash for 'C:\usb_driver\x86\wdfcoinstaller01009.dll'
libwdi:info [ScanDirAndHash] added hash for 'C:\usb_driver\x86\winusbcoinstaller2.dll'
libwdi:info [CreateCat] successfully created file 'C:\usb_driver\SEC_S5PC110_Test_BD.cat'
libwdi:info [CreateSelfSignedCert] created new self-signed certificate 'CN=USB\VID_04E8&PID_1234 (libwdi autogenerated)'
libwdi:info [SelfSignFile] added certificate 'CN=USB\VID_04E8&PID_1234 (libwdi autogenerated)' to 'Root' and 'TrustedPublisher' stores
libwdi:info [SelfSignFile] successfully signed file 'C:\usb_driver\SEC_S5PC110_Test_BD.cat'
libwdi:info [SelfSignFile] successfully deleted private key
Driver Installation: SUCCESS
3 devices found.
*********************************************
I have the Heimdall One Click for this device but as seen previously in both linux and windows - Heimdall does not detect this device as a Samsung and shows Disconnected... Similarly Odin does not detect this device.
So I switched back over to VM Virtual Box running Ubuntu 12.04 and no difference there either. I further made the USB permanent and took off automount from windows so that I could ensure the device interfaced directly into linux in the short period of time I assume is the download period - that is to be able to enter password for Resurrector, then plug in phone, and then press OK in a short period of time. The result is the same.
Summary - in Linux, Resurrector recognizes the device but Fails to write 24586 bytes as before. I can now also be in Windows and have the S5PC110 device recognized however nothing can write to it in Windows as far as I know.
*********************
One last try with a different method - held Vol +&- & power before connecting to computer. The following output from Resurrector in Linux appears the same as previous except for the questionable write. After the usb_bulk_write however I heard the device disconnect and again the progress stopped here
----------------------------------------------------------
Hummingbird Interceptor Boot Loader (HIBL) v2.1
Copyright (C) Rebellos 2011
-------------------------------------------------------------
SMDK42XX,S3C64XX USB Download Tool
Version 0.20 (c) 2004,2005,2006 Ben Dooks <[email protected]>
S3C64XX Detected!
=> found device: bus 001, dev 002
=> loaded 24576 bytes from /tmp/TempHeimdallOneClick14WD41A3/UnBrickPack/HIBL.bin
=> Downloading 24586 bytes to 0xd0020000
=> Data checksum d8dc
=> usb_bulk_write() returned 24586
Interceptor Injection Complete. Injecting modified SBL
************************************************** **************
there is no display on the phone and nothing progresses. The usb bulk write happens only on occassion and is immediately followed by the usb disconnect sound.
Lumin30 has a file called usbdeview in his fresh out of the box thread. Use that to remove all samsung drivers. It sounds like a residual driver is causing a problem.
eollie said:
Lumin30 has a file called usbdeview in his fresh out of the box thread. Use that to remove all samsung drivers. It sounds like a residual driver is causing a problem.
Click to expand...
Click to collapse
Thanks eollie but I did that already. I had to delete all previous Samsung and S5PC installations as I've tried so many things to date which involved using almost every usb port. It did make a difference in that now the device is recognized but as the test board and not as Samsung. I have gone through the route of installing the samsung drivers previously from the various Samsung Driver files that are around however none resulted in this phone being recognized as a Samsung again.
On the windows pc go to device manager and delete all USB drivers not just the ones related to phone then reboot and then try a heimdall one-click and only use zadig to install drivers??
OK - so I wanted to remove Windows from the equation as the experts suggested it's a driver issue and despite all my efforts I was having no success. I installed Ubuntu (dual boot) and voila Resurrector now completes and for the first time I actually get into download mode with a graphic on the screen. Using bhundven's One click The T959V Heimdall One-Click Collection I finally saw "connected" and was able to follow the steps twice to flash bootloaders. All operations completed successfully before disconnecting the phone however the phone did not reboot. SO I repeated the whole process again without any change.
current state - I cannot get the phone into download mode without using Resurrector. While I know a ton of progress has been made here thanks to the tools provided by Adam, bhundven, and others my phone still behaves as it did before - no display except for button lights on some methods to get to download mode. My jig does nothing either. Battery is fully charged and I remain stumped.
Did you make sure you flashed with bootloaders cus Ive had tthat happen with an older phone
----------------------------------------------
If helped don't be afraid to hit the thanks button it doesn't bite lol
erikmm said:
Did you make sure you flashed with bootloaders cus Ive had tthat happen with an older phone
Click to expand...
Click to collapse
Yes twice with UVKJ6 package and subsequently tried AntonX-Basic_with_a_twist-v1.1.0-OC_UV.jar with double cycle to get the bootloaders flashed...
each time the process now gets to the point where it tries to reboot the phone and disconnects. The bottom status screen still maintains a rolling circle with statement of it's last step but the phone is powered down and nothing else will happen. No combination of buttons or jig or usb to computer will get the phone to boot or enter download mode.
On going back to windows (and Zadig) the device is still only seen as S5PC110 -- so I guess there is an improvement in but the phone is still not recognized as Samsung, Heimdall or Odin won't see it, and I have no idea what to try next.
You do have a SGH-T959V and not a 959W right? Have you tried to use heimdall frontend and flash everything except the modem? The 959W people that have been stuck in a bootloop got out of is by flashing everything except the modem. Then once sucessful they reboot to recovery and flash the modem of choice for the rom you are using.
I would pm getochkn and get the exact steps he uses and try it.
eollie said:
You do have a SGH-T959V and not a 959W right? Have you tried to use heimdall frontend and flash everything except the modem? The 959W people that have been stuck in a bootloop got out of is by flashing everything except the modem. Then once sucessful they reboot to recovery and flash the modem of choice for the rom you are using.
I would pm getochkn and get the exact steps he uses and try it.
Click to expand...
Click to collapse
This. Are you in Canada? A quick google search of "drsilicone" shows people with that same name on Canadian forums like redhotdeals, etc, so if that's you and you have a "W" phone, I may be able to help. 99% of the phone is the same as the "V" but small differences make a big deal sometimes and I have a pretty much complete dump now of a "W" phone with great help from bhundven and other team acid members. PM if you do have the "W" phone and we'll see what we can do. I've helped fix 2 other "W" peoples phones in the past 2 days. If you don't have a "W", then I can't help much. lol.
EVen if you see nothing on the screen, try the download button combo anyways. I did that to my phone yesterday, looked dead, but holding the buttons and putting the cable in, it still went into DL mode and Heimdall saw it, flashed back my dumps and was going again.
100% T959V -- it's a T-mobile phone that yes I previously rooted and unlocked. Worked fine for a year until my idiocy with the boot loader a few days ago.
and thanks for the advice but as I've noted above I've tried every key, button, jig, usb combination with no luck. The Unbrickable mod, resurrector, and Heimdall one-click with boot loader flash sequence appears to have worked except for the very last event expected - that is for the phone to reboot -- it does not reboot however.
The ONLY thing that produces any recognition or response in the phone is Adam's Resurrector. True the phone is now recognized in the window's environment as S5PC110 Test BD but it has never again been recognized as a Samsung so Heimdall simply won't find, connect, or otherwise allow command line flashing of this device. Similarly, Odin does not show any ID:Com open so that doesn't work either.
I can only hypothesize that the boot loaders were NOT actually written to the device as it would then show up as a Samsung no?? The only other thing to note is that after resurrector puts the device into Download mode (and I now see the yellow triangle graphic) I cannot disconnect the device and move to another port - the phone shuts right down and it's not responsive to ANYTHING I've tried..... and I think I've tried all sorts of combinations with battery in and out.
Edit:
Reading the Unbrickable Captivate thread again FredWorrell wrote on2nd September 2011, 04:31 AM #24
... a tip the size of a human hair. Although, if you screw up and you remove both resistors instead of just one, the phone can now be put into download mode and will accept a download. Unfortunately, it still won't boot normally.
Click to expand...
Click to collapse
This is the situation I guess I face but as I'm not certain what resistors he was referring to nor what those comparable resistors are on the T959V I'm still stumped -- unless Adam or someone knowledgeable can offer input...
I've borrowed this picture from Tablador for the magnification and clarity (Thank you Tablador) to highlight one resistor I have my questions about. I'm not sure how I can test it's function right now and my magnification is at 6X so I can't truly see the solder joints. I did disturb it but fixed it - could that explain this symptom?
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Problems SOLVED
Thanks for everyone's help - it turns out that it was the resistor pictured above. The picture above shows solder shoulders on these resistors - without equal magnification I would swear there was none and with the landing pads located underneath it looks like an impossible task but with the right technique I was able to correct my previous mistake.
Funny story goes along with this - I bought a Vibrant last year from a kid who said it was bricked by Kies and he didn't know what to do. I'm up for an adventure and bought it from him. I ended up getting the T959V right after with a broken screen so didn't really try too hard to fix the vibrant. Anyway, with this challenge I set out tonight to do the unbrickable mod on the Vibrant as the T959V wasn't working. On opening up I found quite the mess -- this kid obviously tried the unbrickable mod and the whole bank of high and low resistors was gone with 4 chips spread off to the sides -- A complete disaster indeed and made me realized I had been taken in buying it... Oh well, I was able to harvest a resistor (I guessed one near the cpu that looked similar to the one I wrecked on the T959V) and my only choice now was to go back to the T959V and try again.\
I added some magnification and was able to install the new resistor in place of the questionable one pictured. Happy simply with the new soldering skills I've gained over the past week I resigned myself to the result of this final attempt. Imagine my surprise when I pressed the power button and it booted into CWM -- I couldn't complete the boot sequence so I had to run Resurrector again followed by Heimdall One CLick and I'm overjoyed - This time it all worked as expected.
Thanks to Adam, bhundven, and all others who've contributed to these magnificent technical lessons.
If this thread will serve anyone else in trying the Unbrickable mod I would summarize my lessons --
#This is very difficult and technical work trying to solder these things - don't try it without the right tools, knowledge (which can be gained by reading and watching videos), and a steady hand. Seriously, if you shake under a microscope don't bother - pay someone.
#Don't bother trying to do this in Windows - not worth the headache -- Ubuntu provides a very easy way to install dual boot to your computer and it was so intuitive that I regret not doing it sooner.
# and I guess I'll just testify as one more person that this mod really does work exactly as described -- if it's not working as described you may have USB driver issues or soldering issues as I had. If it's not working - do the mod again and make sure all the connections are as they should be.
Hi! I'm exasperated so I turn to the experts: you! I hope this is right (or should I have continued this megathread?)
TLDR: Want to root international S6 running branded 5.1.1; but using Linux and having trouble getting things to work. Have tried lots already; details below.
1. bootloader status = I think it's unlocked but not sure how to determine this.
2. Rom name with complete baseband/date/version = "Austrian 3/Hutchinson" branded, PDA Version G920FXXU3COI9, CSC Version G920FDRE3COJ1, PHONE Version G920FXXU3QOJ1.
3. Kernel name = uh, stock Samsung 5.1.1?
4. Mods = none
5. Custom Rom = none
6. Guides =
7. Root status = unrooted.
8. Your exact problem = Want to root, having trouble doing so.
9. Any method you tried that failed = see details below.
10.Any other detail you think would be necessary = my phone's ODIN screen lists this information:
PRODUCT NAME: SM-G920F
CURRENT BINARY: Samsung Official
SYSTEM STATUS: Official
REACTIVATION LOCK: OFF
Secure Download: Enabled
KNOX WARRANTY VOID: 0 (0x0000)
RP SWREV: B:3 K:2 S:2
I've tried rooting my S6 using Linux, using a virtual WInXP hosted on Linux, and using an old real WinXP computer. None of the methods worked, but let me describe what I've tried on each -- I'd be happy if I can get either one of the methods across the finish line!
1) Virtual WinXP computer on Linux host
created a brand-new virtual WinXP installation to make sure nothing would interfere.
Installed Samsung drivers.
Installed Odin 3.06 - this is the newest version I could find that didn't show the error "The procedure entry point DecodePointer could not be located in the dynamic link library KERNEL32.dll."
In the settings for the virtual machine, set up rules to ensure all Samsung USB devices (USB vendor ID 04e8, any product ID) would be routed directly to the virtual machine.
Rebooted for good measure.
Connected phone in rear USB port, directly on motherboard (no hubs).
Neither Windows nor Odin sees the phone - neither in its normal operating mode nor in its "Odin" download mode.
Give up.
2) Physical Ubuntu computer, using JOdin
Installed Heimdall (latest version = 1.4.0-0).
Downloaded JOdin (latest version = v1035).
Installed Oracle Java 8 (8u67).
Rebooted for good measure.
Connected phone in rear USB port, directly on motherboard (no hubs).
JOdin says: "We could not obtain the pit file. We tried, but it didn't work." It seems that this is not really JOdin's fault but rather Heimdall (which JOdin relies on) because running just Heimdall from the CLI gives the same problem, as seen from this log (verbose version).
I dare not download a "random" PIT file from the Internet; this would satisfy JOdin but the risk of choosing the wrong one is too high. Other sites also mention ways to use the adb shell but ironically these require root - so I can't use them.
3) Physical WinXP computer
I did all of the above Linux trickery because I don't own a computer with Windows. By sheer chance, a friend came by with an old WinXP machine that I could commandeer for this purpose.
Installed Samsung drivers.
Installed Odin 3.06 - this is the newest version I could find that didn't show the error "The procedure entry point DecodePointer could not be located in the dynamic link library KERNEL32.dll."
Rebooted for good measure.
Connected phone in rear USB port, directly on motherboard (no hubs).
Odin sees my phone in download mode (first success!) and I can do the steps to start the root.
Odin works it way through the file and goes to "NAND write start" and then "Complete(Write) operation failed". I've tried this using the CF-Auto-Root and also separately using the unibase kernel for 5.1.1, with identical results.
I feel that I'm so close and yet success is not yet in reach. What more can I do? Thank you for your help and kind assistance!
torbengb said:
Hi! I'm exasperated so I turn to the experts: you! I hope this is right (or should I have continued this megathread?)
TLDR: Want to root international S6 running branded 5.1.1; but using Linux and having trouble getting things to work. Have tried lots already; details below.
1. bootloader status = I think it's unlocked but not sure how to determine this.
2. Rom name with complete baseband/date/version = "Austrian 3/Hutchinson" branded, PDA Version G920FXXU3COI9, CSC Version G920FDRE3COJ1, PHONE Version G920FXXU3QOJ1.
3. Kernel name = uh, stock Samsung 5.1.1?
4. Mods = none
5. Custom Rom = none
6. Guides =
7. Root status = unrooted.
8. Your exact problem = Want to root, having trouble doing so.
9. Any method you tried that failed = see details below.
10.Any other detail you think would be necessary = my phone's ODIN screen lists this information:
PRODUCT NAME: SM-G920F
CURRENT BINARY: Samsung Official
SYSTEM STATUS: Official
REACTIVATION LOCK: OFF
Secure Download: Enabled
KNOX WARRANTY VOID: 0 (0x0000)
RP SWREV: B:3 K:2 S:2
I've tried rooting my S6 using Linux, using a virtual WInXP hosted on Linux, and using an old real WinXP computer. None of the methods worked, but let me describe what I've tried on each -- I'd be happy if I can get either one of the methods across the finish line!
1) Virtual WinXP computer on Linux host
created a brand-new virtual WinXP installation to make sure nothing would interfere.
Installed Samsung drivers.
Installed Odin 3.06 - this is the newest version I could find that didn't show the error "The procedure entry point DecodePointer could not be located in the dynamic link library KERNEL32.dll."
In the settings for the virtual machine, set up rules to ensure all Samsung USB devices (USB vendor ID 04e8, any product ID) would be routed directly to the virtual machine.
Rebooted for good measure.
Connected phone in rear USB port, directly on motherboard (no hubs).
Neither Windows nor Odin sees the phone - neither in its normal operating mode nor in its "Odin" download mode.
Give up.
2) Physical Ubuntu computer, using JOdin
Installed Heimdall (latest version = 1.4.0-0).
Downloaded JOdin (latest version = v1035).
Installed Oracle Java 8 (8u67).
Rebooted for good measure.
Connected phone in rear USB port, directly on motherboard (no hubs).
JOdin says: "We could not obtain the pit file. We tried, but it didn't work." It seems that this is not really JOdin's fault but rather Heimdall (which JOdin relies on) because running just Heimdall from the CLI gives the same problem, as seen from this log (verbose version).
I dare not download a "random" PIT file from the Internet; this would satisfy JOdin but the risk of choosing the wrong one is too high. Other sites also mention ways to use the adb shell but ironically these require root - so I can't use them.
3) Physical WinXP computer
I did all of the above Linux trickery because I don't own a computer with Windows. By sheer chance, a friend came by with an old WinXP machine that I could commandeer for this purpose.
Installed Samsung drivers.
Installed Odin 3.06 - this is the newest version I could find that didn't show the error "The procedure entry point DecodePointer could not be located in the dynamic link library KERNEL32.dll."
Rebooted for good measure.
Connected phone in rear USB port, directly on motherboard (no hubs).
Odin sees my phone in download mode (first success!) and I can do the steps to start the root.
Odin works it way through the file and goes to "NAND write start" and then "Complete(Write) operation failed". I've tried this using the CF-Auto-Root and also separately using the unibase kernel for 5.1.1, with identical results.
I feel that I'm so close and yet success is not yet in reach. What more can I do? Thank you for your help and kind assistance!
Click to expand...
Click to collapse
I think may need to find a way to run the newest odin thats the only thing i can see thats rong in your attempts idk im not a big linux guy. U might need to get ahold of a win8 pc
WinXP SP2 = solved!
I solved the problem on Windows and finally got that big friendly PASS! :laugh:
As it turns out, there were two things blocking my success:
Odin version not compatible
Windows XP needed Service Pack 2
Initially I tried using the newest version of Odin, of course. But version 3.10.7 does not work, says "is not a valid Win32 application" so I went back to earlier versions until I found one that could run. The second-newest Odin version 3.10.6 does not work, says "The procedure entry point DecodePointer could not be located in the dynamic link library KERNEL32.dll." Finally, version 3.06 could run, but as I now know, that version is so old that it does not support the Samsung S6! Of course it doesn't say so, and that's why I was stumbling in the dark for a good while.
So I need a newer version, but what can I do to make the newest one work? I finally discover that v3.10.7 (despite being only a minor release) has this in its unofficial release notes: "Removed support for Windows XP or earlier"! Okay that was hard to find!
So I need the previous version, v3.10.6. However, that one complains about kernel32.dll. Where can I find a newer version of that DLL? It dawns on me that my brand-new WinXP installation doesn't have any of the service packs yet, so I install WinXP SP2 and, lo and behold, version 3.10.6 can finally run!
But all of this was on my virtual machine, and it still couldn't detect when I plugged in the phone on the host computer. So I took a look at the WinXP machine that luckily was passing through my home just now. It's in German, and only runs WinXP SP1. I managed to find and install SP2 in German, and finally I had Odin v3.10.6 running on that machine - and it actually detected my phone!!
From here on, it was trivial to complete the rooting process. Once the software gets to run as intended, it's a beautifully simple thing. My phone is now rooted, and I can finally have Llama put it into airplane mode when I go to sleep. SUCCESS!
(But I still don't know why it doesn't work on Linux.)
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Changelog:
v2 - Fixed the issue with the screen
Make sure to read this guide completely before starting. It requires you to open the tablet, however you don't need to solder or use any advanced tools.
This is only for Fire HD 8, 8th generation, also known as karnak or KFKAWI. It's now confirmed to work on both 16GB and 32GB models.
You will lose all data on the tablet, make a backup of important data before you start. If you've enabled encryption, it's probably a good idea to disable it before you proceed with the guide.
What you need:
- a Linux installation. Since I had to rush it, this guide is only for Linux. Once I get a chance to test it on Windows I'll update the guide.
- microusb cable to connect your tablet to the PC
- some way to open the tablet (pry tool, opening picks, etc)
- something conductive (metal tweezers, a paper clip, a piece of wire, etc)
- amonet.tar.gz
- 6300.zip: https://mega.nz/#!FI1HSI5T!2zUAeiW9I-eH3Ph0Ar10_2nioNIm0ilSnNYgOG9YPNE
- Magisk-v18.0.zip: https://github.com/topjohnwu/Magisk/releases/download/v18.0/Magisk-v18.0.zip
- finalize.zip
Install python3, PySerial, adb and fastboot. For Debian/Ubuntu something like this should work "sudo apt install python3 python3-serial android-tools-adb android-tools-fastboot".
Extract amonet.tar.gz, open a terminal and navigate to it.
You might need to run the scripts on your PC under sudo if you're getting permission errors.
0. Shut your device down and disconnect it from USB! Also, disconnect all other Android devices you might have connected from your PC. Also, if you have ModemManager installed, you MUST disable or uninstall it before you begin
1. Use a pry tool to remove the back shell from the tablet. Start at the bottom and work your way up. There are no cables between the back shell and the motherboard.
2. On the left side of the board there are 4 test points labeled DAT0, RST, CMD, CLK. We only care about the bottom one, CLK.
3. Plug in one end of the microusb cable, either to the PC or to the tablet, whatever's more convenient.
4. On your PC, run `./bootrom-step.sh`. It should print "Waiting for the bootrom".
5. Using your conductive apparatus, short the CLK test point to the ground. This means you should connect one side of your paperclip to the CLK pin and the other to the metallic shield or a side of the PCB. Firmly hold it in place so that there is connection. (See https://i.imgur.com/7BXIb2y.jpg)
6. Plug in the other end of the microusb cable.
7. You should see a new device appear on your PC
Code:
[10894.058045] usb 3-2.4.1: new full-speed USB device number 9 using xhci_hcd
[10894.239684] usb 3-2.4.1: New USB device found, idVendor=0e8d, idProduct=0003
[10894.239690] usb 3-2.4.1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[10894.241330] cdc_acm 3-2.4.1:1.0: ttyACM0: USB ACM device
This *must* be the device you see. If you see a "preloader" device instead, you didn't hold the paperclip strong enough. Unplug it, shut down your Fire (pull out USB cord and wait; if it doesn't shut down, you might have to disconnect the battery) and try again starting at step 4.
8. The script you ran in step 4 should now tell you to remove the short. Remove the paperclip and press Enter as instructed.
9. The script will now proceed to downgrade your device and flash some essential files. Just let it be, it will take about 4 minutes. You should see the following output:
Code:
[2019-01-26 23:30:02.157670] Waiting for bootrom
[2019-01-26 23:30:20.438333] Found port = /dev/ttyACM0
[2019-01-26 23:30:20.439362] Handshake
[2019-01-26 23:30:20.441693] Disable watchdog
* * * Remove the short and press Enter * * *
[2019-01-26 23:30:22.636037] Init crypto engine
[2019-01-26 23:30:22.661832] Disable caches
[2019-01-26 23:30:22.662505] Disable bootrom range checks
[2019-01-26 23:30:22.685773] Load payload from ../brom-payload/build/payload.bin = 0x4690 bytes
[2019-01-26 23:30:22.693170] Send payload
[2019-01-26 23:30:23.527965] Let's rock
[2019-01-26 23:30:23.528832] Wait for the payload to come online...
[2019-01-26 23:30:24.260602] all good
[2019-01-26 23:30:24.261069] Check GPT
[2019-01-26 23:30:24.596346] gpt_parsed = {'proinfo': (1024, 6144), 'PMT': (7168, 9216), 'kb': (16384, 2048), 'dkb': (18432, 2048), 'lk': (20480, 2048), 'tee1': (22528, 10240), 'tee2': (32768, 10240), 'metadata': (43008, 80896), 'MISC': (123904, 1024), 'reserved': (124928, 16384), 'boot': (141312, 32768), 'recovery': (174080, 40960), 'system': (215040, 6354944), 'vendor': (6569984, 460800), 'cache': (7030784, 1024000), 'userdata': (8054784, 22722527)}
[2019-01-26 23:30:24.596619] Check boot0
[2019-01-26 23:30:24.841858] Check rpmb
[2019-01-26 23:30:25.051079] Downgrade rpmb
[2019-01-26 23:30:25.052924] Recheck rpmb
[2019-01-26 23:30:25.949978] rpmb downgrade ok
[2019-01-26 23:30:25.950284] Flash lk-payload
[5 / 5]
[2019-01-26 23:30:26.471797] Flash preloader
[288 / 288]
[2019-01-26 23:30:44.845804] Flash tz
[6732 / 6732]
[2019-01-26 23:33:08.502134] Flash lk
[685 / 685]
[2019-01-26 23:33:23.337460] Inject microloader
[4 / 4]
[2019-01-26 23:33:23.667547] Reboot to unlocked fastboot
If the script freezes at some point, you will have to restart it. Terminate the script, unplug USB, and try again starting at step 4. If after unplugging USB cable the device doesn't shut down, you might have to disconnect the battery. You can keep it disconnected until the script succeeds, but once it's done you must reconnect it before booting to fastboot.
9. You should see a success message: "Reboot to unlocked fastboot". Only proceed if you see the message.
10. Once the device boots to fastboot (check with "fastboot devices". You should see amazon logo on the screen.), you can run "./fastboot-step.sh". Then, flip the device over so that you can see the display.
11. At this point the device should boot into recovery, however it's possible that the screen will be off by default. Just press the power button twice and the screen should turn on.
12. We'll now upload required files to the recovery. On your PC, do:
adb push 6300.zip /sdcard
adb push Magisk-v18.0.zip /sdcard
adb push finalize.zip /sdcard
13. In the recovery, go to "Install", navigate to "/sdcard" and flash 6300.zip
14. Go to "Wipe" and do the default wipe, then reboot
15. At the Fire setup screen, select your language. On the next screen, Wifi setup, select any password-protected network, then instead of entering the password press "cancel". Now, back at the wifi setup screen, press "skip" and "skip" in the dialog pop-up again
16. Hold down the power button, press Restart and hold volume down to boot into recovery.
17. In the recovery, go to "Install", navigate to "/sdcard" and flash Magisk-v18.0.zip
18. Press back, select finalize.zip and flash it
19. Once finalize.zip is flashed, press "Reboot System"
20. Done. The device should now boot into a rooted 6.3.0.0 firmware. You should have Magisk manager installed, and root working. You will be able to boot into recovery by holding volume down.
21. At this point it should be safe to connect to wifi. If everything works okay, assemble your device.
Your device is now unlocked. You can flash a custom boot image, system image, etc. However, if you ever brick the device so bad the recovery does not boot, you will have to repeat these steps starting from the first one. Read below for what you should not do.
VERY IMPORTANT STUFF:
Only ever flash boot images from TWRP. Since nothing but TWRP is aware of the exploit, if you try to flash a boot image from Android, it won't have the exploit integrated into it! This includes Magisk as well, so do NOT install or uninstall it from Magisk Manager (However, installing modules should be fine; although it depends on the specific module).
Due to how the exploit works, it takes over the first 0x400 bytes of boot.img/recovery.img. When flashing zips from the recovery, it will transparently remove and then reinstall the exploit when needed. So long as you flash zips from the recovery, you should treat the boot image normally. However, this means that you cannot use any other apps (e.g. FlashFire) to flash the boot or recovery partitions.
To revert back to stock:
- download update package from amazon https://fireos-tablet-src.s3.amazon...ate-kindle-NS6301_user_1611_0001309035396.bin to your PC
- flash 6300.zip from twrp
- flash revert-stock.zip from twrp
- wipe data
- reboot to recovery; you should see amazon recovery now
- select "apply update from ADB" in the recovery menu
- run "adb sideload update-kindle-NS6301_user_1611_0001309035396.bin" on your PC
Another way to fix a brick:
- Download update package from amazon https://fireos-tablet-src.s3.amazon...ate-kindle-NS6301_user_1611_0001309035396.bin to your PC
- Download and unzip revert-stock.zip
- Do steps 0 to 9 from this guide (so everything until fastboot-step.sh)
- Wait for device to boot into fastboot mode (check with "fastboot devices")
- Run "fastboot flash boot boot.img" using boot.img from the revert-stock.zip
- Run "fastboot flash recovery recovery.img" using recovery.img from the from the revert-stock.zip
- Run "fastboot reboot recovery"
- Select "apply update from ADB" in the recovery menu
- Run "adb sideload update-kindle-NS6301_user_1611_0001309035396.bin" on your PC
Other misc information / troubleshooting:
- If you need to disconnect the battery, use a pair of tweezers to grab the wires and gently pull towards yourself. You can do bootrom-step.sh either with or without the battery connected, however fastboot-step.sh should be done with the battery connected.
- If your device is bricked (e.g. from a downgrade), just follow the steps as-is.
- If you're getting an error like "Serial protocol mismatch", or any other error in bootrom-step, try disabling or temporarily uninstalling ModemManager from your Linux
- To remount /system as rw use "mount -o rw,remount /system". ("mount -o remount,rw /system" will not work)
Thanks to: @hwmod @firetablethelp for testing different versions of the payload.
Special thanks to: aftv2-tools contributors https://gitlab.com/zeroepoch/aftv2-tools; the bootrom download protocol scripts are largely based on their work
GPL Notice:
- Source code for modified TWRP is available from https://github.com/xyzz/android_bootable_recovery
- Source code for amonet/brom-payload is available from https://github.com/xyzz/amonet/tree/master/brom-payload
Device tree to build TWRP: https://github.com/xyzz/android_device_amazon_karnak
Additionally, source code of the full exploit chain is available from https://github.com/xyzz/amonet
When I finish the writeup for this vulnerability, I'll update this post with a URL to the writeup.
You sir, are a marvelous wizard leet haxor ?. Thanks for this. Will this ever lead to any software solution for root on this tablet. Parden my noob questions?
beanaman said:
You sir, are a marvelous wizard leet haxor . Thanks for this. Will this ever lead to any software solution for root on this tablet. Parden my noob questions?
Click to expand...
Click to collapse
The only reason you have to open the tablet is to put the bootrom into download mode. If somebody figures out another way to do that, then yes it can be done completely in software. One way is to brick the tablet by erasing the preloader completely (both copies). However, this would require root (temporarily), and is more dangerous. Ultimately, I figured that the difficulty level here is about as much as replacing a battery (even lower) so I haven't investigated this further.
Thank you for explaining that further. It's nice to have this capability in our toolbox.
Wow! @xyz` you are a genius!
This exploit can be applied to fire 7 7th gen?
xyz` said:
Make sure to read this guide completely before starting. It requires you to open the tablet, however you don't need to solder or use any advanced tools.
This is only for Fire HD 8, 8th generation, also known as karnak or KFKAWI. I've also only tested this on the 16GB version, though the 32GB one should work the same.
You will lose all data on the tablet, make a backup of important data before you start. If you've enabled encryption, it's probably a good idea to disable it before you proceed with the guide.
What you need:
- a Linux installation. Since I had to rush it, this guide is only for Linux. Once I get a chance to test it on Windows I'll update the guide.
- microusb cable to connect your tablet to the PC
- some way to open the tablet (pry tool, opening picks, etc)
- something conductive (metal tweezers, a paper clip, a piece of wire, etc)
- amonet.tar.gz
- 6300.zip: https://mega.nz/#!FI1HSI5T!2zUAeiW9I-eH3Ph0Ar10_2nioNIm0ilSnNYgOG9YPNE
- Magisk-v18.0.zip: https://github.com/topjohnwu/Magisk/releases/download/v18.0/Magisk-v18.0.zip
- finalize.zip
Install python3, PySerial, adb and fastboot. For Debian/Ubuntu something like this should work "sudo apt install python3 python3-serial android-tools-adb android-tools-fastboot".
Extract amonet.tar.gz, open a terminal and navigate to it.
You might need to run the scripts on your PC under sudo if you're getting permission errors.
0. Shut your device down and disconnect it from USB! Also, disconnect all other Android devices you might have connected from your PC.
1. Use a pry tool to remove the back shell from the tablet. Start at the bottom and work your way up. There are no cables between the back shell and the motherboard.
2. On the left side of the board there are 4 test points labeled DAT0, RST, CMD, CLK. We only care about the bottom one, CLK.
3. Plug in one end of the microusb cable, either to the PC or to the tablet, whatever's more convenient.
4. On your PC, run `./bootrom-step.sh`. It should print "Waiting for the bootrom".
5. Using your conductive apparatus, short the CLK test point to the ground. This means you should connect one side of your paperclip to the CLK pin and the other to the metallic shield or a side of the PCB. Firmly hold it in place so that there is connection. (See https://i.imgur.com/7BXIb2y.jpg)
6. Plug in the other end of the microusb cable.
7. You should see a new device appear on your PC
This *must* be the device you see. If you see a "preloader" device instead, you didn't hold the paperclip strong enough. Unplug it, shut down your Fire (pull out USB cord and wait; if it doesn't shut down, you might have to disconnect the battery) and try again starting at step 4.
8. The script you ran in step 4 should now tell you to remove the short. Remove the paperclip and press Enter as instructed.
9. The script will now proceed to downgrade your device and flash some essential files. Just let it be, it will take about 4 minutes. You should see the following output:
If the script freezes at some point, you will have to restart it. Terminate the script, unplug USB, and try again starting at step 4. If after unplugging USB cable the device doesn't shut down, you might have to disconnect the battery. You can keep it disconnected until the script succeeds, but once it's done you must reconnect it before booting to fastboot.
9. You should see a success message: "Reboot to unlocked fastboot". Only proceed if you see the message.
10. Once the device boots to fastboot (check with "fastboot devices"), you can run "./fastboot-step.sh". Then, flip the device over so that you can see the display.
11. At this point the device should boot into recovery, however it's possible that the screen will be off by default. Just press the power button twice and the screen should turn on.
13. We'll now upload required files to the recovery. On your PC, do:
adb push 6300.zip /sdcard
adb push Magisk-v18.0.zip /sdcard
adb push finalize.zip /sdcard
14. In the recovery, go to "Install", navigate to "/sdcard" and flash 6300.zip
15. Go to "Wipe" and do the default wipe, then reboot
16. At the Fire setup screen, select your language. On the next screen, Wifi setup, select any password-protected network, then instead of entering the password press "cancel". Now, back at the wifi setup screen, press "skip" and "skip" in the dialog pop-up again
17. Hold down the power button, press Restart and hold volume down to boot into recovery.
18. In the recovery, go to "Install", navigate to "/sdcard" and flash Magisk-v18.0.zip, finalize.zip, in that order.
15. Press "Reboot System" once the latest zip, finalize.zip, is installed.
16. Done. The device should now boot into a rooted 6.3.0.0 firmware. You should have Magisk manager installed, and root working. You will be able to boot into recovery by holding volume down.
17. At this point it should be safe to connect to wifi. If everything works okay, assemble your device.
Your device is now unlocked. You can flash a custom boot image, system image, etc. However, if you ever brick the device so bad the recovery does not boot, you will have to repeat these steps starting from the first one. Read below for what you should not do.
VERY IMPORTANT STUFF:
Only ever flash boot images from TWRP. Since nothing but TWRP is aware of the exploit, if you try to flash a boot image from Android, it won't have the exploit integrated into it! This includes Magisk as well, so do NOT install or uninstall it from Magisk Manager (However, installing modules should be fine; although it depends on the specific module).
Due to how the exploit works, it takes over the first 0x400 bytes of boot.img/recovery.img. When flashing zips from the recovery, it will transparently remove and then reinstall the exploit when needed. So long as you flash zips from the recovery, you should treat the boot image normally. However, this means that you cannot use any other apps (e.g. FlashFire) to flash the boot or recovery partitions.
To revert back to stock:
- download update package from amazon https://fireos-tablet-src.s3.amazon...ate-kindle-NS6301_user_1611_0001309035396.bin to your PC
- flash 6300.zip from twrp
- flash revert-stock.zip from twrp
- wipe data
- reboot to recovery; you should see amazon recovery now
- select "apply update from ADB" in the recovery menu
- run "adb sideload update-kindle-NS6301_user_1611_0001309035396.bin" on your PC
Special thanks to: aftv2-tools contributors https://gitlab.com/zeroepoch/aftv2-tools; the bootrom download protocol scripts are largely based on their work
Click to expand...
Click to collapse
LMFAO I can't ****ing believe this. I'm almost certain this will work on the HD 10 too. You found it before me. Absolutely brilliant. You've just proved many weeks and or months of my hard research that I've posted in more than a few threads between the fire 7 forums and here. You just happened to be a lot quicker at this and probably smarter. ACM I discovered a few weeks or months ago on the HD 10. There is a build file that has many ways to set ACM props. doing this made everything light up on my PC...new drivers were installed and being used including the preloader drivers. I set my test HD 10 to persist ACM since then, convinced it was one of the possible keys to the puzzle. If you've read anything I've done in the past several weeks and months you may have been the only one who truly believed anything I had been saying. I don't know who you are or where you came from but I can only thank you. You've made my day, my week and my year. At least now I can say I'm not crazy, hallucinating or 'don't know what I'm doing or talking about.' it will take me a few days to get started, but I'll get right to testing my test HD 10 in the next few days or so.
Edit: I was convinced it had to do with fos_flags too, which I believe is another way to unlock.
Sent from my MotoG3 using XDA Labs
Rortiz2 said:
Wow! @xyz` you are a genius!
This exploit can be applied to fire 7 7th gen?
Click to expand...
Click to collapse
The vulnerability is present on every mediatek device, so yeah. It will not work as-is because of different addresses (for the crypto device and offsets for LK). Additionally, on Fire 7 7th gen the eMMC test point is hidden behind the shield that you need to desolder, so you will probably want to find a different way to enter the bootrom download mode.
Great work!
xyz` said:
The vulnerability is present on every mediatek device, so yeah. It will not work as-is because of different addresses (for the crypto device and offsets for LK). Additionally, on Fire 7 7th gen the eMMC test point is hidden behind the shield that you need to desolder, so you will probably want to find a different way to enter the bootrom download mode.
Click to expand...
Click to collapse
This is very promising could you please elaborate, what exactly needs to be modified to port this to other MTK-hardware.
I have a fire 5th gen here and I can access brom-mode by pressing left mute button while pluging in.
tried your scripts as is (commenting out the parts that change rpmb or flash partitions) and it get's stuck at
Code:
[2019-01-28 00:01:40.973289] Disable bootrom range checks
Does the hash in load_payload.py (4dd12bdf0ec7d26c482490b3482a1b1f) need to be modified?
I do have the kernel-sources for the device and am willing to investigate correct addressing etc.
Also since this is a boot-rom exploit wouldn't it allow flashing a hacked preloader + lk which just ignore boot-signatures so we can just run a standard twrp?
k4y0z said:
This is very promising could you please elaborate, what exactly needs to be modified to port this to other MTK-hardware.
I have a fire 5th gen here and I can access brom-mode by pressing left mute button while pluging in.
tried your scripts as is (commenting out the parts that change rpmb or flash partitions) and it get's stuck at
Code:
[2019-01-28 00:01:40.973289] Disable bootrom range checks
Does the hash in load_payload.py (4dd12bdf0ec7d26c482490b3482a1b1f) need to be modified?
I do have the kernel-sources for the device and am willing to investigate correct addressing etc.
Also since this is a boot-rom exploit wouldn't it allow flashing a hacked preloader + lk which just ignore boot-signatures so we can just run a standard twrp?
Click to expand...
Click to collapse
So first of all make sure you're accessing bootrom mode and not preloader mode (Although if the preloader supports read/write, the exploit should work there as well, I just haven't tested it since on hd 8 8th gen none of preloaders support these). I suggest soldering on a UART adapter, then use 115200 baud rate. When in bootrom dl mode, you should see "[DL] 00000BB8 444C0005 010701" (basically, the "[DL]" part is the important one)
If it's a different soc, you will have to dump the bootrom and find the offset where range check data is stored (in my case, 0x102868). You might have to modify the 4dd12bdf0ec7d26c482490b3482a1b1f part as well, it's basically calculated as a xor of expected data and actual data it's written. Then, you'll also need to update the pointer I'm overwriting (0x1028A8 in my case, called ptr_send in brom-payload). Again, if executing under preloader it's gonna be completely different way to exploit it.
Once all this is done, you should be able to load binary payloads and execute them in bootrom mode. You'll also need to edit brom-payload and set up proper pointers to send_dword/recv_dword/etc, these can be found by reversing your bootrom dump. At this point it should be possible to get emmc read/write.
Finally, if you want a persistent unlock (and not just the ability to modify /system) you'll need to port lk exploit as well. So you'll have to figure if your lk is vulnerable to the same bug, port microloader, inject_microloader.py and lk-payload to use the proper offsets. It's a lot of work.
I'll hopefully finish my writeup in the next weeks and post a link to it, that should be easier to understand since I'll explain the whole process from start to finish.
You're right about being able to load a custom preloader/lk, however the bootrom exploit requires a PC connection and a bunch of USB commands (so in a way, it's "tethered"). The actual unlock exploit isn't using any bootrom bugs, but rather the lk bug, since that one works without a PC. In fact, the bootrom exploit is only used to flash stuff to eMMC (but, of course you could probably do more fun stuff with it) in my chain.
Thanks for your quick reply.
xyz` said:
So first of all make sure you're accessing bootrom mode and not preloader mode (Although if the preloader supports read/write, the exploit should work there as well, I just haven't tested it since on hd 8 8th gen none of preloaders support these). I suggest soldering on a UART adapter, then use 115200 baud rate. When in bootrom dl mode, you should see "[DL] 00000BB8 444C0005 010701" (basically, the "[DL]" part is the important one)
Click to expand...
Click to collapse
I'm pretty sure I'm in boot-rom, my preloader actually has direct read/write using read_mmc.py but that has been fixed in newer preloaders, so I would rather go the boot-rom route.
Have you tried if pressing left (or both) volume buttons while pluging in brings you to brom-mode as well, like it does on my device?
I'll attach a serial to check for the output.
xyz` said:
If it's a different soc, you will have to dump the bootrom and find the offset where range check data is stored (in my case, 0x102868). You might have to modify the 4dd12bdf0ec7d26c482490b3482a1b1f part as well, it's basically calculated as a xor of expected data and actual data it's written. Then, you'll also need to update the pointer I'm overwriting (0x1028A8 in my case, called ptr_send in brom-payload). Again, if executing under preloader it's gonna be completely different way to exploit it.
Click to expand...
Click to collapse
Any hint on how i would dump the bootrom? Also could you upload your boot-rom so I can compare once i got mine?
xyz` said:
Finally, if you want a persistent unlock (and not just the ability to modify /system) you'll need to port lk exploit as well. So you'll have to figure if your lk is vulnerable to the same bug, port microloader, inject_microloader.py and lk-payload to use the proper offsets. It's a lot of work.
Click to expand...
Click to collapse
Willing to put that work in
xyz` said:
I'll hopefully finish my writeup in the next weeks and post a link to it, that should be easier to understand since I'll explain the whole process from start to finish.
Click to expand...
Click to collapse
looking forward to your writeup.
xyz` said:
You're right about being able to load a custom preloader/lk, however the bootrom exploit requires a PC connection and a bunch of USB commands (so in a way, it's "tethered"). The actual unlock exploit isn't using any bootrom bugs, but rather the lk bug, since that one works without a PC. In fact, the bootrom exploit is only used to flash stuff to eMMC (but, of course you could probably do more fun stuff with it) in my chain.
Click to expand...
Click to collapse
I thought it might be possible to flash a preloader that exploits the same vulnerability, but from your explanation I assume that won't be possible.
For this device it would already be great to be able to overwrite RPMB to downgrade, since there was an LK that allowed booting into unsigned TWRP.
k4y0z said:
Thanks for your quick reply.
I'm pretty sure I'm in boot-rom, my preloader actually has direct read/write using read_mmc.py but that has been fixed in newer preloaders, so I would rather go the boot-rom route.
Have you tried if pressing left (or both) volume buttons while pluging in brings you to brom-mode as well, like it does on my device?
I'll attach a serial to check for the output.
Click to expand...
Click to collapse
Yep, I've tried and it didn't work, though it could be device-specific. There are several additional ways preloader can force you into bootrom download mode, for example if preloader has an assertion and you hold volume down, it just deletes itself from emmc and next boot you'd be in bootrom mode (this doesn't work on hd 8 though as there's a bug in how it's set up); then there's some button checks that sets up a SRAMROM_USBDL which bootrom checks (but the code for the button check isn't present on Fire preloader). So unfortunately the only option that worked for me is shorting eMMC to ground.
k4y0z said:
Any hint on how i would dump the bootrom? Also could you upload your boot-rom so I can compare once i got mine?
Click to expand...
Click to collapse
This will be in the writeup, it's too long to explain here. I'm not sure if I can share my dump since technically it's copyrighted code.
k4y0z said:
I thought it might be possible to flash a preloader that exploits the same vulnerability, but from your explanation I assume that won't be possible.
For this device it would already be great to be able to overwrite RPMB to downgrade, since there was an LK that allowed booting into unsigned TWRP.
Click to expand...
Click to collapse
Well, we only can flash preloaders signed by amazon. If you have a preloader/LK combination that doesn't have signature checks that's great, you can use that.
k4y0z said:
Any hint on how i would dump the bootrom? Also could you upload your boot-rom so I can compare once i got mine?
Click to expand...
Click to collapse
Also, here's what I used on my Fire 7:
Code:
def call_func(func):
sdr_write32(0x11010804, 3)
sdr_write32(0x11010808, 3)
sdr_write32(0x11010C00, func)
sdr_write32(0x11010400, 0)
while (not sdr_read32(0x11010800)):
pass
if (sdr_read32(0x11010800) & 2):
if ( not (sdr_read32(0x11010800) & 1) ):
while ( not sdr_read32(0x11010800) ):
pass
result = -1;
sdr_write32(0x11010804, 3)
else:
while ( not (sdr_read32(0x11010418) & 1) ):
pass
result = 0;
sdr_write32(0x11010804, 3)
return result
def hw_acquire():
sdr_write32(0x11010000, sdr_read32(0x11010000) & 0xFFFFFFF0)
sdr_write32(0x11010000, sdr_read32(0x11010000) | 0xF)
sdr_write32(0x11010004, sdr_read32(0x11010004) & 0xFFFFDFFF)
def hw_release():
sdr_write32(0x11010000, sdr_read32(0x11010000) & 0xFFFFFFF0)
sdr_write32(0x11010000, sdr_read32(0x11010000) | 0xF)
def init():
sdr_write32(0x11010C0C, 0)
sdr_write32(0x11010C10, 0)
sdr_write32(0x11010C14, 0)
sdr_write32(0x11010C18, 0)
sdr_write32(0x11010C1C, 0)
sdr_write32(0x11010C20, 0)
sdr_write32(0x11010C24, 0)
sdr_write32(0x11010C28, 0)
sdr_write32(0x11010C2C, 0)
sdr_write32(0x11010C00 + 18 * 4, [0] * 4)
sdr_write32(0x11010C00 + 22 * 4, [0] * 4)
sdr_write32(0x11010C00 + 26 * 4, [0] * 8)
def aes_read16(addr):
sdr_write32(0x11010C04, addr)
sdr_write32(0x11010C08, 0) # dst to invalid pointer
sdr_write32(0x11010C0C, 1)
sdr_write32(0x11010C14, 18)
sdr_write32(0x11010C18, 26)
sdr_write32(0x11010C1C, 26)
if call_func(126) != 0: # aes decrypt
raise Exception("failed to call the function!")
words = sdr_read32(0x11010C00 + 26 * 4, 4) # read out of the IV
data = b""
for word in words:
data += struct.pack("<I", word)
return data
def aes_write16(addr, data):
if len(data) != 16:
raise RuntimeError("data must be 16 bytes")
pattern = bytes.fromhex("6c38d88958fd0cf51efd9debe8c265a5")
# iv-xor
words = []
for x in range(4):
word = data[x*4:(x+1)*4]
word = struct.unpack("<I", word)[0]
pat = struct.unpack("<I", pattern[x*4:(x+1)*4])[0]
words.append(word ^ pat)
sdr_write32(0x11010C00 + 18 * 4, [0] * 4)
sdr_write32(0x11010C00 + 22 * 4, [0] * 4)
sdr_write32(0x11010C00 + 26 * 4, [0] * 8)
sdr_write32(0x11010C00 + 26 * 4, words)
sdr_write32(0x11010C04, 0xE680) # src to VALID address which has all zeroes (otherwise, update pattern)
sdr_write32(0x11010C08, addr) # dst to our destination
sdr_write32(0x11010C0C, 1)
sdr_write32(0x11010C14, 18)
sdr_write32(0x11010C18, 26)
sdr_write32(0x11010C1C, 26)
if call_func(126) != 0: # aes decrypt
raise Exception("failed to call the function!")
Try calling aes_read16(0) and see if it returns valid looking data (should start with "07 00 00 EA FE FF FF EA FE FF FF EA FE FF FF EA")
xyz` said:
Also, here's what I used on my Fire 7:
Try calling aes_read16(0) and see if it returns valid looking data (should start with "07 00 00 EA FE FF FF EA FE FF FF EA FE FF FF EA")
Click to expand...
Click to collapse
It seems to just hang with both aes_read16 and aes_write16.
It is probably related to the CRYPTO_BASE.
I tried finding the correct one here: https://github.com/chaosmaster/andr...ch/arm/mach-mt8127/include/mach/mt_reg_base.h
but didn't seem to find anything usefull (I tried CRYPTO_BASE = 0x1101B000, but that doesn't work either)
k4y0z said:
It seems to just hang with both aes_read16 and aes_write16.
It is probably related to the CRYPTO_BASE.
I tried finding the correct one here: https://github.com/chaosmaster/andr...ch/arm/mach-mt8127/include/mach/mt_reg_base.h
but didn't seem to find anything usefull (I tried CRYPTO_BASE = 0x1101B000, but that doesn't work either)
Click to expand...
Click to collapse
So what you can do is download a firmware update for your device, load up the preloader in IDA (or a disassembler of your choice) and search for "hw sha". You should see it used like this: https://i.imgur.com/1PcObV7.png. Then inside that function https://i.imgur.com/wvpq5Qm.png the first call is essentially hw_acquire, then hash, then hw_release. Going further https://i.imgur.com/D5Z9UoM.png. So the base in my case is 0x10210000. You should figure out at which point it hangs, if it's inside one of the while loops, make sure you call init() and hw_acquire() first (it's not always required, seems to be hw-dependent)
Porting the hack to Fire 7" 7th Generation
xyz` said:
So first of all make sure you're accessing bootrom mode and not preloader mode (Although if the preloader supports read/write, the exploit should work there as well, I just haven't tested it since on hd 8 8th gen none of preloaders support these). I suggest soldering on a UART adapter, then use 115200 baud rate. When in bootrom dl mode, you should see "[DL] 00000BB8 444C0005 010701" (basically, the "[DL]" part is the important one)
If it's a different soc, you will have to dump the bootrom and find the offset where range check data is stored (in my case, 0x102868). You might have to modify the 4dd12bdf0ec7d26c482490b3482a1b1f part as well, it's basically calculated as a xor of expected data and actual data it's written. Then, you'll also need to update the pointer I'm overwriting (0x1028A8 in my case, called ptr_send in brom-payload). Again, if executing under preloader it's gonna be completely different way to exploit it.
Once all this is done, you should be able to load binary payloads and execute them in bootrom mode. You'll also need to edit brom-payload and set up proper pointers to send_dword/recv_dword/etc, these can be found by reversing your bootrom dump. At this point it should be possible to get emmc read/write.
Finally, if you want a persistent unlock (and not just the ability to modify /system) you'll need to port lk exploit as well. So you'll have to figure if your lk is vulnerable to the same bug, port microloader, inject_microloader.py and lk-payload to use the proper offsets. It's a lot of work.
I'll hopefully finish my writeup in the next weeks and post a link to it, that should be easier to understand since I'll explain the whole process from start to finish.
You're right about being able to load a custom preloader/lk, however the bootrom exploit requires a PC connection and a bunch of USB commands (so in a way, it's "tethered"). The actual unlock exploit isn't using any bootrom bugs, but rather the lk bug, since that one works without a PC. In fact, the bootrom exploit is only used to flash stuff to eMMC (but, of course you could probably do more fun stuff with it) in my chain.
Click to expand...
Click to collapse
That was smart of you @xyz a genial solution.
You have proven that the "chain of trust" was a joke.
Many have said that what we were trying was impossible.
Did you realize on the 7" 7th Gen there are RST and EINT pads on the back of the photo I sent ?
Can we port your method to the 7th Gen by using RST instead of CLK to stop the MCU accessing the EMMC ?
Also the "watchdog" you disabled is on the RTC device of the MT6323 PMIC chip which in turn is on the I2C bus.
I can write to the I2C bus using a Bus Pirate v4, I already tried some write and seems I can do that too as an alternative.
Again the pads for accessing the I2C bus are on the back of the PCB of 7th Gen. tablets, they are labelled SCL2 and SDA2.
In a couple of week, or less, you have shown that Lab126 didn't deserve all that money for such a fake security mechanism.
I confirm that zeroing the "preloader" in "mmcblk0boot0" also forces the MCU to enter [DL] mode.
I was sure that investing time on the the [DL] mode would have paid back.
Again congratulation for the achievement and thank you for the time you have put on this.
.:HWMOD:.
hwmod said:
Did you realize on the 7" 7th Gen there are RST and EINT pads on the back of the photo I sent ?
Can we port your method to the 7th Gen by using RST instead of CLK to stop the MCU accessing the EMMC ?
Click to expand...
Click to collapse
I haven't tried with RST. Try it and see if you get a "[DL]" message on uart, if you do then it should work.
hwmod said:
Also the "watchdog" you disabled is on the RTC device of the MT6323 PMIC chip which in turn is on the I2C bus.
I can write to the I2C bus using a Bus Pirate v4, I already tried some write and seems I can do that too as an alternative.
Again the pads for accessing the I2C bus are on the back of the PCB of 7th Gen. tablets, they are labelled SCL2 and SDA2.
Click to expand...
Click to collapse
Yeah, I haven't investigated the watchdog too much. I don't think there's anything interesting you can do with it though.
hwmod said:
In a couple of week, or less, you have shown that Lab126 didn't deserve all that money for such a fake security mechanism.
I confirm that zeroing the "preloader" in "mmcblk0boot0" also forces the MCU to enter [DL] mode.
I was sure that investing time on the the [DL] mode would have paid back.
Click to expand...
Click to collapse
To be fair to lab126 all of the fail lies solely on mediatek. The bootrom code amazon probably doesn't even have access to, and LK is likely based on mediatek sources (although, it's a really obvious bug in image loading, come on). The boot chain is reasonably secure in its design, it's only the implementation that's flawed.
xyz` said:
So what you can do is download a firmware update for your device, load up the preloader in IDA (or a disassembler of your choice) and search for "hw sha". You should see it used like this: https://i.imgur.com/1PcObV7.png. Then inside that function https://i.imgur.com/wvpq5Qm.png the first call is essentially hw_acquire, then hash, then hw_release. Going further https://i.imgur.com/D5Z9UoM.png. So the base in my case is 0x10210000. You should figure out at which point it hangs, if it's inside one of the while loops, make sure you call init() and hw_acquire() first (it's not always required, seems to be hw-dependent)
Click to expand...
Click to collapse
Sadly i don't have the IDA decompiler, so just assembler it is :/
I did however find the correct CRYPTO_BASE I believe:
Code:
CRYPTO_BASE = 0x11010000
that gives the following output with aes_read16:
Code:
b'\x07\x00\x00\xea\xfe\xff\xff\xea\xfe\xff\xff\xea\xfe\xff\xff\xea'
aes_write16 now fails with "RuntimeError: ERROR: Serial protocol mismatch".
Can i dump the boot-rom with this now?
First of all, congrats and big thanks!
So, any hope for the 2017 HD8?
k4y0z said:
Sadly i don't have the IDA decompiler, so just assembler it is :/
I did however find the correct CRYPTO_BASE I believe:
Code:
CRYPTO_BASE = 0x11010000
that gives the following output with aes_read16:
Code:
b'\x07\x00\x00\xea\xfe\xff\xff\xea\xfe\xff\xff\xea\xfe\xff\xff\xea'
aes_write16 now fails with "RuntimeError: ERROR: Serial protocol mismatch".
Can i dump the boot-rom with this now?
Click to expand...
Click to collapse
Yeah, just go through all of the bootrom memory (0 to 0x20000, just to be sure, in 16 byte increments), call aes_read16 on it, concatenate everything and you'll get your bootrom dumped. It should end with a bunch of FF bytes so that's how you can tell the actual size.