Database Info

[Q] Trying to root SM-G920F using Linux

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

Cannot root & flash LineageOS 14.1 (v1awifi) with sequence in LineageOS wiki page

Cannot root & flash LineageOS 14.1 (v1awifi) with sequence in LineageOS wiki page
Presently I have an unrooted SM-P900
Android: v 5.0.2
Build: LRX22G.P900UES1CPL1
I am using a custom built desktop Windows 10 machine. At this point I don't know what else to try. I'm not a computer noob, but I am new to rooting and flashing Android ROMs. I'm hoping I can get help from the community.
The installation instructions I followed are on the Lineage OS wiki. I can't post the link because I have fewer than 10 posts here.
1. Success: Setup "adb" via instructions. Entered "adb devices" and got successful response.
2. Success: Enabled USB debugging on P900.
3. Success: Installed Heimdall Suite v 1.4.0. Found at Glassechidna website. Installed " Microsoft Visual C++ 2012 Redistributable Package (x86)" version 4. Typed "heimdall version" in 'Command Prompt' and got "1.4.0" in response.
4. Success: Next - 'Power' + 'Vol. Down' + 'Home' - to get into 'Download Mode' on the P900: Successful.
5. Success: Run "zadig.exe" [v2.0.0]. 'Options' menu, 'List all devices'. Found item called "Gadget Serial" that represents my tablet.
6. Success: In "zadig.exe", choose a 'driver' and click "Replace Driver" button.
a. The 'driver' options to choose from are: WinUSB (v6.1.7600.16385), libusbK (v3.0.4.0), libusb0 (v1.2.5.0).
b. In my efforts to be successful, I tried all 3 drivers.
7. FAIL: Test Heimdall Suite setup. Type "heimdall print-pit --verbose", if device reboots then Heimdall is installed and working correctly.
* This is the point in the installation process I can't get past. I get errors and my P900 does not reboot. In the 'Command Prompt' I see:
Initialising connection...
Detecting device...
Claiming interface...
Setting up interface...
Initialising protocol...
ERROR: Failed to initialise protocol!
** 'Verbose' mode returns more information than what I've shown. The 'Initializing protocol' step has failed with errors: -1, -7, -12 depending on the drivers I installed in Step 6. Those drivers are compiled into the "zadig.exe" program.
I have tried the following:
( 1 ) All three drivers in v2.0.0 of 'zadig.exe' listed above.
( 2 ) All four drivers in v2.3.701 of 'zadig.exe' which includes: WinUSB (v 6.1.7600.xxxx), libusb-win32 (v1.2.6.0), libusbk (v3.0.7.0), usb Serial (CDC).
( 3 ) USB 3.0 samsung cable in both USB 2.0 and USB 3.0 ports.
( 4 ) USB 2.0 Amazon cable in both USB 2.0 and USB 3.0 ports.
( 5 ) Repeated all previous steps with a Lenovo Ideapad Y470 laptop with Windows 10. Nothing different happened.
( 6 ) Reinitializing Android OS with Kies v3. Kies sees the P900. I can choose to 'update and reinitialize'. It presents a status bar showing it is downloading something. The tablet then goes into 'Download Mode'. But then I get an error that connection with the P900 was lost. Tried this with USB 2.0 / USB 3.0 cables and ports on desktop PC, same result.
My thoughts:
[ i ] There is a v1.4.2 of the Heimdall Suite. But only the source code is available. When I googled it I read of people having more success with that most recent version on other Android devices. But, I don't know the first thing about compiling the code into a Windows 10 executable. And I don't want to use Linux distro CD to run v1.4.2 because I know nothing about Linux OS.
[ ii ] I used 'Power' + 'Vol. Up' + 'Home' to reformat P900 into factory condition prior to all of these steps. But I thought that my tablet initially was 4.4.2 Android. I thought perhaps downgrading the Android OS to 4.4.2 might help, which is why I tried KIES. But even that does not work.
[ iii ] My initial motivation for doing this was to format my external SD card as internal. I know it will be slower, but that is ok. I just do not want to have storage limitations (I have 32 GB version). v 5.0.2 has immature options to achieve this on the P900. I couldn't simply format the external SD card as 'internal'. NO option to do so.
Thank you,
Bearacuda

