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
Related
Okay guys, so here's a weird one.
My g-tablet was working great. Was running VEGAn-Tab Build, BETA 5.1.1, no reason to update it, because it did everything I needed. I finally had it to where I wanted it, then it all kind of started falling apart. Here's how.
I power it on and notice my home screen got all messed up for some reason (using launcher pro). All of the settings defaulted to the original. I tweaked it back to more or less how I wanted it, and when I had it back to normal, thought nothing better of it. Must have glitched out some how.
Then I notice a bunch of things starting to force close, specfically android market, amazon market, titanium backup, google services framework, launcher pro, etc. Odd thing is it would do it one at a time, but otherwise my tablet would carry on as normal.
I go ahead and restart the tablet, to see if that helps at all, and what do you know, the homescreen is messed up again! I thought launcher pro might have been the culprit, so I un-installed the app and rebooted... And launcher pro is still there.
I go ahead and delete it again and start deleting other apps, restarting the tablet, and no matter what I do, everything stays the same. time for some clockwork mod action. I go into clockwork mod, and try to do the factory reset option, thinking what the hey, I'll try anything right now. Hit it, mourn the loss of my user data, and reboot the system... and again, everything is still the same.
I hook up my tablet to the computer via usb, and it looks like I'm able to at least delete misc. files that way. But when I return to good old Tabatha (my nickname for Gtab) everything is stuck just the way it is.
Needless to say, it feels like I'm stuck in the twilight zone.
I know I should have researched it by now, but I'm going to finally look it up to see if I can recover with NVFlash (I know I know, very noobish of me, using strange roms and not knowing any of the basics).... but I'm increasingly worried I've got some kind of a hardware malfunction on my hands. Could it be the memory? The internal SD card?
Oddly enough, my tablet still functions... I can browse the web, hook it up to my computer, etc etc, but no matter what I do I can't alter the data I already have on my tablet. Can't delete things, can't change settings, update apps, etc. etc. Which makes it pretty much useless for what I wanted to use it for.
I finally realized what this is like. The movie groundhog day, and I'm stuck in the same day, over and over again.
Any help or input that might get me out of this mess would be greatly appreciated.
Phil: "I was in the Virgin Islands once. I met a girl. We ate lobster, drank piña coladas. At sunset, we made love like sea otters. *That* was a pretty good day. Why couldn't I get *that* day over, and over, and over..."
This is now the second time that I've seen this exact same problem. I was in the process of troubleshooting the original one when the user returned his gTablet for replacement. If you can stand the deja vu, read this thread.
Do not nvflash your tablet--nvflash cannot fix SD-card related problems. Read this post for why not.
Instead, do this for me: Reboot the gTablet, then open a Terminal, or, use adb and run this command:
Code:
$ dmesg > /mnt/sdcard/dmesg.txt
Attach that dmesg.txt which will contain messages from the kernel to your next post.
I'll check this thread in the evening.
rajeevvp said:
This is now the second time that I've seen this exact same problem. I was in the process of troubleshooting the original one when the user returned his gTablet for replacement. If you can stand the deja vu, read this thread.
Do not nvflash your tablet--nvflash cannot fix SD-card related problems. Read this post for why not.
Instead, do this for me: Reboot the gTablet, then open a Terminal, or, use adb and run this command:
Code:
$ dmesg > /mnt/sdcard/dmesg.txt
Attach that dmesg.txt which will contain messages from the kernel to your next post.
I'll check this thread in the evening.
Click to expand...
Click to collapse
Thanks for the direction, at least I know it isn't an isolated incident. It's 1:45 AM where I am right now, and I have to wake up for work in about 5 hours... So I probably won't be able to get in depth with the follow up on this stuff untill after work tomorrow night (so long as the wife doesn't hog the computer )
Again thanks for the quick response, I appreciate you pointing me into some sort of direction. Can't wait to try to get this sorted out!
Currently trying to figure out how to get ADB going.... pretty intimidating, but I'm trying. I got the Java JDK installed, installing the SDK, but can't find the "SDK Setup.exe" file or even a USB driver folder in the SDK directory. Got a good resource for getting ADB set up?
Save yourself some trouble. Got to http://www.knoppix.org/ and download the latest Knoppix live CD image.
Burn it, boot it, then use the adb executable from this post. For simple things like just running adb, you don't need the entire Android SDK.
Get me a dmesg while inside ClockworkMod:
Code:
$ [B]sudo ./adb shell dmesg > dmesg.txt[/B]
ADB commands documentation
Thanks, I'll try it out sometime this weekend!
Well, I really screwed myself now. I got the Linux distro loaded but still couldn't figure out how to get ADB to work. For whatever reason, When I boot from the DVD, I can't download the zip from within linux (get errors) and I could not open the ADB command by navigating to where I have it extracted in my hard drive. [Do I need to load the OS onto a flash drive instead?]
So I started messing with some stuff in clockwork mod. I apparently really goofed it, and I got a "Magic Value Mismatch" error everytime I tried to boot it up.
I looked up Magic Value Mismatch, and from there it pointed to using NVFlash to try to fix that problem. So tried that. After I flashed it, I thought for sure I finally had it back to stock, as the intro screen started to show the tap n tap logo... but i basically got stuck in a boot loop, tap n tap, then "n", then tap n tap, then "n", etc, until it dies.
I looked up this issue and apparently the key is to get into clockwork mod and do factory reset, reset cache, and partition the SD card to 2048 and 0, which I did... (per post #4 on this thread: http://www.slatedroid.com/topic/17501-helpstuck-in-bootloop/ ) but still no dice.
Not sure where to go from here, or if I can even get it to interface with ADB in its current state. Looks like I'm done for
Thanks for trying though
On second thought, I may have had a breakthrough, at least in getting ADB to see my tablet!!! Woohoo! It finally sees the device and has a serial number. Was following the device on this thread:
http://www.androidtablets.net/forum/viewsonic-gtablet-technical/5377-adb-g-tab-step-step.html
7. under the "[Google.NTx86]" section, paste the following:
Code:
;NVIDIA Tegra
%SingleAdbInterface% = USB_Install, USB\VID_0955&PID_7000
%CompositeAdbInterface% = USB_Install, USB\VID_0955&PID_7100&MI_01
save the file and exit.
But I have a 64 bit machine, so I finally figured it out and plopped that into the 64 bit portion of the .inf file. DOH!
So now let me see what I can drum up through the previous commands above.... though the parameters have changed now to be sure... Due to my haste things may have taken a turn for the worse.
To recap, now my tablet is stuck in a boot loop after having done NV Flash, after having screwed up some settings in clockwork mod trying to fix a "Magic Value Mismatch" error.
Tried:
$ dmesg > /mnt/sdcard/dmesg.txt
I just run this in the cmd prompt at my platform-tools directory where the adb is correct?
All it says is, "The system cannot find the path specified."
Am I doing something wrong, or is my tablet that messed up?
Okay, this is slightly weird. So I was browsing around in clockwork mod, and lo and behold, the original zip flies for vegan tab are all STILL THERE. So I reloaded them... And My tablet zips back to exactly the way I had it before!
Only this time, so far no force closes. This looks way too good to be true after what I've been through. I'm going to try modifying some files and settings and restart my tablet to see what it does. I'm pretty sure I can't be out of the woods yet. Allthough it is 3:33 AM as this is happening... magic hour. I may be going insane.
EDIT: Nope, was definitely way too good to be true. All my data is as stuck as it was ever was. But at least now I can get into it again. But now we're back to square one. Lemme figure out this dmesg business and get back to you. X(
So I would try issuing the following exactly in the command line at the adb platform tools folder:
$ dmesg > /mnt/sdcard/dmesg.txt
Is that code supposed to be copy and paste in? I don't seem to be getting anything. I can do the following command and get the info to pop into the command interface:
adb shell dmesg
But I can't figure out how to save that to a text file. And you want me to do that while the g tablet is in recovery, correct?
FYI, trying to do it through Windows 7. Would that command only operate in the linux environment via knoppix?
Thanks
titobetlogs said:
I can do the following command and get the info to pop into the command interface:
adb shell dmesg
But I can't figure out how to save that to a text file.
Click to expand...
Click to collapse
Redirect the output to a file:
Code:
C:\SOME\PATH> [B]adb shell dmesg > dmesg.txt[/B]
titobetlogs said:
I got the Linux distro loaded but still couldn't figure out how to get ADB to work. For whatever reason, When I boot from the DVD, I can't download the zip from within linux (get errors) and I could not open the ADB command by navigating to where I have it extracted in my hard drive.
Click to expand...
Click to collapse
I suggested using Knoppix just because it is so easy to use adb in Linux. Broken-down steps for future reference:
1. Download and burn the latest Knoppix Live CD iso image. Check the downloaded file size. The .iso file should be ~700MB in size. Also, test the CD by booting it and then typing at the boot prompt: knoppix testcd
2. Boot Live CD and skip the creation of any partition or file to store user data. After all, we just want to run adb.
3. After Knoppix has booted into the desktop, run a browser, right click on the adb.zip attachment in this post, then select "Save Link As..." and save the zip file into /tmp.
4. Connect the gTablet to the PC via the USB cable.
5. Open a terminal window, then type in it:
Code:
hostpc$ [B]cd /tmp[/B] [I]Change to the dir. where adb.zip was saved[/I]
hostpc$ [B]unzip adb.zip[/B] [I]Unzip zip file[/I]
hostpc$ [B]ls -l adb[/B] [I]Check if the adb program was extracted OK[/I]
-rwx------ 1 rvp rvp 159620 Dec 1 22:23 adb
hostpc$ [B]chmod 555 adb[/B] [I]Make adb executable.[/I]
hostpc$ [B]sudo ./adb shell dmesg > dmesg.txt[/B]
Note 1: do not type in the shell prompt, 'hostpc$'. It is only there to show you what the screen should (roughly) look like.
Note 2: If adb says something like "device not found", just unplug the USB cable from the PC, wait a few moments, then re-plug the cable and re-run the adb command again.
6. Go back into the browser and attach the dmesg.txt file that is there in /tmp. You will have to tell the Noscript plugin to allow scripts from xda-developers to enable attachments. Right click on the page, then select the Noscript menu item, then choose "Temporarily allow xda-developers.com".
I thought for sure I finally had it back to stock, as the intro screen started to show the tap n tap logo... but i basically got stuck in a boot loop, tap n tap, then "n", then tap n tap, then "n", etc, until it dies.
Click to expand...
Click to collapse
I'm not surprised. If the files on the internal SD card cannot be modified then that boot loop behaviour is to be expected. Here's why:
Android requires certain partitions to exist on the system. These partitions can be either on the flash or on SD cards. The partitions are:
/system: This is where the binaries and system apps that come with the firmware are stored. This partition is usually mounted read-only to protect it. On the gTablet, this partition is on the 512MB built-in NAND flash chip.
/cache: As the name indicates, this is the partition used to speed up the execution of the Java apps. Temporary files are also created here. This partition too is on the built-in NAND flash chip.
/data: This is where user-downloaded apps are stored by default, and also where Android stores its system configuration data. This partition, on the gTablet, is on the internal SD card.
/sdcard: This is where user content like media files, books, and the apps moved to SD card are stored. This partition too is on the internal SD card.
The first 3 partitions are critical and Android won't come up without them being present (or, if there are any errors on them). Among these 3, only /system needs to be correctly populated (When you install a ROM, new stuff is copied here). The other 2 partitions, /data and /cache can be empty and the system will boot up fine--with defaults. In fact, when you select "wipe data/factory reset" in CWM, /cache and /data are re-formatted--effectively, wiped clean.
(There are 2 other important partitions on the NAND flash chip, but, these are not mounted because they don't contain a proper filesystem. You have to use special tools to create the contents of these 2 partitions.
The first of these is the "boot" partition. This one and "system" are re-written when you install a new ROM. The "boot" partition holds the Android Linux kernel. If you install a new kernel, only the "boot" partition is rewritten.
The second is the "recovery" partition. This contains a separate, and usually different (and safe), Linux kernel and a mini filesystem image. This is a fail-safe partition. Stock recovery and ClockworkMod sit here.)
In your case, nothing on the internal SD card can be modified, so the stuff in /data will still be from your old ROM. (nvflash also cannot modify SD card contents, as I mentioned before.) When the stock firmware boots up, it will find incompatible stuff in /data. Critical apps will then die. Android will restart them, they will die again. This is your boot loop.
Get me the dmesg output and then we'll run a few tests using CWM, but, judging from your previous posts, I don't think your internal SD card can be fixed. You have 2 options:
1. Return the tablet for a replacement.
2. If you can't return it, I can switch the internal and external SD cards on your ROM so that you can boot and use the system (almost) normally. But, this is a custom solution and you will need to have an external SD card in its slot always. Read through this thread.
Wow, you really know you're stuff! I'll see what I can get you later on in the day with regard to the dmesg, I'm currently still at work.
I had suspected a hardware error... bummer. I'll definitely be interested in seeing if I can just use the external micro sd slot to sub out for the internal sd card. I would at least like this thing to be functional again, though I suppose I'll never be able to try any of the honeycomb roms when those get past alpha. Oh well.
Do you know if this thing takes 32 gb micro sd cards? That would be pretty awesome, I at least wouldn't feel too limited on space.
By the way, thanks for all your help on this, I know I'm a huge noob. I greatly appreciate your patience and taking the time to break everything down for me. I have absolutely zero background in programming or anything computer related, though I do find this stuff extremely fascinating! If I could rewind the clock and study this stuff in school, I would do it in a heartbeat.
Again, thanks so much, can't thank you enough.
titobetlogs said:
I would at least like this thing to be functional again, though I suppose I'll never be able to try any of the honeycomb roms when those get past alpha. Oh well.
Click to expand...
Click to collapse
No, you should be able to run whatever ROM you want. I'll send you an installable zip file, in a few days, which should get you going again on Vegan-Tab, at least. You'll just need to remember to flash this zip file right after you've flashed the ROM (of your choice).
Right now, I don't know if I need one zip file for each kind of ROM in existence for the gTablet, or, if I can use some scripting and do the internal/external SD card switch using just a single installable zip file. I'll look into this on the weekend.
Do you know if this thing takes 32 gb micro sd cards?
Click to expand...
Click to collapse
Yes, it does.
By the way, thanks for all your help on this, I know I'm a huge noob...
Click to expand...
Click to collapse
I was a complete noob to Android myself back in April of this year. I've picked all of this up in just a few months. I'm pretty sure you can do it too, with a bit of poking around in the system. Of course, having a background in Unix/Linux helps a lot.
In your honor, below are some inspiring lyrics from the Karate Kid soundtrack:
You’re the best!
Around!
Nothing’s gonna ever keep you down
You’re the Best!
Around!
Nothing’s gonna ever keep you down
You’re the Best!
Around!
Nothing’s gonna ever keep you dow-ow-ow-ho-how-ho-own
INSPIRING GUITAR SOLO
Dude! you're embarrassing me -- I haven't send you the zip file yet... and, you haven't sent that dmesg output I wanted.
I know I've been stuck at work and family functions every day this week so far. Hopefully I'll get to it soon
Finally got to this! Here you go! Thanks again!
titobetlogs said:
Finally got to this! Here you go!
Click to expand...
Click to collapse
Can't see any problems in that dmesg output. Time for some tests on the internal SD card.
Boot into CWM, then run on PC (on Linux run: sudo ./adb shell):
Code:
C:\SOME\PATH> [B]adb shell[/B]
~ # [B]mount /dev/block/mmcblk3p1 /sdcard[/B] [I] Mount internal SD card partition[/I]
~ # [B]mkdir -p /sdcard/a/b/c[/B] [I]Make a directory tree[/I]
~ # [B]echo test > /sdcard/a/b/c/test.txt[/B] [I]Create a file[/I]
~ # [B]cat /sdcard/a/b/c/test.txt[/B] [I]Read it back again[/I]
test [I]Correct[/I]
~ # [B]echo 3 > /proc/sys/vm/drop_caches[/B] Flush kernel caches
~ # [B]cat /sdcard/a/b/c/test.txt[/B] Read it back again
test Correct
~ # [B]umount /sdcard[/B] [I]Unmount[/I]
~ # [B]mount /dev/block/mmcblk3p1 /sdcard[/B] [I]Remount /sdcard[/I]
~ # [B]cat /sdcard/a/b/c/test.txt[/B] [I]Reread file[/I]
test [I]You should see "test" here[/I]
~ # [B]umount /sdcard[/B]
You should see "test" after the kernel flush and the remount.
Next, reboot the tablet--back into CWM, then run the cat command again. `cat' should output "test", again, if the SD card is OK.
Here's a screen of the commands I entered and what I got back. Did I do anything wrong? Looks like something's a bit off.
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:
This thread has been deleted.
This thread has been deleted.
This thread has been deleted.
***** really really really reserved*****
Working w/ Root on a Mac (OSX Yosemite)
CONFIRMED: This works using AT&T (SM-R750A), OSX (Yosemite), VirtualBox and Windows XP. See this link for the driver setup I used on my Mac.
http://www.onebadkid.com/?p=6930
I also find that after factory reset, I still have root! Great job!
---
Also, I haven't been able to get the scripts to work in the virtual machine so I've just been "pushing" the files manually. I did open up the scripts to get the destinations for the various files, so thank you OP. Also, you have to have the Tizen Wearables SDK installed and then use SDB commands in the terminal.
Remember, when using SDB on a Mac, it's: ./sdb [command] (you have to use the "dot-slash")
./sdb devices (to show whether or not your device is connected)
./sdb root on
./sdb shell (puts you into the device's shell so you can navigate the device in a Darwin/Linux terminal)
./sdb push [/full path of the file you want to upload to the device] [/full path of the desination]
I usually open up three Darwin/Linux Terminals on my Mac. One to use to navigate my watch in shell, the other to run the ./sdb command (just like in Windows, you have to run SDB on the mac from within it's home location: "/Users/[you]/tizen-wearable-sdk/tools"), and a third to drop files into so I can quickly see their full file path/location.
"PWD" = print working directory so you can use that in the Darwin/Linux Terminal so you don't get lost.
I'm using Windows 8.1 (don't know if it matters) but after updating to this driver my PC no longer recognized my Gear S. Had to roll back to previous driver.
Ohhhhh!!!
ohh SO installing these and getting it ready for the rest
Edit: got rootfs.img odin'd in so now i wait lmao
Wondering
Good write up so far. I had already gotten root from the previous thread with horrible direcions. LoL After I got my replacement gear s (ALWAYS CHECK YOUR SIM COVER), I rooted it using the bad direction method again (luckily I already know how to do these things), but your directions are very clear cut and noob friendly. You're doing a huge favor to new comers who come looking to root their gear. Hopefully they don't brick them before they find this.
cipherswitch said:
Got any request for certain alarms, notification sounds or ringtones? Shoot me a PM and I will get through them as fast as I can and repost here.
No themes as of yet, but I will definitely be working on custom clock faces apart from everything else
Click to expand...
Click to collapse
Reset my gear to factory to try out your method.
Odin'd over the root img and all went well after a few reboots (dont' turn off destination, installing new configuration, final reboot).
Watch reboots, open a command prompt and type "sdb root on" (Switched to'root' account mode)
sdb shell whoami
root
sdb shell setup-folder.sh
-1: /bin/setup-folder.sh: Permission Denied
I went and checked your .bat file and it uses the same command. The device says I have root but it's read only file system. I have been trying every trick I know the past half hour; any thoughts?
Megaflop666 said:
Reset my gear to factory to try out your method.
Odin'd over the root img and all went well after a few reboots (dont' turn off destination, installing new configuration, final reboot).
Watch reboots, open a command prompt and type "sdb root on" (Switched to'root' account mode)
sdb shell whoami
root
sdb shell setup-folder.sh
-1: /bin/setup-folder.sh: Permission Denied
I went and checked your .bat file and it uses the same command. The device says I have root but it's read only file system. I have been trying every trick I know the past half hour; any thoughts?
Click to expand...
Click to collapse
Do this
sdb root on
sdb shell
chmod +x /bin/setup-folder.sh
./bin/setup-folder.sh
Megaflop666 said:
Reset my gear to factory to try out your method.
Odin'd over the root img and all went well after a few reboots (dont' turn off destination, installing new configuration, final reboot).
Watch reboots, open a command prompt and type "sdb root on" (Switched to'root' account mode)
sdb shell whoami
root
sdb shell setup-folder.sh
-1: /bin/setup-folder.sh: Permission Denied
I went and checked your .bat file and it uses the same command. The device says I have root but it's read only file system. I have been trying every trick I know the past half hour; any thoughts?
Click to expand...
Click to collapse
Color me embarrassed. It seems in the final uploads, I nabbed the rootfs file that wasn't done yet. Uploading the new file now,sorry for the delay.
I reset, flashed the wrong one to confirm the issue then flashed the correct rootfs and confirmed it working. That was the issue, Im waiting for the new one to upload to mediafire now.
and yeah, I couldnt type this morning, totally freaking out.
cipherswitch said:
Color me embarrassed. It seems in the final uploads, I nabbed the rootfs file that wasn't done yet. Uploading the new file now,sorry for the delay.
I reset, flashed the wrong one to confirm the issue then flashed the correct rootfs and confirmed it working. That was the issue, Im waiting for the new one to upload to mediafire now.
and yeah, I couldnt type this morning, totally freaking out.
Click to expand...
Click to collapse
Its all good, I decided to tear into some things and bricked the damn thing, so I am sitting here waiting (forever) for the original firmware to download so I can factory restore it. I was not even able to get into recovery, just download mode. LoL
Oh well, if flashing the original firmware doesn't fix it, i'll take it up to Tmo at 10am and get a new one.
new rootfs uploaded as of 12/17/14 8:42 am est, I also updated the link in the writeup.
::::::Just a quick dirty write-up of how to load sounds with your newly rooted Samsung Gear S::::::
Since most folks are rooting their Gear S for the ability of adding Ringtones (which can be done via a pay app) and adding Notifications, Wallpapers, Watch Faces, you get it......
Once you have followed the awesome rooting guide contained here and you want to load some stuff:
Path for Ringtones:
/opt/share/settings/Ringtones/
Path for Notifications:
/opt/share/settings/Alerts/
Path for Wallpapers:
/opt/share/settings/Wallpapers/
Path for Alarm Sounds:
/opt/share/settings/Alarms/
I have placed both mp3 and off files and they both work fine. Sometimes when setting your applicable Alert/Notification/Ringtone and the file is a mp3, the sound will not play, no worries, it will when the Alert/Notification/Ringtone is invoked.
To load files (Choose appropriate folder listed above)
sdb root on
sdb shell ls /opt/share/settings/Alerts/ (Shows directory listing for /opt/share/settings/Alerts/ on the Gear 2)
sdb push NAMEOFFILE /opt/share/settings/NOTIFICATION_TYPE_FOLDER (ie /Alerts or /Ringtones)
Megaflop666 said:
Its all good, I decided to tear into some things and bricked the damn thing, so I am sitting here waiting (forever) for the original firmware to download so I can factory restore it. I was not even able to get into recovery, just download mode. LoL
Oh well, if flashing the original firmware doesn't fix it, i'll take it up to Tmo at 10am and get a new one.
Click to expand...
Click to collapse
It is SO hard to brick this device so you will be fine! If you get into the firmware failed to install screen you're still good to go. Like I said, I got to bootloops and thought it was dead but stock fixed everything.
No worries you're fine!
You'll be fine!
You will be fine. I've been able to restore from this screen using stock.
Um actually..... its easier. Connect your gear, drop your content into the right folders (eg; ringtones, alerts and such) and run the update script. done and done.
ipstack said:
::::::Just a quick dirty write-up of how to load sounds with your newly rooted Samsung Gear S::::::
Since most folks are rooting their Gear S for the ability of adding Ringtones (which can be done via a pay app) and adding Notifications, Wallpapers, Watch Faces, you get it......
Once you have followed the awesome rooting guide contained here and you want to load some stuff:
Path for Ringtones:
/opt/share/settings/Ringtones/
Path for Notifications:
/opt/share/settings/Alerts/
Path for Wallpapers:
/opt/share/settings/Wallpapers/
Path for Alarm Sounds:
/opt/share/settings/Alarms/
I have placed both mp3 and off files and they both work fine. Sometimes when setting your applicable Alert/Notification/Ringtone and the file is a mp3, the sound will not play, no worries, it will when the Alert/Notification/Ringtone is invoked.
To load files (Choose appropriate folder listed above)
sdb root on
sdb shell ls /opt/share/settings/Alerts/ (Shows directory listing for /opt/share/settings/Alerts/ on the Gear 2)
sdb push NAMEOFFILE /opt/share/settings/NOTIFICATION_TYPE_FOLDER (ie /Alerts or /Ringtones)
Click to expand...
Click to collapse
sbrownla said:
It is SO hard to brick this device so you will be fine! If you get into the firmware failed to install screen you're still good to go. Like I said, I got to bootloops and thought it was dead but stock fixed everything.
No worries you're fine!
Click to expand...
Click to collapse
I wasn't worried to begin with. It's dead, stock firmware flash didn't even fix it. New one will be here tomorrow afternoon. It'll be my third one since I first bought it done my kids drowned the first one. Lmao
Megaflop666 said:
I wasn't worried to begin with. It's dead, stock firmware flash didn't even fix it. New one will be here tomorrow afternoon. It'll be my third one since I first bought it done my kids drowned the first one. Lmao
Click to expand...
Click to collapse
Hm ... what was it doing when you tried to flash?!
I was working on changing some permissions, rebooted it and it never came back, don't even have recovery. From what tmo said, this has happened to other people on this watch
After breaking the screen on my phone I spent the following months reading about how to extract data. It all comes down to enabling ADB debugging and having your computer authorised. Usually this can be done from recovery and you're good to go. However, if you have a broken phone that is fully stock, with ADB disabled and with no custom recovery support then your data is as good as bricked. Such was the case with me when I broke my rare Samsung G360G. However, my phone was supported by CF-AutoRoot by Chainfire, and this gave just the opening I needed to go full wide.
Prerequisites:
Your phone needs to be supported by CF-AutoRoot. Check on there and the new site linked for support of your phone. If it's not there then you will need to download a stock ROM and use the CF-AutoRoot site tool to generate a root package for you. But that is outside the scope of this tutorial. This procedure has only been tested on Samsung. Your phone should have a minimal working charge.
https://autoroot.chainfire.eu/
This tutorial is also based on Linux. It should be translatable to Windows and Cygwin. But for simplicity I'll just use the method I used on Linux. However, if using Odin like I do, you'll need Windows to finish it off.
Aside from this it assumes files in are named in a particular format with a certain file format.
Tutorial:
1. First you need to download a CF-AutoRoot package for your phone. Won't get far without it.
2. Open up a terminal in Linux. We need to download some depends so enter this command:
Code:
sudo apt-get install android-tools-adb android-tools-fsutils
3. We need to extract the archive contents out. Create a suitable folder inside your home folder to build the patch in and cd to it. This uses an example file named CF-AutoRoot-example.tar.md5. Substitute with your actual archive name. Like so.
Code:
mkdir cfar-adb
cd cfar-adb
tar -xf CF-AutoRoot-example.tar.md5
4. There should be a recovery.img and a cache.img.ext4 extracted out. We just need to modify the cache.img.ext4. But first we need to convert it to a workable format. From a sparse to a raw image.
Code:
simg2img cache.img.ext4 cache.raw.ext4
5. We need to mount the cache image
Code:
mkdir cache
sudo mount -t ext4 -o loop cache.raw.ext4 cache
6. The big one. Doing the mod. So now we need to modify the cfar cleanup script. We need to insert commands on the end to enable ADB and add the key to authorise the computer. The following will do just that in this fashion.
a)
You will need to load in the cfar-cleanup.sh file inside the cfroot folder from the cache point mounted. Locate the end and paste the following lines before the reboot and exit commands on the end. Don't save yet.
Code:
echo -n 'mtp,adb' > /data/property/persist.sys.usb.config
mount -o remount,rw /system
echo '' >> /system/build.prop
echo 'persist.service.adb.enable=1' >> /system/build.prop
echo 'persist.service.debuggable=1' >> /system/build.prop
echo 'persist.sys.usb.config=mtp,adb' >> /system/build.prop
chmod 644 /system/build.prop
mount -o remount,ro /system
mkdir -p /data/misc/adb/
echo '' >/data/misc/adb/adb_keys
chmod 640 /data/misc/adb/adb_keys
b)
Load up the ~/.android/adbkey.pub file in a text editor and copy the entire contents in the clipboard. Now back at the script locate that last echo command you pasted into it and set the cursor just after the first single quotation mark. Now paste the clipboard in! This will add your key in. Make sure it's only between the single quotes with no extra characters or line feeds. The lines will naturally split if they don't fit on screen. Otherwise it should be good to go.
c)
Okay now save the file. The above will enable ADB and authorise your computer on the main Android system after the rooting script has done it's work. Before it reboots normally.
7. We need to unmount the cache so it's ready for use.
Code:
sudo umount cache
8. We need to convert the raw image back into a sparse image.
Code:
img2simg cache.raw.ext4 cache.img.ext4
9. Okay were almost done. Now we repack the files into a new Odin archive. Choose a suitable new filename. Like I have done here with my example file.
Code:
tar -H ustar -c recovery.img cache.img.ext4 > cfar-adb.tar
md5sum -t cfar-adb.tar >> cfar-adb.tar
mv cfar-adb.tar cfar-adb.tar.md5
10. The final step! So now the new package is ready for use. We just to use Odin and flash it to the phone. Save the package to a USB stick if needed.
a)
Reboot into Windows. Or you can run it virtualised from Linux. But I prefer to use the real things when dealing with things of a delicate manner and working blindly. Unplug your phone from the computer if connected. Now load up Odin in admin mode.
b)
Just to make sure pull the battery from your phone. Give it a few seconds then put the battery back in and click the back cover on. Now hold down volume down, then home key, and finally hold down power. Wait for the vibration. Then release power after a few moments. Finally release the other keys. At this point press volume up briefly. You should have just put your phone blindly into download mode. I've done this numerous times.
c)
Plug your phone into your computer. After a moment you should see Odin respond with a device added. Usually the phone can vibrate also when it connects giving more positive signs. If nothing happens disconnect the phone from the computer and retry the last step again to put it into download mode. Took me a few tries before I could do it blindly. It helps if you have a working Samsung to test it out on so you can see what happens before you can only feel it.
d)
Now in Odin press the PDA (or AP) button. Select the cfar-adb.tar.md5 package you made up. If the package is fine it will pass the md5 test. Now press the Start button and watch it go! If all goes well it will upload recovery, cache, give you a pass and then the phone will reset. At this point it will be in the process of being rooted, enable ADB, then reboot. If something goes wrong then you may need to go back and check all the patched files. Then rebuild the package again. But be careful, if the ADB has been enabled in the build.prop file one time, you don't want to add it in again and create duplicates, no matter how keen. Once I had it added the only other major problem I encountered was using the correct adb key.
e)
Hopefully now your phone is rooted, has ADB enabled and is booting up normally. Give it a few minutes. You can even see signs of life in Odin with adds and removes on USB activity. Your phone should also vibrate at times. And making noises is also a good sign.
1.1. So I just cranked it up to eleven. Open a Linux terminal again and give it a test. With your phone plugged in.
Code:
adb devices
If all goes well then adb will find your phone as well as list your device as authorised. You can now open shell to the inside. USB debugging is now enabled.
Conclusion:
Well I hope this helps those who have their app data stuck under a broken screen. As long as it was to type in this tutorial It still took me less time to write this tutorial than to learn all that was needed and apply it to my phone. This ends here but for you it may be only the beginning. A next step would be a screen mirroring app which I think is a must have for visual feedback. And USB debugging opens up these possibilities. One thing to be careful of, in a related issue, is that just because you can use adb and the phone is also rooted doesn't mean it will all work at once. If you are tempted to "su" it in an adb shell and get right in there then SuperSU will ask for permission on a blank screen. As will also happen if you try to do an adb backup, it will ask for confirmation on screen. So just expect to work with USB debugging blindly unless you already have a screen mirroring app installed. If you don't have one installed that is your next step.
And on that note. Good luck!
Hi there,
Your tutorial on how to achieve this on Linux looks real neat and complete. Unfortunately, i'm on Windows and i would like to know if you would be able to rewrite this totorial for a Windows user?
I've been reading online for about a week and i've never saw such a complete guide to help newbies to ADB to be able to retrieve data on their locked broken devices.
Cheers!
Hi RaiM1986 and thanks for your kind words. Yes I wrote it so it would be useful to newbies and seasoned hackers alike. Plus I needed to write down some instructions in case I need to do it all again.
Looking at the tutorial it is a bit Linux-centric. I don't know how well it would translate to Windows. Though there would be Windows version of the tools used the main problem would be mounting the filesystem image and making modifications without corrupting it. Because of things like Linux file modes.
However the following tools may be of assistance.
ADB tools:
https://wiki.lineageos.org/adb_fastboot_guide.html
Cygwin provides Linux tools if needed:
http://www.cygwin.com
simg2img:
https://github.com/KinglyWayne/simg2img_win
For mounting the ext4 image:
https://www.osforensics.com/tools/mount-disk-images.html
img2simg and other tools:
https://forum.xda-developers.com/showpost.php?p=49235638&postcount=5
For the ADB key it should be in %USERPOFILE%\.android and other spots I've read of are C:\Windows\System32\config\systemprofile\.android
In case any of the above fails, since I haven't tested them, the easiest alternative might be to just download a Linux live CD, boot it and do the steps inside. Of course any work is lost when you shut it down. You could also boot it in VM program running on Windows.
Amazing guide, Hypexed! The amount of work you put in to figure this out is incredible.
However, I'm stuck on step 6c, where I'm supposed to save the cfar-cleanup.sh file. It's not letting me save it at all, either within the mount point or to another location, it says that I don't have permissions to save the file. I tried the 'sudo chown' to change ownership to try to edit the permissions, but that didn't work either with it still saying I can't have access to the file. Any ideas? There is probably a simple solution, but this is my first time really using Linux so I'm a noob. I'm using Ubuntu 18.04.1LTS installed, not live, dual-booted with Windows, if that's important to know
SpinningQyarks said:
Amazing guide, Hypexed! The amount of work you put in to figure this out is incredible.
Click to expand...
Click to collapse
Thank you for noticing. It really was the culmination of months of hacking and cracking. Not to mention research. I decided I had to write a guide so I could document what I did in case I needed to do it again. And of course if it helped anyone else.
However, I'm stuck on step 6c, where I'm supposed to save the cfar-cleanup.sh file. It's not letting me save it at all, either within the mount point or to another location, it says that I don't have permissions to save the file. I tried the 'sudo chown' to change ownership to try to edit the permissions, but that didn't work either with it still saying I can't have access to the file. Any ideas? There is probably a simple solution, but this is my first time really using Linux so I'm a noob. I'm using Ubuntu 18.04.1LTS installed, not live, dual-booted with Windows, if that's important to know
Click to expand...
Click to collapse
Sorry you got stuck. I can see some issues in my guide. Especially after trying to do 6c again. First I notice I didn't specify where to store all the folders. Somewhere in the home folder obviously but it looks like you sorted that out fine.
I have tested a working solution to the permissions problem. In fact two:
1. Locate cf folder in the cache mount point on the desktop and go into it. Now right click in the window to bring up the context menu and select "Open as Root". Open up the editor as before.
2.. In the terminal run the editor as root. For example:
sudo gedit cfar-cleanup.sh
I've tested this on Mint which is a "relation" of Ubuntu so should work the same.
Now the original permissions should be left intact. I checked and they didn't have the execute bit set which is unusual. It may help here to save your work on the file to a place you can save to in the meantime. So you don't get stuck again. And then unmount your cache mount point, extract the raw image again as per step 4 and remount as per step 5, if the permissions need restoring. They really should be as they are originally set in the image.
Then continue through to step 6 and beyond as you were.
Good luck!
I attempted to unlock the bootloader on my 3rd gen Fire HDX 8.9 (apollo) running 4.5.5.3, but am stuck at the bulk mode stage. I can reboot the device and see the USB connection drop and present the partitions again when it comes back up in bulk mode, but I see nothing visible on the screen. Holding volume up + power results in the same as just the power button. Can anyone confirm if the aboot stage of the boot should present anything on the screen or not? Without knowing more about the system, my guess would be that if that was working, I would have gone back into either the system image or fastboot.
I ran draxie's get_code.sh script, and was able to successfully write out a file from my Linux laptop. I then rebooted into fastboot and forced the system into bulk mode. That's where I got stuck:
$ sudo dd if=~/lineageos/apollo/emmc_appsboot-14.3.2.3.2_user_323001720.mbn of=/dev/sde6
677+1 records in
677+1 records out
#also tried this step with version 13, no difference
$ sudo dd if=~/lineageos/apollo/apollo-twrp-3.0.0-0.img of=/dev/sde18
16249+1 records in
16249+1 records out
#I also tried this one from the TWRP site for an alternate recovery, just in case, but no change
#$sudo dd if=~/lineageos/apollo/twrp_soho/recovery.img of=/dev/sde18
# I also looked at parted for /dev/sde before the flash, just to make sure the partition numbers matched up with the Windows instructions I located for bulk mode, and everything seemed to match up.
Do I have the correct files?
fd832b67eb6b44d847ec8c105a6a56943dc36cf11306e0aec44980a0306c3878 apollo-twrp-3.0.0-0.img
12e536cd88887012b60ae20478c005b79538908b9dfd591fa5748038a4eecc61 emmc_appsboot-13.3.2.3.2_user_323001720.mbn
ce616bbd84e9b1a711583eafa6e0722a733b9f488857a78f8a3c2708fcc2fe21 emmc_appsboot-14.3.2.3.2_user_323001720.mbn
Any hints to narrow down the troubleshooting?
Thank you!
nexusguy4 said:
I attempted to unlock the bootloader on my 3rd gen Fire HDX 8.9 (apollo) running 4.5.5.3, but am stuck at the bulk mode stage. I can reboot the device and see the USB connection drop and present the partitions again when it comes back up in bulk mode, but I see nothing visible on the screen. Holding volume up + power results in the same as just the power button. Can anyone confirm if the aboot stage of the boot should present anything on the screen or not? Without knowing more about the system, my guess would be that if that was working, I would have gone back into either the system image or fastboot.
I ran draxie's get_code.sh script, and was able to successfully write out a file from my Linux laptop. I then rebooted into fastboot and forced the system into bulk mode. That's where I got stuck:
$ sudo dd if=~/lineageos/apollo/emmc_appsboot-14.3.2.3.2_user_323001720.mbn of=/dev/sde6
677+1 records in
677+1 records out
#also tried this step with version 13, no difference
$ sudo dd if=~/lineageos/apollo/apollo-twrp-3.0.0-0.img of=/dev/sde18
16249+1 records in
16249+1 records out
#I also tried this one from the TWRP site for an alternate recovery, just in case, but no change
#$sudo dd if=~/lineageos/apollo/twrp_soho/recovery.img of=/dev/sde18
# I also looked at parted for /dev/sde before the flash, just to make sure the partition numbers matched up with the Windows instructions I located for bulk mode, and everything seemed to match up.
Do I have the correct files?
fd832b67eb6b44d847ec8c105a6a56943dc36cf11306e0aec44980a0306c3878 apollo-twrp-3.0.0-0.img
12e536cd88887012b60ae20478c005b79538908b9dfd591fa5748038a4eecc61 emmc_appsboot-13.3.2.3.2_user_323001720.mbn
ce616bbd84e9b1a711583eafa6e0722a733b9f488857a78f8a3c2708fcc2fe21 emmc_appsboot-14.3.2.3.2_user_323001720.mbn
Any hints to narrow down the troubleshooting?
Thank you!
Click to expand...
Click to collapse
Suggest you PM @draxie as you have access to a Linux host. Using his 1-click script will be far easier than self (or another member) walking you through the manual method.
Relevent link: https://forum.xda-developers.com/kindle-fire-hdx/general/multi-platform-1-click-bootloader-t3241014
nexusguy4 said:
I attempted to unlock the bootloader on my 3rd gen Fire HDX 8.9 (apollo) running 4.5.5.3, but am stuck at the bulk mode stage. I can reboot the device and see the USB connection drop and present the partitions again when it comes back up in bulk mode, but I see nothing visible on the screen. Holding volume up + power results in the same as just the power button. Can anyone confirm if the aboot stage of the boot should present anything on the screen or not? Without knowing more about the system, my guess would be that if that was working, I would have gone back into either the system image or fastboot.
Click to expand...
Click to collapse
Situation normal. The screen should be pitch black in bulk mode.
And once there, you cannot boot to anything else until you wrote
back part of the bootloader that got erased.
nexusguy4 said:
$ sudo dd if=~/lineageos/apollo/emmc_appsboot-14.3.2.3.2_user_323001720.mbn of=/dev/sde6
$ sudo dd if=~/lineageos/apollo/apollo-twrp-3.0.0-0.img of=/dev/sde18
Click to expand...
Click to collapse
These command-lines are incomplete. You could check the forums for the right ones,
but I could also just tell you to add at least 'oflag=direct' if you want them to be effective.
1-Click uses this incantation (where $bd refers to the block device representing your HDX's
internal storage, in your case /dev/sde; and the positional parameters should be as follows
$1 - input file
$2 - partition number
$3 - input size (e.g. stat -c%s $1)
$4 - friendly name for input [completely irrelevant]):
Code:
bulk_flash() {
local d=$bd$2
echo Flashing $4 to $d
dd if=$1 of=$d bs=64k conv=notrunc oflag=direct
echo Verifying $d
cmp -n $3 $1 $d
}
nexusguy4 said:
Do I have the correct files?
fd832b67eb6b44d847ec8c105a6a56943dc36cf11306e0aec44980a0306c3878 apollo-twrp-3.0.0-0.img
12e536cd88887012b60ae20478c005b79538908b9dfd591fa5748038a4eecc61 emmc_appsboot-13.3.2.3.2_user_323001720.mbn
ce616bbd84e9b1a711583eafa6e0722a733b9f488857a78f8a3c2708fcc2fe21 emmc_appsboot-14.3.2.3.2_user_323001720.mbn
Click to expand...
Click to collapse
You do have the correct appsboot files for sure.
That TWRP version is too old for me to have kept
a copy, but I'd expect that to be correct as well.
1-Click can fix this for you, but you can also do it yourself,
if you like, just don't forget the extra parameter to 'dd'.
Also, make VERY sure you write BOTH aboot *and* TWRP
with the right command-line BEFORE you attempt to boot.
I was foolish enough to "test" if it was working when only
aboot was flashed properly, and there was no way to get
anywhere with that device afterwards, as I had no valid
recovery and the button-combo to get into fastboot does
NOT work until the device gets unlocked (but you need
fastboot access to enter the unlock code -> catch 22).
Thank you so much, both of you. That bulk flash routine and arguments was exactly what I needed. I have TWRP running now, tablet unlocked, and I expect to be able be able to manage this just like any other of my lineage devices..
If this performs as expected based on the hardware specs, I'll probably hunt down a few more of this same model. At that price, it's the perfect size for standalone displays for some equipment like oscilloscopes/scope cameras, patch loading to a modeling guitar amp, etc.
nexusguy4 said:
Thank you so much, both of you. That bulk flash routine and arguments was exactly what I needed. I have TWRP running now, tablet unlocked, and I expect to be able be able to manage this just like any other of my lineage devices..
If this performs as expected based on the hardware specs, I'll probably hunt down a few more of this same model. At that price, it's the perfect size for standalone displays for some equipment like oscilloscopes/scope cameras, patch loading to a modeling guitar amp, etc.
Click to expand...
Click to collapse
Glad you got it working. Keep in mind 3rd gen HDX devices do not support OTG. That means no tethered devices or storage. Only adb, mtp and fastboot transactions. There are no known workarounds. Everything must be onboard or communicate wirelessly.
draxie said:
Situation normal. The screen should be pitch black in bulk mode.
And once there, you cannot boot to anything else until you wrote
back part of the bootloader that got erased.
These command-lines are incomplete. You could check the forums for the right ones,
but I could also just tell you to add at least 'oflag=direct' if you want them to be effective.
1-Click uses this incantation (where $bd refers to the block device representing your HDX's
internal storage, in your case /dev/sde; and the positional parameters should be as follows
$1 - input file
$2 - partition number
$3 - input size (e.g. stat -c%s $1)
$4 - friendly name for input [completely irrelevant]):
Code:
bulk_flash() {
local d=$bd$2
echo Flashing $4 to $d
dd if=$1 of=$d bs=64k conv=notrunc oflag=direct
echo Verifying $d
cmp -n $3 $1 $d
}
You do have the correct appsboot files for sure.
That TWRP version is too old for me to have kept
a copy, but I'd expect that to be correct as well.
1-Click can fix this for you, but you can also do it yourself,
if you like, just don't forget the extra parameter to 'dd'.
Also, make VERY sure you write BOTH aboot *and* TWRP
with the right command-line BEFORE you attempt to boot.
I was foolish enough to "test" if it was working when only
aboot was flashed properly, and there was no way to get
anywhere with that device afterwards, as I had no valid
recovery and the button-combo to get into fastboot does
NOT work until the device gets unlocked (but you need
fastboot access to enter the unlock code -> catch 22).
Click to expand...
Click to collapse
The extra `dd` arguments saved me from my long black screen days.
Thank you!