No access, no copy, no way? - G4 Q&A, Help & Troubleshooting

I tried to copy the system image file (system.rooted.H81510c-EU.img = 4 GB) to a different location as the /data/media/0/ of
Code:
dd if=/data/media/0/system.rooted.H81510c-EU.img bs=8192 seek=55296 count=529920 of=/dev/block/mmcblk0
is obviously NOT available to me because I use device encryption. (/data unavailable) So I tried to find a way to replace /data/media/0/ with anything that maps to my external_SD Card (/mnt/media_rw/external_SD) as this is not encrypted (can be encrypted easily). The Send_Command.exe \.\\COM5 shell is NOT very helpful in even understanding if the SD_Card is mounted. Anyone knows anything about it?
Second I tried to, as I am rooted, to copy the system image file to any location the Send_Command.exe \.\\COM5 shell would be able to read from although the device is encrypted. This would have been a 2 step process of rooting, unrooting and encryption and re rooting but I wanted to try. Somehow despite having root rights I could NOT copy anything directly to /. Or any other folder available in the Send_Command.exe \.\\COM5 shell. Any files or folders I created where successfully created when NOT created in / but I could not copy the large image file. It always told me not enough space, which is not the case. Folders I created seemed to be vanished after a reboot.
Anyone can shine a light on this? Can’t I copy because the device is already encrypted, or can’t I copy because of SLELinux Security?
Third I tried to copy the image file via Push_File.exe \\.\COM5 system.rooted.H81510c-EU.img /tmp/system.rooted.H81510c-EU.img which seemed to work. Just to find out it started fine and then quickly failed. Maybe not enough space in /tmp or wrong Push_File.exe parameter?
Anyone can help me out here?
Best regards

since you are going to need to re-encrypt it after you root it anyway why don't you just decrypt it first and save yourself the hassle?

run id in the command shell. it'll show you have recovery selinux context, which is very limited. you cant do much which is why we are having to copy the whole system partition off the device and edit it remotely. I dont think you'll have much luck mounting the sdcard, but thats not to say you shouldnt try and post back if you succeed.

@diedemus
Because LG encryption is buggy and will not encrypt when rooted. (10a + 10b tested)
I run the id command successfully. So I do have the limited shell = recovery selinux and I am root. Any idea how to mount the sdcard when in recovery selinux context?
Is there a technical documentation of that shell? I couldn't find any. Help is greatly appreciated.
Sent from outer space using telepathy

