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.
Related
Hi !!
I'm sorry if I write about talking before but I search for 2 dayes internet (Most link coming from xda ) without success.
I'm pretty sure that is not possible to do on Trinity due to bootloader limitation but I want a last confirm before to flash my device.
My boot loader is a Des' Crash-Proof SPL:
TRIN100
IPL-0.50
TRIN100
SPL-9.99 CP
After I play with the WM6 registry it don't load th OS after reset.
I wondering if is it possible to dump the ROM (The mass storage part) to mount in a linux box from the boot loader.
I read that the Trinity lack of the s2d command and also the rbmc didn't work.
There is any other way to do it
Off course I can't use pdocread.exe due to the OS is not loaded on the Trinity.
Thanks in advance and sorry for my english.
Carlo.
Hi again.
I was able to read ROM whit the rbmc command using the follow command:
password BsaD5SeoA
set 1e 1
task32
rbmc >/tmp/dump.bin 0x3100 0x17900
The problem is that the output is show on the screen and not writed in the file.
I tried on linux using HTCFlasher and mtty on WIndows whit the > and without.
Any Idea ?
Carlo
Try QMAT too, although it's not meant to be used with Trinity, it supports rbmc dumping.
Thanks, I'll try it tonight.
Here's an rbmc partition dumper I've created for dumping os, storage and ext rom. Storage partition doesn't seem to be readable this way...
You need to have a security unlocked device or HSPL that allows rbmc when device is not security unlocked.
Hope this helps...
Thanks for the command, I tried and it don't work.
I have the Des' Crash-Proof SPL on my Trinity and the rbmc command work but I have to give the follow commands before use it.
password BsaD5SeoA
set 1e 1
task32
is your command supplied it before to dump or there is any command line option to pass it to the command ?
Works on my trinity allright... task 32 is not required, btw.
Did you manage to get QMAT working/dumping?
I tried more times but I have allways this message:
C:\Temp2>rbmc.exe
HTC RBMC reader version 1.0, Dec 19 2008
Reading OS.nb...
WARNING: rbmc OS.nb command failed!
Reading Storage.nb...
WARNING: rbmc Storage.nb command failed!
Reading ExtROM.nb...
WARNING: rbmc ExtROM.nb command failed!
Read 0xC1B144 bytes in 0d:00h:00m:01s.953ms
HTCSBye!>.L.HTCE
I switch the Trinity to the bootloader screen and then I plug the usb and ru the command with no args.
Where I wrong ? I tried without ActiveSync open and with it opne with the usb connection disbled.
No, I was unable to use QMAT, the manuals is little different from the version and don't explain the very first operation to recognise the PDA to the program.
Instend I was able to capture the rmbc output on my linux box and minicom on usb but I get error after a while the program is dumping (The same I got on the screen using mtty) and then I'm little confusing about partition dimension showed by the "info 8" command
Bye.
What happens when you manually issue "rbmc c:\temp\os.bin OS" in mtty or minicom?
I start minicom with the capture option active then I use the command
Cmd>rbmc a 0x3100 0x17900
Then the dump start
Cmd>rbmc a 0x3100 0x17900
GetExtRomData+(): *pszPathName=a, dwStartAddress=57600000, dwLength=8C08DAA0
:F=a :A=57600000 :L=8C08DAA0 :rbmc= HTCS¼Ñÿÿùÿ0ÖÿÿùÿRPQQ"RTP¤QP>Öÿÿùÿ¤ìÿÿùÿÔÿÿùÿ9Öÿÿùÿ<Öÿÿùÿ=Öÿÿùÿina
condominiale
[.....]
,(*"(B+&*0ùÿNANDFlashReadSectorWithSectorInfo: dwBlockIndex=0x400
NANDFlashReadSectorWithSectorInfo: Address over boundary!!!
rbmc: read data error at 0x8000000
In the [...] I got about 1 MByte of data.
My I was to dump th user partition to recover same data, not the OS.
This syntax is not valid:
rbmc a 0x3100 0x17900
1. Do not use 0x prefix for offset and length
2. Use actual flash offsets (starting at 50000000 (hex))
Can you try this exact command?
rbmc c:\temp\os.bin OS
This is the command rbmc.exe executes and it seems to be failing on your Trinity.
I tried and that is what I had:
C:\temp>rbmc c:\temp\os.bin OS
HTC RBMC reader version 1.0, Dec 19 2008
Reading OS.nb...
WARNING: rbmc OS.nb command failed!
Reading Storage.nb...
WARNING: rbmc Storage.nb command failed!
Reading ExtROM.nb...
WARNING: rbmc ExtROM.nb command failed!
Read 0xC1B144 bytes in 0d:00h:00m:02s.031ms
HTCSBye!>.L.HTCE
C:\temp>
cybor said:
I tried and that is what I had:
C:\temp>rbmc c:\temp\os.bin OS
HTC RBMC reader version 1.0, Dec 19 2008
Reading OS.nb...
WARNING: rbmc OS.nb command failed!
Reading Storage.nb...
WARNING: rbmc Storage.nb command failed!
Reading ExtROM.nb...
WARNING: rbmc ExtROM.nb command failed!
Read 0xC1B144 bytes in 0d:00h:00m:02s.031ms
HTCSBye!>.L.HTCE
C:\temp>
Click to expand...
Click to collapse
Can you do it in mtty?
Ok, sorry, I missunderstand.
Cmd>password BsaD5SeoA
Pass.
HTCST ÚÈÒHTCEPassWord: BsaD5SeoA
Cmd>set 1e 1
Cmd>rbmc c:\temp\os.bin OS
Command error !!!
Ok, it looks like your SPL doesn't support rbmc command, but if you do "rbmc 50000000 1" in mtty that works?
Yes, it work.
Cmd>rbmc 50000000 1
GetExtRomData+(): *pszPathName=50000000, dwStartAddress=1, dwLength=8C08DAA0
rbmc=8DAA0
Cmd>
But it work only if I supply the "task 32" command after the "password .. " and "set 1e 1"
Colud you modify your command to supply the "task 32" command, maybe by a switch ?
Finally it work !!
I mean your command.. after the message before I tried this way.
I connect to the bootloader with the patched version of TeraTerm (To have the copy and paste function ), then I supply the three commands like the message above and finally I close the Teraterm and lunched your command with no parameters and here what I get:
C:\Temp0\rbmc>rbmc.exe
HTC RBMC reader version 1.0, Dec 19 2008
Reading OS.nb...
0x4d50800 bytes read
Reading Storage.nb...
WARNING: rbmc Storage.nb command failed!
Reading ExtROM.nb...
WARNING: rbmc ExtROM.nb command failed!
Read 0x55628D8 bytes in 0d:00h:02m:02s.125ms
HTCSBye!>.L.HTCE
How you can watch it don't read the Storage.nb and the ExtROM.nb, but now I can get OS.
So I think that the "task 32" is mandatory in with the HardSPL I got in my Trinity.
Witch HardSPL do you use for test your command ?
cybor said:
So I think that the "task 32" is mandatory in with the HardSPL I got in my Trinity.
Witch HardSPL do you use for test your command ?
Click to expand...
Click to collapse
Yeah, well, this seems to be the way HardSPL works, you only get access to locked commands after faking security lock status with "task 32". I've added this command to rbmc.exe, however I want to make it more generic before I post the updated version, because dumping storage doesn't work so far.
I'm using MFG SPL 1.05 patched to allow rbmc, this shouldn't be relevant though.
Ok, so attached is an updated version of rbmc.exe.
It will work just like the old version without any parameters, but you can specify the same parameters as you would feed to rbmc command too now.
E.g. to dump storage you can do
C:\>rbmc.exe storage.bin Storage
However due to a bug in SPL this won't work, it will produce an error message showing the starting offset of storage partition though.
Grab that offset, substract it from 0x60000000 to get the correct storage size and rub rbmc.exe again with parameters:
C:\>rbmc.exe storage.bin 0x53540000 0xACAC0000
You should have a dump of storage partition (albeit not excatly 0xACAC0000 bytes) in storage.bin file as a result. Note that resulting dump has NAND flash block status data (0x10 bytes every 0x200 bytes) that you may need to strip to get an image of storage partition you can work on.
Good luck!
Thanks for this new realese, it work fine.
I have a problem to understand how to calculate the offset.
When I run
rbmc.exe storage.bin Storage
I get:
Dumping rbmc storage.bin Storage to storage.bin...
ERROR: rbmc storage.bin Storage command failed; last message:
"Storage address error.(0x54DC0000, 0xB301000) "
What I must subtract from 0x60000000 to get the offset and which is the other value in the last example you write.
C:\>rbmc.exe storage.bin 0x53540000 0xACAC0000
I'm sorry to waste your time, but I tried to understand but I fail, but I want to reach the end because in future a tool like this will be very usefull to recover data froma crashed Trinity.
Disclaimer:
PoC was made for testing and educational purposes, ME is not responsible for what you do on/with your device using PoC, you must agree that you using PoC on your own risk, I am not responsible if you brick your device, you lost your personal data or anything else!
Hello!
First of all this tool fully replaces DRM fix! So do not use our tool with DRM fix!!! I'm going to explain what is this, how it working. Everybody know what drm fix doing and everybody know whats happening when bootloader is unlocked. Ok. This PoC is designed for unlocked devices and makes things identic to having bootloader never unlocked! Which mean this is for peoples who have backup of the trim area BEFORE unlocking bootloader! This PoC mounts your trim area backup (TA.img) to the kernel loop5 device which makes your trim area like real trim area partition (in our case it mounts your backup TA.img and uses it instead of unlocked trim area partition) so everything after android boot up is like having locked bootloader which mean all drm keys, widevine keys and etc is fully functional! And most better thing, we can use PoC with AOSP, CM or whatever for having trim area fully functional!!!
Do in mind this is for stock roms only! Only nougat and marchmallow by now, some of before marchmalow too.
Supported kernel images:
- SIN (kernel.sin)
- ELF (kernel.elf)
- IMG (boot.img)
So you no need to extract elf from kernel since our tool extract any sony format, sin,img,elf autodetection.
Credits:
- I must give big creadits to @steom since he tested things very deeply on his xperia x compact, he tested things more than 7 days, he tested it very frequently and I must say... big respect to him! Thanks man!
- Also respect to @tobias.waldvogel ! His mkinitfs source code (idea about #perm appended to file names) helped me a lot making our tool for windows. His scripts helped me a lot figuring out all things! Thanks man! Original forum thread for tobias.waldvogel great work -> https://forum.xda-developers.com/xp...oot-automatic-repack-stock-kernel-dm-t3301605
- Uhh sorry, forgot to give credit to @osm0sis for great extended version of the boot image tools https://github.com/osm0sis/mkbootimg
- @serajr mate sorry, forgot your great scripts!
- @the_laser for figuring out that poc is working by directly using TA.img, no need to mount to loop, thanks man!
- @mbc07 for this post https://forum.xda-developers.com/showpost.php?p=73232574&postcount=1547
How to extend our tool:
I have reserved some spaces for everybody who need to extend our tool (tool looks for user script.sh or script.bat), so if tool found user script tool will execute that scipt which mean everybody can make own scipt to extend ramdisk patching mechanism (e.g. to add su... etc). If tool didn't find user script, tool pause so you have enough time to modify everything you need manualy and continue tool by pressing any key on your keyboard. Tool didn't delete output folder so you can use for example something from unmodified boot.img-ramdisk.gz if you need. Also sepolicy binary file have a backup (backupsepolicy) so you can use it too if you need.
How to fix byself denials from dmesg:
This explains how: https://forum.xda-developers.com/showpost.php?p=70955889&postcount=47
And finaly this is a tool: https://forum.xda-developers.com/showpost.php?p=70973513&postcount=120
Everybody and every device is involved! You need at least good knownledge in getting logcat and dmesg if you want to help here! You can suggest, speak whatewer you want in this thread since this thread is for everybody! Need your words about tool and suggestions! Please if you want to post logcat or dmesg please use http://www.pastebin.com for it! If you need tool working for your device please get involved here!
. .
munjeni said:
That mean we can use stock camera blobs finaly with AOSP, CM or whatewer!!!
Click to expand...
Click to collapse
This will change everything regarding (not stock based) custom ROMs... If this is proved to work...
Outstanding job! Even if this post has no logcat/dmesg attached I felt like that I have to say some respectful words! :good:
Bootloop on nougat is solved now! New version is out! Soo close to get it working on nougat
I officially declare that the @munjeni PoC work! also with Nougat!
A new era is begun!
Does it mean, that camera will now work well on Xperias with Nougat AOSP?
Anyway it's big success.
haha was thinking of the same thing some weeks ago
tad_static can be cheated easily but what about suntrold and rmt_storage?
Where are your sources please?
steom said:
I officially declare that the @munjeni PoC work! also with Nougat!
A new era is begun!
Click to expand...
Click to collapse
Bro i want to test on my z5 dual but dont know what should i do it
can you explain clearly?
thanks
having problems
Code:
hash:0x54288A7A calc_hash:0x54288A7A
hash:0x4CBAA939 calc_hash:0x4CBAA939
hash:0x9B8793E3 calc_hash:0x9B8793E3
hash:0x482AF9EB calc_hash:0x482AF9EB
device: F8331
serial number: CB512BEE32
drm key: 0001046B 0010 44 98 8A 61 A3 B2 10 48 02 19 38 59 73 7F 7E 52
Trim area dump is a valid.
Locked bootloader.
Deleting old folder ramdisk if exist...
if exist ramdisk (rd ramdisk /s/q)
returned: 0.
New directory ramdisk created.
Created ouput folder "out"
opening kernelX.sin
unable to open kernelX.sin
Kernel dump tool returned an error!
Mmm.... rename kernel.sin to kerlelX.sin helped
Using EliteKernelV3 (Z3C) did not work with following output:
Code:
------------------------------------------------------------------------
Nougat Trim Area PoC kernel image patcher by Munjeni @ 2017
------------------------------------------------------------------------
hash:0x037C9C1E calc_hash:0x037C9C1E
hash:0x90A0164B calc_hash:0x90A0164B
hash:0x04E5A139 calc_hash:0x04E5A139
device: D5803
serial number: YT911BPNF7
drm key: 0001046B 0010 ED EE 37 63 7B D8 AD 8B 03 C4 8C 1C 2A 3C 61 B0
Trim area dump is a valid.
Locked bootloader.
Deleting old folder ramdisk if exist...
if exist ramdisk (rd ramdisk /s/q)
returned: 0.
New directory ramdisk created.
Created ouput folder "out"
opening boot_Z3c.img
boot_Z3c.img is Android image format.
Dumping to out...
BOARD_KERNEL_CMDLINE androidboot.hardware=qcom user_debug=31 msm_rtb.filter=0x3b7 ehci-hcd.park=3 androidboot.bootdevice=msm_sdcc.1 vmalloc=400M dwc3.
maximum_speed=high dwc3_msm.prop_chg_detect=Y androidboot.selinux=permissive
BOARD_KERNEL_BASE 00000000
BOARD_NAME
BOARD_PAGE_SIZE 2048
BOARD_KERNEL_OFFSET 00008000
BOARD_RAMDISK_OFFSET 02000000
BOARD_TAGS_OFFSET 01e00000
BOARD_DT_SIZE 284672
Done.
Gunziping...
setting up infflate...
infflating...
infflate returned: -3
gzpipe: invalid or incomplete deflate data
Error gunziping boot_Z3c.img!
Drücken Sie eine beliebige Taste . . .
I compared the the files in folder "out" with the one of osmosis' Android Image Kitchen:
This is TA Tool: boot.img-ramdisk.gz
And this AIK: boot_Z3c.img-ramdisk.cpio.gz
But both with exact the same file size...
Ramdisk is not decompressed successfully.... Looks for me like an mismatch while decompressing cpio and gunzip.
My thought: Your tool is expecting gzip files - But EliteKernelV3 was compressed first with cpio and then with gzip.
kernel.sin and kernel.elf are working fine!
Is lollipop in progress or?
for z1 that would be great
maksim_kw said:
Mmm.... rename kernel.sin to kerlelX.sin helped
Click to expand...
Click to collapse
Come one! You have to adjust the starting batch file according to your kernel file name
fluffi444 said:
Using EliteKernelV3 (Z3C) did not work with following output:
I compared the the files in folder "out" with the one of osmosis' Android Image Kitchen:
This is TA Tool: boot.img-ramdisk.gz
And this AIK: boot_Z3c.img-ramdisk.cpio.gz
But both with exact the same file size...
Ramdisk is not decompressed successfully.... Looks for me like an mismatch while decompressing cpio and gunzip.
My thought: Your tool is expecting gzip files - But EliteKernelV3 was compressed first with cpio and then with gzip.
kernel.sin and kernel.elf are working fine!
Click to expand...
Click to collapse
It's for stock kernel. EliteKernel has own fix method.
nailyk said:
haha was thinking of the same thing some weeks ago
tad_static can be cheated easily but what about suntrold and rmt_storage?
Where are your sources please?
Click to expand...
Click to collapse
Hi! Till after ta is mounted whole things working like real trim area on locked bootloader! Things which might not work (untested curently) is fota and other things, but I realy not going to mess with it, you guys can make your own scripts for fine tune purpose! Source code as I promised after my ban not going to be public available because my ban.
vato4001 said:
Is lollipop in progress or?
for z1 that would be great
Click to expand...
Click to collapse
I didn't tried, probably it will work or error during compilation.
x_one said:
EliteKernel has own fix method.
Click to expand...
Click to collapse
You know that I know that - But I really prefer this TA solution than DRM fix which I removed from Kernel as soon as I got the manual TA mod working on EliteKernel.
You know that I have an working EliteKernel with TA mount... But it would also be nice to get this tool working for such custom kernel as well.
Anyway - I really appreciate @munjeni 's work. And if the answers is ONLY for stock kernel than it's fine for me as well (the manual way works - as I said)
fluffi444 said:
You know that I know that - But I really prefer this TA solution than DRM fix which I removed from Kernel as soon as I got the manual TA mod working on EliteKernel.
You know that I have an working EliteKernel with TA mount... But it would also be nice to get this tool working for such custom kernel as well.
Anyway - I really appreciate @munjeni 's work. And if the answers is ONLY for stock kernel than it's fine for me as well (the manual way works - as I said)
Click to expand...
Click to collapse
In general it will work on any kernel since I have made some free space for userscripts! It will come later till after poc starts working!
New version is out and finaly it is a first one working for nougat! Only one problem thought is tool have an bug which I need to figure our (you must copy TA.img to the /data/local/tmp) folder to get poc working! I will solve that soon!
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
Greetings,
I'm new to these forums, but have been into the Android development/customization scene since the original Motorola Droid. I recently purchased one of the (in)famous Chinese 8227L head units and have started doing some things to it. I was surprised to find that there are a lot more people out there with questions than answers when it comes to these things. So I figured I'd introduce myself with a quick tutorial, a small utility release for now. I have work in progress on a ROM release for these things. There are quite a few issues to get past as well as different boards to account for, so stay tuned for that sometime in the coming weeks. For now, let's get started with customizing the boot screen.
One of the simplest, yet most satisfying modifications one can do to any Android device is changing logo image that is displayed when the unit boots. For units like ours, running MediaTek hardware there are a couple of extra steps involved, but the process is still very simple. I was able to find a few different utilities that could be downloaded online to do this, but none of them seemed to work for these head units. I suspect our units use a slightly different header than the MediaTek phones those utilities are designed for, but that is a technical issue beyond the scope of this tutorial.
Disclaimer: These steps have been tested repeatedly on my device, and it's my assumption that they will work on any head unit based on the ac8227l, but I have obviously not tested every single one of them. There is always an inherent risk when you modify the software on any device that you own. This risk is your own, and I am not responsible for any damage you do to your device by following this tutorial!
Your unit does not need to be rooted to do this mod, but you will need to have the bootloader unlocked.
Pre-requisites:
logo.bin file from your ROM backup (You DO have a backup, don't you?)
Ability to read and follow directions
Access to a Linux command line OR the ability to run python applications on your system
SP Flash Tool or one of its equivalents, or a custom recovery installed, such as TWRP.
The boot logo is contained in the logo.bin file from your ROM. More accurately, the logo.bin file IS the boot logo for your ROM, with a 512 byte header attached to it. We need to separate the two in order to change the image that gets displayed.
This can be done very simply from the linux command line via the following command:
Code:
dd if=logo.bin of=logo.bmp skip=1
This command simply reads in the logo.bin file and writes it back out after skipping the first 512 bytes. dd has an optional argument bs= which stands for block size. It defaults to 512 bytes. So the skip=1 is simply
telling dd to skip the first 512 bytes when it writes the file back out. The result is a 1024x600 pixel bitmap image. However, we're going to need that header in a later step, so write it out to its own file using:
Code:
dd if=logo.bin of=header.bin count=1
This command simply writes the first block (remember block size is 512 bytes by default) out to a file and then stops, so we have our 512 byte header saved for later.
Now, you can either edit the logo.bmp file or replace it with your own image file. However you do it, just ensure that you end up with a 1024x600 pixel bitmap image in 8-bit RGB color. The following steps assume we have generated such an image in the same directory we were just working in, and named it newlogo.bmp. To join the header file to your new image, use the following command:
Code:
cat header.bin newlogo.bmp > newlogo.bin
This command concatenates (puts together) the two files back into one file. The order is important. The header needs to be at the start of the resulting file, so it must be the first argument you pass to cat! The resulting newlogo.bin is ready to be flashed to your head unit. Congratulations, enjoy your new boot screen! If you save the header.bin file, you can always use it to make more boot logos later.
Alternative method for Windows users or Linux users who would prefer to have a utility:
I have written a simple command line utility in python to do this process for you. You will need to have python installed to utilize it. It's written in python 3.8 but will work on some earlier versions, I think. You can get it from my github repository at https://github.com/threadreaper/logobin.git or from your command prompt using the PyPi repository through pip3. pip3 should be installed automatically when you install python 3. Use this command to fetch the utility:
Code:
pip3 install logobin
If you've elected to clone the git repository instead of using PyPi, you need to cd to the directory you downloaded it to (this should be the directory with the setup.py file) and install using:
Code:
pip3 install .
Whichever method you used, if everything went correctly, the "logobin" utility should now be available to you from your command line. To unpack an existing logo.bin image:
Code:
logobin -u logo.bin
And to pack an image with a header file back into a flashable bin file:
Code:
logobin -p header.bin logo.bmp (filename)
The filename argument above is optional and defaults to logo.bin if you don't select one. The utility can also be used to check a file for the presence of a valid header, using the -c switch:
Code:
logobin -c logo.bin
In this manner, you can check your stock logo.bin file to make sure it will work with this method before you start. You can also use it to check an extracted header to make sure it's correct, and you may also want to use it to verify that your logo.bin file has been packed correctly before you flash it to your phone.
I have attempted to make both the utility and this tutorial as simple to follow as possible, but if you have any questions, feel free to ask.
Excellent tutorial? I have a non rooted Enon 8227 unit and I’m having problem with it, could you be so kind to point me to a tutorial to make a rom backup please? all the stuff in my unit are blocked and I can t almost change anything.
Thank you.
Sent from my iPhone using Tapatalk Pro
Good day sir.
Could you guide me as to how to extract the logo.bin file please? I couldn't really find it.
I have a PX6 STM32 device.
Thanks!
arturojgt said:
Excellent tutorial? I have a non rooted Enon 8227 unit and I’m having problem with it, could you be so kind to point me to a tutorial to make a rom backup please? all the stuff in my unit are blocked and I can t almost change anything.
Thank you.
Sent from my iPhone using Tapatalk Pro
Click to expand...
Click to collapse
I'm planning to do a full tutorial on this too, but the short version is as follows:
Get SP Flashtool, and find a scatter file that will work for your device. That can be difficult sometimes, as there is a quite a bit of variance between units. Fortunately, to make your initial backup the only info you need in your scatter file is for the preloader, and as far as I know that is always the same. So if you don't already have a scatter file copy this:
Code:
#########################################__WwR_MTK_2.50__###################################################
#
# General Setting
#
#########################################__WwR_MTK_2.50__###################################################
- general: MTK_PLATFORM_CFG
info:
- config_version: V1.1.2
platform: MT3367
project: 8227l_demo
storage: EMMC
boot_channel: MSDC_0
block_size: 0x20000
############################################################################################################
#
# Layout Setting
#
############################################################################################################
- partition_index: SYS0
partition_name: preloader
file_name: preloader_8227l_demo.bin
is_download: true
type: SV5_BL_BIN
linear_start_addr: 0x0
physical_start_addr: 0x0
partition_size: 0x40000
region: EMMC_BOOT_1
storage: HW_STORAGE_EMMC
boundary_check: true
is_reserved: false
operation_type: BOOTLOADERS
is_upgradable: true
empty_boot_needed: false
reserve: 0x00
And save it as scatter.txt
Select this file as your scatter file in SP Flashtool, and click on the memory test tab. Uncheck all the options under memory test except for RAM test. Remove external power from the unit entirely, click start on the memory test, and then connect the 4 pin usb to your PC. It should sync up and do the memory test. Once the memory test is complete you will have the sizes of BOOT_1, BOOT_2 and EMMC_USER. Use these values with the readback option to make your backup. Use 0x0 as the start address each time, and the size value you got from the memory test. Back up BOOT_1, BOOT_2 and EMMC_USER and save them somewhere. This is the most basic backup that you can always use to go back to stock. Using tools like MTK Droid Tools and WWR MTK it is possible to split EMMC_USER backup into all of your separate partition backups.
Good luck, and keep an eye out for a more detailed walkthrough coming up soon!
kingdew11 said:
Good day sir.
Could you guide me as to how to extract the logo.bin file please? I couldn't really find it.
I have a PX6 STM32 device.
Thanks!
Click to expand...
Click to collapse
See my reply above about making a backup of your device. You get your logo.bin file from the extracted backup.
Please add your PayPal account to your xda so we can buy you some beer for the amazing work you're doing
Sent from my MI 9 using Tapatalk
zetlaw01 said:
Please add your PayPal account to your xda so we can buy you some beer for the amazing work you're doing
Sent from my MI 9 using Tapatalk
Click to expand...
Click to collapse
I don't drink beer, but you can always buy me a coffee
Thanks for information.
I want to backup with Flastool or similar program, is that possible?
and how do I root.
thank you
bicer79 said:
Thanks for information.
I want to backup with Flastool or similar program, is that possible?
and how do I root.
thank you
Click to expand...
Click to collapse
I posted instructions on backing up a unit two posts above your reply ^^. To root, find a compatible twrp image and flash it, then install magisk from twrp. I will be doing more detailed tutorials on these steps in the near future, but as I mentioned there is a crash course on SP-flashtool backup in this very thread, and the root process is pretty much the same for these units as it is for many others, assuming you find a working twrp image for your particular device, so you shouldn't have too much trouble finding a walkthrough if you need one.
threadreaper said:
Greetings,
I'm new to these forums, but have been into the Android development/customization scene since the original Motorola Droid. I recently purchased one of the (in)famous Chinese 8227L head units and have started doing some things to it. I was surprised to find that there are a lot more people out there with questions than answers when it comes to these things. So I figured I'd introduce myself with a quick tutorial, a small utility release for now. I have work in progress on a ROM release for these things. There are quite a few issues to get past as well as different boards to account for, so stay tuned for that sometime in the coming weeks. For now, let's get started with customizing the boot screen.
One of the simplest, yet most satisfying modifications one can do to any Android device is changing logo image that is displayed when the unit boots. For units like ours, running MediaTek hardware there are a couple of extra steps involved, but the process is still very simple. I was able to find a few different utilities that could be downloaded online to do this, but none of them seemed to work for these head units. I suspect our units use a slightly different header than the MediaTek phones those utilities are designed for, but that is a technical issue beyond the scope of this tutorial.
Disclaimer: These steps have been tested repeatedly on my device, and it's my assumption that they will work on any head unit based on the ac8227l, but I have obviously not tested every single one of them. There is always an inherent risk when you modify the software on any device that you own. This risk is your own, and I am not responsible for any damage you do to your device by following this tutorial!
Your unit does not need to be rooted to do this mod, but you will need to have the bootloader unlocked.
Pre-requisites:
logo.bin file from your ROM backup (You DO have a backup, don't you?)
Ability to read and follow directions
Access to a Linux command line OR the ability to run python applications on your system
SP Flash Tool or one of its equivalents, or a custom recovery installed, such as TWRP.
The boot logo is contained in the logo.bin file from your ROM. More accurately, the logo.bin file IS the boot logo for your ROM, with a 512 byte header attached to it. We need to separate the two in order to change the image that gets displayed.
This can be done very simply from the linux command line via the following command:
Code:
dd if=logo.bin of=logo.bmp skip=1
This command simply reads in the logo.bin file and writes it back out after skipping the first 512 bytes. dd has an optional argument bs= which stands for block size. It defaults to 512 bytes. So the skip=1 is simply
telling dd to skip the first 512 bytes when it writes the file back out. The result is a 1024x600 pixel bitmap image. However, we're going to need that header in a later step, so write it out to its own file using:
Code:
dd if=logo.bin of=header.bin count=1
This command simply writes the first block (remember block size is 512 bytes by default) out to a file and then stops, so we have our 512 byte header saved for later.
Now, you can either edit the logo.bmp file or replace it with your own image file. However you do it, just ensure that you end up with a 1024x600 pixel bitmap image in 8-bit RGB color. The following steps assume we have generated such an image in the same directory we were just working in, and named it newlogo.bmp. To join the header file to your new image, use the following command:
Code:
cat header.bin newlogo.bmp > newlogo.bin
This command concatenates (puts together) the two files back into one file. The order is important. The header needs to be at the start of the resulting file, so it must be the first argument you pass to cat! The resulting newlogo.bin is ready to be flashed to your head unit. Congratulations, enjoy your new boot screen! If you save the header.bin file, you can always use it to make more boot logos later.
Alternative method for Windows users or Linux users who would prefer to have a utility:
I have written a simple command line utility in python to do this process for you. You will need to have python installed to utilize it. It's written in python 3.8 but will work on some earlier versions, I think. You can get it from my github repository at or from your command prompt using the PyPi repository through pip3. pip3 should be installed automatically when you install python 3. Use this command to fetch the utility:
Code:
pip3 install logobin
If you've elected to clone the git repository instead of using PyPi, you need to cd to the directory you downloaded it to (this should be the directory with the setup.py file) and install using:
Code:
pip3 install .
Whichever method you used, if everything went correctly, the "logobin" utility should now be available to you from your command line. To unpack an existing logo.bin image:
Code:
logobin -u logo.bin
And to pack an image with a header file back into a flashable bin file:
Code:
logobin -p header.bin logo.bmp (filename)
The filename argument above is optional and defaults to logo.bin if you don't select one. The utility can also be used to check a file for the presence of a valid header, using the -c switch:
Code:
logobin -c logo.bin
In this manner, you can check your stock logo.bin file to make sure it will work with this method before you start. You can also use it to check an extracted header to make sure it's correct, and you may also want to use it to verify that your logo.bin file has been packed correctly before you flash it to your phone.
I have attempted to make both the utility and this tutorial as simple to follow as possible, but if you have any questions, feel free to ask.
Click to expand...
Click to collapse
did you build twrp from source or port it for your device?
I was able to build TWRP from source, but I haven't released it due to some rather annoying bugs I haven't had time to sort out with it just yet.
threadreaper said:
I was able to build TWRP from source, but I haven't released it due to some rather annoying bugs I haven't had time to sort out with it just yet.
Click to expand...
Click to collapse
which bugs?
I am so delighted to see someone hitting on the hot iron. Looking forward to the detailed tutorial to take backup, unlock bootloader, customize my radio.