[TOOL][HOW-TO] [N7] [grouper+tilapia] BootUnlocker Script [Flashable Zip]
BootUnlocker Script for Nexus 7 (2012) -- Unlock your bootloader without fastboot.
Important Information
Those of you with any of the other recent flagship Nexus devices (Galaxy Nexus onward) may already be familiar with the brilliant work of segv11 in creating the BootUnlocker for Nexus Devices app. His app uses root to flip a byte on a device partition, allowing you to relock your bootloader for security and unlock it again any time you wish without the data loss that would come from unlocking via fastboot. I have also followed segv11's method and created a recovery flashable zip for the same devices available from my Odds & Ends thread.
Through the work of myself and several others in the GN BootUnlocker App thread it has been found that the data which controls the lockstate for the N7 '12 is stored in the mmcblk0boot0 partition. Unfortunately we also found this data cannot be simply altered to change the lockstate of the N7 '12 (like it can with the other Nexus devices) due to encryption on a per-device basis. The encrypted data also changes with each new version of the bootloader. The complicated nature of the key means that it's unlikely that the encryption could ever be cracked.
There is, however, still a working solution. Even though your mmcblk0boot0 partition is uniquely encrypted for your device, I found it also changes exactly the same way each time you lock or unlock your bootloader. This means if you back up your mmcblk0boot0 partition when your device is both unlocked and locked, you can simply flash these partition dumps whole to change the lockstate, with no data loss. That's where my script comes in.
In this How-To we are going to make dumps of your mmcblk0boot0 partition in both lockstates, then alter my included zip and updater-script using the dumps so that you have a fully functioning BootUnlocker Script recovery flashable zip tailored to your specific device. When flashed, this zip will lock or unlock your device (depending on what state it's currently in), whenever you want with no data loss.
Requirements
Nexus 7 (2012) grouper/WiFi or tilapia/GSM-HSPA+ (both use the exact same bootloader).
An UNLOCKED bootloader (if locked you'll need to fastboot oem unlock first which WILL factory reset your device).
Bootloader version 4.23 (if newer, then you'll also need to follow the steps to update the bootloader check, found in the 3rd post).
Custom recovery (CWM or TWRP) flashed to your device.
adb+fastboot binaries/executables, either from the Android SDK or you can get them standalone from here.
Universal Naked Driver for Android devices recommended installed for both adb+fastboot on Windows machines.
Notepad2, Notepad++, or another text editor capable of keeping the LF (linefeed) format required for Linux/Unix files like the updater-script.
Disclaimers / Warnings (READ)
I am in no way responsible for you somehow messing up these reasonably simple steps and damaging your device. DO NOT attempt this if you do not accept this risk. If you met the above requirements (in particular the unlocked bootloader), then the following instructions will not result in any data being lost in this process. DO NOT post your zips to this thread once you've followed the directions since the zips will not work on other peoples' devices and if another user somehow flashes your dumps by mistake, could damage their device. Each device must have its own specific BootUnlocker Script zip made using the unique dumps that belong to it.
It is critical that you have read all of the above before you move on.
Building Instructions
Instructions
Step 1 - Getting the dumps and their sha1sums:
Start by downloading the zip attached to this post to your PC. Save it for later.
Boot into your custom recovery on your device with it connected, open a command prompt on your PC where you have adb+fastboot.
Ensure the device is recognized by typing "adb devices".
Type "adb shell" in and then do the following, being sure to copy+paste the sha1sum for unlocked to Notepad for later.
Code:
dd if=/dev/block/mmcblk0boot0 of=/tmp/unlocked-mmcblk0boot0.img
sha1sum /tmp/unlocked-mmcblk0boot0.img
exit
adb pull /tmp/unlocked-mmcblk0boot0.img unlocked-mmcblk0boot0.img
adb reboot-bootloader
fastboot devices
fastboot oem lock
Boot to Recovery using the Bootloader menu then "adb shell" in and do the following, again copy+paste the sha1sum for later, this time for locked.
Code:
dd if=/dev/block/mmcblk0boot0 of=/tmp/locked-mmcblk0boot0.img
sha1sum /tmp/locked-mmcblk0boot0.img
exit
adb pull /tmp/locked-mmcblk0boot0.img locked-mmcblk0boot0.img
It's important that the dumps are named correctly according to the lockstate for the script, and equally important you have kept those sha1sums straight and you know which corresponds to unlocked and which is for locked.
Step 2 - Editing the updater-script:
Extract the updater-script (in /META-INF/com/google/android/) from the zip.
It appears as follows, and is written with safety checks for bootloader version and current lockstate to prevent flashing on the incorrect version or device, respectively. It is currently written for v4.23 ONLY of the bootloader. If you update the bootloader or have a newer version you must update all of these checks (instructions in next post).
Code:
ui_print("");
ui_print("Nexus 7 BootUnlocker Script");
ui_print("by osm0sis @ xda-developers");
ui_print("");
ui_print("For N7 bootloader 4.23 ONLY");
ui_print("and the device belonging to <yourname> ONLY");
show_progress(1.34, 0);
ui_print("");
ui_print("Verifying device...");
mount("ext4", "EMMC", "/dev/block/platform/sdhci-tegra.3/by-name/APP", "/system");
ui_print(getprop("ro.product.device"));
assert(getprop("ro.product.device") == "<devicename>" ||
getprop("ro.build.product") == "<devicename>");
set_progress(0.2);
ui_print("");
ui_print("Verifying bootloader version...");
ui_print(getprop("ro.bootloader"));
assert(apply_patch_check("EMMC:/dev/block/platform/sdhci-tegra.3/by-name/USP:10485760:8c206a1a87599f532ce68675536f0b1546900d7a"),
getprop("ro.bootloader") == "4.23" ||
getprop("ro.boot.bootloader") == "4.23");
set_progress(0.5);
ui_print("");
ui_print("Checking bootloader status...");
run_program("/sbin/busybox", "dd", "if=/dev/block/mmcblk0boot0", "of=/tmp/current-mmcblk0boot0.img");
ifelse(sha1_check(read_file("/tmp/current-mmcblk0boot0.img")) == "<locked sha1sum>",
(ui_print("Bootloader is locked.");
ui_print("");
ui_print("Unlocking...");
package_extract_file("unlocked-mmcblk0boot0.img", "/tmp/mmcblk0boot0.img");
),
(ifelse(sha1_check(read_file("/tmp/current-mmcblk0boot0.img")) == "<unlocked sha1sum>",
(ui_print("Bootloader is unlocked.");
ui_print("");
ui_print("Locking...");
package_extract_file("locked-mmcblk0boot0.img", "/tmp/mmcblk0boot0.img");
),
(ui_print("Status does not match known values.");
ui_print("This is not the intended specific device.");
ui_print("");
ui_print("Your system has not been changed.");
ui_print("");
ui_print("Script will now exit...");
ui_print("");
delete("/tmp/current-mmcblk0boot0.img");
unmount("/system");
abort();
)
);
)
);
set_progress(0.9);
assert(run_program("/sbin/sh", "-c", "echo 0 > /sys/block/mmcblk0boot0/force_ro"),
run_program("/sbin/busybox", "dd", "if=/tmp/mmcblk0boot0.img", "of=/dev/block/mmcblk0boot0"),
run_program("/sbin/sh", "-c", "echo 1 > /sys/block/mmcblk0boot0/force_ro"),
delete("/tmp/current-mmcblk0boot0.img", "/tmp/mmcblk0boot0.img"));
set_progress(1.2);
unmount("/system");
ui_print("Done!");
set_progress(1.34);
Open Notepad 2/Notepad++ and ensure it is set so that it won't break the LF (Unix) formatting when it saves, then open the extracted updater-script.
Make sure the device check on lines 14+15 matches your device. ie. If you are running a tilapia then you should change them (quotes intact) to "tilapia", likewise for "grouper".
Replace <yourname> on line 7 with your username. eg. the device belonging to osm0sis ONLY
Replace <unlocked sha1sum> on line 35 with the sha1sum for the unlocked dump you saved from Step 1.
Replace <locked sha1sum> on line 29 with the sha1sum for the locked dump you also saved from Step 1.
The sha1sum replacements are the most important. They MUST match the dumps correctly. Also make sure you leave the quotes in the script surrounding the sha1sums intact, eg. "0000000000000000000000000000000000000000"
Save and exit Notepad.
Step 3 - Putting it all together:
Add both .img files to the zip. They should be in the root (top level) of the zip. Make sure they are located correctly.
Overwrite the updater-script in /META-INF/com/google/android/ of the zip with your new edited version. Double check that it has replaced the old one and has been added correctly.
Save and exit the zip.
It is now recommended you name the zip according to the following scheme: cwm-N7.<device>.BootUnlocker.v<bootloaderversion>-<username> to differentiate device, bootloader version and user. Mine is cwm-N7.grouper.BootUnlocker.v4.23-osm0sis.zip. This should help prevent confusion.
Done! You now have a BootUnlocker zip for your N7 '12 until the bootloader gets updated.
Flash it to unlock your device again. Flash it again to lock it.
Previous version download count: 131
Update Instructions
Updating When A New Bootloader Is Released
Once built for your device, the above script will work as long as the bootloader remains at v4.23 (as per the naming). The way I've scripted it, for safety it shouldn't work on any other bootloader version or on anyone else's device, but I'd still advise against trying. Since the encrypted data also changes based on the version of the bootloader, if/when you update the bootloader you MUST also get NEW dumps of the mmcblk0boot0 partition both unlocked and locked.
BEFORE you update your bootloader, if your device is locked, start by using the BootUnlocker Script zip you previously created to unlock.
Update your bootloader to the new version (usually done via OTA or fastboot flash of a Factory Image).
Follow the steps in the 2nd post again to update your zip, replacing the .img files with the new dumps, and altering the update-script with the new corresponding sha1sums.
Change the version number in the updater-script warning on line 6 and the version number check on lines 22+23 to that of the new bootloader, and be sure you have renamed the zip with the new version number as well to keep things straight.
"adb shell" in while booted to custom recovery and run the following, copy+paste the bytesize and sha1sum for the next step.
Code:
dd if=/dev/block/platform/sdhci-tegra.3/by-name/USP of=/tmp/USP.img
sha1sum /tmp/USP.img
rm /tmp/USP.img
Enter the new bootloader's bytesize and sha1sum into the bootloader version check on line 21, in the following format USP:<bytesize>:<bootloader sha1sum>, eg. for v4.23 it is
Code:
USP:10485760:8c206a1a87599f532ce68675536f0b1546900d7a
Enjoy!
Questions, comments and feedback welcome.
Thanks to segv11 and efrant for all the fun in the GN BootUnlocker App thread, scary alien for the help with the bootloader check assert syntax in his OTA Verifier App thread, and thanks to trevd for the update-binary info/help in the GN EDIFY Scripting thread. Also a special thank you to Mach3.2, scary alien, partha and drose6102 for submitting dumps so all this could be figured out, and for basically being the Beta/RC testers for this script. Cheers!
You finally got it working! I ought to try this, of course after wrestling with the grizzly dad of mine. Awesome job there Chris!
Sent from my Galaxy Nexus using Tapatalk 2
Haha yup. I've had it working for awhile now, it was just a matter of writing up this monster guide. Thanks Fitz. Good luck with that wrestling.
Very cool, and very nice work.
osm0sis said:
Since the encryption also changes based on the version of the bootloader
Click to expand...
Click to collapse
The encryption does not change, that is static for the life of the device, what changes is the data stored. Also boot0/1 are technically not partitions and are more analogous to mmcblk0 than mmcblk0px there are 3 partitions that start within this range, BCT, PT and the start of the bootloader. BCT takes up the entire boot0 and part of boot1.
The reason you cannot just flash back your backup copy is a hash of the bootloader is stored in the bct for verification and integrity checking purposes[1]. This changes the end result because all SBK encrypted data is done in AES-128-CBC meaning the previous blocks cipher text is the next blocks IV.
Because of this you should also be careful of any number of other conditions that cause writing to the BCT as they have the potential to cause the decryption to fail on the rest of the BCT which is in mmcblk0boot1. While this may not (and at this point should not) cause bricking, changes made by google in the future may alter this outcome.
[1] The hash stored in BCT not matching the bootloader hash causes the device to fall back into APX mode.
lilstevie said:
The encryption does not change, that is static for the life of the device, what changes is the data stored. Also boot0/1 are technically not partitions and are more analogous to mmcblk0 than mmcblk0px there are 3 partitions that start within this range, BCT, PT and the start of the bootloader. BCT takes up the entire boot0 and part of boot1.
The reason you cannot just flash back your backup copy is a hash of the bootloader is stored in the bct for verification and integrity checking purposes[1]. This changes the end result because all SBK encrypted data is done in AES-128-CBC meaning the previous blocks cipher text is the next blocks IV.
Because of this you should also be careful of any number of other conditions that cause writing to the BCT as they have the potential to cause the decryption to fail on the rest of the BCT which is in mmcblk0boot1. While this may not (and at this point should not) cause bricking, changes made by google in the future may alter this outcome.
[1] The hash stored in BCT not matching the bootloader hash causes the device to fall back into APX mode.
Click to expand...
Click to collapse
Hey great to finally get some more information about the encryption used and the contents of boot0-1. Very interesting stuff. How did you determine this? We couldn't find much documentation on the matter. Any ideas on how to decrypt it would also be greatly appreciated, since that might allow segv11 to still be able to include it in the BootUnlocker app.
So far the only time we've seen the md5hash of the boot0 block change on a particular device is with a bootloader version change, after which it continues to remain consistent depending on lockstate. I was merely guessing that was part of the encryption process but the data changing would of course also make perfect sense, so thank you for that information. What doesn't change when unlocking/locking the bootloader is boot1, so flipping between the two states for boot0 will still keep decryption of boot1 intact.
I definitely understand your concerns that it is a dangerous business writing to these blocks, and I agree, but as you've seen I haven't taken this lightly in either my posts or my script; the script has safeties built in to make sure it only writes to boot0 when it meets one of the two known states for that person's device (locked or unlocked). If somehow the boot0 did change randomly in the future without a bootloader update then the script wouldn't run, it would abort, questioning whether this was the intended device or not since it couldn't determine the lockstate from the stored sha1sums. :good:
osm0sis said:
Hey great to finally get some more information about the encryption used and the content of boot0-1. Very interesting stuff. How did you determine this? We couldn't find much documentation on the matter. Any ideas on how to decrypt it would also be greatly appreciated, since that might allow segv11 to still be able to include it in the BootUnlocker app.
So far the only time we've seen the md5hash of the boot0 block change on a particular device is with bootloader version change, after which it continues to remains consistent depending on lockstate. I was merely guessing that was part of the encryption process but the data changing would of course also make perfect sense, so thank you for that information. What doesn't change when unlocking/locking the bootloader is boot1, so flipping between the two states for boot0 will still keep decryption of boot1 intact.
I definitely understand your concerns that it is a dangerous business writing to these blocks, and I agree, but as you've seen I haven't taken this lightly in either my posts or my script; the script has safeties built in to make sure it only writes to boot0 when it meets one of the two known states for that person's device (locked or unlocked). If somehow the boot0 did change randomly in the future without a bootloader update then the script wouldn't run, it would abort, questioning whether this was the intended device or not since it couldn't determine the lockstate from the stored md5hashes. :good:
Click to expand...
Click to collapse
it is off the shelf tegra security. As I said at this time changes shouldn't echo all the way through, but the BCT partition is usually ~3MB but only uses a fraction of that.
Decryption and Encryption of the data is not something easily available, it entirely defeats the purpose of it if you can do it yourself.
lilstevie said:
it is off the shelf tegra security. As I said at this time changes shouldn't echo all the way through, but the BCT partition is usually ~3MB but only uses a fraction of that.
Decryption and Encryption of the data is not something easily available, it entirely defeats the purpose of it if you can do it yourself.
Click to expand...
Click to collapse
Haha yeah of course it defeats the purpose, but in a way so does unlocking the bootloader with root.
Either way, thanks for the help and your Tegra knowledge.
Works perfect
Thanks a ton osm0sis. Just tested and it's flawless. Finally got rid of that unsightly unlock icon when you first boot and I still have full functionality. Locks and unlocks in an instant with the edited .zip file. Great work! :highfive:
lilstevie said:
The encryption does not change, that is static for the life of the device,
Click to expand...
Click to collapse
I am very interested in unlocking the bootloader without rooting or fastboot oem unlock my device. I'd love to find that key and be able to write an encrypted bootloader via JTAG access for example (I guess can't do otherwise to write an encrypted image as the encryption is probably done by the bootloader while uploading an image through fastboot am I right?)
I foresee 2 possibilities, but might be very wrong: 1) key hardcoded (in the BIOS for ex), I am trying to see if I can JTAG access the processor next week (theoretically frist, as my N7 arrives after 2 weeks)
2) the key is computed based on the device serial number (which I think might very well be the case) at startup (I'd guess a logical operation like an XOR on the serial maybe with a master key hardcoded or just a crypto op on the serial) in this case it might not be required to search for it in a memory dump but aska crypto guy see if with the knowledge of cyphered data, the algorithm and the serial, a key could be diversified...
If some of you guys are interested to work on that...we could open a new thread?
Meanwhile any of you know where I can get more info on the memory map of the flash?
My guess was that it was device serial number based as well. If you want to work on decrypting it, you could probably take it back to the main BootUnlocker App Dev thread: http://forum.xda-developers.com/showthread.php?t=1731993, since if you ever got it working it could likely be included in the app again.
No idea on the memory map unfortunately.
Just a reminder to everyone to unlock before you flash the OTA. Instructions for updating the script for new bootloader versions are in the 3rd post of this thread.
Happy OTA Day!
What is strange USP.img sha1 did not change. It still is 8c206a1a87599f532ce68675536f0b1546900d7a
???
---------- Post added at 06:07 PM ---------- Previous post was at 05:58 PM ----------
Anyway....working ok with 4.2.2 after updating with post 2 instructions.
sebarkh said:
What is strange USP.img sha1 did not change. It still is 8c206a1a87599f532ce68675536f0b1546900d7a
???
---------- Post added at 06:07 PM ---------- Previous post was at 05:58 PM ----------
Anyway....working ok with 4.2.2 after updating with post 2 instructions.
Click to expand...
Click to collapse
You're right, interesting! My guess, based on what lilstevie said, is that when the OTA writes the new bootloader to /USP it actually writes it to multiple contiguous partitions starting with USP, including the mmcblk0boot ones we dump. So whatever changed in the bootloader didn't alter the actual USP part this time, and that's why it checksums the same. The mmcblk0boot blocks do change, so the method in post 3 should still be followed.
Just updated to 4.18 and followed the instructions (minus the USP section in post 3) and all is working as expected. Thanks again!
Just noticed that having the mount /system in an assert will actually fail the assert if the system is already mounted. Not really a big deal, just means /system can't already be mounted when you go to run the BootUnlocker script or it won't make it past the device check. I haven't decided whether it matters enough to upload a new version of the script zip or not, since it's easy enough to go unmount /system before running it.
Also easy enough to fix it yourselves if you like:
Code:
assert(mount("ext4", "EMMC", "/dev/block/platform/sdhci-tegra.3/by-name/APP", "/system"),
getprop("ro.product.device") == "grouper" ||
getprop("ro.build.product") == "grouper");
should instead be:
Code:
mount("ext4", "EMMC", "/dev/block/platform/sdhci-tegra.3/by-name/APP", "/system");
assert(getprop("ro.product.device") == "grouper" ||
getprop("ro.build.product") == "grouper");
Anyway, thought I'd give everyone the heads up even though nobody's apparently run into it or brought it to my attention before. :good:
Thanks for your tips! As I prefer to use the stock recovery I made a script to use your solution from the device itself, placing the partition backups in /system/usr/bootunlock. Here it is in case anyone else finds it useful:
Code:
#!/system/bin/sh
case $1 in
"lock")
echo "[x] Locking bootloader..."
echo 0 > /sys/block/mmcblk0boot0/force_ro
dd if=/system/usr/bootunlock/locked-mmcblk0boot0.img of=/dev/block/mmcblk0boot0
echo 1 > /sys/block/mmcblk0boot0/force_ro
echo "[x] Bootloader locked!"
;;
"unlock")
echo "[x] Unlocking bootloader..."
echo 0 > /sys/block/mmcblk0boot0/force_ro
dd if=/system/usr/bootunlock/unlocked-mmcblk0boot0.img of=/dev/block/mmcblk0boot0
echo 1 > /sys/block/mmcblk0boot0/force_ro
echo "[x] Bootloader unlocked!"
;;
*)
echo "Usage: $0 <lock|unlock>"
exit 1
;;
esac
Does it still work on the latest bootloader of Androud 4.3?
I just need to change the value in script and replace img files?
Thanks.
Related
When scripting a ROM is there a way to verify the a certain version of recovery is installed before flashing?
Thanks!
Hmm, that is a good question. I don't think it can and even if it could, with the limitations in the edify scripting, it would be very hard to. For example, on the EVO 4G, I wanted to make it check what device you were running and what kernel you were using but it was such a PITA to even attempt that I just gave up. What made it even harder was that recovery uses it's own kernel, so trying to find out info from the kernel you were running was impossible.
That would be cool, some form of a incompatibility check.
Does getprop return anything while in recovery?
Must be possibly if ROM Manager can do it.
Edit: NM, sorry, I didn't properly read the OP.
Sent from my PG86100 using XDA Premium App
myn said:
Does getprop return anything while in recovery?
Click to expand...
Click to collapse
Not sure?
-viperboy- said:
Hmm, that is a good question. I don't think it can and even if it could, with the limitations in the edify scripting, it would be very hard to. For example, on the EVO 4G, I wanted to make it check what device you were running and what kernel you were using but it was such a PITA to even attempt that I just gave up. What made it even harder was that recovery uses it's own kernel, so trying to find out info from the kernel you were running was impossible.
Click to expand...
Click to collapse
Thats sorta what I am trying to do! At least I am not alone in this quest.
scrosler said:
When scripting a ROM is there a way to verify the a certain version of recovery is installed before flashing?
Thanks!
Click to expand...
Click to collapse
i don't think there is a definite guaranteed method .. although maybe somebody will prove me wrong as i might be thinking through it too much.
i dont have adb access to verify anything yet, but here is my line of thought.
the recovery binary, generally stored in /sbin/recovery won't really have a stamped version number on it, although you might be able to strings the binary for a version number, which could be executed by a .sh script called by the updater-script and if the script fails, you can stop the update and print an error message.
another thought, the kernel the recovery binary is housed in that is flashed/stored on the recovery partition won't really give much indication as the kernel will probably always be the same kernel version (2.6.35 or whatever is easiest to build for device support), but its compile number might increase, assuming they didn't just merge a new /sbin/recovery binary into the ramdisk and merge with an existing zImage (which could happen).
I've seen manufacturer OTA updater-script files and even cm7 verify device product.model using assert and getprop to confirm the correct .zip is being applied to the correct device before allowing the ROM to be flashed. any official OTA should have this assert getprop command at the top as well as any cm7 .zip.
unfortunately none of those methods or approaches will tell you which version of recovery is being used as twrp, amon and koush all use arbitrary (only really internally significant) version numbers for their recoveries.
on a more positive note, it is possible to test for some types of support in a recovery before allowing an updater-script .zip file to be loaded.
in an effort to better understand and perhaps take an alternate route to provide a solution, what are you trying to accomplish, i.e. what type of support are you requiring from the recovery?
myn said:
Does getprop return anything while in recovery?
Click to expand...
Click to collapse
it should but i can't prove it w/o adb access. i'm pretty positive manf OTA .zip files and cm7 .zip use assert(getprop(ro.product.model="supersonic")) etc to check before they allow the .zip to load .. but i'm thinking ro.product.model should be pulled from /system/build.prop which might/might not be mounted in recovery mode when the .zip is being loaded or stored else where when the updater-script is being executed?
should be easy enough to test with adb access to recovery ....
EDIT: adb access now:
cwm recovery on evo 3d, getprop is not setup in the shell and does not work.
taken from the NS4G OTA released a week or so ago:
assert(file_getprop("/system/build.prop", "ro.build.fingerprint") == "google/sojus/crespo4g:2.3.4/GRJ22/121341:user/release-keys" ||
file_getprop("/system/build.prop", "ro.build.fingerprint") == "google/sojus/crespo4g:2.3.5/GRJ90/138666:user/release-keys");
assert(getprop("ro.product.device") == "crespo4g" ||
getprop("ro.build.product") == "crespo4g");
if the call to file_getprop mounts /system, then the second call to getprop should read from the same /system/build.prop. otherwise the stock recovery would have to support the getprop command, which i doubt as the first command differs from the 2nd.
hope that makes sense. looks like assert(file_getprop( is your best bet .. and that doesn't verify recovery version. if you can provide more information around what you're wanting to do, perhaps there is another way to approach.
hope that helps!
Interesting...
How about just asking if that is possible in scripting. If twrp then else...., just an idea or if recovery is at a fixed location...read binary to see a signature? Check the md5 and see what it belongs to? You bad boy is my daily driver!
life64x said:
How about just asking if that is possible in scripting. If twrp then else...., just an idea or if recovery is at a fixed location...read binary to see a signature? Check the md5 and see what it belongs to? You bad boy is my daily driver!
Click to expand...
Click to collapse
I don't know if you've ever looked at an updater-script but it's not like standard scripting. I guess you might be able to extract a shell script and run it to check for some identifying information in recovery and have it report back the results in a ui_print but it would be a pain in the balls IF you could get it to work.
-viperboy- said:
extract a shell script and run it to check for some identifying information in recovery and have it report back the results in a ui_print but it would be a pain in the balls IF you could get it to work.
Click to expand...
Click to collapse
the part that would be a pain, as viperboy eludes to, is creating an index of the recovery versions, example:
md5sum: 029jlaksdfl232l34jklas = twrp recovery 1.0.0
md5sum: 0djlsdkj23lkj423lkjasdfl = twrp recovery 1.0.1
md5sum: lksd0923jlszdf092034 = twrp recovery 1.0.2
and doing that for each version of the recovery being released in addition to also indexing cwm recovery. sure, its doable ... is it practical?
the list would need to be updated with each new version of a recovery that is released, otherwise an installing ROM wouldn't know which version a new recovery was.
the OP never answered my inquiry as to what exactly he is looking for in the recovery, a specific feature or function? without knowing the full story, its hard to say this is the best approach.
Never did look up updating script. Just trying to give ideas out of the box. It seems limiting.
life64x said:
Never did look up updating script. Just trying to give ideas out of the box. It seems limiting.
Click to expand...
Click to collapse
in my opinion, i'm not sure its a limitation of edify (updater-script) or a limitation of bash/sh/shell scripting (which edify can leverage) but more of a limitation in how custom recovery's are designed and versioned. provided android wasn't really designed to have many different versions of custom recovery's on one device, there aren't really any APIs setup for version control in the recovery .. in fact very little is supported in recovery as its just that ... a temporary recovery mode.
the method i mention above, hash'n out each version and storing in a table/index, would be one approach to implementing a type of version control w/o the custom recovery developer's changing their approach.
imo, the ideal approach would be for the custom recovery developers to implement a type of version control all custom recovery's follow, but since its not really *needed* or popularily demanded, i dont think that concept has a very high likihood of that occuring in the near future.
edify (updater-script) and bash scripting are both pretty decent languages and i think bring a very good set of features and abilities to the table, given the scope android originally designed the recovery mode for.
if for whatever reason you want recovery to support other languages or more features, i know twrp has a github where they track issues, put in a request or fork, code and send a pull request to their git. likewise i'm sure koush is open also.
the skys the limit!
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.
Hi All,
This is the .zip to grant temporary root to your device. Currently this is only tested on the BrightStart device. You can see the software number in the file name.
The boot.img is located inside.
Steps:
1. Unlock bootloader via htcdev.com (I was able to do it when originally testing; however, I've heard other people have had issues.
2. Download file below.
3. Boot into fastboot
4.
Code:
fastboot oem rebootRUU
5.
Code:
fastboot flash zip A3_root_boot.zip reboot
Your device should now have temporary root. This temporary root is a little different than most. You can perform
Code:
adb remount
to access the system folders without superSU; however, none will stick after reboot due to the write protection.
NOTE
This is more of a starter for other developers to begin work, but please Thank Me and reference here if you utilize this at all.
Also, the process was a little easier for me since I was working with HTC and eventually was using s-off devices.
Beautiful, thank you!
Edit: with that, I wonder if this module could enable permanent root for us by disabling write protection? It says it can be hex edited to change to our kernel version and might work:
http://forum.xda-developers.com/showthread.php?t=2230341
Edit 2: if we can remount, we should be able to take a full image backup of the phone as well I believe... Maybe we can do that, then push the full root boot image with the module above back to the device. After the module is hex edited to work with our kernel version of course, which is currently 3.4.0-gb799e00
ClearD said:
Beautiful, thank you!
Edit: with that, I wonder if this module could enable permanent root for us by disabling write protection? It says it can be hex edited to change to our kernel version and might work:
http://forum.xda-developers.com/showthread.php?t=2230341
Edit 2: if we can remount, we should be able to take a full image backup of the phone as well I believe... Maybe we can do that, then push the full root boot image with the module above back to the device. After the module is hex edited to work with our kernel version of course, which is currently 3.4.0-gb799e00
Click to expand...
Click to collapse
That logic is sound; however slight differences in the model maybe.
Currently in the M8 this file is located in block/blk-core.c, which has the following.
Code:
#ifdef CONFIG_MMC_MUST_PREVENT_WP_VIOLATION
sprintf(wp_ptn, "mmcblk0p%d", get_partition_num_by_name("system"));
if (!strcmp(bdevname(bio->bi_bdev, b), wp_ptn) && !board_mfg_mode() &&
(get_tamper_sf() == 1) && (bio->bi_rw & WRITE)) {
pr_info("blk-core: Attempt to write protected partition %s block %Lu \n",
bdevname(bio->bi_bdev, b), (unsigned long long)bio->bi_sector);
err = 0;
goto wp_end_io;
} else if (atomic_read(&emmc_reboot) && (bio->bi_rw & WRITE)) {
pr_info("%s: Attempt to write eMMC, %s block %Lu \n", current->comm,
bdevname(bio->bi_bdev, b), (unsigned long long)bio->bi_sector);
err = -EROFS;
goto wp_end_io;
}
#endif
That line of code will need to be intercepted at boot to allow permanent root.
I haven't checked recently, but is the source for desire 610 posted?
Another dev just said source is released, so couldn't we just remove that and build?
help!
I get the following message when entering "fastboot flash zip A3_root_boot.zip reboot":
"FAILED (remote: 41 model id check fail)"
any ideas
thanks
Yep. Don't use that method and instead read the unlock and root guide. You need to pull the image out of the zip and flash it manually, however this method is outdated and unnecessary.
Maybe you could flash this kernel, since it disable write protection feature.
That won't help him, the issue is that we're not s-off. The security check is what's stopping it from flashing. Manual flashing will work though. Removing it from the zip and flashing the other way as stated in the unlock and root thread. Also, this is deprecated, as it isn't an actual root method either. Only shell root.
Does this method might work on desire 510???
Sent from my HTC Desire 510 using XDA Premium 4 mobile app
Doubtful. It's an entire boot image made for the 610. You may brick your device by flashing it without a full backup.
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?
First time posting and I wanted to say thank you to all the excellent talent here on XDA! None of this would have been done without the work of so many people.
I have a Moto G Play (2021) (XT2093-4) that I recently purchased (Best Buy - $159 US/Carrier Unlocked) and I wanted to document my adventure in to rooting, making '/system' RW, and fixing the missing LED notification light (hint: I used the charging light) (hint^2: It's not required to make '/system' RW in order to fix the LED notification light - I just wanted more control over my phone).
First, "OEM unlocking" was greyed out for me, but became available after several days of having the phone online with a SIM card.
I followed the instructions here to unlock the bootloader and root with Magisk (Non-TWRP). Along with these instructions.
Once bootloader is unlocked, you will need the 'boot.img' file from your stock firmware. I used the "Rescue and Smart Assistant" utility to grab a copy of the stock firmware (GUAMNA_RETAIL_QZAS30.Q4_39_35_9_subsidy_DEFAULT_regulatory_DEFAULT_CFC.xml) and extracted the "boot.img" file for the next steps.
Continue installing Magisk (Filenames may be different! Don't just copy and paste.):
Code:
adb install Magisk-v23.0.apk
adb push boot.img /sdcard/Download
(Follow the instruction on your phone to patch 'boot.img' in Magisk)
adb pull /sdcard/Download/magisk_patched-23000_aKKMt.img
adb reboot bootloader
fastboot flash boot_a magisk_patched-23000_aKKMt.img
fastboot flash boot_b magisk_patched-23000_aKKMt.img
You should now have a working, rooted Moto G Play. You can just stop here and have fun with your phone, but I noticed that even with root, the system partition was not RW.
I followed these instructions to make '/system' writable (Note: you will need the 'sysrw_repair.zip' that's included in the bundle and a Linux system):
Code:
adb push systemrw_1.32_flashable.zip /data/local/tmp/
adb shell
su
cd /data/local/tmp/
unzip systemrw_1.32_flashable.zip
cd systemrw_1.32/
chmod +x systemrw.sh
./systemrw.sh in=`ls -l /dev/block/by-name/super | awk '{print $NF}'` out=/data/local/tmp/systemrw_1.32/img/super_original.bin size=50
The phone doesn't have enough space to complete 'lpmake' on the device and will end with an "Error 73" code. Running the "sysrw_repair_v1.32" tool on a Linux machine was a workaround because it pulls the '*.img" files to your local machine then combines them in to a single '.bin' file. But, before I did that, and because it's really annoying, I made some room to stop the phone from complaining about a lack of space:
(Still on the phone's adb)
Code:
rm ./img/super_original.bin
Now, on the Linux machine, I unzipped 'sysrw_repair_v1.32_proper.zip' then commented out line 39 (where it calls the "flash()" function) of the script (sysrw_repair.sh) because I wanted to flash the "super" partition myself.
(On another Linux terminal)
Code:
cd /path/to/unzipped/sysrw_repair/dir/
chmod +x sysrw_repair.sh
./sysrw_repair.sh
This results in a new folder (img) with a rather large bin file (super_original.bin).
(Back on the phone adb)
Code:
exit # Exit root
exit # Exit adb
adb reboot bootloader
Now it's time to flash the fixed bin file to the "super" partition:
Code:
cd /path/to/unzipped/sysrw_repair/dir/
fastboot flash super ./img/super_original.bin
fastboot reboot
You should be able to login and have a writable '/system':
Code:
adb shell
su
mount -o rw,remount /
No errors should appear.
Last, I like having an LED indicator that tells me that I have an SMS/MMS notification waiting. Motorola thought it would be wise to eliminate that feature altogether instead of having the option to enable it. So, I forced it back on using a startup script that dumps the notifications and greps for some key words. And, if it finds something, it "breaths" the charging LED. The script loops until the notification is gone, then keeps checking for new notifications every 30 seconds. (Note: the "/data/adb/service.d/" directory is used by Magisk like an INIT service):
(Still root on the phones adb)
Code:
cd /data/adb/service.d/
cat <<EOF > ledfix.sh
#!/bin/sh
while true; do
if dumpsys notification | egrep NotificationRecord | egrep sms > /dev/null
then
if [[ $(cat /sys/class/leds/charging/breath) == 0 ]]
then
echo 1 > /sys/class/leds/charging/breath
sleep 2
continue
else
sleep 2
continue
fi
elif egrep 'Charging' /sys/class/power_supply/battery/status > /dev/null
then
if [[ $(cat /sys/class/leds/charging/breath) -ne 0 && $(cat /sys/class/leds/charging/brightness) -ne 0 ]]
then
echo 0 > /sys/class/leds/charging/breath
echo 255 > /sys/class/leds/charging/brightness
elif [[ $(cat /sys/class/leds/charging/breath) == 0 && $(cat /sys/class/leds/charging/brightness) == 0 ]]
then
echo 255 > /sys/class/leds/charging/brightness
else
continue
fi
else
echo 0 > /sys/class/leds/charging/breath
echo 0 > /sys/class/leds/charging/brightness
fi
sleep 30
done
EOF
chown 0.0 ledfix.sh
chmod 0755 ledfix.sh
reboot
Now, the charging light will fade off and on about every 2 seconds if there's an SMS/MMS notification waiting. And will check for notifications every 30 seconds. I'm sure someone can come up with a better way of doing this, but this was a nice quick-and-dirty way to get what I wanted.
Hope this helps!
I created an account to say thank you for this, I have already done a good portion, having unlocked the bootloader, the problem is the Rescue Smart Assistant, it won't let me log in, it keeps telling me it can't connect, and the GUI is different because of an update, there is no download button inside the program, only a greyed out rescue button. How did you manage to make the backup Boot.img? Maybe you are using a different OS, and/or version of the program (Not the app, that is already auto-installed), I'm using Windows 10, are you on Linux? I might just need to try from Linux, maybe in a VM.
I was trying to do this before I found this post, and have already installed ADB, the SDK, fastboot, and Motorola Drivers, I just need a way to get the Boot.img, and to patch it, also figure out how to flash it. The last android I rooted with a custom rom was the HTC EVO 4G with Oreo/Jellybean, so I'm a little rusty, but am able to understand technical jargon.
If anyone could help, that would be awesome. I've reinstalled different versions of Rescue Smart Assistant as well, they always upgrade on boot, same problem. I've added exceptions to my firewall and everything.
UPDATE: Was about to post this when I had updated from android 10 to 11 and decided to try logging in again a little closer to my router, to see if the connection was timing out, I think that was the cause, as I can now sign in, and the GUI seems correct from the first appearance. I don't see why I should have any trouble following the rest of the guide, but feel I should share my trials and frustrations anyways, for anyone else experiencing the same,
Thanks again.
PROFSLM said:
I created an account to say thank you for this, I have already done a good portion, having unlocked the bootloader, the problem is the Rescue Smart Assistant, it won't let me log in, it keeps telling me it can't connect, and the GUI is different because of an update, there is no download button inside the program, only a greyed out rescue button. How did you manage to make the backup Boot.img? Maybe you are using a different OS, and/or version of the program (Not the app, that is already auto-installed), I'm using Windows 10, are you on Linux? I might just need to try from Linux, maybe in a VM.
I was trying to do this before I found this post, and have already installed ADB, the SDK, fastboot, and Motorola Drivers, I just need a way to get the Boot.img, and to patch it, also figure out how to flash it. The last android I rooted with a custom rom was the HTC EVO 4G with Oreo/Jellybean, so I'm a little rusty, but am able to understand technical jargon.
If anyone could help, that would be awesome. I've reinstalled different versions of Rescue Smart Assistant as well, they always upgrade on boot, same problem. I've added exceptions to my firewall and everything.
UPDATE: Was about to post this when I had updated from android 10 to 11 and decided to try logging in again a little closer to my router, to see if the connection was timing out, I think that was the cause, as I can now sign in, and the GUI seems correct from the first appearance. I don't see why I should have any trouble following the rest of the guide, but feel I should share my trials and frustrations anyways, for anyone else experiencing the same,
Thanks again.
Click to expand...
Click to collapse
You can also get the firmware from
Lolinet Mirrors
https://t.me/MotoUpdatesTracker
Search for Firmware by codename, software channel, Software Version, and build #
So I wasn't going crazy when I could swear a LED notification light in the upper right side above the screen blinked once whenever I rebooted the phone?
Why would Motorola include such a thing and not utilize it for more than merely a boot up indicator? Like I dont even get to see it come on while charging, it literally only blinks once during boot and that's it.
mario0318 said:
So I wasn't going crazy when I could swear a LED notification light in the upper right side above the screen blinked once whenever I rebooted the phone?
Why would Motorola include such a thing and not utilize it for more than merely a boot up indicator? Like I dont even get to see it come on while charging, it literally only blinks once during boot and that's it.
Click to expand...
Click to collapse
I know!
I don't know what triggers that light to come on. I even waited until the battery was at 6% and the light still never came on.
So, I updated the script above to make the light go full brightness if the battery is charging. The order matters, so if a notification comes in while charging, it'll "breath" the LED. Also, if the battery is full, then the light will turn off. Kind of telling you that it's time to unplug.
I followed these steps and my touch screen stopped working. I had previously installed twrp already on it while trying to learn how to root it, and when i boot into fastboot it goed through twrp, i also used the boot.img file from lolinet, not sure which of these caused the issue. Interestingly though, the touch screen does work whilst in twrp. any suggestions on how to fix or what would be causing it? Phone does work with usb mouse over OTG
jorduino said:
I followed these steps and my touch screen stopped working. I had previously installed twrp already on it while trying to learn how to root it, and when i boot into fastboot it goed through twrp, i also used the boot.img file from lolinet, not sure which of these caused the issue. Interestingly though, the touch screen does work whilst in twrp. any suggestions on how to fix or what would be causing it? Phone does work with usb mouse over OTG
Click to expand...
Click to collapse
Are you absolutely sure you used the correct boot.img from an image version exactly matching your phone variant version?
mario0318 said:
Are you absolutely sure you used the correct boot.img from an image version exactly matching your phone variant version?
Click to expand...
Click to collapse
Im not completely sure how to get the right file, but I think the first time it was the wrong one, but then when i got what i thought was the right one, it just didn't work at all and I had to recovery flash it. I had just updated so maybe the correct image wasn't available yet. Im going to try again though
Oh! Hello @latentspork. Thanks for your interest in my SystemRW project. I just came across this thread randomly...
I'm happy you got my script to work on your Motorola device by using the included sysrw_repair script
Please feel free to send me your log files from script folder. Thanks. It's useful for further development of the script
latentspork said:
The phone doesn't have enough space to complete 'lpmake' on the device and will end with an "Error 73" code. Running the "sysrw_repair_v1.32" tool on a Linux machine was a workaround because it pulls the '*.img" files to your local machine then combines them in to a single '.bin' file. But, before I did that, and because it's really annoying, I made some room to stop the phone from complaining about a lack of space:
Click to expand...
Click to collapse
That's not 100% accurate. Lpmake error 73 means CAN'T_CREATE and has nothing to do with error 70 (insufficient space).
To this day I still don't know exactly what causes error 73 on some devices (mostly Motorola and others) but it looks like some kind of kernel panic. If anyone knows how to avoid this error 73 in Android please let me know! Thanks!
Yes that's true the included sysrw_repair script (Linux only) pulls the image files from the phone to your computer and attempts to run the same lpmake command with the same arguments that just failed with error 73 on the phone itself and now all of a sudden it just works in Linux. Go figure.
latentspork said:
(Still on the phone's adb)
Code:
rm ./img/super_original.bin
Click to expand...
Click to collapse
Why would you delete the super_original.bin ? That's your stock read-only super image which by default is automatically dumped by script for backup purposes in case you ever get a bootloop.
And if you launch the script by specifying a custom input value (in=x) like in your example above then you won't even have a super_original.bin file to begin with because script will skip the whole dumping of original super image process.
latentspork said:
This results in a new folder (img) with a rather large bin file (super_original.bin).
Click to expand...
Click to collapse
I think you mean super_fixed.bin
latentspork said:
Now it's time to flash the fixed bin file to the "super" partition:
Code:
cd /path/to/unzipped/sysrw_repair/dir/
fastboot flash super ./img/super_original.bin
fastboot reboot
Click to expand...
Click to collapse
Here in your instructions you are manually flashing the wrong file. Shouldn't you be flashing super_fixed.bin to your super partition?
Usually I only flash the super_original.bin to get back out of a bootloop...
latentspork said:
Now, on the Linux machine, I unzipped 'sysrw_repair_v1.32_proper.zip' then commented out line 39 (where it calls the "flash()" function) of the script (sysrw_repair.sh) because I wanted to flash the "super" partition myself.
Click to expand...
Click to collapse
See that's why I included that automatic flash() function in the repair script. Then you don't have to worry about manually flashing the wrong file to your super partition
Enjoy a fully read/write-able device!
Great news! New SystemRW version coming soon!
@lebigmac
I really appreciate the reply and the tool! It did work really well on my model (XT2093-4).
That's not 100% accurate. Lpmake error 73 means CAN'T_CREATE and has nothing to do with error 70 (insufficient space).
To this day I still don't know exactly what causes error 73 on some devices (mostly Motorola and others) but it looks like some kind of kernel panic. If anyone knows how to avoid this error 73 in Android please let me know! Thanks!
Click to expand...
Click to collapse
I only assumed that "Error 73" was caused by insufficient space, because the phone really did run out of space. I noticed that the phone was out of space because I got a home screen notification warning, asking me to free up space. I confirmed it with a "df -h" at the shell. Apparently, the OS takes up almost 15GB. When you add the ".img" files, there's only about 5GB left. There wasn't enough room to complete the ".bin" file. Maybe I could have used an SD card or something.
You're probably correct in that "Error 70" is the correct error for that, but on my phone, I never saw that error. I did notice that the tool was still trying to write data as the phone ran out of space, then it would throw the "Error 73". Maybe it didn't register the lack of space, or just an oddity with my model? No idea.
Why would you delete the super_original.bin ?
Click to expand...
Click to collapse
This is the file that was created when I initially ran the "./systemrw.sh" command on the phone. The result of running the command on the phone were several ".img" files and a very large "super_original.bin", but it was incomplete because the command threw an "Error 73". I was following your instructions, and I noticed that the output name of the file was "original" instead of "fixed". I probably could of outputted it to a new name to reduce confusion, but I didn't really care too much about the name as long as I had a working file.
I think you mean super_fixed.bin
...
Shouldn't you be flashing super_fixed.bin...
Click to expand...
Click to collapse
Normally, yes. But the Linux script also outputted the filename "super_original.bin". Again, as long as it worked, I was okay with it. The commands I used above were the exact commands that I ran at the time. I copied them from the terminal consoles I was using. So I don't know why it wasn't outputting the correct filename (again, I was following your instructions and was a little confused that the names came out differently - I just figured I was doing something wrong like not use the proper output command or something).
Then you don't have to worry about manually flashing the wrong file to your super partition...
Click to expand...
Click to collapse
I was really just being cautious because my previous phone broke and I didn't have a fallback.
But, at no point were there two bin files (original and fixed), so there wasn't much confusion. Where I originally had just ".img" files before running the script, I now had a single ".bin" file. I knew that was the file I needed.
But again, thank you for all the hard work on this tool! I was reading that it's worked on lots of different model phones, and it's always good to see the open source community doing things that help all kinds of people.
For moto notification for this phone at least use https://play.google.com/store/apps/details?id=br.com.itsmeton.motoledreborn or moto led reborn from the play store it just works
Hi, sorry. This can be removed. I put it in place because I was having issues with the xda app. For whatever reason, every time I tried to share this particular post, it would share a link for the post which I used originally, rather than the current post. I knew that if I commented I could get back here easily on my PC.
So what is the place holder for