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?
Related
With the release of the kernel sources, it seems that the 3 AndroidOne devices all share the same kernel and internals,
with only the rom branding and chassis they're in being different.
If this is the case, then the roms themselves are built by goog and thusly OTAs handled directly by them.
What it also implies is that the 3 devices might be able to share roms and kernels as they already appear to share kernel sources.
What I need:
Dump of /system Edit: Done
If the rom prompted for an OTA at initial setup
Dump of /oem
Bootloader version
Baseband version
Hi all) Make please dump or backup in CWM recovery and lay out it here.
rock12345 said:
Hi all) Make please dump or backup in CWM recovery and lay out it here.
Click to expand...
Click to collapse
What is it and how to do that...???
I have the phone
TheManii said:
With the release of the kernel sources, it seems that the 3 AndroidOne devices all share the same kernel and internals,
with only the rom branding and chassis they're in being different.
If this is the case, then the roms themselves are built by goog and thusly OTAs handled directly by them.
What it also implies is that the 3 devices might be able to share roms and kernels as they already appear to share kernel sources.
What I need:
Dump of /system
If the rom prompted for an OTA at initial setup
Bootloader version
Baseband version
Click to expand...
Click to collapse
I doubt there is a custom recovery already prepared,
the simplest way to dump /system is
enable ADB
do a "adb pull /system"
upload the system folder
TheManii said:
I doubt there is a custom recovery already prepared,
the simplest way to dump /system is
enable ADB
do a "adb pull /system"
upload the system folder
Click to expand...
Click to collapse
what r u going to do with it?
Am new to this...
Tell me in detail so that I can try it
sukhith said:
What is it and how to do that...???
I have the phone
Click to expand...
Click to collapse
please do backup and throw off here.I need your system and boot.It is possible to make through ADB or CWM recovery.
---------- Post added at 07:07 AM ---------- Previous post was at 06:56 AM ----------
Recognized Noob said:
what r u going to do with it?
Click to expand...
Click to collapse
We want to port your ROM
i cud have done it but my net speed wont allow.
TheManii said:
I doubt there is a custom recovery already prepared,
the simplest way to dump /system is
enable ADB
do a "adb pull /system"
upload the system folder
Click to expand...
Click to collapse
No root bro. How can anyone dump anything?
Sent from my GT-I9082 using Tapatalk
---------- Post added at 09:10 AM ---------- Previous post was at 09:10 AM ----------
No root, how can anyone dump anything?
Sent from my GT-I9082 using Tapatalk
##W4TCH0UT## said:
No root bro. How can anyone dump anything?
Sent from my GT-I9082 using Tapatalk
---------- Post added at 09:10 AM ---------- Previous post was at 09:10 AM ----------
No root, how can anyone dump anything?
Sent from my GT-I9082 using Tapatalk
Click to expand...
Click to collapse
Apropos rue: from the first move of rues I received through http://www.kingoapp.com. But if already tried to receive others ON, my council, we put an insertion from scratch, and everything turns out.
It is possible to eat one subtlety (and coincidence is possible, simple), when receiving a rue in process, it is necessary to come mtk tools/engineer mode/engineer mode MTK/Log and Debugging/user2roor/root
To take down a poroshivka that I wouldn't will be to check.
If it didn't help, try and here it is http://software.techas…ng-quirky_7403136.html
And then we scratch on Habrahabr and ispravly not justice with a SD card that Yandex there would climb http://habrahabr.ru/post/214431/
There will be time will paint in more detail, while so
System dump
Find system dump here http://dropjar.com/#YazLGa6
##W4TCH0UT## said:
No root bro. How can anyone dump anything?
Sent from my GT-I9082 using Tapatalk
---------- Post added at 09:10 AM ---------- Previous post was at 09:10 AM ----------
No root, how can anyone dump anything?
Sent from my GT-I9082 using Tapatalk
Click to expand...
Click to collapse
sheldroid said:
Find system dump here http://dropjar.com/#YazLGa6
Click to expand...
Click to collapse
Thanks a lot)
##W4TCH0UT## said:
No root bro. How can anyone dump anything?
Sent from my GT-I9082 using Tapatalk
---------- Post added at 09:10 AM ---------- Previous post was at 09:10 AM ----------
No root, how can anyone dump anything?
Sent from my GT-I9082 using Tapatalk
Click to expand...
Click to collapse
delete
sheldroid said:
Find system dump here http://dropjar.com/#YazLGa6
Click to expand...
Click to collapse
Lay out please still boot.img
Guys Do We Have The Stock ROM Image of the Device
Kunal.Kene.1797 said:
Guys Do We Have The Stock ROM Image of the Device
Click to expand...
Click to collapse
Factory images will be released by Google soon
Sent from my GT-I9082 using Tapatalk
##W4TCH0UT## said:
Factory images will be released by Google soon
Click to expand...
Click to collapse
Do you have any proof of this?
AndroidOne isnt nexus, and Android Wear has nothing but the kernels released as they're legally required to release those.
Code:
import /oem/oem.prop ro.product.model
I need a dump of /oem too, as apparently androidone does things differently now
Dump
Make dump via sp flash tools
Through flashtool can not only flash. You can read the firmware, in whole or in a specific section.
Run SP Flash Tool and click on Readback
Select scatter file (the name depends on the platform Your smarth) MT6589_Android_scatter_emmc.txt from firmware (or received via MTK Droid Tools)
If You have already read the data in this way, the tab displays read block settings, otherwise click "Add".
Double click with the left mouse button opens a file save dialog with the read memory block.
The file name can be left at default ROM_ or append the name used to identify, for example, ROM_S920, and click "Save".
In the next dialog box enter the start address and the length of the read block:
The length can be obtained from the scatter file (in the scatter of the old type next __NODL_FAT or FATстоит the starting address of the built-in flash, for example 0x5c780000 - indication of such length we consider the contents of memory to a partition of the built-in flash; scattered new type, look for the line partition_name: BMTPOOL and below it will be the start address linear_start_addr: 0xFFFF00a8) and click "OK".
Click "Read Back" and connect powered off phone to the computer.
Time backup for about 10-20 minutes. The blue bar at the bottom must pass 100%. Then the phone disconnected from the computer and turn as usual.
Via MTK Droid Tool to cut the dump firmware: connect the smartphone with the included USB debugging to PC, run MTK Droid Tool, tab, root, backup, recovery, press the button to Make a backup of ROM_ of fistula and specify the read memory block, then MTK Droid Tool in your folder backups will create a subfolder species Lenovo-S920_ROW_131217_ForFlashtoolFromreadback_140206-163344 and it will parse the read data block, creating drilled by cable full backup.
Attached files
The attached file instructions for preparation of the image memory and writing it in телефон.pdf 711,29K 3532 Number of downloads:
Message was edited by Stanner: 15 September 2014 - 15:32
javum, serega_83, linerty and 7 others liked this message
I'm not a magician - I am just learning....
As not to violate the rule 4.12 (citation) | How to remove the text under the spoiler (small text)
#2 how to create a full dump Telefonica to this message #2 steaven
Admin
Administrator
27 000 messages
7 477
Divine reputation
EXT. information [+]
Sent On 06 January 2014 - 12:13
Through flashtool can not only flash. You can read the firmware, in whole or in a specific section.
Run SP Flash Tool and click on Readback
post-833-0-04438700-1388998531 .png
Select scatter file (the name depends on the platform Your smarth) MT6589_Android_scatter_emmc.txt from firmware (or received via MTK Droid Tools)
If You have already read the data in this way, the tab displays read block settings, otherwise click "Add".
Double click with the left mouse button opens a file save dialog with the read memory block.
The file name can be left at default ROM_ or append the name used to identify, for example, ROM_S920, and click "Save".
In the next dialog box enter the start address and the length of the read block:
The length can be obtained from the scatter file (in the scatter of the old type next __NODL_FAT or FATстоит the starting address of the built-in flash, for example 0x5c780000 - indication of such length we consider the contents of memory to a partition of the built-in flash; scattered new type, look for the line partition_name: BMTPOOL and below it will be the start address linear_start_addr: 0xFFFF00a8) and click "OK".
Click "Read Back" and connect powered off phone to the computer.
Time backup for about 10-20 minutes. The blue bar at the bottom must pass 100%. Then the phone disconnected from the computer and turn as usual.
Via MTK Droid Tool to cut the dump firmware: connect the smartphone with the included USB debugging to PC, run MTK Droid Tool, tab, root, backup, recovery, press the button to Make a backup of ROM_ of fistula and specify the read memory block, then MTK Droid Tool in your folder backups will create a subfolder species Lenovo-S920_ROW_131217_ForFlashtoolFromreadback_140206-163344 and it will parse the read data block, creating drilled by cable the full backup.
Driver preloader: https://yadi.sk/d/G092mk0Rbb3P2
Original post taken from where the instruction: http://lenovo-forums.ru/topic/2560-как-и-чем-создать-полный-дамп-телефона/
TheManii said:
Code:
import /oem/oem.prop ro.product.model
I need a dump of /oem too, as apparently androidone does things differently now
Click to expand...
Click to collapse
oem contains only junk oem apps and their libs and below is oem prop
Code:
ro.product.device=Mi-498_sprout
ro.product.name=Mi-498
ro.product.manufacturer=Spice
ro.product.model=Spice Mi-498
ro.product.locale.language=en
ro.product.locale.region=IN
ro.config.wallpaper=/oem/media/Default.jpg
Disclaimer:
Xflasher tool was made for testing and educational purposes, ME is not responsible for what you do on/with your device using xflasher, you must agree that you using xflasher on your own risk, I am not responsible if you brick your device or anything!
How to use:
(2017 phones like xz premium which have usb vid : pid = 0fce : b00b is not supported since use new flashing protocol! Use newflasher tool if your device usb pid is B00B!!)
1. (this step only for windows version!) install usb drivers the same like one which you using with flashtool
2. simple put xflasher.XXX in firmware dir which is created by great @IgorEisberg tool caled XperiFirm, double click xflasher.exe (or execute xflasher.XXXX in case non windows version) it will create xflasher.bat (or xflasher.sh in case non windows version)
3. modify xflasher.bat (or xflasher.sh in case non windows version) for your needs
4. put your phone into flashing mode (do in mind its not fastboot mode, must be in flash mode!)
5. make sure your battery is enought charged at least 30 percent charged!!!
6. double click xflasher.bat (or run xflasher.sh in case non windows version) and wait until xflasher flash your rom
7. done
8. enjoy
Supported platforms:
- there is 3 versions, one is for Linux, one is for Windows, and one for Android! You can now flash phone trought another phone, so no more needs for PC!!!
Credits:
- @shoey63 for helping me deeply testing xflasher, thanks a lot man!
Source code:
- https://github.com/munjeni/xflasher
is it support for zeus mode xperia m ?
MOD EDIT @gregbradley
Quote removed, not needed and had large images
sorry if im wrong, but this will eventually be able to unlock bootloader?
inunxelex said:
is it support for zeus mode xperia m ?
Click to expand...
Click to collapse
No, this tool use s1 protocol so all phones which use s1 protocol can use this tool!
ayuready1989 said:
sorry if im wrong, but this will eventually be able to unlock bootloader?
Click to expand...
Click to collapse
Only on bootloader unlock allowed phones!
New version is out!
Changelog (v2):
- support for safety unlocking device bootloader (sha256 key check + check rooting alowed yes or no before unlocking)
- support for flashing all sin files from bundle but NOT BOOT BOOTBUNDLE! I will implement boot boondle soon (boot bondle mean: boot delivery from boot folder aka sbl1, s1sbl, dbi, aboot... so please do not flash them since if you flash wrong file you will hard brick your device!)!
- you can change usb VID and PID parameter (but in usb driver do it manualy by self)
Log about success in flashing some sin files is in attachment
After the experience you acquired writing this tool and with the previous research , do you think it would be possible to make backups of TA partition (or at least that area of TA partition that stores DRM keys) even from an unrooted phone?
I mean, personally I have an Xperia S, but I was especially thinking to our friends with a Z3 that aren't able to preserve them atm.
Good question! I thinked the same like you, but there is some problems, for example I have analysed ta and found 4 partitions inside ta, first one is 0100 (aka 01) and seccond one is 0200 (aka 02), booth 1 and 2 can be dumped trought special command to bootloader (flash tool dumping only partition 2 and not all units). But there is other two partitions which is 0101 and another one 0201, I have no idea how to send command to bootloader in order to dump them, for example for dumping first two partitions I need to send command OPEN_TA with partition number as parameter before sending command READ_TA unit, have tried many combinations for opening parrition 0101 but getting error reaply from bootloader which mean parameter error It will be a great having possibility dumping ta in full form without a needs having root, but seems its not possible by now, maybe in future we can do it.
Allso found something interesting. Dump.ta maded by our tool dumping partition 1 and 2, but flashing ta file only partition 1 data is writen since fitst parameter in file is 01 which mean "open partition 1", but to open seccond partition and write seccond partition data we must separate one file into two files since each partition and partition data must be separated since flashtool or s1tool can't see seccond partition parameter, so one file must be cut into 2 files before flashing! In any way you can not brick your phone by not separated files, but only partition 1 will be flashed.
Edit:
Drm keys and all things lives in partition 2 (on rooting allowed devices), I will need to compare s1 dump with ta dump and see what was not dumped from ta. Drm keys for sure missing, probably can not be dumped with reason since it will be easy way tricking Sony bootloader unlocking policy He have designed unlocking procedure to delete drm and probably his bootloader is designed to skip drm dumping Some units magic bytes is masked with ffffffff00000000, have no defined size in header...etc, which probably is with reason hiden to unit dumper command
munjeni, nice work. As fas as I researched, DRM keys are located in Unit 0x1046B. At least this is the unit which the bootloader deletes when it recognizes the device as rooted. I was not able to dump this unit via flashtool. Trying to flash it resulted in:
Code:
ERROR - ERR_SEVERITY="MINOR";ERR_CODE="0026";ERR_DYNAMIC="Not authenticated";
So I guess it's somehow special protected.
I was able to dump the unit with miscta_read_unit (you need atleast system privilegues) but not write to via miscta_write_unit (resulted in error code 3).
We should be able to dump all TA units with system user (in regards to the recent exploit which theoretically allows privilegue escalation to system user).
Problem is we can not simply restore them unless we find a way to generate a TA.img (with correct unit layout) out of unit data.
. .
Check TA.img from locked phone Unit 0x1046B is there with size 0x10. You can also check appsboot loader, if the device is rooted it deletes this unit.
I have used your ta_gen and it had unit 0x1046B inside resulted custreset.ta. You can flash this unit in emergency mode, but not normal mode (see previous post).
zxz0O0 said:
Check TA.img from locked phone Unit 0x1046B is there with size 0x10. You can also check appsboot loader, if the device is rooted it deletes this unit.
I have used your ta_gen and it had unit 0x1046B inside resulted custreset.ta. You can flash this unit in emergency mode, but not normal mode (see previous post).
Click to expand...
Click to collapse
You are right, its on partition 1! Will try something now related to our tool (seems I have s1 dump of unlocked ta since I can not see these unit by now in dump). But if my tool can dump these unit than probably we can reconstruct ta img from s1 dump, see my previous post (explained everything related to partitions and units)!
Tool can not read these unit
Log:
Want read ta unit 0001046B...
Sending command...
Command raw[13]:
00000000 00 00 00 0C 00 00 00 03 00 00 00 04 12 .............
Sending command...
Want unit raw[4]:
00000000 00 01 04 6B ...k
CRC32[4]:
00000000 BF CE 17 E3 ....
Writing crc32 for want read ta unit...
Verifying crc32...
Error: device reported that wanted ta unit is not found or can not be read!
Success: bulk read 4 bytes
Raw reply[4]:
00000000 00 00 00 00 ....
Error reading unit 0001046B!
Click to expand...
Click to collapse
So non rooted device have no chance having full ta dump since unit 1046B will be missed in s1 dump Maybe we can generate these unit? And how? Its probably MD5??? Or probably 3 x crc32 of the MARLIN+CKB+WMLA + 1 x crc32 of the crc32+crc32+crc32 ??
zxz0O0 said:
I was able to dump the unit with miscta_read_unit (you need atleast system privilegues) but not write to via miscta_write_unit (resulted in error code 3).
We should be able to dump all TA units with system user (in regards to the recent exploit which theoretically allows privilegue escalation to system user).
.
Click to expand...
Click to collapse
Ahh I see, how you dump these unit trought system user?
munjeni said:
Tool can not read these unit
Log:
So non rooted device have no chance having full ta dump since unit 1046B will be missed in s1 dump Maybe we can generate these unit? And how? Its probably MD5??? Or probably 3 x crc32 of the MARLIN+CKB+WMLA + 1 x crc32 of the crc32+crc32+crc32 ??
Click to expand...
Click to collapse
There is a command 0x19 (hook), I will try with hooking first and see whats happening!
zxz0O0 said:
Check TA.img from locked phone Unit 0x1046B is there with size 0x10. You can also check appsboot loader, if the device is rooted it deletes this unit.
I have used your ta_gen and it had unit 0x1046B inside resulted custreset.ta. You can flash this unit in emergency mode, but not normal mode (see previous post).
Click to expand...
Click to collapse
You need to change first argument in ta "02" to "01" since these unit is in partition 01 but be carefull since I do not know if some units from partition 02 exist in partition 01 since if you flash wrong data you can get brick! My tool was helper tool only for unbricking devices, I need to modify my tool a bit for that since I was not know about partitions in ta!
You can use miscta_read_unit from libmiscta.so to read this unit.
Code:
static int (*_miscta_read_unit)(int TAUnit, void* buf, int* size)
But you need system or root privileges.
Hopefully you can update your ta_gen tool since it could not unbrick my device. There should be a command to format TA (maybe 0x0B?). Maybe we can send this command before restoring TA backup for successful unbrick.
zxz0O0 said:
You can use miscta_read_unit from libmiscta.so to read this unit.
Code:
static int (*_miscta_read_unit)(int TAUnit, void* buf, int* size)
But you need system or root privileges.
Hopefully you can update your ta_gen tool since it could not unbrick my device. There should be a command to format TA (maybe 0x0B?). Maybe we can send this command before restoring TA backup for successful unbrick.
Click to expand...
Click to collapse
Which device you have? If your ta partition is bricked or formated you will have chance to unbrick only by emmc tool or by jtag tool!
Commands in s1 protocol:
Code:
#define CMD_LOADER_INFO "\x00\x00\x00\x01" /* loader info (hook phone in flashmode) */
#define CMD_FLASHMODE_OFF "\x00\x00\x00\x04" /* Kick device off flashmode */
#define CMD_WRITE_SIN_HEADER "\x00\x00\x00\x05" /* write SIN header */
#define CMD_WRITE_SIN "\x00\x00\x00\x06" /* write SIN */
#define CMD_GET_LAST_ERROR "\x00\x00\x00\x07" /* Get last error */
#define CMD_OPEN_TA "\x00\x00\x00\x09" /* open TA (takes the partition number as parameter) */
#define CMD_CLOSE_TA "\x00\x00\x00\x0A" /* close TA */
#define CMD_READ_TA "\x00\x00\x00\x0C" /* read TA */
#define CMD_WRITE_TA "\x00\x00\x00\x0D" /* write TA */
#define CMD_DISABLE_VERIFICATION "\x00\x00\x00\x19" /* Disable Final Verification check ? */
Not sure about 0B and allso not going to try them since I allready changed my mainboard after bricking ta partition
Tried to read unit 1046B after writing coomand hook but stil no chance dumping them trought s1. In next few days I will focus on generating ta.img from s1 dump and will analyse things more
I have Z1 Compact and tried to recover using your ta_gen and s1tool. But still dead I don't own a jtag device nor have any experience using it.
Hey, I noticed while looking through the Stock Firmware AP file, that in meta-data/fota.zip there are .jar files that have to do with package signing. Only issue is that the zip is password protected. If someone has the Compute power and skills to decrypt a zip and look at the jar files and ****, maybe we could find a way to sign our own TWRP recoveries and roms. Just a thought, i'll post a link to the fota.zip file i was talking about in a bit if anyone wants to take a crack at it. (Google drive is taking forever to upload cause of AT&T's ****ty DSL speeds, sorry)
Download Link: htt*ps:/*/drive.*google*.com/file/*d/0B9tb-svjqaVD*b3Y0V0tXR3drSzA/vie*w?usp=sharing (Remove all *'s from link, stupid 10 post until you can post links limitation)
Thanks,
Lavavex
Did you saw this Thread?
https://forum.xda-developers.com/an...signing-boot-images-android-verified-t3600606
About fota.zip...
Did you heard about plain text attack?
In few Seconds... minutes done... no password required but you can unpack.
Best Regards
Yesterday I have download this fota.zip... and yes... same password as for instance from my prior test with:
SM-J330F and 1 more...
Here are the 3 keys to decrypt if somebody want try...
Code:
2b4d493c
6142b289
1b7024aa
Code:
Key0
Key1
Key2
I have used Advanced Archive Password Recovery from elcomsoft...
Best Regards
adfree said:
Yesterday I have download this fota.zip... and yes... same password as for instance from my prior test with:
SM-J330F and 1 more...
Here are the 3 keys to decrypt if somebody want try...
Code:
2b4d493c
6142b289
1b7024aa
Code:
Key0
Key1
Key2
I have used Advanced Archive Password Recovery from elcomsoft...
Best Regards
Click to expand...
Click to collapse
Which will allow unpacking of the above zip? I thought it needed a zip password.
osm0sis said:
Which will allow unpacking of the above zip? I thought it needed a zip password.
Click to expand...
Click to collapse
We never found the Password... but for Decryption you need only these 3 Keys...
They can be easily found in few Minutes... with the right Tool...
Code:
2b4d493c
6142b289
1b7024aa
Here Key0 Key1 Key2 for Samsungs fota.zip...
This is really no rocket science...
Simple read about plain-text attack...
You can see all filenames...
You can see all filesizes etc...
Many files are floating around the Internet... to create ZIP for attack...
Then result is in few Minutes possible... :angel:
Use these 3 Keys in Tool:
Code:
Advanced Archive Password Recovery
And try self to unpack...
Best Regards
Edit 1.
Screenshot added...
Then maybe more clear...
Trial Version have mabye limtations... but to see it work... it is enough to play with trial.
@adfree or to anyone who can answer.
Quick question, what are the legal limitations to what is going on here? I may or not have a file from inside the fota.zip, but will sharing it put me in the legal wrong? If it is within the legal boundaries, I'd be happy to upload it for anyone to take a look at, but I don't want to land on the wrong side of the law by doing so. Please do let me know, as this is the most exciting development we've had when it comes to bootloader unlocking in a while. Also, it seems as though we can't view the entirety of the contents of the fota.zip with the trial version of the zip extraction tool mentioned in this thread, so if someone with more knowledge about this can confirm we could unlock our bootloaders with the contents of the zip (based on what is currently known about this), I'd be happy to bite the bullet of paying for the premium version given we can do this within the boundaries of the law.
Thanks.
1.
Maybe you can answer your question self...
Samsung PROTECTED this ZIP with password.
2.
IMHO it is Kernel related...
Yeah I know... Boot is every irritating...
But it is not sboot.bin related...
3.
About decrypting all files...
There are floating around Command Line Tool...
Code:
pkcrack
Try to Google it...
I have not tried...
I am 1 click Button user...
Best Regards
zipdecrypt from the pkcrack package plus those 3 keys worked flawlessly. :good:
Edit: Crazy number of utilities in this zip, but no script to run them all, and a lot of references to external files. No smoking gun like a "sbootimg_signer" binary or anything to make their proprietary footer signature, and no Samsung signature files.
the password for that zip is fotatest1234
Correct. All fota zips passwords are fotatest1234
Drdra3 said:
Correct. All fota zips passwords are fotatest1234
Click to expand...
Click to collapse
@lavavex , @osm0sis
Yes it is, but now the question still to be answered is, do the tools within the fota.zip file, actually work for legitimately repacking the boot/recovery image? Because in the fota.zip I checked from Android Pie's release it mentioned the "user/test-keys" and very much so had all of the compiled tools to actually patch a system and create and ADB flashable zip for stock recovery.
Could we technically make a signed sideloadable update.zip if the the update package was created on the device itself? The scripts included, along with the updated compiled binary tools, really do seem to be the Toolkit we've been looking for but have overlooked. I haven't tested it out fully, but I'm still reading about how to proceed. It isn't just the S7 either. So are the tools customized to the device, the android branch, or the bootloader?
Delgoth said:
@lavavex , @osm0sis
Yes it is, but now the question still to be answered is, do the tools within the fota.zip file, actually work for legitimately repacking the boot/recovery image? Because in the fota.zip I checked from Android Pie's release it mentioned the "user/test-keys" and very much so had all of the compiled tools to actually patch a system and create and ADB flashable zip for stock recovery.
Could we technically make a signed sideloadable update.zip if the the update package was created on the device itself? The scripts included, along with the updated compiled binary tools, really do seem to be the Toolkit we've been looking for but have overlooked. I haven't tested it out fully, but I'm still reading about how to proceed. It isn't just the S7 either. So are the tools customized to the device, the android branch, or the bootloader?
Click to expand...
Click to collapse
Presumably what I previously said still stands:
osm0sis said:
Crazy number of utilities in this zip, but no script to run them all, and a lot of references to external files. No smoking gun like a "sbootimg_signer" binary or anything to make their proprietary footer signature, and no Samsung signature files.
Click to expand...
Click to collapse
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.
The last few weeks I have been reverse engineering this model in Ghidra looking for hint's on how to unlock the bootloader of this device, I have tried many methods and have come up short. First thing I would like to mention the unlock.bin is most definitely stored in the misc partition after a factory reset, Most interestingly the unlock able variants store the unlock.bin in its complete form ready for unlock once transferred to a new hex document with a length of 0x3FE, In misc this key is stored between 0x6C004 and 0x6C218. That being said on the locked variant it is also recorded to misc only when booting from a us997 aboot but unlike the unlocked variant it is encrypted the cert being written to misc is that of aboot and starts with UNLOCK_RSA_020 which can be extracted from aboot with binwalk. Theoretically by cross flashing images from other devices it is possible to trick it into writing the key to misc. What I need to know is I understand the unlock key is stored in rpmb protected memory only accessible by trustzone, would it be possible to chroot a linux distro on top of system and mount secure world without complete trustzone privilege? I have temp root and it is possible to make it persistent by modifying system but unfortunately system is not referenced in /proc/mounts it is only occasionally mountable in rw for a fraction of a second. This is easily bypassed by passing temp root and starting a system mount app with the am command in root. Also If I were to make a full backup of mmcblk0 would secure world be contained in such a backup or is it accessed via spi? Any help is appreciated thank you in advanced.
SpliffWellington said:
The last few weeks I have been reverse engineering this model in Ghidra looking for hint's on how to unlock the bootloader of this device, I have tried many methods and have come up short. First thing I would like to mention the unlock.bin is most definitely stored in the misc partition after a factory reset, Most interestingly the unlock able variants store the unlock.bin in its complete form ready for unlock once transferred to a new hex document with a length of 0x3FE, In misc this key is stored between 0x6C004 and 0x6C218. That being said on the locked variant it is also recorded to misc only when booting from a us997 aboot but unlike the unlocked variant it is encrypted the cert being written to misc is that of aboot and starts with UNLOCK_RSA_020 which can be extracted from aboot with binwalk. Theoretically by cross flashing images from other devices it is possible to trick it into writing the key to misc. What I need to know is I understand the unlock key is stored in rpmb protected memory only accessible by trustzone, would it be possible to chroot a linux distro on top of system and mount secure world without complete trustzone privilege? I have temp root and it is possible to make it persistent by modifying system but unfortunately system is not referenced in /proc/mounts it is only occasionally mountable in rw for a fraction of a second. This is easily bypassed by passing temp root and starting a system mount app with the am command in root. Also If I were to make a full backup of mmcblk0 would secure world be contained in such a backup or is it accessed via spi? Any help is appreciated thank you in advanced.
Click to expand...
Click to collapse
Hey. While I can't help you, because I don't know about all that, I just wanted to let you know that we're all rooting for you (pun intended). That said, how's progress going? Is it close to completion, or has the project been shut down?
SpliffWellington said:
The last few weeks I have been reverse engineering this model in Ghidra looking for hint's on how to unlock the bootloader of this device, I have tried many methods and have come up short. First thing I would like to mention the unlock.bin is most definitely stored in the misc partition after a factory reset, Most interestingly the unlock able variants store the unlock.bin in its complete form ready for unlock once transferred to a new hex document with a length of 0x3FE, In misc this key is stored between 0x6C004 and 0x6C218. That being said on the locked variant it is also recorded to misc only when booting from a us997 aboot but unlike the unlocked variant it is encrypted the cert being written to misc is that of aboot and starts with UNLOCK_RSA_020 which can be extracted from aboot with binwalk. Theoretically by cross flashing images from other devices it is possible to trick it into writing the key to misc. What I need to know is I understand the unlock key is stored in rpmb protected memory only accessible by trustzone, would it be possible to chroot a linux distro on top of system and mount secure world without complete trustzone privilege? I have temp root and it is possible to make it persistent by modifying system but unfortunately system is not referenced in /proc/mounts it is only occasionally mountable in rw for a fraction of a second. This is easily bypassed by passing temp root and starting a system mount app with the am command in root. Also If I were to make a full backup of mmcblk0 would secure world be contained in such a backup or is it accessed via spi? Any help is appreciated thank you in advanced.
Click to expand...
Click to collapse
Hey! Though you probably already have root, on the off-chance you don't, use this temp root! Hope this helps you out. Just make sure to rollback to Android 8, follow the guide, and read the posts. Should work fine on H873.
https://forum.xda-developers.com/lg...-as993-wip-t3908213/post80908533#post80908533