Database Info

[UPDATED 8/26/2014]HTC 8x wp8 GDR2 UEFI Extracted From .cab update

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

Verified boot and Full Disk Encryption: Testings, explanations, consequences

Hello,
I've tested the full verified boot stack of Nexus 5X, to better understand the various implications, especially for my SuperUser project ( http://forum.xda-developers.com/android/software-hacking/wip-selinux-capable-superuser-t3216394/ ).
First of all, I'd like to say that they took time, but with this bootloader, Google did a really nice piece of security, without excluding alternate ROMs. (No doubt they got their inspiration from Chrome project, which are(were?) ahead on the matter).
This means that we can have alternate ROMs, even possibly roots, without compromising our devices! (of course assuming root/ROMs do their part of the job)
Everything is explained in https://source.android.com/security/verifiedboot/verified-boot.html and https://source.android.com/security/encryption/index.html
For users who haven't got their hand on a Nexus 5X/6P yet, here are the various screens you might see on boot when booting a non official ROM: https://source.android.com/security/verifiedboot/verified-boot.html#user_experience
The bootloader has two states: locked or unlocked, nothing new here. locked won't let you flash, unlocked will.
But then, there are 4 boot state that can be shown (or not to the user):
- Green boot state: the device is locked and running Google's ROM. It's the only boot state which is not displayed by bootloader
- Orange boot state: the device is unlocked.
- Yellow boot state: the device is locked, running an alternate ROM
- Red state: This shouldn't happen, it means the boot.img has been badly signed. Could mean an attack is undergoing.
Yellow state has two different possible screens depending on if the boot.img is signed. The difference is, if it is signed, an ID is displayed: this is the fingerprint of the public key used to signed the boot.img.
This means that we, the users, have a way to always be sure we booted the boot.img made by the ROM developer.
The same way we know we are on a Google ROM when there is no warning screen, we know that we are indeed on the ROM we are expecting.
But wait, there is more! The bootloader gives to the TEE/Trustzone the public key of the boot.img, and the TEE/Trustzone changes its answers based on the public key.
The TEE/Trustzone answers are used to generate the key of the /data encryption.
This means that in locked mode, with a signed boot.img, a trusted keystore-owner (doesn't have to be Google), full disk encryption enabled, and dm-verity enabled, even if an attacker is capable of overwriting any part of eMMC through either a privilege escalation, or physical attempt, trying to phish you to prompt your password, then the attacker won't get access to your data!
The TL;DR is, it is now possible to be as secure as original Google's ROM with a custom ROM (you still have to trust Google though) thanks to verified boot features.
Here are my advices to fully benefit from this feature:
- KEEP Full Disk Encryption (forceencrypt)
- KEEP keystore/keymaster/qseecomd
- Lock bootloader back
- Use custom security keys, including verity key, and keep them safe.
- Sign boot.img (this is default AOSP behaviour I think)
- Use a different security key for recovery (so recovery won't ever access to your userdata)
- Untick "OEM unlocking" if you feel safe about your ROM, to have Factory Reset Protection working (ie anti-theft feature)
For unknown quality ROMs:
- When first booting a new ROM/security key, try to memorize the fingerprint. If you don't memorize it all, try to memorize characters are random position, not the beginning.
- When the device asks for you deciphering password, check you booted the proper fingerprint. Do that especially if you have unexpected reboots.
Even though I consider this is a really great step forward to having secure alternate ROMs, there are some downsides:
- There is no "verified" mode where you can flash anything, but it does apply the security policy. This makes TWRP/Flashfire/CWM/a proper OTA system needed to be able to flash again without erasing all data
- The fingerprint is 6bytes/48bits, this is by far lower than most security standards. Also, some algorithms make ascii-art from fingerprints to help user recognize matching fingerprint.
- Changing ROM is complicated: you either need to resign all ROMs with your own key, to factory reset or "transmit" in clear the cipher key
Despite the the downsides, I hope to convince some ROM devs, and users to go to lock mode and check they implemented my various advices.
Please note that this security works only on Nexus 5X/6P, it doesn't work on N6 or N9.

Next step is to add ability for the end user to create a chain of trust in bootloader area.
User must have the way to blow it's own public key to the SoC Qfuses/Qfprom and to sign a chain of bootloaders and activate a Secure Boot after that.
---
Sony Xperia A2 SO-04F (Japan version of Z1 Compact)

Did someone check the second public key emplacement in Qfuses is locked?

New piece of information about this feature, this should become widespread amongst devices.
The Android comformity document for Android M ( https://static.googleusercontent.co...com/fr//compatibility/6.0/android-6.0-cdd.pdf section 9.10) states that verified boot is mandatory.
It is/was unclear whether this document refers to https://source.android.com/security/verifiedboot/verified-boot.html, or just requires any verified boot.
But a commit in Qualcomm's bootloader gives some signs:
https://www.codeaurora.org/cgit/qui...3&id=3b6a87e4556587b3cc0c652ada680b7284d2fae7
"platform: msm_shared: update for bootloader's requirements."
It could be some overthinking, but anyway this means that all Android M-native devices will have this feature (OR be fully locked, this is allowed as well :/)
This is IMO a really great news as this means we will be able to have secure ROMs on all devices!

How could you have a secure custom ROM if you don't have ability to blow your own key (with wich partition's hashes is signed) to a SoC Qfuses/Qfprom?
---
Sony Xperia A2 SO-04F (Japan version of Z1 Compact)

I said it in my post. The encryption of /data is computed by the TZ and based on the public key of boot.img
I even think FRP is kept, though I don't really want to play with that

phhusson said:
Hello,
I've tested the full verified boot stack of Nexus 5X, to better understand the various implications, especially for my SuperUser project on N6 or N9.
Click to expand...
Click to collapse
Thanks for this.
Just a few questions (with respect to the nexus 6P):
1. Do you upload a custom keystore via "fastboot flash keystore" (nexus 6P)?
2. Will changing the key store as per (1) affect the OEM keystore (i.e. is that separate)?
3. Would you mind sharing how you made your own keystore?
- edit: found your repo https://github.com/phhusson/super-bootimg/tree/master/scripts
4. After you relock the bootloader, how are you supposed to flash a custom recovery given that there is no verified mode? My undestanding is that the stock recovery has to be in place before locking the bootloader (for data wipe to occur). Or does the locked state also use the custom keystore?
5. On a somewhat related matter, say you have no custom keystore and the boot chain is compromised so that the phone boots into the red state. Are you still able to access the android OS? I've seen conflicting information on this.

ceribik said:
1. Do you upload a custom keystore via "fastboot flash keystore" (nexus 6P)?
5. On a somewhat related matter, say you have no custom keystore and the boot chain is compromised so that the phone boots into the red state. Are you still able to access the android OS? I've seen conflicting information on this.
Click to expand...
Click to collapse
Although the keystore partition is flashable, it is useless.
The only thing checked is the public key with which is signed the boot.img
Thus the only red state possible is because of dm-verity.
The anti-signature change is provided by the fact that data are encrypted with a key based on the public key of the boot.img
2. Will changing the key store as per (1) affect the OEM keystore (i.e. is that separate)?
Click to expand...
Click to collapse
Nope. Even in CAF implementation which handles keystore, the state is different between OEM keystore and user keystore.
(Yellow in user keystore, green in oem keystore)
3. Would you mind sharing how you made your own keystore?
- edit: found your repo https://github.com/phhusson/super-bootimg/tree/master/scripts
Click to expand...
Click to collapse
Though it is mostly useless. The only use is for CAF devices, with verified mode.
4. After you relock the bootloader, how are you supposed to flash a custom recovery given that there is no verified mode? My undestanding is that the stock recovery has to be in place before locking the bootloader (for data wipe to occur). Or does the locked state also use the custom keystore?
Click to expand...
Click to collapse
I haven't checked that part yet, but I don't think you need original recovery.
But yes, the no-reflashing annoys me a lot, it means a custom ROM MUST provide an OTA system.
5. On a somewhat related matter, say you have no custom keystore and the boot chain is compromised so that the phone boots into the red state. Are you still able to access the android OS? I've seen conflicting information on this.
Click to expand...
Click to collapse
As mentioned earlier, I'm only aware of dm-verity-based red state, which can indeed be bypassed.
I hope this answers your questions, don't hesitate to ask for more

Dude I really wanna pick your brain on this. It's sad I arrive late to these parties Anyways I have a Pixel and believe this is more relevant than ever now because verified boot is strictly enforced. I want to have a modified phone with custom ROM & locked bootloader but after flashing super TWRP/SU/EX to kernel I'm positive it breaks signing.
So my question is how can I re-sign the kernel after it had been modified by SuperSU/TWRP/EX Kernel etc? I would like to flash my own keystore.img and sign the boot.img so my phone will boot with yellow warning. Can it only be done with a full build environment at compile time or can I grab some tools, generate the keystore & sign an image that pull with dd? This is something that is very new to me & there is really no step-by-step for this that I've found.
Please forgive me for my lack of knowledge on this subject but I am desperate to have a modified kernel /system and the ability to re-lock my boatloader. I can live without the dm-verity since I have a tendency to modify system files on a regular basis anyways. I sent you a PM cause I had lost this page. If I can figure out a step by-syep process to do this that didn't require a whole build env I can probably script a tool once I know necessary commands and tools.
So far I've generated my keystore keys
1.
Code:
/make_key keystore '/C=US/ST=California/L=Long Beach/O=Android/OU=Android/CN=Android/[email protected]'
now I am trying to figure out the keystore image.
2.
Code:
java -Xmx512M -jar BootKeystoreSigner.jar keystore.pk8 keystore.x509.pem keystore.img

Geofferey said:
Dude I really wanna pick your brain on this. It's sad I arrive late to these parties Anyways I have a Pixel and believe this is more relevant than ever now because verified boot is strictly enforced. I want to have a modified phone with custom ROM & locked bootloader but after flashing super TWRP/SU/EX to kernel I'm positive it breaks signing.
So my question is how can I re-sign the kernel after it had been modified by SuperSU/TWRP/EX Kernel etc? I would like to flash my own keystore.img and sign the boot.img so my phone will boot with yellow warning. Can it only be done with a full build environment at compile time or can I grab some tools, generate the keystore & sign an image that pull with dd? This is something that is very new to me & there is really no step-by-step for this that I've found.
Please forgive me for my lack of knowledge on this subject but I am desperate to have a modified kernel /system and the ability to re-lock my boatloader. I can live without the dm-verity since I have a tendency to modify system files on a regular basis anyways. I sent you a PM cause I had lost this page. If I can figure out a step by-syep process to do this that didn't require a whole build env I can probably script a tool once I know necessary commands and tools.
So far I've generated my keystore keys
1.
Code:
/make_key keystore '/C=US/ST=California/L=Long Beach/O=Android/OU=Android/CN=Android/[email protected]'
now I am trying to figure out the keystore image.
2.
Code:
java -Xmx512M -jar BootKeystoreSigner.jar keystore.pk8 keystore.x509.pem keystore.img
Click to expand...
Click to collapse
Off the top of my head, you have to add the public signing keys to the root directory of the ramdisk in the boot.img, and then sign the boot.img with the private keys.
I think the image is signed with the verity keys, and the public key has a special form for nougat/7.1/14.1, with some rounding. I think marshmallow was different. From the android build environment, you can use "make generate_verity_key". The actual source is here system/extras/verity if you just want to compile the pieces parts.. The script will be in the out/host directory if you use the make command. Use the convert option "generate_verity_key -convert <path-to-x509-pem> <path-to-key>" to convert the keystore.x509.pem cert that you made. This script will generate the public key in the just the right form that android is looking for. This is what goes into the root of the ramdisk. I think it has to be named verity_key. Yes, I know you aren't turning on dm-verity for the system image, but the boot is signed with the same key.
There is probably a script in one of the aosp repos that will make and sign the boot image. You want to find that and figure out what it is doing.
The finger print will be the first 6 words from the sha1 fingerprint:
Code:
openssl x509 -noout -in keystore.x509.pem -fingerprint -sha1
Hope that helps.
Edit: In the system/extra/verity dir, there is a boot_signer script that references a bootsignature.jar that might do what you are looking for. You'll probably have to build it since it will be in the out/host/ directory somewhere. or just hotwire the java yourself.

Off the top of my head, you have to add the public signing keys to the root directory of the ramdisk in the boot.img, and then sign the boot.img with the private keys.
I think the image is signed with the verity keys, and the public key has a special form for nougat/7.1/14.1, with some rounding. I think marshmallow was different.
There is probably a script in one of the aosp repos that will make and sign the boot image. You want to find that and figure out what it is doing.
The finger print will be the first 6 words from the sha1 fingerprint:
Hope that helps.
Click to expand...
Click to collapse
I'm slowly starting to figure this out, but I have one problem. On the Pixel there is no keystore partition so I can't flash my keystore.img. Do I need to flash a keystore for my signed images to boot? If not I will continue and sign but it was my understanding that I would need that. I suppose I should also grab the verity tools from a 7.0 tree instead of phhussons repo?

Geofferey said:
I'm slowly starting to figure this out, but I have one problem. On the Pixel there is no keystore partition so I can't flash my keystore.img. Do I need to flash a keystore for my signed images to boot? If not I will continue and sign but it was my understanding that I would need that. I suppose I should also grab the verity tools from a 7.0 tree instead of phhussons repo?
Click to expand...
Click to collapse
The pixel night be different, but I think the signature is appended to the boot.img. i don't think you need the keystore partition? I could be wrong. The fingerprint lets you know that it wasn't re-signed by a different key.
I think you want to use a nougat branch for sure.

Pixel Locked Bootloader Custom ROM / Kernel
Okay so I got this whole thing figured out. Just had to read stuff all over the place. Everything we need is in phhussons repo under the keystore_tools and the 6.0 CAF tree will suffice. I knew I was close.
BTW: I only recommend this for flawless ROMs with no major issues. Once re-locked DO NOT disable Allow OEM Unlock in the developer options menu unless you are 100% sure your phone will boot especially after /data wipes etc. Do not make modifications of any kind in a locked state with OEM unlock off. I learned the hard way with a 5X when I tried to dd a vendor.img via adb on a locked bootloader without TWRP. Don't do anything crazy! You have been warned!
Here is how you can re-sign after mods beofore re-locking a Pixel.
Grab boot images from android (needs root or twrp):
I actually used Android Terminal Emulator for this step
Code:
sailfish:/ # cd /dev/block/platform/soc/624000.ufshc/by-name
sailfish:/dev/block/platform/soc/624000.ufshc # dd if=boot_a of=/sdcard/boot_a.img
sailfish:/dev/block/platform/soc/624000.ufshc # dd if=boot_b of=/sdcard/boot_b.img
Generate Keystore:
Code:
./make_key keystore '/C=US/ST=California/L=Long Beach/O=Android/OU=Android/CN=Android/[email protected]'
openssl rsa -in keystore.pk8 -inform der -outform der -pubout -out keystore.pub.pk8
Sign the boot Images:
Code:
java -jar BootSignature.jar /boot boot_a..img keystore.pk8 keystore.x509.pem boot_a_signed.img
java -jar BootSignature.jar /boot boot_b..img keystore.pk8 keystore.x509.pem boot_b_signed.img
Reflash with fastboot:
Code:
fastboot flash boot_a boot_a_signed.img
fastboot flash boot_b boot_b_signed.img
Relock the bootloader (will erase device)
Code:
fastboot oem lock
One thing I have noticed is the fingerprint isn't displayed on boot, yet still starts up fine. Maybe it's because I didn't place the .pub key in ramdisk before signing? It could also be due to the use of CAF & not AOSP tools. In any case I got the pixel to boot yellow in a locked state after modifying the kernel.

I'm a newbie compared to you guys and I had problems running Java. I've unpacked the boot image and repacked it after modifications. I have also generated keys and I'm wondering if there is a script (Python?) that I can run to sign the boot image? Also, where should I copy the public key inside the ramdisk? This is for a 7.0.1 Nougat boot image of OnePlus 3. Thanks,

Unfortunately there is no other method that I have found to sign boot images with besides the BootSignature.jar in phhusson's repo. You could also setup a build environment but the method I described is magnitudes simpler. Both methods require java there is no python script to perform this. You put the .pub key at root of RAM disk renamed as verity_key. I think that's only required if you are using dm-verity and a generated tree for your system image.
What OS are you running? I did my signing in Ubuntu.

Was this tested on OnePlus 5 by anyone before?

Geofferey said:
Okay so I got this whole thing figured out. Just had to read stuff all over the place. Everything we need is in phhussons repo under the keystore_tools and the 6.0 CAF tree will suffice. I knew I was close.
BTW: I only recommend this for flawless ROMs with no major issues. Once re-locked DO NOT disable Allow OEM Unlock in the developer options menu unless you are 100% sure your phone will boot especially after /data wipes etc. Do not make modifications of any kind in a locked state with OEM unlock off. I learned the hard way with a 5X when I tried to dd a vendor.img via adb on a locked bootloader without TWRP. Don't do anything crazy! You have been warned!
Here is how you can re-sign after mods beofore re-locking a Pixel.
Grab boot images from android (needs root or twrp):
I actually used Android Terminal Emulator for this step
Code:
sailfish:/ # cd /dev/block/platform/soc/624000.ufshc/by-name
sailfish:/dev/block/platform/soc/624000.ufshc # dd if=boot_a of=/sdcard/boot_a.img
sailfish:/dev/block/platform/soc/624000.ufshc # dd if=boot_b of=/sdcard/boot_b.img
Generate Keystore:
Code:
./make_key keystore '/C=US/ST=California/L=Long Beach/O=Android/OU=Android/CN=Android/[email protected]'
openssl rsa -in keystore.pk8 -inform der -outform der -pubout -out keystore.pub.pk8
Sign the boot Images:
Code:
java -jar BootSignature.jar /boot boot_a..img keystore.pk8 keystore.x509.pem boot_a_signed.img
java -jar BootSignature.jar /boot boot_b..img keystore.pk8 keystore.x509.pem boot_b_signed.img
Reflash with fastboot:
Code:
fastboot flash boot_a boot_a_signed.img
fastboot flash boot_b boot_b_signed.img
Relock the bootloader (will erase device)
Code:
fastboot oem lock
One thing I have noticed is the fingerprint isn't displayed on boot, yet still starts up fine. Maybe it's because I didn't place the .pub key in ramdisk before signing? It could also be due to the use of CAF & not AOSP tools. In any case I got the pixel to boot yellow in a locked state after modifying the kernel.
Click to expand...
Click to collapse
Signing the boot image.
What does it actually do? From the semantics, it looks like it is signing the boot image with the generated private key.
How does the bootloader in the device know to trust the images(like recovery, system or roms) signed with this private key?

praveenkv1988 said:
Signing the boot image.
What does it actually do? From the semantics, it looks like it is signing the boot image with the generated private key.
How does the bootloader in the device know to trust the images(like recovery, system or roms) signed with this private key?
Click to expand...
Click to collapse
See the class B implementation of verified boot.
https://source.android.com/security/verifiedboot/verified-boot
The boot is signed with the key and it is verified against the included certificate. Yes, someone else could just sign the boot image with their key, but you can verify the fingerprint when the device boots to make sure it was signed with the correct key. This makes it tamper evident, not tamper proof.
The rom itself should use dm-verity to check the integrity at the block level. The boot image, which is signed, has the dm-verity public key so that the rom can be verified. Similar verification process can apply to recovery if it is signed and has dm-verity. Most don't, but it is certainly possible to do.

Since lineageos builds are signed by their private key, Can we just lock the bootloader after installing lineageos? Will it boot in yellow state?

praveenkv1988 said:
Since lineageos builds are signed by their private key, Can we just lock the bootloader after installing lineageos? Will it boot in yellow state?
Click to expand...
Click to collapse
On 14.1- the locked bootloader will show the yellow state and the LOS key fingerprint. But, if you don't lock down the recovery, there's little point in locking the bootloader. It also seems risky to lock the bootloader with a rom that is signed with a private key that you don't control. Depending on the phone, you night not be able to decrypt data in recovery (think backups).
On 15.1, I think things are more complex and this or related parts in LOS might not be working yet.
My bootloader is locked and I was trying to upgrade my n5x to 15.1 yesterday and all I got were bootloops. I reverted to 14.1 and recovered, but there are no guarantees.
Lastly, the way you asked the question makes me think you shouldn't lock you bootloader. Not trying to be mean or rude, but I am trying to prevent you from losing your data or being locked out of your phone. The hard part about locking the bootloader is that you can't use fastboot to flash things like radios, vendor images, etc.

[INFO] BOOT PROCESS: ANDROID vs. LINUX

NOTE:
I'm not a developer or Android expert. All information provided here is copied from different internet sources and is to the best of my knowledge. I'll not be responsible for any harm to you or your device resulting from this.
1. PC BOOT PROCESS
Before diving into Android boot process, let's have a look at Linux PC first.
Power Button Pressed
Power On Self Test (POST); identify the devices present and to report any problems
BIOS / UEFI
Necessary hardware initialization (keyboard, disk etc.)
Disk (MBR)
DOS Compatibility Region code (optional)
Bootloader
Active/boot partition (Boot sector)
Kernel
Initrd / initramfs (init)
Services/daemons/processes
BIOS / UEFI is the first software code that is hard-coded on board and runs after we press power button. BIOS runs in real (16 bit) mode of processor, thus it can not address more than 2^20 bytes of RAM i.e. routines can't access more than 1 MiB of RAM, which is a strict limitation and a major inconvenience.
When creating partitions, MBR is saved in LBA0, GPT header in LBA1 and primary GPT in LBA2-33, LBA34 (35th) is the first usable sector. Backup or secondary GPT is saved in last 33 LBAs, last usable sector by OS is ( Total LBAs - 33 ). Partitioning software aligns GPT partitions at larger boundaries, e.g. at LBAs that are multiple of 2,048 to align to 1,048,576 bytes (512 bytes * 2048 = 1 MiB) boundaries. So first sector of first partition is LBA 2048 and so on.
When a system boots, driver of a filesystem is to be loaded in RAM in order to use that filesystem, but driver is itself a file, inside some filesystem. It's like a chicken and egg scenario. So the solution is to always load (as a BIOS/UEFI standard) the first sector on the bootable storage (0/0/1 C/H/S in older schemes and LBA0 in newer), which is (legacy or protective) MBR. This communication between BIOS/UEFI and storage media is through commands which are specific to host controller e.g. ATA commands for devices with SATA/AHCI interface on PC.
Master Boot Record (MBR)
1st 512 bytes (1 sector) at the start of 1st valid disk
Bootstrap code (446 bytes) + Partition Table (64 bytes)
Executable code: Bootloader 1st stage scans partition table and finds 1st sector of active partition (or may point towards intermediate stage)
Partition table provides information about active/bootable partition (and all others as well)
Small size of 64 bytes limits the number of maximum (primary) partitions to 4
Since bootloader unable to understand filesystem (inodes etc.) yet, so MBR is itself executable
Last 2 bytes are boot signatures i.e. to find immediately if disk/drive is bootable or not and hence switch to the next
DOS Compatibility Region
This stage is specific to legacy GRUB, GRUB 2 (default bootloader on most of modern Linux ditros) splits this stage to stage 2 and 3
31.5 KiB / 63 sectors next to MBR, contains filesystem utilities
Still loaded by BIOS routines (or bootloader may use it's own drivers)
Required by certain hardware, or if "/boot" partition (sector containing stage 2) is above 1024 cylinder heads of disk, or if using LBA mode
Volume Boot Record (VBR) / Partition Boot Record (PBR)
Sector no. 63 (64th sector) and above may contain Volume Boot Record or Partition BR, very similar to MBR
Also called Volume Boor Sector, it may be the first boot sector on any partition
NTFS saves VBR as metadata file name $Boot at first clusters, which also contains cluster number of file $MFT. $MFT describes all files on the volume; file names, timestamps, stream names, lists of cluster numbers where data streams reside, indexes, security identifiers (SID's), and file attributes like "read only", "compressed", "encrypted", etc.
If disk isn't partitioned, it's the first boot sector of disk
Boot Partition (if exists)
In MBR scheme, a partition can be marked bootable / active using a flag, usually the first partition of disk
Windows stage 1 bootloader reads and loads only the "Active Partition" from MBR Partition Table
Bootsector or VBR/PBR is read by stage 1 or 1.5 (2 or 3 on GRUB2) bootloader which loads stage 2 (4 on GRUB2) or actual bootloader
MBR / VBR Contains:
Jump instruction (first 3 bytes) i.e. "goto boot code" command
Filesystem header
Executable boot code, usually contains jump instruction for next adjacent sector(s) containing stage 2 bootloader
End of sector (similar to boot signature)
Stage 1 or 1.5 (or 3 on GRUB2) bootloader reads the filesystem table (like MFT / FAT) on partition and loads actual bootloader as a regular file
Bootloader (Actual)
Loaded by previous bootloader from the filesystem of same partition
Loads all necessary filesystem drivers (if any further required)
Configuration is read from database e.g. /boot/grub/ on Linux (GRUB) and <"System Reserved" Partition>/Boot/BCD on Windows (BOOTMGR)
Windows:
BCD is binary file, can be read and modified by commandline tool bcdedit.exe or GUI tool EasyBCD
NTLDR on XP simply used C:\ as active partition reading C:\Boot.ini
Linux:
GRUB makes use of modules to offer extra functionality for complex boot processes
It can show a boot menu to user if needed or configured e.g. for multi-booting or in safe/recovery mode or boot from USB/Network etc.
Locates and loads the kernel of desired OS and ramdisk in RAM
If GRUB is unable to handle the kernel of an OS like Windows, it can be configured for CHAINLOADING i.e. read and execute bootsector of the partition containing Windows bootloader
'os-prober' helps 'grub-install' and 'grub-update' finding Windows boot partition (System Reserved) by reading bootloader configuration in that partition
Kernel
1st MB of kernel from same partition (/boot) loaded in RAM by bootlader in read mode, then switch to protected mode (32-bit) and move 1MB ahead clearing 1st MB
Then swith back to real mode and do same with initrd (if it's separate from kernel)
Kernel contain ramfs drivers to read rootfs from initrd and mount it
Initramfs
Contains minimal filesystem and modules (required drivers which aren't carried by kernel) to access real rootfs (hard driver, NFS etc.)
udev or specific scripts load required modules
<ramdisk>/init is usually a script which loads necessary drivers and mounts real rootfs
finally init switch_root's to real rootfs and executes <real rootfs>/sbin/init; sysV (traditional), upstart (Ubuntu's initiative) or systemD (the latest widely accepted)
init > getty (on virtual terminals) > login (program) > motd > login shell > bashrc / bash_profile​Read more about LINUX CONSOLE & VIRTUAL TERMINALS
UEFI
UEFI can understand filesystem contrary to BIOS, hence no limitation of MBR code (446 bytes)
Needs an EFI System Partition (ESP), preferrably of minimum 550MB
ESP partition is formatted as FAT32 but can understand other filesystems such as FAT12 (floppy), FAT16, ISO9660 (CD/DVD), UDF etc.
EFI firmware reads directly <ESP_Partition>/EFI/<vendor>/<boot_programs> as configured in boot manager (which disk, which partition, which program)
Boot programs make use of EFI firmware or EFI shell or GUI Boot Manager to load kernel
If boot program is just the disk, (no partition and no program configured), then fallback program <disk>/<ESP partition>/BOOT/BOOTX64.EFI is executed
Secure boot feature verifies signature of boot program before loading
Multi-booting is easy, just read different entry from ESP partition unlike relying on single bootloader to chain load all available OS's
EFISTUB feature of Linux kernel allows booting kernel directly as a boot_program
UEFI works better with GPT than MBR
Must read:
ANDROID PARTITIONS & FILESYSTEMS
2. ANDROID BOOT SEQUENCE
There might be a single or multiple bootloaders (to give directions how to boot). For a typical android device (most common Qualcomm SoC / ARM processor), boot sequence is as follows:
BootROM (like BIOS on PC). It's integrated with SoC.
Processors, bootloaders
POST
SBL
Parallel loading related stuff from different partitions.
Application BootLoader (aboot)
Primary Boot Mode (if no Kernel detected or if bootloader/download mode key combination applied)
Bootloader/Download Mode
Secondary boot
Kernel (hardware detection and populating /sys, /dev/ and /proc directories as the processes start) and initramfs (creating rootfs and other pseudo filesystems on rootfs)
Init (first process with PID "1". It initiates further loading of processes and daemons)
System / OS (ROM)
Recovery (if recovery mode key combination applied. It's a kernel with UI to perform basic troubleshooting operations)
3. BOOTLOADERS
Bootloader(s) facilitate the the initial starting up of device by taking control from SoC, performing necessary checks, loading required components and then hand over the charge of booting to kernel. RAM is detected at first stage to start loading configuration of other hardware (like keypad, display etc.) in it.
There exist(ed) multiple bootloaders which are executed by different processors, on different devices with different (partition) names like RPM (PBL), DBL (Device Boot Loader; CFG_DATA or sbl1), SBL2, SBL3 (QCSBL) and OSBL (Operating System Boot Loader) etc.
In a nutshell, on modern ARM devices (Qualcomm SoC):
BootROM / iROM and PBL
iROM run by CPU0 on power button press, loaded in iRAM (before RAM is initialized)
It may set up RAM and execute PBL in RAM or leave this for SBL. iROM/PBL is hard-coded on SoC, written during CPU production process and it's closed source.
On devices (such as open boards or some tablets) which support booting from multiple sources like eMMC/sdcard/USB/UART/Network like a PC BIOS, there is an extra stage between iROM and PBL:
IBL (Initial BL)
It's also loaded in iRAM. Depending on CPU pin settings (hidden and soldered or exposed for manual switching) informed by iROM, IBL passes boot mode selection to PBL and optionally checks PBL integrity if itself e-signed by iROM.
SBL or XBL (Preloader)
IBL calls SBL from eMMC/SDCard which supports LCD output. SBL initializes the DDR RAM, loads the trusted firmware (TZ) and the RPM firmware if not loaded by BootROM. SBL calls the final bootloader after self testing the device.
Uboot is open-source secondary bootloader for embedded devices. However sources of SBL can also be obtained from Qualcomm.
ABOOT (APPSBL; predecessor of Little Kernel)
ABOOT loads Partition Table, kernel, splash screen (logo) and modem. It's also responsible for charging mode and fastboot mode. Memory addresses in RAM for boot/recovery partitions are hard-coded in aboot.
Other examples of final (i.e. just before kernel) bootloaders are uboot (traditional Linux bootloader for embedded devices) or manufacturers' developed BL's like hboot (used by HTC) and redboot etc.
Manufacturers put their limitations (say of network carrier i.e. SIM lock and others) at this stage. USB protocol isn't enough and communication with bootloader to hack such restrictions require special devices (called Flashing Box or Service Box in common language), even sometimes a protocol like JTAG i.e. talk directly to microprocessor.
As a norm, all of these stage-1,2,3... bootloaders are simply called BOOTLOADER. While on some devices there is no bootloader partition at all and bootloader(s) resides on SoC.
Coming back to the booting process, after initializing boot process, bootloader (if it's locked) checks the integrity of boot.img (normal boot) or recovery.img (recovery boot), loads them in RAM and transfers control to kernel offering it with "phys_initrd_start" address of compressed (cpio, gzipped) initramfs.
4. KERNEL & INITRAMFS
Once the kernel is loaded and extracted in RAM by bootloader along with parameters, kernel starts executing. Kernel is in fact a self-contained (static) executable binary, made up of many object files (.o) linked together at compile time. Once the architecture and CPU are identified, architecture-dependent code is executed as per parameters passed from bootloader. Then arch-independent stage is executed which includes setting up drivers (display, touch etc.), filesystems like rootfs, tmpfs, proc, ext4 etc. and initializing console as well (if configured). Here the kernel-space ends and user-space begins (what they call it).
Kernel extracts compressed initramfs in rootfs (which itself is ramfs or tmpfs) and executes /init binary which subsequently reads its configuration files /init.rc and other /*.rc files written in Android specific init language. With the help of kernel, init mounts pseudo filesystems /sys and /proc and populates /dev directory containing device node files. Then it mounts /system and all other partitions including /data (also decrypts it if encrypted) and sets (SELinux security) policies, system properties and environment variables (PATH, EXTERNAL_STORAGE etc.). Additionally init also look after any hardware changes (ueventd) and started services changes (watchdog) occurring dynamically.
Finally init starts the runtime located on the system partition. One of the major last processes started by init is Zygote (Java virtual machine) which compiles apps to run for specific architecture (mostly arm / arm64).
DEVICE TREE BLOB
Device Tree Blob (DTB) - created by DT Compiler (DTC) from DT Source (DTS) text - is a mapping of hardware components on a board/SoC and usually a part of kernel source.
PC hardware usually support hardware enumeration through ACPI i.e. kernel may enquire (probe) the buses - PCI (internal devices), USB (external devices), SCSI (storage devices), HDMI/DVI/VGA (display devices) etc. - which device is connected to it.
Buses on embedded devices (including Android devices) mostly don't support enumeration (hardware discovery) because there are usually fixed set of devices and no option for a different OS to be loaded on device. Therefore OS needs to be informed of all connected devices and this is done by providing a standard DTB to kernel. DTB is provided by SoC / motherboard vendor and is usually a part of kernel source. During boot process, DTB is loaded by bootloader at boot time and passed to kernel so that it can discover hardware and create node points accordingly.
We can view device tree on Adroid device by:
Code:
~# ls /sys/firmware/devicetree/base
~# ls /proc/device-tree
DTB may live on a separate dtb/odm partition as specified by AOSP (and was the proposed solution for ARM based embedded Linux devices before Android's birth) but that isn't widely practiced. Usually DTB is appended to kernel zImage/Image.gz or placed at second stage inside boot.img.
VERIFIED / SECURE BOOT
Ensuring a chain of trust from Power ON up to loading of kernel is with the domain of SoC vendor (Qualcomm, Intel etc.) and OEM's. Injecting some malicious or harmful code at any point during booting is made harder to the extent of impossibility.
To ensure a secure booting chain, PBL verifies authenticity of SBL which subsequently verifies integrity of bootloaders (TZ, RPM, DSP, HYP and aboot) so that to avoid loading of unsigned images (boot, recovery, system and others). TZ, after being loaded by SBL also verifies ABOOT using a hardware-based root certificate.
A bootloader with Verified/Secure Boot implementation verifies boot.img or recovery.img (kernel, initramfs and DTB appended to kernel or on second stage of boot.img) by matching their signature with key(s) stored in "OEM keystore" (some partition like CMNLIB, KEYMASTER or with some other name) which itself is signed by OEM. Some vendors allow replacing/appending this keystore with custom one so that custom signed images can be flashed followed by re-locking of bootloader. A simple detail is given here.
At this stage, the chain of trust is handed over to "dm-verity" key stored in boot image initramfs, responsible for "Verified Boot" process of Google/AOSP. Dm-verity (a part of Verified Boot implementing Linux Device Mapper by Google) is a kernel feature i.e. it comes into action after boot image (kernel and ramdisk) is loaded in RAM. It verifies subsequently loading block devices; /system, (/vendor if it exists) and optionally others.
For details see this, this and this.
Google suggests integrating libavb (native code to verify integrity of boot.img) in bootloaders starting from Verified Boot 2.
Unlocking Bootloader
Read here to know about the risks of BL unlocking.
Unsigned kernel or recovery cannot be loaded unless bootloader is unlocked. To make any modification to OS, a critical piece of process is disabling a security system built into the Android's bootloader (aboot) that protects the read-only partitions from accidental (or intentional) modification for privacy, security and DRM. This is what's referred to as "unlocking NAND" or "unlocking bootloader." You have to firstly unlock bootloader to modify partitions "boot" or "recovery" and to gain root access on /system. If bootloader is locked, you only have write access to /cache and /data partitions. Everything else is read-only on device and bootloader will prevent unsigned images from being flashed to the phone. Unlocked bootloader ignores signature verification check which was initiated by BootROM and then transferred to "SBL" and then to "ABOOT" while loading kernel or recovery.
Some newer devices don't allow unlocking of bootloader directly (FRP) without permission from manufacturer to ensure more security i.e. contents of partition "devinfo" are signed by the OEM and can't be modified without their approval. After having permission, an official method is provided to unlock BL using PC. Still some functions related to Proprietary Content might be lost due to bootloader unlocking.
DRM is used to protect content from being copied.
Certain pre-loaded content on your device may also be inaccessible due to the removal of DRM security keys.
Click to expand...
Click to collapse
Android Rooting
Must Read: Root User and Linux Capabilities: Linux vs. Android
Note: Unlocking Bootloader and Rooting breaks "Verified Boot". It can be dangerous.
In order to perform some privileged task on Android, we need to "root" the device first. Since it's impossible to start a process with elevated privelages from within running Android OS, rooting usually involves running a root process (su-daemon) from boot with all capabilities. Superuser requests are made by any non-privelaged programs by executing "su" binary and permissions are managed by an app.
In early days, rooting usually involved booting into a custom recovery which in turn mounted and modified /system files. Usually some daemon's executable binary was replaced with a custom script. In order to address the OTA and other issues caused by improving security features (SELinux, Verfied Boot, SafetyNet etc.), systemless root method was introduced which is used by latest apps like Magisk. It involves modifying /boot image and putting some files on /data as well. So a new init service is injected fulfilling all necessary requirements of new security mechanisms.
In both cases, a locked bootloader won't boot custom recovery or modifed kernel (boot.img). See Verified Boot. Therefore bootloader needs to be unlocked for rooting.
However it is possible to gain root sometimes without unlocked bootloader but not always.
Other methods of rooting a phone from within a running ROM using some sort of One-Click rooting solution (KingRoot, Z4Root, KingoRoot etc.) depend on some vulnerability or exploit in Android OS. Making such security breaches is getting harder and harder with every new release of Android and with improved defense mechanisms, though it varies for different vendors too. The most prominent was with the release of Lollipop and Marshmallow when systemless method had to be introduced beacuse the previous methods failed to work. When phone is rooted using one of such improper root methods, there is a high probability to face "incomplete root" like messages at some point. If such a rooting method works for your device, it's alarming. This exploit is also a way for malware to enter your device. For examples, see Magisk Installation - Exploits, this and this. A very popular exploit dirty cow was patched later.
In addition to that, there are some hacks for certain devices to flash custom recovery without unlocking bootloader using some kind of Firmware Flasher tool (SPFlasher, MiFlasher etc.) in Download Mode because Download Mode provides access to device even before bootloader/fastboot is loaded. Or if you are expert in coding, you can mimic the custom recovery image look like the factory signed firmware and flash it through stock recovery. But this exploit isn't a universal solution either.
So the proper way to rooting which doesn't need any vulnerability, goes through unlocked bootloader. While buying a new phone this must be considered. Keeping you away from root access and unlocked bootloader goes in favor of vendors. By forcing you to use their ROMs (with bundle of useless bloatware apps), they earn a lot from you - money as well as forced loyalty - by collecting data, showing ads and using a lot of other tactics. Go for a brand that provides kernel source and ability to unlock bootloader (on customer's responsibility and with voided warranty obviously).
FIRMWARE UPDATE PROTOCOLS (BOOTLOADER MODE)
Likewise BL, on every device there might be a single or multiple BL modes with different names like bootloader mode, download mode, emergency mode (EDL), ODIN (Samsung), nvFlash tool etc. When we boot in BL mode, device is stuck on boot logo. Some factory flashers work in these modes such as MiFlasher (Xiaomi) and SP Flash Tool (for MTK devices). Bootloader or Download Mode is accessible even if device is soft bricked i.e. if Recovery and/or ROM isn't accessible.
Download Mode
Download Mode (certain button combination while powering on device; usually Vol. Up + Vol. Down or Vol. Down for longer duration + Power) is an official method used by many vendors to flash factory firmware / updates using Flasher (software). Emergency Download Mode (EDL), as it's called on Xiaomi Devices, can also be accessed through fastboot/adb commands or by using some jigs/jumpers. However, to ensure more security, EDL is disabled on some newer devices.
Download Mode is primary to bootloader mode (at PBL or SBL stage) and can be used without unlocking bootloader.
Odin (Samsung), QPST/QFIL work in Download mode (Qualcomm HS-USB QDloader 9008).
When we boot in Download mode, device is stuck on blank screen.
Fastboot Mode
Fastboot - provided by ABOOT - is a software development tool and a standard communication protocol for Android bootloader. It's an alternate of recovery flashing that works in BootLoader mode (aboot) and comes bundled on most of the recent ARM Qualcomm devices. It's a minimal UI through commandline to interact with device in case of failure or to modify / flash partitions. Some OEM's provide fastboot with limited functionality e.g. 'fastboot oem' commands not working and some devices haven't at all. It's up to the discretion of mobile phone vendor.
Fastboot mode is used to perform operations through commands when device is connected to PC through USB. It works even when phone is not switched on in Recovery or ROM or even if android isn't installed on phone. You can read here what operations we can perform through fastboot mode.
Only NAND (eMMC) and USB modules (drivers) are activated at this stage.
INIT PROCESSES & SERVICES: ANDROID vs. LINUX
FILESYSTEM TREE MOUNTED BY INIT: ANDROID vs. LINUX
RESOURCES:
From the bootloader to the kernel

RESERVED

RESERVED

RESERVED

RESERVED

You have to firstly unlock bootloader to modify partitions "boot" or "recovery" and to gain root access on /system. If bootloader is locked, you only have write access to /cache and /data partitions. Everything else is read-only on device and bootloader will prevent unsigned images from being flashed to the phone.
Click to expand...
Click to collapse
I'm under the impression that unlocking the bootloader is not mandatory for rooting the device.
You can root the device with a locked bootloader and gain full access to /system partition.

NikosD said:
I'm under the impression that unlocking the bootloader is not mandatory for rooting the device.
You can root the device with a locked bootloader and gain full access to /system partition.
Click to expand...
Click to collapse
Yeah I think my brief statement is a bit misleading because rooting is out of the scope of this thread. I have added some details to first post.

Thank you very much for all this useful info.
Some more comments.
A locked bootloader won't boot custom recovery or modified kernel (boot.img)
Click to expand...
Click to collapse
It happens to have a budget Chinese tablet with Oreo 8.0 and MediaTek SoC, which I can root using a modified/patched boot.img with Magisk v17.1 inside of course - I mean full root without problems - keeping the bootloader locked before and after rooting.
In addition to that, there are some hacks for certain devices to flash custom recovery without unlocking bootloader using some kind of Firmware Flasher tool (SPFlasher, MiFlasher etc.) in Download Mode because Download Mode provides access to device even before bootloader/fastboot is loaded
Click to expand...
Click to collapse
The tablet mentioned above, belongs to this category too.
Using SPFT (Smart Phone Flash Tool), I can flash custom recovery TWRP for my device without unlocking the bootloader.
So, I have two questions:
1) Is it rare to have such a device or is it common nowadays to be able to root and flash custom recovery TWRP with locked bootloader ?
2) How is technically possible to patch boot.img for rooting and flash TWRP using SPFlashTool (even in download mode before bootloader) without complains afterwards from bootloader, verified boot, dm-verity and all these safety checks that validate digital signature of Vendor ?
I mean you can do whatever you want before bootloader starts, but how can you escape from security traps after the initialization of bootloader verifications ?
Thank you.

NikosD said:
1) Is it rare to have such a device or is it common nowadays to be able to root and flash custom recovery TWRP with locked bootloader ?
Click to expand...
Click to collapse
I'm not sure how common it is but I must say these are exploits. Developers are making use of these vulnerabilities for positive and negative purposes. But these are not a "long-term" solution for rooting.
2) How is technically possible to patch boot.img for rooting and flash TWRP using SPFlashTool (even in download mode before bootloader) without complains afterwards from bootloader, verified boot, dm-verity and all these safety checks that validate digital signature of Vendor ?
I mean you can do whatever you want before bootloader starts, but how can you escape from security traps after the initialization of bootloader verifications ?
Click to expand...
Click to collapse
That's what my point is. Fastboot code verifies signatures/hashes only when flashing the image and doesn't verify or fails to verify integrity if image is already flashed. This is not the desired behavior so it's an exploit and it should be closed. Letting unsigned images be flashed in Download Mode is another exploit which is common with Chinese vendors as far as I have come across some instances. They don't address "loopholes" seriously. Failure to stop security breaches at or after bootloader level is definitely on SoC Vendor or OEM's part. I have added a paragraph in first post with some useful details and links.
This link explains:
The Qualcomm SoC is analyzed in the previous chapter dload / edl mode, the mode in the firmware image download process does not do any verification, can be directly written into the brush.
Click to expand...
Click to collapse
It's badly translated from Chinese but is informative.
Exploiting Qualcomm EDL Programmers is a complete series on this subject summarized here.

mirfatif said:
Only NAND (eMMC) and USB modules (drivers) are activated at this stage.
Click to expand...
Click to collapse
Hey pal, I'd like to know if you could help me with an issue I'm facing. I have a Moto G5 that isn't booting to any ROM (it either bootloops in bootlogo or in boot animation), and also on TWRP and during the boot animations the device is slow as hell (like 0.5 FPS on TWRP and even less on boot animation; on TWRP the device also takes a few seconds to complete even the simplest tasks - like the press of a button or the swipe of a slider - here's a video that shows differences between how stuff works on fastboot and how slow things are on TWRP, it takes like 2 hours to completely flash a custom ROM, i.e.).
I know much of the issue will be device-specific, but my point (and the reason I quoted that specific part of your OP) is that, on fastboot mode, the device is snappy and responsive. When I press a button it completes the corresponding task immediately, frames don't stutter (not that there are any animations to be rendered in fastboot, but when I switch from one option to another using the volume keys, it does so on screen as it should, with no lag), and so on. Stock recovery also seems to be ok with speed, but it's even harder to measure than fastboot because, in almost 10 years meddling with android devices, I have always found stock recoveries (and CWM in the pre-TWRP times) to be somewhat slow. Stock recovery definitely looks snappier than TWRP, though. Tried several ROMs, both custom and stock, and the issues remain on all of them.
I got to this post by researching if fastboot mode was stored on the same NAND chip as recovery, OS and so on (found out that yes, it's all on the same chip). If it wasn't, I could just assume it was a hardware fault on the NAND chip, and that would be the reason that fastboot was running fine but recovery and OS weren't, but since they're all on the same cell, I can only think that some part of the system (I mean as in every single code that runs on the device, not only the OS) that loads on TWRP and on normal boot, but not on fastboot (and possibly not on stock recovery) are faulty, thus being a software issue (either solvable with just a normal USB cable or needing a flash box).
So, my question is: which are the differences in the parts of system loaded by fastboot and by TWRP? Are there any parts that are loaded by TWRP that aren't loaded by the stock recoveries on most devices?
I know it's a rather complicated question and some stuff might be device-specific, but if there is anything you could tell me that are more generic to every Android device, it would help me a lot. Thanks in advance.

Would it be possible for manufacturers to provide you with your phones' unique Android Attestation Key?

[android-security-discuss] Apply for key attestation for hardware-backed keystore authentication
android-security-discuss.narkive.com
It says in this link that the TEE attestation keys aren't generated in the TEE and are batch keys issued by a keymaster? So, if the manufacturer has access to your phone's individual key, should they be able to restore it to your device if your bootloader has stayed locked with all official software installed?

Perhaps we might have the ability to regenerate our own keys? They appear to be generated by the secure bootloader and the attestation key seems to change on updates. So, if we give the generator what it needs from the secure bootloader (Which shouldn't be lost if it stays locked), the Android version, and patch level could we generate a new key, like what the system seems to do on the very first boot?
Keymaster Functions | Android Open Source Project
source.android.com

AFAIK the hash keys stored in the vbmeta files are generated when manufacturers compile Android for their phones. Also Android's boot.img gets signed by OEM.
May be you by means of AVB2TOOL can regenerate the vbmeta files on base of installed Android at your own. But IDK it.
FYI: On device's very 1st boot the ANDROID_ID key gets generated, not the vbmeta files.

[CLOSED] 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 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