Develop Bugs

bad_pool_header crash with WM5 upgrade

I upgraded my XDA Exec with the new ROM 1.30.162 WWE and Activesync 4.1 but each time I sync, I get a "bad_pool_header" error on a blue background which crashes my machine.
I installed Activesync 4.1 on another laptop to check if this problem was due to drivers etc on my main laptop, and discovered that the device syncs with no problems. There is, therefore, a conflict between the new Activesync 4.1 or the new ROM, and something on my main laptop.
Has anyone come across this problem?
Thanks

The problem is definitely on your PC. Reinstall motherboard drivers, reflash bios, remove antivirus, reinstall windows, etc.

Thanks - pretty drastic...!
Is there a short cut? ie reinstalling drivers one by one? If so, which are likely to be the main culprits? Motherboard? Broadband modem? etc
The error code after reboot of the laptop is:
BC code 19 BCP1:00000020 BCP2: 89A76000 BCP3: 89A766C0 BCP4: 0AD8000
OS Ver 5_1_2600 SP: 2_0 Product 256_1
\WER22c7.dir00\Mini052506-06.dmp
\WER22c7.dir00\sysdata.xml
Does this reveal anything that could explain which driver?
Thanks

10860 said:
Does this reveal anything that could explain which driver?
Click to expand...
Click to collapse
no.
You should create a complete crash dump, and use microsoft debugging tools to find faulting driver. Or better reinstall windows.