With samsung there is a way to encrypt a rooted device.
Download terminal and launch
$su
Click to expand...
Click to collapse
the $ will become a #
Now type
pkill -KILL daemonsu
Click to expand...
Click to collapse
the# will become a $
Just after that (don't wait) go to encryption and encrypt the phone (it can take long time).

remixtech said:
With samsung there is a way to encrypt a rooted device.
Download terminal and launch
the $ will become a #
Now type
the# will become a $
Just after that (don't wait) go to encryption and encrypt the phone (it can take long time).
Click to expand...
Click to collapse
Interesting. I should try that one day. Only have one device left though, no more playing around [emoji2]
This development device was encrypted. LG devices can be unencrypted. Did NOT work. Device rebooted and never started decryption. Same as with encryption.
I did remove root, supersu, busybox everything AND tricked the LG RCT into thinking that the device was never rooted.
Decryption worked fine after that. I guess encryption will too. Why LG links device encryption and rooting is beyond me.
I should write a full guide one of this days on how to archive that.
This post was written on my rooted LG G4 with Xposed AND device encryption. So it is possible [emoji3]
Gesendet von meinem LG-H815 mit Tapatalk

fpsq said:
Interesting. I should try that one day. Only have one device left though, no more playing around [emoji2]
This development device was encrypted. LG devices can be unencrypted. Did NOT work. Device rebooted and never started decryption. Same as with encryption.
I did remove root, supersu, busybox everything AND tricked the LG RCT into thinking that the device was never rooted.
Decryption worked fine after that. I guess encryption will too. Why LG links device encryption and rooting is beyond me.
I should write a full guide one of this days on how to archive that.
This post was written on my rooted LG G4 with Xposed AND device encryption. So it is possible [emoji3]
Gesendet von meinem LG-H815 mit Tapatalk
Click to expand...
Click to collapse
Please do that. I come from Samsung and i would like to encrypt my device with XPosed !

Related

[HOW-TO] [GSM & CDMA] How to root without unlocking bootloader (for ITL41D to JRO03O)

[HOW-TO] [GSM & CDMA] How to root without unlocking bootloader (for ITL41D to JRO03O)
As of Oct 10, 2012: Google has patched this vulnerability starting with JRO03U. That is to say, this works on versions of ICS and JB from ITL41D to JRO03O inclusive. It will not work for JRO03U or newer. (My previous guide found here only worked on Android versions 4.0.1 and 4.0.2, i.e., ITL41D/F and ICL53F.
Once you have root, you can use segv11's BootUnlocker app to unlock your bootloader without wiping anything. Easy as pie!
Disclaimer: I take no credit for this exploit or the implementation of it. All credit goes to Bin4ry and his team. I just isolated the parts required for the GNex, modified it slightly and eliminated the script.
So, it looks like Bin4ry (with the help of a couple of others) has managed to find a way to exploit a timing difference in the "adb restore" command. See source here. (Although this may be old news to some, I hadn't seen it before a few days ago.) This is more for informational purposes, as having a Nexus device, we are able to backup our data, unlock the bootloader and restore the backup, so this is guide is not really that useful for most, but you still have those users who are scared to unlock their bootloader. It is useful however, for those with a broken power button, as it allows them to unlock their bootloader without the power button.
How this works
The way this works is as follows: the "adb restore" command needs to be able to write to /data to restore a backup. Because of this, we can find a way to write something to /data while this is being done. Now, Android parses a file called /data/local.prop on boot. If the following line exists in local.prop, it will boot your device in emulator mode with root shell access: ro.kernel.qemu=1. So, if we can place a file called local.prop with the aforementioned line in /data, once your device boots, it will boot in emulator mode and the shell user has root access, so we now can mount the system partition as r/w.
So what does this all mean:
You can now root any version of ICS and JB released to-date without having to unlock your bootloader (and without losing your data).
Moreover, you should now be able to root your device even if your hardware buttons are not working.
Additionally, this allows those who have not received an OTA update and want to apply it without having an unlocked bootloader or root to do so by copying the OTA update to /cache from /sdcard.
Notes:
1) Please read the entire post before attempting this.
2) This does not wipe any of your data, but I take no responsibility if something happens and you lose your data. Maybe consider doing a backup as per this thread before attempting this.
3) This assumes that you have USB Debugging enable on your device (Settings > Developer Options > Enable USB Debugging) and the drivers for your device installed on your computer. For the drivers, I would recommend you remove all old drivers and install these. If you don't know how to install them, or are having issues, look here.
4) This obviously needs to be done over ADB, as you cannot run adb in a terminal emulator on-device. If you do not have ADB, I've attached it in the zip (Windows and Linux versions). Unzip all files.
Step-by-step:
1) Download the attached files to your computer and unzip them;
2) Open a command prompt in that same directory;
3) Copy the root files to your device:
adb push su /data/local/tmp/su
adb push Superuser.apk /data/local/tmp/Superuser.apk
4) Restore the fake "backup": adb restore fakebackup.ab Note: do not click restore on your device. Just enter the command into the command prompt on your PC and press the enter key.
5) Run the "exploit": adb shell "while ! ln -s /data/local.prop /data/data/com.android.settings/a/file99; do :; done" Note: when you enter this command, you should see your adb window flooded with errors -- this is what is supposed to happen.
6) Now that the "exploit" is running, click restore on your device.
7) Once it finishes, reboot your device: adb reboot Note: Do not try and use your device when it reboots. Running this exploit will reboot your device into emulator mode, so it will be laggy and the screen will flicker -- this is normal.
8) Once it is rebooted, open a shell: adb shell
Note: Once you do step 8, your should have a root shell, i.e., your prompt should be #, not $. If not, it did not work. Start again from step 4. (It may take a few tries for it to work. Thanks segv11.)
Now we can copy su and Superuser.apk to the correct spots to give us root.
9) Mount the system partition as r/w: mount -o remount,rw -t ext4 /dev/block/mmcblk0p1 /system
10) Copy su to /system: cat /data/local/tmp/su > /system/bin/su
11) Change permissions on su: chmod 06755 /system/bin/su
12) Symlink su to /xbin/su: ln -s /system/bin/su /system/xbin/su
13) Copy Superuser.apk to /system: cat /data/local/tmp/Superuser.apk > /system/app/Superuser.apk
14) Change permissions on Superuser.apk: chmod 0644 /system/app/Superuser.apk
15) Delete the file that the exploit created: rm /data/local.prop
16) Exit the ADB shell: exit (May have to type exit twice to get back to your command prompt.)
17) Type the following (not sure if this is needed for the GNex, but it shouldn't matter): adb shell "sync; sync; sync;"
18) Reboot: adb reboot
19) Done. You now should have root without having to unlock your bootloader. If you want to unlock now, you can without wiping anything. See segv11's app linked at the beginning of this post.
Note: If you still do not have root access after doing these steps, redo them and add this step between 10 and 11:
10b) Change the owner of su: chown 0.0 /system/bin/su (Thanks maxrfon.)
I've done all. It installs supersuser app but the phone is not really rooted and apps that requires it doesn't work
Lorenzo_9 said:
I've done all. It installs supersuser app but the phone is not really rooted and apps that requires it doesn't work
Click to expand...
Click to collapse
Did you try opening the Superuser app?
What happens when you open an app that requires root? Do you get the request for su access?
You can open the app but whith apps that requires root there are no requestes and they don't... Even using root checker you see that you're not rooted
Lorenzo_9 said:
You can open the app but whith apps that requires root there are no requestes and they don't... Even using root checker you see that you're not rooted
Click to expand...
Click to collapse
Re-run the entire procedure again (including pushing the su and Superuser.apk files). When I had done it, I used the latest version of su and Superuser.apk, but when I uploaded the files in the attachment in post #1, I used the files that Bin4ry had in his package, which I assume are older. Regardless, re-download the attachment in the first post and try it again.
efrant said:
Re-run the entire procedure again (including pushing the su and Superuser.apk files). When I had done it, I used the latest version of su and Superuser.apk, but when I uploaded the files in the attachment in post #1, I used the files that Bin4ry had in his package, which I assume are older. Regardless, re-download the attachment in the first post and try it again.
Click to expand...
Click to collapse
Ok I'll do it and then I'll report you what happens. So now have you updated su and superuser.apk?
Lorenzo_9 said:
Ok I'll do it and then I'll report you what happens. So now have you updated su and superuser.apk?
Click to expand...
Click to collapse
Yes, I put the latest versions in the zip in the first post.
I can confirm that this works, and also that step 10b was not needed for me. This is the first time I have not used a toolkit so if I can do it, anyone can.
Running a Verizon Galaxy Nexus, this allowed me to update to the leaked Jelly Bean OTA with a locked bootloader. I first flashed stock 4.0.4 and locked the bootloader. I then used the exploit to gain root access, allowing me to apply IMM76Q and JRO03O OTA updates via stock recovery. (Rebooting between updates.) Thank you for creating a guide that this newb could easily understand and follow.
serty4011 said:
I can confirm that this works, and also that step 10b was not needed for me. This is the first time I have not used a toolkit so if I can do it, anyone can.
Running a Verizon Galaxy Nexus, this allowed me to update to the leaked Jelly Bean OTA with a locked bootloader. I first flashed stock 4.0.4 and locked the bootloader. I then used the exploit to gain root access, allowing me to apply IMM76Q and JRO03O OTA updates via stock recovery. (Rebooting between updates.) Thank you for creating a guide that this newb could easily understand and follow.
Click to expand...
Click to collapse
Thanks for confirming that step was not needed.
Thanks!
Bookmarked for future reference :good:
does it work on nexus 7 ?
dacc said:
does it work on nexus 7 ?
Click to expand...
Click to collapse
Yes, it should.
thans for quick response
Works fine for my GNex, big thanks! How about putting it into a script for non-advanced users here?
wictor1992 said:
Works fine for my GNex, big thanks! How about putting it into a script for non-advanced users here?
Click to expand...
Click to collapse
Glad you got it working!
As for putting it into a script, I could but I'd rather not. As with most of the guides that I have written up, I purposely do not put things into a script so that people would actually go through all the steps and, by doing so, maybe get an understanding of what they are actually doing, and hopefully learn something in the process. If I would have packaged it up into a script, a lot of the less experienced users would not even try to go through the steps -- they would just use the script, and no one learns anything yet again. See here for some discussion on one-click scripts. Granted, blindly following a step-by-step is not much better, but I have tried to put comments and explanations throughout to facilitate learning. It's about the journey...
P.S.: I would appreciate it if no one else posts a script in this thread.
efrant said:
P.S.: I would appreciate it if no one else posts a script in this thread.
Click to expand...
Click to collapse
can i make a script that just puts in big text "STOP USING TOOLKITS AND 1 CLICKS"
Zepius said:
can i make a script that just puts in big text "STOP USING TOOLKITS AND 1 CLICKS"
Click to expand...
Click to collapse
LOL! Yes, sure, that's one script I don't mind being posted. LOL!
Heh, fair enough. I think I'm learning a bit about adb
One question: I can't replace system APKs by installing them, it tells me that there is a signature conflict. How can I fix that? I thought it shouldn't happen after rooting. (I'm trying to install the "international" velvet.apk).
wictor1992 said:
Heh, fair enough. I think I'm learning a bit about adb
One question: I can't replace system APKs by installing them, it tells me that there is a signature conflict. How can I fix that? I thought it shouldn't happen after rooting. (I'm trying to install the "international" velvet.apk).
Click to expand...
Click to collapse
Let's try to keep this thread on-topic please.
But to answer your question, don't install the apk. Using a file explorer that has root access, copy it to /system/app (after making sure that system is r/w) and make sure the permissions are set to match the other apks in that directory.
when running adb after running the command where i tell it to restore fake restore and then while the "exploit" is running ikeep getting , in cmd, link failed, no such file or directory, and it just keep doing that. is this normal or did i do something wrong.
efrant said:
Let's try to keep this thread on-topic please.
But to answer your question, don't install the apk. Using a file explorer that has root access, copy it to /system/app (after making sure that system is r/w) and make sure the permissions are set to match the other apks in that directory.
Click to expand...
Click to collapse

Bricked AFTV1 - Is repair possible with hardware mod?

I feel like a bonehead cuz I bricked my FireTV by getting ahead of myself. This FTV came shipped with 51.1.3.0 and I have always had updates blocked in my router. I purchased a SD-card adapter and was able to gain root by injecting su into /system/xbin, Installed busybox, and all that fun stuff. Everything was going along just fine, until i tried to install RBox's boot menu/Recovery without fully understanding everything. Following a guide, I ran the full bootloader unlock script and it seemed to complete fine and FTV would still boot normally with root access. What I did next is the following, trying to install recovery I download the bootmenu.img file, uploaded it to my sd card and issued the following commands:
mount -o remount,rw /system
mkdir /system/boot
dd if=/dev/block/platform/msm_sdcc.1/by-name/boot of=/system/boot/boot.img
mount -o remount,ro /system
dd if=/sdcard/bootmenu.img of=/dev/block/platform/msm_sdcc.1/by-name/boot
exit
exit
adb reboot​My FTV restarted and has been stuck at the FireTV Logo every since. Not exactly sure where I went wrong. Did I have to downgrade before trying to install the boot menu? I did to the checksum test on the file before using it and it matched. Anyways, I tried factory reseting by holding the back/right remote control keys....no joy, tried the alt+prtsc+i keyboard procedure....nothing, tried a fastboot cable recovery.......got the drivers installed, firetv listed in devices using kindle usb driver, but although fastboot would connect and communicate to the FTV, it wouldn't respond to any fastboot commands.
I have the ability to gain direct access to the FTV's file system, but although my electronic skills are superb, my linux/android skills are quite lacking. When I disable the CPU and connect the flash to my Ubuntu 15 VMWare system via usb, I am able to mount up 6 linux partitions from the FTV. I explored around them, but don't want to go plowing through anything like a bull in a china shop until I have a direction to take from someone who actually knows what they are doing to get my beloved Firetv booting again. Any suggestions would be GREATLY appreciated. Thanks in advance.
Plug in the fire TV with a USB to USB to your PC. If the boot loader is fully unlocked you should be able to fastboot boot clockwork recovery and flash the rom that doesn't require boot menu.
{ParanoiA} said:
Plug in the fire TV with a USB to USB to your PC. If the boot loader is fully unlocked you should be able to fastboot boot clockwork recovery and flash the rom that doesn't require boot menu.
Click to expand...
Click to collapse
I mentioned in my OP that I have already tried this and although the fastboot drivers install correctly, the "fastboot devices" command returns nothing, and the "fastboot reboot recovery" command waits for about 10 seconds, then returns "no reply received by device". So this is a dead end and I guess the problem lies in the fact that my bootloader failed to unlock. I was also guessing that the solution would be to put the stock bootloader back onto the FireTV, but cannot figure out where it goes on the fire's 6 mounted partitions in linux using the soldered-in USB flash device. I can access the /system directory, but cannot locate the /dev/block/platform/msm_sdcc.1/by-name/boot folder where the bootmenu.img file was written to which caused the bricking. Any other ideas?
No I'm not that familiar with the partitions. @rbox would probably be the best one to answer this
Adaptel said:
I mentioned in my OP that I have already tried this and although the fastboot drivers install correctly, the "fastboot devices" command returns nothing, and the "fastboot reboot recovery" command waits for about 10 seconds, then returns "no reply received by device". So this is a dead end and I guess the problem lies in the fact that my bootloader failed to unlock. I was also guessing that the solution would be to put the stock bootloader back onto the FireTV, but cannot figure out where it goes on the fire's 6 mounted partitions in linux using the soldered-in USB flash device. I can access the /system directory, but cannot locate the /dev/block/platform/msm_sdcc.1/by-name/boot folder where the bootmenu.img file was written to which caused the bricking. Any other ideas?
Click to expand...
Click to collapse
boot is partition 10. You should be able to use gdisk on the mmc device to see the partition table with the partition labels.
rbox said:
boot is partition 10. You should be able to use gdisk on the mmc device to see the partition table with the partition labels.
Click to expand...
Click to collapse
Thank you for chiming in Rbox. I am in awe of your amazing work with FireTV and keep up the spectacular work!!!
Anyways, I wanted to attach a screenshot of my dead fireTV1's MMC partition layout, but becasue I am new here, the forum won't let me add a screenshot jpg. I used gparted because as I said before, I am a linux novice and couldn't get gdisk to show me what I wanted to. Partition 10 is labeled "boot", is 10MB in size, and shows up as having a file system type "Unknown". Should I dd the stock recovery file to this partition, or what do I need to do to undo these commands which bricked my device. (Which I am pretty sure due to the fact that I didn't get the bootloader unlocked correctly).
dd if=/dev/block/platform/msm_sdcc.1/by-name/boot of=/system/boot/boot.img
mount -o remount,ro /system
dd if=/sdcard/bootmenu.img of=/dev/block/platform/msm_sdcc.1/by-name/boot​Thank you so much for your help in advance!
Adaptel said:
Thank you for chiming in Rbox. I am in awe of your amazing work with FireTV and keep up the spectacular work!!!
Anyways, I wanted to attach a screenshot of my dead fireTV1's MMC partition layout, but becasue I am new here, the forum won't let me add a screenshot jpg. I used gparted because as I said before, I am a linux novice and couldn't get gdisk to show me what I wanted to. Partition 10 is labeled "boot", is 10MB in size, and shows up as having a file system type "Unknown". Should I dd the stock recovery file to this partition, or what do I need to do to undo these commands which bricked my device. (Which I am pretty sure due to the fact that I didn't get the bootloader unlocked correctly).
dd if=/dev/block/platform/msm_sdcc.1/by-name/boot of=/system/boot/boot.img
mount -o remount,ro /system
dd if=/sdcard/bootmenu.img of=/dev/block/platform/msm_sdcc.1/by-name/boot​Thank you so much for your help in advance!
Click to expand...
Click to collapse
You can just dd that boot.img in /system/boot back to the partition to undo what you did.
rbox said:
You can just dd that boot.img in /system/boot back to the partition to undo what you did.
Click to expand...
Click to collapse
That did the trick & my FTV is now booting and still has root and all my stuff just where I left it......you are the best!
Should I not even try to install boot menu/recovery? I thought i was on 51.1.3.0, but I just now checked and I am actually on 51.1.4.0. I ran the full bootloader unlock script right before I reflashed the recovery partition which bricked my fire. Is it because 51.1.40 is the version-of-no-return for installing recovery, should I have ran the partial bootloader unlock, or something else? Any advice? I am happy to have my Fire TV working again, but half the fun of this is learning and understanding what goes on inside and how it works. THANKS AGAIN!!!!!
Adaptel said:
That did the trick & my FTV is now booting and still has root and all my stuff just where I left it......you are the best!
Should I not even try to install boot menu/recovery? I thought i was on 51.1.3.0, but I just now checked and I am actually on 51.1.4.0. I ran the full bootloader unlock script right before I reflashed the recovery partition which bricked my fire. Is it because 51.1.40 is the version-of-no-return for installing recovery, should I have ran the partial bootloader unlock, or something else? Any advice? I am happy to have my Fire TV working again, but half the fun of this is learning and understanding what goes on inside and how it works. THANKS AGAIN!!!!!
Click to expand...
Click to collapse
You can't unlock that version. You should block updates and wait until I release TWRP and prerooted fireos5 roms.
hey rbox, quick question: once you release the prerooted fireos5 is it possible to dd recovey.img through hardware mmc to get the unlocked bootloader?
my firetv got bricked using supersu me and now i wonder what the best way is to bring it back alive..
Adaptel said:
That did the trick & my FTV is now booting and still has root and all my stuff just where I left it......you are the best!
Click to expand...
Click to collapse
Can you tell me the command wich give you finally the success ?
Another question by me is how to create a system.img from the bin files.
I know that there is folder in the bin-zip but how to create from them a system.img or how to create a valid stuck-recovery.img
Greetings by Idijt
I_did_it_just_tmrrow said:
Can you tell me the command wich give you finally the success ?
Click to expand...
Click to collapse
Certainly. The process I went through (using Ubuntu Linux 15 with Fire's eMMC chip connected via USB via hardware mod) is as follows (keep in mind I'm not a Linux genius but know enough to get by:
When eMMC is successfully connected, Ubuntu auto-mounted 6 partitions with partition names/ids that consisted of a long string of hex digits.
By looking around these ext4 partitions, I noticed that one of them was obviously the entire contents of the Fire's /system folder.
I navigated to /system/boot/ and saw that the boot.img file was in there. I right clicked on it, selected Properties to gain a full path of the files location and copied it
I installed and ran gparted partition editor to view the partition layout of the eMMC. There are a total of 20 partitions on fire's disk, (/dev/sdb1 through /dev/sdb20 on my system) but most of them aren't mounted because they use a non-linux standard file format).and as Rbox said. Partition 10 was 10.00MB in size, type=unknown, name=boot, and was located at /dev/sdb10 (on my system).
Now all I had to do was issue this command: sudo dd if=/<long string of hex digits described abouve>/system/boot/boot.img of=/dev/sdb10
Remove 4 wires soldered to Firetv, Solder CPU oscillator pads together, Reboot and Cheer​The fire tv rebooted fine and everything was good....but I do have an update with even more good news. I felt emboldened having access to my MMC ao since my software was on version 51.1.40, I was able to then follow the guide (EXACTLY) at http://solderwiresandplastic.com/20...the-amazon-firetv-to-achieve-root-privileges/​starting at "Step 2", and was able to successfully install the latest clockworkmod recovery, RBox's AWESOME boot menu, and install RBox's latest prerooted rom. This worked because I was on version 51.1.4.0 and the bootloader eFuse freeze occurred on 51.1.4.1 (so don't even think of trying the steps in this link if your box has 51.1.4.1 or higher on it. Hope this makes sense and helps in some way.
mrchrister said:
hey rbox, quick question: once you release the prerooted fireos5 is it possible to dd recovey.img through hardware mmc to get the unlocked bootloader?
my firetv got bricked using supersu me and now i wonder what the best way is to bring it back alive..
Click to expand...
Click to collapse
No. To unlock your bootloader you need an old version of the aboot partition. But if you're on the latest software, you will brick if you attempt to flash that old version.
thanks, good to know!
Sent from my iPhone using Tapatalk
Hello. I have a bricked fire tv because of supersu me. I've extracted a system.img from a working one via adb. My problem is, that i don't know how to install this on my bricked one with hardware mod (card reader). Any advice?
where did you find the 5.0.5 image i need it also , mines bricked also from super sume just waiting for EEMC chip to come in..
geist_patrick said:
Hello. I have a bricked fire tv because of supersu me. I've extracted a system.img from a working one via adb. My problem is, that i don't know how to install this on my bricked one with hardware mod (card reader). Any advice?
Click to expand...
Click to collapse
---------- Post added at 01:21 PM ---------- Previous post was at 01:18 PM ----------
[/COLOR]
geist_patrick said:
Hello. I have a bricked fire tv because of supersu me. I've extracted a system.img from a working one via adb. My problem is, that i don't know how to install this on my bricked one with hardware mod (card reader). Any advice?
Click to expand...
Click to collapse
think you could send me your img file thanks. as im on 5.0.5 firmware bricked also. thanks
Rootet system.img
https://drive.google.com/open?id=0B8P7DODeSgf8cmk5UUx4UUFXYkk

