Hello! I’ve come, because in my quest to root my recent Galaxy S Devices, I’ve hit a big fork in the road and I don’t have the knowledge base to answer the last few questions I have. I feel like I should know the answers here, but for some reason I am lost to what to do next. I don’t quite understand how the newer root methods work these days, since working with the system & recovery images isn’t as easy with the newer Samsungs.
I got together with a developer, @droidvoider, where together we came up with this idea to get a root shell capable of at least remounting the filesystem R/W before reboot. He coded it on 6.0.1, and I talked a whole lot while I tested it on 5.1.1.
The Greyhat Root Console post#63
droidvoider said:
Major update!
1. I have debugged the tool heavily and it appears to me that I can replace any file on the system. Testing files you can't normally read is done via code so it's slow going, let me know if you find any blocks now.
2. If you have any file that gives an error but then replaces, that's because it tried other contexts.. PUT THIS ACTION AS THE LAST ENTRY, it might not be changing back to install_recovery from some contexts
3) the su install thing is designed to give an error I didn't even try to get root with this, literally focused on getting the tool done only.
4) next is a console of sorts, with exec dcow patching.. muahahaha
https://github.com/droidvoider/CVE-2016-5195_GreyhatRootProject_Root_Console
Click to expand...
Click to collapse
droidvoider said:
post#41you start an apk with am or monkey ... Let me know if I missed any other questions I'm excited about my find
I have awesome news.. As soon as I started playing with ls -la / using both contexts with root I seen that inside /cache/recovery/ is some log files. I am pressed for time hard, however
Code:
ls -la /cache/recovery/
Attached you can see the full output acquired from ls under both contexts
Click to expand...
Click to collapse
I'll start with the fact that I do not have Cellular Service. I no longer own a Note 5 N920A. But I do still own an S5 G900V, S6 Edge G925V, and a S7 Edge G935V. They serve as Wi-Fi Only Devices, and they are owned by myself. So slightly selfishly, I concern myself only with modifications that allow the device to boot, working network services are not a primary concern of mine. As they can more than likely be configured after boot by someone smarter than me.
I know that normally DM-Verity, KNOX, Encryption, U/G IDs, and SELinux, play a big role in allowing a user to execute processes as the root user. I am running 5.1.1 Android on my S6e & 7.0 on my S7e. I have an Engineering Kernel and boots normally with ADB Root Shell access. I have an Engineering Sboot, and allows me a non Root ADB Shell while booted normally in Stock Recovery. Right now the Eng Kernel I have, sets SELinux to Enforcing Mode. If I use the stock factory binary kernel, I lose root adb shell access but gain Permissive SELinux Mode. How do I inject root from here in a stable fashion?
akiraO1 said:
post#112
But I did want to post my findings so far on my selinux adventures thus far with my note 7....
So I was able to change the root context permanently from ubject_r:rootfs:s0 to u:r:shell:s0.
This by itself isn't all that helpful except that I actually changed it, and it stuck when I rebooted the device.
I achieved this through dirtycow-ing the file_contexts file with my customs file_contexts file and the commmands restorecon -RFv / and chcon -Rhv u:r:shell:s0 / restorecon makes selinux reload the file_contexts file immediately, so it loads all or most of my custom contexts. then I do a chcon command to make sure it writes?
well thats all I have for now but im working vigorously and will keep posting my findings as I find them =)
Click to expand...
Click to collapse
Using "DD" on Android 6.0.1 post#18
droidvoider said:
Tool is working!!!
Android 64 bit universal dirtycow dd image write works for both push/pull.. I am tired so please see github readme, the Makefile and push_files.txt, pull_files.txt examples. I am going to get root, this is the first step.
https://github.com/droidvoider/Android_6.01__DD_Dcow
Click to expand...
Click to collapse
Page 4 for File and GHR Console
Page 5 further discussion of Console
Page 6 GHR Console
I'm going to go into some detail here about the Firmware I've been flashing just so everyone knows without having to ask. I'm almost really hoping maybe we could all muster one more attempt at rooting this Note 5 variant.
I really feel like I really might have something here, especially with the updated binaries of "Farm Root", "CVE 2016-5195 (dirtycow)", and bootimgtools (mkbootimg & unpackbootimg). All compiled for arm64-v8a. Thanks to @droidvoider for helping to compile those. I'm not a linux Expert by any means, but I'm on a mission, and I do know a few things. With all of the Security Bulletins that have come out since November, there should be plenty of Attack Vectors for using the LL Eng Kernel or DirtyCow to gain enough Kernel Privileges to maybe even unlock the dang bootloader. Or maybe bypass the signature check for one boot. LL-based UCU1AOGG Recovery Mode does not use DM-Verity when exiting, and the Combination Firmware doesn't seem to use it at all So....
Q1.) Can someone please help me get at least a systemless root installed? WITHOUT using a custom recovery? It might need to actually be a system root though looking at the Galaxy S8.
This should be possible using the LL Engineering Kernel & Engineering Sboot for the Factory Binary. Especially since the August builds are fully exploitable by DirtyCow, and with an eng Kernel that is half the battle we were using dirtycow for in the first place. Now we should be able to use DirtyCow to finish the root injection. Because the Factory Binary does not utilize DM-Verity that is obvious. So using the Factory Combination Firmware, there may actually be a way to legit boot a custom recovery I feel, even if only for one boot, that is plenty enough if prepared when that oneshot boot happens. Once installed with the full Combination Bootloader (ODIN BL file) I can then flash any N920A LL ODIN AP File. All the way back to N920AUCU1AOGG. Warranty Bit Intact, Official Status, Normal Rebooting. In fact, after everything I've done thus far, I have still yet to trip my KNOX Warranty (Still 0x00).
**************
** MM 6.0.1 **
**************
Here are the contents of the tar.md5's:
Code:
tar -tvf AP_N920AUCS3BPH4_CL7563702_QB10603229_REV00_user_low_ship.tar.md5
-rw-rw-r-- dpi/dpi 28746016 2016-08-10 00:31 boot.img
-rw-rw-r-- dpi/dpi 29413664 2016-08-10 00:32 recovery.img
-rw-rw-r-- dpi/dpi 4125403456 2016-08-10 00:33 system.img
-rw-r--r-- dpi/dpi 549536816 2016-08-10 00:33 userdata.img
tar -tvf BL_N920AUCS3BPH4_CL7563702_QB10603229_REV00_user_low_ship.tar.md5
-rw-rw-r-- dpi/dpi 1634576 2016-08-10 00:31 sboot.bin
-rw-rw-r-- dpi/dpi 1095680 2016-08-10 00:28 param.bin
-rw-rw-r-- dpi/dpi 2113808 2016-08-10 00:28 cm.bin
tar -tvf CP_N920AUCS3BPH4_CL7563702_QB10603229_REV00_user_low_ship.tar.md5
-rw-rw-r-- dpi/dpi 37269840 2016-08-10 00:28 modem.bin
tar -tvf CSC_ATT_N920AATT3BPH4_CL7563702_QB10603229_REV00_user_low_ship.tar.md5
-rw-rw-r-- dpi/dpi 3072 2016-08-10 00:32 NOBLELTE_USA_ATT.pit
-rw-r--r-- dpi/dpi 89608656 2016-08-10 00:34 cache.img
For this MM Stock Firmware, I've also come across this Modem for a Z3X Flash Box, that is used when direct unlocking this device. I do know, that when I have this CP installed, I do have access to the APN Editor, to Add/Modify/Delete APN's:
Code:
tar -tvf N920A_UCS3BPH4_CP_FOR_UNLOCK.tar
-rw-r--r-- 0/0 37269840 2016-08-10 00:28 modem.bin
******
**************
** LL 5.1.1 **
**************
I’ve happened upon the full ODIN flash-able SW Rev 3 Factory Binary for the AT&T Galaxy Note 5. It allowed me to do a full firmware downgrade from MM 6.0.1 to LL 5.1.1 without worrying about trying to downgrade my binary counter in download mode. It’s the only 5.1.1 build I’ve seen that isn’t a binary 2-(SW REV 2) & It contains these files:
Filename: COMBINATION_FA51_N920AUCU3APH1_CL6053901_QB10608083_REV00_user_mid_noship.tar.md5
Code:
tar -tvf COMBINATION_FA51_N920AUCU3APH1_CL6053901_QB10608083_REV00_user_mid_noship.tar.md5
-rw-rw-r-- dpi/dpi 1634576 2016-08-10 06:44 sboot.bin
-rw-rw-r-- dpi/dpi 1095680 2016-08-10 06:43 param.bin
-rw-rw-r-- dpi/dpi 2113808 2016-08-10 06:43 cm.bin
-rw-rw-r-- dpi/dpi 24660256 2016-08-10 06:44 boot.img
-rw-rw-r-- dpi/dpi 24754464 2016-08-10 06:44 recovery.img
-rw-r--r-- dpi/dpi 1537858544 2016-08-10 06:44 system.img
-rw-r--r-- dpi/dpi 4292768 2016-08-10 06:44 persdata.img
-rw-rw-r-- dpi/dpi 36163408 2016-08-10 06:43 modem.bin
-rw-rw-r-- dpi/dpi 3072 2016-08-10 06:44 NOBLELTE_USA_ATT.pit
Using ODIN v3.12.5, I flashed this firmware using the AP slot overtop of the Full 3BPH4, and after flashing the Factory Binary these are the build details that boot up with zero errors. Mind you, I have tried this with, and without, a sim card inserted. It is not lost on me either, that UCS3BPH4 (Stock) and UCU3APH1 (Factory) have the same build dates listed on them.
***
* Device := SM-N920A
* Android Version := 5.1.1
* Baseband Version := N920AUCU3APH1
* Kernel Version := 3.10.61 August 10th 2016
* Build Number := LMY47X.FA51_N920AUCU3APH1
* SELinux Status := Permissive
***
From @TechNyne66 I got the LL Eng Kernel from the 2APB2 build. I have yet to see any other UCE branded files.
Code:
tar -tvf N920AUCE2APB2.tar
-rwxr-xr-x 0/0 27326752 2016-02-11 01:42 boot.img
But flashing this kernel into the Factory Binary sets SELinux to Enforcing, which makes things a bit more difficult. And I don't know how to edit the Kernel in a way I can repack it for flashing. My attempts thus far have failed when trying to flash a repacked boot.img. Probably because I did not make the necessary build.prop tweaks, and because I didn't use the correct compression levels to repack. What I mentioned earlier about not understanding the filesystem all that well anymore, stems from not having a broad understanding of build/default.prop & the various .rc/init files.
This is also possibly due to Samsung using a customized header for the Kernel's Binary.
Q2.) Is there a way to update the UID/GID from 'dpi/dpi' to '0/0' without modifying the signature embedded into the tar.md5?
Q3.) Is there a way to extract the extra data from the end of the file?
Q4.) Can I examine the persdata.img directly, to see it's contents before flashing? I don't know how to view the img format and how to extract it.
My post is too long, so I'm moving to post #2
Since these are too long to fit in post 1, I was forced to double post. Here is the last bit about partition tables. The reports are long. Please, any solid advice would be helpful.
***************************
** PIT File Examinations **
***************************
Moving on, I have used "PIT Magic 1.3 Release", found here on XDA, to look at the partition tables of the .pit files included with the N920AUCS3BPH4 & N920AUCU3APH1 ODIN firmware packages. I have also included the PIT File examination from the unlocked European Firmware. Given that PIT Magic 1.3 is a few years old, the latest version I have is labeled 2012. I read about how difficult it was to get the format correctly back then, and I have no way of knowing if the PIT File format has changed since then. But it does still seem to give usable output. I just don't know how to use this output meaningfully yet.
If you could hack one of the apps that are included in the sepolicy and set the Androidmanifest.xml to include android:dubuggable="true" we can make a two stage app. read and replace as root with the cow and then reload your inits.
toolbox.c root trick:
I am working on a very very powerful tool now. I am taking farm-root toolbox.c and changing it to grab root + context but then fork a process into a loop and just keep those privs. Hopefully I can even control that loop from the command line still! Currently I can get root and system_server, install_recovery.. But today after work we find out if I can hold on to it in a loop.
recovery-from-boot.p
I researched this today because we can read/patch this file with dirtycow. This file replaces the stock recovery every time you boot if they are different. I don't know if it also uses the hardware signature verification process, if so that's a key that's hidden in the partition image (hopeless for us i bet)
So if we replace recovery we have to crush this file with dirtycow.c
This sounds very interesting, i have a damaged g935f with dm-verty faied and frp lock so there is no way to use this device unless i flash with no-verity firmware but cant as frp stops me flashing root, hopefully you can use this exploit with the factory combination firmware to replace the boot loader with twrp or other custom bootloader to fix this issue, there is lots of people with same the problem im sure
verg0 said:
This sounds very interesting, i have a damaged g935f with dm-verty faied and frp lock so there is no way to use this device unless i flash with no-verity firmware but cant as frp stops me flashing root, hopefully you can use this exploit with the factory combination firmware to replace the boot loader with twrp or other custom bootloader to fix this issue, there is lots of people with same the problem im sure
Click to expand...
Click to collapse
Can you get booted at all? If you can' t get booted I won't be gaining access to that phone until someone smart works out the encryption, no one has on the note 3 yet not even hashcode (that he ever released). While the bootloader is locked.... The sboot.bin = signed by hardware key. If that key is not present there is an undisclosed backup key embedded in the partition, one must be present and neither are known. Minus the presence of those keys, chain of trust fails.
S7 is worth saving if it can be saved tho
droidvoider said:
Can you get booted at all? If you can' t get booted I won't be gaining access to that phone until someone smart works out the encryption, no one has on the note 3 yet not even hashcode (that he ever released). While the bootloader is locked.... The sboot.bin = signed by hardware key. If that key is not present there is an undisclosed backup key embedded in the partition, one must be present and neither are known. Minus the presence of those keys, chain of trust fails.
S7 is worth saving if it can be saved tho
Click to expand...
Click to collapse
No bud, the phone wont boot a normal firmware as the certificate is screwed and imei 0000000000, but it will boot with combination firmware, all i need to do is gain root and disable 'frp lock' via z3x box or another method and car repair the phone... Im not fussed about the warranty being void to be honest... I have ADB but not root fix phone
My tool will likely be helpful to you because that sounds good enough as long as you can get to a prompt that is CVE-2016-5195 / SVE-2016-7504 vulnerable. Anyone who isn't patched beyond Sept 2016 on any Android in the last 10 years will be able to use the tool I'm building to do amazing things. I am designing it precisely for people like you and Delgoth who have large investments in phones that could simply be repaired with enough access.
I am thinking now to fork off a child process anytime I can capture root + "any_new_context"... This will be forked into a child process then kept in a loop. If there is a new root + context that happens along through toolbox, we will grab that also.. (but I won't grab two of the same for example root + system_server I just need once)
I am hoping I can control this loop from the command line but since I am not the caller of the process for which I am capturing I am not sure that would work. This is new code to me, not sure of any examples of something like this. If I have to control it through values I set in files it adds a little more time. The great news is I am not having binary size problems so I can add quite a bit of code while still keeping toolbox much less than the currently installed version on my Note 5. File size must match exactly otherwise patching causes seg fault and seg fault ruins the fun (reboot to cure but irritating)
anyway just needed to come up for air I have a ton done, need to get toolbox fired up to test angle.. any c programmers that want to help or anyone with awesome ideas please feel welcome I could use help
Ah cool the combination firmware i have is:
COMBINATION_FA60_G935FXXU1APB5_STEP1_OLDFW\COMBINATION_FA60_G935FXXU1APB5_CL7345605_QB8752841_REV00_user_mid_noship.tar
The kernel is 3.18.14-7345605 Thu 25th Feb 2016 so it should be exploitable I'd love to get my S7 Edge working again
droidvoider said:
My tool will likely be helpful to you because that sounds good enough as long as you can get to a prompt that is CVE-2016-5195 / SVE-2016-7504 vulnerable. Anyone who isn't patched beyond Sept 2016 on any Android in the last 10 years will be able to use the tool I'm building to do amazing things. I am designing it precisely for people like you and Delgoth who have large investments in phones that could simply be repaired with enough access.
I am thinking now to fork off a child process anytime I can capture root + "any_new_context"... This will be forked into a child process then kept in a loop. If there is a new root + context that happens along through toolbox, we will grab that also.. (but I won't grab two of the same for example root + system_server I just need once)
I am hoping I can control this loop from the command line but since I am not the caller of the process for which I am capturing I am not sure that would work. This is new code to me, not sure of any examples of something like this. If I have to control it through values I set in files it adds a little more time. The great news is I am not having binary size problems so I can add quite a bit of code while still keeping toolbox much less than the currently installed version on my Note 5. File size must match exactly otherwise patching causes seg fault and seg fault ruins the fun (reboot to cure but irritating)
anyway just needed to come up for air I have a ton done, need to get toolbox fired up to test angle.. any c programmers that want to help or anyone with awesome ideas please feel welcome I could use help
Click to expand...
Click to collapse
Do you have your toolbox on github? And is it commented decently? If so, I can look into helping with your code. I ask about comments because Ive not really looked into the whole. But if we figure out what parts samsung and at&t stripped down the AOSP toolbox, there could be a vector for completely patching the toolbox binary installed on our device.
Most root methods I see around, use busybox and su.
But our note 5 actually uses toolbox instead. Meaning, adapting a root method to use toolbox instead of busybox, eliminates that extra disk space taken up by the busybox binary, that needs to be patched in memory.
I needed to finish another piece of code before I started on toolbox, and that code is finished and on github. I need to be able to replace a list of files and know they are exact byte for byte, that's the code that I made available, which is in itself cool. Now I'm testing how to control the toolbox loop but so far if I get input from the command line the child executes one task then dies. I don't really want to fork fork fork fork things.. I need better control logic. soon i will solve it then upload a great starting point
edit: I realized there is places I can post snippets of code.. Here's the code I'm playing with but please realize some things may not work, not belong or I may have started making variables I never used.. (this is the pile of code I am using for testing).
I test code in Ubuntu first otherwise there wouldn't be enough time in a day:
gcc -o fork_u fork_u.c
./fork_u
http://pastebin.com/7nFxGcnY
Update: It's not exiting after executing a command at all. I messed up that if statement that checks for x. I am not a C programmer by trade I took it in college 20 years ago. Now I'm relearning it, so be warned on that
====>] We have changed directions back to replacing the bootloader see the next post [<====
I am exuberantly confident we can take the bootloader after the testing I've done today. This is the basics of the bootloader
https://www.xda-developers.com/galaxy-s7-bootloader-lock-explained-you-might-not-get-aosp-after-all/
===>] I need someone to copy their bootloader in both locked/unlocked status so I can find what to change. [<===
I am starting to suspect I can't simply copy an unlocked bootloader from another device. I am fairly certain that I need to pull the sboot from the device, patch it and then push it back. I need to actually look at the source code and perform any steps it does as well, such as deleting stuff.
I need someone who is vulnerable to dirtycow with an unlocked version of the Note 5 to pull their sboot in locked/unlocked status. This means they would run the hack I'm using on their device, overwrite toolbox, dumpstate and app_process temporarily to pull the partition.
====>] Plan B is downgrading then attacking an earlier version of the phone [<====
I believe I can write the original sboot.bin and system.img to the Note 5 now to do a forced downgrade. If that is true we could be dealing with trying to root an Android 5.0 device instead of Android 6.0 .. This opens the door on a million exploits!!
Plan B is all I have for now let me know if anyone can help with Plan A
**** Warning **** This is the most dangerous developer tool I've seen in a very long time. You can easily smoke your device with this without even trying.
====>] farm-root updated for Note 5 [<====
Ok guys it works for recovery or boot. It will pull an image or push an image.
https://github.com/droidvoider/Note5-Root-Farmer
toolbox directory compressed for recovery and boot, matches above code
boot push / pull --- aosp toolbox directory
recovery push / pull --- aosp toolbox directory
-DFARM_BOOT changes from recovery to boot in the shared.c
-DFARM_PULL is for pulling in toolbox,c / bridge.c, no define means compile to push.
-DDEBUG is for logcat messages, recompile minus this option to reduce binary size a lot
===>] What was wrong? [<===
When I got this working at first a couple weeks ago I thought I checked the path but I didn't. That and the updates to dirtycow are the only differences between mine and freddies version. (except that I also added push boot.img)
partitions:
/dev/block/platform/15570000.ufs/by-name/RECOVERY
/dev/block/platform/15570000.ufs/by-name/BOOT
directory containing sym links: (shell is allowed to ls -la inside this directory and view partition links!)
/dev/block/platform/15570000.ufs/by-name/
===>] So why can't we do this to the bootloader? [<===
I am now focusing just on this idea!!
Notes: I have a suspicion that if we used the bootloader from another device the numbers won't match, such as mac, and that will be permanent hard brick. I need someone to copy their bootloader partition both locked and unlocked using a tool I create for that purpose. (anyone got a friend who will help out?) Obviously this will not be an AT&T version.
===>] Basic instructions [<===
Download and unzip to a Ubuntu directory (android sdk + ndk needed)
Plug in your device and make sure you can adb shell
Add a screen lock pin to your device first
In terminal change to the directory first then make log
Open another terminal then you compile the sources for pushing or pulling as follows
make pull_boot, make pull_recovery, make_push_boot, make_push_recovery
You will be hung on "waiting for process to complete"
On your phone enter your pin, then go to settings, remove the screen lock pin..
close settings
On your phone again now go add back a lock screen pin.. close settings.
repeat the lockscreen thing it will go...
===<> Breaking my rule and playing with it now <>===
I tried boot.img altered with Assayed kitchen modified heavily but no changes, I think it was written back on reboot I bet recovery-from-boot.p really replaces this.
So I tried with recovery.img from Assayed kitchen modified heavily, I got a big blue error telling me to take my phone to AT&T
(if you get an error use heimdall to flash the specific file(s) or use odin to flash your AP file from the firmware.)
Continue Notes: I have confirmed I am replacing the boot.img and recovery.img completely freddie knocked it out of the park fellas. I have only tried heavily modified versions, I have not tried modifying the pulled version yet. If I flash anything not factory the phone has an error screen telling me to take it to at&t. pwr+vol. down I have to release and retry but eventually I get it to reboot, then download mode. Then simply flashing back what I replaced with farm-root gets me back up again.
If I flash recovery.img from t-mobile note 5 twrp it won't give me the error message until I attempt to enter recovery! After that it will always give the error. I tried putting twrp as the boot.img but that fails too, it does look like it almost loads something then I get the chain of trust error.
continuation of notes: I've still only tried heavily modified versions but I have unpacked the boot.img and recovery.img I've pulled, they are complete. If I flash recovery.img first then reboot without entering recovery it doesn't error. (until you enter recovery then it won't allow boot)... So instead I flashed boot.img also. Now boot.img isn't replaced on startup, I get the blue error message and this time I have to flash both recovery.img and boot.img to get the phone working again. (what does that mean?, mostly it confirms we wrote to both partitions which I have also confirmed through pulling / testing after writes) one thing is for sure this is a lot more fun then having nothing.
edit: nevermind on this idea I want to stay focused on unlocking the bootloader or downgrading it to Android 5.01
Update on status:
I can hard code toolbox to replace a list of files that you create right now, I am confident this includes bootloader, system, and a ton more.. So if anyone wants to do the leg work and find out which partitions are which, gather up a file list to replace and deliver that to me (the text version not the real files) .. I will hard code that out for you.. (i think that's freedom for you, see later bye)... Everyone else please realize I am having fun.. I tried to write toolbox to read what to change from /data/local/tmp/ but as suspected it can't read from there.. Today I will try to use dumpstate to copy a file list to /data/cache so that I can read it as install_recovery.
--- When I read what to change from a file we just need one toolbox for everything.. (no more separate toolboxes)
--- When I can communicate with toolbox in this manner I can move on to the next tool which is controlling the loop
Update:
toolbox is very limited on what it can open for reading if anyone is working on another project following along here for ideas you need to use the farm-root bridge idea. and by that I do mean even patching arbitrary file tests have failed now also, so there will be no eliminating bridge/dumpstate process
Updated again: Haven't had a tremendous amount of time to play lately but I sat down and tested my way through my final idea for farm-root. Bridge reads what to pull/push from a text file and then also pushes a text file to cache/recovery for toolbox to read. The file will have the dd if/of statements. Instead of performing 1 operation bridge will loop it will either wait..pull...wait or push...wait..push.. toolbox dd pulls or dd writes, waits for bridge and they loop between one another doing the work.
(still uncertain about dealing with 4gb file size but I realized that I don't need a sig verification. So I can unpack system, make it quite small then repack. This should smash down the version problem then we will need to do a follow flash of OJ1 AP, CP, CSC files...)
....thanks for your help with things lately @Delgoth you've hurtled this project ahead and are likely the reason it's here at all. I'm not forgetting the other things you mentioned I'm just at a wait and see pattern on what we need to force this downgrade, then get root
droidvoider said:
Update on status:
I can hard code toolbox to replace a list of files that you create right now, I am confident this includes bootloader, system, and a ton more.. So if anyone wants to do the leg work and find out which partitions are which, gather up a file list to replace and deliver that to me (the text version not the real files) .. I will hard code that out for you.. (i think that's freedom for you, see later bye)... Everyone else please realize I am having fun.. I tried to write toolbox to read what to change from /data/local/tmp/ but as suspected it can't read from there.. Today I will try to use dumpstate to copy a file list to /data/cache so that I can read it as install_recovery.
--- When I read what to change from a file we just need one toolbox for everything.. (no more separate toolboxes)
--- When I can communicate with toolbox in this manner I can move on to the next tool which is controlling the loop
Update:
toolbox is very limited on what it can open for reading if anyone is working on another project following along here for ideas you need to use the farm-root bridge idea. and by that I do mean even patching arbitrary file tests have failed now also, so there will be no eliminating bridge/dumpstate process
Updated again: Haven't had a tremendous amount of time to play lately but I sat down and tested my way through my final idea for farm-root. Bridge reads what to pull/push from a text file and then also pushes a text file to cache/recovery for toolbox to read. The file will have the dd if/of statements. Instead of performing 1 operation bridge will loop it will either wait..pull...wait or push...wait..push.. toolbox dd pulls or dd writes, waits for bridge and they loop between one another doing the work.
(still uncertain about dealing with 4gb file size but I realized that I don't need a sig verification. So I can unpack system, make it quite small then repack. This should smash down the version problem then we will need to do a follow flash of OJ1 AP, CP, CSC files...)
....thanks for your help with things lately @Delgoth you've hurtled this project ahead and are likely the reason it's here at all. I'm not forgetting the other things you mentioned I'm just at a wait and see pattern on what we need to force this downgrade, then get root
Click to expand...
Click to collapse
If toolbox is becoming limited, Toybox is also a partner binary that is used on the system beside toolbox.
Also if you can shrink the system partition and keep it persistent. You can shrink it from 4gb to 3.5 safely and then possibly reclaim that 500mb for your own private partition. My installed stock system uses 3.4gb of 4. That hidden partition should then remain even after a factory reset. As long as the device was not repartioned by odin or otherwise. Or as long as a new PIT isn't flashed.
This is where you can store your hacks, and have access to on device when first booting to recovery from a fresh flash.
toybox, good idea
I forgot about toybox when I get this code working I will rerun some of the test code on it to see how powerful it is.
New logic for root-farmer
root-farm will now only have 1 bridge and maybe 2 toolboxes (depending on final binary size for toolbox)
Now the files to PUSH/PULL are in a text file. Bridge copies it to cache and then toolbox can read it also.
PULL example: <= everything before the '|' is one execv command used by toolbox. => | <=== following this character is bridge copy leftvalue => | right value
of=/cache/recovery/bota0_pull.img if=/dev/block/platform/15570000.ufs/by-name/BOTA0 bs=10m|cache/recovery/bota0_pull.img|/data/local/tmp/bota0_pull.img
So push will only push a files.txt, pull_files.txt/push_files.txt is copied to /data/local/tmp/ then bridge decides if this is a push or pull depending on the text file format. After that it's pretty much business as usually toolbox uses the dd command as root+install_recovery to over write or copy anything
This code snippets are not complete. They are meant to show you what I did to test my theories.
toolbox_working example
bridge will copy files.txt to /cache, toolbox will pick it up and then spit the contents out into logcat -- success
unfinished_test_code
that's the parsing, it echos the commands it doesn't actually dd anything.. but you can see it echo what it should be copying, or dd'ing.
updated (adding sources per a users request):
brdg.c.tar.gz == linux proof of concept for bridge, i make copies, test stuff from blocks of code like this then port to android
This morning something dawned on me. If I can write to the first partitions known to the computer worlds as MBR1 512kb limit MBR2 extended mbr.. Then I already own this device. Now I need twrp with the correct addresses for my device, I simple write twrp on the device and wipe the rest.
While I think that is true 100% I have different passions then simply winning. If anyone is willing to try it I will port farm-root over to point at those partitions instead, and also to replace them in one go.
Those waiting for the finished tool I get to play today a little since I had to work Sunday! we should have a template at minimum this evening. I'm adding to sources one is the partitial conversion it will be called Android_Dirtycow_root_farmer from now on.. (because it isn't specific to any device any more it will work with any 64bit dirtycow vulnerable device)
the test zip?, man I forgot what I tested with that just type make test and watch logcat.. tests are always safe, reboot afterwards though.
Tool is working!!!
Android 64 bit universal dirtycow dd image write works for both push/pull.. I am tired so please see github readme, the Makefile and push_files.txt, pull_files.txt examples. I am going to get root, this is the first step.
https://github.com/droidvoider/Android_6.01__DD_Dcow
More info on it
I updated this thread with some info first/last posts only
https://forum.xda-developers.com/no...g-dirtycow-t3559637/post71102343#post71102343
What about root right now?
If I can get system_server + root, then switch to install_recovery + root I can fork both these processes away and send commands to them through a text file just like I sent the options for push/pull. This code wasn't only to eliminate the need for multiple toolbox / bridge binaries.. It was to create a command shell that I can issue any command. Remember my examples above?
.....Work study: take the examples I created and create a loop that doesn't close but instead waits for changes to a text file. Then execv those changes returning to wait again for more changes.
I have to be away for 1 to 4 weeks I just found out.. I might be able to check messages, I dunno. not away but same as.. have fun
Im going to go over all this, this weekend. Hopefully I can work out what data to write.
If we can patch /sbin/sverifysignature then we maybe able to disable the sig check. Right now my device is without a DT_Hash, I have busybox installed and linked to /system/xbin
I also have the su binary in xbin but its not linked so apps dont know it's there. But they both persist through reboots no problem. I am currently half way rooted, with zero hiccups so far.
Im close but im running 5.1.1 with an eng kernel and eng sboot. I dont currently have a CSC installed.
The problems im running into are that most apps have always done root the same way, the way that doesnt work on this device. Root is possible, but the age old standard root injection doesnt fly here, we have to do it manually this time because the standard root install scripts expect privs we dont have in certain places. That doesnt mean we can't root, it just means we have to edit the scripts and run them from some place other than TWRP. Which is still possible.
So here is what I have:
Dm Verity verification failed... Message when entering recovery. No effect on operation.
ADB root on boot, and when charging offline.
Busybox 1.22 fully linked from /system/xbin
Chainfire supersu 2.76 su binary placed in /system/xbin unlinked, I dont know how to link it like I did with busy box.
Even though dm verity fails, I can mount the entire filesystem read/write, and all my changes are still in place after normal reboot. I can modify my system and dm verity does NOT undo my changes. I can even pull my boot img from /dev/block/sda5
What do I have in my hands right now?
Related
I live in Japan and after more than 6 months I have successfully and permanently rooted both my Sharp 003 SH Galapagos and the 005SH Galapagos (Softbank not Docomo). My next concern is how to SIM unlock. I have been reading the posts about hacking the nv_bin file. I have searched through all of the the files (Root FTP thank you!) but there was no such file. I am happy to send along any screenshots or data files if that helps.
Thanks in advance.
Search Sharp 003SH Root Success and Sharp 005SH Root success on Youtube for more info
Can't really help you. Don't know anything about it. But I would like to know how you ended up rooting this phone of ours.
Its not a file on the filesystem. The sim locking in these phones is in the radio image; which can be accessed when you use the custom build kernel thats in the latest rootkit (I assume thats what you are using).
See the 2ch root/ROM thread for more details, but basically it is done through ADB, manually backing up the "_modem" partition; stripping the spare/ECC bytes and then extracting the radio OS using QualcommDumpAnalyser
I have managed to extract this image, but no idea where to go from there. None of the other device info seems to apply to this (HTC, Samsung, LG, any other Android that has had its sim-lock discovered in the radio)
Advice i got from the guys on 2ch: "Qualcomm's NAND code is neither difficult, nor unique, so if you know what you are looking for its not hard"
003SH 005SH Sim unlock
Thanks very much for giving me a new direction. I'll get started on it right away and let you know how it progresses.
It just sucks that the guys who know how to unlock it are staying quiet, saying its "taboo"
FYI, stripping the Spare/ECC bytes can be done manually (i wrote a C program to do it), but there is an option in the RevSkills app to do it all for you - i recommend doing that.
Of course we face another issue once we find the actual unlock - recalculating the ECC bytes after making the change; the only way to access the radio is with raw data access.
P.S. hope you have warranty on your phones - this is very likely to brick at least one phone until we get it right
---------- Post added at 12:30 PM ---------- Previous post was at 12:24 PM ----------
In the spirit of open cooperation, here are the instructions i was given, translated and simplified
In ADB Shell, type su to get the # prompt, then:
cat /proc/mtd <Enter>
Confirm that you have the "_modem" partition available. If not, you need to reflash with the custom build kernel
Dump the image to file with the following command:
dump_image -r -D -F _modem /sdcard/backupimages/modem.img
Access this with anything as "raw dump" and all blocks will get read as ECC error, so definitely dont do this
ECC positioning is different to Linux, so take care
The following maps out how 512bytes of data and 10 bytes of ECC info are stored in a 528 byte block:
0000 - 01CF (0-463): Data
01D0 - 01D1 (464-465): Unused (0xff)
01D2 - 0201 (466-513): Data
0202 - 020B (514-523): ECC
020C - 020F (524-527): Unused (0xff)
Use RevSkills application to extract the data portions:
Menu⇒Calculators/Generators⇒Android MTD Nand remove Spare and ECC
Extract all of the Data only portions out of the raw dump, and then use QualcommDumpAnalyser to read it and split up the various parts. I did notice that i wasnt able to get the AMSS block out with QualcommDumpAnalyser - i copied that out manually by calculating the byte positions shown in QDA.
003SH bootloader key sequence?
Eternalardor,
I'd be happy to swap information. Perhaps you could shed some light on the question of the bootloader for the Sharp 003SH and 005SH? There seems to be no discernible key sequence (Power+home+Volume up etc.) to access the bootloader. I feel like I've tried them all. Can you tell me this critical piece of information?
Is a form of the USB Jig necessary to access it?
Looking forward to your response.
003SH SIM unlock
Dominik,
Here are the results of the original /proc/mtd (before rooting)
boot
cache
misc
recovery
ipl
system
persist
log
battlog
calllog
ldb
userdata
I don't see the _modem partition. Should I?
I have also included a screenshot of the results showing size. I have most of them backed up as .img files too.
FYI: .img backed up sizes. Perhaps this will help you to ponder where the _modem partition may have gone. Maybe it's been renamed?
boot 11,264KB
cache 3,072KB
misc 1,024KB
recovery 11,264KB
ipl 15,360KB
system 419,840KB
persist 30,720KB
ldb 45,056KB
userdata 405,120KB
There is no bootloader menu AFAIK. If you install the custom kernel, you will have the option of a quasi-recovery mode, by pressing the home button between 7-12 seconds after the Galapagos logo is seen (or was that the Softbank logo)
Anyway, looking at the screenshots, it seems you do not have the custom kernel.
How did you achieve root on your phone?
To do this, you need to use the "003sh_005sh_dm009sh-rootkit" from at least 5/27 (recommend _0614); which is available on the 2ch forums. This includes 2 possible ways of achieving root:
1. A modified standard kernel (boot image), which, when flashed gives you regular root access
2. A custom compiled kernel, which has full root, a bunch of power profiles, and heaps more features (inc that quasi recovery), as well as access to the "_modem" image.
Judging from your youtube videos, you speak some Japanese, so the Japanese menus in the rootkit shouldnt be much trouble.
http://www1.axfc.net/uploader/Si/so/142435
This is what i used.
Go here for help/instructions http://anago.2ch.net/test/read.cgi/android/1337845757/
And dont even think about typing in English on there, or you will be ignored and/or told to go away
This all looks familiar. I have been using the root kit (5/27) to get where I am now - step by blessed step. It was pretty straight forward BUT I have never seen the option to write to the system partition. It is in all the instructions but the only option I have with respect to the system partition is to back it up. I'm confused as to why it doesn't seem to show up for me. I am using a Japanese machine so all the characters are displayed and I can read the instructions but I can't find help anywhere as to why I don't have that particular (and critical) option. I can see a lot of new and cool options in the 6/14 release. I'm excited and would like to get it installed.
I'll let you know how it goes. Thanks for your help .... keep it coming!
And another thing
Could you explain a little more about "having" the custom kernel? Using the root kit, I wrote to the Recovery partition then the Boot partition then rebooted from the Recovery partition and all seemed well. As I said above, I have never been able to write to the System partition despite it appearing in all the instructions. I suspect that is what is holding me back from the latest and greatest custom kernel. Still, I am enjoying all the same functionality that everyone else seems to be enjoying in root. What am I missing?
Eep, you wrote to the boot partition before trying the recovery? Brave!
The steps should be:
Write image to recovery partition;
Then reboot to recovery partition (from the menu) and confirm it all works without errors.
Then write image to boot partition
And then turn off the phone, and reboot (the last part is only my instructions - you could just select "reboot to boot partition" from the menu)
You are doing this on your 005SH right? It should be the same for the 003SH, but i only have the 005SH. In the rootkit there is 2 options when you say "burn custom image":
1 カスタムビルドrootedカーネル（リカバリーキット機能付き）
2 S4080 標準rootedカーネル（簡易リカバリー機能付き）
Q 中止してメインメニューへ戻る
You must do the first one, the CUSTOM rooted kernel, to get any of the really cool features. The second option is only if you just want root access for a particular app or something. AFAIK the second option doesnt even disable MIYABI LSM, which prevents you from mounting the system dir as R/W
But either way, writing to the System dir is not important for what we are doing. You need the Custom kernel, which gives you access to the "_modem"
Edit, i just noticed in your screenshots above, you didnt even get root in ADB shell?
Type
ADB Shell<Enter>
Then type
su<enter>
The cursor should change to a #, this means root. You may get a prompt on the phone from Superuser asking you to give root access to "shell". Once you have this try the cat /proc/mtd again
jcroot003sh,
can you tell me how to root 003sh?
Use the link i provided in my previous post
http://forum.xda-developers.com/showpost.php?p=27989085&postcount=8
You can use a translator if you dont understand Japanese, but the general instructions are in the post above yours
I translated it for a friend, but that is at work, so wont be able to put it up until monday.
DominikB said:
Use the link i provided in my previous post
http://forum.xda-developers.com/showpost.php?p=27989085&postcount=8
You can use a translator if you dont understand Japanese, but the general instructions are in the post above yours
I translated it for a friend, but that is at work, so wont be able to put it up until monday.
Click to expand...
Click to collapse
Thank you for your replying. I will wait for your translated version. You are really a good person.
Progress
I have successfully found and dumped the "_modem" image. Exactly as you stated - forgot the "su" command in ADB. Thanks. The next problem is editing out the code. I am way above my head here so I will do some research before bugging you for a step-by-step for that.
Also, the bootloader worked. I didn't realize how to do it until I read the notes in the 6/14 release. I successfully put a previously dead phone back on it's feet EXACTLY to the point of my current phone simply by backing up and then restoring partitions through the bootloader. Very slick and easy.
Will get to work. I'll be in contact soon with my progress on the SIM unlock.
I have spent a bit of time looking at it, it certainly isnt easy (Certainly isnt a "lock=yes" section). I assume the actual locking portion is encrypted/compressed/or just compiled, because it would be too easy otherwise (be happy to be proven wrong). For starters, i cannot even find my IMEI number in the dump file... I think that this dump only includes the radio code, not the NV RAM which contains the IMEI and SIM Lock status. If that is the case then the solution should be to change the portion of the radio code that queries the NV RAM, so that it doesnt care if the SIM lock is supposed to be applied.
Extracting the spare/ECC bits out should be done with the RevSkills app; extracting the relevant portions, that is a bit of a cludge; QualcommDumpAnalyser can show the start/end positions, but doesnt extract the AMSS part (AFAIK thats where the code will be). You need to use a hex editor to cut that part out manually... And i am still not 100% sure what the block size is on this NAND.
Good luck!
And if there *are* any experienced hackers out there willing to help out, i can offer some monetary help (as will a few of my fellow Japanese smartphone owning friends) as this will be valuable for not just these 2 phones (there is an army of 007SH owners waiting on this unlock)
Shall we give the 007/009 a shot?
I can see mountains of the 007SH on the auction (mostly pink). Perhaps I should pick one up and take it for a spin. I am happy to try to do something to help out for all the help I am receiving.
Or perhaps the 009SH?
How hard would it be to crack the 007? The 009SH looks like it is supported in the latest release kit.
Thoughts?
Currently, the 003/005SH are going to be the easiest, because they have the custom kernel which allows access to the "_modem" image. To do it on the 007SH we need to build a custom kernel (compiled from the sources available on the ktai-dev site), and add the modem access code (this is in the src directory of the rootkit). Not impossible, but i dont have a Linux machine to compile the sources.
However i think that the code will be fairly universal. Once we find it on the 005SH we will know what we are looking for on the 007SH as well. That will make many people happy
Anyway, my 005SH is under warranty/anshin plan so i dont mind if it gets bricked (especially now that we can take nand backups).
First things first though - examining the 005SH modem image. Does anyone know whether the NAND is a 16kb or 128kb block size? Or is it something completely different?
P.S. The DM009SH is just the Disney Mobile version of the 003SH
Linux machine no problem
I have a Linux server running 24/7 so compiling the kernel is easy. Don't let that be the holdup. I'll keep working on the 003SH _modem image.
DominikB,
I can't open this site [anago.2ch.net/test/read.cgi/smartphone/1319287551/] on channel2 for free. This site had been moved to the past-log storehouse. So.... I even can't look at Japanese version for rooting 003sh. It is very helpful if you can show me the steps for rooting 003sh.
Firstly a big thank you macexplorer who again found the relevant links amongst much Japanese.
See the original thread on rooting the F-01D:
http://forum.xda-developers.com/showthread.php?t=1611484
Following are quick instructions on how to upgrade the device to ICS. All your data will remain intact, but the /system partition is completely wiped.
NB: YOU WILL LOSE ROOT IF YOU FOLLOW THESE INSTRUCTIONS. YOU WILL NOT GET ROOT BACK.
To be clear, at the present moment in time, you need to CHOOSE BETWEEN ICS OR ROOT, you can't have both. The official upgrade below completely reflashes the system partition, so tools like OTA RootKeeper will not help you. The new release is more secure than ever and at current we don't know a new way to get root. If anyone finds any new information, please speak up
DISCLAIMER: Following these instructions might brick your device, void your warranty, etc. This is unlikely since you're basically installing an official update, but to be clear, I disclaim any and all responsibility for any (permanent) damage that might be caused by these instructions. DO AT YOUR OWN RISK.
The original instructions are here (or see in Google Translate)
http://spf.fmworld.net/fujitsu/c/update/nttdocomo/f-01d/update1/top/index.html
My instructions are slightly different, aimed at more advanced users, and serves the file direct from my server (I found the original server quite picky in terms of refer and user agent, and also slow. I'm also serving the unzipped version, since compression was 0% anyways).
PRE-REQUISITES
At least 50% battery (ideally more in case things go wrong...).
Settings -> About, make sure Android version is 3.2, and Build number is either V28R43A (as recommended on the official page) or V19R36D (what I had; it worked for me but YMMV).
Settings -> Storage, at least 1.5 GB free in "Built in storage" (try installing first to external SD card and let me know if it works.. it's a lot safer).
ICS UPGRADE FOR F-01D
Download F01D_TO_SP_ICS1.enc and put it in /sdcard (md5sum: 2014d0254568a4ef955b21476012a9b5)
Boot into recovery (power off, hold down both volume keys and power up), select "update firmware" and press the power button agin.
Pay attention... the first time I tried this, it rebooted back in to recovery part way.... if this happens, just repeat step 2 above and make sure the progress bar completes all the way.
After this, it will reboot a few times, don't worry. Boot 1 will do the "optimizing android apps" screen, Boot 2 will be "upgrading calendar, contacts, etc..." and Boot 3 will say "finishing upgrade" and let you use the system.
If anyone has any leads on re-rooting the device, speak up. From my initial observations security is tighter than ever, so this might be a problem... but there are clever people out there
Regarding root
No leads for now. We can create /data/local.prop using the ICS/JB restore technique, but unfortunately the new firmware is completely ignoring either this file or the ro.kernel.qemu property.
If I understood the google translated Japanese correctly, this guy got to the same conclusion, and is now looking for other solutions. I wish him luck because after spending the day on this I have to get back to my real work
http://blog.huhka.com/2012/09/arrows-tab-lte-f-01d-icsshell-root.html
Temporary Root
This link in xda works to get a temporary root:
http://forum.xda-developers.com/showthread.php?t=1886310
i think to get permanent root, need the lsm_disabler.ko for ICS kernel.
Update:
ICS kernel has blocked loading kernel modules; so cannot insmod a custom kernel.
so cannot remount /system, and cannot get permanent root..
shame on the dandroids..
Post upgrade restart errors?
Hi, slightly off-topic but related - has anyone had issues after upgrading with google maps? Whenever I start google maps it will hang and then restart my tablet.
Essentially google maps is now unusable which is very annoying. Please let me know if anyone has experienced this too and if so if they have a solution to the problem.
Many thanks in advance!
I lost boot after upgrade the device to ICS :crying:
anyone help me repaid boot
Thanks:laugh:
longdau12 said:
I lost boot after upgrade the device to ICS :crying:
anyone help me repaid boot
Thanks:laugh:
Click to expand...
Click to collapse
Help me :crying:
macexplorer said:
This link in xda works to get a temporary root:
http://forum.xda-developers.com/showthread.php?t=1886310
i think to get permanent root, need the lsm_disabler.ko for ICS kernel.
Update:
ICS kernel has blocked loading kernel modules; so cannot insmod a custom kernel.
so cannot remount /system, and cannot get permanent root..
Click to expand...
Click to collapse
FINALLY..ROOT on F-01D for V08R31A
I hope someone is still using the F-01D. So here's to you diehards.
After many many failed attempts, i finally managed to get a more permanent root.
Probably others have got this to root, but I havent seen anything come up via searches.
Main stumbling block has been in getting the address of 'ptmx_fops'. Finally got it thro, rootkitXperia_20131207.zip (get_root..this prints but fails in ptrace; ptrace is blocked in f01d)
I have just managed to get a permanent root. The steps maybe little approx. Do verify and let me know. Its non-destructive, so no harm done.
but do at your own risk..and other standard disclaimers apply
Steps:
1. do the temp root as per : http://forum.xda-developers.com/showpost.php?p=33071441&postcount=3
2. get the exploit source from https://github.com/fi01/unlock_security_module
(recursive download)
3. compile the source. this will generate a libs/armeabi/unlock_security_module binary
4. add the following recs to the device_database/device.db
these are kallsyms kern func addresses; most are avail direct from kallsyms, except for ptms_fops.
Code:
sqlite3 device_database/device.db
insert into supported_devices values(187,'F-01D','V08R31A');
insert into device_address values(187,'commit_creds',3221986012);
insert into device_address values(187,'prepare_kernel_cred',3221985196);
insert into device_address values(187,'ptmx_fops',3229222484);
insert into device_address values(187,'remap_pfn_range',3222251308);
insert into device_address values(187,'vmalloc_exec',3222293708);
5. push device.db and unlock_security_module to /data/local/tmp/
6. simply run from /data/local/tmp: ./unlock_security_module as the root obtained temp earlier.
7. after sometime, this will say LSM disabled!!
8. now remount /system as rw. carefully copy su binary to /system/xbin/ (pref use the latest version from SuperSu).
Also copy Superuser.apk to /system/app
>>carefully copy means: chown/chgrp /system/xbin/su to "0"; set perms: chmod 06755 /system/xbin/su.
9. copy busybox from /data/local/tmp to /system/xbin; and install (./busybox --install -s /system/xbin/
10. At this stage, su doesnt seem to work for newer shell connections (must do _su and then su). probably due to the exploit messing up the kernel.
11. reboot. and enjoy your newly permanent rooted status.
12. after reboot, still cannot do system remount as lsm is back to original. rerun the unlock_security_module should disable this.
maybe even move this to /system/xbin/;
But this seems to destabilise the system.
Its not possible to use a lsm disabler ko insmod. the kernel sec mech validates the module with path and hash.
So it has to be: unlock security; do your thing with /system etc., reboot.
(not sure yet if any changes to /system/buid.prop will help)
Do let me know how this works out and point out errors in the steps.
And as luck would have it there is a new ICS release out on 5-Feb.
https://www.nttdocomo.co.jp/support/utilization/product_update/list/f01d/index.html
http://spf.fmworld.net/fujitsu/c/update/nttdocomo/f-01d/update1/top/data/download.html
(F01D_TO_SP_ICS2.zip)
This moves the version to V12R33B.
Do not hazard to update to this, if you want to keep this root. this release probably fixes many of the exploits.
the wifi model seems to have got 4.1..wonder is something will trickle down to f01d.
Drawing from the impressive work of CrashXXL in rooting our phones, jahrule in simplifying the process, and Sabissimo in developing a tutorial to bake in apps for those of us with locked bootloaders and write protected systems, I have with great effort arrived at this glorious day. I present to thee: Suicide Flash.
What is Suicide Flash? It is a collection of Bash scripts and other files which streamline and automate the process of using the Qualcomm emergency download mode (Qualcomm HS-USB QDLoader) to write to the system partition on Moto phones using MSM8960 processors. It applies the method used to root these devices (see here, for example) to the task of arbitrary system modification. In other words: Suicide Flash makes it easy(ish) to modify system files for those of us who can't use traditional methods.
Code:
DISCLAIMER: This is obviously a dangerous tool. I mean, it
flashes your phone by bricking it first. Be smart. I shan't be held
responsible if your phone melts, explodes, loses all of its data,
or cheats on you with a hula dancer.
Who Can Use It?
Suicide Flash is for sure compatible with most Moto X variants. The testing has been done primarily with an XT1049, the Republic Wireless model, but has also included the XT1060 (Verizon) and should work on most/all of them. However, in theory any phone, or at least any Moto phone, using the MSM8960 chip could be compatible, such as the Droid Turbo. So to simplify:
XT1049 (Moto X Republic Wireless): Tested and working
XT1060 (Moto X Verizon): Tested and working
XT1058 (Moto X AT&T): Untested, highly likely to work
XT10XX (Any other Moto X): Untested, likely to work
Others: Untested, may work as long as they use MSM8960
How Do I Use It?
Suicide Flash (SF) consists of three main scripts: a flashing script, a package creation script, and a pushing script. Details:
suicideflash.sh: Flashes SF packages to the phone in bricked (QDLoader) mode
pkgmaker.sh: For developers. Creates SF packages from system images.
suicidepush.sh: Uses the SF system to "push" system files in an ADB-like way
To use these scripts, simply extract them to a place of your convenience. All scripts must be run from the root Suicide Flash folder. Do not run any of them from within the "scripts" folder. Also, while it may not strictly be necessary, it is best (if you are developer) to include any relevant system images in the root Suicide Flash folder, as well.
As an end user, you can download SF packages created by developers and flash them using the main Suicide Flash script. As a developer, you can pull system images and use them to create SF packages with the pkgmaker.sh script. Anyone can feel free to use the Suicide Push script to push files to their device. For more information, here are the help pages for each.
Suicide Flash:
Code:
Usage: suicideflash.sh PACKAGE
Flashes PACKAGE to the system parition of a Moto phone using Qualcomm
emergency download mode.
Options:
-h, --help displays this help message
-s, --skip skips all prompts and runs without user interaction
Created by the Nicene Nerd, whose blog at <http://www.thenicenenerd.com/> has
absolutely nothing to do with Android
Package Maker:
Code:
Usage: pkgmaker.sh [OPTION]... ORIGINALSYSTEM TARGETDEVICE REQUIREMENTS
SYSTEMOFFSET OUTPUTFILE
Creates a Suicide Flash package for writing to Moto phones via the emergency
Qualcomm download mode.
Arguments:
ORIGINALSYSTEM provides the original system image to be modded
TARGETDEVICE specifies the model of phone for the package to flash
REQUIREMENTS notes any important requirements for the phone state
prior to flashing
examples: "Stock", "Rooted", or "Rooted+Xposed"
SYSTEMOFFSET the address of the system partition on the target device
should be in hex format (i.e. 0x6420000 or 6420000)
can use value ADB to pull the offset over ABD
OUTPUTFILE the name of the Suicide Flash zip package to be created
Options:
-h, --help returns this help message
-m MODDEDSYSTEM specifies an existing modded system image
if not given, will mount original for modification
Created by the Nicene Nerd, whose blog at <http://www.thenicenenerd.com/> has
absolutely nothing to do with Android
Suicide Push:
Code:
Usage: suicidepush.sh LOCALFILE REMOTEFILE
Uses Suicide Flash to push LOCALFILE to a phone system at REMOTEFILE.
Created by the Nicene Nerd, whose blog at <http://www.thenicenenerd.com/> has
absolutely nothing to do with Android
What Do I Need to Use It?
A Linux installation
ADB
Fastboot
Rhino
Python
A package called python-serial
VirtualBox
ADB Insecure (if developing or using Suicide Push)
If you don't have some of these (except, obviously, the first one and the last one), you can run the included script install-tools.sh. It will automatically install anything you're missing.
Okay, Give Me Step-By-Step Instructions
For End Users:
Download the attached Suicide Flash zip
Extract the zip to a convenient folder and open a terminal window there
Go ahead and use sudo su
Run install-tools.sh
Download an SF package from a developer for your device
Flash the package with the command:
Code:
./suicideflash.sh DOWNLOADEDPACKAGE.zip
Profit!
For Developers:
Download the attached Suicide Flash zip
Extract the zip to a convenient folder and open a terminal window there
Go ahead and use sudo su
Run install-tools.sh
Pull a system image from your phone
Run pkgmaker.sh to create an SF package
Upload the package for the benefit of others
For Anyone, to Use Suicide Push
Download the attached Suicide Flash zip
Extract the zip to a convenient folder and open a terminal window there
Go ahead and use sudo su
Run install-tools.sh
Push files to your phone's system partition with this command:
Code:
./suicidepush.sh LOCAL_SOURCE /system/PUSH_DESTINATION
So, What Can I Do with It Right Now?
If you're a developer, you can get to work creating SF packages for your device. If you're just a plain ol' user, there's not much to be done until others chip in. I have uploaded one package as a sample and for the convenience of anyone looking to root their XT1049 and install Xposed. I will maintain a master list of uploaded packages as people make them.
XDA:DevDB Information
Suicide Flash for Moto, Tool/Utility for the Moto X
Contributors
Nicene Nerd, CrashXXL, Sabissimo
Version Information
Status: Testing
Created 2015-08-07
Last Updated 2015-08-07
Master Package List
XT1049: Republic Wireless Moto X
- root-xposed-xt1049-4.4.4.zip: Root and Xposed for XT1049. Requires stock 4.4.4 from SBF, not OTA.
- busybox-xt1049-rooted-xposed-4.4.4.zip: BusyBox for XT1049. Requires 4.4.4 rooted w/ Xposed.
XT1058: AT&T Moto X
- root-xt1058-4.4.4.zip: Root for XT1058 KitKat. Requires stock 4.4.4 from SBF, not OTA.
- xposed-xt1058-rooted-4.4.4.zip: Xposed for XT1058 KitKat. Requires rooted 4.4.4.
- root-xt1058-5.1.zip: Root for XT1058 Lollipop. Requires stock 5.1 from SBF, not OTA.
XT1060: Verizon Wireless Moto X
- root-xt1060-4.4.4.zip: Root for XT1060. Requires stock 4.4.4 from SBF, not OTA.
- xposed-xt1060-rooted-4.4.4.zip: Xposed for XT1060. Required rooted 4.4.4.
Changelogs:
08/07/2015 - v0.2
- suicideflash.sh: Increased wait period before giving error on not finding phone in emergency mode
- mountimg.sh: Fixed issue which would cause errors preventing images from mounting
- pkgmaker.sh: Added option to pull system image over ADB, improved error handling
Developer pkgmaker.sh Tutorial: Creating an Xposed Framework Package
Say you want to make a package that installs the Xposed framework, since that requires writing to /system. Here's how you would do it with Suicide Flash (assuming you have already rooted the phone):
Open a terminal window to your Suicide Flash root folder. Then sudo su.
Pull a system image. One way to do that:
Code:
adb root
adb shell dd if=/dev/block/platform/msm_sdcc.1/by-name/system /sdcard/originalsystem.img bs=1024
adb pull /sdcard/originalsystem.img
Run the pkgmaker script like this, assuming you're using a rooted XT1049 on 4.4.4, but you don't know the offset of the system partition, so you want to pull it via ADB. The script will be placed in output/xposed-flash-package.zip.
Code:
./pkgmaker.sh originalsystem.img XT1049 "Stock 4.4.4" ADB xposed-flash-package.zip
The script will pause when originalsystem.img is mounted for writing. As root, copy the Xposed app_process file (which you can extract from the APK if you need it) to "mnt-originalsystem.img/bin/app_process". Then press enter.
The script will continue executing, hopefully without errors.
Voila! Your package xposed-flash-package.zip is ready to upload and/or flash.
Finally!
The XT1049 has stumped me for a long time, but finally someone found a way!
Just a thought as I'm going into this, there's no mention of drivers for linux. Obviously this isn't to "user" level yet, and I wouldn't put myself too much beyond that, but it's a nice thing to include. I'll be trying it later, but are the drivers for USB/ADB the same as the emergency mode drivers? I'm kind of nervous to try because of the soft brick, and there doesn't appear to be any mention of how the flashed file that bricks it is put back. I'm assuming I can pull the original image before I flash the new one, but I'm not sure yet.
Also, if you have it tested and everything with Republic, I would appreciate a torrent or hosted file somewhere. If there isn't one before I finish, I'll post it.
---------- Post added at 09:42 PM ---------- Previous post was at 09:38 PM ----------
Cindex said:
The XT1049 has stumped me for a long time, but finally someone found a way!
Just a thought as I'm going into this, there's no mention of drivers for linux. Obviously this isn't to "user" level yet, and I wouldn't put myself too much beyond that, but it's a nice thing to include. I'll be trying it later, but are the drivers for USB/ADB the same as the emergency mode drivers? I'm kind of nervous to try because of the soft brick, and there doesn't appear to be any mention of how the flashed file that bricks it is put back. I'm assuming I can pull the original image before I flash the new one, but I'm not sure yet.
Also, if you have it tested and everything with Republic, I would appreciate a torrent or hosted file somewhere. If there isn't one before I finish, I'll post it.
Click to expand...
Click to collapse
Sorry for the double post but I can't edit yet, just realized that the zip file there is all that's needed for Republic. I was going to post the ADB/USB driver setup link for linux, but I'm not allowed yet.
Cindex said:
The XT1049 has stumped me for a long time, but finally someone found a way!
Just a thought as I'm going into this, there's no mention of drivers for linux. Obviously this isn't to "user" level yet, and I wouldn't put myself too much beyond that, but it's a nice thing to include. I'll be trying it later, but are the drivers for USB/ADB the same as the emergency mode drivers? I'm kind of nervous to try because of the soft brick, and there doesn't appear to be any mention of how the flashed file that bricks it is put back. I'm assuming I can pull the original image before I flash the new one, but I'm not sure yet.
Click to expand...
Click to collapse
You shouldn't need to do anything special for Linux drivers. It works straightforwardly as long as you have fastboot and ADB. The flashed file that creates the softbrick is included by the package maker script in every Suicide Flash package, so it is easy to unbrick. In fact, I can upload another package just for unbricking if you'd like.
Added a BusyBox package for XT1049, and added root and Xposed packages for XT1060.
Edit: also added root packages for XT1058 on both KitKat and Lollipop, plus Xposed for XT1058 KitKat.
Nicene Nerd said:
You shouldn't need to do anything special for Linux drivers. It works straightforwardly as long as you have fastboot and ADB. The flashed file that creates the softbrick is included by the package maker script in every Suicide Flash package, so it is easy to unbrick. In fact, I can upload another package just for unbricking if you'd like.
Click to expand...
Click to collapse
That's good to know, I looked around and couldn't find anything on the driver for the Qualcomm Emergency Download mode. I suppose not needing one would be why. Actually some kind of emergency package to unbrick might be good. Now that I see the script in there I don't have a problem, but someone might like it.
So now I'm wondering if I actually have to do a factory reset again, or if I can just flash the SBF file itself and not have to wipe. I'm not sure how big of a difference there is, because I did the factory restore recently and the OTA update was like 6MB or something. I wouldn't think there's be an issue flashing it rather than factory restore. Any ideas?
Also, if anyone knows a good way to do this with Virtualbox it would be a nice addition. I'm personally not going to bother since I already have a bootable Ubuntu USB, but it seems that most people would rather set up a VM with a small linux distro. If it had the tools baked in, it would make it an easy process.
Cindex said:
That's good to know, I looked around and couldn't find anything on the driver for the Qualcomm Emergency Download mode. I suppose not needing one would be why. Actually some kind of emergency package to unbrick might be good. Now that I see the script in there I don't have a problem, but someone might like it.
So now I'm wondering if I actually have to do a factory reset again, or if I can just flash the SBF file itself and not have to wipe. I'm not sure how big of a difference there is, because I did the factory restore recently and the OTA update was like 6MB or something. I wouldn't think there's be an issue flashing it rather than factory restore. Any ideas?
Also, if anyone knows a good way to do this with Virtualbox it would be a nice addition. I'm personally not going to bother since I already have a bootable Ubuntu USB, but it seems that most people would rather set up a VM with a small linux distro. If it had the tools baked in, it would make it an easy process.
Click to expand...
Click to collapse
Technically, the only reason for the SBF is because when you install OTA updates, files may end up in slightly different positions depending on the circumstances. For this to work, you must start with an identical system partition to the one used for making the package. So all you need to really do is extract the system.img and flash it, if you wish. No data loss necessary.
Also, I'll look into a minimal VM. I thought about actually trying to make a Windows version of Suicide Flash. I'm not sure which I'll end up with.
So I tried this on my Ubuntu 12.04.5 last night, and it didn't recognize the device in fastboot. I'm going to try on Ubuntu 15.04 soon here. Another question for you though, which sdk do I use for XPosed? I don't seem to be able to figure it out searching all over. I would think 16, but maybe it's for Lollipop?
I think I'm going to get some of these with the OTA, it'll make it easier for the average Republic user once it's gotten going.
Cindex said:
So I tried this on my Ubuntu 12.04.5 last night, and it didn't recognize the device in fastboot. I'm going to try on Ubuntu 15.04 soon here. Another question for you though, which sdk do I use for XPosed? I don't seem to be able to figure it out searching all over. I would think 16, but maybe it's for Lollipop?
I think I'm going to get some of these with the OTA, it'll make it easier for the average Republic user once it's gotten going.
Click to expand...
Click to collapse
I can't answer your Xposed Lollipop question. I was wondering the same thing, but I ended up simply pulling the file from an existing Xposed installation. I suppose you could do the same and then diff the files to find out which is correct.
As for the OTA, that's not possible. Every time an OTA is installed, the files can end up in different places on the flash memory, and this utility requires knowing the exact locations for making changes. You'd have to make separate packages for every phone. Otherwise you'll end up with bootloops.
Has anyone tried using Suicide Push? It's slow, but I thought it would be the more celebrated part of this since it lets you do basically the same as an ADB push to the system partition. You could even install Xposed that way:
Code:
./suicidepush.sh local_app_process_file /system/bin/app_process
Nicene Nerd said:
Has anyone tried using Suicide Push? It's slow, but I thought it would be the more celebrated part of this since it lets you do basically the same as an ADB push to the system partition. You could even install Xposed that way:
Code:
./suicidepush.sh local_app_process_file /system/bin/app_process
Click to expand...
Click to collapse
I'm still working on getting it to root. I was going to a few days ago, but my flash drive burned out. I'm going to try Ubuntu 14.04.3.
What linux distro did you use?
---------- Post added 14th August 2015 at 12:41 AM ---------- Previous post was 13th August 2015 at 11:47 PM ----------
Sorry to double post again, but I can't edit yet and have a few more things. I can't seem to be able to find a RW SBF file. I'm thinking restore from factory sounds like a good solution, but I don't know if that's the same thing.
How can I pull a system image if I'm not root? Without an SBF file, I need to package it for myself. Without root, I can't pull the system.img. I'm sure others on networks not covered yet would like to know also. Where did you get your system.img?
Also, if we can get this deep, and you can modify the bootloader, couldn't you just flash the old bootloader image and then the rest of the ROM? Then we could unlock the bootloader using older methods. We might have to flash block by block, but it should work?
Cindex said:
I'm still working on getting it to root. I was going to a few days ago, but my flash drive burned out. I'm going to try Ubuntu 14.04.3.
What linux distro did you use?
---------- Post added 14th August 2015 at 12:41 AM ---------- Previous post was 13th August 2015 at 11:47 PM ----------
Sorry to double post again, but I can't edit yet and have a few more things. I can't seem to be able to find a RW SBF file. I'm thinking restore from factory sounds like a good solution, but I don't know if that's the same thing.
How can I pull a system image if I'm not root? Without an SBF file, I need to package it for myself. Without root, I can't pull the system.img. I'm sure others on networks not covered yet would like to know also. Where did you get your system.img?
Also, if we can get this deep, and you can modify the bootloader, couldn't you just flash the old bootloader image and then the rest of the ROM? Then we could unlock the bootloader using older methods. We might have to flash block by block, but it should work?
Click to expand...
Click to collapse
I used Ubuntu 14.04.
The RW 4.4.4 SBF can be found here or here. It does not appear possible to pull a system image without root. But even without permanent root, KingRoot can get you temp root long enough to pull a system image.
As for the bootloader, there's certainly a chance that this could be done. It's just so risky that I won't try it myself. If there was a single variable missed, it could easily mean hard-brick. But in theory, as far as I understand, it might work. The biggest obstacle might be partition changes. If you got the bootloader to get into fastboot mode, though, you could presumably fix that with an old SBF.
Flashing the olderer bootloader will not work (I have tried and confirmed it does not work). It is because the efuses verify the bootloader.
Wow! That's hell of a tool you've created here Awesome job! I haven't tried it myself yet, but, judging by source code, it should get the work done. More of a developer tool, ofc, but it's more then impressive Maaan, I wish there was a normal way to work with ext4 partitions to make it available on Windows))
Since you've made "push" version of it (and that's the most interesting part, longest though), the next step in future development should be doing the same with TWRP flashable zips. Some of them just put apk-s in system folder, some of them have shell scripts inside, I've yet to figure out the pattern But that would be awesome next step to this awesome project
download link not found )
theres a tool bar at top crash with download links next to discussions and screenshots
Sabissimo said:
Wow! That's hell of a tool you've created here Awesome job! I haven't tried it myself yet, but, judging by source code, it should get the work done. More of a developer tool, ofc, but it's more then impressive Maaan, I wish there was a normal way to work with ext4 partitions to make it available on Windows))
Since you've made "push" version of it (and that's the most interesting part, longest though), the next step in future development should be doing the same with TWRP flashable zips. Some of them just put apk-s in system folder, some of them have shell scripts inside, I've yet to figure out the pattern But that would be awesome next step to this awesome project
Click to expand...
Click to collapse
I've actually started work on a Windows version, but it's on back burner because school just started. Here's a hint, though: with OSFMount and Ext2Fsd, you can mount Moto system images (pulled from the phone, not SBF ones) as hard drives or removable disks. Suicide Flash for Windows will rely on them.
So what are the chances I could use this to pull a system.img, and actually go in and delete some apps out of my XT1058? I had some success but it pulled the image as a mbn and I'm hesitant to try flashing it.
lpjunior999 said:
So what are the chances I could use this to pull a system.img, and actually go in and delete some apps out of my XT1058? I had some success but it pulled the image as a mbn and I'm hesitant to try flashing it.
Click to expand...
Click to collapse
Here's what you'll want to do:
Create the system image on the phone with
Code:
dd if=/dev/block/platform/msm_sdcc.1/by-name/system of=/sdcard/oldsystem.img bs=1024
ADB pull or MTP copy the image to your PC.
Run pkgmaker.sh like so:
Code:
./pkgmaker.sh oldsystem.img XT1058 "My System" 4B000000 modded-system.zip
When prompted, you can delete apps as root from the mounted system image under mnt-oldsystem.img/app or mnt-oldsystem.img/priv-app
Continue and finish the script.
Flash with
Code:
./suicideflash.sh -s output/modded-system.zip
Hey All
I'm new to Android but not linux.
Bought cheap Allwinner type 5.1.1 tablet - 10.6" Fusion5 108 Octa Core Android Tablet PC
rooted it using KingRoot, messed around with Supersume to remove KingRoot and now device won't boot properly. Using adb I can see dmesg is complaining about debuggered which is actually now a zero byte file. su won't work now and I don't have the rights to fix it.
Before I did any of this the first thing I did as root was backup the mmc partitions to a USB stick.
The bootloader and recovery areas have not been changed.
Can I use my system partition backup to create a update.zip for use in recovery mode?
Or maybe in fastboot though I'm currently having problems getting fastboot to see my tablet whether I use linux or windows so recovery mode fix prefered..
lol
Looks like the solution is to post here, and then find a partial answer 5 minutes later.
fastboot command on linux didn't work (despite adb working, udev configured etc)
Then tried with manufacturer id
fastboot -i 0x1f3a
then works
Then did
fastboot -i 0x1f3a erase system
fastboot -i 0x1f3a flash system /home/user/android/13-11-16/system
It complained that about magic so I suspect this DIDN'T work. although data was sent.
fastboot -i 0x1f3a reboot
and device came up in a graphical environment asking for wireless password. Judging by network trace on my router I think it might be trying to download a factory image over the Internet. Will see.
Bit confused as my system parition backup is like 900Mb but when I did flash system I think it said device reported size was 32MB approx. More to learn
OK
The 32Mb was referring to buffer size, so can confirm system flash did work.
Device was booting, getting to graphical environment, and then trying to connect some web servers - not sure why really but seem to have got past that point.
Now can't install apps - get stuff like
W/art ( 9462): Unable to open /data/dalvik-cache/. to delete it's contents: Permission denied
W/art ( 9462): Unable to open /data/dalvik-cache/arm to delete it's contents: Permission denied
W/art ( 9462): Could not create image space with image file '/system/framework/boot.art'. Attempting to fall back to imageless running. Error was: Unable to relocate image '/system/framework/boot.art' from '/system/framework/arm/boot.art' to '/data/dalvik-cache/arm/[email protected]@boot.art': Only the zygote can create the global boot image.
Think /data is corrupt so will flash my backup of that.
I'm more thinking outloud at this point rather than expecting people to do it for me But I'll post anyway if that's ok if only for my own reference - though any insights by all means.
Can't flash data backup.
Ended up with 13Gb file from mmc copy when system was working so after img2img didn't seem to be working used ext2simg on it as it was a ext image.
Created a more reasonable sparse 887335016 file.
fastboot wouldn't flash it though complaining that data partition was unknown. Searching seems to suggest that sometimes the bootloader doesn't know about all partitions (though it does about system which was flashed ok).
Tried playing with other recovery environments. Not willing to flash anything at this point so trying flashboot boot <img>. No luck so far - device just stays on bootloader splash screen. Probably not great that this device is a Allwinner A38 to which there doesn't seem to be huge support at the moment.
Even tried flashboot boot <recovery partition dump> file I made and that doesn't work.
Trimmed the first 0x800 so image starts with kernel code without joy.
A binwalk of the initrd image inside the dump shows a init.recovery.sun8i.rc file, and a default.prop with
ro.secure=1
ro.allow.mock.location=0
ro.debuggable=0
in init
# Always start adbd on userdebug and eng builds
on property:ro.debuggable=1
write /sys/class/android_usb/android0/enable 1
start adbd
So assuming default.prop is used (I'm still learning) then that's why I can't adb when in recovery mode. Seems stupid to design it that way.
I'm thinking if I can restore data partition it will fix the can't install apps problem, though perhaps the /system part is fundamentally busted. If I can reinstall KingRoot and root again I assume the device will be usable as it would effectively undo my supersume attempt to remove it.
Env partition dump I made used by the bootloader there is
Code:
boot_normal=sunxi_flash read 40007800 boot;boota 40007800 boot
boot_recovery=sunxi_flash read 40007800 recovery;boota 40007800 recovery
Usage:
sunxi_flash read command parmeters :
parmeters 0 : addr to load(hex only)
parmeters 1 : the name of the part to be load
[parmeters 2] : the number of bytes to be load(hex only)
if [parmeters 2] not exist, the number of bytes to be load is the size of the part indecated on partemeter 1
Click to expand...
Click to collapse
So maybe I need to specify the correct memory location when I'm fastboot boot'ing
There's no image type header specifing load address at the start of the recovery part dump I made.
Didn't manage to boot the recovery image - don't know why but a challenge for another day. Would probably be easier with UART access or similar to see what is actually happening.
In the end I mounted my /system backup on my linux server, cleaned it of KingRoot crap, and flashed it. Now everything is fine! Except no root access and the script I added to give me it comes us as unlabeled in selinux and isn't accessible.
The learning journey continues
og0 said:
Didn't manage to boot the recovery image - don't know why but a challenge for another day. Would probably be easier with UART access or similar to see what is actually happening.
In the end I mounted my /system backup on my linux server, cleaned it of KingRoot crap, and flashed it. Now everything is fine! Except no root access and the script I added to give me it comes us as unlabeled in selinux and isn't accessible.
The learning journey continues
Click to expand...
Click to collapse
I know this is a 2 year old thread... but does the OP still have that firmware that fixed the tab??
I have a Fusion5_108 with the A83T allwinner processor, stuck in a boot loop, wont get past the 'no command' screen when trying to recover,
think my only option is to make an sd card with a working firmware on it, and load it onto the devise like that, but i cant find a firmware or anything for this tablet
Ok, I get that boot-debug has been around for years... since android 10 for me, before that, it was variant=user, or variant=eng(ineer).
Strange how after I show boot-debug.img, magisk chooses this very path, but only after. Keeping in mind many people come here asking questions, and all those that know sit back and say nothing. Until they dont like what they see.
If you know better, and cant help, please keep your comments to yourself. This thread is intended to HELP, and is targetted toward those who CHOOSE to HELP because they CAN.
How I got su to work. Is this root? Now this is a good question. I dont want ANY overlaid system in my fone. I want to write to system like many others want to.
Not some google way of forcing us to use their mirrored online version of a locked filesystem already on my f'n.
Priority 1: I want to root my f'n without internet. Period. I do NOT want magisk using my credit. This proves we pay for magisk. I sometimes live so far from the world wide web, that offline is the only way to work. So I need to be able to root without google or THEIR employees offerings.
Priority 2: RW-able system.
So, I discover boot-debug.img for my f'n. Had it for a year, before I discovered it. Yeah, I discovered it after a year here asking, and getting NO replies that worked. Only after I'm vindicated to the naysayers 'thats been around forever...' yeah, try helping instead of useless comments.
In the end, I learned so much in such a short time. Constructive critiscism is NOT insulting. Magisk kills root in MY f'n. PERIOD. Camera does not work, location does not work, and I cant make/receive calls. But hey, it's an overlaid file system, of course it wont ALL work, I mean, I'd expect to lose a lil functionality, but disabling the GSI ability in dev options? I dont think so.. Worse, lack of adb or fastboot is produced in my f'n when using magisk, so tata magisk.
My logs actually explain all, so no more crappy adb logs. Yeah, I like simple adb, it works, or I'll MAKE it work.
Like this:
Attempt every possible method of flashing magisk according to tut's, nada. 3 different paths lead me to...?
1: The note9 recovery I found, that lopstom was kind enough to twrp for me (well appreciated) is the KEY to gaining root on my ulefone armor x5 mt6765. It turns out that the note9 recovery is actually an android 9 os, with a 'super' .img - and being android 9, the bootloader I used is an OLD bootloader, in particular, the variant=eng type. Note this, this is key.
2: With the note9 flashed to recovery I can RW system in android 10 properly, but only in twrp.
3: Discover boot-debug.img - yup, it's not quite a variant=eng build, but it does work for the following:
Flash boot-debug.img. By doing so, you get the adb root command, and the disable-verity options, way better than wiping vbmeta, which contains the 'is it rw, or ro' of every file in every partition to be mounted in their own partitions, but what most dont know, is each file mounted in it's own mountpoint also has the information contained by vbmeta, but for each seperate file. So unless you add the /null (one for system, the other for vendor) after the disable-verity...
Nah, wipe most of your directory structure, then wonder why in a RW-able system, it still dont work. Because each file in it's own mountpoint knows if the system directory SHOULD be ro or rw. That's EACH and EVERY stock file in it's OWN mountpoint, has the RW or RO inf for the system & vendor directory, ie, is system RW?
Example: Camera wont work, get it?
In the end, this is how I went about installing su.
Flashed boot-debug.img did NOT flash recovery. Flashed meefik busybox-arm64 to f'n, but did NOT install it, instead, I opened it to install it, top left, saved the busybox-arm64 and then flashed twrp, and while there, flashed the system_rw, to defeat the system_RW saying not enough space, I chose 1024, did the copy over of super_fixed, then rebooted, enabled system, THEN flashed the busybox-arm64 from twrp, and rebooted.
Results: I copied the busybox-arm64 su, from xbin to system. In order to defeat the system_RW saying not enough space, I chose 1024. Round numbers matter with system_RW, same senario as memory, so use sizes equal to how memory works. ie, 32, 64, 128, and multiples of.
Look at the adb posts in my closed thread.
With Su installed, I have to type exit TWICE to exit. without su in system, exit only needs typed once.
Now here is why I continue. I found root, but dont have the experience, but it's like this:
See all those lovely new file that end in .cel? Mine says platinum. That means I AM ROOT. By swapping out .cel files, I have all the access magisk denies me. .cel files... get on it devs... swap them out, try try try... find what I found.
I dont actually need su, but i need it for some apps. What I have proven, is that SU does NOT kill android 10_Q.
variant=user or variant=eng, is NOW dependant on .cel files, like, say, boot-debug.cel.
Have a nice discovery... I hacked googles latest offering my-cel-f
Edit: Cel files are found in the bootloader, a zero byte file, the file NAME decides what the loader can or cant do, PERIOD.
New root tools only require swapping these out, as well as a few system edits when done.
Ok, slight mistake in spelling so I'll add the following for you to 'see'..
userdebug_plat_sepolicy.cil
So it's not cel as I wrote in the first post, my point being just as valid.
Platinum clearly states there are more who's names I have yet to obtain...
Theoretically in my mind, if I swap the .cil file in the bootloader for say hypothetically:
engdebug_plat_sepolicy.cil... with the few edits seen in the android 10 notes I posted from china, the one where people say 'too much hassle' - I say, for them. Those notes show the rest of the cil files, so yeah, I got root OPTIONS to play with
Stay tuned for more scottish inventor style NOTES.
Edit: for the record: https://source.android.com/compatibility/vts/vts-on-gsi