Database Users

[REF][R&D] Building Bootloaders on Qualcomm Devices

This is a research & development thread for building your own bootloaders on a
number of modern Qualcomm based devices, utilizing extracted partitions and
corresponding partition table information. We'll focus in particular on those
devices using the Snapdragon SoC/PoP chipset.
Code:
Thread difficulty: [B][COLOR=Red]Hard[/COLOR][/B]
Thread type: Development
Thread completeness: Fair
Building your own Bootloaders on Qualcomm Devices
Table of Content:
Introduction
Qualcomm/Intel HEX files
<WIP> QFIT (Qualcomm Factory Image Tools)
<WIP> The MBR Image
<TBD> BoToX (Bootloader Tool Box)
<WIP> Building for Windows Phone 8
<TBA> Compiling Bootloaders
<WIP> References
INTRODUCTION
All modern Qualcomm mobile chipsets contain some functionality for sideloading
binary code from an external source in case the normal boot procedure fails or
is interrupted by some other HW signal, like JTAG or other JIG debug
connection. In addition this side loading functionality is crucial for the
programming and formatting of additional memory devices like eMMC and SD cards
that are external to the processor and it's accompanying PoP memory. It is
also used by OEMs to revive soft-bricked devices and update the many
bootloaders used in the Qualcomm bootloader chain. However, all these features
and their various functionality are closely guarded secrets usually kept from
the public by very strict NDA for their company employees. Thus it has been
very difficult for the developer community to try to understand, use and
benefit from these most useful functions. Instead the dark side of mobile
phone community have made continuous profits in reversing the manufacturer
schemes by providing their own hacks and programs to offer mobile owners
various solutions for a charge, that is often out of proportion for what is
actually done. This is especially true for services requiring debricking by
various JIGs (such as the proprietary Anyway Jig and various JTAG solutions.)
All these solution rely on the possession of some inside information about the
device in question.
This thread is an attempt to alleviate this situation and allow anyone who
wishes, to freely flash and take charge of their own hardware, in the true
spirit of the XDA community. Here I will present information about how
Qualcomm put together their own bootloaders and how you could do the same, if
you only had the source code or talent to write your own or modify already
existing such. Although, there is one big hitch. Most new chipsets are using
a very secure authentication scheme (Secure Boot 3.0) to prevent
non-developers from flashing and using arbitrary boot code.
The information herein have been collected from older available Qualcomm tools
such as QPST and QXDM, and from pieces of their documents found around the
internet. Another important and challenging source have been the many Chinese
websites where people have managed to get some of this working and actually
bothered writing/blogging about it. Thank you China!
I will not go into details about the various bootloaders as they are already
covered elsewhere, for example, in this thread. I have also chosen to focus
primarily on the Qualcomm Snapdragon processor/modem SoC series, as they are
the most popular chips used in most mid- to upper-level smartphones today.
These devices typically include the MSM8x60 series consisting of the widely
popular MSM8660 and MSM8960 SoCs, currently found around the world. Another
highly relevant chipset is that of MSM8260A which is found in many Windows
Phone's, in particular in WP8.
...​REFERENCES
<WIP>​==================================================
If you find any errors or have any relevant additional information
that can be important for the correctness and content of this thread.
Please let me know by either posting here or sending me a PM.
Also, please do not ask any questions that is not of direct relevance
or help in the discussions in this thread . They will not be answered
and removed.
==================================================
​Enjoy!

