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.
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?
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