I looked at the minidump file and used MS debugger, the readout is below. I am not sure if I did the debugging ok, or how to interpret it. Anything useful in the readout?
Thanks
Loading Dump File [C:\Mini052406-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available
Symbol search path is: C:\WINDOWS\Symbols
Executable search path is:
Unable to load image ntoskrnl.exe, Win32 error 2
*** WARNING: Unable to verify timestamp for ntoskrnl.exe
Windows XP Kernel Version 2600 (Service Pack 2) UP Free x86 compatible
Product: WinNt, suite: TerminalServer SingleUserTS
Kernel base = 0x804d7000 PsLoadedModuleList = 0x8055a420
Debug session time: Wed May 24 20:25:34.038 2006 (GMT+1)
System Uptime: 0 days 0:52:32.633
Unable to load image ntoskrnl.exe, Win32 error 2
*** WARNING: Unable to verify timestamp for ntoskrnl.exe
Loading Kernel Symbols
.......................................................................................................................................................................................................
Loading User Symbols
Loading unloaded module list
.................................
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
Use !analyze -v to get detailed debugging information.
BugCheck 19, {20, 88187000, 881876c0, ad80000}
Probably caused by : Unknown_Image ( nt!KeBugCheck2+4d4 )
Followup: MachineOwner
---------
kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
BAD_POOL_HEADER (19)
The pool is already corrupt at the time of the current request.
This may or may not be due to the caller.
The internal pool links must be walked to figure out a possible cause of
the problem, and then special pool applied to the suspect tags or the driver
verifier to a suspect driver.
Arguments:
Arg1: 00000020, a pool block header size is corrupt.
Arg2: 88187000, The pool entry we were looking for within the page.
Arg3: 881876c0, The next pool entry.
Arg4: 0ad80000, (reserved)
Debugging Details:
------------------
BUGCHECK_STR: 0x19_20
POOL_ADDRESS: 88187000
CUSTOMER_CRASH_COUNT: 1
DEFAULT_BUCKET_ID: DRIVER_FAULT
LAST_CONTROL_TRANSFER: from 00000000 to 8053331e
STACK_TEXT:
f78cab74 00000000 00000000 00000000 00000000 nt!KeBugCheck2+0x4d4
STACK_COMMAND: kb
FOLLOWUP_IP:
nt!KeBugCheck2+4d4
8053331e ?? ???
FAULTING_SOURCE_CODE:
FOLLOWUP_NAME: MachineOwner
SYMBOL_NAME: nt!KeBugCheck2+4d4
IMAGE_NAME: Unknown_Image
DEBUG_FLR_IMAGE_TIMESTAMP: 0
BUCKET_ID: ZEROED_STACK
MODULE_NAME: Unknown_Module
Followup: MachineOwner
---------

Nothing useful, minidump does not have enough information
It is very difficult to debug pool corruptions.

[UTIL] QC Mobile Analysis Tool - Universal tool for QC mobile analysis (and HTC too)

QMAT - QC Mobile Analysis Tool
What is it ?
It is a development and debugging tool for Qualcomm mobiles - the only tool you'll ever need for research and development.
Who may need it ?
Mobile engineers / reverse engineers and cryptoanalysts
Crypto Functions :
- Calculate CRC-30, CRC-32, SHA1, SHA2 (SHA224 + SHA256), MD4 and MD5 of any file
- Bruteforce bytes to fit CRC-30 needed when qcsblhd_cfgdata.mbn was edited
- Decrypt and Encrypt any RSA-Message, including ASN-1 / SHA Signatures. (you can add publickeys to publickeys.xml)
- Generate RSA Private Key and create .pvk files
- Check firmware signature given Modulus and Exponent (for HTC and BQS mobiles)
- Extract information from .pvk files
- Search for algorithms in binary files (find cryptomethods + signatures) CRC8, CRC16, CRC32, MD4, MD5, SHARK, HAVAL, GZIP, ZIP, SHA1, ... and much more (you can add cryptosignatures to crypto.xml)
JTAG Interface :
(soon via Segger J-Link)
Functions for QC mobiles :
1. Load binary files for :
Extraction of certificates
Extraction of BMPs,GIFs,PNGs, JPGs
2. Load Partition File to get overview about NAND/NOR structure
3. Send any String to a COM/USB Port and backup all your SMS !
4. Make usage of QCs Diag USB/COM Port Interface
(Useful for any QC mobile in the world)
Standard Features :
- Send standard diag commands or any hexadecimal command you want (database included)
- Read out all NVItems (range given)
(all that exist, more than QPST normally extracts)
- Backup and Restore all NVItems
- Read out and Dump Firmware in Memory (SRam)
- Read out complete EFS
- Switch to FTM Mode (or anything else you want)
- Get infos about phone, codes ..... etc ..... a lot more functions
- Generate SimSecure Command to write to SimSecure using given file (may brick your phone when used without knowledge)
- Full Feature EFS Browser
Bootloader / DownloadMode Features :
- Load any file to mobile at any address and execute (bootloader f.e.)
- Read out complete NAND Memory using bootloader (range given) with included MSM6250/A bootloader or any given bootloader
Usage : Take out battery, put in battery, press ON # to enter emergency mode, Execute Loader
or (with SL91,SF71 f.e.) enable FTM mode, Execute Loader
- Use any Download Mode or Bootloader Command to experiment
- Read application memory of newer Diag Ver 6 in Download Mode
- Show complete infos about used NAND after loading of Bootloader
Flasher Features :
Flash any QC mobile (OBL Multiboot) with given bootloader
- Flash PBL (dangerous), QCSBL, QCSBL Header and Config Bits, Partition, OEMSBL, OEMSBL Header, AMSS, AMSS Header and EFS
Functions for BQS only :
1. Load AMSS to extract files or useful infos
(EF81, E81C, EF91, SXG75, EF82, SF71, SL91 or similiar ones)
Features :
Extract Infos from AMSS : USBID, Product.Nr., SVN, SwBuild, Mobiletype
Extract internal filesystem (mif,bar,sig etc. files)
Extract AMSS signature bytes (if production key)
Show all file references used by mobile
2. Check Firmware validity (signature)
3. Sim_Secure extraction/decryption (non-public)
4. Master-/Usercode/Unlock extraction and direct unlock (non-public)
Functions for HTC only :
1. Check validity of HTC firmware (signature check)
2. Cut out signatures from .nbh file
3. Split radio.nb into qualcomm files for analysis
4. Find HTC Public keys using Cryptosearch
5. Generate Security passwords (SPL + radio) for newer HTC
6. Generate NBH Files (you can add any device into devlist.xml)
7. Dump Files from NBH (you can add any type into nbhtype.xml)
8. Fix radio.nb checksum
9. Generic Bootloader / AT Command interface with logging functions
Functions for Network Engineers
Network Calculators :
TDMA (GSM/UMTS) :
--------------------
IMEI
GSM A5-1
GSM A5-2
GSM A5-3
3G ECSD
GEA3 - GPRS
3G SNOW
3G UEA2
3G UIA2
GSM A3/A8 COMP128 V1
GSM A3/A8 COMP128 V2
GSM A3/A8 COMP128 V3
3G Milenage
3G Milenage Resync
CDMA :
-------
CAVE
CAVE Authentication
CAVE CMEA
CAVE EMEA
CAVE EMEA_NF
CAVE Wireless Residential Extension
CAVE Datakey / Look Up Table / Mask
CAVE DTC / DCCH
CAVE KSG
CAVE Long Block
CAVE Short Block
CAVE Enhanced Message
CAVE Enhanced Voice Privacy
CAVE Enhanced Data Mask
and much more ....
Planned in future :
1. Bugfixes
2. EFS Restore to Zip File
3. QC Jtag interface using Segger J-Link ARM
4. LNBS HTC support to replace MTTY 5. Tooltips showing real addresses in graphical window
5. CDMA Write functions
6. Read out / Write back Addressbook
7. Restore backupped SMS to phone
8. much much more
NO UNLOCKING ! PLEASE DO NOT REQUEST. THIS PROJECT IS FOR EDUCATIONAL PURPOSES ONLY, NOT TO HARM COMPANIES FOR THEIR EFFORTS.
What we need :
- Any contribution to the project is welcome.
- Donations for new hardware and software for further development of this tool.
Link to the project files :
------------------------
Version 4.21 (Major Release) Stable
QMAT Homepage
Cya and keep on reversing,
Viper BJK
==> Donate via PayPal <==

Thanks, that's very useful. Keep up the good work!

Update : Version 3.51
---------------------
- Crypto Bugfixes solved
- Com Port Bugfixes solved
Added QMAT 3.51 manual to download page
Cya,
Viper BJK

Update : 3.52
-------------
What's new ?
1. Added SHA2 crypto search algos (SHA224 and SHA256)
2. Added SHA2 (SHA224 and SHA256) and MD5 hash generation
3. Some Bugfixes
4. HTC Security Generator for all newer HTC models (reverse genned) :
SPL and radio (works with Diamond !!)
Note : For Copy'n'Paste .. do not use MTTY, but Putty !!!
See new manual for further details ....
Enjoy !
Cya,
Viper BJK

nice one..!
Thanks

New version : 3.54
------------------
Updates :
- Added SHA-256 from HTC
- Improved RSA Decryption ... now better readable
- Added function to reverse byte strings for RSA Decryption
- Bugfixes
Cya,
Viper BJK
Update:
Small SHA2 bugfix

Good information. thanks

New version : 3.6
------------------
Updates :
- Added NBH Generator Tool
=> you can add any device to devlist.xml
=> you can sign rom files either using pvk file or using dummy signature
- Added NBH Dump Tool
=> Remove Signatures function or
=> Extract any part you wish or
=> Extract all files from nbh
=> Show infos about nbh file
=> Add new deviceparts (typeinfo) to nbhtype.xml
- Added publickeys as XML
=> add any public key to publickeys.xml
- Added tool to fix radio.nb checksum
Bugfixes :
- Fixed NBH Signature extraction
- Fixed RSA Function
For the design of NBH Tools, I was strictly influenced by Olipro's work
Cya,
Viper BJK

This is a real work....!!!!
thx for this great program

Update : 3.61
-------------
What is new ?
-------------
After being fed up with buggy Putty + Mtty, I implemented
HTC Bootloader AT Command Interface. (see picture below)
Also I was missing a good copy paste function for my hex editor.
Why wasn't it working before ?
=> HTC Bootloader isn't able to take more than one byte sent.
So :
- Implemented HTC Bootloader AT Command Tool (works also for other ones)
- Several severe bugfixes (like Display fixes)
- Fixed RSA Decryption bug (Pubkeys loaded incorrectly from xml)
What will be next ?
------------------
As I'm a Vista user (sic!) I also use the really old Activesync driver.
But this one lacks of high-speed transfer, so I'm going to implement a solution
for newer HTC phones and newer OS, as Micros*** changed to WinUSB Interface (which is better imho than virtual com port).
So :
- Will implement REAL Usb interface, no virtual serial port use
Cya,
Viper BJK

Small update :
--------------
WinUSB is now fully implemented !
It really works like a charm, much faster than putty or mtty, and really stable.
mb command runs like hell
Even better, you can break off USB connection and continue seconds after reading out bytes .... this is big news
So ... Vista Users, use new WMDC drivers, forget about old activesync one.
And as for the XP users, download WinUSB runtimes now
Bad to say, but of course WinUSB won't work with old activesync.
I'm going to implement now a logfunction for binary data, so it can be used with pdump. Once I understand how "autodownload" works, I will implement it also so that my tool can replace mtty.
If there are any wishes what should be implemented, say so
Of course I will open source for WinUSB connection for those who want to port their tools.
Cya,
Viper BJK

Update 3.70
------------
What is new ?
--------------
- Big bugfixes
- Added new WinUSB and Serial Interface for HTC Bootloader (with binary log AND pdump support)
- Added partition tool to show MORE info
- Complete new Serial interface
- Added feature to use different bootloader commands for nand reading
- Added feature to read different sizes for nand reading
- Fixed radio.nb extraction
- Fixed radio.nb checksum calculation
- etc. ..... see Manual 3.7 for complete introduction
Cya,
Viper BJK

Update 3.71
------------
Sorry for that one ... WinUSB didn't work due to memory leak.
Fixed ....
Cya,
Viper BJK

Update 3.72
------------
What's new ?
-------------
- Included HTC Security Decoder in AT Command Interface
(easier to use)
- Fixed USB / SER Problems
- HTCE/HTCS were not displayed correctly
- Fixed Display Scroll Problems in AT Command Interface
Enjoy !
Cya,
Viper BJK

Update 3.73 *Speed release !*
------------
As someone really needed this func, the following was added :
- htc at command interface bytelog can now be any filename (select log file)
- You can send any data to encapsulate, for example you want to send bytes 0x00 0x01 0x02 and 0x03 .... enter "00010203", press encap button and
bytes will be send using correct HTC "HTCS....HTCE" encap
Cya,
Viper BJK

- removed -

Update 3.74 *Special Edition for CMonex*
------------------------------------------
News :
- Added function to upload files in encapsulated header
- Bugfixes
Cya,
Viper BJK

News :
-------
3.74 has a lot of bugs in it, so sorry for that.
Download of my tool is atm not possible, I'm looking for another hoster.
New version 3.75 will be soon out, adding several bugfixes and nvitems support for HTC. Also, beginning with 3.75, my software will be shareware.
People that already donated 15 EUR will of course get source and registration key as usual for free.
Expect news soon.
Cya,
Viper BJK

ThanX Alot for this GREAT Tool !
Keep up your Good Work !

Is it possible to upload this tool on the board ? I have a forbidden acces to the google code page ... :'(

oldest Firmware maybe mandatory for Research - XXJB6

For investigation I'm searching for oldest Firmware...
At the moment I found "only".
S8500XXJB6.rar
Differences:
1.
Few adresses not same in Multiloader
2.
Not running on my handset... accept amss.bin
3.
TriX can't extract anything...
PSAS can't decrypt apps_compressed.bin
4.
Bootloader different
Best Regards

older firmware, like S8500XXJB6 is a bit different (is much closer in structure to S8000)
ad. 2, i assume you have newer bootloader in phone (it won't accept older one)
ad. 3, shp, csc file signature is a bit different (will be fixed soon). FS file is just fat16 image (TriX support fat images via FATe plugin, i have no idea fat images was used before, i will add FATe plugin in next build)
ad. 4, if someone still has that firmware in phone is very luky guy. I can bet with jet android port can be ported to it with any problem - JB6 bootloader is not crypted.

5.
Rsrc2_S8500(Low).rc2 works also in JI5 for instance...
Different Boot Pics... maybe this helps to identify location of each Pic.
Battery...
Samsung Logo...
.
.
.
Maybe we find out, which Format... maybe also QMG.
Best Regards

you can already extract rc2 files
use the same program that is used for older samsungs
this one if I'm not wrong
http://code.google.com/p/samsung-firmware-tools/

I've used Tool WinImage for extraction of *.FFS... renamed into *.img
Usefull also for FFS of other bada handsets like:
S5250
S5330
S5750
S7230
In CSC of S8500XXJB6 I navigate via 005C00 to see where folder/file is.
Best Regards

Still problem.
That I can't bypass Bootloader Security...
Not with Multiloader nor with JTAG...
My knowledge how Boot is correct written + activated... = 0
I saw some other Firmware from other models... it seems IMRC is still used...
Maybe someone found Algo or Tool to decode RC1.
Thanx.
Best Regards

Blub...
XXJB6 unfinished mission...
2 new Firmware good for research.
XXJEB as bada 1.x Firmware... nearly all Certs removeable...
Only Integrity check for *.so files left.
For bada 2.x
XPKG5 very interesting...
Only bad, I can't find where these 2 last Certs are stored?
Code:
SamsungSBRootCA.cer
Samsung_RootCA.crt
Best Regards

New attempt with JTAG... but again failed... :crying:
Magic is now CMM Script...
BUT I have only ELF from XXJEB...
Maybe this is the reason why Multiloader not flash XXJB6 Bootloader...
Now I could learn more about CMM...
To flash correct file to correct address...
Or maybe way to extract RC1 ... because old IMRC Algo...
Not sure if maybe broken for other Samsung handsets...
Best REgards

Hmm, I can see S8000 Jet use for RC1 also IMRC...
Maybe possible to flash RC1 XXJB6 to S8000, then copy content from handset...
Best Regards

Please help.
I am searching for friendly S8000 Jet User.
Can someone confirm working Command:
Code:
FmSecureMode off
And I wish content of S8000 folder System please.
See here what I mean:
http://forum.xda-developers.com/showpost.php?p=12436452&postcount=1
Thanx in advance.
Best Regards

http://forum.xda-developers.com/showpost.php?p=34508619&postcount=132
Now I have own S8000 Jet...
First try to flash RC1 from XXJB6 fail...
NAK_invalid_len
Need more knowledge about S8000...
Best Regards
Edit 1.
Maybe no chance... I have forgotten to check size...
Rsrc_S8000_Open_Benelux_OCE.rc1 is 80 MB
Rsrc_S8500_Open_Europe_Common.rc1 is 100 MB
Maybe S8000 not reserved 100 MB for RC1... :crying:
Edit 2.
I have removed 20 MB...
S8000 Jet start with reduced XXJB6 RC1
Now I copy System folder...
Maybe few files corrupted and over 20 MB missing...
But better then nothing. :victory:

http://forum.xda-developers.com/showpost.php?p=34518982&postcount=34
Okay, second attempt successfully read few files from XXJB2 RC1...
And I found limit for RC1 in S8000...
Code:
> FLASH_RSRC1_SIZE : [B]0X04B00000[/B]
> FLASH_RSRC1_START_ADDR : 0X03700000
> FLASH_RSRC1_END_ADDR : 0X08200000
So ""80 MB"" ...
Will check older Firmware, maybe more place in other Versions reserved...
Best Regards

http://www.mediafire.com/?um7dr5ufti7h0dx
Here is folder with RBMs from XXJB6.
Also not all are visible with Wave_Remaker...
Few are funny and interessting...
Later I will upload more... but again.
During small reservation of S8000 I was only able to flash 75 MB of 100 MB from RC1.
Maybe also few files are corrupt... Not checked all.
Best Regards

I'm trying to collect few other Firmware from other Samsung devices...
U700 IMRC seems other algo maybe...
Bluescreen ... on S8000
FmMountVolume
Fm_FS_LFS
FM_PARTITION_LFS_C
Next try is M8910 RC1...
Btw. I have forgotten XXJC5 is also IMRC and bigger then XXJB6...
Later more...
Best Regards
Edit 1.
M8910 RC1 without problems work on S8000...
Remember only end.bin last 1024 Byte have to be modified for correct addresses...
Edit 2.
S5620 RC1 tested...
It seems more compatible then U700 RC1 but also loop...
Maybe if I can disable Animation Power ON then chance to check next Error...

New Year... New attempt
Bootfiles Mixed with XXJEB...
boot_loader.mbn from XXJEB
dbl.mbn from XXJB6
Multiloader can flash this combination and it seems XXJEB then work...
I hope if I manage to understand how to use Binary instead ELF in CMM Script, then maybe I am 1 day able to flash Boot from XXJB6...
Best Regards

IMRC related... there are more Samsung devices with IMRC compressed RC1...
Code:
RC1(IMRC) compatible size
S8000 x 75/80
S8500 XXJB6 x 100+
M8910 x 75/?
S5620 -
U700 -
F480 -
S5510 -
S7350 -
G800
U900
I am not sure if different IMRC Versions... because mandatory few RBM files needed in System folder...
Best Regards
Edit 1.
Sometimes I can see Power ONOFF Animation...
Edit 2.
It seems IMRC different Versions... see first 8 Byte...
F480 for instance compared with S8500...
I think at 0x14 4 Bytes for DEcompressed size stored... Little Endian

yes, the header is different.
index - also. but it is clear.
the compression algorithm - still a mystery
PHP:
//magick //always1 //index_type //size??? //count //array of tail size or offset
G80LXEIE1 0x43524D49 0x00001000 0x0000000B 0x00000006 0x02464A38 0x00002466 0x00000000 0x00000338 0x000004A0 0x000007C8 0x00000924 0x00000BA4 0x00000CFC 0x00000F94 0x000010E4
U70BXEIF1 0x43524D49 0x00001000 0x0000000B 0x00000006 0x01E5BB48 0x00001E5D 0x00000000 0x00000338 0x00000498 0x00000774 0x000008B8 0x00000BC4 0x00000D28 0x00000EF8 0x00001028
F480XEHE1 0x43524D49 0x00001000 0x0000000C 0x00000006 0x01A55024 0x00001A56 0x00000170 0x0000030F 0x0000013A 0x000002F6 0x00000147 0x000002B6 0x000000E4 0x00000295 0x00000144
F48FXEID1 0x43524D49 0x00001000 0x0000000C 0x00000006 0x01EF4A6C 0x00001EF5 0x0000016C 0x000002E7 0x0000014B 0x00000335 0x0000012D 0x000002A1 0x000000E0 0x00000277 0x0000013F
S5510XEIJ1 0x43524D49 0x02000400 0x00001000 0x0000000C 0x00000006 0x01CC581C 0x00001CC6 0x00000165 0x00000358 0x000000AE 0x00000277 0x000000BD 0x00000284 0x0000015D 0x00000327 0x000000EC
S735EXEII2 0x43524D49 0x02000400 0x00001000 0x0000000C 0x00000006 0x02A74E80 0x00002A75 0x00000147 0x0000033A 0x000000D4 0x000002A0 0x000000B5 0x0000027E 0x00000125 0x00000315 0x00000111
S8500XXJB6 0x43524D49 0x02000400 0x00001000 0x0000000C 0x00000006 0x09BF64A0 0x00009BF7 0x00000141 0x000002DC 0x00000116 0x00000280 0x0000014B 0x000002FB 0x00000155 0x000002D4 0x00000124
U90UXEIE3 0x43524D49 0x00001000 0x0000000C 0x00000006 0x032BAF08 0x000032BB 0x00000168 0x0000030B 0x0000012F 0x000002C3 0x0000013F 0x000002D0 0x00000103 0x00000272 0x000000D0

I don't understand if RC1 is decompressed by Bootloader or by apps_compressed.bin...
QMD in Header is in later Firmware from S8500...
Short tested...
I can change this in RC1...
QAB
S8500 starts normal...
If I try to change all 3 letters... then short Bluescreen... But I can't see Error message fast enough... maybe later...
I have changed into 123 instead QMD...
Will check again... Maybe I can capture Bluescreen...
Video or something else...
Later I will try this with S800 and IMRC textstring...
I want to identify if Boot or apps_c task to decompress RC1...
Best Regards
Edit 1.
I hope Pic is readable... Tested with Debug Level high and on XXJEB S8500...
Looks like something like this...
Code:
QuramMduceRFlashInitM((void*)pFotaRsrcCompHeader[QURAM_RSRC_BIN_TYPE_LFS]
Found in apps_compressed.bin...
Hmmmmmmmmmmmm. In theory it seems I don't need Bootloader from XXJB6...
BUT... damn apps_compressed.bin is also secured by something ugly...
Last 1024 Byte... aka end.bin...
Anyway... will now check again IMRC Header in S8000...
Maybe here also possible to force Bluescreen in Debug Level High...
Best Regards

If I destroy IMRC Header on S8000... XPJA1... Debug Mid...
Later I will try to catch all 5 Bluescreens..
Here 1/5...
Best Regards

Code:
RC1(IMRC) compatible size
S8000 x 75/80
S8500 XXJB6 x 100+
M8910 x 75/?
S5620 -
U700 -
F480 -
S5510 -
S7350 -
G800 -
U900
S5600 -
B5310 -
Found few more devices...
It seems - not ever means incompatible... I can see sometimes Power ONOFF Animation... smaller Resolution then 480 x 800... So maybe reason is smaller *.rbm files force to Reboot... Will check "later" with Debug Mid...
Best Regards

Security related Questions

SecretKey.key
Any idea what this is for?
Searched little bit through folder Security...
Found in S8500XPKJ1.
Best Regards

For quick insight:
Main function is SpkiDispatch , it does create this file by calling SpkiSaveMasterSecretKey, together with that key it does create directories
"/Security/Log/"
"/Security/Log/Cert/"
"/Security/CM"
SpkiSaveMasterSecretKey does use functions
SecFrameGetIMEI
SpkiBase64Decode
SecCrDecodeRSAPublicKeyEx
Whole "Spki" functions family seems to be related with OS certificate manager. And yeah, looks like it is based on IMEI, or does include IMEI itself.
//edit:
Oh yes, string which is hardcoded into APPS and is being decoded by Base64 during runtime (probably kind of init state of the key) is
MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDKyA2m2/PTRbsv9Y+39R6wroIniRv3nAUcOPH6dhg/9+2sCoWk0BgDtmfNMtUpueEzAr1OmAtxIfxt+gcaaFGDTr2NiY4ML9NhIv0frmlEsE8CLZFcMLYnCaeo7IMpDhnkUJA/aFhm42hmHM//e9sW2zOeN/oFrZ6wH7BEJmVEpQIDAQAB
Click to expand...
Click to collapse

from the looks of that string - I think you're looking at ... ahem wait for it ... a secret key -- or perhaps one half of a public/private key pair. Something that AES128 would be perfect for... good luck cracking that one.

Compared between S8500 and S8530... both on KJ1:
Code:
535730310093C300064D4F42494C45C5000431303234C60080
Something human readable like this:
Code:
SW01 MOBILEÅ 1024
So first 25 Bytes are for header...
Then 128 Bytes...
Hmmm... 128 Bytes could be RSA 1024 encrypted...
Best Regards

Factory Production Mode
This seems interesting... for me...
Tested on XXJEB...
If I play with Developer Commands... for instance:
Code:
> *> cmd="[B]CheckFPM[/B]"
> DevGetHomeDLFlag : Address(0x1dcc0000) flag(0xffffffff)
> RbmCHCheckHomeDLFlag : FLAG value=0x8,result=0
> *> return value = -1 (0xFFFFFFFF)
Code:
> *> cmd="[B]EnableFPM[/B]"
> DevGetHomeDLFlag : Address(0x1dcc0000) flag(0xffffffff)
> DevSetHomeDLFlag : Address(0x1dcc0000) flag(0x0000fff7)
> DevGetHomeDLFlag : Address(0x1dcc0000) flag(0x0000fff7)
> RbmCHEnableHomeDLFlag : FLAG value=0xfff7,result=1
> *> return value = 1 (0x00000001)
and...
Result is, after next Boot Wave starts with this funny Screen blue, then green... known by wrong key combination...
If I have changed to Qualcomm before... I can also write NV items via QPST...
Maybe here are more funny Flags possible... Check in JTAG dump at 0x1DCC0000...
Best Regards

I have found reason, how Wave checks "valid" apps_compressed.bin... also Boot...
Multiloader or every Flashing action writes own 512 Byte Info Block...
You can find them in 512 MB Full dump... from JTAG or from Ram Dump eXtractor:
http://forum.xda-developers.com/showpost.php?p=39658811&postcount=23
Search for this HEX value...
Code:
3412CDAB02000000
Now you can see your PC name... and your Country too...
your own IP address is also stored...
The other data are from last 1024 Bytes from boot_loader.mbn and apps_compressed.bin... parts of it... later more...
Sometimes I can see this... no idea yet why... or what:
Code:
Init Case 2
or
Code:
C#O#D#E Set
Hmmm... if I see this about Code... searching for and I find this in Boot...
Code:
Samsung:UNLOCK-KEY:/Security/Disabled
Fixed one for Samsung 3G platform. This string should be long ecnough maximum length is 128 bytes
[B]A#D#D#R[/B] Set C#O#D#E Set
Hmmm, will try later...
Anyway, with this I have solved my BIG problem after M210S Firmware...
For now only with JTAG possible, but maybe later other solution... for instance via FOTA...
Best Regards

Code:
gHostInfo.pComputerName =
gHostInfo.pIP =
gHostInfo.pLocation = Germany
gHostInfo.pToolVer =
gHostInfo.uDatePC =
Nand Read ECC count 0, Retry total count 0
=================================
BootDebugBuffNandWrite
=================================
Taken from S8000 Jet dump...
Here more clear what Multiloader writes from your private data...
Best Regards

I'm trying to remove this from MultiLoader V5.67.exe...
Found in .exe
Code:
GetLocaleInfo
GetComputerName
Leads to kernel32.dll ...
Maybe I can find something else...
GetDateFormat crashes Multiloader...
Also
GetCalendarInfoA
To change into Set... I think its dangerous not to kill my Windows...
Best Regards
Edit 1.
GetComputerNameW for Unicode instead GetComputerNameA
Now Multiloader only writes first Character of your Computername... :angel:

Back to the Info Block with 512 Byte....
With Command PrtSecBoot
Code:
> SecBoot : slot num(2), mass production(0), verSecurity(2), slot age(3)
> SecBoot : invalid binary key detected
> SecBoot : slot age(3) Usb Version("S8530+XX+LA1"), usb age(1), Usb Creation time stamp "42/01/05 10:05"
> SecBoot : Code Version(""), code age(1), Code Creation time stamp ""
> SecBoot : Code Download device time("00/01/01 00:00:GMT"), host PC time("43/06/06 15:23:GMT")
> SecBoot : Used Downloading Tool is FastMultiLoader 0 5.6.7
> SecBoot : Download hostname("[COLOR="Red"][B]yourPCname[/B][/COLOR]"), location("Germany"), ip(1x3.1x3.9.xx)
> SecBoot : SysInfo change device time("00/01/01 00:00:GMT"), host PC time("00/01/01 00:00:GMT"), tool ver(""), change Method(0), age(0)
In this Info Block are stored 2 RSA 512 Signatures from Boot and 1 from apps_compressed.bin... from apps_c the second RSA 512 Sig... see here:
http://forum.xda-developers.com/showpost.php?p=38088383&postcount=68
I was able to try few things...
I can manipulate
verSecurity(2), slot age(3)
Click to expand...
Click to collapse
But tried to find
mass production(0)
Click to expand...
Click to collapse
tool ver("")
Click to expand...
Click to collapse
Here I can see Init Case 2... so this should be position for ... also:
C#O#D#E Set
I think this is set, if Unlock via Code... in theory...
A#D#D#R
No idea yet...
Maybe in this Info Block it is possible to complete disable Security check...
Best Regards

Little progress...
I am able to erase/overwrite address in 512 MB OneNAND manually via sending Commands...
http://forum.xda-developers.com/showpost.php?p=42919458&postcount=31
For now only 2000+ Bytes in FOTA area tested...
Code:
7E02EE[B]00005009[/B]8000...
7E00DD[B]00005009[/B]0008...
0x9500000 from XXLA1 S8530...
Later I hope I can erase this damn Info Block to repair my S8530 with M210S Firmware... without JTAG...
Best Regards

1.
How to find IMEI in JTAG dump?
1.1
Where is EFS address ...
2.
Contains sysinfo IMEI ?
2.1
How to find sysinfo in JTAG dump?
bada 1.x if Wave alive... in Security folder...
Then it is possible to search for in dump...
But it seems not on every Firmware on same position...
sysinfo is 6560 Bytes (19A0 HEX ) ...
Will do few tests with XXJL2... maybe laaaaaater I can identify IMEI and/or sysinfo in strange unkown JTAG dumps...
Best Regards
Edit 1.
For study maybe this:
S8500_Full512MB_IMEI_38178104728484_NandEC50_Alive
Test 1.
Search by text + Unicode... (if IMEI is correct in name...)
14 Digits instead 15...
Test 2.
Converting into NV item 550 Format...
083A...
Edit 2.
Maybe little progress... to find sysinfo in dump...
Found Header before... but there is no unique Header... with Joker between 3000 or 0 hits...
Different positions maybe "randomly" or apps_compressed Version specific...
To be sure I'm now downloading XXJF5 to compare with dump...

Strange...
I have remove sysinfo from my own JTAG dump, written back dump...
sysinfo restored or rebuild or copied from somewhere else?
Because 1:1 same...
Next attempt, to remove "Info Block" from 1FFC5000...
This is so strange...
Best Regards

http://forum.xda-developers.com/showpost.php?p=43436279&postcount=6
I'm using now this as template...
Changed only at 1FFC5000...
Then flash complete XXJL2 for compare...
Result is working S8500...
sysinfo is generated different...
And Imiation_IMEI.dat file is different...
Now will try to check few "INFO Blocks"... and compare results...
if sysinfo and/or Imiation_IMEI.dat will be different..
Best Regards

1.
How to find IMEI in JTAG dump?
1.1
Where is EFS address ...
Click to expand...
Click to collapse
Sometimes my brain works slooow...
1.
IMEI is stored in Format used in QC handsets 15 + years...
Near "MP" ... Hardwareversion...
1.1
Header of EFS seems:
Code:
ABEFCDAB
So address is:
0x1E700000
In older Firmware where Hardwareversion is PV... instead MP 2.000 or MP 1.000
Here I will check later again with open eyes... to find IMEI.
For now I will do some tests with replace ... to fully start foreign JTAG dumps to learn more about sysinfo...
Best Regards

Tested with S8500 and S8530 JTAG dumps... (on S8500)...
Attached PFS contain sysinfo and Imiation_IMEI.dat...
This force apps_compressed.bin to start with IM.. not active...
If NAND/Header Info at 0x1FFC5000 will be removed/deleted...
With RIFF JTAG for instance erase 0x1FFC 0000 to end...
For repair and educational purpose... only.
How to decrypt sysinfo?
Whole file ?
Parts of it ?
Best Regards

Little progress...
https://code.google.com/p/badadroid/source/browse/trunk/FOTA
100 years later I am able to compile these examples...
Easy under Windows 7 tested with FASMARM:
http://forum.xda-developers.com/showpost.php?p=46788023&postcount=35
I have tried with XXJEE Boot... because I need bada 1 for find sysinfo for my studies...
Very interesting.
In syssec.uniqueKey.bin I have found now S/N ...
S/N is also on Label under battery... before Samsung killed Service via Kies. It was also helpfull to download Firmware...
I was ever wondering, why I am not able to find S/N...
Anyway. These FOTA examples helps me to increase my little brain.
For now tested only these:
Code:
[B]dump[/B]_netlock_info.fota
[B]dump[/B]_unique_keys.fota
nv_[B]dump[/B].fota
Next will be write_netlock_info.ASM...
Maybe this is what I think...
Yes, I know about FLOCK. But I need this for my JTAG Fullflash journey ... and for my little brain to understand how this work...
Btw.
I have no device here with SIM or Netlock...
To look into decrypted sysinfo and see the SHA1 Hashes is also possible via these FOTAs...
Thanx.
Best Regards

Few tests later...
It seems I have to play with DEcrypted sysinfo...
http://forum.xda-developers.com/showpost.php?p=47851350&postcount=49
First test failed with write_netlock_info.ASM before...
I have used DEcrypted Version, but nothing happens...
Maybe again my fault... anyway... tiny little step forward.
1 Goal is to identify sysinfo in JTAG dump... but here I need encrypted sysinfo...
Best Regards

Aha...
The reason is not only IMEI, because normally you can find IMEI in JTAG dump, but it seems Wave can not find anymore correct sysinfo... if fulldump from other Wave is flashed via JTAG.
http://forum.xda-developers.com/showpost.php?p=47851350&postcount=49
Result is working handset without IMEI... but this no problem...
Will check if now S/N is my or also gone with the other FOTAs...
But now I can flash 512 MB Fulldump WITHOUT modification of this file...
Then restore/rebuild sysinfo via bterm + correct FOTA...
Later more.
Best Regards

"Strange"...
sysinfo contain more then 1 or 2 SHA1 Hashes...
The others looks like "not available/not active" or something...
I have no handset with Lock...
I have only compared few DEcrypted sysinfo...
Simple copy and Paste not activate the Locks...
Later more...
Best Regards

Interesting...
Unique Key known from Header Info...
Stored in 512 MB OneNAND...
Is written into MBR (512 Byte) of moviNAND...
http://forum.xda-developers.com/showpost.php?p=49989727&postcount=68
If OneNAND is full erased, by JTAG RIFF for instance... Then text instead number:
Code:
PRODUCTCODEINVALID
Hmmmm, maybe this helps me later to restore sysinfo from JTAG dumps...
Best Regards

Qualcomm-based devices 9006/9008 qdl mode unbrick project (with sources)

Hello everyone. I read this forum for quite a while now and i got here some precious informations that helped me developing a new linux-based solution for qualcomm-chipped devices that are *totally* bricked.
I bricked my HTC One (m7) while trying to tweak it a few days ago and i was quite desperate since i only had it working for 1 day... My phone was consistently disconnecting from network and as a software developer, i thought it was a software problem of course. Once bricked i saw a small piece of paper stuck in the simcard slot when i opened it... Too late
Ok, that's all for the story. Once "dead", my phone started to show the infamous "DLOAD 9006" mode and i found some interesting pieces of software designed to fix that. But, no luck, that phone seems stuck in some kind of "bastard" mode, telling 9006 mode but refusing to act like a usb storage disk. Lots and lots of errors looking at the kernel log with dmesg.
Tried several kernels, 2.6, 3.16 & 4.4 & macintosh too, but really no luck.
And then i came with an idea : making my own stuff to unbrick that sh*t.
I found lots of informations on Qualcomm-based machines, including some info on iPhones and routers. Impossible to get a hold on the official Qualcomm DLOAD documentation, but some others seem to have better luck, and by reading engouh source code, i merged everything i found and made my own project on github.
So here it is, the "dloadtool" : github.com/jnaulet/dloadtool
Sorry i can't post links as i'm a newbie here, you'll have to copy it in your browser by yourself
Don't expect any documentation yet, don't expect binaries, i started to work on this on the 10th of march.
But i can tell you about the main syntax :
# dloadtool [ -F device] command [args...]
By default, the device is /dev/ttyUSB0, but you can change that with the F flag.
Commands are the following (for now) :
- reset (resets the Qualcomm, can be *really* useful)
- magic (sends a magic number) -> as i understood, will only work if chip is correctly loaded
- info (displays some info about the device)
- send XXXX... (sends hexadecimal values directly to the phone, useful for testing, no 0x prefix equired)
- loadhex file.hex (loads a .hex file in memory)
- loadbin file.mn (loads a .mbn file in memory and executes it)
- execute XXXX (executes code at XXX hex address, no 0x prefix required)
Now, you'll need an extra library called libcintelhex to build this program. Here's the source : github.com/martin-helmich/libcintelhex (same problem as above). This lib is required to load intel32 hex files (the MPRGXXX.hex files).
If, like me, you have no luck, your phone will be stuck in a undocumented 9006 mode. That's why you'll need to build the qcserial module i put in my project and patched for the HTC One M7. Just use the build.sh script and everything should go right. Then you'll probably need to type something like that :
# modprobe usb_wwan
# insmod qcserial.ko
So now's the deal. I successfully put my phone from "bad' 9006 mode to clean 9008 mode by using :
# ./dloadtool reset
Then, i could successfully load a piece of code typing
# ./dloadtool loadhex MPRG8064.hex
But program refuses to execute and seems to crash the Qualcomm. I need to unplug & re-plug it, reset it again.
I found lots of MPRGXXX.hex & .mbn files in the UFIBox.com software (if you're looking for them) but none seems to make a difference. Some don't load cause of a different memory map, some crash. :crying:
Maybe, as the chip is a 8064T (Krait 300 core), 8064 (Krait 200) code is not working, i don't know. If you got any kind of information that could help me, please, share ! Thank you. :fingers-crossed:

Some news
Here are some news...
I could finally get a hold a some Qualcomm documentation thanks to this forum, especially the 80-39912-1-E_DMSS_Download_Protocol.pdf on a thread i lost since (sorry).
I made some major updates to my source code, adding lots & lots of commands, some useless, some not so.
So here are the commands i designed :
Code:
#./dloadtool info -> Displays some basic info
#./dloadtool reset -> Hard reset
#./dloadtool magic -> Send magic (Streaming DLOAD protocol, useless for the moment)
#./dloadtool send <hex value> -> Send raw hex values (for testing purposes)
#./dloadtool loadhex <hexfile> [address] -> Loads a .hex file into RAM (IMEM for Snapdragon 600)
#./dloadtool loadmbn <mbnfile> [address] -> loads a .mbn file into RAM
#./dloadtool loadbin <binfile> [address] -> load a raw binary file into memory
#./dloadtool execute <address> -> Executes code at address (More info on this)
#./dloadtool infombn <mbnfile> -> Displays info about the mbn file (reads header)
#./dloadtool signhex <hexfile> <signaturefile> -> experimental. Concatenates hexfile & signature in a .mbn file & modifies header accordingly. Useless at the moment
#./dloadtool signmbn <mbnfile> <signaturefile> -> Same as above
#./dloadtool read <address> <length> -> Reads length bytes at address. Doesn't work in my PBL (only SBL)
#./dloadtool erase <address> <length> -> Erases length bytes at address. Warning: addresses are 20bits segment:offset calculations so probably useless on modern phones (probably used only in old qualcomm NOR flash stuff)
Now let's talk a little more about the HTC One i'm trying to unbrick with this tool.
Here are some info :
Code:
# ./dloadtool -F /dev/ttyUSB2 info
Software Version: PBL_DloadVER2.0
Protocol Version: 0x8
Min Protocol Version: 0x1
Max Write Size: 0x600
Model: 0x90
Device Size: 0x0
Device Type: 0x0
According to the documentation i have, protocol version 8 means the corresponding sheet is 80-39912-1-E_DMSS_Download_Protocol.pdf. Ok, i have it. And if i look inside, Min Protocol Version 1 means non-secure implementation :fingers-crossed: (no need for UNLOCK command at least). Device size & type are no relevant information.
I can load a hex file : :good:
Code:
#dloadtool -F /dev/ttyUSB2 loadhex MSM8064/MPRG8064.hex
< Software Version: PBL_DloadVER2.0
< Protocol Version: 0x8
Min Protocol Version: 0x1
Max Write Size: 0x600
Model: 0x90
Device Size: 0x0
Device Type: 0x0
Loading file MSM8064/MPRG8064.hex...
File size is 53658 bytes
Load address is 0x2a000000
< .< .< .< .< .< .< .< .< .< .< .< .< .< .< .< .< .< .< .< .< .< .< .< .< .< .< .< .< .< .< .< .< .< .< .< .< .< .< .< .< .< .< .< .< .< .< .< .< .< .< .< .< . Done
But i still can't run any file i have, CPU crashes.
So i tried something... Typing every command that's in the spec... And when i typed
Code:
#./dloadtool -F /dev/ttyUSB2 send 18
< 18 01 00 ba 21 02 da 99 c9 24 05 8c 75 8f a9 f4 | ....!....$..u...
25 08 47 c9 2c ab de 17 fd ce f0 1d 4d af f8 df | %.G.,.......M...
5d 67 53
0x18 command stands from "Public Key Hash Request". So there's a public key security system even in this little PBL emergency downloader... Very bad news... :crying::crying::crying:
According to ARM's documentation (didn't re-read Qualcomm's docs yet), this means it's highly possible that even this small primary boot loader needs to check a certificate & signature to allow the "go/exec" commmand.
Unlock command is probably obsolete (only 64 bits), now welcome to RSA encryption secured bootloaders !
This could explain why the MPRG8084.hex file is in fact an intel32-formatted version of a small .mbn file. If i show you the headers of a .mbn file, you'll probably understand what i mean :
Code:
#./dloadtool -F /dev/null infombn MSM8064/8064_msimage.mbn
Read successful
codeword : 0x844bdcd1
magic : 0x73d71034
Image type : SBL1
Load address : 0x2a000000
Body length : 83072
Code length : 83072
Signature address : 0x2a014480
Signature length : 0
Certificate address : 0x2a014480
Certificate length : 0
If i use a .hex file i converted, here's the result
Code:
#./dloadtool -D /dev/null mbninfo mprg8064.mbn
Read successful
codeword : 0x844bdcd1
magic : 0x73d71034
Image type : eHostDl
Load address : 0x2a000050
Body length : 53572
Code length : 53572
Signature address : 0x2a00d194
Signature length : 0
Certificate address : 0x2a00d194
Certificate length : 0
Now, my hypothesis is the CPU refuses to exec cause he wants to check the certificate & signature of the files i upload. But i don't have any of this, only Qualcomm & HTC own these files & they keep them no matter what, cause it's a source of profit for their customer services. :crying:
After two weeks of hard work, unbricking this phone not using JTAG seems hopeless and i'm very frustrated , i'm really mad at Qualcomm & HTC for not letting educated people take total control of a device they bought at a considerable price . Ok, mine was a bargain (before it crashed...), but that's not the point.
I will try to make contact with HTC to see if they can provide my some stuff, but i don't think they will cooperate.
To be continued ?

Some news again
Hello,
Here are the news i got... I made some research and i don't have any good news. :crying:
I started to look at some specs and found information about "the root of trust", part of a security system by ARM called "TrustZone".
Briefly, it's a certificate-based system, put once and for all in the SoC's ROM. Its goal is to ensure no "untrusted" code can be executed. By untrusted, they mean, not signed by the "correct" authority (whose public key hash is available by using the 0x18 command).
More info here : www dot embedded.com/design/safety-and-security/4438300/Securing-the-IoT--Part-2---Secure-boot-as-root-of-trust- AND here : www dot arm.com/products/processors/technologies/trustzone/
I'm no security specialist, but i can tell it will be really difficult to create a certificate that has the same 256 bits hash to sign any code. Collisions may exist in SHA-1 and MD5, but SHA256 is still considered solid.
So I asked Qualcomm about the files i needed to unlock my HTC One phone and here's their answer :
Any information other than what is listed on our website (URL listed below for your reference) is Proprietary to Licensees.
Unfortunately we are unable to assist with your inquiry. We recommend you follow-up with a vendor that carries this product and seek their feedback on your technical questions.
Please note, Qualcomm is the technology provider, not a manufacturer of consumer products and therefore we are unable to answer your product specific question. We hope this direction helps.
Thank you for your inquiry,
Qualcomm Technologies Inc.
Click to expand...
Click to collapse
In short, "ask HTC".
That's what i did and i have little hope. No answer at the moment. :fingers-crossed:
So now's the moment i complain about this exaggerated use of security. This is ridiculous. Exploits exist in Android itself, no need to access the service ports for that, so what's the point ? It seems really unlikely that anyone would install a trojan using the 9008 mode, counting on a user's mistake is a much safer bet.
Boot loaders have become a real pain in the *ss because of this technology. There's a primary boot loader (which requires certification), a secondary boot loader (same thing), a third boot loader (idem) and then android's boot loader (signed too). Is that a phone or a safe ?
For my last words, i recommend that we stay away from the manufacturers that use these technologies to make more and more profit, treating their customers as prisoners.
Stay safe, stay away from this sh*t !

I am looking at this thread here for the first time and thanks for your contribution. Do your tools only work on linux kernels, what about Solaris? I have both is why I ask...
I too am having an issue finding the right programmers...I noticed when using windows based tools to send binaries in 9008 mode that my phone would reset or lose the ability to do the handshaking process. I am going to mark your site on github and take a deeper look at this. This tool may be what I am looking for or at least another option. Thanks!

nate0 said:
I am looking at this thread here for the first time and thanks for your contribution. Do your tools only work on linux kernels, what about Solaris? I have both is why I ask...
I too am having an issue finding the right programmers...I noticed when using windows based tools to send binaries in 9008 mode that my phone would reset or lose the ability to do the handshaking process. I am going to mark your site on github and take a deeper look at this. This tool may be what I am looking for or at least another option. Thanks!
Click to expand...
Click to collapse
As long as you device is recognized as /dev/<something>, this should work in either system, using the -F option to select the right device, if needed. The kernel patch is for linux only and should not be required at all (unless your phone shows as 9006 mode but is in fact 9008, like mine was).
As i'm a linux user, i got some more info by using dmesg (to know if a driver was loaded correctly) and lsusb (to get the phone's mode). I don't know if these tools are available on Solaris. But there are probably alternative commands, though.
Beware, using this tool, i was able to reset & load files into the phone's memory, but not to run any code. I hope you're lucky enough to have a phone that's not "secure boot"-protected.

I tried a hex file labelled GPP8064.mbn and I believe it executed on my Nexus 7.
Dmesg was flooded with 14 devices that looped but could not connect successfully.
Perhaps this information would help you further?
Sent from my ONE A2005 using Tapatalk

when I launch your program (dloadtool) I got
./dloadtool -F /dev/ttyUSB0 info
< Invalid CRC!!!
Error receiving software version!!
< Invalid CRC!!!
Errore di segmentazione

marte3707 said:
when I launch your program (dloadtool) I got
./dloadtool -F /dev/ttyUSB0 info
< Invalid CRC!!!
Error receiving software version!!
< Invalid CRC!!!
Errore di segmentazione
Click to expand...
Click to collapse
Same here, trying to use it on a US s8+ (sd835)

can anyone supply me the download link please