WM6 for Tornado
ALPHA RELEASE!
The link is now BROKEN as I have had to take down the ALPHA version to make way for the test BETA that I've made available to a few people for preliminary testing.
Note: This is in no way a finished product, some stuff still might not work, but as far as Tornado ROM's go in terms of speed and reliability, it runs like sh!t off a shovel
But we take no responsibility for any catastrophies that might occur eg. you brick your phone, your dog dies, your girlfriend gets pregnant etc. etc.
This ROM was developed entirely in our free time between college and university, there's no need to pay us for that, but a donation would be nice. If you wish to do so, then please click HERE
To Do:
MMS
HTC Camera App
Remove remaining HTC debug apps
Changed:
Fixed WiFi problems
Fixed Audio problems
Fixed GPRS issues (IPL 2.00, SPL 2.00.0008 and Radio 4.1.13.28_02.61.01 included in the NBF to sort this out)
Custom splash screen
Voice Command in ROM
xT9 cab (must install BEFORE the lanugage pack)
xT9 Language pack with 14 different languages
HTC Task Manager cab
HTC Comm Manager cab (unfortunately, bluetooth settings don't work yet)
HTC Clear storage cab
SP5 and SP5m button fixes as cabs
I will embed these cabs at a later date, however atm, I don't have time so I've just dumped the i-mate SP5 ROM and cab'd up a few apps you all wanted.
Phil
Flashing instructions are as follows:
NOTE: This will work on vista providing you have followed the Vista RUU guide HERE or HERE
For those getting the "Not Allow Operation" error in TeraTermPro, or, even worse, getting stuck in bootloader after flashing. You MUST superCID your device using the SPV-Sevices client! This step is NOT optional and could result in your phone becoming a brick if anything goes wrong
1. Make sure you device is SuperCID, you can check using the SPV Services client, if on reading the CID it displays 3131313131313131 in a long string of numbers then it IS CID unlocked, if not, the click the CID = 11111111 button and reset your device
2. Download the ROM linked in the first post
3. Download the attached TeraTermPro.zip
4. Disable USB connections in ActiveSync (right click the icon in the systray, then select connection settings and untick the USB connections box), turn off your device, hold camera ad plug the device into the USB port to enter bootloader mode.
5. Extract TeraTermPro.zip and run ttermpro.exe, then select Serial and then USB in the drop down box. Then type:
Code:
info 2
You will then probably get the following output:
Code:
info 2
GetDeviceInfo=0x00000002
+ SD Controller init
- SD Controller init
+StorageInit
CMD55 failed
+ SD Controller init
- SD Controller init
+StorageInit
CMD55 failed
HTCSSuperCID ' HTCE
Cmd>
If you don't see HTCSSuperCID ' HTCE above the Cmd> prompt then your device isn't SuperCID. You must use the SPV Services Client to make your device SuperCID as instructed in step 1
6. Type
Code:
format BINFS
This will then output:
Code:
Cmd>format BINFS
Format BinFS partition.
Format is completed!!
Cmd>
7. Now type:
Code:
ResetDevice
You device will then reboot, display the splash screen for around 2 seconds before running into the bootloader again. This is normal.
8. Extract WM6TornadoALPHA.zip then run ROMUpdateUtility.exe in the RUU folder.
9. Wait while it flashes your device
10. Install the extras you want in the 'extra stuff' folder, I recommend you install comm manager, task manager and xT9 as these solve most of the WiFi and T9 icon issues people are expericencing
11. Done
Phil
Thanks go to:
duke_stix
Faria
c4software
tadzio
anichillus
molski
bepe
Speacial thanks to pyrorob and bogdi1988 for their contributions since release
And last but certainly by no means the least, our anonymous sources, who, without their trust, we would have never got anything to cook
Sick of reading?
DOWNLOAD ALREADY!
The link is now BROKEN as I have had to take down the ALPHA version to make way for the test BETA that I've made available to a few people for preliminary testing.
So far, my site has had around 74GB of traffic just from that one file!
This ROM was developed entirely in our free time between college and university, there's no need to pay us for that, but a donation would be nice. If you wish to do so, then please click HERE
Phil
And i am HERE!!
I'm sorry but how can I delete this reply...
I'll sticky that thread for now. Congratz on that wm6 for tornado btw.
That will be the day.
vista help please...
i know u r very busy trying to release the alpha, but could you post any instructions for the people using Vista? how to flash and what do we need to be able to run WM6 with Vista
thanks again for all of the work
I'll get started on 'apps' for WM6!
@bogdi1988 - Updated second post
Phil
jm012a9749 said:
@bogdi1988 - Updated second post
Phil
Click to expand...
Click to collapse
THANKS A BUNCH!!!
one more question what do i use to change the cid?
bogdi1988 said:
THANKS A BUNCH!!!
one more question what do i use to change the cid?
Click to expand...
Click to collapse
Unlock your phone first, then use SPV-Services to change the cid.
See SDA Application Unlock and SPV-Services in the attachments.
was just testing out to see if i can connect via teratermpro.
and it seems i cant. ? :s
Shot at 2007-07-16
Shot at 2007-07-16
fixed the issue seems that tertermpro tools doesnt seem to connect or work for me.
so i used mytt 142.exe application
Turn off the phone and disconnect USB
Press Camera button and holding it insert USB connector (or holding Camera button press Power button for 1-2 seconds).
When "Need an UI (0)?" appears on the screen press [0] immediately. You will see tricolor screen, in the blue zone there will be "Typhoon IU" message, if you see "Typhoon XIP" you were late to press [0], start from beginning.
Run mtty1.42.exe from archive, choose [USB], press Enter and you will see a prompt.
Will this method work if I don't want to SuperCID as my warranty is not over yet?
"Here is how I got the rom to install without the devauth error.
1) use a hex editor on the rom file and search for the devauth.exe string e.g. 44 00 65 00 76 00 41 00
2) between the "devauth" and the "exe" you will see the hex "00 2e".
3) swap these bytes around so they are "2e 00" instead of "00 2e".
4) This will keep te same checksum but will not allow the devauth.exe to run. well it work in my case at least"
Hope it works
Click to expand...
Click to collapse
is it work on my
Imate SP5m \
running Windows Mobile 5
what about downgrade to WM 5.0?
nice work.thx!
Hello
Where is the ROM??
Can anyone post the link please?
thx
The Rom Will Be Posted In The First Page When It Is Ready, Now They Are Just Packing The Rom, So Please Be Patient
i heard that super cid doesn't work with internet explorer 7, is that true?I set cid=111111111 and when i enter in spv_services again it shows me the old cid
NOTE: full jtag instructions to unbrick or root devices can be found on the cyanogen mod wiki:
http://wiki.cyanogenmod.com/index.php/JTAG_DREAM_AND_MAGIC
----
Any G1 user disappointing believing they are unable to use the latest buggy 1.5 cupcake android release from rogers.. look no further.
With a 2005 series SPL all you need to do to successfully use this spectacular firmware on your phone is:
1) extract the rom.nbh form the windows installer;
2) enter fastboot mode on your phone and run "fastboot flash nbh rom.nbh"
This flashes the Official Rogers firmware on your phone in all its glory; including:
1) bad battery life
2) internet that drops periodically even in strong signal.
3) old version of android (1.5)
4) no apps2sd
http://twitpic.com/19p2wm - Home Screen
http://twitpic.com/19p355 - Rogers boot logo
http://twitpic.com/19p397 - About Screen
http://twitpic.com/19p3bm - SPL (close)
http://twitpic.com/19p3gk - SPL (again)
-----
So now you are asking ... why did I do this.. mostly because (as the wires show) The phone is already jtaged And I intend to use it to show how to remove the firmware via jtag. (hopefully tomorrows posting)
However its interesting to note the T-Moblie G1 *CAN* run the EBI1 radio 3.22.26.17 with related EBI1 port and SPL. (I do recommend that if you care to test EBI1 ports on a G1 ... make it a rooted rom not the rogers one)
----
Edit: Brick->Alive .. Rogers->custom a A phone's journey is posted..
While many technical details are provided this is *not* intended as a solution for all. as it requires some skill and equipment to utilize jtag. openocd is used for its relative cheapness and open source nature. Other products will likely work just as well but may need some minor process changes.
How to remove the post 911 firmware via jtag right?
(ROM version 1.89.631.1 Rogers)
Newbies please do not threadcrap this asking for unbrick for your G1 yet. As of right now this method is still not just for everyone.
Original JTAG thread for more info: http://forum.xda-developers.com/showthread.php?t=591048
xaueious said:
(ROM version 1.89.631.1 Rogers)
Click to expand...
Click to collapse
That is what the phone says it is on the about screen (not surprised I did flash the full nbh)
I was asking because you didn't mention which one you were talking about. There was also that old pre 911 nbh, ROM version 1.85.631.5 for Rogers. This rom worked with flashrec (one-click root).
I still know very little about JTAG but I thought I might as well post some of the SPL/radio combinations here with some links.
A link to the old Rogers ROM is here for future reference for any Rogers Dream users to return to a rootable stock image for some reason: http://forum.xda-developers.com/showthread.php?t=625073
Contains stock pre-911 update Rogers ROM with
HBOOT Version 1.33.0009
Radio Version 3.22.20.17
* * * Reference Recommended SPL + Radio Combinations * * *
Anyhow if everything works... Useful links for SPL, radio and recovery flashing:
Rogers Dream Info for Reference, no Rogers Waiver Signed
Upgrade to 3.22.26.17 if you haven't signed the waiver or don't want to. This makes your phone incompatible to most ROMs in this thread until you flash a 'kernel port' update file.
Needs Amon_RA G1/Dream recovery version R
So target would be:
HBOOT VERSION: 1.33.2005
RADIO VERSION: 3.22.26.17
Rogers Dream Info for Reference, Rogers Waiver Signed OR T-Mobile G1
This radio makes the phone work with most G1 ROMs you can find on these forums.
Needs Amon_RA non-R G1/Dream recovery or Cyanogen's G1/Dream recovery
HBOOT VERSION: 1.33.2005
RADIO VERSION: 2.22.23.02
* * * Download Links for Relevant Files * * *
Amon_RA Recovery for G1/Dream
http://forum.xda-developers.com/showthread.php?t=566669
Radio 2.22.23.02
T-Mobile G1 radio. EBI0 kernel. Makes the G1/Dream compatible with most ROMs posted in this forum.
http://forum.xda-developers.com/showpost.php?p=5763943&postcount=1
Radio 3.22.26.17
T-Mobile G1 radio. EBI1 kernel (aka Magic 32A old radio kernel). Makes the G1/Dream incompatible with most ROMs posted in this forum until you flash an additional kernel (kernel port). Allows for flashing of Magic old radio ROMs if ROM is not too large for the G1/Dream's internal flash memory.
http://wiki.cyanogenmod.com/index.php/Upgrade_Rogers_Dream_Radio#Preparations
SPL/HBOOT 1.33.2005
Also Danger/Death SPL. Originally for Sapphire/Magic but has support for Dream to increase size of /system partition. Prerequisite for some ROMs.
http://sapphire-port-dream.googlecode.com/files/spl-signed.zip
Or here:
http://wiki.cyanogenmod.com/index.php/Upgrade_Rogers_Dream_Radio#Preparations
xaueious said:
I was asking because you didn't mentioned which one you were talking about. There's also that old pre 911 nbh aka ROM 1.85.631.5 Rogers.
Now this ROM might be good for your procedure for Rogers Dream users. It's here by the way in case you didn't have a link: http://forum.xda-developers.com/showthread.php?t=625073
Click to expand...
Click to collapse
Yes, that should be just as good (and you will have a way to root without jtag just in case ). I believe that it is the exact same SPL and slightly different radio (might matter for jtag though). The only reason we were able to root this rom was because of the kernel exploit.
A phones Journey
So a short recap for those not following along in the various threads.
The T-Mobile Phone in question
I've recently (off ebay) got a bricked HTC T-Mobile G1. (failed attempt to install the 2005 SPL.. (**sidenote)
Given it was a cheap phone it was a good candidate for jtag testing; after shorting something out on previous jtag work on my rogers dream. (the jtag port is the same on both phones.. and it did work on the dream for a bunch of tests before the incident)
Details of the de-brick are on this threadRogers Rom
Given the phone already has jtag attached (a little bit of a painful process) I decided to try unrooting a rogers rom on it before going to any other phone. So I took the nbh from the rogers installer (I still have the original 1.89.631.1 rom.nbh from when I created the hacked version which skipped the spl/splash1 portions of the flash.)
This flashed from the 2005 SPL without incident making the T-Mobile phone running a full rogers stack (splash image included) see op post for images of the phone/rom in this mode.Unroot (I know this is what you are here for)
(Note an updated version of this process now exists on a wiki: http://wiki.cyanogenmod.com/index.php/JTAG_DREAM_AND_MAGIC )
So now with a fully locked SPL in place and jtag already set up time to hack out of the rogers rom to an EBI1 port!!
Prerequisites:
A) phone running locked roger rom 1.89.631.1 (actually as listed it will work for any rom on radio 3.22.26.17 and with offsets in my de-brick post other radios.
B) Jtag adapter.. I'm using OLIMEX ARM-USB-OCD.. however others will work as well.. my steps assume the openocd program on your computer which supports many USB/ParPort adapters. (my current cfg hopefully will improve but works for this hack.. note its for version "Open On-Chip Debugger 0.4.0" not the old cvs/svn version that is on the CD with the hardware)
C) outfit phone with jtag adapter.. this i will leave to another topic.. see the Jtag thread for the test points.
D) A HTC Serial wire.. I recommend without the +5 power line since blue light mode is sometimes hard to enter while the device is charging.. (information on my wire with links to parts. If you wish you can also attatch a USB wire to the USB leads which allows you to see serial output while flashing.. but ensure you can have the USB unplugged while the oemspl serial is in use.
E) 2005 SPL *.img file extract it from the zip file: http://sapphire-port-dream.googlecode.com/files/spl-signed.zip
MD5 (hboot.img) = cdf75d34e24937da1a8a84bcd72496c3
F) Recovery *.img .. your favorite flavor of '-R' version from this thread: http://forum.xda-developers.com/showthread.php?t=566669
G) a sense of adventure
Procedure:
1) Ensure the jtag adapter is hooked up to the phone
2) power on phone into blue light mode
3) attach serial wire
4) connect to serial console (mtty in windows, "screen /dev/<serial device> 115200" in osx/linux)
5) start openocd or other jtag application (openocd -f dream.cfg)
6) start telnet to the ocd: "telnet localhost 4444"
7) run the following:
Code:
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
Open On-Chip Debugger
> [color=blue]halt[/color]
target state: halted
target halted in ARM state due to debug-request, current mode: Supervisor
cpsr: 0x200000d3 pc: 0x0090861c
MMU: disabled, D-Cache: disabled, I-Cache: disabled
> [color=blue]mww 0x0090379C 0xea000013[/color]
> [color=blue]mww 0x9029d8 0x0[/color]
> [color=blue]load_image [b]<pathto>[/b]/hboot.img 0x0[/color]
No working memory available. Specify -work-area-phys to target.
no working area available, falling back to memory writes
524288 bytes written at address 0x00000000
downloaded 524288 bytes in 11.635834s (44.002 kb/s)
> [color=blue]mww 0x00000c0c 0x98000C4C[/color]
> [color=blue]mww 0x00000c08 0x98000C4C[/color]
> [color=blue]mww 0x00000c04 0x98000C4C[/color]
> [color=blue]mww 0x00000c00 0x98000C4C[/color]
> [color=blue]resume[/color]
The offsets are based off my de-brick post
* 0x0090379C is the CID bypass point for 3.22.26.17
* 0x009029d8 is 4 less than the previously defined breakpoint for 3.22.26.17 SPL modification (for other radios subtract 4 from my breakpoint location);
This is the location of a subroutine call to load the SPL.. since we are going to load it our self we want to nop the instruction.. no 0x0 is not the nop instruction.. but it will achieve the same results (and lack their of).
* load_image will load a file into the phones ram; point this at the hboot.img you downloaded as that is what we want to run
* 0x00000c00 to 0x00000c0c is the switch jump table in the 2005 hboot image once loaded for the boot mode.. we are forcing modes 0-3 to ruu/fastboot mode.
* then we can resume the CPU and optionally kill openocd.
8) into the serial termal run command "?" this ought to now output help on many commands (before it would only say invalid command)
9) run command "cego"
<phone will now boot into the ram image of 2005 SPL; display splash image (if screen is connected) and enter fastboot mode>
10) remove serial wire and attach USB wire.. or plug in usb part of USB/serial hybrid wire.
12) "fastboot flash hboot hboot.img"
13) "fastboot flash recovery recovery.img" (the ebi1 RA recovery)
14) "fastboot oem powerdown"
Now you can boot into recovery and flash your favorite EBI1 rom.. or if you don't like EBI1.. follow the EBI0 installation instructions
** sidenote: To packagers and those making processes.. Given all I have seen to date.. whenever possible flash radios and SPLs via fastboot not recovory zip files..
If you are stuck on a splash screen on boot.. both the SPL and radio are working.. they are just usually stuck in an invalid mode.. which is less likely to happen if flashed by fastboot.. this particularly applies where the 2005 SPL is involved.
Hacking can be fun.. but this hacking is not cheap
If interested donations are accepted
I wonder why no one's responding to this thread. This is great news!
I agree that this is good news. Just bought a slightly used Dream and it was. Just my luck that the previous owner ran the mandatory update shortly before selling it.
I am a little unsure about the process though. Does the jtag involve physically modifying the phone? If so, is there any chance that this method will lead to a non-jtag way of getting around the perfect SPL?
SilentTweak said:
I wonder why no one's responding to this thread.
Click to expand...
Click to collapse
Because most of newbies here doesn't have idea about what is talking ezterry with his method
I might be motivated to try this if I actually had a brick. If I buy a Dream I might look into this.
For now I am not motivated to get my own jtag working. ezterry and other fellow xdaers on the other thread seem to be trying to find a method that doesn't require soldering.
Dreaming
I would be willing to try this on the $100 Dream i picked up, but the only thing is spending another $50-$100 on JTAG and serial cable equipment. which i might F#@CK the phone LOL
PS is it possible to use a cheap parallel port jtag to do this?, i think diffrent software would be required for the process though....any suggestions?
Thanks
Raymar23
raymar23 said:
I would be willing to try this on the $100 Dream i picked up, but the only thing is spending another $50-$100 on JTAG and serial cable equipment. which i might F#@CK the phone LOL
PS is it possible to use a cheap parallel port jtag to do this?, i think diffrent software would be required for the process though....any suggestions?
Thanks
Raymar23
Click to expand...
Click to collapse
No reason a parport adapter won't work, and openocd supports many part port adapters.
Also if you are more comfortable with other arm compatable software it ought to be easy to port the steps.. its just ram writes.
I just don't own any computers I can plug in Part port devices anymore.
scholbert from the other jtag thread may be able to give more info.
http://www.diygadget.com/universal-jtag-adapter-for-routers-modem-fta-and-more.html
Could I use this JTAG adapter? Or is there another adapter on this site I can purchase to do this process? I'm thinking of buying a couple bricked phones and trying this out lol
SilentTweak said:
http://www.diygadget.com/universal-jtag-adapter-for-routers-modem-fta-and-more.html
Could I use this JTAG adapter? Or is there another adapter on this site I can purchase to do this process? I'm thinking of buying a couple bricked phones and trying this out lol
Click to expand...
Click to collapse
Looks like a 74HCT244....
I posted a link to a schematic for what is really the exact same thing -- should be in the other thread. It takes about 10 minutes to solder one of those up and you can make it for $2 in locally acquired parts.
Hey,
ezterry opened up another hacker thread...
Nice work mate
Anyway here's a schematic and some comments i once posted at the original JTAG on Dream thread.
http://forum.xda-developers.com/showpost.php?p=5110255&postcount=37
It's low cost LPT-adaptor and works very well with the MSM IO voltage of 2.6V.
Feel free to re-distribute
Maybe some soft tweaks are needed to integrate in openocd.
Once made a patch... but it's lost somewhere.
Cheers,
scholbert
Thanks
ezterry said:
No reason a parport adapter won't work, and openocd supports many part port adapters.
Also if you are more comfortable with other arm compatable software it ought to be easy to port the steps.. its just ram writes.
I just don't own any computers I can plug in Part port devices anymore.
scholbert from the other jtag thread may be able to give more info.
Click to expand...
Click to collapse
Thank you very much for the insights and also for all your work and knowledge that has been shared with the community.
BTW. Anyone know where to buy a parallel port JTAG in Canada (i hate customs) lol
Thanks again to everyone who posts in these forums
lbcoder said:
Looks like a 74HCT244....
I posted a link to a schematic for what is really the exact same thing -- should be in the other thread. It takes about 10 minutes to solder one of those up and you can make it for $2 in locally acquired parts.
Click to expand...
Click to collapse
I was searching that schematic without luck, can you please post the link here?
thanks!
kR105! said:
I was searching that schematic without luck, can you please post the link here?
Click to expand...
Click to collapse
Anyway here's a schematic and some comments i once posted at the original JTAG on Dream thread.
http://forum.xda-developers.com/show...5&postcount=37
Click to expand...
Click to collapse
If you want a true wiggler clone, this isn't...
I'll prepare another schematic...
Regards,
scholbert
ezterry said:
So a short recap for those not following along in the various threads.
The T-Mobile Phone in question
I've recently (off ebay) got a bricked HTC T-Mobile G1. (failed attempt to install the 2005 SPL.. (**sidenote)
Given it was a cheap phone it was a good candidate for jtag testing; after shorting something out on previous jtag work on my rogers dream. (the jtag port is the same on both phones.. and it did work on the dream for a bunch of tests before the incident)
Details of the de-brick are on this threadRogers Rom
Given the phone already has jtag attached (a little bit of a painful process) I decided to try unrooting a rogers rom on it before going to any other phone. So I took the nbh from the rogers installer (I still have the original 1.89.631.1 rom.nbh from when I created the hacked version which skipped the spl/splash1 portions of the flash.)
This flashed from the 2005 SPL without incident making the T-Mobile phone running a full rogers stack (splash image included) see op post for images of the phone/rom in this mode.Unroot (I know this is what you are here for)
So now with a fully locked SPL in place and jtag already set up time to hack out of the rogers rom to an EBI1 port!!
Prerequisites:
A) phone running locked roger rom 1.89.631.1 (actually as listed it will work for any rom on radio 3.22.26.17 and with offsets in my de-brick post other radios.
B) Jtag adapter.. I'm using OLIMEX ARM-USB-OCD.. however others will work as well.. my steps assume the openocd program on your computer which supports many USB/ParPort adapters. (my current cfg hopefully will improve but works for this hack.. note its for version "Open On-Chip Debugger 0.4.0" not the old cvs/svn version that is on the CD with the hardware)
C) outfit phone with jtag adapter.. this i will leave to another topic.. see the Jtag thread for the test points.
D) A HTC Serial wire.. I recommend without the +5 power line since blue light mode is sometimes hard to enter while the device is charging.. (information on my wire with links to parts. If you wish you can also attatch a USB wire to the USB leads which allows you to see serial output while flashing.. but ensure you can have the USB unplugged while the oemspl serial is in use.
E) 2005 SPL *.img file extract it from the zip file: http://sapphire-port-dream.googlecode.com/files/spl-signed.zip
MD5 (hboot.img) = cdf75d34e24937da1a8a84bcd72496c3
F) Recovery *.img .. your favorite flavor of '-R' version from this thread: http://forum.xda-developers.com/showthread.php?t=566669
G) a sense of adventure
Procedure:
1) Ensure the jtag adapter is hooked up to the phone
2) power on phone into blue light mode
3) attach serial wire
4) connect to serial console (mtty in windows, "screen /dev/<serial device> 115200" in osx/linux)
5) start openocd or other jtag application (openocd -f dream.cfg)
6) start telnet to the ocd: "telnet localhost 4444"
7) run the following:
Code:
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
Open On-Chip Debugger
> [color=blue]halt[/color]
target state: halted
target halted in ARM state due to debug-request, current mode: Supervisor
cpsr: 0x200000d3 pc: 0x0090861c
MMU: disabled, D-Cache: disabled, I-Cache: disabled
> [color=blue]mww 0x0090379C 0xea000013[/color]
> [color=blue]mww 0x9029d8 0x0[/color]
> [color=blue]load_image [b]<pathto>[/b]/hboot.img 0x0[/color]
No working memory available. Specify -work-area-phys to target.
no working area available, falling back to memory writes
524288 bytes written at address 0x00000000
downloaded 524288 bytes in 11.635834s (44.002 kb/s)
> [color=blue]mww 0x00000c0c 0x98000C4C[/color]
> [color=blue]mww 0x00000c08 0x98000C4C[/color]
> [color=blue]mww 0x00000c04 0x98000C4C[/color]
> [color=blue]mww 0x00000c00 0x98000C4C[/color]
> [color=blue]resume[/color]
The offsets are based off my de-brick post
* 0x0090379C is the CID bypass point for 3.22.26.17
* 0x009029d8 is 4 less than the previously defined breakpoint for 3.22.26.17 SPL modification (for other radios subtract 4 from my breakpoint location);
This is the location of a subroutine call to load the SPL.. since we are going to load it our self we want to nop the instruction.. no 0x0 is not the nop instruction.. but it will achieve the same results (and lack their of).
* load_image will load a file into the phones ram; point this at the hboot.img you downloaded as that is what we want to run
* 0x00000c00 to 0x00000c0c is the switch jump table in the 2005 hboot image once loaded for the boot mode.. we are forcing modes 0-3 to ruu/fastboot mode.
* then we can resume the CPU and optionally kill openocd.
8) into the serial termal run command "?" this ought to now output help on many commands (before it would only say invalid command)
9) run command "cego"
<phone will now boot into the ram image of 2005 SPL; display splash image (if screen is connected) and enter fastboot mode>
10) remove serial wire and attach USB wire.. or plug in usb part of USB/serial hybrid wire.
12) "fastboot flash hboot hboot.img"
13) "fastboot flash recovery recovery.img" (the ebi1 RA recovery)
14) "fastboot oem powerdown"
Now you can boot into recovery and flash your favorite EBI1 rom.. or if you don't like EBI1.. follow the EBI0 installation instructions
** sidenote: To packagers and those making processes.. Given all I have seen to date.. whenever possible flash radios and SPLs via fastboot not recovory zip files..
If you are stuck on a splash screen on boot.. both the SPL and radio are working.. they are just usually stuck in an invalid mode.. which is less likely to happen if flashed by fastboot.. this particularly applies where the 2005 SPL is involved.
Hacking can be fun.. but this hacking is not cheap
If interested in giving a donation feel free to contact me
Click to expand...
Click to collapse
how build device to reflash dead G1 ? electro scheme?
some buy exterry the solderless jtag adapter
mentioned in the other post
or he will end up with a huge collection of phones
I'll even chip in
my dream is fine and rooted but my magic was shipped the rogers ways
so I am waiting with great hopes for the jtagless option
and more than willing to help where I can
My phone is only three color mode, if i switch on. I try different rom upgrade but nothing. What i can do?
A little more information is needed:
What does the 3 color screen tell?
What happens if you execute a ROM update?
How do you try to make the ROM update, shipped ROM (which) or a cooked ROM (which)?
Has the device ever worked?
Which ROM was on the device before it got stuck in bootloader (3 color screen)?
Tri-color screen meant by bootloaderit (red, green, blue). When I try to update the ROM, it shows that it would be done, but the re-launch the bootloader all the time. Try a different ROM, which is designed for the HTC Qtek 8310 and the Tornado. WM6, WM61 and WM65. WM5 device worked before, more detailed version i dont know. letter on the screen IPL: 2.00 SPL: 2.00.0009
It seems that the loaded ROM does not succeed to load. If you load a shipped ROM everything outlined below should be done automatically for you, so if that does not work as well, then the device may be broken. So check first if you can load a shipped ROM again.
For cooked ROMs you need to prepare the BINFS to match the size of a ROM before you load it. As you succeed in loading any ROM, the device seems to be CID unlocked already. Check the following:
Connect the device in bootloader mode. Switch off, then keep camera button pressed and insert USB cable.
Disable USB for Active Sync (Connection settings of AS).
startup a terminal program that can connect via USB (e.g. TTerm pro)
connect ot the USB port
press enter
Command prompt appears
enter "info 2" (no quotes) enter
read the last line, it should give something like "HTC SuperCID". If not, then you must CID unlock the device first. Lookup the relevant threads for the cooked ROMs or search for Lokiwiz.
If the device is already SuperCID, then you must match the BINFS formatted size to be larger or equal the ROM size (OS partition). For most cooked ROMs it is the binary file size. Relevant actions are also described in some cooked ROM threads, e.g. mine - see my signature.
What is shipped ROM? Original Rom? I do not have it.
Tera Term
info 2
GetDeviceInfo=0x00000002
+ SD Controller init
- SD Controller init
+StorageInit
CMD55 failed
+ SD Controller init
- SD Controller init
+StorageInit
CMD55 failed
HTCSBPT_0501 Lqœ»HTCE
I try unlock SuperCID with program lokiwiz02b.
But nothing happend.
machinagod's HTC Wizard Unlocker v0.2
NOW WITH CID Unlocking POWER!
--------------------
WARNING: This tool is highly experimental!
I will NOT be held responsible for any problems caused by this tool.
--------------------
Thanks to xda-developers, spv-developers, and especially itsme by the work they
released. This solution would not be possible without them.
--------------------
U. Unlock
L. Lock
C. CID Unlock (SuperCID)
Q. Quit
--------------------
Type the letter and press Enter: c
CID unlocking mobile... DO NOT DISCONNECT UNTIL THE PHONE REBOOTS!
What i try next?
IF your OS is not up, then the lokiwiz will not do anything to your device!
With THIS status you should not succeed in doing any update or format your BINFS. You first need to get the original OS up and running again before you van get any further on changing your OS. The steps to take are:
Get old OS running up again
Application unlock the old OS
CID unlock the device (backup your *.bin files!)
load new OS
1.) is your problem currently. There are several ways to achieve this, try a hard-reset first, this should work for your device:
switch off device
press L+R softkey and hold both
switch on device and keep L+R softkey pressed
wait until prompt and act accordingly
device will reboot to OS
OK now?
I do not have the original OS or even the old OS. After a hard reset as well as the OS does not come up.
# Switch off the Device
# Softkey Press L + R and hold Both
# Switch the device and keep L + R softkey presses
Press 0 to restore factory default. Other key to exit
I press 0
After hard reset load the bootloader again.
OK, then you need to load the CID matching old OS via the shipped ROM standard procedure. Look to: http://www.shipped-roms.com/shipped/Tornado/ and get 8310_2090_253121_020900_to_dan_eur_ship.exe
Execute it on the PC while the device is connected in bootloader mode. If that does not work, then try other ROMs in the same directory until you succeed with the loading.
Mind that a first boot takes 3-5 minutes, so be patient if the bootloader is not coming up any longer. Also do not interrupt the ROM loading in the first steps when the upload has started. It is normal that there are phases where the progress bar does not move. I think the sequence is per partition (IPL, SPL, Splash, OS): load to RAM (bar progressing), load from RAM to ROM = flashing (no bar progress, but color change of bar at the end). The large OS partition is loaded at the end of the sequence so the second step will take some time - be patient.
Good luck!
I try all ROM's but always give me ERROR 294 INVALID VENDOR ID.
And now the phone does not start anymore. No picture. I dont know what happend
This seems to prove that the device has something broken.
Make sure that the battery gets charged while the device is off. Despite the device was connected to USB all the time there is no charging happening in bootloader mode. Wait until the green light is there again before you continue - power drain in bootloader mode is quite heavy.
When none of the shipped ROMs work for upload, it really gets hard to load back an OS running on that for further steps :-(
There is a procedure called "Gold Card method", the rough procedure is (only did that once years back - so this is no step-by-step guide):
Prepare the card so that the bootsector contains the magic device specific "Gold Card" signature. For that you need a trial version of PSAS, and a working windows mobile device(!).
then you would have to load the *.nbh file that gets uploaded to the device (and fails) to that mini-SD card root directory,
rename it to TORNIMG.NBH there
load the card to the device,
then reboot to bootloader (Camera + on)
and hope it gets it loaded
A detailed procedure is described for the Excalibur device but this works equally well for Tornado if you adjust the relevant parts (PSAS is the success of QMAT). Mind that the miniSD card should be in really good condition (fresh full format, check that the file loaded can be read byte-identical from it). If the loading from the card fails or corrupts the IPL/SPL while loading then your device is really bricked. It happened to me with an Excalibur (read the whole thread linked above) - so be extra careful (though - what do have to loose?)!
Hello all, I've been trying to root my Droid Maxx 4.4.4 SU6-7 and was working fine until after bricking it, I was unable to run the RUN_Root.bat. I'm running Windows 7 64 bit. This is the error I would get in the command prompt after trying to run RUN_Root.bat .
C:\Python27>python qdloadRoot.py MPRG8960.bin -ptf _root/partitions.txt
QDLoad utility version 1.2 (c) VBlack 2014
Found TTY port: com9
Requesting Params...
Params:
Version: 8
Min version: 1
Max write size: 1536 (0x00000600)
Model: 144
Device size: Invalid or unrecognized Flash device, or Flash device programming not supported by this implementation
Device type: Intel 28F400BX-TL or Intel 28F400BV-TL
Requesting SoftwareVersion...
Version: PBL_DloadVER2.0
Requesting SerialNumber...
Serial number: 00,00,48,03
Requesting HW Id...
HW Id: 00,00,48,03,e1,10,7e,00
Requesting PublicKey...
PublicKey: 39,c4,ee,3e,b5,be,eb,87,8e,2f,e3,b8,53,4d,14,6f,91 ,ca,fd,bb,94,2a,0d,aa,d0,1e,b0,87,62,d4,b9,b8
Uploading file 'MPRG8960.bin' to addr 0x2a000000...
Executing...
Could not find Qualcomm device in Emergency download mode
Done, with errors!!!
C:\Python27>pause
Press any key to continue . . .
I can still use the USB I think. I see Qualcomm HS-USB Loader 9008 (COM9) in the device manager whenever I would plug in the USB and it was manually updated after I selected x64 folder from the windows_drivers_QHSUSB_DLOAD folder(windows would say it was up to date when selecting x64 folder). I tried different ports but the Port otion never shows up for them in the device manager. I'm also not using USB 3.0.
I believe I followed every other instruction as far as I know from this thread http://forum.xda-developers.com/droid-ultra/general/droid-mini-maxx-ultra-root-pogress-100-t3071609 I'd really appreciate if someone could help me out.
Phoop said:
Hello all, I've been trying to root my Droid Maxx 4.4.4 SU6-7 and was working fine until after bricking it, I was unable to run the RUN_Root.bat. I'm running Windows 7 64 bit. This is the error I would get in the command prompt after trying to run RUN_Root.bat .
C:\Python27>python qdloadRoot.py MPRG8960.bin -ptf _root/partitions.txt
QDLoad utility version 1.2 (c) VBlack 2014
Found TTY port: com9
Requesting Params...
Params:
Version: 8
Min version: 1
Max write size: 1536 (0x00000600)
Model: 144
Device size: Invalid or unrecognized Flash device, or Flash device programming not supported by this implementation
Device type: Intel 28F400BX-TL or Intel 28F400BV-TL
Requesting SoftwareVersion...
Version: PBL_DloadVER2.0
Requesting SerialNumber...
Serial number: 00,00,48,03
Requesting HW Id...
HW Id: 00,00,48,03,e1,10,7e,00
Requesting PublicKey...
PublicKey: 39,c4,ee,3e,b5,be,eb,87,8e,2f,e3,b8,53,4d,14,6f,91 ,ca,fd,bb,94,2a,0d,aa,d0,1e,b0,87,62,d4,b9,b8
Uploading file 'MPRG8960.bin' to addr 0x2a000000...
Executing...
Could not find Qualcomm device in Emergency download mode
Done, with errors!!!
C:\Python27>pause
Press any key to continue . . .
I can still use the USB I think. I see Qualcomm HS-USB Loader 9008 (COM9) in the device manager whenever I would plug in the USB and it was manually updated after I selected x64 folder from the windows_drivers_QHSUSB_DLOAD folder(windows would say it was up to date when selecting x64 folder). I tried different ports but the Port otion never shows up for them in the device manager. I'm also not using USB 3.0.
I believe I followed every other instruction as far as I know from this thread http://forum.xda-developers.com/droid-ultra/general/droid-mini-maxx-ultra-root-pogress-100-t3071609 I'd really appreciate if someone could help me out.
Click to expand...
Click to collapse
Besides manually update the driver.
First, you have to disable the mandatory use of signed drivers in Windows.
Why? The driver you are trying to install (or update) is not signed and windows by default only allows the use of signed drivers.
Search a tutorial on "how to install an unsigned driver Windows 7"
I send you some, but I am the translator of google lol ..
I had a similar problem for the driver and the solution I gave you, solved my problem.
The best of luck, a big hug!
I managed to fix my problem yeasterday following br0adband advice in this thread http://forum.xda-developers.com/showpost.php?p=62651329&postcount=1159 sorry I forgot to close my thread(if I can figure out how). Thanks for that helpfull tip though, I'll keep that in mind for later driver issues.
{
"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.