UPDATE
I reached out to the LineageOS community on Reddit. AndyCGYan replied and told me he had compiled 1.4.2 windows versions of heimdall.exe and heimdall-frontend.exe. I asked him to share them with me. He did. In a command prompt I typed: "heimdall142 print-pit --verbose". The command prompt scrolled with a flurry of text and my SM-P900 rebooted from 'Download Mode'. It worked!
I'd feel better if the Glassechidna guy would compile his own software into a 1.4.2 windows product, but I'm grateful this guy responded.
Thanks AndyCGYan

UPDATE 2: SM-P900 flashed with TRWP and Lineage OS 14.1
I finished the process of flashing my SM-P900 to the Lineage OS v14.1 (20171125). Lineage OS v14.1 (20171202) gave the following error:
"adb: error: failed to get feature set: no device/emulators found"
But when I flashed the 20171125 version it worked. So I'm guessing there is a problem with the 1202 nightly.
The Windows compiled v1.4.2 version of Heimdall I received got me past the 1.4.0 print-pit problem. I don't have 10 messages posted here yet so I can't post the link to the files. But if you go to my post on Reddit in the Lineage OS forum you'll see the link. The person who made the files available to me said he'd keep the files there for others to download. Unless you compile them yourself, I don't know of anywhere else these can be obtained.
To clarify, here is the information regarding my SM-P900
Stock Android v5.0.2
Country: Cellular South (XAR)
PDA: P900UES1CPL1
CSC: P900XAR1CPL1
Kies 3.0 (to obtain most recent Windows Samsung device drivers)
ADB v1.0.39
Heimdall Suite (v1.4.0 with heimdall.exe (v1.4.2) and heimdall-frontend.exe (v1.4.2) replacing 1.4.0 versions)
TWRP v3.1.1-0-v1awifi
Lineage OS 14.1 - Android v7.1.2 - nightly version 20171125 (20171202 gave an error)
Open GApps - arm - v7.1 nano
addonsu - arm - v14.1
NOTE: Even though ADB was successfully setup, I was not successful pushing any files (TWRP, LineageOS, etc.) onto "/sdcard/". Trying so caused an error. I was able to:
( 1 ) remove my extSDCard (64gb Samsung) from the SM-P900,
( 2 ) plug it into my computer and copy over the TWRP, LineageOS, Open Gapps, and addonsu zip files to extSDCard
( 3 ) re-insert my extSDCard back into SM-P900
( 4 ) In TWRP recovery mode, there is an 'INSTALL' button that lets you select multiple zips from either internal or external SD storage. After selecting the zips on the extSDCard all of the files flashed over just fine.
NOTE: When the LineageOS instructions tell you to reboot into recovery mode just after flashing TWRP, what they mean is to press the "REBOOT" button which then leads to a submenu with a "RECOVERY" button. I initially thought the "REBOOT" button meant restarting the system so I didn't push it. Instead I tried pressing the Home + Vol. UP + Power button combination. But all that did was restart the SM-P900 into the stock v5.0.2. Which according the LineageOS instructions destroys the TWRP custom recovery. After repeating this step several times while trying variations of button pressing I finally hit the "Reboot" button and found the submenu of additional options: "System", "Recovery", "Download", etc...
Good Luck

Bearacuda said:
I reached out to the LineageOS community on Reddit. AndyCGYan replied and told me he had compiled 1.4.2 windows versions of heimdall.exe and heimdall-frontend.exe. I asked him to share them with me. He did. In a command prompt I typed: "heimdall142 print-pit --verbose". The command prompt scrolled with a flurry of text and my SM-P900 rebooted from 'Download Mode'. It worked!
I'd feel better if the Glassechidna guy would compile his own software into a 1.4.2 windows product, but I'm grateful this guy responded.
Thanks AndyCGYan
Click to expand...
Click to collapse
please can you share the 1.42 version with me? i am having the same problems

never mind in ended up using odin in the end with twrp. all good now

I'm not sure if there is a specific reason you proceeded using this method rather than using Odin as it was pretty painless to do it with Odin 3.10.6. This is what I did :
(I was already on Lollipop so I did not need to install a Lollipop bootloader.)
- Uploaded TWRP through Odin with auto-reboot and Reset Time unselected.
- I manually turned off the tablet after it was done flashing.
- I turned the tablet back on by pressing Vol.Up + Home + Power
- In TWRP : I swiped to allow modifications
- I made a backup
- I wiped everything except external storage
- I flashed Lineage OS and Magisk in one go.

