Related
I just wanted to share a story of woe and redemption so that it doesn't happen to you.
As background, I had sim unlocked my phone using helroz's method a while back, and my phone has been working fine from team whiskey's early days till now. Recently, I was flashing my phone as most of us do. I noted that after flashing the dead horse kernel, my market was not working properly, so I decided to odin back to JFD. From there, I flashed Bionix, but afterward, noted that I wasn't getting any cell reception. After some investigation and several odins, I looked at my software info and found that my baseband was unknown. I flashed back to JFD however, and it worked fine. In fact, this was the only rom where the cell worked. The phone otherwise was functioning flawlessly, including wifi.
Further investigation showed that this has happened to others, and anecdotally, people have fixed it by odining over and over or doing some magic with their sim card. I did just that but to no avail. After some thinking, it occurred to me that maybe my /efs data was bad, so I took a look. Hitting *#06# showed the generic samsung IMEI while in JFD (it did not work in other versions as the baseband was not working), not my normal IMEI. That's odd. I still had the backup from trying to sim unlock it months ago. I tried to overwrite the /efs folder w/ my own, but I could not write it due to 'not enough space.'
Further investigation showed that indeed, my efs partition had been borked, and so I could not write data to it (I could copy however). The only way to fix this is by flashing/odin'ing a new partition. This only works if you have a backup, which I didn't. Basically, I had a fancy media player at this point.
I went ahead and looked on craigslist and found a vibrant w/ a broken screen, figuring I could swap out the guts. I immediately backed up the /efs folder and partition of the broken phone, just in case. On a whim, I tried to flash the efs partition from the broken phone to my phone. Lo and behold, the baseband came back. I was now able to write to that partition, so overwrote the /efs folder w/ my backup from before. My IMEI came back afterwards, and so now, I have 2 functioning vibrants. I'm not sure what data is stored in /dev/block/stl3, but I do know I was able to fix my phone using another phone's data. They both work w/ my sim, though I am unsure if they can connect simultaneously using different sims or if they are somehow cloned, but the IMEIs are different for sure.
The moral of the story is that this phone is nigh unbrickable and even when it doesn't boot, you can always try the jig. The only part of the phone you can't fix w/ a routine odin it seems, is the efs partition, so I would encourage everyone to make a backup and keep it safe. This is not done standard as an initiation into rooting and roms and such, but it should be. Normally, odin'ing a rom does not write to this area, but even w/o screwing with this, frequent flashing and odins can apparently corrupt it, leaving you high and dry. With this backup and odin, you could probably fix your phone from any jam.
Here are the relevant threads on how to do this:
http://forum.xda-developers.com/showthread.php?t=882039
http://forum.xda-developers.com/showthread.php?t=859914
Keep those backups safe!
Thank you for sharing ur experience, I recently noticed that my data speeds have gone down after unlocking my vibrant using the method you mentioned above.Damn, I get edge speeds when I am on a HSPA network. Dunno whats the problem,called up simple mobile,am not data throttled.Sigh..
Sent from my SGH-T959 using XDA App
man this is scary, but your phone still works at JFD right?
Sent from my SGH-T959 using XDA App
It didn't for a while. Now, both phones are fully functional. I had a copy of the /efs folder of my old phone, but not an image of the partition. The problem is, when the partition gets screwed, you can't write to it, making the /efs useless.
That's why I'm trying to get people to make the backup. It takes a few minutes, but can be a lifesaver. I do believe you can flash a foreign stl3 partition and overwrite the /efs like I did, but unless you had a friend, no one would share it w/ you as it contains their imei info. Better to just back up your own. And if you lose your /efs, game over.
How exactly do you back up a partition?
Very cool of you to post this up. Is there any reason to back up your efs partition if you have no reason to unlock?
<---backing it up anyway.
It's not the unlocking. It seems that over time, some people (such as myself) screwed up the efs partition by just flashing/odin'ing various roms. It shouldn't happen, but it does. Consider that no roms write to the stl3 layer, yet mine was working one day, then one odin later, it didn't. I'm sure the number of people this happens to is quite small, but when it happens, it happens. It's like a 6 mb backup which isn't that big of a deal.
It's better to be safe than sorry.
I did an experiment on my Galaxy Tab, that I move the /efs folder to memory card.
Soon I found the reception goes way worse (at least 10dBm less) and the serial number changed to 00000000, then I immediately copied (restore) the folder and everything was back to normal.
I tried to examine the files with hex editor but I found nothing spectular.
vnamee said:
It's not the unlocking. It seems that over time, some people (such as myself) screwed up the efs partition by just flashing/odin'ing various roms. It shouldn't happen, but it does. Consider that no roms write to the stl3 layer, yet mine was working one day, then one odin later, it didn't. I'm sure the number of people this happens to is quite small, but when it happens, it happens. It's like a 6 mb backup which isn't that big of a deal.
Click to expand...
Click to collapse
That's really weird. I've never really looked into the occurrence because I always assumed it was isolated only to those that did some weird hacking in an attempt to unlock, or to those that were developing and found themselves doing some nasty, nasty things.
I just created efs_dev-block-st13.img and efs-backup.tar.gz so hopefully I'm all safe and sound now.
Thanks again! Once I get beyond GPS stuff I find myself clueless.
draikz said:
How exactly do you back up a partition?
Click to expand...
Click to collapse
You need to read the two links in the OP and download adb. You also need root and busybox.
all you need is to root your phone, such as w/ superoneclick which will put busybox on there. Then all you need is adb.exe.
Open up a command prompt where adb.exe is located. You can adb su or just go adb shell and then su.
The only commands you need are:
cat /dev/block/stl3 > /sdcard/stl3.bin (backs up sector management layer of partition)
cat /dev/block/bml3 > /sdcard/bml3.bin (backs up block management layer of partition)
tar zcvf /sdcard/efs-backup.tar.gz /efs (tars /efs folder)
cp stl3.bin efs.rfs (just makes copy of stl3.bin to new name efs.rfs)
tar -cf efs.tar efs.rfs (makes an odin flashable tar of partition)
I kept a copy of stl3.bin, bml3.bin, efs-backup.tar, and efs.tar.
vnamee said:
all you need is to root your phone, such as w/ superoneclick which will put busybox on there. Then all you need is adb.exe.
Open up a command prompt where adb.exe is located. You can adb su or just go adb shell and then su.
The only commands you need are:
cat /dev/block/stl3 > /sdcard/stl3.bin (backs up sector management layer of partition)
cat /dev/block/bml3 > /sdcard/bml3.bin (backs up block management layer of partition)
tar zcvf /sdcard/efs-backup.tar.gz /efs (tars /efs folder)
cp stl3.bin efs.rfs (just makes copy of stl3.bin to new name efs.rfs)
tar -cf efs.tar efs.rfs (makes an odin flashable tar of partition)
I kept a copy of stl3.bin, bml3.bin, efs-backup.tar, and efs.tar.
Click to expand...
Click to collapse
I've got backups of stl3.bin, bml3.bin and efs-backup.tar.gz
When I try to make the partition an odin flashable tar it tells me: "No such file or directory".
You have to cd into the directory, or else it should be:
cp /sdcard/stl3.bin /sdcard/efs.rfs (just makes copy of stl3.bin to new name efs.rfs)
tar -cf /sdcard/efs.tar /sdcard/efs.rfs (makes an odin flashable tar of partition)
This is kind of old news, but nevertheless important.
Months ago in the Q&A section there were two threads about the importance of the EFS, and how a corrupted nv_data.bin and EFS can cause many problems including losing the ability to use a different carriers sim, yet nobody paid attention to those threads, but I thought the info was vital.
Would using ROM Manager and backing up your current rom, also backup the /efs?
vnamee said:
You have to cd into the directory, or else it should be:
cp /sdcard/stl3.bin /sdcard/efs.rfs (just makes copy of stl3.bin to new name efs.rfs)
tar -cf /sdcard/efs.tar /sdcard/efs.rfs (makes an odin flashable tar of partition)
Click to expand...
Click to collapse
Yeah, I did. I'll do it again and post up exactly what I type and put in. Maybe it's just operator error.
Here ya go.
It might have been operator error because that time I watched efs.tar get written to /sdcard
It should be efs.rfs, not efs/rfs. It's a file, not a directory.
SamsungVibrant said:
Would using ROM Manager and backing up your current rom, also backup the /efs?
Click to expand...
Click to collapse
Nandroid does not back up the /efs partition, at least not that I can tell. All those files in the backup folder are of the various partitions, and efs partition is not part of it.
The reason I made this thread to begin with is because when I had this problem, I looked high and low, and found scant info. In the future, if someone else has this problem, this will come up in a search and won't have some lame magical fix that may or may not work.
vnamee said:
It should be efs.rfs, not efs/rfs. It's a file, not a directory.
Click to expand...
Click to collapse
Pinky slip!!! For whatever reason, it took 3 tries but I finally got it to backup. Thanks for the help! I would never think to back this stuff up. Everyone does Nandroid's like crazy, which is good, but losing this stuff is losing your phone!
Excellent write-up vnamee thank you..........
I've been flashing N7 with no issues as recently as over the weekend. Today I tried to flash a new ROM and it failed. Tried a second, different ROM, same result. Do not know what I did. Any thoughts?
Error log would help greatly.
How do I get/generate the log? Haven't had to do it before.
Thanks,
Paul
The logs= errors displayed on the screen provided by the interface you use to flash the rom (recovery, computer...)
Does this help any?
TWRP V2.4.4.0
Updating partition details
E: Unable to open zip file
Error flashing zop
Updating partition details...
do I need to create a partition? Never get more details despite the tease.
Thanks,
First -
Try and download a different (NEWER) TWRP. Re-flash TWRP. Try again
or
Have you tried completely wiping the device? And pushing a ROM from ADB or using a USB OTG and Memory stick?
I had issues with my nexus becoming VERY unstable. Leading to issues.
I completely, and I mean completely, wiped. To the point that all that device basically had was a recovery, and a bootloader.
I proceeded to flash again, BOOM all fixed up.
Is there a new TWRP?
I did a factory restore after wiping everything thing, if that is what you mean?
It was working as expected last week, don't know what I did to screw it up
Boot recovery try the operation, choose advanced then copy log to sdcard. The paste the log results.
sent via electromagnetic radiation.
ibsk8 said:
Boot recovery try the operation, choose advanced then copy log to sdcard. The paste the log results.
sent via electromagnetic radiation.
Click to expand...
Click to collapse
Did this, and it said it copied but I am unable to locate it. It says 0\media\data But that folder structure doesn't exist, at least according to file expert
Will a complete wipe/restore create a partition?
pmgreen said:
Will a complete wipe/restore create a partition?
Click to expand...
Click to collapse
None of the instructions currently found in this forum alters the partitioning of the N7. Not fastboot & not the custom recovery, either.
You are chasing a red herring I think. That message you see is about the recovery performing a scan to check to see if there is a change in file systems (or partitioning of external devices) ... which might have occurred in preceding (custom recovery) operations, but didn't in this particular case.
pmgreen said:
Does this help any?
TWRP V2.4.4.0
Updating partition details
E: Unable to open zip file
Error flashing zop
Updating partition details...
Click to expand...
Click to collapse
Focus your efforts here; it certainly looks like a first-order problem.
bftb0 said:
None of the instructions currently found in this forum alters the partitioning of the N7. Not fastboot & not the custom recovery, either.
You are chasing a red herring I think. That message you see is about the recovery performing a scan to check to see if there is a change in file systems (or partitioning of external devices) ... which might have occurred in preceding (custom recovery) operations, but didn't in this particular case.
Focus your efforts here; it certainly looks like a first-order problem.
Click to expand...
Click to collapse
Think reinstalling TWRP would help? It was working fine so I'm a bit stumped what changed and why
pmgreen said:
Think reinstalling TWRP would help? It was working fine so I'm a bit stumped what changed and why
Click to expand...
Click to collapse
You can also soft-boot a recovery without actually flashing it, e.g.
Code:
fastboot boot custom-recovery.img
I suppose you could then poke around and see if it is having troubles mounting any of the normal partitions (/data, /system, or /cache). Look in the kernel boot log of the recovery (cat /proc/kmsg or "dmesg") to see if anything looks strange, etc.
There have been a couple of reports from folks who developed problems that looked like eMMC flash media errors - loss of partitions, failure to mount /data, et cetera. At the moment though, your symptoms are very generic and non-specific, as in "it doesn't boot".
I suppose you saw no errors at all reported on the screen during that stock-install-via-fastboot procedure?
bftb0 said:
You can also soft-boot a recovery without actually flashing it, e.g.
Code:
fastboot boot custom-recovery.img
I suppose you could then poke around and see if it is having troubles mounting any of the normal partitions (/data, /system, or /cache). Look in the kernel boot log of the recovery (cat /proc/kmsg or "dmesg") to see if anything looks strange, etc.
There have been a couple of reports from folks who developed problems that looked like eMMC flash media errors - loss of partitions, failure to mount /data, et cetera. At the moment though, your symptoms are very generic and non-specific, as in "it doesn't boot".
I suppose you saw no errors at all reported on the screen during that stock-install-via-fastboot procedure?
Click to expand...
Click to collapse
The only error is that it can't open the zip. I've tried downgraded TWRP, then upgrading back. Tried flashing the existing rom.
Nothing has worked. The N7 is functional, just will not allow me to flash
pmgreen said:
The only error is that it can't open the zip. I've tried downgraded TWRP, then upgrading back. Tried flashing the existing rom.
Nothing has worked. The N7 is functional, just will not allow me to flash
Click to expand...
Click to collapse
Well, if the source material can't be opened, then there is nothing to be flashed.
So maybe it is better to call this a "can't open files" problem instead of a "can't flash" problem.
Are there any special characters in the file name ... or spaces? If so, try renaming the file so the name only contains [a-z], [A-Z], [0-9] plus dash, underscore, and dot.
The other thing that can happen is if you drop a file in /data/media/0 as the root user, it will show up under /sdcard, but can't be read by non-privileged users via the /sdcard/ path. I'm not sure what the exact details are here - much less why this would effect the recovery (as you would expect everything to be running as root there) - but you can detect this problem by using a terminal emulator, and looking for differences in ownership or file permission:
Code:
$ su
# cd /data/media/0
# ls -ld *
use chown and chmod as appropriate to fix files as needed
bftb0 said:
Well, if the source material can't be opened, then there is nothing to be flashed.
So maybe it is better to call this a "can't open files" problem instead of a "can't flash" problem.
Are there any special characters in the file name ... or spaces? If so, try renaming the file so the name only contains [a-z], [A-Z], [0-9] plus dash, underscore, and dot.
The other thing that can happen is if you drop a file in /data/media/0 as the root user, it will show up under /sdcard, but can't be read by non-privileged users via the /sdcard/ path. I'm not sure what the exact details are here - much less why this would effect the recovery (as you would expect everything to be running as root there) - but you can detect this problem by using a terminal emulator, and looking for differences in ownership or file permission:
Code:
$ such
# cd /data/media/0
# ls -ld *
use chown and chmod as appropriate to fix files as needed
Click to expand...
Click to collapse
Thanks bftb, you are correct it's a can't open zip. No error than fail and it can't open the zip. It says updating partition but nothing changes
The file names are from the developers, once of which I recently successfully flashed. Tried coping the log to the SD card, but unable to find /data/media/0. Do I need to recreate a partition?
(FYI there was an auto-correct typo in my prior post - "su" not "such". Derp)
pmgreen said:
Do I need to recreate a partition?
Click to expand...
Click to collapse
No. (There is no way to do that with the tools we have anyway)
Unless what you mean by "recreate" is rebuild/reinitialize a filesystem in a partition - that's a possibility.
You need to try and figure out why you can't read files.
As a workaround, you can put files on a USB key (FAT formatted, not NTFS) and using TWRP access them by putting the USB key on the other end of a OTG cable.
Your posts are a bit vague - I can't even tell if you have tried other ROM files, whether you checked them to see if they are the correct size/checksum, etc.
pmgreen said:
Tried coping the log to the SD card, but ...
Click to expand...
Click to collapse
At this point, your best approach is still to follow the initial advice of 'ibsk8'. Look in the log file for any further details about errors that occurred.
The logs are typically in /cache/recovery/ or (while the custom recovery is running) in /tmp
Use "adb pull" to get the log file to your PC and have a look at it. If you can't find anything obvious in there, then cut-n-paste the file to http://pastebin.com and provide the link to us.
bftb0 said:
At this point, your best approach is still to follow the initial advice of 'ibsk8'. Look in the log file for any further details about errors that occurred.
The logs are typically in /cache/recovery/ or (while the custom recovery is running) in /tmp
Use "adb pull" to get the log file to your PC and have a look at it. If you can't find anything obvious in there, then cut-n-paste the file to http://pastebin.com and provide the link to us.
Click to expand...
Click to collapse
I am not familiar using ADB pull. Tried using a root file manager to access the log but don't see.
Greatly appreciate your help, let me know what other info I should paste.
Thanks,
EDIT: If you are coming here for the first time, this guide should still work, but @PorygonZRocks has created a flashable zip that should deal with a lot of these issues automatically. You can check out his post here:
https://forum.xda-developers.com/showpost.php?p=75787067&postcount=699
This method will indirectly allow you to root the LG Gpad v410 after it has been upgraded to Lollipop 5.1.1. Yes. Rooting LG v410 Lollipop. It's through a downgrade, but it works.
It took a while to get working, but here's how I did it. The process is straightforward, but the details matter greatly. You will brick your device if you mess up. Please read everything *first* before you do anything. Be sure you understand the process. I'll try to explain what's going on along the way.
An external SD card is extremely helpful for this process. You *could* adb push everything, but that will tedious.
First, you need some files.
The 4.4.2 KDZ which is a TEST OS, but it can be rooted and it downgrades to a Bump'able bootlaoder:
http://forum.xda-developers.com/g-pad-10/general/kdz-lg-g-pad-7-0-v410-t3224867
The LG 2014 Flash Tool:
http://www.mediafire.com/download/fwrcd3pdj0svjtb/LG_Flash_Tool_2014.zip
Android LG Drivers:
https://www.androidfilehost.com/?fid=24052804347802528
Parted for Android. You can probably find it other places, but I found this file:https://dl.dropboxusercontent.com/u/84115590/LG%20G2%2016GB%20Solution/sdparted-recovery-all-files.zip
EDIT: There seems to be a lot of confusion here. My bad. All you need is the file named "parted" from this zip file - nothing else. Just put that one file in the root of your external SD card.
https://dl.dropboxusercontent.com/u/84115590/LG G2 16GB Solution/sdparted-recovery-all-files.zip linked from here: http://www.**********.com/your-32gb-lg-g2-shows-only-16gb-storage-space-heres-the-fix/
EDIT2: The dropbox link is down. I've attached the file directly.
The Candy5 ROM (This will potentially save you some manual steps. Somewhat optional, but highly recommended):
http://forum.xda-developers.com/g-pad-10/development/rom-candy5-g-pad-v410-lollipop-5-1-1-v2-t3111987
Flashify APK:
http://www.apkmirror.com/apk/christian-gollner/flashify/flashify-1-9-1-android-apk-download/
TWRP for the v410:
http://forum.xda-developers.com/g-pad-10/development/recovery-twrp2-8-5-0lgv400-410-t3049568
LG One Click Root:
http://forum.xda-developers.com/lg-g3/general/guide-root-lg-firmwares-kitkat-lollipop-t3056951
(You may use Purple Drake or whatever else you want. They all use the same root script as this does and the GUI is helpful for novices.)
Android SDK (specifically adb.exe. After installing go to SDK Manager and ensure that Android SDK Platform Tools is checked):
http://developer.android.com/sdk/index.html
For clarification below, when I have commands in "quotes" they are Windows commands. When they are in `backticks` they are commands that you run inside of ADB which actually run on your device....as root. Root can screw things up. Please be extra cautious. If you blame me for messing up your device I will laugh at you. But that's not gonna happen, right? Good. Let's go.
Now that you have everything, put it all into a folder where you can access it easily.
Install the LG Drivers.
Install Android SDK (or otherwise get adb.exe).
Extract all of the archives.
Move the KDZ to the LG Flash Tool 2014 folder.
Put the tablet into Download Mode by powering it off, holding VolUp, and plugging in the USB cable. Press VolUP when instructed. You must be in Download mode before continuing.
Run LGFlashTool2014.exe. Select the KDZ file. Click "CSE Flash". Click "Start". Select "English" and click OK. Do not change anything else.
WAIT for the flash to continue. If you really want to brick your device, here's a good opportunity.
The device will reboot into Android 4.4.2. You will only have 4GB of internal storage at this point. DON'T PANIC! We are fixing it.
Enable USB debugging.
Connect the device.
Install and run LG One Click Root. Wait for the device to be rooted before proceeding.
Copy the Flashify apk, TWRP image, and Candy5 ROM to your external SD card.
Install Flashify and flash TWRP to the recovery partition.
Use the Flashify menu to reboot in to recovery.
DON'T PANIC! You will get white vertical lines on the boot screen from now on. They only show up during boot animations. A small price to pay. This may be fixed at a later date. for the time being! Thanks to marcsoup's first post ever, we have a fix! Details below. PLEASE click this link and thank him!
Things get tricky here. Copy parted to your external SD card and then run "adb shell" from Windows to get a shell in TWRP.
In TWRP, unmount /data by tapping Mount > uncheck Data.
`cp /sdcard/parted /sbin/` This copies the parted binary to /sbin so it can be executed in the path. I had trouble running `/sdcard/parted`, but YMMV.
`chmod +x /sbin/parted` Make it executable.
`parted /dev/block/mmcblk0` Run parted against the internal mmc
`p` Prints the partition table.
`rm 34` Deletes partition 34 labeled "grow". This is the root of our problem. The KDZ apparently only creates a 4GB partition, I assume so the test build has maximum compatibility with all sized devices.
`rm 33` Deletes partition 33 "userdata"
`p` Print to verify
`mkpartfs` Create a partition and put a filesystem on it. If we only expand the partition it won't help us because the filesystem is still only 4 GB.
a) name: userdata
b) type: ext2 (the tool only supports ext2. This is ok for now.)
c) start: 3439MB (the end of part 32. IT MAY BE DIFFERENT FOR YOU!) Be sure you do not omit the MB part otherwise the offset will overwrite another critical partition.
d) end: 15.8GB (where "grow" ended above. IT MAY BE DIFFERENT FOR YOU!) Be sure you do not omit the GB part otherwise the offset will overwrite another critical partition.
`p` Verify. For me it did not name the partition properly. Gotta fix that.
(if necessary) `name 33 userdata` This is critical for mount to find it in /dev/block/platform/msm.sdcc.1/by-name/ on some/all ROMS.
`p`. Verify one last time. Compare it to my partition table in the attachments. If you want to brick, delete some random partitions here.
Flash Candy5 with TWRP. It's only 239 MB, so it will flash quickly. I do this because Candy5 will reformat mmcblk0p33 from ext2 to ext4 for you. It does this as part of it's system boot, apparently. If you install a different ROM that does not do this, you can reformat it by running `make_ext4fs /dev/block/mmcblk0p33`. If your ROM does not have make_ext4, it likely has some differnt method to make an EXT4 filesystem. `/system/bin/mke2fs -t ext4 /dev/block/mmcblk0p33` may work better. Just flash Candy5 and be done with it.
Tap Wipe > Swipe to Factory Reset.
Tap Reboot > System.
WAIT!!! It will take a minute for the ROM to start the first time. You will have white lines and and possibly a white screen. WAIT. It's moving the DEX files to cache, formatting a partition, creating default folders on the internal storage, and several other things. WAIT! When the screen goes dim or turns off then it's ready.
Cycle the display or turn it on. You should be at the Candy5 lock screen.
USB debugging is on by default. Run "adb shell".
`mount | grep userdata` Make sure mmcblk0p33 is mounted.
`df` Make sure /data is 11.3 GB (or whatever size it is on non-16GB devices).
HELL YEAH, you downgraded, rooted, and fixed the partition problem. Enjoy your tablet!
Thanks to dopekid313 for finding the KDZ.
Thanks to timmytim for Candy5.
Thanks to the creators of the root script, flashify, TWRP, and XDA for being so awesome.
Thanks to marcsoup for fixing a fix to the white lines.
Thanks to navin56 for the partition dumps. PLEASE thank his post!
White lines fix.
What we are going to do is flash the aboot partition with the stock image provided by navin56. I've removed the extra files from the dump, so simply download aboot.img.7z below. Unzip it using 7zip.
These commands are to be run in TWRP. Reboot to TWRP recovery and connect with "adb shell". All of the following commands will be run in ADB under TWRP. If you cannot figure out how to get here, please post in the thread and someone will help you. Onward:
If you do everything correctly then you don't have to reflash your ROM and you won't lose data. This process can be done any time after flashing the KDZ, even before you follow the steps above to resize the userdata partition. It's a completely separate process.
Unzip aboot.img.7z so you have the file named aboot.img. You should also make sure that aboot.img's MD5 sum is e97431a14d1cee3e9edba513be8e2b52. Do not flash the 7z file. Please.
Copy aboot.img to your external SD card. It should live at /sdcard/aboot.img
Boot to TWRP and run "adb shell"
`ls -al /dev/block/platform/msm_sdcc.1/by-name/` Let's make sure we are flashing the right partition. On my device "aboot" is /dev/block/mmcblk0p6. You should verify this on your device or you WILL brick your tablet.
`dd if=/dev/block/mmcblk0p6 of=/sdcard/aboot-fukt.img` Let's back up our current aboot partition before we go flashing things just in case there are unintended consequences later. Be sure you have the same partition that "aboot" referred to in the 4th step or you have just backed up the wrong partition.
`dd if=/sdcard/aboot.img of=/dev/block/mmcblk0p6` Be sure the file exists, is the correct aboot.img, and you are flashing the right partition. You have been warned!!
Reboot TWRP and enjoy your boot animations again.
If I missed anything, please let me know. As far as I know this is the very first tutorial that details what is necessary to accomplish this. Please hit the Thanks button on every thread that you visit to download files!
FAQ:
Q: Why do I only have 11.3 GB of space when my device is 16GB?
A: The entire internal SD card (eMMC) is 16 GB. Gotta have someplace to install the bootloader, recovery, android, the modem OS, the secondary bootloader, the cache, the resource and power manager, and all of the other partitions necessary for the table to operate. Please look at the second screenshot in the OP. All of those 33 partitions take up room on the internal card. Fortunately ALL of those partitions ONLY take up about 4.4 GB. Hence the 'userdata' partition is ~11.3 GB.
If anyone wants to use my work to create a flashable zip to make it easier for novices, please do so. My problem is solved and I don't have the time to create the zip. Please post any questions and I'll gladly answer them! I'm so stoked that we have a usable downgrade method now!
Thank You, Worked Great
Thanks for making this I was gonna do it but was to lazy lol and thanks for linking my thread and giving cred instead of just linking straight to the kdz thank you
grandamle91 said:
Thank You, Worked Great
Click to expand...
Click to collapse
Glad to be of help!
dopekid313 said:
Thanks for making this I was gonna do it but was to lazy lol and thanks for linking my thread and giving cred instead of just linking straight to the kdz thank you
Click to expand...
Click to collapse
Of course! If you hadn't obtained the firmware then we'd all still be looking for a solution. It pisses me off to no end when people try to take credit for other people's work. We all just need to realize and acknowledge that we are simply standing on the shoulders of those who did the work necessary for each of us to do our work.
I just noticed since we formatted the userdata it screws up TWRP. It won't mount Data and it says the settings are corrupted
grandamle91 said:
I just noticed since we formatted the userdata it screws up TWRP. It won't mount Data and it says the settings are corrupted
Click to expand...
Click to collapse
Is this after you've rebooted into Candy5 and the partition is reformatted as ext4 (or you've done so manually)? TWRP may not be able to mount an ext2 partition.
EDIT: I just tested this. Following my instructions and flashing to Candy5, TWRP sees mmcblk0p33 (userdata) as the full size and mounts it at /emmc.
For clarification, after you run the parted commands, it will mess with the partition table and TWRP will most likely not be able to see it to remount it - at least not until after a reboot. This is why you need an external SD card from which to install ROMs.
/data not mounted
Edit: nevermind. The partition 33 was still ext2. I had to run make_ext4fs /dev/block/mmcblk0p33 and now I am able to mount /data. Thanks.
Thanks for taking the time to help us.
I followed the steps and till 33 I am good. But once I am in Candy5, I am not able to adb shell (adb not recognizing device eventhough usb debugging is on). I rebooted to recovery and adb works there. But my /data partition is not enabled in TWRP. I am not able to check it either under Mount in TWRP.
Code:
mount | grep userdata
is empty
Code:
df
does not show data
I tried this and my tablet bootlooped. I was able to get into fastboot and restore. I would GREATLY appreciate it if someone who has the time, would kindly donate their valuable time to into making an exe zip or something.
gridironbear said:
I tried this and my tablet bootlooped. I was able to get into fastboot and restore. I would GREATLY appreciate it if someone who has the time, would kindly donate their valuable time to into making an exe zip or something.
Click to expand...
Click to collapse
At what point did it bootloop? What was the last step that you took before rebooting?
Zip
I would really appreciate a zip file as I have never been savvy with adb and for whatever reason it doesn't want to work on Windows 10.
drumm3rb0y said:
I would really appreciate a zip file as I have never been savvy with adb and for whatever reason it doesn't want to work on Windows 10.
Click to expand...
Click to collapse
A zip file for what part? The only part that requires ADB directly is to fix the internal storage. You absolutely have to flash the KDZ and then root before you can do anything. If you are on 5.x then you have no possible way to root, much less flash a zip file.
If you tell me what exactly you are having issues with I will try to help.
fatbas202 said:
A zip file for what part? The only part that requires ADB directly is to fix the internal storage. You absolutely have to flash the KDZ and then root before you can do anything. If you are on 5.x then you have no possible way to root, much less flash a zip file.
If you tell me what exactly you are having issues with I will try to help.
Click to expand...
Click to collapse
The adb part is the part im having issue with. Everything else is flashed already. I was wondering if you could make a zip for the adb part so I can just flash it through twrp.
thanks for the great help. it did work perfectly to regain the lost space.
what about white lines ? is there any solution for that problem ?
I have tried flashing back stock recovery extracted from kdz, dd' but didn't help.
Now i am thinking of flashing back the aboot.bin extracted from original kdz or i can dump ".img" from another working device. (i have 4 similar devices)
what is your opinion i m not a developer and i need your advise. should i go ahead and which partition should i dd ? aboot or abootb or boot ?
regards
shahidmianoor said:
thanks for the great help. it did work perfectly to regain the lost space.
what about white lines ? is there any solution for that problem ?
I have tried flashing back stock recovery extracted from kdz, dd' but didn't help.
Now i am thinking of flashing back the aboot.bin extracted from original kdz or i can dump ".img" from another working device. (i have 4 similar devices)
what is your opinion i m not a developer and i need your advise. should i go ahead and which partition should i dd ? aboot or abootb or boot ?
regards
Click to expand...
Click to collapse
I have no solid evidence of this, but I suspect that the white lines are caused by a display driver issue where when the bootloader hands over control of the display to the kernel it doesn't get reinitialized properly. I have no ideas as to how to get rid of that at the moment but if I stumble across something I'll be sure to post here.
While I'm not an Android developer, I've been a Linux admin for 10+ years and have a lot of experience with Android devices. I'd be really hesitant to go flashing things ad hoc. While Download Mode may save you if you flash the wrong thing, I'm not entirely sure what the limitations that you may run in to with a locked bootloader are.
After having this device for months on 5.x and FINALLY being able to downgrade and run custom ROMs with root, not seeing a boot animation is a pittance to pay. But I'll keep looking.
i have same problem entered in TWRP but when ADB sheel thorough DP tools it didn't connect to my device. i m also using windows 10
Do I need to Re-mount Data ? I press format data button at TWRP and mount data. It looks work great.
After all process, it shows 16Gb total at storage, 11.04GB available. it works perfectly.
I need the stock V41010d, so I reflash the stock rom rooted at [ROM][STOCK](V410 ONLY)KOT49I.V4101d | 4.4.2 | Rooted + Busybox
Now, my Gpad is at stock V41010d, but I have a question about the boot screen, is it still with white lines and white screen? Any method to fix it?
Hello,
Thanks for the great work. unfortunately I am facing some difficulty, starting from step# 16 "Things get tricky here", how to run"adb shell in TWRP?
also can I use minimal_adb_fastboot_v1.1.3_setup.exe as mentioned in the link in the OP http://www.droidviews.com/your-32gb-lg-g2-shows-only-16gb-storage-space-heres-the-fix/ ?
also I noticed the path have been used includes 'parted' folder, but the folder I have after unzipping the parted zip called 'sdparted-recovery-all-files', do I rename the folder to 'parted' instead?
please help and excuse my broken English.
I'm also having trouble with the adb shell step. When my device is powered on normally, adb commands work. However, in TWRP mode my computer can't recognize the tablet, mount properly, and copy over parted. All the steps have been identical to this point. Any ideas?
iphone5sf said:
Do I need to Re-mount Data ? I press format data button at TWRP and mount data. It looks work great.
After all process, it shows 16Gb total at storage, 11.04GB available. it works perfectly.
I need the stock V41010d, so I reflash the stock rom rooted at [ROM][STOCK](V410 ONLY)KOT49I.V4101d | 4.4.2 | Rooted + Busybox
Now, my Gpad is at stock V41010d, but I have a question about the boot screen, is it still with white lines and white screen? Any method to fix it?
Click to expand...
Click to collapse
You shouldn't need to remount or format data. The parted command nukes the filesystem and creates a new one formatted as ext2. At this point the running kernel has the old partition table loaded and won't know that the partition has been extended. Simply flash Candy5 and reboot at this point and it will reformat the userdata partition.
See above for the white lines during the boot animation. Known issue, no fix in sight, doesn't really matter.
nmnm4alll said:
Hello,
Thanks for the great work. unfortunately I am facing some difficulty, starting from step# 16 "Things get tricky here", how to run"adb shell in TWRP?
also can I use minimal_adb_fastboot_v1.1.3_setup.exe as mentioned in the link in the OP http://www.droidviews.com/your-32gb-lg-g2-shows-only-16gb-storage-space-heres-the-fix/ ?
also I noticed the path have been used includes 'parted' folder, but the folder I have after unzipping the parted zip called 'sdparted-recovery-all-files', do I rename the folder to 'parted' instead?
please help and excuse my broken English.
Click to expand...
Click to collapse
You only need the sdparted-recover-all-files.zip from that site. "parted" is not a folder, but the binary (without a file extension) inside of that zip file. Copy that file to /sbin and you are in business.
zmali1 said:
i have same problem entered in TWRP but when ADB sheel thorough DP tools it didn't connect to my device. i m also using windows 10
Click to expand...
Click to collapse
summonholmes said:
I'm also having trouble with the adb shell step. When my device is powered on normally, adb commands work. However, in TWRP mode my computer can't recognize the tablet, mount properly, and copy over parted. All the steps have been identical to this point. Any ideas?
Click to expand...
Click to collapse
I'd recommend installing the SDK and pulling the drivers from that. Alternatively, you can try the drivers here: https://github.com/koush/UniversalAdbDriver.
Technically, when I ran the "parted" commands I was actually booted in to rooted 4.4.2 from the KDZ; I wasn't actually in TWRP. It's just not a very recommended way of going about it. I explained how to run all of this from TWRP, but there's no technical reason that you *can't* run this from Android. You just *shouldn't* because you can't cleanly unmount the filesystem and it theoretically could cause filesystem corruption. I just figured that I don't care about that partition getting corrupted since it's getting wiped out.
This guide will fix the issue of the wifi MAC address changing on every reboot that multiple people were having. I've tested this on T-Mobile, although it should work on the h850 as well. I've seen multiple people posting about this issue and I had the issue as well, do I decided to figure out how to fix it and wanted to share.
Step 1) Use root browser and go-to /data/misc/wifi/ folder.
Step 2) If you have a folder called config, delete it (it needs to be a file not a folder)
Step 3) Using a root browser go-to root of your sdcard (internal storage) and create a file called config (no extension), or use file I attached.
Step 4) Open the new file and put the following:
Code:
cur_etheraddr=5c:00:00:00:00:00
This will be your MAC address, change it to what you want your MAC address to be and save the file. If you downloaded attached file, put in root of your sdcard, open it and edit MAC address to what you want and save it without any file extension, I had to put as .Txt to upload it, just make sure to change to no file extension or it won't work.
Step 5) Open a terminal emulator (install one if you don't have one already) and run the following command:
Code:
su -c "cat /sdcard/config > /data/misc/wifi/config"
(and no you can't just copy the file to that location, it won't write)
Step 6) Reboot
This will give you a set MAC address even after reboot. Again fully tested on T-Mobile h830, but should work on h850 as well.
Nice guide, thank you
Once I figured out that the " at the end wasn't purely decorative (roughly 6 reboots later :laugh: ) I got it to work :highfive:
Now the MAC remains the same, but that stupid phone still refuses to use the IP my router is set to assign to it (192.168.1.199), it insists on using 192.168.1.100 unless I set a static IP in the phone's advanced wifi/router settings. I never had that problem with my S4 so I'm stumped ... I don't suppose you (or someone else) has any ideas how to fix that
Nimueh said:
Nice guide, thank you
Once I figured out that the " at the end wasn't purely decorative (roughly 6 reboots later :laugh: ) I got it to work :highfive:
Now the MAC remains the same, but that stupid phone still refuses to use the IP my router is set to assign to it (192.168.1.199), it insists on using 192.168.1.100 unless I set a static IP in the phone's advanced wifi/router settings. I never had that problem with my S4 so I'm stumped ... I don't suppose you (or someone else) has any ideas how to fix that
Click to expand...
Click to collapse
Happy it worked for you. Maybe I should put copy and paste exactly But as far as the other issue not sure, it should use whatever you set it to from router. Maybe later today I'll get a chance to do some testing and see if I can figure it out.
jeffsga88 said:
Happy it worked for you. Maybe I should put copy and paste exactly But as far as the other issue not sure, it should use whatever you set it to from router. Maybe later today I'll get a chance to do some testing and see if I can figure it out.
Click to expand...
Click to collapse
All my other devices (tablet, PC, my S4 when I still had it) play nice and use the IPs assigned by my router ... the G5 is the only one that refuses unless I set a static IP in the wifi settings. It's been like that from the start (I've had it since May) and it always wants to use that silly .100 IP ... no clue why
For now I've given up and opened the ports I need on the .100 IP ... without the MAC constantly changing that works at least. But yea, if you find a solution I wouldn't mind trying it
Thanks again for the MAC fix :good:
for all the people who have the MAC changing issue.. have you wiped your misc partition at some point?
these symptoms sound like what happens after misc is wiped.. and why wiping misc should only be wiped as a last resort.
tho if you are also running into this without ever wiping misc.. very interesting...
autoprime said:
for all the people who have the MAC changing issue.. have you wiped your misc partition at some point?
these symptoms sound like what happens after misc is wiped.. and why wiping misc should only be wiped as a last resort.
tho if you are also running into this without ever wiping misc.. very interesting...
Click to expand...
Click to collapse
It happens after formatting data partition on TWRP to remove encryption. Also when I clean flash Roms I always wipe everything as well as format data partition, so probably why as I'm sure that wipes misc partition (although I would think it wouldn't). I just did a clean install of RR wiping and then formatting data in TWRP and have changing MAC address again (have to re run steps above to fix). So why I'm thinking it has to do with formatting.
autoprime said:
for all the people who have the MAC changing issue.. have you wiped your misc partition at some point?
these symptoms sound like what happens after misc is wiped.. and why wiping misc should only be wiped as a last resort.
tho if you are also running into this without ever wiping misc.. very interesting...
Click to expand...
Click to collapse
If Misc gets wiped when installing custom roms then yes. My MAC has changed ... idk, I'm pretty sure from day 1 which means I tend to agree with @jeffsga88 that it happens when you format data after flashing TWRP
jeffsga88 said:
It happens after formatting data partition on TWRP to remove encryption. Also when I clean flash Roms I always wipe everything as well as format data partition, so probably why as I'm sure that wipes misc partition (although I would think it wouldn't). I just did a clean install of RR wiping and then formatting data in TWRP and have changing MAC address again (have to re run steps above to fix). So why I'm thinking it has to do with formatting.
Click to expand...
Click to collapse
Nimueh said:
If Misc gets wiped when installing custom roms then yes. My MAC has changed ... idk, I'm pretty sure from day 1 which means I tend to agree with @jeffsga88 that it happens when you format data after flashing TWRP
Click to expand...
Click to collapse
misc would only get wiped if you manually did it. a lot of people zero the misc after flashing the H830 custom TOT w/TWRP.
shouldn't get wiped from installing a rom or anything.
if you never did that, misc should be fine and I guess it's formatting /data as mentioned above.
autoprime said:
misc would only get wiped if you manually did it. a lot of people zero the misc after flashing the H830 custom TOT w/TWRP.
shouldn't get wiped from installing a rom or anything.
if you never did that, misc should be fine and I guess it's formatting /data as mentioned above.
Click to expand...
Click to collapse
I can't remember if I wiped misc or not, so I can't confirm or deny that I did or didn't, but it is entirely possible. At any rate, the solution fixed it for me. I was able to find my actual MAC address and set it in the config file. Now my router assigns the IP I want it to and the MAC doesn't change after reboot. Thanks for the instructions jeffsga88!!!
dbs179 said:
I can't remember if I wiped misc or not, so I can't confirm or deny that I did or didn't, but it is entirely possible. At any rate, the solution fixed it for me. I was able to find my actual MAC address and set it in the config file. Now my router assigns the IP I want it to and the MAC doesn't change after reboot. Thanks for the instructions jeffsga88!!!
Click to expand...
Click to collapse
It appears to be from formatting data to remove encryption. After doing this to fix it and then going in TWRP and formatting (not wiping) data I had same issue and had to redo fix. So just remember, if you format data in TWRP after doing this fix, you will need to redo the fix again. Just wiping and installing new ROM, the fix will stick.
@autoprime
Would the following command wipe the misc partition (I believe it does):
Code:
dd if=/dev/zero of=/dev/block/platform/624000.ufshc/by-name/misc
If so then that would explain things. This was one of the commands that we had to use if we got TWRP boot loop after flashing 10d rooted tot. That would explain why it started happening after rooting phone using 10D rooted tot. But then after using my fix and going into TWRP and formatting data (not wiping), why is it wiping misc again?
dbs179 said:
... I was able to find my actual MAC address and set it in the config file. Now my router assigns the IP I want it to and the MAC doesn't change after reboot. ...
Click to expand...
Click to collapse
How did you find your actual MAC address? I simply used the one that was shown at the time
jeffsga88 said:
@autoprime
Would the following command wipe the misc partition (I believe it does):
Code:
dd if=/dev/zero of=/dev/block/platform/624000.ufshc/by-name/misc
If so then that would explain things. This was one of the commands that we had to use if we got TWRP boot loop after flashing 10d rooted tot. That would explain why it started happening after rooting phone using 10D rooted tot. But then after using my fix and going into TWRP and formatting data (not wiping), why is it wiping misc again?
Click to expand...
Click to collapse
yes, that command you listed wipes the misc partition. It should be avoided when possible.. instead.. only wiping the things to stop getting stuck in TWRP etc. Many suggest the quick and easy "wipe the entire thing" method... but you can now see some of the results from doing that. Since the G2 and G3 days I've been suggesting otherwise - https://forum.xda-developers.com/lg-g3/development/fix-stuck-custom-recovery-trying-ota-t2907508
Command to safely get out of stuck TWRP would need to be updated for the G5:
dd if=/dev/zero of=/dev/block/bootdevice/by-name/misc bs=256 count=1 conv=notrunc
that would help some people stuck in TWRP (wont help those stuck in download mode.. they should just successfully flash a TOT/KDZ to stop phone from booting into download mode). And it may not work in every instance but should work in many.
As for "why is it wiping misc again?"...
it's not. you placed a file in /data/ to fix the issue.. then you are wiping /data/. why would the fix stay?
if you want a perm fix, fix misc and don't bother with your temp fix in /data/. Or perhaps update you're OP and include both (if my fix works.. but I believe it should) just so people have options.
Here's a 10-step MAC Fix (assuming you aren't using the "temp" fix in /data/)
1. backup/dump your misc partition:
dd if=/dev/block/bootdevice/by-name/misc of=/sdcard/misc-dump.img
or if in TWRP with encrypted /data use: dd if=/dev/block/bootdevice/by-name/misc of=/tmp/misc-dump.img to dump to the /tmp/ directory.
2. pull misc-dump.img from phone onto computer.
adb pull /sdcard/misc-dump.img
or adb pull /tmp/misc-dump.img
etc...
3. On computer, open up misc-dump.img in a hex editor. HxD is a decent free hex editor for Windows. Or use whatever.. hex editor is hex editor ( I use 010 Editor).
4. After opening the misc-dump.img in the hex editor you'll see the file in raw hex. Scroll down to offset 6000 for the Wifi MAC.
As seen in the picture below, the Wifi MAC is @ 6000h and is currently DE:AD:BE:EF:FE:ED, you will edit that section with your original MAC address instead (or current mac address you want to stick).
{
"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"
}
5. Now scroll down to offset 8000 for the Wifi MAC.
As seen in the picture below, the BT MAC is @ 8000h and is currently DE:AD:BE:EF:CA:FE, you will edit that section with your original MAC address instead (or current mac address you want to stick).
6. Save the edits made to the misc-dump.img. To be proper, select "Safe As.." instead of save and name the new file: misc-fixed.img
7. Push the fixed misc partition to your phone:
adb push /sdcard/misc-fixed.img
or... adb push /tmp/misc-fixed.img
8. Flash the misc-fixed.img on your phone to your misc partition:
dd if=/sdcard/misc-fixed.img of=/dev/block/bootdevice/by-name/misc
or.. dd if=/tmp/misc-fixed.img of=/dev/block/bootdevice/by-name/misc
9. Reboot phone, or boot into Android if in TWRP. Wifi/BT MAC should now be fixed.
10. Save misc partitions just in case. Ideally you want an untouched misc partition before messing with anything on your phone.. sort of like backing up your EFS first. But worst case.. you can use the steps above to fix Wifi/BT MAC address issues.
autoprime said:
yes, that command you listed wipes the misc partition. It should be avoided when possible.. instead.. only wiping the things to stop getting stuck in TWRP etc. Many suggest the quick and easy "wipe the entire thing" method... but you can now see some of the results from doing that. Since the G2 and G3 days I've been suggesting otherwise - https://forum.xda-developers.com/lg-g3/development/fix-stuck-custom-recovery-trying-ota-t2907508
Command to safely get out of stuck TWRP would need to be updated for the G5:
dd if=/dev/zero of=/dev/block/bootdevice/by-name/misc bs=256 count=1 conv=notrunc
that would help some people stuck in TWRP (wont help those stuck in download mode.. they should just successfully flash a TOT/KDZ to stop phone from booting into download mode). And it may not work in every instance but should work in many.
As for "why is it wiping misc again?"...
it's not. you placed a file in /data/ to fix the issue.. then you are wiping /data/. why would the fix stay?
if you want a perm fix, fix misc and don't bother with your temp fix in /data/. Or perhaps update you're OP and include both (if my fix works.. but I believe it should) just so people have options.
Here's a 10-step MAC Fix (assuming you aren't using the "temp" fix in /data/)
1. backup/dump your misc partition:
dd if=/dev/block/bootdevice/by-name/misc of=/sdcard/misc-dump.img
or if in TWRP with encrypted /data use: dd if=/dev/block/bootdevice/by-name/misc of=/tmp/misc-dump.img to dump to the /tmp/ directory.
2. pull misc-dump.img from phone onto computer.
adb pull /sdcard/misc-dump.img
or adb pull /tmp/misc-dump.img
etc...
3. On computer, open up misc-dump.img in a hex editor. HxD is a decent free hex editor for Windows. Or use whatever.. hex editor is hex editor ( I use 010 Editor).
4. After opening the misc-dump.img in the hex editor you'll see the file in raw hex. Scroll down to offset 6000 for the Wifi MAC.
As seen in the picture below, the Wifi MAC is @ 6000h and is currently DE:AD:BE:EF:FE:ED, you will edit that section with your original MAC address instead (or current mac address you want to stick).
5. Now scroll down to offset 8000 for the Wifi MAC.
As seen in the picture below, the BT MAC is @ 8000h and is currently DE:AD:BE:EF:CA:FE, you will edit that section with your original MAC address instead (or current mac address you want to stick).
6. Save the edits made to the misc-dump.img. To be proper, select "Safe As.." instead of save and name the new file: misc-fixed.img
7. Push the fixed misc partition to your phone:
adb push /sdcard/misc-fixed.img
or... adb push /tmp/misc-fixed.img
8. Flash the misc-fixed.img on your phone to your misc partition:
dd if=/sdcard/misc-fixed.img of=/dev/block/bootdevice/by-name/misc
or.. dd if=/tmp/misc-fixed.img of=/dev/block/bootdevice/by-name/misc
9. Reboot phone, or boot into Android if in TWRP. Wifi/BT MAC should now be fixed.
10. Save misc partitions just in case. Ideally you want an untouched misc partition before messing with anything on your phone.. sort of like backing up your EFS first. But worst case.. you can use the steps above to fix Wifi/BT MAC address issues.
Click to expand...
Click to collapse
Okay so that fix doesn't work for me, maybe due to already having a wiped misc partition? When opening the misc partition I pulled, both the 6000 and 8000 offset are blank, my guess from wiping it back when I rooted to get out of twrp boot loop. I tried adding the MAC address to both of those locations and I still have a changing MAC every boot (unless I use my temp fix). Not sure if there's a way to restore the misc partition or maybe get a copy from another device (although not sure that's a good idea or not, or does kdz restore misc partition?). Or could it possibly be at a different address? Also, yeah I forgot my fix was a temp fix to the data partition lol.
Nimueh said:
How did you find your actual MAC address? I simply used the one that was shown at the time
Click to expand...
Click to collapse
If you happen to have router logs from before this became an issue or if you had already previously set up MAC address filtering on your router for your G5, you would have the actual MAC address, otherwise don't think you'll find it without maybe taking apart the phone (that's if it's even printed on the board). Either way it shouldn't matter much as long as it's sticking between reboots.
jeffsga88 said:
If you happen to have router logs from before this became an issue or if you had already previously set up MAC address filtering on your router for your G5, you would have the actual MAC address, otherwise don't think you'll find it without maybe taking apart the phone (that's if it's even printed on the board). Either way it shouldn't matter much as long as it's sticking between reboots.
Click to expand...
Click to collapse
Yea, I don't have router logs or old filters going back to last May, so I'm sol :laugh:
I just figured there was some cool "press 14 buttons on the phone"-way to get the correct MAC or something ... I'll just stick with the one I have now
Oh and I flashed the RR Nougat rom yesterday ... now the phone insists on using the .104 IP and no longer the .100 it was so fond of on MM. I still can't get it do use the one the router wants to assign, guess I'll give up on that. No idea what LG did to this phone, neither the MAC addy nor the IP issue was one I ever had before on Samsung
Your MAC fix works on M and N btw, so thanks again :good:
Nimueh said:
Yea, I don't have router logs or old filters going back to last May, so I'm sol :laugh:
I just figured there was some cool "press 14 buttons on the phone"-way to get the correct MAC or something ... I'll just stick with the one I have now
Oh and I flashed the RR Nougat rom yesterday ... now the phone insists on using the .104 IP and no longer the .100 it was so fond of on MM. I still can't get it do use the one the router wants to assign, guess I'll give up on that. No idea what LG did to this phone, neither the MAC addy nor the IP issue was one I ever had before on Samsung
Your MAC fix works on M and N btw, so thanks again :good:
Click to expand...
Click to collapse
Yeah it appears that anyone on t mobile that got stuck in TWRP boot loop when trying to get root and then followed the steps in the 10D rooted tot section for getting out of boot loop ended up with this issue. One of the commands was wiping the whole misc partition, which wiped the MAC address and created the issue. Like autoprime said earlier, to get out of TWRP boot loop, shouldn't wipe whole misc partition. Maybe when wiping misc it also messed up something with proper IP addressing. Oh well, what's done is done, but at least we have a temp fix.
jeffsga88 said:
Yeah it appears that anyone on t mobile that got stuck in TWRP boot loop when trying to get root and then followed the steps in the 10D rooted tot section for getting out of boot loop ended up with this issue. One of the commands was wiping the whole misc partition, which wiped the MAC address and created the issue. Like autoprime said earlier, to get out of TWRP boot loop, shouldn't wipe whole misc partition. Maybe when wiping misc it also messed up something with proper IP addressing. Oh well, what's done is done, but at least we have a temp fix.
Click to expand...
Click to collapse
I'm neither on T-Mobile (I have the unlocked EU version) nor did I ever get stuck in TWRP or wipe the misc partition. In my case it must have happened when I formatted Data after rooting + flashing TWRP.
The temp fix is great indeed ... if you remember to re-do it after flashing a new rom :laugh:
Can we "paste" a command into Terminal Emulator? If so I'll probably put that whole command into a .txt file for easy copy/pasting in the future :angel:
Nimueh said:
I'm neither on T-Mobile (I have the unlocked EU version) nor did I ever get stuck in TWRP or wipe the misc partition. In my case it must have happened when I formatted Data after rooting + flashing TWRP.
The temp fix is great indeed ... if you remember to re-do it after flashing a new rom :laugh:
Can we "paste" a command into Terminal Emulator? If so I'll probably put that whole command into a .txt file for easy copy/pasting in the future :angel:
Click to expand...
Click to collapse
I thought some people with h850 had same issue but wasn't sure, good to know fix works for both the h850 and h830 models. Thought it was only happening after wiping misc partition but guess not then. As far as flashing new roms it should stick as long as you don't reformat data partition, although I personally always format data partition as well for a completely clean flash (I know it's not necessary, I'm just ocd lol). Also you could paste the commands into terminal emulator or use a program like 3c toolbox and use the script editor and make it into a script, then just run the script after first flash (just make sure you save script file to ext SD). And 3c toolbox has terminal emulator which allows you to paste the command into it as well.
jeffsga88 said:
I thought some people with h850 had same issue but wasn't sure, good to know fix works for both the h850 and h830 models. Thought it was only happening after wiping misc partition but guess not then. As far as flashing new roms it should stick as long as you don't reformat data partition, although I personally always format data partition as well for a completely clean flash (I know it's not necessary, I'm just ocd lol). Also you could paste the commands into terminal emulator or use a program like 3c toolbox and use the script editor and make it into a script, then just run the script after first flash (just make sure you save script file to ext SD). And 3c toolbox has terminal emulator which allows you to paste the command into it as well.
Click to expand...
Click to collapse
Yea I did a clean flash (coming from a Marshmallow to a Nougat rom) and when I checked my phone had picked a completely different MAC again.
I'll look into 3C and copy/pasting ... the next time I do any clean flashes. Thanks for the tip
jeffsga88 said:
Okay so that fix doesn't work for me, maybe due to already having a wiped misc partition? When opening the misc partition I pulled, both the 6000 and 8000 offset are blank, my guess from wiping it back when I rooted to get out of twrp boot loop. I tried adding the MAC address to both of those locations and I still have a changing MAC every boot (unless I use my temp fix). Not sure if there's a way to restore the misc partition or maybe get a copy from another device (although not sure that's a good idea or not, or does kdz restore misc partition?). Or could it possibly be at a different address?
Click to expand...
Click to collapse
hmm interesting. On previous LG devices this fix worked... I had just assumed it still would on G5.
Yes those offsets were blank due to wiping misc partition after using TOT to install TWRP/root (using recowvery to install twrp is now the superior method).
I might test out wiping my misc and trying to restore the MACs when I get some time to do that. Not sure why it isnt working.. unless there is more in the misc now besides those 2 addresses. And yes, those addresses should be correct.. I had checked a previously backed up H830 misc partition before posting to be sure. But I'll have to pull my current misc just to double check.
Nimueh said:
I'm neither on T-Mobile (I have the unlocked EU version) nor did I ever get stuck in TWRP or wipe the misc partition. In my case it must have happened when I formatted Data after rooting + flashing TWRP.
Click to expand...
Click to collapse
This is interesting... MAC issues without wiping the misc partition is new to me. Could you dump your misc partition and check the offsets to see if your Wifi and BT MAC are in your misc still?
Perhaps there is something tied to formatting /data as well.. like you both have mentioned doing.
I'll try looking into that as well.
I looked through the fixed vulnerabilities and found the stack corruption in the fastboot mode. Can it possibly get the TA party through it? Maybe someone guide me in right direction?
Use is extremely simple: run some like "fastboot flash dahdbachegwekjwekghkusbcekfyewkuwgkeufgwyfw4gfsmncqdbxvsffg some_file".
I've tested on XZP with latest firmware and think other models are also may be affected.
CVE-2017-11007
P. S. qdbxvsffg is mistake of forum, i can't delete it.
fastboot flash <random 59 chars string> some_file
This thread seems to be a great opportunity to remember and discuss this: backup of the TA partition on the latest devices (2017/2018)!
If I'm not mistaken, even if we somehow figured out a temp root, allowing us to backup (dd) TA (and/or any other partition) on locked BL, that would not be enough to allow us to relock BL again, nor to create a hack like we did with ta-poc, since both drm and unlock keys do not seem to be present in the TA partition anymore (maybe now inside at own bootloader... don't know)!! Would DRM-fix be our last hope from now on?
I would like to hear some enlightening words from the masters @munjeni @the_laser @sToRm// @tobias.waldvogel @zxz0O0 (everyone is welcome ofc)
Thanks in advance!
On the topic of possible exploits:
A user posted here that he's getting an error when attempting to flash the v47.1.A.12.119 partition SIN file. The error is "FAIL Command not authenticated" which suggests that it's requesting SAKE authentication.
The v47.1.A.2.374 firmware was the last one to have the LA1.1_O_77 bootloader (which is the BL version I'm on) and doesn't have a problem flashing the partition SIN. The v47.1.A.5.51 firmware, and all subsequent firmware versions, have the LA1.1_O_79 bootloader.
So that makes me wonder if they've blocked partition flashing in the newer bootloader to prevent a bypass of some sort.
What's new about the v47.1.A.12.119 firmware is that it has the partition SINs pre-extracted to a folder called partition, where they were previously contained in a zip file. So it's possible that nobody was flashing the partition SINs previously because Newflasher will only flash them if they are extracted.
It would be interesting if you can flash a set of partition data that allows access to a partition that isn't normally allowed.
For an extreme, but unlikely to be workable example, flash partition data that says the TA partition sectors are at the end of the userdata partition, then create a file table entry that encompasses that set of sectors.
pbarrette said:
On the topic of possible exploits:
A user posted here that he's getting an error when attempting to flash the v47.1.A.12.119 partition SIN file. The error is "FAIL Command not authenticated" which suggests that it's requesting SAKE authentication.
The v47.1.A.2.374 firmware was the last one to have the LA1.1_O_77 bootloader (which is the BL version I'm on) and doesn't have a problem flashing the partition SIN. The v47.1.A.5.51 firmware, and all subsequent firmware versions, have the LA1.1_O_79 bootloader.
So that makes me wonder if they've blocked partition flashing in the newer bootloader to prevent a bypass of some sort.
What's new about the v47.1.A.12.119 firmware is that it has the partition SINs pre-extracted to a folder called partition, where they were previously contained in a zip file. So it's possible that nobody was flashing the partition SINs previously because Newflasher will only flash them if they are extracted.
It would be interesting if you can flash a set of partition data that allows access to a partition that isn't normally allowed.
For an extreme, but unlikely to be workable example, flash partition data that says the TA partition sectors are at the end of the userdata partition, then create a file table entry that encompasses that set of sectors.
Click to expand...
Click to collapse
Guy who flashed partition forgot to move partition sin files to partition folder which gaved error "command not authentificated", it was error because instead of command "repartition" wrong command was set "flash" because partition files was in top folder with sin files which use command "flash". For partition flashing diferent command must be used "repartition".
munjeni said:
Guy who flashed partition forgot to move partition sin files to partition folder which gaved error "command not authentificated", it was error because instead of command "repartition" wrong command was set "flash" because partition files was in top folder with sin files which use command "flash". For partition flashing diferent command must be used "repartition".
Click to expand...
Click to collapse
Are you sure about that?
Look at the log he posted:
Repartition: partitionimage_0
Error, didn't got Repartition OKAY reply! Got reply: FAILCommand not authenticated
pbarrette said:
Are you sure about that?
Look at the log he posted:
Repartition: partitionimage_0
Error, didn't got Repartition OKAY reply! Got reply: FAILCommand not authenticated
Click to expand...
Click to collapse
I wrote about fastboot mode (led is blue) not flashmode (led is green). That message was about error in flashmode.
To go in fastboot you need poweroff the phone, push vol_up button and connect phone to PC.
kv123 said:
I wrote about fastboot mode (led is blue) not flashmode (led is green). That message was about error in flashmode.
To go in fastboot you need poweroff the phone, push vol_up button and connect phone to PC.
Click to expand...
Click to collapse
Yes, I know that.
Serajr, however, brought up the point that this would be a good thread to use for a broader discussion of possible exploits that could be used to access the TA partition.
Since I recently saw a situation which suggests that Sony may have blocked the ability to flash the partition table, I thought it warranted a mention here as opposed to being hidden on page-26 of a thread about VoLTE. Because if they have blocked that ability in a newer bootloader, it suggests that there's a way to alter the partition table in a way that Sony did not intend. And if that's true, it could open the door to accessing other partitions, including the TA partition.
pbarrette said:
Are you sure about that?
Look at the log he posted:
Repartition: partitionimage_0
Error, didn't got Repartition OKAY reply! Got reply: FAILCommand not authenticated
Click to expand...
Click to collapse
You mean this post? -> https://forum.xda-developers.com/showpost.php?p=76162897&postcount=769 It was what I talking about. That thing is fixed with latest v11 version, see -> https://forum.xda-developers.com/showpost.php?p=76163127&postcount=773 partition sucesfully flashed!
---------- Post added at 05:09 PM ---------- Previous post was at 05:07 PM ----------
pbarrette said:
Yes, I know that.
Serajr, however, brought up the point that this would be a good thread to use for a broader discussion of possible exploits that could be used to access the TA partition.
Since I recently saw a situation which suggests that Sony may have blocked the ability to flash the partition table, I thought it warranted a mention here as opposed to being hidden on page-26 of a thread about VoLTE. Because if they have blocked that ability in a newer bootloader, it suggests that there's a way to alter the partition table in a way that Sony did not intend. And if that's true, it could open the door to accessing other partitions, including the TA partition.
Click to expand...
Click to collapse
Sucesfully flashed partition table -> https://forum.xda-developers.com/showpost.php?p=76163127&postcount=773
One more thing, you can't flash modified partition sin file since its signed! All sin files is signed. Only maybe trought bootloader command "write_block", "read_block", maybe a chance for modifying partition table (in case not protected by sake authentification like it was protected to some trim area units like drm key unit...etc). List of command you can get inside LILO which lives in one of the sin files in bootdelivery, didn't remember name of the file but know only it was .img file format when unpack that sin file, inside that .img file inside ramdisk there is lilo file which is our bootloader, just decompile it and see what you need...
I know for sure about drm + unlock key (more about unlock key since I didn't found it on unlocked bootloader ta dump) is being outside trim area from 2017 and including 2018 models, and I'm believing booth drm key and unlock key is inside trust zone! Somehow I'm not believing which @the_laser says about drm key being deleted from trim area on android boot, its somehow nonsense, lets hope it is not true. Only a chance having that info for sure is soldering Easy Jtag Tool with emmc adapter directly to emmc pins and reading directly first partition while device is power down...
---------- Post added at 05:29 PM ---------- Previous post was at 05:09 PM ----------
pbarrette said:
Are you sure about that?
Look at the log he posted:
Repartition: partitionimage_0
Error, didn't got Repartition OKAY reply! Got reply: FAILCommand not authenticated
Click to expand...
Click to collapse
Can you give me link? I see now, instead of Repartition:0 wrong command is set Repartition: partitionimage_0 that might be again partition string changes. My tool use basename of the extracted file to send command e.g. 0.img and 0.cms, than basename of the file is 0 and command is xxx:0, but again where you saw that post? Can you post link? That thing would not cause problem since I have fixed that s o n y changes https://github.com/munjeni/newflasher/commit/a70e4984dc6863413043d2ce8bdd557879db5b69 , might be you found some old post?
device key ( unit 66667 ) is deleted from trim area only after rooting process completed.
munjeni said:
You mean this post? -> https://forum.xda-developers.com/showpost.php?p=76162897&postcount=769 It was what I talking about. That thing is fixed with latest v11 version, see -> https://forum.xda-developers.com/showpost.php?p=76163127&postcount=773 partition sucesfully flashed!
---------- Post added at 05:09 PM ---------- Previous post was at 05:07 PM ----------
Sucesfully flashed partition table -> https://forum.xda-developers.com/showpost.php?p=76163127&postcount=773
One more thing, you can't flash modified partition sin file since its signed! All sin files is signed. Only maybe trought bootloader command "write_block", "read_block", maybe a chance for modifying partition table (in case not protected by sake authentification like it was protected to some trim area units like drm key unit...etc). List of command you can get inside LILO which lives in one of the sin files in bootdelivery, didn't remember name of the file but know only it was .img file format when unpack that sin file, inside that .img file inside ramdisk there is lilo file which is our bootloader, just decompile it and see what you need...
I know for sure about drm + unlock key (more about unlock key since I didn't found it on unlocked bootloader ta dump) is being outside trim area from 2017 and including 2018 models, and I'm believing booth drm key and unlock key is inside trust zone! Somehow I'm not believing which @the_laser says about drm key being deleted from trim area on android boot, its somehow nonsense, lets hope it is not true. Only a chance having that info for sure is soldering Easy Jtag Tool with emmc adapter directly to emmc pins and reading directly first partition while device is power down...
---------- Post added at 05:29 PM ---------- Previous post was at 05:09 PM ----------
Can you give me link? I see now, instead of Repartition:0 wrong command is set Repartition: partitionimage_0 that might be again partition string changes. My tool use basename of the extracted file to send command e.g. 0.img and 0.cms, than basename of the file is 0 and command is xxx:0, but again where you saw that post? Can you post link? That thing would not cause problem since I have fixed that s o n y changes https://github.com/munjeni/newflasher/commit/a70e4984dc6863413043d2ce8bdd557879db5b69 , might be you found some old post?
Click to expand...
Click to collapse
The link was in my first post, but here it is again.
The next post in the thread is me asking him to flash the old bootloader to see if that allows the partition flash, but I never got a response.
This is on a XZ1c.
Previously, Sony firmware included the partition SIN files as a zip file. So if you wanted to flash them with Newflasher, you had to extract them to the partition folder yourself.
Starting with v47.1.A.12.119, there's no zip file anymore. Instead, there's a folder called partition and the partition SIN files exist inside it. So, if you're using Newflasher, you don't have to move or extract anything.
I also get that the images are signed. But, it looks like you have to:
1] Extract the signature and upload it.
2] Extract the data to be flashed and upload it.
So you're already feeding the signature separately from the data, as opposed to uploading the entire SIN file.
Is it possible that Sony made a mistake in the old bootloader? That the partition data gets flashed before the signature validation occurs?
There have been some CVE's against the Qcom bootloader for flash before validation issues, as well as flash OOB issues in the Android Security Bulletins.
I mean, Sony didn't change the bootloader in Nov-2017 for no reason.
I'd test it myself, but I'm on the old bootloader version with the bootloader still locked. So I don't want to flash the newer one at this time if it's possible that I won't be able to downgrade it. I almost got burned that way with my old Moto phone.
pbarrette said:
The link was in my first post, but here it is again.
Click to expand...
Click to collapse
It was 01.Apr.2018 but latest version of the newflasher is from 08.Apr.2018, it might work now as like already comfirmed.
pbarrette said:
The next post in the thread is me asking him to flash the old bootloader to see if that allows the partition flash, but I never got a response.
This is on a XZ1c.
Previously, Sony firmware included the partition SIN files as a zip file. So if you wanted to flash them with Newflasher, you had to extract them to the partition folder yourself.
Starting with v47.1.A.12.119, there's no zip file anymore. Instead, there's a folder called partition and the partition SIN files exist inside it. So, if you're using Newflasher, you don't have to move or extract anything.
Click to expand...
Click to collapse
Yes, no need to extract anything in case it is already inside partition folder.
pbarrette said:
I also get that the images are signed. But, it looks like you have to:
1] Extract the signature and upload it.
2] Extract the data to be flashed and upload it.
So you're already feeding the signature separately from the data, as opposed to uploading the entire SIN file.
Click to expand...
Click to collapse
It will not work since data is uploaded in chunks, every chunk is processed and in case you have modified any part of it entire process will fail, in worst case you get hardbrick.
pbarrette said:
Is it possible that Sony made a mistake in the old bootloader? That the partition data gets flashed before the signature validation occurs?
There have been some CVE's against the Qcom bootloader for flash before validation issues, as well as flash OOB issues in the Android Security Bulletins.
I mean, Sony didn't change the bootloader in Nov-2017 for no reason.
I'd test it myself, but I'm on the old bootloader version with the bootloader still locked. So I don't want to flash the newer one at this time if it's possible that I won't be able to downgrade it. I almost got burned that way with my old Moto phone.
Click to expand...
Click to collapse
Don't know but might be true.
---------- Post added at 03:47 PM ---------- Previous post was at 03:41 PM ----------
the_laser said:
device key ( unit 66667 ) is deleted from trim area only after rooting process completed.
Click to expand...
Click to collapse
But now booth keys is no more seen in trim area partition dump, which is not a case on pre 2017 models, on 2017 and up models e.g. after unlocking bootloader unlock key 0x8b2 is no more inside trim area as like it was a case on pre 2017 models. The same with drm. It might be that unit number is moved to some diferent number? Or booth stored in tz? On short search I'm unable to get anything in secd about 1046b or 8b2 or inside ta lib
device key ( unit 66667 ) still present in trim area and parsed by appropriate routines.
bootloader unlock key parsed by linuxloader.efi application and removed from trim area after parse as many other one-time keys ( remote lock reset, etc )
the_laser said:
device key ( unit 66667 ) still present in trim area and parsed by appropriate routines.
Click to expand...
Click to collapse
That mean with temp root we can dump drm key?
the_laser said:
bootloader unlock key parsed by linuxloader.efi application and removed from trim area after parse as many other one-time keys ( remote lock reset, etc )
Click to expand...
Click to collapse
But if it is removed from trim area than whats going on on next boot, its restored to trim area and again deleted? Somehow unclear and somehow nonsense for me. It might be that unlock key have backup key? But in that case where is that backup key stored?
munjeni said:
That mean with temp root we can dump drm key?
But if it is removed from trim area than whats going on on next boot, its restored to trim area and again deleted? Somehow unclear and somehow nonsense for me. It might be that unlock key have backup key? But in that case where is that backup key stored?
Click to expand...
Click to collapse
Yes, with temp root it's possible. Because with the drm fix (patched secd and the relevant libs) the system doesn't wipe the unit at boot (logs proof this). So there should be a way to dump the TA as backup (for future use maybe) and fix the security checks (like I did) in the relevant files while the device is running. After that, the device thinks it's not rooted and we can use it like a brand new device out of the box, but with root and modifications.
munjeni said:
That mean with temp root we can dump drm key?
Click to expand...
Click to collapse
yes, we can dump all high-area units, including device key
But if it is removed from trim area than whats going on on next boot, its restored to trim area and again deleted? Somehow unclear and somehow nonsense for me. It might be that unlock key have backup key? But in that case where is that backup key stored?
Click to expand...
Click to collapse
bootloader unlock key checked by linuxloader.efi, if correct - linuxloader.efi erase userdata, erase device key and modify DEVINFO partition ( set flag "critical unlocked" or "unlocked", whatever )
so, if dump raw trim area before bootloader unlock via exploit, then unlock bootloader and restore trim area dump back - we will get unlocked bootloader and phone with original drm keys.
of course, on next boot releases s1team could add check and erase device key from trim area if devinfo.unlocked true, but this is "could"
the_laser said:
yes, we can dump all high-area units, including device key
bootloader unlock key checked by linuxloader.efi, if correct - linuxloader.efi erase userdata, erase device key and modify DEVINFO partition ( set flag "critical unlocked" or "unlocked", whatever )
so, if dump raw trim area before bootloader unlock via exploit, then unlock bootloader and restore trim area dump back - we will get unlocked bootloader and phone with original drm keys.
of course, on next boot releases s1team could add check and erase device key from trim area if devinfo.unlocked true, but this is "could"
Click to expand...
Click to collapse
"could". That was a case on pre 2017 models, on newer models it is diferent now. Just dump your bootloader UNlocked trim area and search for unit 0x8B2, its not existent! I'm believing drm key too not exist inside LOcked trim area dump. Why I think that? I know, on old models, pre 2017, default case AFTER unlocking bootloader is: trim area gets totaly new unit 0x8B2 which is unlock key string. On new models, all after 2017, unit 0x8B2 NOT exist! Chech if you not believing me! I don't have new sony model but if I somehow decide to buy one (3 percent possible, I promised that I will never buy sony again because of its infinity unfriendly camera-audio-video proprietary libs) I will definitelly disasemble it and connect emmc tool to it and dump trim area and get thing confirmed. Now I not believing about drm unit is inside trim area, lets hope I am wrong.
you did not read my message - once again - linixloader.efi check if unlock key valid and delete it after check.
device key ( unit 66666 ) still in trim area, if you believe in it or not, this will not change how things works.
the_laser said:
you did not read my message - once again - linixloader.efi check if unlock key valid and delete it after check.
device key ( unit 66666 ) still in trim area, if you believe in it or not, this will not change how things works.
Click to expand...
Click to collapse
Ok, but where is 0x8B2 unit? Its gone? Thats a first diferent thing I have noticed. Don't know about 6667 but about 0x8B2 I know. Probably 0x8B2 is no more need, right?
you kidding, right ?
Code:
In order to enable locking/unlocking of the bootloader through
FG4, the xfl has support for oem lock/unlock commands. When executing
those commands, the xfl writes data in miscTA, which is then verified by
the boot on the next boot up, and if valid, the bootloader is locked or
unlocked respectively.
1. If MiscTA Unit 2226 (TA_RCK) is not empty, the boot SHALL check whether
unlocking of the bootloader is allowed.
If unlocking of the bootloader is allowed and the RCK is valid, the bootloader SHALL be unlocked.
Before unlocking the bootloader, the userdata and cache partitions, as well
as MiscTA Unit 66667 (TA_DEVICE_KEY) MUST be erased.
After unlocking the bootloader, MiscTA Unit 2550 (TA_MASTER_RESET) SHALL
be set to 0x2.
MiscTA Unit 2226 MUST be erased after the check.
2. If MiscTA Unit 2237 (TA_RESET_LOCK_STATUS) is not empty,
the boot SHALL validate whether the content of the unit is a valid CMS signed message.
If the message is verified, the bootloader SHALL be locked.
Before locking the bootloader, the userdata and cache partitions, as well as
MiscTA Unit 66667 (TA_DEVICE_KEY) MUST be erased.
After locking the bootloader, MiscTA Unit 2550 (TA_MASTER_RESET) SHALL
be set to 0x2.
MiscTA Unit 2237 MUST be erased after the check.
Not kidding! Dump an trim area for example from xz premium unlocked bootloader phone, and see, there is no unit 2226 (0x8b2)! Believe me!
Edit:
This is wrong:
MiscTA Unit 2226 MUST be erased after the check
Click to expand...
Click to collapse
Thas never worked that way! Unit 2226 IS NOT cleared after the check (at least on pre 2017 models), that unit keep bootloader unlocked! Erasing unit 2226 on e.g. xperia z1 compact giving bootloader unlock status "unknown", I can say that for sure! Lets make thing clear, you mean that for 2017-2018 models and NOT for pre 2017 models?