Related
GUIDE how to backup Verizon Developer Device aboot Partition
All Samsung Developer Devices are identical to retail devices with exception of one partition "aboot". What is all this fuss aboot? This partition holds the magic that unlocked your bootloader. It has a signed SHA256 key that a thousand Monkeys could not crack. If this partition is overwritten or corrupt the DE phone could brick, and bootloader will lock. Welcome to retail. This partition is device ID specific and coded to the device with super encryption. If this partition is backed up prior to corruption, it could be possible to restore a locked developer device. Some discussion of DE's aboot here and here
As of this writing several DE owners were smart enough to backup aboot, several were able to restore their unlocked bootloader. They were able to restore with the help of several XDA devleopers that were able to take the pre-saved aboot, and make it into an Odin flashable tar. It was reported that EFS Professional could create an Odin flashable aboot.tar.gz, that doesn't need any prior modifications. This info was incorrect, all backups of aboot will require modification prior to flashing. If you accidentally "Retail" your DE, post to this thread, and myself or one of the other devs will fix your backup. There is risk involved with restore, so please don't perposly flash your device to retail.
(No you can't flash aboot on your retail phone)
There are several ways to backup this unique partition, these procedures are not real difficult, but care should be taken. One method is by using ADB. Big learning curve, but rewarding. install Google SDK and use ABD [ADB Guides] Setup and run ADB, and backup the partition using dd command. This is a computer to Android terminal interface via USB. If you have used Linux scripts, this should easy peasy once ADB is functional. Copy and paste a script to copy aboot to SD, and the rest of the partitions using the ADB Method below.
You could even copy aboot to your phone's SD using your recovery file editor, or use ADB pull (permissions, mount, could make this tough though).
There is a cool program built by XDA contributor @lyriquidperfection, it's called EFS Professional It is a very powerful tool, it runs on windows computers, and uses a GUI, no scripts, just point and, click, click, click Easy Method.
Both interfaces require ROOT, and use Busybox. SuperSU, and busybox must be installed on your device prior, as well as Samsung drivers (Direct link to VZW Note 4 DE )
I like BusyBox Tools by Stephen (Stericson), or try Busybox On Rails
Disclaimer: If you are careful, study a bit, and follow direction closely there isn't much risk. Please be careful, these tools are capable of bricking your phone if you blindly explore other commands. If you run into problems, Post to this thread, someone will help you. If you go poking around the advanced user commands and mess it up, good luck. Don't hate on me if you do something stupid.
1. ADB Method Here is a quick guide that I made while backing up my note-4 DE. I point out the path to the partitions on Note-4. The VZW note-4 aboot partition is mmcblk0p7 This location and partition number are different in other DE models. This backup will need to be made flash-able if it's ever needed.
2. EFS Professional Easy Method (This guide will work for the other developer devices too. Tested on Note-3 & Galaxy S5 Developer Editions)
Download EFS Professional on windows computer, install EFSProfessional. This program has an imbedded version of ADB built in (don't run any other ADB programs at the same time)
Make sure USB debug is checked under phone's setting "Developer options", tick "USB debugging" (might already be ticked) If "developer options" tab is missing from "Settings", go to "Settings", "About phone", then tap, tap, tap, on "Build number" do it spasticly until it unlocks, aboot 7 times. ha ha Canada
(Click on the attached thumbnails to enlarge them to huge)
View attachment 3075958 View attachment 3075959
Hook the phone to USB & computer prior to running EFSPro. Keep an eye on the phones screen when the program starts, a few popups will probably pop up on the phone, allow your computer's RSA key, tic the always remember, and allow access to your computer. SU will pop up on the screen too, grant access. (If it doesn't connect, check phone's drop down for connection options. Worst case, toggle usb debug off/on while attempting connection in efspro).
{
"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"
}
Click on EFS Professional, The only folder you need to use is under the backup tab. Don't mess around under the other tabs, just click on backup.
View attachment 3048807 View attachment 3125707
Under the Backup Tab select "manage" Then select "Create New". Now you will create a PIT file, the map of your DE's system.
View attachment 3075885 View attachment 3075886
Type in the File name, display name, and description. I typed "note-4" in all three boxes.
View attachment 3181033
Click "Read Pit" a popup will nag, just click "OK" and continue, device written, click "OK", Then hit "Save".
View attachment 3075888
You now have your DE's PIT, the road map to your system partition. Ready to backup aboot? Lets go, press "Manage" then "refresh". Now your new pit should be visible under the "manage" drop down.
View attachment 3075899
From the drop down find your device (Note-4), and "select" it.
View attachment 3075900 View attachment 3075901
"Deselect all", then tic aboot only (You don't want to save all in one zip, it's +3GB, and will take forever, and most likely choke on it's self. Later after backing up aboot you can go back, and save the other partitions that aren't backed up by TWRP).
View attachment 3075902 View attachment 3075911
Click "backup". When it's finished you should now have two copies of aboot zipped up in a nice file (Note-4_xxxxxxxx.tar.gz) in EFSProBackup folder on your internal SD (or External SD), and on your computer both locations should contain a TAR of aboot. You can rename it "MyNote4_aboot.tar.gz". Later you should also manually move this to external SD using Root Explorer or ES File explorer
View attachment 3075912
Now is the time to donate to @lyriquidperfection , or a least go back to his OP and hit the thanks button.
View attachment 3075913
If a stock Tar is accidentally flashed, locking the boot loader, the phone won't be able to run EFS Pro because it requires root, and busybox, and may not boot anyway. If you do somehow lock your boot loader. Post your request for help to this thread, someone will PM you asking for your aboot backup, one of the devs here will make your aboot odin flashable, and send it back ready to go.
*Odin can't flash all the partitions, only the ones that are mapped in your PIT file. Please do a second backup, make a combined zip, select the following: aboot.mbn, NON-HLOS.bin, rpm.mbn, sbl1.mbn, sdi.mbn, tz.mbn. This will up your insurance policy to premium
Now that your are "out of the woods", go back into EFSPro and backup all partition blocks, minus a few huge ones that are already backed up by your recovery. I back up all blocks on a fresh DE image, before installing a bunch of apps (recovery, SuperSU, and Busybox). If you have a bunch of stuffs already installed you might want to skip blocks: 25 Cache, and 27 User Data. They are huge, and redundant if you already backed up everything in TWRP. You do have everything backed up in TWRP, right???
Eye glazing stuffs: The backups can be un-zipped to a tar, aboot.mbn.tar. Then unzipped again to reveal the unzipped partitions. These can be selectively modified into an Odin flash-able tar.md5. This part should be done by a developer because some hex editing and special software adds an md5 checksum .
Don't be the one that flashes a stock image tar, or allows a repair kiosk to touch your precious. Hopefully the insurance policy you just made won't ever have to be claimed.
Check back for correction, and updates. Please post your results good, or bad to this thread.
THANKS!
Nice guide I will have to do this
radionerd said:
Samsung Developer Devices are identical to retail devices with exception of one partition "aboot". If this partition is overwritten or corrupt the phone will brick, and bootloader will lock. This partition is device ID specific and coded to the boot partition, and device. If both of these partitions are backed up prior to corruption, it would be possible to restore a locked developer device.
There are several ways to backup these unique partitions, these procedures are not real difficult, but care should be taken. One method is by using ADB. install Google SDK and use ABD [ADB Guides] Setup and run ADB, and backup the partitions using dd command. This is a computer to phone terminal interface via USB. If you have used Linux scripts, this should easy peasy once ADB is functional.
There is a cool program built by XDA contributor lyriquidperfection, it's called EFS Professional It is a very powerful tool that runs on windows computers, and uses a GUI, no scripts, just point and click
Both interfaces use Busybox, so it must be installed on your device prior.
I like BusyBox Tools by Stephen (Stericson), or Busybox On Rails
Disclaimer: If you are careful, study a bit, and follow direction closely there isn't much risk. Please be careful these tools are capable of bricking your phone if you explore other commands. If you run into problems, I will try to help.
1. ADB Method Here is a quick guide that I made while backing up my note-4 DE. The VZW note-4 aboot partition is mmcblk0p7 This location and name are different in other models.
2. EFS Professional Method
Download EFS Professional on windows computer, install it. This program has a imbedded version of ADB built in (don't run any other ADB programs at the same time)
Make sure USB debug is checked under phone's setting, Developer options tick USB debugging (should already be ticked) If developer options is missing, go to settings, About phone, tap tap tap "Build number" spasticly until it unlocks.
Hook the phone to USB prior to running EFSPro. Keep an eye on the phones screen when the program starts, a few popups will probably pop up on the phone, Tic the always remember, and allow access to the computer. SU will pop up on the screen too, grant access.
View attachment 3048807
(Click on the attached photos to enlarge them)
The only folder you need to use is under the backup tab. Don't mess around under the other tabs, just backup.
Under the Backup Tab select "manage" Then select "Create New". Now you will create a PIT file, and grab a map the DE system.
View attachment 3048818
Type in the File name, display name, and description. I typed "note-4".
Then Click "read device", it should look like the picture below. Then hit "Save".
View attachment 3048835
You now have a Note-4 PIT, and map. Ready to backup aboot and boot, just press "Manage" then "refresh". Now your new pit should be visible under "manage drop down".
From the drop down find your device, and "select" it.
View attachment 3048845
"Deselect all", then tic aboot and boot only (You don't want to save all in one zip, it's Gigs, and will take forever, and most likely choke on it's self later you can go back and save the other partitions that aren't backed up by TWRP).
Then click "backup", when it's done you should now have an efsprofessional folder on your internal SD, and on your computer that contains a TAR of aboot and boot.
View attachment 3048866
Now is the time to donate to Liquid Perfection, or a least go back to his OP and hit the thanks button.
This is a ruff work in progress, but it's getting late, so check back for typos, correction, and updates. Please post your results good, or bad to this thread.
THANKS!
Click to expand...
Click to collapse
This is great work. Thanks so much. We've already seen a couple of our fellow Note 4 DE owners need a aboot backup to restore their unlocked bootloader. This is a must for any DE owner. It's like an insurance policy.
How do you restore?
Once you use the dd command in terminal emulator or in adb, or once you have an efs-professional backup of your aboot, so you have an aboot.mbn or aboot.bak, how do you restore it if you have inadvertently, let's say, flashed a retail edition aboot by flashing a retail full tar file from Odin for instance? I bought a Note 3 DE last year, and I made a copy of my aboot as soon as I got it, using the dd command, the file is about 2mb, but so far I don't know how to restore it if it does get the retail aboot installed on it by accident. Could you please shed some light on the restoration procedure as well?
Also, I know if you backup your /efs partition on twrp, it can't be restored if you mess it up, supposedly that's what makes the phone tick and gives it its identity, I have read about a few people on this forum that accidentally deleted their /efs partition and their phone never worked right after that, like their unlock screen wouldn't work and a lot of other stuff was messed up, as they described. If you make a /efs backup with efs-professional, could it be restored correctly if the /efs partition gets corrupted by accident? I don't really know why anyone would need to delete that partition, but I think some rom or modem update procedure did it, but just in case it happens.
Thank you for the great work and tutorial
newuser134 said:
Once you use the dd command in terminal emulator or in adb, or once you have an efs-professional backup of your aboot, so you have an aboot.mbn or aboot.bak, how do you restore it if you have inadvertently, let's say, flashed a retail edition aboot by flashing a retail full tar file from Odin for instance? I bought a Note 3 DE last year, and I made a copy of my aboot as soon as I got it, using the dd command, the file is about 2mb, but so far I don't know how to restore it if it does get the retail aboot installed on it by accident. Could you please shed some light on the restoration procedure as well?
Click to expand...
Click to collapse
Hopefully no one will have to be the Guinea Pig, and restore a corrupted aboot from accidentally flashing a retail TAR on their DE. As far as I know only one guy has tried aboot restore successfully, with big help from a dev who made his prior saved aboot flashable.
As far as I know aboot restore is untested with efsprofessional, I have successfully restored other partitions using efspro on my note-3 DE.
Unfortunately every DE version that has been released has had several folks overwrite aboot; accidentally, or in desperation flash retail Tars, by themselves, by Samsung service center, or at a retail store kiosk, like bestbuy.
Your DE warranty, and insurance is your backups. Samsung won't fix your corrupted system, if they do (only if no knox trip 0x0), you will receive your phone with a retail image put on it. Having an aboot backup could possibly bring it back to DE.
newuser134 said:
Also, I know if you backup your /efs partition on twrp, it can't be restored if you mess it up, supposedly that's what makes the phone tick and gives it its identity, I have read about a few people on this forum that accidentally deleted their /efs partition and their phone never worked right after that, like their unlock screen wouldn't work and a lot of other stuff was messed up, as they described. If you make a /efs backup with efs-professional, could it be restored correctly if the /efs partition gets corrupted by accident? I don't really know why anyone would need to delete that partition, but I think some rom or modem update procedure did it, but just in case it happens.
Click to expand...
Click to collapse
Been there done that, Most of the guys that had efs messed up on Note-3 DE, including myself, we used the first T-mobile TWRP version that didn't backup the right efs partition, upon TWRP restore we had major problems, some of us compounded the problems, me too TWRP was quickly updated, and a few of us figured out ways to rebuilt /efs.
"What I learned was backup your backup, then back that up too" I do complete TWRP backup as soon as rooted, DD of all partitions, then backup all partitions, except a few huge partitions using efspro.
newuser134 said:
Thank you for the great work and tutorial
Click to expand...
Click to collapse
Thanks WIP, hope to add soon "copy and paste" scripts for all the partitions.
Thanks for the instructions. I hope to never need it, but I will follow this procedure just to be on the safe side.
Doesn't TWRP handle this by ticking on the EFS checkbox when making a backup?
solidunit said:
Doesn't TWRP handle this by ticking on the EFS checkbox when making a backup?
Click to expand...
Click to collapse
TWRP does backup EFS, but not aboot, or a handful of other partitions. EFS pro can backup all partitions.
radionerd said:
Type in the File name, display name, and description. I typed "note-4".
Then Click "read device", it should look like the picture below. Then hit "Save".
View attachment 3048835
Click to expand...
Click to collapse
When I get to the "read device" step I get an error saying it cannot find the pit file in the EFS folder. What am I missing? Thanks
tfly212 said:
When I get to the "read device" step I get an error saying it cannot find the pit file in the EFS folder. What am I missing? Thanks
Click to expand...
Click to collapse
Did you click on the Manage box and select "create new"
Then read device
Then name note-4 on device name, display name, and description, then click save
go back to manage, click refresh
Then go to device filters, find your note 4
de-select all, then select aboot
Then click backup.
Now you should have a "double zipped" file of aboot in your computer efsprofessional folder, and on your sdcard.
Attached a few pictures from my note 3
radionerd said:
Did you click on the device filter box "v" and select "create new"
Then read
Click to expand...
Click to collapse
I did not the first time...but once I did it worked perfectly, thank you. I didn't think to click the dropdown as I knew Note 4 wasn't going to be on there. Might want to add that line to the instructions in case anyone else runs into the same issue.
All good now...going to donate to the dev tonight.
tfly212 said:
I did not the first time...but once I did it worked perfectly, thank you. I didn't think to click the dropdown as I knew Note 4 wasn't going to be on there. Might want to add that line to the instructions in case anyone else runs into the same issue.
All good now...going to donate to the dev tonight.
Click to expand...
Click to collapse
Great!
I will go look at the wording of the OP
tfly212 said:
I did not the first time...but once I did it worked perfectly, thank you. I didn't think to click the dropdown as I knew Note 4 wasn't going to be on there. Might want to add that line to the instructions in case anyone else runs into the same issue.
All good now...going to donate to the dev tonight.
Click to expand...
Click to collapse
Buy him some nappies for his kid
Thanks man,
I updated my OP with 27 8"x10" color glossy photos with circles and arrows
radionerd said:
Buy him some nappies for his kid
Thanks man,
I updated my OP with 27 8"x10" color glossy photos with circles and arrows
Click to expand...
Click to collapse
Will do...I have a little one also, and while a beer sounds better, the way they go through diapers is staggering.
How do I find my computers RSA key? I am on windows 8.1?
texasez said:
How do I find my computers RSA key? I am on windows 8.1?
Click to expand...
Click to collapse
You don't need to know the computer's RSA key, The RSA pop-up comes up on your phone when entering ADB mode. The key is in the pop-up, Just grant access.
Is the "sbl1bak" a backup of the "sbl1" ????????
larrycjr said:
Is the "sbl1bak" a backup of the "sbl1" ????????
Click to expand...
Click to collapse
Yup,
However sb1bak is empty on my note 4
Easy look at Note 4 partition Mounts by-name (trltevzw)
aboot -> /dev/block/mmcblk0p7 (2048KB)
apnhlos -> /dev/block/mmcblk0p1
boot -> /dev/block/mmcblk0p17
cache -> /dev/block/mmcblk0p25
carrier -> /dev/block/mmcblk0p26
dbi -> /dev/block/mmcblk0p5
ddr -> /dev/block/mmcblk0p6
efs -> /dev/block/mmcblk0p13
fota -> /dev/block/mmcblk0p19
mdm1m9kefs1 -> /dev/block/mmcblk0p14
mdm1m9kefs2 -> /dev/block/mmcblk0p15
mdm1m9kefs3 -> /dev/block/mmcblk0p10
mdm1m9kefsc -> /dev/block/mmcblk0p16
misc -> /dev/block/mmcblk0p20
modem -> /dev/block/mmcblk0p2
pad -> /dev/block/mmcblk0p11
param -> /dev/block/mmcblk0p12
persdata -> /dev/block/mmcblk0p23
persist -> /dev/block/mmcblk0p22
recovery -> /dev/block/mmcblk0p18
rpm -> /dev/block/mmcblk0p8
sbl1 -> /dev/block/mmcblk0p3
sbl1bak -> /dev/block/mmcblk0p4
ssd -> /dev/block/mmcblk0p21
system -> /dev/block/mmcblk0p24
tz -> /dev/block/mmcblk0p9
userdata -> /dev/block/mmcblk0p27
I finally get past the RSA problem by using installer mode on phone but the phone auto changes back to media device and then efs pro does not recognize the phone. I tried camera (ptp) mode but it will not go past pressing the device info button on efs pro. How do I make the phone stay in installer mode. I keep getting popups wanting me to install the verizon software but I did not install.
How do I keep the installer mode active?
Your obviously on the dev edition?? Correct? If so if it's not to much to ask will you send me a copy of your sbl1. Please.
Sent from my SM-N910V
Hey,
After attempting to flash a new LineageOS version using the updater my phone wouldn't get out of recovery mode.
In order to fix it I accidentally cleared the entire misc partition instead of only a part of it.
After doing a complete factory reset using LGUP I got it to boot again. Unfortunately WiFi doesn't work anymore (the *.kdz file doesn't contain a misc.img either)
Could someone with an H870 phone upload an image of that partition please
The steps are as follows:
Code:
ls /dev/block/platform/soc/*/by-name/misc
which is /dev/block/platform/soc/624000.ufshc/by-name/misc in my case
and then
Code:
dd if=/dev/block/platform/soc/624000.ufshc/by-name/misc of=/sdcard/misc.img
Finally upload the misc.img file somewhere and post a link here.
Thanks
Did you manage to do find the misc partition? I think I did exactly what you did.
Doesn't misc partition contain IMEI number and such?
you SHOULD'T use a misc partition from other devices. That contains data that is specific to your device - CID (Carrier or Region ID), USB configuration, hardware settings etc
Check your IMEI. Does he appears correctly?
foobar1234 said:
Hey,
After attempting to flash a new LineageOS version using the updater my phone wouldn't get out of recovery mode.
In order to fix it I accidentally cleared the entire misc partition instead of only a part of it.
After doing a complete factory reset using LGUP I got it to boot again. Unfortunately WiFi doesn't work anymore (the *.kdz file doesn't contain a misc.img either)
Could someone with an H870 phone upload an image of that partition please
The steps are as follows:
which is /dev/block/platform/soc/624000.ufshc/by-name/misc in my case
and then
Finally upload the misc.img file somewhere and post a link here.
Thanks
Click to expand...
Click to collapse
Wiping that partition wipes your IMEI and Mac info, no Mac info means no WiFi.
Huh, I had completely forgotten about this thread and didn't get any notifications until I was quoted.
In any case I managed to solve it somehow. I don't remember what I did exactly but I think it was something like this:
I noticed that bluetooth had an all zero mac address as well unless I disabled and reenabled it. In this case it would generate a random one. Rebooting would set it to all zero again of course, but I think I just copied the misc partition from the running kernel to a pc and then back to the phone. That seemed to work.
After that I tried changing a few bytes near the BT Mac with a hex editor until the wifi address changed (I think it was less than 20bytes away). I don't remember what happened to the IMEI but I'm still using the phone and seem to have a valid one now.
Maybe this will help someone but of course take everything with a grain of salt.
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?
Hello,
I managed to break my fingerprint reader. I don't think the problem is my /persist because all sensors work fine. But unfortunately, I had never backed up the rest of the sensitive partitions: vbmeta, vbmeta_system, keystore, keymaster, odm, core_nhlos, secdata, abl, cmnlib, cmnlib64, devcfg, dsp, hyp, xbl, xbl_config, tz, rpm, aging, aging_mod.
Could someone on a TMO 7t Pro 5G McLaren (with a working fingerprint reader preferably running the latest 10.0.35 software, please pull and post these partition img files? If you don't know how, it's very simple, please ask.
I point to this because my previous phone, Essential PH1, had similar issues, but at least Essential had posted all of the firmware images on their website every month, and flashing the above partitions would fix it. 1+ doesn't provide anything and even the MSM doesn't restore all of these partitions.
Thanks so very very much in advance!
Edit: If possible, could one extract all partition img files from 10.0.35 in addition to those requested above?
EDIT2: ODM partition has 1st priority for anyone who can help.
Edit3: odm is fine. After looking through some logs,
I need keystore, keymaster (_a or _b, whichever is your current slot), vbmeta (a or b), and vbmeta_system (a or b). None are very large I think.
You're making me want a backup. I thought MSM was supposed to be that for us. Irritating.
A couple of those look like they could have sensitive data. Anyone know of a reason not to post them? Looks like they are all available via /dev/block..
ttabbal said:
You're making me want a backup. I thought MSM was supposed to be that for us. Irritating.
A couple of those look like they could have sensitive data. Anyone know of a reason not to post them? Looks like they are all available via /dev/block..
Click to expand...
Click to collapse
If you don't already have a backup of every partition, please please please do so urgently. Or an RMA will most likely be in your future. That should be in huge bold print with a link to instructions at the very top of the root and bootloader unlock threads.
I've never had a device with these issues before. It's starting to get ridiculous.
Edit: If you didn't take backups before unlocking the bootloader, Widevine L1 support (being able to watch Netflix in HD instead of 480p crap on our giant beautiful screens) is lost forever (except for RMA). And just flashing a "bad" canary version of magisk was enough to kill the fingerprint sensor. Of course I didn't learn any of this until it was too late.
MSM will get your phone back to life but not fully heal it. Basically all the MSM is guaranteed to do is get the phone to boot. No sensors, no fingerprint, no Widevine L1, no IMEI and wifi Mac address fix (if one is really screwed). And 1+ didn't take any measures to protect the sensitive partitions once bootloader is unlocked. It's all just a clusterf**k
Same issues on 7T and 8 and 8pro if that makes you feel any better ¯\_(ツ)_/¯
Well, that's irritating. WTF wouldn't you have a recovery tool for all those? Interestingly, I don't seem to have odm in there at all. Ah, scratch that, it's in /dev/block/mapper and there are 3. _a, _b, -verity.
It's rpm I don't seem to have. 10.0.35.
ttabbal said:
Well, that's irritating. WTF wouldn't you have a recovery tool for all those? Interestingly, I don't seem to have odm in there at all. Ah, scratch that, it's in /dev/block/mapper and there are 3. _a, _b, -verity.
It's rpm I don't seem to have. 10.0.35.
Click to expand...
Click to collapse
Yeah, system, vendor, product, and odm are stored in super.img on Android 10. But u found it. Find out what slot you are on, running 10.0.35, and you'd want the _a or _b files that match your current slot.
ttabbal said:
Well, that's irritating. WTF wouldn't you have a recovery tool for all those? Interestingly, I don't seem to have odm in there at all. Ah, scratch that, it's in /dev/block/mapper and there are 3. _a, _b, -verity.
It's rpm I don't seem to have. 10.0.35.
Click to expand...
Click to collapse
I think you are right. Rpm doesn't exist possibly on this phone. Don't have time to research right now.
But I noticed in /dev/block/mapper, I only have _a and _b. No -verity file. For system, vendor, odm, nor product. Could you post the -verity file(s)?
What files/file sizes do you have in /odm/ ?
starcms said:
I think you are right. Rpm doesn't exist possibly on this phone. Don't have time to research right now.
But I noticed in /dev/block/mapper, I only have _a and _b. No -verity file. For system, vendor, odm, nor product. Could you post the -verity file(s)?
What files/file sizes do you have in /odm/ ?
Click to expand...
Click to collapse
Doesn't look really interesting to me, but here's the ls output.
Code:
OnePlus7TProNR:/sdcard/img # ls -l /odm
total 20
drwxr-xr-x 4 root root 4096 2008-12-31 17:00 etc
drwx------ 2 root root 16384 2008-12-31 17:00 lost+found
OnePlus7TProNR:/sdcard/img # ls -l /odm/etc
total 12
-rw------- 1 root root 2735 2008-12-31 17:00 build.prop
-r--r--r-- 1 root root 0 2008-12-31 17:00 fs_config_dirs
-r--r--r-- 1 root root 0 2008-12-31 17:00 fs_config_files
drwxr-xr-x 2 root root 4096 2008-12-31 17:00 selinux
drwxr-xr-x 2 root root 4096 2008-12-31 17:00 vintf
OnePlus7TProNR:/sdcard/img # ls -l /odm/etc/selinux/
total 728
-rw-r--r-- 1 root root 733547 2008-12-31 17:00 precompiled_sepolicy
-rw-r--r-- 1 root root 65 2008-12-31 17:00 precompiled_sepolicy.plat_sepolicy_and_mapping.sha256
-rw-r--r-- 1 root root 65 2008-12-31 17:00 precompiled_sepolicy.product_sepolicy_and_mapping.sha256
OnePlus7TProNR:/sdcard/img # ls -l /odm/etc/vintf/
total 16
-rw-r--r-- 1 root root 5300 2008-12-31 17:00 manifest.xml
-rw-r--r-- 1 root root 1369 2008-12-31 17:00 manifest_ese.xml
-rw-r--r-- 1 root root 622 2008-12-31 17:00 manifest_noese.xml
I can try, but my upstream sucks. It might be faster for someone else to grab them.
-rw-r--r-- 1 travis travis 816K Jun 4 15:40 img/odm-verity.img
-rw-r--r-- 1 travis travis 1.3G Jun 4 15:41 img/product-verity.img
-rw-r--r-- 1 travis travis 2.2G Jun 4 15:40 img/system_root-verity.img
-rw-r--r-- 1 travis travis 884M Jun 4 15:43 img/vendor-verity.img
After looking through some logs, you can ignore most of that.
I need keystore, keymaster (_a or _b, whichever is your current slot), vbmeta (a or b), and vbmeta_system (a or b). None are very large I think.
Thanks for all of your time @ttabbal. Sorry if I'm driving you crazy Been driving myself crazy trying to fix this for 2 weeks now lol
My /odm seems to be fine. Matches yours. I was mainly concerned about those 2 files with 0 size. But I don't have any of the -verity.imgs from /dev/block/mapper. I'm pretty sure they are supposed to be created and mounted at boot (from super.img and by verity/vbmeta). I'm hoping those 2 vbmeta partitions will fix things up. If not, then I'll try keystore and keymaster. And then I'll have to send it in...
Edit:. Just curious, I'm assuming you are bootloader unlocked and running Magisk? Just confirming since you have those -verity.imgs
ok.. Hope it helps.
https://drive.google.com/file/d/1a9FTbvdEM2n12wjc4SL7kNMu3SAtfuAY/view?usp=sharing
https://drive.google.com/file/d/15Ssumik6iMY7kWgldHfFajsbyNdh9aTz/view?usp=sharing
Yes, I am unlocked and rooted with Magisk.
ttabbal said:
ok.. Hope it helps.
https://drive.google.com/file/d/1a9FTbvdEM2n12wjc4SL7kNMu3SAtfuAY/view?usp=sharing
https://drive.google.com/file/d/15Ssumik6iMY7kWgldHfFajsbyNdh9aTz/view?usp=sharing
Yes, I am unlocked and rooted with Magisk.
Click to expand...
Click to collapse
Well, not exactly lol.
Flashed your two images via fastboot, still broken fingerprint and still missing -verity files from /dev/block/mapper/ , went to flash my backups of vbmeta and vbmeta_system via fastboot, got into a bootloop, and after a couple hours of screwing with it, finally got back where I started from...except using your images.
I don't understand. vbmeta and vbmeta_system are NOT device specific. One from my phone, one from your phone, one from anyone's phone running 10.0.35 should be exactly the same.
What exact method did you use to pull the images? dd to a tmp dir on device and then adb pull img? dd directly to computer? or adb pull the partitions themselves direct to computer? Shouldn't all 3 methods return the same results?
I swear, after the RMA I really don't know if I am going to risk unlocking the bootloader again (this is coming from someone who has had s-off/bootloader unlock/root/su/Magisk on every single android device ever owned over the past 10 years...without ever having any problem I couldn't fix by myself)
It should all be the same img, but I did "dd bs=1M if=/dev/<partition> of=/sdcard/img/" and adb pull them to the computer. Pretty much the same dd command I use for most image work. I am on 10.0.35.
One of the biggest reasons I gave this device a shot was the ability to reflash back to stock. Now I hear that doesn't work. That's really annoying. This is something Oneplus should just provide as a backup. They don't even have to keep it up to date. We can OTA our way to the latest. They have to have something like that to flash the phones before shipping them out. I guess they could flash to storage chips before installing them on the PCBs.
I was also hoping to see some development, I didn't realize that the A/B thing or A10 was going to cause so many problems. Not the devs fault, just one more thing to shake my head at. Sadly, I think root stuff is going to start phasing out. I don't mind no support for modified software, but I hate that I don't own my devices.
ttabbal said:
It should all be the same img, but I did "dd bs=1M if=/dev/<partition> of=/sdcard/img/" and adb pull them to the computer. Pretty much the same dd command I use for most image work. I am on 10.0.35.
One of the biggest reasons I gave this device a shot was the ability to reflash back to stock. Now I hear that doesn't work. That's really annoying. This is something Oneplus should just provide as a backup. They don't even have to keep it up to date. We can OTA our way to the latest. They have to have something like that to flash the phones before shipping them out. I guess they could flash to storage chips before installing them on the PCBs.
I was also hoping to see some development, I didn't realize that the A/B thing or A10 was going to cause so many problems. Not the devs fault, just one more thing to shake my head at. Sadly, I think root stuff is going to start phasing out. I don't mind no support for modified software, but I hate that I don't own my devices.
Click to expand...
Click to collapse
What is the need or result of the "bs=1M" in the command? I've never seen that before in other threads. I'm assuming it means block size equal to 1MB. Is that definitely required to get a good pull? Same bs for any/all partitions?
If you have persist and both EFS images backed up, you should be okay. The MSM tool can restore I think everything else. I'd keep a backup especially of any partitions that don't end in _a or _b. The MSM tool definitely takes care of the rest (those ending in _a and _b). I just hate using it because there's no way to make it not wipe userdata. And without being able to make a nandroid backup due to no fully working twrp due to A10, it's just a giant pain.
And unfortunately we can't just OTA our way to the latest, at least not by manually downloading an OTA from 1+. Only way to update is with a real OTA update from T-Mobile.
The A/B partitioning isn't the problem with development. That's been around since Android 7 or 8. It's the new dynamic partitioning format that all phones that launch with Android 10 (or newer) have. Even the Pixel 4 doesn't have fully working twrp yet. It's coming soon though...
Edit: Also, for the dd commands, did you use /dev/block/actual_partition or /dev/block/by-name/friendly_name_of_partition? Again, should it really make a difference?
Edit2: All of these issues have a root cause from Android 10. The new required partitioning system for any phones that launch with it. That's why unlocking the bootloader wipes reserve.img. Because it's in userdata (cause of A10) and 1+ forgot about that and didn't rewrite the algorithm used when the bootloader is unlocked. It's also their negligence (combined with A10) which causes persist (and other key partitions) to become so easily corrupted. Virtually all devices launched since Android 7 use "fastboot flashing unlock" and then "fastboot flashing unlock_critical" to allow changes to device specific partitions. For some reason 1+ still is using the antiquated "fastboot oem unlock" command which unlocks literally everything, even some stuff that unlock_critical doesn't, and which in the old days, didn't matter. A10 especially should not ever be used with fastboot oem unlock. Google says so lol.
If it makes you feel better, this isn't unique to this phone. It's a problem on every device 1+ has launched with A10 and still is (OP7T/TPro/OP8/Pro). Because of A10 partitioning combined with the use of an antiquated bootloader that only supports "fastboot oem unlock"
The block size doesn't matter for the pull and doesn't change the image at all. It just reads in chunks, making it faster.
Yes, I used by-name and it shouldn't matter if you use that or the sd# names.
It's your persist and it's unique. The rest of your sensors won't care. If you didn't back it up, you're screwed. An MSM restore doesn't fix this.
LLStarks said:
It's your persist and it's unique. The rest of your sensors won't care. If you didn't back it up, you're screwed. An MSM restore doesn't fix this.
Click to expand...
Click to collapse
The issue is I had a backup of my unique persist. And restoring it doesn't fix the dang fingerprint. That's why I was thinking the issue had to be elsewhere
Hello,
unfortunately, my Google Keep app had just decided to wipe its db file up. (/data/data/com.google.android.keep/databases/keep.db)
It is not (and never was) synchronized to Google.
When it happened I just copied (dd'ed over adb) /dev/block/sda13.
From mount command output, I could recognized /dev/block/sda13 as /data backing block device.
Then I did some searches in the output image file and noticed it actually encrypted per file.
I learned from it OP uses FBE (file-based-encryption). I wanted to try and run some ext4 recovery tools (autopsy, undelete ...).
FBE encrypts also filenames so I can't use the generated image as is.
I checked what caused FBE on /data partition and it's the encryption setting. I read it uses the fingerprint/pattern/password to decrypt the encrypted /data.
I didn't power-off the phone since then to avoid any more losses.
My questions:
1. Given /dev/block/sda13 as an image file, how can one decrypt it and use forensics/restoration tools on it?
2. Another option - how to acquire the unencrypted /dev/block/sda13 from the running device?
3. Maybe there is some backup partition for files in /data?
4. Can I run the mentioned tools straight on some unencrypted device file? (Assuming cross-compilation to android)
5. Any caches/other places I can search for residues? (I tried dumping CursorWindow ashmem the Keep app used but the app has restarted since then)
6. OP compiled the kernel without DEVMEM. Maybe there is other option to acquire the whole RAM to try to scan for residues?
More side-notes:
- I tried other files in the Keep app directory to try to recover some residues, pictures where saved outside the db file so I was able to restore them (but what is important are the notes stored in the db itself(
- I was able to notice keep.db was replaced with an empty sqlite3 db file (for some strange reason ...). My guess was it didn't overridden the original db file so if I had the ext4 /data partition, I will be able to scan it with the tools mentioned above.
References:
* https://forum.xda-developers.com/t/...-encrypt-data-partition-on-oneplus-5.3642144/
* https://www.cs1.tf.fau.de/research/system-security-group/one-key-to-rule/
If some details are missing, please let me know!
https://www.cs1.tf.fau.de/research/system-security-group/one-key-to-rule/ is really interesting.
The problem now is how to get a full memory dump without /proc/mem and signed kernel modules.
Any help? I'm out of ideas but it seems like a solvable problem.