Related
Hello folks,
it's me again (RaymanFX aka Chris Hesse) and I want to introduce you to a little, but important project.
My goal is to finally be able to backup the 'boot' partition of our device in CWM and TWRP or others !
How can we get to that ?
Well, I already have an exact plan on how to do it.
1. Step : examining the boot partition (LNX) size and offsets
2. Step : invoke a kernel hack to parse the partition layers to the system at runtime (WARNING : This will only work on a hack-enabled kernel) - I will provide one.
3. Step : re-enable 'boot' partition backup (in TWRP, e.g.) I will recompile TWRP with newest code when the time is right
Ok, so what do we have ?
1. To examine these partition layout sizes and offsets, we have to strip of the hex value of !ANDROID or ANDROID! of /dev/block/mmcblk0 using the dd command.
I already did this.
Here's how to do it :
Code:
iMac21:~ RaymanFX$ adb shell
* daemon not running. starting it now on port 5037 *
* daemon started successfully *
~ # dd if=/dev/block/mmcblk0 of=/sdcard/20m.bin bs=1M count=20
20+0 records in
20+0 records out
20971520 bytes (20.0MB) copied, 1.271406 seconds, 15.7MB/s
~ # exit
iMac21:~ RaymanFX$ adb pull /sdcard/20m.bin /Users/RaymanFX/Desktop
2413 KB/s (20971520 bytes in 8.487s)
Then open a hex editor and search for the sring value 'ANDROID!' and copy that value.
Mine is :
Code:
0x37FFED
Now we have to convert this to get the sizes and offsets we need (I work together with Dees_Troy to resolve this).
-> To be fixed soon !
2. When we proceed, we need to invoke a kernel hack at compile time, so every old kernel needs to be recompiled.
-> I will provide a recompiled and hack-enabled harmony kernel soon
Code:
Here will be the required code fix; commit at my GitHub
3. And last but not least :
A new version of TWRP needs to be compiled to re-include the boot partition for the nandroid system, i will compile one with the newest updates once the previous steps are made.
As always, I need assistance to proceed faster with your help.
I can do everything on my own, but it will take time. What I need the most urgent is someone to convert the hex values to get the offset and size values.
One for me
The recompiled harmony kernel and information for kernel devs will be posted here.
Last one, open disscussion now !
NOTE : THIS IS A [DEV] THREAD, SO PLEASE DON'T CLUTTER IT WITH QUESTIONS THAT DON'T BELONG IN HERE. IF YOU WANT TO SUPPORT ME, HIT THE 'THANKS' BUTTON TO KEEP ME MOTIVATED !
Hmm, sounds intriguing. Why would we want to backup our boot partition exactly? Sorry, I just had to ask. Why wouldn't we be able to poll the partition via adb, or is this to make it possible via a GUI? Or are you talking about the boot loader? Argh, I'm confused...
hanthesolo said:
Hmm, sounds intriguing. Why would we want to backup our boot partition exactly? Sorry, I just had to ask. Why wouldn't we be able to poll the partition via adb, or is this to make it possible via a GUI? Or are you talking about the boot loader? Argh, I'm confused...
Click to expand...
Click to collapse
so we can back up kernel, each time we restore a rom from CWM it does not restore kernel so we have to reflash that.
hanthesolo said:
Hmm, sounds intriguing. Why would we want to backup our boot partition exactly? Sorry, I just had to ask. Why wouldn't we be able to poll the partition via adb, or is this to make it possible via a GUI? Or are you talking about the boot loader? Argh, I'm confused...
Click to expand...
Click to collapse
The 'boot' partition (LNX, in our case) stores the whole kernel and the ramdisk, combined as a boot image.
This means if I am successful, we can just backup the kernel in recovery along with the rom, like other android devices already do.
E.g. when you flash a new rom, but backed up the old one first, you have to flash a kernel compatible with the rom manually when going back to your backup as of now.
After my work has succeeded, you can just restore the old android, which restores the kernel automatically.
RaymanFX said:
The 'boot' partition (LNX, in our case) stores the whole kernel and the ramdisk, combined as a boot image.
This means if I am successful, we can just backup the kernel in recovery along with the rom, like other android devices already do.
E.g. when you flash a new rom, but backed up the old one first, you have to flash a kernel compatible with the rom manually when going back to your backup as of now.
After my work has succeeded, you can just restore the old android, which restores the kernel automatically.
Click to expand...
Click to collapse
Okay, I thought so, I just needed confirmation. Bad question #3: why can't we did the kernel partition, and restore it that way?
hanthesolo said:
Okay, I thought so, I just needed confirmation. Bad question #3: why can't we did the kernel partition, and restore it that way?
Click to expand...
Click to collapse
Ask this to ASUS !
Those guys gave us a crappy partition layout, meaning we only have /staging for flashing boot and recovery blobs, NO REAL PARTITIONS holding those files. -> UNITL NOW ! I examined the boot offset and size ...
Seems like the recovery ad boot partition share the same offsets and sizes .. will check this
EDIT : Progress : I have the offsets and sizes right at my hands !
See : My hex offset is 0x37ffed, I take this and convert it to decimal ()10 ... then I get 3669997, which fits our definitions perfectly (7chars).
Now, we have to divide this by the block layer size (512), we get 7167.962890625, which is ugly.
The second one has hex offset at 0x87ffe8, decimal at 8912872, decided by 512 makes 17407.953125
Very nice work, seems like more and more people are learning to dev.
RaymanFX said:
Ask this to ASUS !
Those guys gave us a crappy partition layout, meaning we only have /staging for flashing boot and recovery blobs, NO REAL PARTITIONS holding those files. -> UNITL NOW ! I examined the boot offset and size ...
Seems like the recovery ad boot partition share the same offsets and sizes .. will check this
EDIT : Progress : I have the offsets and sizes right at my hands !
See : My hex offset is 0x37ffed, I take this and convert it to decimal ()10 ... then I get 3669997, which fits our definitions perfectly (7chars).
Now, we have to divide this by the block layer size (512), we get 7167.962890625, which is ugly.
The second one has hex offset at 0x87ffe8, decimal at 8912872, decided by 512 makes 17407.953125
Click to expand...
Click to collapse
Oh, okay, ouch, this sounds like it is going to be a LOT if fun to do . I thought it would be possible because the uodater-script flashes kernels to mmcblk0p4, but I guess that was staging, not the actual kernel partition (this also explains why I got a fliesize if 500ish MB the other day when I dd'ed the partition). Good luck to you, and I will try to help the next time I am bored/have free time.
The important stuff is in the header (raw?) of mmcblk0, so it should be possible to just use dd.
K900 said:
The important stuff is in the header (raw?) of mmcblk0, so it should be possible to just use dd.
Click to expand...
Click to collapse
... so ?
Look at my first post, this is exactly what I did. Stripped off the first 20M and found the offsets. I am getting assistance from Dees_Troy and the TF300 devs to ensure everything is going the right way.
RaymanFX said:
... so ?
Look at my first post, this is exactly what I did. Stripped off the first 20M and found the offsets. I am getting assistance from Dees_Troy and the TF300 devs to ensure everything is going the right way.
Click to expand...
Click to collapse
What I mean is patching the kernel to make it a 'partition' is dangerous and can cause unexpected results, so dd and a modified recovery should be used instead.
K900 said:
What I mean is patching the kernel to make it a 'partition' is dangerous and can cause unexpected results, so dd and a modified recovery should be used instead.
Click to expand...
Click to collapse
Believe me, they can't be used. We need the kernel patch. The guys from tf300 tried anything, but using the kernel hack was the only way to make this possible.
And if (not possible in theory) the hack would cause problems, we can always flash a different one since the /staging-flash is not affected at all
RaymanFX said:
Believe me, they can't be used. We need the kernel patch. The guys from tf300 tried anything, but using the kernel hack was the only way to make this possible.
And if (not possible in theory) the hack would cause problems, we can always flash a different one since the /staging-flash is not affected at all
Click to expand...
Click to collapse
There should be other solutions that don't involve uber ugly kernel hacks. I'll see if I can get more info since I have some docs regarding the boot process on generic Tegra boards and reusing same methods (likely bypassing ASUS bootloaders altogether) should be possible, at least now that we have nvflash access for all.
Hey Rayman, any word on this getting up and going? It will kick tail if you do. No more multiple zips then which means more space for me.
According to my research with others in the #asus-transformer channel on Freenode, the correct values are 0x380000 and 0x880000
380000 to decimal becomes: 3670016
3670016 / 512 = 7168 so 7168 is your first offset
880000 to decimal becomes: 8912896
8912896 / 512 = 17408 so 17408 is your second offset
The difference between the 2 values is hex 500000, decimal 5242880.
5242880 / 512 = 10240 which is your size for both.
Of course, after you build a kernel with the correct source and offsets, you'll want to dd dump the partitions and verify with a hex editor that you're getting the right stuff. Both partitions should start with "ANDROID!". You'll also want to unpack the contents of the dd images with unpackbootimg or something and determine which one is recovery and which one is boot. Most likely the first one is recovery.
Technically some of the other people are right. You can probably use dd with the right seek and size values to flash and dump the partitions without modifying the kernel, but modifying the kernel makes for a cleaner, simpler setup. We've used the kernel approach on the TF201, TF300T, and TF700T with much success.
Hope that helps.
Dees_Troy said:
According to my research with others in the #asus-transformer channel on Freenode, the correct values are 0x380000 and 0x880000
380000 to decimal becomes: 3670016
3670016 / 512 = 7168 so 7168 is your first offset
880000 to decimal becomes: 8912896
8912896 / 512 = 17408 so 17408 is your second offset
The difference between the 2 values is hex 500000, decimal 5242880.
5242880 / 512 = 10240 which is your size for both.
Of course, after you build a kernel with the correct source and offsets, you'll want to dd dump the partitions and verify with a hex editor that you're getting the right stuff. Both partitions should start with "ANDROID!". You'll also want to unpack the contents of the dd images with unpackbootimg or something and determine which one is recovery and which one is boot. Most likely the first one is recovery.
Technically some of the other people are right. You can probably use dd with the right seek and size values to flash and dump the partitions without modifying the kernel, but modifying the kernel makes for a cleaner, simpler setup. We've used the kernel approach on the TF201, TF300T, and TF700T with much success.
Hope that helps.
Click to expand...
Click to collapse
From my research
Code:
Position 3670016 / 512 = 7168
Position 8912896 / 512 = 17408
Diff
5242880
10240
From nvflash flash.cfg
SOS Size 5242880 / 512 = 10240
LNX Size 8388608 / 512 = 16384
Also, I already have a kernel compiled. I'll test later.
Just thinking about this thing and wondering about the linux-based (or are they also based on other architectures?) blob tools as a possible workaround? Ignore this if it seems silly. I haven't thought about this sort of thing for a long time and not at all on the transformer.
-
When any of the many kernel/ROM installer scripts take off and do their thing, they use the compiled (usually for linux, but some sort of combo binary and script) blob tools , I thought from Rayman as well (but it's been awhile since I've played with the source and the tools themselves.
Is there any reason why an android version of those couldn't be built and used inside either cwm or tw* to perform both the backup and retrieval of the kernel? I realize it would have to churn out an installer type script somewhere in the backup directory and run it upon restore, but would something like this be one of the multiple possible solutions? I'm guessing there is some obvious reason I've not looked into yet, like a dependency upon some other API or utility that is in a full linux system, but not in an android OS.. (but I don't know).
I suppose the good news of this would be that numbers tied to the partition wouldn't be of much importance since blobbing works OK without them, but there might also be a down side to adding a completely different type of backup/restore paradigm just for the kernel to a nice little piece of code (cwm/tw*) that works for everything else.
hachamacha said:
Just thinking about this thing and wondering about the linux-based (or are they also based on other architectures?) blob tools as a possible workaround? Ignore this if it seems silly. I haven't thought about this sort of thing for a long time and not at all on the transformer.
-
When any of the many kernel/ROM installer scripts take off and do their thing, they use the compiled (usually for linux, but some sort of combo binary and script) blob tools , I thought from Rayman as well (but it's been awhile since I've played with the source and the tools themselves.
Is there any reason why an android version of those couldn't be built and used inside either cwm or tw* to perform both the backup and retrieval of the kernel? I realize it would have to churn out an installer type script somewhere in the backup directory and run it upon restore, but would something like this be one of the multiple possible solutions? I'm guessing there is some obvious reason I've not looked into yet, like a dependency upon some other API or utility that is in a full linux system, but not in an android OS.. (but I don't know).
I suppose the good news of this would be that numbers tied to the partition wouldn't be of much importance since blobbing works OK without them, but there might also be a down side to adding a completely different type of backup/restore paradigm just for the kernel to a nice little piece of code (cwm/tw*) that works for everything else.
Click to expand...
Click to collapse
That would be an option as well I suppose. Take the image and call blobpack and build a blob to be flashed on reboot. Although, if we could 'dd' it cleanly without causing issues with other devices, that would be an ideal solution. Until then, this kernel change will work.
Hello folks,
This is a revised version of the same question posted to another forum, where no usable answer was received. I hope this might reach more knowledgeable people here .
On Allwinner A10/A13 platforms (tablets), the boot process differs significantly in Gingerbread (& earlier) vs. ICS (& later)
I think I have a pretty good understanding of the normal vs. recovery boot process in GB-style firmwares:
- boot.axf detects the special "boot to recovery" button combination based on info (key_min, key_max) found in script.bin
- it goes reading /linux/recovery.ini instead of /linux/linux.ini
- recovery.ini gives the name of the kernel to boot (uImage) and the name of the parameters file: paramsr instead of params found in linux.ini
- paramsr contains the name of the NAND partition to mount as root (the one that contains the recovery) and the proper arguments passed as the kernel command line
- done deal.
However in ICS-style firmware, things happen differently:
The uImage kernel has been replaced by a tertiary bootloader: u-boot.bin, whose job is to load the Linux kernel.
The recovery.ini file is gone, only linux.ini remains.
The u-boot binary does seem to have all the necessary parameters embbeded to boot in normal or recovery mode. But since it is boot.axf that detects the key combination, how does it pass the information "boot in recovery, dude" to u-boot? It's not using the "boot-recovery" string written to the "misc" partition because this information is checked and used by boot.axf itself and not by u-boot.bin as far as I can tell. Since boot.axf gets alls the information it needs from linux.ini I doubt that it has the ability to pass command-line arguments to u-boot.bin (I suspect that the limited environment available at this time has any such notion as process arguments anyway).
Actually the same question goes when "boot-recovery" is written to the "misc" partition: boot.axf detects this, but how is this information passed to u-boot?
Summary: in ICS-style firmware, how is the "boot to recovery" information passed from boot.axf to u-boot.bin?
I've Googled for this and found only one post with someone basically asking the same question, without a reply.
If someone can enlighten me I'd be immensely grateful.
@Lannig - I'm facing a similar issue in trying to figure out how the "boot to recovery, dude" message is passed to u-boot from boot.axf. I've created a thread with the information here: http://forum.xda-developers.com/general/help/allwinner-a20-stuck-recovery-reboot-loop-t2979416
I went through your thread here as well: http://www.slatedroid.com/topic/41091-ics-bootloader-recovery-boot-process-question/, where you seem to have had little success in your venture, could you please update on the details how you got the boot from SD card working. Thanks!
So I was able to make a decompressed extracted dump of the UEFI cab update package. After extracting the 2_UEFI.bin file from the cab update, I ran it through some PC bios extraction tools. Just my luck it worked.
This package is only partially extracted. And readable.
MORE STUFF ON POST#2
here is picture attached here
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
PLEASE MAKE NO!!!! ATTEMPT TO FLASH ANY OF THESE FILES. UNLESS YOU KNOW WHAT YOUR DOING.
FULL DUMP CAN BE DOWNLOADED HERE
View attachment UEFI-VOL-DUMP.zip
Here are some strings from EBL module that was extracted from a Vondafone UEFI update cab.
EblCheckRefurbishResult
[FAT_ERROR] fat_get_next_cluster: allocate %d bytes for FAT table sector buffer fail!
[FAT_ERROR] fat_get_next_cluster: read FAT table sector[%d] fail!
fat_read_disk [FAT_ERROR] fat_get_skip_cluster: allocate %d bytes for FAT table sector buffer fail!
[FAT_ERROR] fat_get_skip_cluster: read FAT table sector[%d] fail!
[FAT_ERROR] fat_open_file: can not alloc heap for the file description!
[SSD-PLAT] ReadSector failed, please probe removable media first.
[SSD-PLAT] ReadSector failed, please probe removable media first.
[SSD-PLAT] WriteSector failed, please probe removable media first.
[SSD-PLAT] WriteSector failed, please probe removable media first.
EblEMMCInformation: Not found hTC Sdcc extention protocol!! (%r)
EblEMMCInformation: Not found hTC Sdcc extention protocol!! (%r)
c:\apollo_bsp\accord_u_gdr2_00_s\wp\uefi\edk2\EmbeddedPkg\Ebl\hTC\tz.c !EFI_ERROR (gBS->LocateProtocol(&gQcomPmicVregProtocolGuid, 0, (void**)&PmicVregProtocol))
c:\apollo_bsp\accord_u_gdr2_00_s\wp\uefi\edk2\EmbeddedPkg\Ebl\hTC\tz.c !EFI_ERROR (gBS->LocateProtocol(&gQcomPmicVregProtocolGuid, 0, (void**)&PmicVregProtocol))
c:\apollo_bsp\accord_u_gdr2_00_s\wp\uefi\edk2\EmbeddedPkg\Ebl\hTC\tz.c !EFI_ERROR (gBS->LocateProtocol (&gEfiCpuArchProtocolGuid, 0, (void **)&CpuArch))
c:\apollo_bsp\accord_u_gdr2_00_s\wp\uefi\edk2\EmbeddedPkg\Ebl\hTC\tz.c !EFI_ERROR (gBS->LocateProtocol (&gEfiTzeLoaderProtocolGuid, 0, (void**)&TzeLoader))
[SECURITY] TZ_HTC_SVC_READ_SIMLOCK_MASK modified ret = %d, mask = 0x%X
[SECURITY] TZ_HTC_SVC_READ_SIMLOCK_MASK modified ret = %d, mask = 0x%X
[SECURITY] TZ_HTC_SVC_UPDATE_SIMLOCK: TZ NOT return updating record index
[SECURITY] TZ_HTC_SVC_UPDATE_SIMLOCK: TZ NOT return updating record index
[SECURITY] secure_get_simlock_upgrade_magic, ret=%d (0x%x, 0x%x, 0x%x)
[SECURITY] secure_get_simlock_upgrade_magic, ret=%d (0x%x, 0x%x, 0x%x)
[SECURITY] TZ_HTC_SVC_EMMC_WRITE_PROT set magic (0x%X, %d) ret = %d
[SECURITY] TZ_HTC_SVC_EMMC_WRITE_PROT set magic (0x%X, %d) ret = %d
[SECURITY] TZ_HTC_SVC_EMMC_WRITE_PROT get magic 0x%X 0x%X ret = %d
[SECURITY] TZ_HTC_SVC_EMMC_WRITE_PROT get magic 0x%X 0x%X ret = %d
hash: %a 2 [1: sha1 | 2: sha256] [src address] [src len] [digest addr] [digest len]
hash: %a 2 [1: sha1 | 2: sha256] [src address] [src len] [digest addr] [digest len]
aes: %a 3 [0: aes128 | 1: aes256] [0: ECB | 1: CBC | 2: CTR] [0: encrypt | 1: decrypt] [iv addr] [key addr] [src addr] [len] [dest addr]
aes: %a 3 [0: aes128 | 1: aes256] [0: ECB | 1: CBC | 2: CTR] [0: encrypt | 1: decrypt] [iv addr] [key addr] [src addr] [len] [dest addr]
aes encryption with SW key: %a 8 [0: aes128 | 1: aes256] [0: ECB | 1: CBC | 2: CTR] [0: encrypt | 1: decrypt] [key id] [iv addr] [src addr] [len] [dest addr]
aes encryption with SW key: %a 8 [0: aes128 | 1: aes256] [0: ECB | 1: CBC | 2: CTR] [0: encrypt | 1: decrypt] [key id] [iv addr] [src addr] [len] [dest addr]
set ddr mpu config: %a 11 [index] [read vmid mask] [write vmid mask] [start] [end]
set ddr mpu config: %a 11 [index] [read vmid mask] [write vmid mask] [start] [end]
enable_hw_auth
disable_jtag
blow_boot_cfg
blow_sec_key
hide_hwkey
checksbl1
je board_evm
evm
EVM8960
ke board_evm2
evm2
EVM28960
board_evita
evita
EVITA board_accord_wl
accord_wl
PM2310000
board_accord_wr
accord_wr
PM2330000
board_accord_u
accord_u
PM2320000
board_accord_ul
accord_ul
PM2321000
board_accord_td
accord_td
PM2350000
[ERR] partition_update offset is not emmc sector[%d] aligment! Offset[%d]
htc_pg_sanity_check pg %a: calculated checksum 0x%x is mismatched (header checksum 0x%x)
pg %a: calculated checksum 0x%x is mismatched (header checksum 0x%x)
htc_pg_hdr_get
htc_pg_hdr_set
htc_pg_part_hdr_get
htc_pg_alloc_map
htc_pg_find_best_alloc
htc_pg_alloc
htc_pg_part_reduce_size
htc_pg_fix_part_hdr_add
htc_pg_part_hdr_set
htc_pg_part_traverse
htc_pg_link_size
htc_pg_part_update
htc_pg_part_clear
htc_pg_part_read
htc_pg_update_crc
htc_pg_part_modify
htc_pg_part_modify:
part %a,
offset %d,
len %d,
is_erase %d,
update_crc %d
htc_pg_part_modify:
part %a,
offset %d,
len %d,
is_erase %d,
update_crc %d
htc_pg_free_size
htc_pg_part_crc
check_pgfs
check_boardinfo
chipset_setting_init
chipset_reset
chipset_get_device_id
chipset_set_device_id
read_simlock
write_simlock
EMBEDDED BOOT LOADER COMMANDLINE INTERFACE
I think some of the more experienced gurus form the Windows Mobile days can input more knowledge here.
EblBoardInfoCommand
write_simlock_password
read_simlock_password
radio_init_secure_smem
ClearSimLockCode
AddSimLockCode
EnableSimLock
DisableSimLock
HTC
USB BLDR
HandleSetupPkt
HandleUSBEvent
**** Both TX and RX needs to be queued, but only one can be queued. SOMETHING MAY GO WRONG **** OnBoard_USB_Init OnBoard_USB_Write
**** Both TX and RX needs to be queued, but only one can be queued. SOMETHING MAY GO WRONG ****
OnBoard_USB_Read
detectUsbCable
0 . 0 . 0 . 0
PIKS
MSM8960
c:\apollo_bsp\accord_u_gdr2_00_s\wp\uefi\edk2\Build\Msm8960\RELEASE_RVCT31\ARM\EmbeddedPkg\Ebl\Ebl\DEBUG\AutoGen.c
c:\apollo_bsp\accord_u_gdr2_00_s\wp\uefi\edk2\Build\Msm8960\RELEASE_RVCT31\ARM\EmbeddedPkg\Ebl\Ebl\DEBUG\AutoGen.c
c:\apollo_bsp\accord_u_gdr2_00_s\wp\uefi\edk2\Build\Msm8960\RELEASE_RVCT31\ARM\EmbeddedPkg\Ebl\Ebl\DEBUG\AutoGen.c
c:\apollo_bsp\accord_u_gdr2_00_s\wp\uefi\edk2\Build\Msm8960\RELEASE_RVCT31\ARM\EmbeddedPkg\Ebl\Ebl\DEBUG\AutoGen.c
c:\apollo_bsp\accord_u_gdr2_00_s\wp\uefi\edk2\Build\Msm8960\RELEASE_RVCT31\ARM\EmbeddedPkg\Ebl\Ebl\DEBUG\AutoGen.c
c:\apollo_bsp\accord_u_gdr2_00_s\wp\uefi\edk2\Build\Msm8960\RELEASE_RVCT31\ARM\EmbeddedPkg\Ebl\Ebl\DEBUG\AutoGen.c
c:\apollo_bsp\accord_u_gdr2_00_s\wp\uefi\edk2\Build\Msm8960\RELEASE_RVCT31\ARM\EmbeddedPkg\Ebl\Ebl\DEBUG\AutoGen.c
c:\apollo_bsp\accord_u_gdr2_00_s\wp\uefi\edk2\Build\Msm8960\RELEASE_RVCT31\ARM\EmbeddedPkg\Ebl\Ebl\DEBUG\AutoGen.c
c:\apollo_bsp\accord_u_gdr2_00_s\wp\uefi\edk2\Build\Msm8960\RELEASE_RVCT31\ARM\EmbeddedPkg\Ebl\Ebl\DEBUG\AutoGen.c
No Media
Media changed
Access Denied
Write Protected
Not started
Already started
Aborted
Unsupported
Not Found
Warning
Delete
Failure
Warning
Write Failure
No Response
Bad Buffer Size
No mapping
Warning Unknown Glyph
Warning Buffer Too Small
Volume Full
Invalid Parameter
ICMP Error
TFTP Error
Load Error
Device Error
Protocol Error
Out of Resources
Success
Volume Corrupt
Time out
Not Ready
Snapdragon S4 Processor
GPT PARTITIONS
FFFFFFFF-FFFF-FFFF-FFFF-000000000010
540B4740-D799-497D-9F02-B36D2E958EB0
B7A9BDA8-368C-46BC-B2C7-67501F0E6B52
9183C552-0934-4FD6-AF26-13FE14244223
320D3B19-80D9-467A-99BC-AB2B85287574
A053AA7F-40B8-4B1C-BA08-2F68AC71A4F4
E35F99CF-0025-4252-A608-CAAA1289CAF4
69B4201F-A5AD-45EB-9F49-45B38CCDAEF5
0732095D-CD4E-4492-B229-28D4ECCEC1B6
F0B4F48B-AEBA-4ECF-9142-5DC30CDC3E77
E5C3DF3F-556D-478e-AFE3-DABA98C52897
EBD0A0A2-B9E5-4433-87C0-68B6B72699C7
ebd0a0a2-b9e5-4433-87c0-68b6b72699c7
098DF793-D712-413D-9D4E-89D711772228
400FFDCD-22E0-47E7-9A23-F16ED9382388
DEA0BA2C-CBDD-4805-B4F9-F428251C3E98
E6536BC2-6DA4-495D-A83B-79F93701E799
638FF8E2-22C9-E33B-8F5D-0E81686A68CB
0A288B1F-22C9-E33B-8F5D-0E81686A68CB
EBBEADAF-22C9-E33B-8F5D-0E81686A68CB
3A6A228E-FC35-4A46-A869-4C511F7CE5EC
6BB94537-7D1C-44D0-9DFE-6D77C011DBFC
8C6B52AD-8A9E-4398-AD09-AE916E53AE2D
2373E6C7-FCBE-42B1-B44A-10DDAF18388D
543C031A-4CB6-4897-BFFE-4B485768A8AD
530C3197-F4D2-408F-B886-778ED6CDFDAD
05E044DF-92F1-4325-B69E-374A82E97D6E
74DA3EE7-D422-487C-A573-CE03C261362F
A44D2E89-8B5A-4F42-8FE5-FD36333A3BFF
PARTITION IMAGES
%a:\hTCIMG\QC\MSM8960\%04x\rfg_0.img
%a:\hTCIMG\QC\MSM8960\%04x\rfg_1.img
%a:\hTCIMG\QC\MSM8960\%04x\modem_st1.img
%a:\hTCIMG\QC\MSM8960\%04x\rfg_2.img
%a:\hTCIMG\QC\MSM8960\%04x\modem_st2.img
%a:\hTCIMG\QC\MSM8960\%04x\rfg_3.img
%a:\hTCIMG\QC\MSM8960\%04x\rfg_4.img
%a:\hTCIMG\QC\MSM8960\%04x\rfg_5.img
%a:\hTCIMG\QC\MSM8960\%04x\rfg_6.img
%a:\hTCIMG\QC\MSM8960\%04x\rfg_7.img
%a:\hTCIMG\QC\MSM8960\%04x\disk.img
%a:\hTCIMG\QC\MSM8960\%04x\radio.img
%a:\hTCIMG\QC\MSM8960\%04x\sbl1.mbn
%a:\hTCIMG\QC\MSM8960\%04x\sbl2.mbn
%a:\hTCIMG\QC\MSM8960\%04x\sbl3.mbn
%a:\hTCIMG\QC\MSM8960\%04x\uefi.mbn
%a:\hTCIMG\QC\MSM8960\%04x\rpm.mbn
%a:\hTCIMG\QC\MSM8960\%04x\winsecapp.mbn
%a:\hTCIMG\QC\MSM8960\%04x\tz.mbn
%a:\hTCIMG\QC\MSM8960\%04x\gpt_main0.bin
%a:\hTCIMG\QC\MSM8960\%04x\fat16.bin
%a:\hTCIMG\QC\MSM8960\%04x\MainOS.bin
%a:\hTCIMG\QC\MSM8960\%04x\fat_FFU.bin
%a:\hTCIMG\QC\MSM8960\%04x\UserData.bin
%a:\hTCIMG\QC\MSM8960\%04x\sdata.bin
%a:\hTCIMG\QC\MSM8960\%04x\misc.bin
%a:\hTCIMG\QC\MSM8960\%04x\mfg.bin
%a:\hTCIMG\QC\MSM8960\%04x\modem_fsg.bin
%a:\hTCIMG\QC\MSM8960\%04x\dpp.bin
%a:\hTCIMG\QC\MSM8960\%04x\efiesp.bin
%a:\hTCIMG\QC\MSM8960\%04x\eblogs.bin
RUU CONFIGURATION
THESE VARABLES CAN BE USED TO IN THE ACDUCONF.TXT
[getvzwmid] Query VZW model ID
[getmeid] Query device MEID vzwisLTE
[getdevinfo] Return device Model ID and CID to RUU
[getimei] Return device IMEI to RUU
[blversion] Return bootloader version to RUU wdata
[readconfig ] Read i-th config data or read all config data if no i supplied getmeid getvzwmid
[task TaskNum] Executing task command
[set SetNum SetValue] Executing set command password ResetDevice
[ResetDevice] Reseting the device
[wdata Length Checksum] Writing NBH file format data to device
[ruustart] Enter RUU special command mode
[progress Percentage] Show progress bar and percentage on screen for RUU use readconfig Ask radio to start refurbish startrefurbish getimei task blversion
[password PassWord] RUU password verification getdevinfo progress set Check the refurbish result checkrefurbishresult
[vzwisLTE] Check the device is LTE or not ruustart
FixVoltageMSMC1
FixVoltageMSMC2
KitlIP DCVSParam[0]
DCVSParam[1]
DCVSParam[2]
DCVSParam[3]
DCVSParam[4]
DCVSParam[5]
DebugMethod
PowerSavingDisable
DriverDisable
FixedIdleTime
DriverLocalZone
PagingPoolSize
DebugFlag
DriverFlag
PassiveKitlDbg
HookDebug
ApSwitch
KitlNetMask
FixFreqLevel
USBFlags
RadioDebugFlags
SensorDebugFlags
BootloaderFlags
DLLLowFlags
DummyFlags
SpyFlags
DllBreakPoint
DemFatalCount
AutoFocusTest
DebugBattery
secure erase secure trim
QUALCOMM OEM
STILL NOT SURE ABOUT THESE STRINGS
Q6:
VDDCX:
Krait:
RFSKUIDField_D0
RFSKUIDField_D1
RFSKUIDField_D2
RFSKUIDField_D3
RFSKUIDField_D4
RFSKUIDField_D5
RFSKUIDField_D6
RFSKUIDField_D7
EngineerID
KEK
PK
DPP
HTC OEM SECURE KEYS
fs0:\SecureBootPolicy.p7b
db pDPP.enc
OEM_DB_CLEAR.enc
OEM_KEK_CLEAR.enc
OEM_PK_CLEAR.enc
OEM_DBX_CLEAR.enc
PCBIDField
FunctionSKUField
ssd
delfile
crwfile
fs0:\enc.img
fs0:\ori.img
SKUIDChecksum
fs0:\OEM_dbx_2011.bin
fs0:\OEM_db_2012.bin
fs0:\OEM_KEK.bin
fs0:\OEM_PK.bin
fs3:\pDPP.tmp
fs3:\OEM_DB_CLEAR.tmp
fs3:\OEM_KEK_CLEAR.tmp
fs3:\OEM_PK_CLEAR.tmp
fs3:\OEM_DBX_CLEAR.tmp
var midr
fs0:\keystore.dat
v
w
dbx
CurrentPolicy
QULCOMM SECURE
RFG_0
SBL1
MODEM_FS1
RFG_1
SBL2
MODEM_FS2
RFG_2
SBL3
RFG_3
RFG_4
RFG_5
RFG_6
RFG_7
SDATA
MISC
MODEM_FSG
UEFI
RPM
RADIO
BDP
WINSECAPP
DPP
EFIESP
EBLOGS
MainOS
PLAT
TZ
Data
X
ROM UPDATE UTILITY
HTCIMAGE
GPT_HEADER TOUCH_FW_UPDATE
ACDUIMG.nbh
ACDUNV.nbh
ACDUDIAG.nbh
ACDUCONF.txt
ACDUDIAG.nbh
HTCIMAGE
simunlock
more.
HTCIMAGE
simunlock.
spcustom
prkey
wvkey_lv1
dpkey.
tamper
prmkey
wvkey_lv3.
sbl1_update
c:\apollo_bsp\accord_u_gdr2_00_s\wp\uefi\edk2\Build\Msm8960\RELEASE_RVCT31\ARM\EmbeddedPkg\Ebl\Ebl\DEBUG\Ebl.dll....
More info on the tools used to dump the UEFI can be found here Thanks to CodeRush
I have moved on to using PhoenixTool. Many options to choose from including inserting SLIC, SLP, key and RW file. Full customization of ACPI, OEM, RSDT XSDT tables. Preserve module size andmany more features.
any use? I'm a noob.
fengsam said:
any use? I'm a noob.
Click to expand...
Click to collapse
Using RUU configuration script in the ACDUCONF.txt would probably solve some issues with not being able to flash a rom because of incorrect model number issues.
for instance i cannot flash a factory rom on my device because the text that shows up on boot loader screen is incorrect. do to some of the Microsoft developer updates. for Windows embedded compact and handheld sdk updates that have been pushed to my device.
so using this [getdevinfo] should in theory return the ruu with the correct device info. the radio, dpp. and boot partitions that are in the RUUs contain the device info that have to match for the. i just so happens that those config files can be changed without harming the signed.nbh (technically there are not signed images at all. only mostly encrypted. but still unsigned.) I have not been able to dig up any documentation for use of ACDUCONF.txt and how it should be properly used. but similar ruu config file usage has documented us since the early windows mobile all the way up until windows phone 7. its only up until yesterday that this information has been presented to the public.
I am 99% convinced that HTC 8x uefi is can be configured to dual-boot, boot-android, right now with the UEFI that i extracted modules can be altered, replaced new ones can be inserted and at the same time. be resigned. only issue is creating an nbh. I think some old windows mobile tools can sign the image and a goldcard can b used on a usb thumb drive. The HD2 USB Y Cable dongles is OEM approved to be used with the htc accord and has the code written within the uefi bios image its self.
HTC uefi is very similar to Intels edk2 which is based from Edk II DevKit(Sourceforge.net), which is based off of Tianocore. Many of the packages are compattable. [MdePkg]
Though it is not tianocore some of there packages are still based off of the tianocore edk2 platform. along with many of the other edkII development projects on http://www.sourceforge.net.
Also there is strings i found that allowed the use of using a JAVACARD dongle. Which with a JAVACARD you can achieve s-off, and security unlock. (well at least in the case of Android devices.)
Then again who has ever seen a windows phone 8 uefi broken down like this before. none. or at least that i can find. Closest i found was from forums in China, and original source was being shared for Huawei W1 and W2.
fengsam said:
any use? I'm a noob.
Click to expand...
Click to collapse
No ,
@grilledcheesesandwich What PC BIOS Extraction tools did you use?
compu829 said:
@grilledcheesesandwich What PC BIOS Extraction tools did you use?
Click to expand...
Click to collapse
i forgot who made the tools. but i found them on mydigitallife.com forums. there called UEFIExtract.exe and UEFITool.exe the extractions are not perfect and the rebuilding still is not working 100% on 8x uefi .the process request files that only exist within the phones memory.
sent from the moon
grilledcheesesandwich said:
i forgot who made the tools. but i found them on mydigitallife.com forums. there called UEFIExtract.exe and UEFITool.exe the extractions are not perfect and the rebuilding still is not working 100% on 8x uefi .the process request files that only exist within the phones memory.
sent from the moon
Click to expand...
Click to collapse
http://forum.xda-developers.com/showthread.php?t=1966327
@grilledcheesesandwich What tool are you using to browse the UEFI BIOS (like you see in the screenshots?) Also, you need to use 7zip to extract the zip file to get to the tarball...it's not compatible with the built-in windows zip utility
compu829 said:
@grilledcheesesandwich What tool are you using to browse the UEFI BIOS (like you see in the screenshots?) Also, you need to use 7zip to extract the zip file to get to the tarball...it's not compatible with the built-in windows zip utility
Click to expand...
Click to collapse
i tarballed the bios after i extracted it so i could browse it in a flatview
grilledcheesesandwich said:
i tarballed the bios after i extracted it so i could browse it in a flatview
Click to expand...
Click to collapse
Problem is, even if you manage to repack the different modules, (You could Use Andys Tool for that, I got into Bios modding some time ago ) the phone will detect it and since the signature has been broken it won't flash. But I am quite interested in the volume dump since I have a HTC 8S motherboard stuck in recovery mode because I tried to flash the 8X rom on it, with the 8S signature ('t was an accident) You could try to get the offset you need to change with UIFR by Donovan http://donovan6000.blogspot.de/2014/02/universal-ifr-extractor.html
cheers, hutchinsane_
@grilledcheesesandwich I noticed lol.
From what I can gather, if one uses the Y-Cable method to flash the HTC 8x, it bypasses the signature checking done by the standard RUU. I do know that the nbh files for the HTC 8x are unencrypted. I have always wondered about hand-editing the mainOS partition to enable a developer unlock for our devices. The only issue is that I have the T-Mobile variant, which has AWS HSPA+ enabled and unlocked. This radio firmware is not in the standard RUU for the EURASIA ROMS, so I never bothered with it because I Can't lose AWS support.
hutchinsane_ said:
Problem is, even if you manage to repack the different modules, (You could Use Andys Tool for that, I got into Bios modding some time ago ) the phone will detect it and since the signature has been broken it won't flash. But I am quite interested in the volume dump since I have a HTC 8S motherboard stuck in recovery mode because I tried to flash the 8X rom on it, with the 8S signature ('t was an accident) You could try to get the offset you need to change with UIFR by Donovan http://donovan6000.blogspot.de/2014/02/universal-ifr-extractor.html
cheers, hutchinsane_
Click to expand...
Click to collapse
ok here is what i have so far. Ideas are still out there.
I need to find a tool that can extract a perfect capsule. from the uefi. even though the uegi binary partition is write protected. the capsule may be writeable. no need to worry about signatures and keys as long as the capsule is back to its origiinal size and expands as normal after being flashed to the device. also no alteratiin can been done to Security module within the capsule. thats ok because all the modules are contained within there own class and to do not require signature verification. this has worked with Intel and Amtel Uefi bios. From what i can tell Htc8x has an embedded amtel at24c128bn eeprom security chip present and if there eeprom is as easy as there tpm (trusted platform module) being used for security validation in uefi bios boot process used on pc motherboards we should in some theory be the case here too.
My overal plan is not to only expand the new development into custom roms. the plan is to fully defy microsofts most secure mobile retail device by handing them a fully customizeable device without loosing the featured security.
To my knowledge every htc 8x has the built in feature to change usb connection mode when pluged in to a pc. the only reason we cannot use this feature the same feature offered in pre android 4.3 devices is because the value in the registry is set to disableDialogmenu and the value is set to (1). i think if we can change this to (0) wen will have a popup menu present when plugging in to a pc. i found this key earlier today while searching my phones registry. i will post up this key later.
Another is Andrid. HTC One S Ville U has identical hardware. believe this the hboot for ville U is built just like the uefi for the 8x. so close in fact like you can cee the ebl module refrences the ville u. ok so heres more. when i tore apart ruu ville u i found the exact same files that exist withing the ruu accord. the files im refering to are the platform info files that check for firmware cimpatibility. the only alteration needed would be to replace the secure boot binaries in the ville u rom.zip and inject my certificates i have been holding onto.
i have 2 platform verification keys (pvk) i have found from encrypted jtag nand dumps. probably useless. itsva good refrence start on a possible challenge with DPP partition.
l
self signing certs is not a problem. i have everything to work around the issue of kek db dbx ovk and pvk keys and certificates. found a dev who put together a wpdeveloper pack that creats all needed certificates for wp soc oem ihv developemt and also remotly sets up all the needed requirements and resources to build and flash a signed ffu. i can assure hyc 8x ffu exist. but the only way to get a qualcomm accord u full flash uodate is to build it. you do not have to be an oem to build a ffu. there is a process to doing this. all you need is to create an empty zip archive labeled corrextly likr how nokia ffus look. add a specific xml soap scripts. similar to.the ones for cab update checks. mainly the cabs that are labeled emptypackage.
ive came across a few but not enough. i think a workaround would he microsoft cabinet sdk. to rebuild. whats missing. the cab that contaijes all the xml provision licenses is needed for the ffu build. as well. now the documentation on the wpoem site says you need the phone image design tool to build a ffu........o darn dead end.... nope the is another way. some confedientel ihv documents demonstrate like rhe above mentoned empty zip file correctly labeled with correct xml scemas layed out then added to the zip. you must setup your pc environment with microsoft client connextion to redmond. they validate you contoso build zip is accurate and if doen correctly you will returned with a fully built full flash update package. theres lots i didnt not mention. i should not.
so any ways. back to the topic. once i can find all the correct libraries to correctly rebuild this uefi all options will be on the table. moke like endless opportunities in customizations and features. well almost.
litsvofbwork needs done. anybody else has gots guts to conqueror with me head over to mydigitallife and sure uobthere endless threads on uedi bios hacking.
i completely sandboxied hck adk win sdk win kits wpsdk ack and vs2013. zi
ffutool.exe & ffuresources.dll
sent from the moon
compu829 said:
@grilledcheesesandwich I noticed lol.
From what I can gather, if one uses the Y-Cable method to flash the HTC 8x, it bypasses the signature checking done by the standard RUU. I do know that the nbh files for the HTC 8x are unencrypted. I have always wondered about hand-editing the mainOS partition to enable a developer unlock for our devices. The only issue is that I have the T-Mobile variant, which has AWS HSPA+ enabled and unlocked. This radio firmware is not in the standard RUU for the EURASIA ROMS, so I never bothered with it because I Can't lose AWS support.
Click to expand...
Click to collapse
i have a rom that supports aws hspa. its not directly tmobile its a wwe rom. also mine is also a tmobile usa variant. and the weird part is its not the same as the other usa versions mine has full lte and gsm support and at one time was sim unlocked. the serial number traced back to being built in germany and was sold here in the usa
I IM GOING TO HELP EVERYONE OUT HERE AND HOST MY COLLECTION OF HTC8X ROMS. AND 8S ROMS.. I keephearing that there is only 2 versions available for the 8x. im going to give everybody at least 6.
Sent from my Galaxy Nexus using XDA Free mobile app
hutchinsane_ said:
Problem is, even if you manage to repack the different modules, (You could Use Andys Tool for that, I got into Bios modding some time ago ) the phone will detect it and since the signature has been broken it won't flash. But I am quite interested in the volume dump since I have a HTC 8S motherboard stuck in recovery mode because I tried to flash the 8X rom on it, with the 8S signature ('t was an accident) You could try to get the offset you need to change with UIFR by Donovan http://donovan6000.blogspot.de/2014/02/universal-ifr-extractor.html
cheers, hutchinsane_
Click to expand...
Click to collapse
ifr extractor does not work with a htc 8x uefi binary. i got an error instantly i might be doing something wrong. i will do more ttesting with that one.
i heard there was some uefi bios devrlopement going on with the htc one. it may be possibkr to incorporate some of there knowledge into this project. the boards have some similarities minus the processor cores ram and so on. i do know that msm8960 code is compattable with msm8260a htc8x and apq8064 htc one, dna, and ny fAvorite my ifc6410 qualcomm snapdragon 600 itx motjerboard.
if you have the uefi cab update for your htc8s i could eztract a dump of it for you and send it back.
@
compu829 said:
radio software version is 1.17b.32.19.14_15.62b.32.19
Firmware revision is 3030.0.34101.531
UEFI bootloader version is 0.0.3030.0(173542)
Chipset is the 8260A
Interestingly enough, in the about page is a spot that says "IMS: Not Registered"...I wonder if they are slipped in Wi-Fi calling support and didn't tell anyone?
from the HTC screen:
PM2322002 P S WP8 I
SBL1-303.000.R15
SBL2-303.000.110
SBL3-303.000.008
RPM-303.CRC.76B
TZ-303.000.241
UEFI-0.0.3030.0(173542)
OS-3.41.531.01
eMMC SMS 14910MB F-15
CID T-MOB010
Radio-1.17b.32.19.14_15.62b.32.19
MSM8260A v3.2.1-p1 0x707910e1
Krait:Nom Q6:Fast VDDCX:SLOW 0x30400
Touch FWS1:1195017,13106,41434467
Vdd_dig - 0.5v, 0x4
Click to expand...
Click to collapse
nice only difference is mine is nom slow. I have a a rom that is almost identical too. what i have found out is that some of the nbh htc windows phone 8 roms floating around out there are incorrectly labeled even the 512kb headers are wrong too. when tearing down and dissecting some of these. it seems as though the partitions change. for instance i have 2 identical extractions and on one change all permissions to alow remote users and any nt or network admin or authority to full control. let all the ruu files give 100% internet access through your firewall. now copy run the ruu in dependency walker and find all the files that the ruu is Depends on. most are in windows active sync installer the others are in you phone. and need to be extracted to and copied to the ruu folder. why am i telling you this? you probably know this being a senior member.
on that note. Ive noticed that the 8s and 8x are obviously different than legacy windows mobile mainly due to gpt guid partition format. within system files from my phone and 8x ruu i have found references to Leo, hd2, Shubert, startrek, Hermes, and a few others. which that lead me into researching how wm, wince, wp7 and ec2013 devices were built using Microsoft sdk's. from what i can see to the best of my knowledge is that newer platforms still use the some of the same source as older designs and even though bsp kits for older builds are not one click compatible with the ec2013, shuffle a few files around and match the folder structures & alter some lines of code for embedded compact and one will just have incorporated classic features into a brand new operating system. i do not believe Qualcomm or Microsoft are hiding easter eggs. my guess is it was all htc. ok so last year i bought an evo shift. yea yea funny haha. i was bored so i got this phone, unlocked it, raw dumped every partition and hex away. in the hboot 7630 build i found strings that referenced windows ce. i never took it any further than that. but i can see now that htc has sloppy source control. or they did this on purpose to see if anybody would catch on.
ok back to wp8. i will make this part quick. the wp8.1 sdk leaked emulator dump OEMprovisioning.exe app can be executed on x64 bit win8.1 desktop pc. strange. i found some registry keys and drivers that allows my phone to run applications in win32 compatibility mode. enough said. i still do not know how it and be incorporated into apps.
about wifi calling. mine says ims not registered too. i dont care on mine. its only purpose to be hacked.
i need to do some work on file write/read app. it some what works. start tiles disappear an it broke my wifi. i need to incorporate the app into a file manager maybe GoodDayToDie's webserver app.
Sent from my Galaxy Nexus using XDA Free mobile app
The above is way above my understanding but I have a 8X that I'm more than willing to test with. Let me know if you need some testing
utopiate said:
The above is way above my understanding but I have a 8X that I'm more than willing to test with. Let me know if you need some testing
Click to expand...
Click to collapse
kind of dangerous if you ask me. if your phone is already bricked and its just lying around as DEAD WEIGHT then whats the worst that could happen. let me throw some stuff together. what is theconditin of your phone?
Sent from my Galaxy Nexus using XDA Free mobile app
Its in fine working order running the dev preview and so a but buggy. I'm just about to get a new phone so I don't mind testing with it
try the hawaei w1 rom flashing method.
i found some registry keys that refrence simpleio.efi in the tmobile variant 8x
Sent from my Galaxy Nexus using XDA Free mobile app
Welcome everyone!
This project has started, becouse we need real solution for the problem. The problem of hard bricked Moto devices. It is like a curse.
When my device bricked I have done solid research, I have gathered many informations and files essential to revive my cellphone but 5 years experience of linux, rooting, compiling kernels and roms weren't enough to make it work.
But nevermind. I am even more determinated and I am asking ALL of You guys here to help me. Together we will come to solution.
Here is what I got, happy reading :
DICTIONARY:
PBL - Primary bootloader of the chip - this is like BIOS for phone so it checks chip for damage and problems and then it tries to load SBL but if SBL is corrupted or checksum doesn't match, PBL invokes Qualcomm HS-USB QDLoader 9008 emergency mode. PBL is hard flashed into SoC and can't be corrupted by firmware.
SBL - Second stage bootloader wich is more advanced than PBL. It initializes phone hardware and ABOOT.
ABOOT - Application bootloader (HBOOT). You probably know this one well. Android botloader.
Full mmcblk0 backup - Backup of whole phone flash storage byto to byte.
blankflash - method of repairing msm phones in 9008 state
programmer.mbn - Special type of software programmer that is being sent to chip in Qualcomm 9008 emergency mode. There it comunicates with pc via firehose protocol. Each phone has set of their own programmers, they are unique to phone and other programmers don't work. These programmers are signed so tampering it results in not working one.
firehose protocol - it is used to tell programmer what operations it must do on chip.
singleimage.bin - this package contains instructions for programmer and set of files it need (for example to replace)
gpt_main0.bin - Partition layout
rawprogram0.xml - instructions for programmer
patch0.xml - I don't know yet
STAR.exe - Application for managing and editing contents of singleimage.bin aka blankflash files
QPST - Flash tool from Qualcomm it basic function is to handle blank-flashing in a better way, also it allows for in-depth debugging of the process
Qualcom Premium Tool - Program made by Mppg Myanmar that is capable of making unlocking bootloader, OEM locks, making backup/restore of chip firmware, handling blank-flashing in VERY specific way (creating instructions for programmer), reading eMMC structure from firmware (can generate gpt layout so very useful!!!), modyfing FW and removing Xiaomi account. It also contains ALL programmers
for more:
https://forum.xda-developers.com/android/general/info-android-device-partitions-basic-t3586565
https://alephsecurity.com/
https://github.com/alephsecurity/firehorse
https://github.com/aravindvnair99/Motorola-Moto-E-XT1022-condor-unbrick
INFO:
1. What causes the brick
I bet 100$ that you hard-bricked your Moto Z Play by installing OTA updates after downgrading firmware. This is only known reason for me at the time of writing this. There is most probable reason why it happens, look:
There are two most common chips on which smartphones are built - Qualcomm and Mediatek. While Mediatek chips are "modification friendly" and simple, Qualcomm chips are somewhat more advanced and have many features that can be enabled or disabled during prorammming in factory. One of them is PBL signature checking. During programming of your phone, proper signatures of SBL are written to it. When someone tries to override default SBL with the new one, it checksums are compared with that stored. If they match, new one is flashed, if not, then update does not happen.
Ok, but what it has to do with brick?!
I explain:
1. You decide to downgrade your firmware
2. During flashing, everything goes "well" (Phone boots), but trully update is partial:
FW in chip is (obviously) more recent that the one you downgrade to, and SBL signature is different (updated), so when it is compared to the signature of SBL from FW you want to flash, it don't match. That don't rise error and flashing continues. Only partition that stays untouched is bootloader, but all other partitions get replaced by those in FW zip. SBL is still compatible with the new partition offsets and partition layout overall so phone functions normally.
3 When OTA is executed, it checks the version of currently installed firware. The most reliabe way to do it is to check checksum of SBL which is pretty logical becouse it's checksum is like "fingerprint" of firmware. Normally, if it would detect the old firmware, OTA would be stopped, but newer SBL tricks it and OTA installs anyway.
4 Results are horrible, becouse OTA does not check GPT table and flashes partitions in bad sectors, corrupting FW.
This causes bootloader to go into Qualcomm HS-USB QDLoader 9008 safe mode.
5 Viola! Hard brick!
2. How to fix it?
That is jolly good question! What we have to do is to reflash full chip firmware. Suprisingly I see some solutions, but those need to be developed:
A) SD-BOOT
It turns out that our fancy chip can probably boot from SD-CARD! The procedure works like this:
- When chip starts, one of the very first things it does is loading the memory, so it can actually work. The trick, is that chip loads it from specific disk, marked with exact name (I don't remember which, but I will do research). Speccially repared SD-CARD can appear with that name, so chip boots from it, not from internal memory. (This trick is proved to work on this model)
How to do it?
- Get full dd of working phone - it must be phone with the SAME chip and very likely the same model
- flash it to SD-CARD of 32GB or more, class 10 speed or higher, directly to card, not partition
- put card in phone, turn it on and wait
- you should see HBOOT
- select fastboot and flash new FW via it
- viola!
!!!THIS IS COMPLICATED PROCEDURE, I WILL MAKE DETAILED THREAD SOON, BUT FOLLOW IT ONLY IF YOU KNOW WHAT ARE YOU DOING!!!
B) FIREHOSE/SAHARA ATTACK
This could be achieved by sending payload via Firehose programmer that would allow to break verification of SBL or somehow allow SBL to be flashed. Now, PBL blocks attempts to update SBL. I have thesis that it is becouse PBL do not allows for SBL downgrade, so it's version must be higher, but we try to flash same version of SBL so it doesn't work. That thesis needs confirmation.
C) CRAFT BLANKFLASH
This would be last resort. It will work for sure, but this method needs knowledge and I don't know if it is doable.
STEP 1: Get white-listed blankflash checksums from OTA (we would need to reverse engineer those)
STEP 2: Break hash
STEP 3: Craft blankflash with needed hash
STEP 4: Flash
NEVER USE BLANKFLASH (ATTENTION!)
DO NOT try any blankflash files. They can make situation a lot worse and even physically (!) dmage your phone.
D) JTAG
Medusa Box etc.
E) Qualcomm Premium Tool
This can even work, but it is untested and there is a slight chance that can worsen state of phone (needs confirming).
The tool is very advanced and I need to gather info about usage, so very probable to be a good solution if we will learn how to use it!
E) METHOD 7
Interesting method from this guy: (7th option, I have contacted him if it is compatibile)
https://github.com/aravindvnair99/Motorola-Moto-E-XT1022-condor-unbrick/blob/master/Unbrick%20methods.md
3. DOWNLOAD
(Links will be aded *soon*)
XDA:DevDB Information
Unbrick Developement for Moto Z Play (addison) Full-Brick, Tool/Utility for the Moto Z Play
Contributors
Bobernator, Artim_96, Camarda
Version Information
Status: Testing
Created 2019-05-03
Last Updated 2019-05-03
Hi, same problem. Did you solve it?
Tl;dr = I have studied the boot process. I understand the Qualcomm SOC boot process PBL > SBL/XBL > And so on. I am trying to get a disassembly of the SBL. I dumped the EMMC and can view all its partitions. Now I am stuck at the 80 bytes header containing the "Loading Address". I can't figure out where and how the processor jumps to this loading address.
Greetings XDA community. This post is more relevant to the developers and power users of android and people who work as embedded developers/security researchers/reverse engineers in general.
Background - I am deeply interested in OSDev and running my own code on the hardware I own. Just like I am building my own bootloader for my PC, I had also been wanting to study the android boot processs for quite some time. In the last few days I got to it and found that the whole low level ecosystem of Android, iOS and Smartphones is really toxic and full of proprietary stuff. But I am still determined to make my own bootloader for my smartphone even if it only displays the good old "Hello World" on that little black display. I am not concerned about bricking my few phones as they are pretty much useless to me now and can be used for RE purposes.
Some Useful Links - https://blog.quarkslab.com/analysis-of-qualcomm-secure-boot-chains.html , https://alephsecurity.com/2018/01/22/qualcomm-edl-1/ , https://lineageos.org/engineering/Qualcomm-Firmware/
Technicals - I copied the whole EMMC from my rooted phone (Xiaomi Mi4) and studied the boot process. So apparently the boot process goes something like PBL --> SBL --> And so on... I found the partition labelled SBL in the dump. I am trying to get code execution at the lowest level possible but it seems I might not be able to resurrect the phone easily if I mess with the SBL (as the phone might not even go into EDL mode then). So I am first considering taking control after the SBL (and before Aboot) with my own code (even if it includes some certificate/proprietary blobs from the manufacturer). But for this I have to understand what exactly the SBL is doing in my particular processor's case. So in the SBL partition is an 80 byte header (source : http://vm1.duckdns.org/Public/Qualcomm-Secure-Boot/Qualcomm-Secure-Boot.htm). This header contains a loading address for the processor. What I can't figure out is how the processor jumps to this address. The source mentions to "remove the header and then load the file in IDA Pro" but what file are they talking about (The EMMC dump? The partition? Something else?). How does the CPU use this loading address? In my particular phone the loading address is : 00 C0 00 F8 (
https://imgur.com/a/ngfFsj5
).
Please shed some light on this issue.
I've barely read it and never dealt with qualcomm before but:
Based on the article linked they seem to be referring to SBL1... but also it should be noted according to them PBL authenticates SBL1 so unless it's unlocked or you have a private key to sign your own SBL1 probably SOL.
Also, can't you just replace kernel/rootfs and achieve the same results utilizing the built-in bootloader?
@vigilante_stark Thread closed as duplicate of
Reverse Engineering Android Boot Process - Need Help
Tl;dr = I have studied the boot process. I understand the Qualcomm SOC boot process PBL > SBL/XBL > And so on. I am trying to get a disassembly of the SBL. I dumped the EMMC and can view all its partitions. Now I am stuck at the 80 bytes header...
forum.xda-developers.com
Please review the XDA Forum Rules with special emphasis on rule no. 5 and post only ONCE! Thanks for your cooperation.
Regards
Oswald Boelcke