Qualcomm/Intel HEX files
This is a text-based (ASCII) file format originally introduced by Intel to
distribute PROM code, that include error checking for redundancy. Today
Qualcomm use this file format to distribute their modem/processor boot code
used in downloading bootloaders in the OEM build-processes or for emergency
download modes etc. There are several dozens of variations on the HEX format,
so we will not go into the details of other formats or uses, but only for that
used in the Qualcomm bootchain.
To convert the Qualcomm provided Intel-HEX files into binaries, you can either
use the simple pre-compiled windows and linux binary hex2bin (src), or you can
compile the much more flexible and complete EPROM file-converter utilities of
srecord, which can handle many more HEX formats including hex-diffing and
hex-merging etc. One of the Qualcomm image build "toolkit" programs, the
"emmcswdownload.exe" already contain a hex-to-bin converter, but it is usually
appending more than one binary file as described in the required XML partition
file. For details about this see the next section about QFIT.
Next we jump right into describing the Qualcomm (aka Intel-32) HEX-file
format. The content of a typical HEX-file, let's say the MPRG8660.HEX are as
follows:
Code:
:020000042A00D0
:10000000D1DC4B843410D773FFFFFFFFFFFFFFFFEE
:10001000FFFFFFFF500000005000002A348802005C
:10002000348802008488022A000000008488022AA2
...
:108850001CAF012A000000005CC4012A8CC4012A5C
:1088600000000000FCBF012AFCC0012A04C0012A4C
:10887000BCC2012AC4C2012ACCC2012A00000000E5
:0488800000000000F4
:040000052A000000CD
:00000001FF
Let's break this down. First things to know are that:
Each line is a record.
Hexadecimal values are always in uppercase.
The sum of all the bytes in each record should be 00 (modulo 256).
So for example, a typical record can be broken down as:
Code:
[SIZE=2]
:[B][COLOR=DarkRed]10[/COLOR]0020[COLOR=Blue]00[/COLOR][/B][COLOR=Green]348802008488022A000000008488022A[/COLOR][COLOR=Red][B]A2[/B][/COLOR]
: 10 0020 00 348802008488022A000000008488022A A2[/SIZE] [SIZE=2]
| | | | ----------------+--------------- |
| | | | | +-- Checksum (1 byte)
| | | | +-------------------- Data (0-255 bytes, here 16)
| | | +--------------------------------------- Record type (1 byte)
| | +------------------------------------------- Address (2 bytes)
| +----------------------------------------------- Data Byte Count (1 byte, here 16)
+-------------------------------------------------- Start of record delimiter[/SIZE]
There are 6 record types defined (for Intel-32 HEX):
'00' = Data Record
'01' = End Of File (EOF) Record
'02' = Extended Segment Address Record
'03' = Start Segment Address Record
'04' = Extended Linear Address Record
'05' = Start Linear Address Record
But only 4 are used for Qualcomm processor/modem HEX-files:
00: Data Record
01: End Of File (EOF) Record
04: Extended Linear Address Record
05: Start Linear Address Record
Where "04" (Extended Linear Address Record) allow for 32 bit addressing (up to
4GiB). The address field is 0000, the byte count is 02. The two data bytes
(two hex digit pairs in big-endian order) represent the upper 16 bits of the
32 bit address for all subsequent 00 type records until the next 04 type
record comes. If there is not a 04 type record, the upper 16 bits default to
0000. To get the absolute address for subsequent 00 type records, the address
specified by the data field of the most recent 04 record is added to the 00
record addresses.
While the "05" (Start Linear Address Record), contain the address that is
loaded directly into the program counter (PC / R15) of the ARM processor. The
address field is 0000, the byte count is 04. The 4 data bytes represent the
32-bit value loaded into the register.
NOTE: The data field endianness may be byte-swapped.
Qualcomm use the following convention for naming their HEX boot-loader
"programmer" files. This is especially true when used in conjunction with
their emmcswdownload.exe. (See this section.)
yPRGxxxx.HEX
where "y" is one of the following:
Code:
[SIZE=2]N = NAND
A = NOR
M = eMMC
arm = Is used to bypass automatic selection by QPST by renaming a custom version to "armprg.hex"
flash = ??
[/SIZE]
<< Here Be More Dragons >>

<< Here Be Snap Dragons 2 >>

<< Here Be Snap Dragons 3 >>

<< Here Be Snap Dragons 4 >>

<< Here Be Snap Dragons 5 >>

<< Here Be Snap Dragons 6 >>

one more awesome guide from E:V:A

It would be cool if someone made a synalysis grammar for the hex codes E:V:A documented above.
For those of us hacking on our Mac OS X machines.

I'm closing this thread until I can actually fulfill my promises.
Sorry! Stay tuned.

[Q] [WIFI Monitoring] Toolchain and Linking

Hi everybody,
It's my first post on XDA, because I always got my answer on the differents topics I found.
I'm actually working on monitoring network. I use the firmware provide by these brillant guys :
http bcmon blogspot ie/.
I want to developp an native code to write a easy airodump-ng like, to monitoring the traffic close to my device.
I need to use radiotap headers to do what I want, and of course a monitoring access to my wireless card.
So I reverse the bcmon.apk provided by bcmon team, to look how they lauch airodump-ng in a term. I noticed they use LD_SHARED=`pwd`/libs LD_PRELOAD=`pwd`/fakedriver.so.
My first problems : my toolchain (provided by NDK) don't have radiotap header access, and I really don't know how to add these last one to it.
My second problems : how to compile my code with the LD_SHARED/ LD_PRELOAD libraries used by bcmon drivers to ensure I'll be able to execute my code with the monitor mode activated. I think that I will have to add the libs contained on /data/data/com.bcmon.bcmon/files/libs
on these of my toolchains, but I really don't know.
I read a lot papers to understand how linking works in C, but I'm probably still missing something.
I really don't know how to improve my toolchain, and I'm quite anoyed because I haven't progressed in my work for days...
Any help will be really appreciated.
Thanks a Million
Ant.