I installed it without problems but this time it doesn't see my sd card I wonder why

[Root] H901 - For Newbies!

None of the methods in this thread are my own work. I struggled with getting my phone rooted for a long time and spend 10s of hours on the process. I had never rooted before and was therefore unfamiliar with all the terms, unfamiliar with how to complete all the recommended checks to ensure one had the right model, etc. There were several helpful threads but most approach the subject with the assumption that one knows something about the process. In this post I lay out what worked for me in a step-by-step way and what you have to do to achieve my results.
#1 Ensure you have a H-901 motherboard and not the Korean F600 motherboard by checking the sticker, and checking “About Phone” -> “Hardware Info” -> “Model number” in settings. These must both be LG-H901…from what I can tell the community has only developed technique for the H-901 variant.
#2 Get a micro SD card and load it with Magisk https://forum.xda-developers.com/apps/magisk/official-magisk-v7-universal-systemless-t3473445 , and if you have Marshmallow or Lollipop and want Nougat (much better experience IMHO), load the files in this thread: https://forum.xda-developers.com/tmobile-lg-v10/development/h901-t-mobile-nougat-v30b-twrp-t3639203 And maybe this thread as well (read both and then decide): https://forum.xda-developers.com/tm.../h901-t-mobile-nougat-v30c-flashable-t3744648
#3 Ensure you have unlocked your bootloader. (apparently only for T-mobile LG v10s since other carriers lock the bootloader) The FWUL virtual machine root method will not work if you have not done so. This is an entire process in itself. The following 2 videos which show how to root android 6.0 or earlier (process will not work with Nougat, 7.0, since some fastboot commands are missing). https://youtu.be/OtXlokk6JkQ , https://youtu.be/PPLwFGxLQA4
Also, this thread may be helpful. https://forum.xda-developers.com/tm...t-mobile-bootloader-factory-unlocked-t3236224 , download the nexus root toolkit here for easy ADB command entry http://www.wugfresh.com/nrt/ —we will only use the “Advanced Utilities” -> ”Manual Input” -> ”Launch CMD Prompt”. When it prompts you to select a phone, select the first option and then for android version select Android *** Any. Don’t use any of the other commands because they are not configured for your device.
If you get a “waiting for device” error while attempting the fastboot oem unlock command in the above thread, see: https://forum.xda-developers.com/tmobile-g4/help/fastboot-waiting-device-t3489789 Great video which shows how to change drivers. You will need to do this, I found a number of drivers that were already on my PC from google and Samsung worked although I didn’t have the specific one mentioned in the above thread. Don’t be afraid to experiment… you can always try another driver. And don’t require it to be hardware compatible. Ignore the warning message: https://youtu.be/nQjg6ePnGAc
---------------------------------------------
NOW that you have your bootloader unlocked you can proceed to actually flash the TWRP image as per this thread: https://forum.xda-developers.com/tmobile-lg-v10/general/root-h901-nougat-t3773942
Notes before beginning:
-To enter download mode to begin: Plug a USB cable into your phone with your phone powered off, hold down on the Vol Up button and plug the USB cord into your computer. It should immediately boot into download mode. Exiting Download mode after flash: pull battery…no damage will be done.
-To enter recovery after flashing TWRP: power off the phone then hold both the down volume and power at the same time. When you see the black LG screen briefly release the power button and then press it again while not letting the volume down up. You will see a screen asking if you want to delete all user settings. Say YES (via the volume and power keys—no touch input). You will see a screen asking if you want to delete all user data. Say YES (the data is only deleted if TWRP loads successfully) You will briefly see the black LG bootup screen. TWRP or factory recovery will load. Or if you did not unlock your bootloader, it will say recovery is corrupted and cannot be trusted, and then boot normally without changing your settings or deleting files.
-Additional note: as of 7-23-18 some commands had changed:
From V20 forum, Brian (runningnak3d) has moved to gitlab.com. So instead of github.com, we have to use a new git repository that Brian created in gitlab.com.
cd
mv lglaf lglaf_BAK
git clone https://gitlab.com/runningnak3d/lglaf
cd lglaf
git pull
git checkout v10-miscwrte
There are additional comments in the thread. Some timeout errors may be solved by: 1 - Download the VirtualBox extension pack: https://download.virtualbox.org/vir..._VirtualBox_Extension_Pack-5.2.8.vbox-extpack
2 - Go to File / Preferences / Extensions / click the + and browse to where you downloaded it.
3 - Once installed, with the VM off, right click on the VM, and go to settings. Click on USB, and pick USB 3.0. If your machine doesn't have a USB 3 port, pick 2.0.
But frankly, simply up arrow after a timeout error to load the last command on the command line and hit enter again. Simply keep doing this until it works. You know it works because no dialog appears for several minutes before informing one of success.
**Upgrade to Nougat after Flashing TWRP and booting to Recovery steps: (I did a full wipe as suggested by this thread: https://forum.xda-developers.com/v20/development/h918-recowvery-unlock-v20-root-shell-t3490594 before flashing the v30b upgrade then full Nougat zip, and then flashing Magisk. I flashed the 3 zips sequentially. I was afraid Nougat would not boot successfully because the zip files are less than 2 gb combined but success! You may want to also flash the 30c upgrade before flashing Magisk for a total of 4 zip flashes. I did not try this. However doing all this means no backups are done so if there is a problem you may have to flash a KDZ with the LG UP tool (don’t ask me how).
As a final note, I cannot answer specific questions about the various processes provided or errors you may encounter that I have not listed in this write up since I have not experienced them. A bit of research on your part may be required, but this post should provide you with a huge head start compared to where I started. Good luck!

Methods to get unlimited mobile hotspot, very useful if you're on the $50 MetroPCs (owned by T-mobile) unlimited plan. All you $70 T-mobile plan suckazzz! https://forum.xda-developers.com/tm...ited-tetherting-hotspot-t3825144#post77249285
I would actually recommend using a USB tether client and forgoing root access if tethering is your only objective and you are trying to be efficient with your time. However, with root you can install all these cool apps!: https://www.digitaltrends.com/mobile/best-android-root-apps/
The following caught my eye:
-Rec: screen record
-liveboot: boot animation (does not work with Magisk)
-Servicely: checks to see which apps are using a lot of battery and lets you suppress them
-Adblock Plus
-Titanium backup: very powerful phone backup application & bloatware remover look into for quickly switching over to a different lg v10
-Greenify: put apps into hibernation
-System tuner: get lots of info about you phone but be careful making changes
-ES file explorer: dig into the android system
-Disk digger: recovers deleted files (photos only?)

Fire HD 8 (2018 ONLY) unbrick, downgrade, unlock & root

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

[FIRMWARE][GUIDE] Topelotek Meteor (T07D) Stock Firmware/Installation Guide

TOPELOTEK METEOR T07D
7" ANDROID TABLET
Product: astar_733Q1
Board Platform: Allwinner-A33
CPU: Quad-Core Cortex-A7 (ARMv7l)
CPU Clock: 200 MHz - 1.2 GHz
[Overclock Up To 1.51 GHz]
GPU: Mali-400MP2
RAM: 1 GB
Bluetooth: 4.0
Internal Storage: 8 GB (eMMC)
External Storage: microSD Slot (Up to 128GB)
USB OTG Support
OEM Unlocked
Display: 7" IPS
Screen Resolution: 800 x 1280
Screen Density: 190 DPI (mdpi)
Battery: 2850 mAh Li-Ion
Cameras: 2.0 MP Main; 0.3 MP Front
OVERVIEW:
The Topelotek Meteor (T07D) is a very affordable, very basic, low-spec 7" Android tablet. As reflected by the above hardware specs, this tablet is by no means spectacular with regard to performance potential. Nonetheless, for the pricetag (typically about $25 or less), the Meteor T07D is not a bad deal. Like many Chinese tablets of its kind, stock firmware can be very difficult -- if not impossible -- to locate. However, this device does ship with a couple of extraordinary features: an unlocked bootloader and insecure boot image support (ro.secure=0) out of the box. As such, rooting and customizing this tablet are fairly simple tasks, as is pulling firmware images from the device's partitions. This firmware package is constructed from unmodified stock partition images (/system, /boot, /bootloader, /recovery), which can be installed using a few rudimentary fastboot commands, and can be beneficial in restoring a device that is soft bricked, stuck in a bootloop, etc. Installing this firmware package per the instructions below will restore your Topelotek Meteor to a stock factory state.
FIRMWARE BUILD INFO:
Android Version: 6.0.1 Marshmallow
Build ID: MOB30R
Firmware Version: v6.0rc3
Build No.: A33-1+8-0312+2145-1280x800-6.0-733Q1-8703-180601
Kernel Version: 3.4.39
Build Date: May 30, 2018
Security Patch Level: April 1, 2018
Insecure Boot Image (ro.secure=0)
DISCLAIMER: By proceeding further, your warranty can be rendered null & void. (However, because the device ships OEM unlocked, out of the box, your warranty may or may not be affected. You will need to make this determination on your own.) As with any other system-level procedure, installing this firmware invokes the possibility that your device could be damaged or rendered completely inoperable. While I have thoroughly tested this firmware on my own device, I will not be held liable for anything that goes wrong during your installation of this firmware. By proceeding, you are taking sole responsibility for the integrity and operability of your device.
PREREQUISITES:
For this installation, you will need a PC or Mac with the latest Android platform tools or the latest Minimal ADB & Fastboot utilities installed. Visit this thread for download links and instructions: https://forum.xda-developers.com/showthread.php?t=2317790 Please give @shimp208 a tap on the THANKS button if you use his work. This is a link to the July, 2019 Minimal ADB & Fastboot thread by @K3V1991. https://forum.xda-developers.com/an...g/tool-mini-adb-fastboot-2019-06-30-t3944288. Again, please give thanks if you use the developer's work.
Also, you will need to install the correct ADB and USB device drivers for this tablet.. A simple Google search for "Allwinner-A33 ADB & USB drivers" will provide links to these files, as well as guidance for proper installation of the drivers. As mentioned supra, this tablet ships with an unlocked bootloader. Nevertheless, you will need to go to SETTINGS>ABOUT TABLET and tap Build Number 7 or 8 times until Developer Options are enabled. Then, you will need to check the box called OEM Unlocking. Once this is done, your device bootloader is unlocked for all intents and purposes.
INSTRUCTIONS:
1. Download the firmware package from the below link and extract the contents of the archive to your ADB & Fastboot directory on your PC;
2. Boot your device into fastboot mode. One way to do this is by connecting your device to your PC with a quality micro USB to USB syncing/charging cable. Boot your device up, ensure USB Debugging is enabled, and open a command prompt on your PC in the path of your ADB/Fastboot directory. Execute this command:
adb devices
If properly connected, the command window will return with an alphanumeric string that represents your device serial number. If you do not see confirmation of a proper connection, check your driver installations, your sync cable, and/or try another USB port.
(In the event your device will not boot into the Android OS (soft brick, boot loop, etc.), you can boot directly into recovery mode/fastboot mode by using hardware key combinations. However, I am not familiar with the hardware key method, so you will need to research the proper procedure.);
3. Once properly connected, execute the following command:
adb reboot bootloader
Your tablet will now boot into fastboot mode. Your device screen will simply display the white Topelotek logo lettering amidst a pale blue screen. Open a command window once again in your ADB/Fastboot directory;
4. Execute this command:
fastboot devices
Once again, if properly connected, the word "fastboot," or your device serial number will be displayed in the command window;
5. Once fastboot communication has been established, execute the following command set:
fastboot flash bootloader bootloader.img
fastboot flash boot boot.img
fastboot flash recovery recovery.img
fastboot flash system system.img
fastboot erase userdata
fastboot erase cache
fastboot reboot
(Please note that system.img is a large file. Fastboot will automatically parse this image into a series of sparsechunks and systematically flash them to your device. This process can take up to 5 or more minutes, so just be patient. To avoid any possible issues, it is imperative to be using a current version of either the Android platform tools or the Minimal ADB and Fastboot utilities.)
Upon reboot, your device should be restored to a factory stock state and be running on the latest available firmware version.
DOWNLOAD LINK:
Firmware v6.0rc3: https://drive.google.com/file/d/1-0UciSFgTwqN-n_TyL255oZcOVZMqjso/view?usp=drivesdk