Modifying the /OEM partition?

Has anyone figured out how to edit the /OEM partition? I've tried through root Explorer and through adb shell Su via terminal
Sent from my Moto Z (2) using Tapatalk
If it's anything like /system it's mounted read-only.
If you're rooted and run Linux:
# adb shell
$ su
# mount -o remount,rw /OEM
... and see what happens.
I don't know if the phone is running SELinux or not, and if so you'll need more special steps. Find out with # getenforce
Quantumstate said:
If it's anything like /system it's mounted read-only.
If you're rooted and run Linux:
# adb shell
$ su
# mount -o remount,rw /OEM
... and see what happens.
I don't know if the phone is running SELinux or not, and if so you'll need more special steps. Find out with # getenforce
Click to expand...
Click to collapse
Aye, I attempted to remount like this but it will not work for some weird reason.
Sent from my Moto Z (2) using Tapatalk
elijahaf97 said:
Aye, I attempted to remount like this but it will not work for some weird reason.
Sent from my Moto Z (2) using Tapatalk
Click to expand...
Click to collapse
wipe it using twrp, and dont use it. remove the items from oem you wish to keep and migrate them to the /system where they need to go, set perms and enjoy.
OEM is read only and is mounted to google, and if you delete something it gets put back, just wipe that partition and enjoy lol
Team DevDigitel said:
wipe it using twrp, and dont use it. remove the items from oem you wish to keep and migrate them to the /system where they need to go, set perms and enjoy.
OEM is read only and is mounted to google, and if you delete something it gets put back, just wipe that partition and enjoy lol
Click to expand...
Click to collapse
Last time I wiped it I was unable to boot.
Sent from my Moto Z (2) using Tapatalk
elijahaf97 said:
Last time I wiped it I was unable to boot.
Sent from my Moto Z (2) using Tapatalk
Click to expand...
Click to collapse
that shouldnt be the case... again you can just move everything from oem to /system and match the perms 1st then wipe it and essentiall all would be good, may need to wipe cache/dalvik cache to rebuild data for apps after move.
You can't add data to oem, but I was able to remove items from oem in TWRP with a kernel that had verity removed and state still green. (The TWRP custom kernel on Oreo and Pantheon both have this option). I still kept safetynet status green as well doing it through TWRP. Be sure to mount oem first!
Doesn't work on latest stock, OEM r/o. Any thought?
If you're just trying to debloat then you can follow this guide.
Uzephi said:
You can't add data to oem, but I was able to remove items from oem in TWRP with a kernel that had verity removed and state still green. (The TWRP custom kernel on Oreo and Pantheon both have this option). I still kept safetynet status green as well doing it through TWRP. Be sure to mount oem first!
Click to expand...
Click to collapse
Can you explain how to mount /oem partition like you did? I cannot for the life of me mount it in twrp to remove unnecessary apps and keep safetynet good?
Latest Sprint firmware. Latest TWRP. Latest Magisk. Latest Pantheon 8.0 kernel. Any help is greatly appreciated.
Typically I use superSU. But Epic games just made the gamepad Fortnite compatible and I'd like to try it WITH some type of root (Magisk) that won't mess up the safetynet check, yet be able to still have most of my usual root freedom.
gokart2 said:
Can you explain how to mount /oem partition like you did? I cannot for the life of me mount it in twrp to remove unnecessary apps and keep safetynet good?
Latest Sprint firmware. Latest TWRP. Latest Magisk. Latest Pantheon 8.0 kernel. Any help is greatly appreciated.
Typically I use superSU. But Epic games just made the gamepad Fortnite compatible and I'd like to try it WITH some type of root (Magisk) that won't mess up the safetynet check, yet be able to still have most of my usual root freedom.
Click to expand...
Click to collapse
Haven't tried on Oreo. Only got it to work on nougat by forcing verity off and disabling encryption.
deleted ...