I found a solution few weeks ago.
I had linking erros.
I reserved the .apk provided by bcmon guys.
For those that want to develop using monitoring functionnalities, there is the way to do :
LD_PRELOAD=/data/data/com.bcmon.bcmon/files/libs/libfake_driver.so LD_LIBRARY_PATH=/data/data/com.bcmon.bcmon/files/libs ./yourprog
If you want to comiple your code using some of their libraries, for example pcap libraries I have done the fellowing stuffs :
1- found radiotap headers, and pcap headers on github likes websites.
2- try to cross compile with the headers
3- Correct the erros (like typedef missing ...)
4- Build your make file adding name of the libraries :
GCC={your toolchain}
FLAGS={your flags}
LIBS=libfake_driver.so \
libpacap.so.1
OBJ = {your obj}
output :
$(GCC) $(OBJ) -c {yoursrcfile) -o {output} $(FLAGS) $(LIBS)
Hope it 'll help.
Ant.

[CODES] Documented secret codes for OnePlus 5T

There was a thread noticing all the codes but they are not documented so this might be useful.
Disclaimer: I am neither resposible to accuracy of description of these codes nor any damage/loss caused by using codes improperly/recklessly.
Notice: Codes here are based on H2OS (which is the stock ROM in China rather than OxygenOS), so some of the codes may not be available in OxygenOS.
Language
*#008# : Change system language to zh-CN immediately.
*#67760044# : Change system language to en-US immediately.
Diagnostic
*#10000# : Show diagnostic results. If you have never cleared them manually or messed with diagnostic menu or functions before, this is your in-factory test result, which should be all OK.
*#800# : System logging menu.
*#808# :Don't operate functions recklessly in this menu. Diagnostic mode main menu.
*#802# : GPS test.
*#803# : Wi-Fi test.
*#804# : Mobile network searching test.
*#805# : Bluetooth test.
*#806# : Don't use this code recklessly since it would take long and may cause other issues if being stopped forcefully. Burn-in quality test.
*#807# : Auto test, which tests lot of things one by one.
*#809# : Microphone Loopback test.
*#814# : TD-SCDMA network searching test.
*#824# : WCDMA network searching test.
*#834# : LTE network searching test.
*#900# : Rear camera test.
Information
*#1234# : Show a dialog box about SoftwareVersion.
*#66# : Show IMEI and encrypted IMEI.
*#6776# : Show more about software version compared to 1234 code.
*#888# : Show motherboard PCB ID and it's QR code.
*##*37847# : Show hardware components' model and suppliers.
Engineering
*#36446337# : Don't operate functions recklessly in this menu. Engineering mode main menu.
*#268# : Don't use this code recklessly as it may damage baseband. NV param testing and calibration.
*#801# : Switches for enginners.
*##*8110# : OTA test mode switch. This switch could probably be used for blocking OTAs.
Others
*#8778# : Factory reset. You will lose all your data.
*#911# : You may lose all your data. This would send you back to first-time setup page after reboot.
*#99# : Screen always on. Enter the code again to disable.
Easter Egg
Not sure if ever presented in OxygenOS.
Game Space - Options - Fnatic Mode - Click the Fnatic icon repetitively - Type "alwaysfnatic" in the textbox poped up - New hidden wallpapers !

Thanks for sharing

Qualcomm IMS/VoLTE configuration demystify

