Related
I take no credit for any of this, I have just put together things I have found on various threads.
As you all know the touch screen calibration that runs at boot does not work with any of the newer kernels as you cannot see some of the cross hairs to tap. I have personally NEVER been able to produce my own accurate ts-calibration file and have been using an ancient one that I downloaded back in the early days of FRX (thank you arrrghhh). Hopefully you have a somewhat functional ts-calibration file as you need to carry out this procedure from within Android. Here we go... (it's easy)
1. Download HtcCalibrate_WVGA.apk, thanks to lukas.pce, attached to first post here http://forum.xda-developers.com/showthread.php?t=1457343 to your device.
2. Install HtcCalibrate_WVGA.apk
3. Run HTC Calibrate and follow the instructions, tapping all the points (I used a toothpick for added accuracy)
4. When complete the app will report 'Calibration complete', tap 'Done'. Your screen should now be accurately calibrated for this session. Test to make sure it is working correctly before proceding to next step.
5. Now to get the calibration data to stick after reboot: Open your file explorer (MUST HAVE ROOT ACCESS; I use ES File Explorer with Menu>Settings>'Up to Root' checked) and navigate to /sys/devices/virtual/input/input3/ there you should see a file named calibration_points.
**It seems that in some builds (perhaps depending on kernel version?) that the devices get defined differently and I have found the file calibration_points in /sys/devices/virtual/input/input2/.
**So if you can't find it in input3/ then check input2/ (I haven't seen it anywhere else, but it probably could be in input1/, 4/, or 5/ as well, if not in the first two).6. Finally copy calibration_points to /sdcard/ (the root of your SD card), delete your existing ts-calibration file (or backup somewhere if you want) and rename calibration_points to ts-calibration.
**Nand users see this (thanks wizardnight!):
wizardknight said:
BTW on the nand version (GBX0* + 3.3.x kernel) it needs to be placed in /data/
Click to expand...
Click to collapse
Done. Your phone should now boot with the calibration data you created.
So that is where it sticks the file. I have been trying to find that out forever. Cool beans.
I had been using an old version of GBX0B on an sd card to make a decent ts-calibration file. Kind of a pain as you have to load up WM, then GBX0B to make the file at boot time (and it wasn't as accurate as the HTC one), copy it , and then reload the GBX and paste it.
BTW on the nand version (GBX0* + 3.3.x kernel) it needs to be placed in /data/
Why couldn't you have posted this sooner When I was using GBX0C I couldn't find the file anywhere
Ha! Sorry, I just found it today. Your problem was prbably that you looked virtually everywhere! It does seem an odd place for the file to be.
Would it work to bind-mount that file to /data/ts-calibration in the boot script, so that running HTC Calibrate will automatically write it?
That I do not know. I have never looked at the boot script or bind mounted anything. But automating this does sound like a great idea!
It would be amazing if a dev could do a reverse compile on this app, and put in an option to select the save location. One can dream.
I was taking a look at the data and time stamps on calibration_points, and it seems that there is a script somewhere that takes ts-calibration and overwrites calibration_points at boot time. If that is correct disabling that overwrite would mean the app could work fine as-is.
Unfortunately just renaming the ts-calibration is not enough. During the boot process it creates a new one with a set of values.
I found this bit of code that might explain why we are seeing this overwriting.
http://gitorious.org/xdandroid/rootfs/merge_requests/4
Part 1 locates the touch screen manager directory
Part 2 looks for ts-calibration in /data/ and if it finds it overwrites calibration_points
otherwise it creates a new ts-calibration using a default set of values and then overwrites calibration_points
So what we want to do is have it overwrite /data/ts-calibration with $touchscreendir/calibration_points as long as calibration has been completed previously within android.
Now I haven't really written code/scripts in a decade and am not yet too familiar with linux but something like:
(tiad8's commit, edited poorly by me)
## Ts Calibration
for i in /sys/class/input/input* ; do
if [ "`cat $i/name`" = "tssc-manager" ] ; then
touchscreendir=$i
echo "Touchscreen device directory is $i"
fi
done
if [ -f /data/ts-calibration ] ; then
echo "Using Saved Touchscreen Calibration"
echo 128,128,1903,128,128,1907,1903,1907,1024,1024 > $touchscreendir/calibration_screen
cat /data/ts-calibration > $touchscreendir/calibration_points
else
if [ -f "$touchscreendir/calibration_points"="0,0,0,0,0,0,0,0,0,0" ] ; then
echo "Using Default Calibration Values"
echo 821,860,197,868,500,517,829,172,191,171 > /data/ts-calibration
cat /data/ts-calibration > $touchscreendir/calibration_points
else
echo "Using Last Calibration Values"
echo 128,128,1903,128,128,1907,1903,1907,1024,1024 > $touchscreendir/calibration_screen
cat $touchscreendir/calibration_points > /data/ts-calibration
fifi
I am sure that my commands and syntax above are wrong, it's the concept that I am trying to convey.
I want to look to see if there is a ts-calibration and if not then look to see if there is valid calibration data in calibration_screen and if there is then write that value to ts-calibration. Thus to update calibration all you need to do is run HTC Calibration, and delete ts-calibration.
I guess you could also compare calibration_screen to ts-calibration and if there are differences (and calibration_screen is valid) have ts-calibration overwritten, removing the need to delete it!
I am assuming that before calibration or having ts-calibration written to it that calibration_screen has the value 0,0,0,0,0,0,0,0,0,0 but it could also be 0 or empty i don't know really and am probably wrong!
Also for GBX0C /data/ would have to be /sdcard/
One major problem with that plan:
/sys/ isn't a real filesystem.
It's a virtual file system, like /proc/, created programmatically by kernel drivers. It's not stored anywhere.
That boot script is writing the node because that's the only way to get the data into the kernel. If you don't do that, the calibration gets purged (or more accurately, not initialized) every boot.
That's why I proposed a bind-mount: make an access to one place in the filesystem affect another place. Though I realize another problem with that... The driver doesn't read from the filesystem! You have to actually write to the node to get the data into the driver. So that busts that plan.
It might be theoretically possible to modify the kernel driver to signal a userspace process to copy that data out, but... I don't know what would go into that, or even if it's ideal.
I have been using the latest kernel, 3.4 with a new build of GBX0C and decided to re-calibrate my screen:
Strange.... When I went looking for calibration_points in /sys/devices/virtual/input/input3/ it wasn't there, it had moved to /sys/devices/virtual/input/input2/
Before I edit the first post can anyone who is using the 3.4 linux kernel confirm this, please?
I can confirm that with the 3.3 kernel, mine is in input2, not input3
where to copy? does not have memory card
karelkopp said:
where to copy? does not have memory card
Click to expand...
Click to collapse
What does not have a memory card? The RHOD certainly has a slot for one...
Edit - I just realized why your question is so poorly worded. You're running NAND, and this thread assumes you're on a SD build.
I responded to you here.
I recently started working on a Android based Car solution and decided to buy the MK802 units. My car used to have a Windows based PC, so I already have VGA touchscreens installed. I didnt want to replace the screens, so I bought a HDMI to VGA converter and the MK802.
I plugged the touchscreen into the MK802, assuming it wouldnt do anything. But sure enough, it works. Problem is the calibration is off and up and down are reversed. So say I tap the bottom of the screen, the mouse pointer appears on the top of the screen and vis versa. My understanding (Im very new to this) is that you have to be rooted, which is the way these devices come.
So my question is, will this calibration tool work? I know most Androids use a multi-touch screen. Mine are 4-wire touch panels. Also, what do I have to look for and edit to get Up to Up and Down to Down?
Thanks in advance!
hijackzx1 said:
I recently started working on a Android based Car solution and decided to buy the MK802 units. My car used to have a Windows based PC, so I already have VGA touchscreens installed. I didnt want to replace the screens, so I bought a HDMI to VGA converter and the MK802.
I plugged the touchscreen into the MK802, assuming it wouldnt do anything. But sure enough, it works. Problem is the calibration is off and up and down are reversed. So say I tap the bottom of the screen, the mouse pointer appears on the top of the screen and vis versa. My understanding (Im very new to this) is that you have to be rooted, which is the way these devices come.
So my question is, will this calibration tool work? I know most Androids use a multi-touch screen. Mine are 4-wire touch panels. Also, what do I have to look for and edit to get Up to Up and Down to Down?
Thanks in advance!
Click to expand...
Click to collapse
This tool was made for HTC phones. You will need to find the group for your device to get support for it.
Calibration problem
Hello,
I am not able to calibrate screen on htc touch pro2 sprint modem (T7380) PocketPC
there is a software problem due to which i had to reset factory restore button inside handset ,and restarted device
but it stuck on calibrate option ,continuous prompt to press all 4 side and centre ,even though i had done multiple time
but no further progress ,would like to know how to come out from this problem
now the handset is completely not starting ...i am on calibrate mode screen.
please suggest any solution .
syedwasi said:
Hello,
I am not able to calibrate screen on htc touch pro2 sprint modem (T7380) PocketPC
there is a software problem due to which i had to reset factory restore button inside handset ,and restarted device
but it stuck on calibrate option ,continuous prompt to press all 4 side and centre ,even though i had done multiple time
but no further progress ,would like to know how to come out from this problem
now the handset is completely not starting ...i am on calibrate mode screen.
please suggest any solution .
Click to expand...
Click to collapse
It sounds like you are having this issue with a Windows Mobile ROM and this thread is dedicated to Android on the Touch Pro2. However...
OFF TOPIC:
I had a similar problem with my old Acer M900 and the solution was to put an empty text file in the root (no folders) of your SD card and rename it welcome.not and this will bypass the screen calibration on your first boot. I was then able to successfully run the calibration afterwards from the settings menu. Here, to make it easy I attached the file here:View attachment welcome.zip. Simply unzip the file and place the file welcome.not on your storage card.
Caldair said:
I take no credit for any of this, I have just put together things I have found on various threads.
As you all know the touch screen calibration that runs at boot does not work with any of the newer kernels as you cannot see some of the cross hairs to tap. I have personally NEVER been able to produce my own accurate ts-calibration file and have been using an ancient one that I downloaded back in the early days of FRX (thank you arrrghhh). Hopefully you have a somewhat functional ts-calibration file as you need to carry out this procedure from within Android. Here we go... (it's easy)
1. Download HtcCalibrate_WVGA.apk, thanks to lukas.pce, attached to first post here http://forum.xda-developers.com/showthread.php?t=1457343 to your device.
2. Install HtcCalibrate_WVGA.apk
3. Run HTC Calibrate and follow the instructions, tapping all the points (I used a toothpick for added accuracy)
4. When complete the app will report 'Calibration complete', tap 'Done'. Your screen should now be accurately calibrated for this session. Test to make sure it is working correctly before proceding to next step.
5. Now to get the calibration data to stick after reboot: Open your file explorer (MUST HAVE ROOT ACCESS; I use ES File Explorer with Menu>Settings>'Up to Root' checked) and navigate to /sys/devices/virtual/input/input3/ there you should see a file named calibration_points.
...
..
**Nand users see this (thanks wizardnight!):
Done. Your phone should now boot with the calibration data you created.
Click to expand...
Click to collapse
I have had a little bit of an alingment problem with my screen on my TP2. The NAND GBX works great so far. The only small but nevertheless important issue is finding a way to calibrate the screen and all Google searches lead back to the same forum post here , which has many files in the zip but NO apk inside.
Anyway, if anybody has any information of where to find an apk that will work, or maybe information on how to use the included files in the above mentioned link would be much appreciated.
My sincere thanks to all the developers that make all this modding possible, thank you all.
isruco said:
I have had a little bit of an alingment problem with my screen on my TP2. The NAND GBX works great so far. The only small but nevertheless important issue is finding a way to calibrate the screen and all Google searches lead back to the same forum post here , which has many files in the zip but NO apk inside.
Anyway, if anybody has any information of where to find an apk that will work, or maybe information on how to use the included files in the above mentioned link would be much appreciated.
My sincere thanks to all the developers that make all this modding possible, thank you all.
Click to expand...
Click to collapse
I just redownloaded the WVGA calibration from the link you refered to here:
[URL="http://forum.xda-developers.com/showthread.php?t=1457343"]http://forum.xda-developers.com/showthread.php?t=1457343
And the file seems to be intact and unchanged.
Those attached files on said thread ARE apk's already, they don't need to be extracted, just installed on your TP2.:good: Hope that helps!
Hi guys, I have the Rock Jaw Vi phone which by all sense and purpose seems to be a clone of the HTC One. It's Quad Core with 2 mega pixel camera on the front and 8 mega pixel on the back. The case and all outward appearances are that of the HTC, the phone info screen displays the following ...
Model Number = RJViJGTL32SM
Andoid version 4.2.1
Baseband version = moly.wr8.w1248.md.wg.mp.v6.p8,2013/08/12 15:55
Kernel version 3.4.5 [email protected] #1 Mon Aug 19 16:54:14 CST 2013
Build Number = 0502H026_20130819
I can get into the boot options screen by doing the On/Volume Down press but the menu's are all in Chinese and just seem to go through self diagnostics and tests. I can drag n drop file from Mac OSx but none of the apps I have found so far will communicate with the phone via USB. I am trying to get root so i can do a full back-up and then to try and put HTC Android 4.3 on it.
Do you guys have any idea on how I can achieve this or to get the phone to display it's boot options in English ?
I am pretty much clueless and stuck, any advice, tips, hacks etc would be really appreciated
I did follow a link at one stage on the web that went to SRSroot but their tool was windows only
Hmmm More messing with the phone has revealed power on with volume up depressed gets me to some very small text menu with the options;
Boot Normal
Fastboot
Boot(UART)
Boot UART is all the test screens that I was getting in Chinese but now they are touch screen buttons and labeled in english ao that's good to know.
Using fastboot-mac from HTCRootOne tries to talk to it but comes back with error: could not clear input pipe; result -536854449, is this something that's platform specific, ie it's not a true HTC so the version of fastboot-mac is no good and needing a non specific version ?
Ok that error is generated to the oem get_identifier_token...
If i do a fastboot-mac devices i get the reply "mt6589_phone_720pv2 fastboot" ...
I'm getting there slowly
Done some more digging with the phone attached to the Mac here and checking my systems profile I see that the phone is listed under usb connections as seen in the screen grab, still referring the as a HTC. Getting a new usb cable delivered to see if the phones usb cable provided is for charging only. If anyone here has any other suggestions I would be all ears or eyes as the case might be
Done more grubbing around and have found it to be a HDC One, HTC One clone .... Now to go see if any are rooted on here
Can anyone help me
Well i am pretty much stuck here so if anyone is reading this and wants to offer some help and advice I could do with it
I have looked around on the phone and can't see any bin or system folders even with show hidden i can't find them.
adb wont give me a remote shell, it complains that there is no bin/bash
when i try and do an adb backup i get 0 byte files grrrrr!!
I still need to find a way of getting root
This phone is a tricky beast for a learner - lol
Install some file explorer that allows you to browse from the top folder (/). I'm pretty sure you'll find at least /system there.
gbl08ma said:
Install some file explorer that allows you to browse from the top folder (/). I'm pretty sure you'll find at least /system there.
Click to expand...
Click to collapse
Thanks Gbl08ma - I have have it opened in Mac osx finder with show all files hidden or otherwise - The phone shows as two "No Name" devices and get mounted immediately on connection ....
I used sideload to push a package file over using adb and then went back to use Finder, and I can't see the file anywhere - hidden partition perhaps ? Can you do that with Android ?
Even the Android SDK file transfer app wont see the phone when it's connected, I am all very confused - lol
Thanks for the reply - Wonder if i can use disk utility to so some probing and at least get an ISO image file incase I goof things real bad - lol
TpwUK
tpwuk01 said:
Thanks Gbl08ma - I have have it opened in Mac osx finder with show all files hidden or otherwise - The phone shows as two "No Name" devices and get mounted immediately on connection ....
I used sideload to push a package file over using adb and then went back to use Finder, and I can't see the file anywhere - hidden partition perhaps ? Can you do that with Android ?
Even the Android SDK file transfer app wont see the phone when it's connected, I am all very confused - lol
Thanks for the reply - Wonder if i can use disk utility to so some probing and at least get an ISO image file incase I goof things real bad - lol
TpwUK
Click to expand...
Click to collapse
/ does not get mounted over USB so you won't see /bin, /system, /data or anything other than the SD card and the internal FAT32 "user" partition when entering USB transfer mode.
You must do it on the device. And for adb to work, USB debugging must be enabled in the settings.
gbl08ma said:
/ does not get mounted over USB so you won't see /bin, /system, /data or anything other than the SD card and the internal FAT32 "user" partition when entering USB transfer mode.
You must do it on the device. And for adb to work, USB debugging must be enabled in the settings.
Click to expand...
Click to collapse
I already had the phone in usb debug mode. Had to set the phone to use usb as MTP and not mass storage device connection type. Now it allows me to get in to the blighter with adb, fastboot still errors with pipes. That method allows me to get adb shell running and i can get android file transfer .... back to the reading part again
Thanks for the information gbl08ma - if i can find a way to back-up the rom i will share it somewhere
Hmm yummy - lots of interesting things in there .... Forgive my ignorance again please, but if i can create an update.zip file from the shell on the device that compresses all files from \ and all subdirs would that be the same thing as a safe ROM backup ? i wanna be safe before i attempt to root the phone as someone on here has a lower spec version of this phone and says it's a partial brick now.
TpwUK
Rooted
This phone is easily rooted with the motochopper
http://forum.xda-developers.com/showthread.php?p=40747604
Now should I push my luck further and go for the ROM - lol
TpwUK
I believe i own the same mobile
@tpwuk01
I also asked the same here; http://forum.xda-developers.com/showthread.php?t=2180425&page=92
but i was only able to root using frama root app, and it worked like a charm, but thats the only thing i could achieve, dont know but it seems theres no official thread of developement going on for any cloned device, mine runs the MOLY.WR8.W1248.MD.WG.MP.V6.P8 2013/08/12 15:55 Baseband.
After root i just installed some root apps, ads blockers, cant get any recovery to work, (Playing safe actually not to brick this now, since no support yet) but would have appreciated trying out kitkat on it, using antutu to view up specs, its impressive, i got to find out our 13MP camera at the back can do a great job than it currently is we only need to figure out how to change the image compression, the one i stumbled upon online was the blast, the 13MP was great also the flash light was tweaked to be 50X its current brightness, our 1GB application space was increased to 3.5GB, GPS and the rest was also modded to work really great.
Would like to hear any new updates you stumble upon bro.
Still a nice and featured packed device.
Hi all. First, apologies if this is the wrong place for this sort of post. It's mainly just a collection of my notes on the Verizon LG G3 running stock software update VS98510B, so there are a lot of different topics touched upon. I'm usually pretty shy around forums, but I figured something I've found might be useful to someone else, so I finally decided to post here. Anyway, here's what I've found.
Autorun Installer
This really annoyed me for a while when I first got the phone. Every time I'd try connecting it to my computer, it'd enter some sort of installer mode for LG/Verizon drivers. It would stay in this mode for about 30 seconds unless I manually put it back into ADB mode. After a good bit of digging around, I found out how to disable it without root or any special permissions. Open the stock dialer app, then enter the code "##3328873" and press send. It'll prompt for a service code, which is (of course) "000000". While the Verizon G3 appears to be missing a large chunk of the hidden menus, this section still seems to work. One of the options is a checkbox for "Tool Launcher enable" - uncheck it to disable the Verizon autorun installer.
Sideloading in Recovery Mode
I was curious how IORoot worked, so I started taking it apart. Basically, on the G3, it just uses a .zip sideloaded in recovery mode to copy over the su and related binaries. There's a decent bit of documentation out there on how to create your own .zip for sideloading, but I found one catch - the .zip needs to be signed with the proper key, or recovery will reject it. It turns out that this key is located at "./bootable/recovery/testdata/testkey" in the AOSP project. I forget the exact command for signing the .zip, but using this key, you can create your own sideload applications. Edify provides a nice way to script your application; I used it to create a sideload application to replace the HotspotProvision apk with a slightly modified version that skips the billing checks. Doing so does not require root access, as the sideloaded application appears to run as root by default. Replacing "HotspotProvision.apk" also does not trigger the root detector. However, I also made my own sideload .zip to copy over the su binary I compiled from AOSP - as soon as I booted the phone, the software status indicator changed to modified. I have some more information on that below. If anyone wants either of these sideload applications, I can upload them somewhere with their source, just let me know.
Ramdisk Compression
The boot, recovery, laf, and factory partitions are all mostly in standard format and can be split into the kernel and ramdisk parts with existing tools. However, most tools seem to expect the ramdisk to be compressed using gzip. Since it's not, they'll fail to extract the cpio archive from it. The G3 ramdisk is compressed using LZ4 instead. Once decompressed using the standard LZ4 utility, it has the same structure as a normal boot ramdisk - the cpio archive can be extracted to view the boot filesystem. I haven't really looked into it, but I believe the boot images all have a device tree binary appended after the ramdisk as well.
AT Commands
When looking into the boot process, I stumbled upon the AT command framework for the G3, which proved to be rather interesting. When connected to my computer in ADB mode, the phone exposes two serial ports. One of these ports looks like it's supposed to accept plain-text AT commands, but it also has been rather buggy in registering the end of a command for me. The other port accepts commands in some sort of binary format that I have not taken apart yet. If you want to send AT commands to the phone from ADB shell, write them to "/dev/smd0" and read the response from there. Sometimes, the response is not put on the device for some reason, but instead just printed to the logs under the tag "Atd"; just use "logcat Atd:V" to view them. The requests seem to be handled by "/system/bin/atd", which largely uses "/system/lib/libatd_common.so" to work. Looking through the disassembly showed some interesting things, included what looked like a test command that involved the bootloader unlock status, though I haven't figured out exactly how it works yet. A lot of the commands began with "AT%", which I think is the vendor specific prefix for AT commands typically. For some reason, I couldn't get any of these commands to work, even though some of the standard commands worked fine. One particularly interesting function (to me) was one that claimed to be able to write the software bootloader, SBL1. The function was called "store_sbl1_image"; there are some other functions that affect sbl1 as well. There are also functions for qfuses/QFPROM and other things that may be of interest to us. A lot of these functions access the misc partition through "/system/lib/liblgftmitem.so", so that may be a partition worth looking into.
Volume Key Booting
Entering the dialer command "##228378" and pressing send brings up a menu that has an option called "Device Test". Choosing this option prompts you that the phone will reboot; if allowed, it will reboot into MiniOS mode, which is stored in the "factory" partition ("/dev/block/mmcblk0p40"). This mode allows you to run a number of device tests, though many options are disabled somehow. One interesting thing I've observed is that, if the phone is shut down from MiniOS mode, then turned on by holding the volume down and power buttons simultaneously (possibly while plugged into a computer, I forget if this is necessary), the phone enters a pseudo-recovery mode that vaguely resembles real recovery mode, but is actually implemented after boot. Another volume key command is to hold volume up while powering on and connected to a computer by USB (the USB connection is required). This boots into factory download mode from the "laf" partition("/dev/block/mmcblk0p33"). The only way I've found to exit this mode is to remove the battery from the case. One final note is that while booting into normal mode, but having done so by holding volume down and the power button, the bootloader logs a message that it is going to enter fastboot mode. However, it does not and just boots normally instead. It seems that fastboot can only be activated if aboot fails to boot normally. I've read of people accomplishing this by messing up the "laf" partition and then booting into download mode, but I've not tried it myself.
Root Checker ("/system/bin/rctd")
After already setting my system to the "modified" status, I looked into the root checker executable at "/system/bin/rctd". A quick disassembly showed almost no strings in the binary. This is because they are all obfuscated. To load the strings, as series of instructions store individual characters into the stack at the proper offsets, eventually forming all of the strings needed by the program. Because I don't have the "Pro" version of IDA, I can't just run the executable through the debugger to get the strings out, so I had to resort to writing a really hacky emulator for a few ARM instructions to produce the strings. I only did this for one function, but the results were rather interesting. This function constructed the following string(s): "mt6575 mt6577 /sbin/su ro.hardware /system/bin/su /system/xbin/su /system/sbin/su /data/local/tmp/su /system/bin/busybox /system/xbin/busybox /data/local/tmp/busybox /system/app/Superuser.apk /system/app/SuperUser.apk /system/app/superuser.apk /system/app/SuperuserPro.apk /data/local/tmp/Superuser.apk /data/local/tmp/SuperUser.apk /data/local/tmp/superuser.apk /data/data/com.noshufou.android.su". I'm assuming this is a list of all of the files that the program looks for to determine if the phone has been rooted. In theory, using some way of randomly naming these files could prevent the root checker from detecting a rooted presence. If anyone who has IDA Pro wants to run "rctd" through the debugger, they might find more interesting things.
fastboot oem-unlock
While I've not tried booting into fastboot mode myself, I have "manually" executed the "fastboot oem-unlock" command. By disassembling the "aboot" partition ("/dev/block/mmcblk0p5"), I found that oem-unlock writes the value 0x01 to offset 0x1FFE10 of the "aboot" partition. I replicated this action with the command from a root shell "echo -en '\x01' | dd of=/dev/block/mmcblk0p5 bs=1 seek=2096656 count=1 conv=notrunc". After doing so and rebooting, which seemed to take longer than usual, I checked the kernel logs in "/data/logger/kernel.log*", and, in the bootloader logs section, there was a line displaying "[ 0.355056 / 01-01 00:00:00.340] [580] use_signed_kernel=0, is_unlocked=1, is_tampered=0.", seemingly indicating that the device was unlocked. However, it is not, as I'll mention later.
LGFTMITEM Spam in logcat
On the two VS985 phones I've looked at, both seem to produce a large amount of spam to logcat under the tag "LGFTMITEM". This takes the form of several lines being logged every 500 ms, consistently. I believe that setting the property "sys.lgsetupwizard.status" to "1" should stop it, though I haven't been able to do so successfully yet.
Bootloader Unlocking
One of the main goals of my tinkering has been to find a method for unlocking the VS985 bootloader. I believe I have identified the path to do so while disassembling "aboot", but I do not know how to enable it. I'll try to describe it here. In "sub_F81FF5C" of the "aboot" partition (I created a basic ELF format binary from the partition by trimming the first 40 bytes of the partition dump and then creating a single section ELF file loading that trimmed portion to address 0x0F800000), there is code that verifies the kernel and ramdisk images of the loaded boot partition. The code refers to "FEATURE_LGE_QCT_HW_CRYPTO", if that has meaning to anyone. Before the verification takes place, however, the function calls function "sub_F81FF58" with a memory location passed in R2. If this function call stores the value 0x67661147 in the memory pointed to by R2, the function bypasses all of the verification checks and simply prints "Device UnLock". This is why I believe "fastboot oem-unlock" would not be effective - my bootloader logs still indicate that the bootloader is taking the cryptographic verification path even though I have "unlocked" the device. I've tried to follow the function calls from here, but they get rather complicated and refer to memory locations not within the executable itself, which confuses me. In one of the functions invoked from here, which seems to print out the results of some sort of command, there are the strings "READ_UNLOCK_DEVICE_CERTIFICATE", "UNLOCK_DEVICE_AUTHENTICATION", "ANTI_ROLLBACK", and most interesting to me, "BACKDOOR". I've been having trouble figuring out how this part of the code works, so if anyone has any ideas, I'd be interested in hearing them.
Well, I think that about covers most of what I've found out about this phone. I'd be happy to explain anything in more detail if it's not clear.
IllegalArgument said:
Hi all. First, apologies if this is the wrong place for this sort of post. It's mainly just a collection of my notes on the Verizon LG G3 running stock software update VS98510B, so there are a lot of different topics touched upon. I'm usually pretty shy around forums, but I figured something I've found might be useful to someone else, so I finally decided to post here. Anyway, here's what I've found.
Autorun Installer
This really annoyed me for a while when I first got the phone. Every time I'd try connecting it to my computer, it'd enter some sort of installer mode for LG/Verizon drivers. It would stay in this mode for about 30 seconds unless I manually put it back into ADB mode. After a good bit of digging around, I found out how to disable it without root or any special permissions. Open the stock dialer app, then enter the code "##3328873" and press send. It'll prompt for a service code, which is (of course) "000000". While the Verizon G3 appears to be missing a large chunk of the hidden menus, this section still seems to work. One of the options is a checkbox for "Tool Launcher enable" - uncheck it to disable the Verizon autorun installer.
Sideloading in Recovery Mode
I was curious how IORoot worked, so I started taking it apart. Basically, on the G3, it just uses a .zip sideloaded in recovery mode to copy over the su and related binaries. There's a decent bit of documentation out there on how to create your own .zip for sideloading, but I found one catch - the .zip needs to be signed with the proper key, or recovery will reject it. It turns out that this key is located at "./bootable/recovery/testdata/testkey" in the AOSP project. I forget the exact command for signing the .zip, but using this key, you can create your own sideload applications. Edify provides a nice way to script your application; I used it to create a sideload application to replace the HotspotProvision apk with a slightly modified version that skips the billing checks. Doing so does not require root access, as the sideloaded application appears to run as root by default. Replacing "HotspotProvision.apk" also does not trigger the root detector. However, I also made my own sideload .zip to copy over the su binary I compiled from AOSP - as soon as I booted the phone, the software status indicator changed to modified. I have some more information on that below. If anyone wants either of these sideload applications, I can upload them somewhere with their source, just let me know.
Ramdisk Compression
The boot, recovery, laf, and factory partitions are all mostly in standard format and can be split into the kernel and ramdisk parts with existing tools. However, most tools seem to expect the ramdisk to be compressed using gzip. Since it's not, they'll fail to extract the cpio archive from it. The G3 ramdisk is compressed using LZ4 instead. Once decompressed using the standard LZ4 utility, it has the same structure as a normal boot ramdisk - the cpio archive can be extracted to view the boot filesystem. I haven't really looked into it, but I believe the boot images all have a device tree binary appended after the ramdisk as well.
AT Commands
When looking into the boot process, I stumbled upon the AT command framework for the G3, which proved to be rather interesting. When connected to my computer in ADB mode, the phone exposes two serial ports. One of these ports looks like it's supposed to accept plain-text AT commands, but it also has been rather buggy in registering the end of a command for me. The other port accepts commands in some sort of binary format that I have not taken apart yet. If you want to send AT commands to the phone from ADB shell, write them to "/dev/smd0" and read the response from there. Sometimes, the response is not put on the device for some reason, but instead just printed to the logs under the tag "Atd"; just use "logcat Atd:V" to view them. The requests seem to be handled by "/system/bin/atd", which largely uses "/system/lib/libatd_common.so" to work. Looking through the disassembly showed some interesting things, included what looked like a test command that involved the bootloader unlock status, though I haven't figured out exactly how it works yet. A lot of the commands began with "AT%", which I think is the vendor specific prefix for AT commands typically. For some reason, I couldn't get any of these commands to work, even though some of the standard commands worked fine. One particularly interesting function (to me) was one that claimed to be able to write the software bootloader, SBL1. The function was called "store_sbl1_image"; there are some other functions that affect sbl1 as well. There are also functions for qfuses/QFPROM and other things that may be of interest to us. A lot of these functions access the misc partition through "/system/lib/liblgftmitem.so", so that may be a partition worth looking into.
Volume Key Booting
Entering the dialer command "##228378" and pressing send brings up a menu that has an option called "Device Test". Choosing this option prompts you that the phone will reboot; if allowed, it will reboot into MiniOS mode, which is stored in the "factory" partition ("/dev/block/mmcblk0p40"). This mode allows you to run a number of device tests, though many options are disabled somehow. One interesting thing I've observed is that, if the phone is shut down from MiniOS mode, then turned on by holding the volume down and power buttons simultaneously (possibly while plugged into a computer, I forget if this is necessary), the phone enters a pseudo-recovery mode that vaguely resembles real recovery mode, but is actually implemented after boot. Another volume key command is to hold volume up while powering on and connected to a computer by USB (the USB connection is required). This boots into factory download mode from the "laf" partition("/dev/block/mmcblk0p33"). The only way I've found to exit this mode is to remove the battery from the case. One final note is that while booting into normal mode, but having done so by holding volume down and the power button, the bootloader logs a message that it is going to enter fastboot mode. However, it does not and just boots normally instead. It seems that fastboot can only be activated if aboot fails to boot normally. I've read of people accomplishing this by messing up the "laf" partition and then booting into download mode, but I've not tried it myself.
Root Checker ("/system/bin/rctd")
After already setting my system to the "modified" status, I looked into the root checker executable at "/system/bin/rctd". A quick disassembly showed almost no strings in the binary. This is because they are all obfuscated. To load the strings, as series of instructions store individual characters into the stack at the proper offsets, eventually forming all of the strings needed by the program. Because I don't have the "Pro" version of IDA, I can't just run the executable through the debugger to get the strings out, so I had to resort to writing a really hacky emulator for a few ARM instructions to produce the strings. I only did this for one function, but the results were rather interesting. This function constructed the following string(s): "mt6575 mt6577 /sbin/su ro.hardware /system/bin/su /system/xbin/su /system/sbin/su /data/local/tmp/su /system/bin/busybox /system/xbin/busybox /data/local/tmp/busybox /system/app/Superuser.apk /system/app/SuperUser.apk /system/app/superuser.apk /system/app/SuperuserPro.apk /data/local/tmp/Superuser.apk /data/local/tmp/SuperUser.apk /data/local/tmp/superuser.apk /data/data/com.noshufou.android.su". I'm assuming this is a list of all of the files that the program looks for to determine if the phone has been rooted. In theory, using some way of randomly naming these files could prevent the root checker from detecting a rooted presence. If anyone who has IDA Pro wants to run "rctd" through the debugger, they might find more interesting things.
fastboot oem-unlock
While I've not tried booting into fastboot mode myself, I have "manually" executed the "fastboot oem-unlock" command. By disassembling the "aboot" partition ("/dev/block/mmcblk0p5"), I found that oem-unlock writes the value 0x01 to offset 0x1FFE10 of the "aboot" partition. I replicated this action with the command from a root shell "echo -en '\x01' | dd of=/dev/block/mmcblk0p5 bs=1 seek=2096656 count=1 conv=notrunc". After doing so and rebooting, which seemed to take longer than usual, I checked the kernel logs in "/data/logger/kernel.log*", and, in the bootloader logs section, there was a line displaying "[ 0.355056 / 01-01 00:00:00.340] [580] use_signed_kernel=0, is_unlocked=1, is_tampered=0.", seemingly indicating that the device was unlocked. However, it is not, as I'll mention later.
LGFTMITEM Spam in logcat
On the two VS985 phones I've looked at, both seem to produce a large amount of spam to logcat under the tag "LGFTMITEM". This takes the form of several lines being logged every 500 ms, consistently. I believe that setting the property "sys.lgsetupwizard.status" to "1" should stop it, though I haven't been able to do so successfully yet.
Bootloader Unlocking
One of the main goals of my tinkering has been to find a method for unlocking the VS985 bootloader. I believe I have identified the path to do so while disassembling "aboot", but I do not know how to enable it. I'll try to describe it here. In "sub_F81FF5C" of the "aboot" partition (I created a basic ELF format binary from the partition by trimming the first 40 bytes of the partition dump and then creating a single section ELF file loading that trimmed portion to address 0x0F800000), there is code that verifies the kernel and ramdisk images of the loaded boot partition. The code refers to "FEATURE_LGE_QCT_HW_CRYPTO", if that has meaning to anyone. Before the verification takes place, however, the function calls function "sub_F81FF58" with a memory location passed in R2. If this function call stores the value 0x67661147 in the memory pointed to by R2, the function bypasses all of the verification checks and simply prints "Device UnLock". This is why I believe "fastboot oem-unlock" would not be effective - my bootloader logs still indicate that the bootloader is taking the cryptographic verification path even though I have "unlocked" the device. I've tried to follow the function calls from here, but they get rather complicated and refer to memory locations not within the executable itself, which confuses me. In one of the functions invoked from here, which seems to print out the results of some sort of command, there are the strings "READ_UNLOCK_DEVICE_CERTIFICATE", "UNLOCK_DEVICE_AUTHENTICATION", "ANTI_ROLLBACK", and most interesting to me, "BACKDOOR". I've been having trouble figuring out how this part of the code works, so if anyone has any ideas, I'd be interested in hearing them.
Well, I think that about covers most of what I've found out about this phone. I'd be happy to explain anything in more detail if it's not clear.
Click to expand...
Click to collapse
You should rename the title of your thread to something more likely to be read by devs trying to unlock the bootloader. It's too generic in my opinion. Excellent work so far, though. Thanks for your efforts and interest!
Nice to see anyone working on an unlock, also thanks for sharing.
---------- Post added at 02:33 AM ---------- Previous post was at 02:25 AM ----------
I forwarded the post to Justin case to see if he may be able to get in touch
This was way over my head. Have you PM'd @autoprime or @thecubed (aka IOMonster)? They are a couple of the devs working on unlock.
Sent from my VS985 4G
Howdy there!
Just in time, too - since I just got back from vacation!
Hop on IRC (freenode) and join #lg-g3 and ask for IOMonster, and mention this thread. I'd be happy to explain what I can to you.
You've followed excellent logic and have come to many of the same conclusions as we have during our exploration of the device. Factory mode reads FTM items, and can enable/disable menu options at will (or you could just extract it like a boot.img and load the lgeftm_* binaries into IDA and see what they do).
RE: AT commands, there's a lot of good logic in there, however at the moment nothing that looks to give us our unlock.
RE: Unlocking, you're close, but a bit far off. There's some special sauce LG is using for unlocks, and last I was looking I believe LGE is obfuscating bits of code with a multi-stage loader. I'll discuss more about this on IRC if you're interested and the rest of the guys on IRC are alright with me doing so.
One of those memory addresses is a function pointer - before I left for vacation we were working on dumping the memory to pull the decompressed function out of RAM on another device that uses a (very) similar strategy.
I look forward to talking to you on IRC!
Hope you enjoyed I'm sure a much needed vacation.. Hopefully soon someone will be able to crack this boot loader and free the G3 variants.
They will unlock it because how can the great device be locked and have only the tmobile version be the only one unlocked... Lol that's crazy. They will unlock it in time
I think your right in time ,unfortunately these guys have full life schedules that don't allow them to stay on it all day! I hope all the g3 community gets to enjoy the full potential of such a great device in the future.
OP @IllegalArgument
Hats off for your first loaded post on XDA, really reassuring to see as many capable devs tinkering with this, welcome and keep em coming
dabug123 said:
....I hope all the g3 community gets to enjoy the full potential of such a great device in the future.
Click to expand...
Click to collapse
Near future hopefully
nerdo said:
OP @IllegalArgument
Hats off for your first loaded post on XDA, really reassuring to see as many capable devs tinkering with this, welcome and keep em coming
Near future hopefully
Click to expand...
Click to collapse
Will see im hopeful but I won't be upset since nexus is close
Nexus won't run on Verizon, you can book that.
Sent from my HTC6525LVW using Tapatalk
dbatech99 said:
Nexus won't run on Verizon, you can book that.
Sent from my HTC6525LVW using Tapatalk
Click to expand...
Click to collapse
Yep agreed, I'm making the switch
dabug123 said:
Yep agreed, I'm making the switch
Click to expand...
Click to collapse
With Xposed framework and the right modules I can make this stock ROM almost like any custom ROM. It will definitely hold me over until they can unlock it.
Jank4AU said:
With Xposed framework and the right modules I can make this stock ROM almost like any custom ROM. It will definitely hold me over until they can unlock it.
Click to expand...
Click to collapse
My thoughts exactly, and with the Wifi tether mod, I'm content, for now.
Jank4AU said:
With Xposed framework and the right modules I can make this stock ROM almost like any custom ROM. It will definitely hold me over until they can unlock it.
Click to expand...
Click to collapse
I enjoy it with xposed..Not the same in the end but the g3 is a great won't ever say different.
Ooh, exciting. I can't wait.
kdouvia said:
Ooh, exciting. I can't wait.
Click to expand...
Click to collapse
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Jank4AU said:
Click to expand...
Click to collapse
Fail lol[emoji13]
Interesting read OP.
Jank4AU said:
Click to expand...
Click to collapse
Haha, bro, I was serious this is the most information I've heard about the boot loader unlock in awhile. I love the meme though. :victory:
I have a Razer Phone 2 rooted with magisk. I use GPS Joystick. I decided to select the "disable system GPS" setting in its options. I rebooted as the app requested and now my phone loads to the point where it wants me to enter my pin and I see my wallpaper for a split second then the screen goes black and it loads up the status bar about ever 10 seconds for a split second then it repeats. Like it is stuck in a loop. After a couple minutes phone reboots and I get this message...
Android Recovery
razer/chery12/aura
9/P-MR1-RC003-RZR-190305/3110
user/release-keys
Use volume up/down and power
Can't load Android system. Your data may be corrupt. If you continue to get this message, you may need to perform a factory data reset and erase all user data stored on this device.
Try again
Factory data reset
Click to expand...
Click to collapse
So I reached out to the dev of GPS Joystick and he explains that the option disables the location services called "fused location provider" and I have to re-enable it to fix the problem. He sent me a post here explaining that I need to pull an .xml file from the phone, change the code, and push it back. Simple right? Well maybe if I have TWRP, but I don't. I can however boot into the phones recovery options and there is an option there to "apply update from adb" but I cannot seem to pull anything using that interface. My Windows computer recognizes the device using Minimal ADB and Fastboot but it shows it as a whole bunch of numbers then the word "sideload" which I guess is a limited form of adb just for side loading? Maybe someone could make me a script that I can sideload that changes the file back to normal? Here is the code from the dev of GPS Jostick that is used to disable and enable the fused lcoation provider.
It calls this code to disable:
ComponentName component = new ComponentName("com.android.location.fused", "com.android.location.fused.FusedLocationService");
getActivity().getPackageManager().setComponentEnabledSetting(component, PackageManager.COMPONENT_ENABLED_STATE_DISABLED, 0);
And similar code to re-enable it:
ComponentName component = new ComponentName("com.android.location.fused", "com.android.location.fused.FusedLocationService");
getActivity().getPackageManager().setComponentEnabledSetting(component, PackageManager.COMPONENT_ENABLED_STATE_ENABLED, 0);
Click to expand...
Click to collapse
So my question is, can I pull this /data/system/users/0/package-restrictions.xml file from my phone and push it back without using TWRP? But instead using the phones recovery option and its various selections? I'd prefer to exhaust the resources to recover the phone since I have spent weeks personalizing it. I am not fluent in adb but I am hoping someone can throw some ideas or even a solution at me that I am missing. All I got to do is pull a file, change a word, push it back and reboot. I can't imagine there isn't a way to do this by just using what the phone has to offer. Any help would be greatly appreciated.
Another idea that came to mind is in its current condition could I install TWRP? Is fastboot an option at this point? Maybe if I can flash TWRP in its current state I can then make the appropriate modifications.
I ended up fixing the problem. I installed arter97's kernel that had TWRP baked into it. I then used TWRP to copy over the .xml file, change the code as mentioned above, and then copied it back to the phone. Problem solved. It is amazing how one simple word in a .xml file can prevent a phone from functioning properly. It simply amazes me.
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