Trouble Restoring Backed Up Stock ROM & WiFi Won't connect using LOS 15.1

Most of my the question/topic was explained here.
@steadfasterX
Re the WiFi pls share also the boot logs (see LOS faq).
Click to expand...
Click to collapse
I couldn't pull a boot log from TWRP, I'd get "Sbin/sh: adb: not found". That output seems to be haunting a lot of my adb attempts, it appears when I try "adb sync" as well.
Ok the choose "format" data in twrp and try to boot first without your userdata backup into stock. Lemme know if that works.
Click to expand...
Click to collapse
I tried, I unfortunately get a solid wall of bootloop. I still have everything from my SALT backup in case anything may or may not be needed. I just had a though, could the problem be that this backup was from before I USUed my phone (I can't remember if I said that in the first place)?
emperordogma said:
Most of my the question/topic was explained here.
@steadfasterX
I couldn't pull a boot log from TWRP, I'd get "Sbin/sh: adb: not found". That output seems to be haunting a lot of my adb attempts, it appears when I try "adb sync" as well.
I tried, I unfortunately get a solid wall of bootloop. I still have everything from my SALT backup in case anything may or may not be needed. I just had a though, could the problem be that this backup was from before I USUed my phone (I can't remember if I said that in the first place)?
Click to expand...
Click to collapse
The confusing part is we talk about 2 different things here:
1) WiFi. This is related to LOS and so when asking for logs l always assume you're on LOS. TWRP must match the LOS version.
2) booting stock. To make TWRP work it must be the matching TWRP installed of your stock release. Is that the case? If not do that first.
So re stock. Its strange that it does not boot with formatted data. Could you also flash magisk here and then try to boot?
steadfasterX said:
The confusing part is we talk about 2 different things here:
1) WiFi. This is related to LOS and so when asking for logs l always assume you're on LOS. TWRP must match the LOS version.
2) booting stock. To make TWRP work it must be the matching TWRP installed of your stock release. Is that the case? If not do that first.
So re stock. Its strange that it does not boot with formatted data. Could you also flash magisk here and then try to boot?
Click to expand...
Click to collapse
1) I'll worry about the WiFi if/when I can get stock up and running. But I was/am using LOS 15.1 (here's the version "lineage-15.1-20210608-UNOFFICIAL-h812_usu"), and my TWRP was "twrp-3.4.0-PREVIEW-230_g4_O".
2) I downgraded my TWRP to "twrp-3.3.1-PREVIEW-196_g4_MM", and same result, I get to the LG screen and the notification light stays on, then nothing. When inputting these dd commands:
Code:
adb shell
dd if=/external_sd/boot.img of=/dev/block/bootdevice/by-name/boot bs=512
dd if=/external_sd/system.img of=/dev/block/bootdevice/by-name/system bs=4096
dd if=/external_sd/userdata.img of=/dev/block/bootdevice/by-name/userdata bs=4096
adb shell sync
When I put "adb shell sync" in I get "/sbin/sh: adb: not found"
I tried clearing the cache after I put it in, then tried formatting, as well as tried installing Magisk. And when mounting the data partition, everything seem to be there (hard to tell exactly since it's not the way I'm used to seeing it).
Edit: I just tried getting a boot log using:
Code:
adb pull /cache/debug/boot_lc_crash.txt
adb pull /cache/debug/boot_lc_full.txt
adb pull /cache/debug/boot_lc_kernel.txt
And the first one comes back with /sbin/sh: adb: not found
emperordogma said:
1) I'll worry about the WiFi if/when I can get stock up and running. But I was/am using LOS 15.1 (here's the version "lineage-15.1-20210608-UNOFFICIAL-h812_usu"), and my TWRP was "twrp-3.4.0-PREVIEW-230_g4_O".
2) I downgraded my TWRP to "twrp-3.3.1-PREVIEW-196_g4_MM", and same result, I get to the LG screen and the notification light stays on, then nothing. When inputting these dd commands:
Code:
adb shell
dd if=/external_sd/boot.img of=/dev/block/bootdevice/by-name/boot bs=512
dd if=/external_sd/system.img of=/dev/block/bootdevice/by-name/system bs=4096
dd if=/external_sd/userdata.img of=/dev/block/bootdevice/by-name/userdata bs=4096
adb shell sync
When I put "adb shell sync" in I get "/sbin/sh: adb: not found"
I tried clearing the cache after I put it in, then tried formatting, as well as tried installing Magisk. And when mounting the data partition, everything seem to be there (hard to tell exactly since it's not the way I'm used to seeing it).
Edit: I just tried getting a boot log using:
Code:
adb pull /cache/debug/boot_lc_crash.txt
adb pull /cache/debug/boot_lc_full.txt
adb pull /cache/debug/boot_lc_kernel.txt
And the first one comes back with /sbin/sh: adb: not found
Click to expand...
Click to collapse
Ok so first of all: adb shell sync must be executed from without the shell you're in. That wasn clear described. So in other words after the dd command you just need to write "sync". That's it. It will not give any output when finished.
So here the next steps:
Try to mount system in TWRP and browse with the file manager if there are any files in /system/apps .
Use bs=512 for all dd commands.
Share your stock boot img here.
What data do you need exactly btw? App data like settings etc? Or just specific files?
steadfasterX said:
Ok so first of all: adb shell sync must be executed from without the shell you're in. That wasn clear described. So in other words after the dd command you just need to write "sync". That's it. It will not give any output when finished.
So here the next steps:
Try to mount system in TWRP and browse with the file manager if there are any files in /system/apps .
Use bs=512 for all dd commands.
Share your stock boot img here.
What data do you need exactly btw? App data like settings etc? Or just specific files?
Click to expand...
Click to collapse
Ahhhh, I assumed everything I saw was in a "copy/paste" format so, I didn't think to even try to exclude the adb from it.
I was able to mount system, and browse apps, there was stuff in there.
I used the "bs=512" method, and it gave the same result. I'm starting to think I'm just boned honestly. I'll upload my boot.img here in a few (in case you see this before I do).
I was hoping I could back up my texts/call logs (I was able to salvage a few, but I'm missing about a months worth), properly backup WhatsApp, get my Nova settings, and make sure I'm not missing anything else (I had a list, but can't think of it now). And I was hoping by doing it, it would fix the annoying Wifi bug.
Edit 1: I don't think it's "bootlooping", because I read that you could boot into TWRP while it's doing it (if your timing is good), I tried and couldn't get into TWRP at all, it's "stone walling" at the LG screen.
Edit 2: My stock Boot.img
ok so .. the boot image you send is not from the STOCK ROM. That is from LOS it seems. Pls upload the stock one which you are trying to flash with dd
steadfasterX said:
ok so .. the boot image you send is not from the STOCK ROM. That is from LOS it seems. Pls upload the stock one which you are trying to flash with dd
Click to expand...
Click to collapse
Huh, I am not sure how that happened. I'm starting to wonder if after the first try with adb push if I was even using my Stock Boot.img, magisk must've messed with me (they said the recommend way to to patch a boot.img) and I got them mixed up? Or at least that's the only thing I can think of.
Anyways, this should be the right one. Boot.img
@steadfasterX
I was able to boot back to Stock using the correct boot.img, unfortunately I lost some very important WhatsApp texts because it had to "re-verify", but other than that, everything seems to be in order. My apologies for confusing us both with the wrong boot.img. When I was messing around with Magisk, I must've gotten the two confused. I won't know if the wifi is fixed in LOS until later (I have to wait a while before I can use WhatsApp again).
emperordogma said:
@steadfasterX
I was able to boot back to Stock using the correct boot.img, unfortunately I lost some very important WhatsApp texts because it had to "re-verify", but other than that, everything seems to be in order. My apologies for confusing us both with the wrong boot.img. When I was messing around with Magisk, I must've gotten the two confused. I won't know if the wifi is fixed in LOS until later (I have to wait a while before I can use WhatsApp again).
Click to expand...
Click to collapse
yea that was my assumption after seeing that wrong boot.img.. all users were able to boot STOCK this way so it was either a mistake or bad flash. glad you figured it out.
when your WiFi does not come back on LOS later attach the boot logs then.
cheers
steadfasterX said:
yea that was my assumption after seeing that wrong boot.img.. all users were able to boot STOCK this way so it was either a mistake or bad flash. glad you figured it out.
when your WiFi does not come back on LOS later attach the boot logs then.
cheers
Click to expand...
Click to collapse
Everything appears to be working fine now, including the WiFi (you were right about fixing it by going back to stock), which appears to be better than it was before! I decided to upgrade to Lineage 16, because you had just updated it recently so, best to stay where the active development is (or at least last update), in case anything goes wrong. Thank you so much for your assistance, sorry about mixing up the boot.imgs. And thank you continuing support for the G4 (in some capacity).
I also just found out my phone had "OEM Unlock" in the developer settings, so I don't think I needed to use USU (if I read about that tight), pretty annoyed with myself for not paying attention properly.
emperordogma said:
Everything appears to be working fine now, including the WiFi (you were right about fixing it by going back to stock), which appears to be better than it was before! I decided to upgrade to Lineage 16, because you had just updated it recently so, best to stay where the active development is (or at least last update), in case anything goes wrong. Thank you so much for your assistance, sorry about mixing up the boot.imgs. And thank you continuing support for the G4 (in some capacity).
I also just found out my phone had "OEM Unlock" in the developer settings, so I don't think I needed to use USU (if I read about that tight), pretty annoyed with myself for not paying attention properly.
Click to expand...
Click to collapse
If your device is not a h811 or h815 international(!) then this option in dev settings will just do.....nothing. If it would be THAT easy there were never the need for UsU so you did it all right
steadfasterX said:
If your device is not a h811 or h815 international(!) then this option in dev settings will just do.....nothing. If it would be THAT easy there were never the need for UsU so you did it all right
Click to expand...
Click to collapse
Then what the heck is the point of that button/switch??? I figured because mine was a frankenstien device that maybe almost all of them had it, or I just got "lucky".
emperordogma said:
Then what the heck is the point of that button/switch??? I figured because mine was a frankenstien device that maybe almost all of them had it, or I just got "lucky".
Click to expand...
Click to collapse
Its just there by mistake. Not by LG but the OEMs. The OEMs like verizon, etc are not doing a good job but that's not new..

Question Help with bootloop after editing settings file

Hey folks,
Last night I was editing a file located under "data/system/users/0/settings_ssaid.xml" and upon rebooting my phone, it's been stuck in a boot loop. I have an original copy saved in a different folder, but unable to access anything to replace it.
Is there any specific fastboot command I can run to swap the files (adb push, pull etc)? Only boot slot A is giving me an issue, and I was reading flashing system.img would be able to help, but I don't wanna do anything I'm unsure will wipe any of my data where I'd have to start over unless I've recovered some of that data first.
If I do have to flash any stock images, pls post the instructions for clarity.
Thanks in advance.
Assuming adb can actually access your device, while it's stuck in a boot loop (test this by running 'adb devices' and see if you receive a response)
You can run the following command to list all the files in your specific folder.
adb shell ls FILEPATH
Every file in your specific folder will be listed. You can then do the following to pull/push your file
adb pull FILEPATH
adb push FILENAME FILEPATH
Of course you need to place the file that you want to push in your ADB folder.
Mind though, that simply replacing your edited file with the backup might not solve your bootloop.
You can always look up available commands here
adb shell ls - Android ADB Shell Commands Manual
Morgrain said:
Assuming adb can actually access your device, while it's stuck in a boot loop (test this by running 'adb devices' and see if you receive a response)
Click to expand...
Click to collapse
Yes, I can access adb and my device while it's booting up, but once it reboots I lose connection. Unless I can interrupt the process I'd have to be very quick in my typing to copy files lol.
Even with the few seconds I have to type some commands to access the directory of the file I edited, I do get a permission denied error.
Would swapping to Slot B during boot allow me into the system, or even flashing the system.img file?
RetroTech07 said:
Yes, I can access adb and my device while it's booting up, but once it reboots I lose connection. Unless I can interrupt the process I'd have to be very quick in my typing to copy files lol.
Even with the few seconds I have to type some commands to access the directory of the file I edited, I do get a permission denied error.
Would swapping to Slot B during boot allow me into the system, or even flashing the system.img file?
Click to expand...
Click to collapse
No because your file is on /data.
The issue is that you can't push your file to /scard since (I guess) you can't even get beyond to the point where /sdcard is mounted.
So copying it from /sdcard will likely be too late in the boot process.
Pushing directly into /data does not work either as you would have to be root. In the old days you could run and in root mode but I'm not sure that is still possible.
Factory reset will work.
On devices with separate recovery partition it would be possible to change recovery to allow adb access to /data so then push old file via recovery... But I would not know how to do that on Pixel as recovery is s part of the boot partition.
So effectively, it's likely you're only solution is to do a full firmware flash along with wipe.
I would first try a full flash removing the -w to avoid the wipe. It may work.
TonikJDK said:
I would first try a full flash adding the -w to avoid the wipe. It may work.
Click to expand...
Click to collapse
Probably a typo, but I think you meant you need to "remove" the -w to avoid a wipe.
Lughnasadh said:
Probably a typo, but I think you meant you need to "remove" the -w to avoid a wipe.
Click to expand...
Click to collapse
Thank you! My post is fixed.
TonikJDK said:
I would first try a full flash removing the -w to avoid the wipe. It may work.
Click to expand...
Click to collapse
Ok, I'm rooted so to be sure I don't mess anything up, lol can you list the steps just as a precaution?
Obviously I'd be in fastboot / recovery mode, then perform a flash-all but remove the -w so as to not erase my data?
Once the system boots, all of my texts and setup should remain as is, or do I have to go and recover it?
Would I be able to install the OS again on the inactive slot to recover data, or does that not work that way?
RetroTech07 said:
Would I be able to install the OS again on the inactive slot to recover data, or does that not work that way?
Click to expand...
Click to collapse
Nope ... there is only 1 data partition, so even when you flash the OS to the inactive slot, it would still use the same data partition. Moreover, it is then likely to upgrade/convert some files on /data which might result in not being able to go to the previous version in the old slot.
RetroTech07 said:
Ok, I'm rooted so to be sure I don't mess anything up, lol can you list the steps just as a precaution?
Click to expand...
Click to collapse
See https://forum.xda-developers.com/t/...thout-wiping-data-and-retaining-root.4356065/
so, unfortunately doing a full flash without wiping data didn't work. I'm almost inclined to believe that if TWRP was available for the P6/P, that I could go and push the file I had saved back into the directory of where it was and save myself from this mess.
I'm kicking myself because I'm usually backing up my data before I modify any system files, but this one time I hadn't done so and I had Google's backup turned off at the time, so I'm gonna have to lose some text messages over the last few days with some folks I enjoy speaking to. I do have some saved from late last week, but nothing from the weekend up until now.
As you said you can access ADB while booting, why not push/remove/replace the file while booting, even if this takes multiple boots to perform all commands, it should work assuming you can also use SU, if you can't, none of the below will work.
Code:
adb push <backup file location> /sdcard
adb shell
su
rm data/system/users/0/settings_ssaid.xml
cp /sdcard/settings_ssaid.xml /data/system/users/0/
chmod 600 data/system/users/0/settings_ssaid.xml
I don't know why it's affecting your boot though, there's a .fallback file that the system should fall back to when the system notes that this file is corrupt.
If the above doesn't work, and you could try:
Code:
adb shell
su
rm data/system/users/0/settings_ssaid.xml
cp /data/system/users/0/settings_ssaid.xml.fallback /data/system/users/0/settings_ssaid.xml
If that doesn't work, try:
Code:
adb shell
su
rm data/system/users/0/settings_ssaid.xml
And reboot, but again, I don't know why you're bootlooping from this, that file shouldn't be integral to booting.
Also, if you need to back up your data, why not just boot to boot_b, if it's not causing you issues? You really shouldn't have to reset your device to fix one problem - you could do a /data & /sdcard pull while booted to boot_b, or just run something like Titanium & SMS backup/restore.
DanielF50 said:
As you said you can access ADB while booting, why not push/remove/replace the file while booting, even if this takes multiple boots to perform all commands, it should work assuming you can also use SU, if you can't, none of the below will work.
Code:
adb push <backup file location> /sdcard
adb shell
su
rm data/system/users/0/settings_ssaid.xml
cp /sdcard/settings_ssaid.xml /data/system/users/0/
chmod 600 data/system/users/0/settings_ssaid.xml
I don't know why it's affecting your boot though, there's a .fallback file that the system should fall back to when the system notes that this file is corrupt.
If the above doesn't work, and you could try:
Code:
adb shell
su
rm data/system/users/0/settings_ssaid.xml
cp /data/system/users/0/settings_ssaid.xml.fallback /data/system/users/0/settings_ssaid.xml
If that doesn't work, try:
Code:
adb shell
su
rm data/system/users/0/settings_ssaid.xml
And reboot, but again, I don't know why you're bootlooping from this, that file shouldn't be integral to booting.
Also, if you need to back up your data, why not just boot to boot_b, if it's not causing you issues? You really shouldn't have to reset your device to fix one problem - you could do a /data & /sdcard pull while booted to boot_b, or just run something like Titanium & SMS backup/restore.
Click to expand...
Click to collapse
I appreciate the help but I can't go back as I've already wiped everything minutes before you sent this. If I had the above commands sooner I would have loved to try, although I'm not really sure why this became an issue in the first place. I tried booting to slot B, using both patched and normal boot images but it wasn't working, unless I did something wrong.
All I remember is installing an app to edit UDID for individual apps that I've used in the past, but because it wasn't identifying root properly, to which I'm assuming is an Android 12 issue, I decided to follow instructions for manually editing such IDs in the file I edited in my OP.
After I rebooted, I remember the main system about to start and seeing the Google boot logo with a percentage # go all the way up to 90%, then that's where the boot loop started. My guess at this point is either the app or the file I edited caused an issue, because I did nothing else up until that point. What's odd, is that after I formatted the whole system and rebooted, I saw the same percentage appear on screen after installing the same app to see if that was the issue, but it booted fully just fine.
I was going to just keep fighting this and keep the phone the way it was until I could maybe fix everything, but figured there's nothing I could do at this point since trying a flash of everything failed. I was up until 5am last night and it's almost 4 am with me trying to fix this. I feel defeated and upset because I don't believe I had to wipe this in the first place, and could have likely saved all of my data. I didn't have Google's backup option turned on and hadn't backed up my text messages because I was dumb. I'm more upset with myself than the phone honestly.
RetroTech07 said:
I appreciate the help but I can't go back as I've already wiped everything minutes before you sent this. If I had the above commands sooner I would have loved to try, although I'm not really sure why this became an issue in the first place. I tried booting to slot B, using both patched and normal boot images but it wasn't working, unless I did something wrong.
All I remember is installing an app to edit UDID for individual apps that I've used in the past, but because it wasn't identifying root properly, to which I'm assuming is an Android 12 issue, I decided to follow instructions for manually editing such IDs in the file I edited in my OP.
After I rebooted, I remember the main system about to start and seeing the Google boot logo with a percentage # go all the way up to 90%, then that's where the boot loop started. My guess at this point is either the app or the file I edited caused an issue, because I did nothing else up until that point. What's odd, is that after I formatted the whole system and rebooted, I saw the same percentage appear on screen after installing the same app to see if that was the issue, but it booted fully just fine.
I was going to just keep fighting this and keep the phone the way it was until I could maybe fix everything, but figured there's nothing I could do at this point since trying a flash of everything failed. I was up until 5am last night and it's almost 4 am with me trying to fix this. I feel defeated and upset because I don't believe I had to wipe this in the first place, and could have likely saved all of my data. I didn't have Google's backup option turned on and hadn't backed up my text messages because I was dumb. I'm more upset with myself than the phone honestly.
Click to expand...
Click to collapse
Ah damn, I was too late!
The 90% thing sounds like the November Google Play services updated - mine updated yesterday and I got the same thing when I rebooted, maybe something between the two got corrupt.
Yeah, I get that, I've had more than my fair share of self inflicted (and not so self inflicted) problems that have lost me data but you live and you learn I suppose

Categories

Resources