Background
It has been a long time since the Qualcomm first launched the IMS support in its AMSS(Adavanced Mobile Subscriber Software) subsytem since CDMA platforms,which is the major function part of VoLTE implementation on MSM platforms,but even years later,almost no one talks about this topic on internet,someone noticed about the Samsung IMS configuration,but it's higher layer and not applicable to original MSM platform phones.
Why no one talked about manual VoLTE configuration in the past
There are many reasons that caused such situation,first,the Qualcomm have NDA on its platform internal scheme,many engineers hesitate to share even some simple magic value about some NV items,which results complete blackbox to the APSS Android environment developers.Second,when there is limited number of available VoLTE phones,the manual configuration methods are hide by the selfish drive-test related device sellers,and they even try to block some useful info on some websites by abuse in order to hide the top business secret.I tried to talk about such topic in past days,but all got blocked in the end.Third,the phone vendors want you just to buy new phones to support the VoLTE,and they just choose to not support the sold devices,in some time,even add barricade,this is something that are not noticed by many customers
How it worked
Most of the Qualcomm IMS feature are implement in the AMSS subsystem,which means the configuration is saved in modem's memory,in this case,the EFS on QC phones,which means you will not got the VoLTE work through some Android side prop modification,like the most talked Magisk VoEnabler.Although these props in android environment are the key switch to launch the IMS function routine,but it will not work when you just opened the switch.They are just some RILJ/RIL control flags that decide which phone to be used(the imsphone or gsmphone in RILJ code).And such prop flags may vary from vendor to vendor,it might need extra prop to be set to make sure the IMS routine are properly called.In English,the Android side is just a client of the IMS-client inside modem AMSS subsystem,all of the actual IMS procedures are all completed in the modem environment.
How is it configured
There are many tools to configure such thing right now,I guess even some private ones,but the major way to configure the IMS configuration is through QXDM,it will have a plenty of NV items and EFS configuration in IMS section,the Qualcomm have internal guide since MSM8960,which talked about how to manually set those values to make the IMS VoLTE work.however I haven't see anyone even talked about it,may due too the reasons I talked above.Obviously,such manual configuration way is user un-friendly,the QC have to find some way else.This had introduced the MBN MCFG when Chinese rolling out the VoLTE,and such methods were invented by the OPPO I guess(patents about it).MBN format had been used by QC for years,but the mcfg mbn is different at least in some way,so no current available tools to parse it on other platform except the AMSS itself.So The MCFG MBN contains IMS related configuration stuff,but how to find what it actual contains?This problem remains unsolve until I found the ORCT by linneman in 2018,a simple and buggy toolkit to parse at least some recent MSM8996 platform MBNs ,and finnally got the proper contents in sw_mcfg.mbn file,Then it's the time to manually add those NV and items file into EFS through QPST,after all that the VoLTE finally worked.
Misconception about MCFG MBN
I guess people noticed something about MBN when some guy tried to use VoLTE on Pixel 2,then they made the Magisk VoEnabler,they thought they had loaded the proper sw_mcfg.mbn by replaceing the MBNs inside vendor partition,but none of them realized that they actually falled back to the generic 3GPP configuration of MSM platform,and after MSM8996,that configuration defaultly enabled the IMS feature to work on some 3GPP lab setting networks,interestingly very coincident work on live network
Further work
Android PDC
In fact,there is an app called MBN test which is considered as bloatware for many users,none of them realized it's the important tool kit like PDC used to choose the MBN for carriers,but on phone it self,it works through the RIL_PDC related command and have the same feature like Windows PDC,but this app got misconfigured when outside the factory,and its configuration methods are highly secreted by the vendors.no one willing to answer this question.
Android IMS NV configuration
After Android Lolipop,Google had introduced the carrierconfig framework,which provided some internal methods like nvReaditem,which can actually be used to configure the IMS parameters in modem side,but it's really weired that no one had realised about this usage on whole internet.I think it will be a more generic and one-click way to DIY VoLTE even on some other platform through those API,but no one ever talked about it
Add the ORCT mirror
GitHub - vtsingaras/orct: Open Radio Calibration Toolkit, an enhanced Open Source Implementation to replace Qualcomm's QRCT
Open Radio Calibration Toolkit, an enhanced Open Source Implementation to replace Qualcomm's QRCT - GitHub - vtsingaras/orct: Open Radio Calibration Toolkit, an enhanced Open Source Implementat...
github.com

Hey I'm wondering if you know how to change the identification domain. My carrier, Bell mobility, uses "ims.bell.ca" instead of the standard "ims.mnc610.mcc302.3gppnetwork.org".
My OnePlus 8 phone uses [email protected] as it's identification and the IMS core answer with 403 Forbidden.
A pixel 5 request [email protected] and it's working.
What do I need to change in the MBN to make it use "ims.bell.ca"?

Any news about this topic?
Based on other guides I am trying to load MBN files from other smartphones rom having the same soc (Snapdragon 845), but the new MBN file is not loaded and I see no error.

[info] Q18 (DZ09 clone?) Dialer codes plus other info tidbits

Q18 Chinese Smartwatch (Actual clone of model is Atm unknown assumed DZ09) see pic for style reference there maybe others with same internals.
Chipset/CPU: MTK ARM MT6260MA
Version Line(might not be real version):
MX6XM-COB-Q18-9340-WKD-6113-HYBR-V06.740-20200910
MRE VERSION: 3100
MRE INFO :
Size: 472336 (not sure if it's mb or what doesn't say)
[SUPPORT MODULES]:
base
resmgr
comm
sm
res
c
ch
draw
gfxold
image
ime
ini
mul
xml
aud
camera
cell
pb
sim
sms
status
tel
timer
launch
Dialer Codes will label as I get info
*#66*# - (I assume what *#00000000# on DZ09 does)
*#3646633# - Device, Misc- (MRE and Memory dump)listed
*#1234# A2DP Mode toggle (not sure what it means)
*#8375# same as DZ09
*#87# same as DZ09
*#06# same as DZ09
------------------
Flashtool does recognize this for ROM dumping however have not found a correct scatter and readback addresses.