still edging closer to the elusive s off.
I have pushed gfree to phone with adb then run using terminal emulator but get the following error.
Do I need to flash a new kernal?
I'm perm root with visionary and on version 1.32 not 1.72
And help would be really really great! I don't have much hair left....
Thanks
export PATH=/data/local/bin:$PATH
$ $/data/local/gfree -f
--secu_flag off set
--cid set. CID will be changed to: 11111111
--sim_unlock. SIMLOCK will be removed
Section header entry size: 40
Number of section headers: 44
Total section header table size: 1760
Section header file offset: 0x00015398 (86936)
Section index for section name string table: 41
String table offset: 0x000151df (86495)
Searching for .modinfo section...
- Section[16]: .modinfo
-- offset: 0x000011cc (4556)
-- size: 0x000000c4 (196)
Kernel release: 2.6.32.21-gf3f553d
New .modinfo section size: 204
Attempting to power cycle eMMC... Failed.
Module returned an unknown code (Operation not permitted).
$
Sent from my Desire HD using XDA App
If you really are permrooted, it might be good to run command "su" before gfree, to gain root shell. When you have root shell, the $ will be replaced with #.
Thank-you, you are a star!
Worked perfectly.
Now to flash that Rom !
Sent from my desire HD using XDA App
Hi! I've been home for the last six hours trying to revert my Desire Z to stock, achieving S-ON and setting my CID back to HTC__Y13.
Now to start of, I'm not entierly sure that I need to do any of this, but this is my work phone that I decided to root yesterday and flash CM7. After this I was unable to connect to a custom APN my job use to access their intranet.
My first theory was that it for some reason required a Sense ROM, don't ask me why but troubleshooting always starts with the easiest solution. That didn't help and I figured that it, for some obscure reason, had to do with my phone now being S-OFF and using SuperCID. Since that's the only things that have changed, AFAIK.
After trying several guides, here on XDA and other forums I just can't get it to work.
gfree gives me the error;
Code:
/data/local/tmp/gfree -s on -c HTC__Y13
--secu_flag on set
--cid set. CID will be changed to: HTC__Y13
Section header entry size: 40
Number of section headers: 44
Total section header table size: 1760
Section header file offset: 0x000138b4 (80052)
Section index for section name string table: 41
String table offset: 0x000136fb (79611)
Searching for .modinfo section...
- Section[16]: .modinfo
-- offset: 0x00000a14 (2580)
-- size: 0x000000cc (204)
Kernel release: 2.6.32.21-g6e170e7
New .modinfo section size: 204
[B]Attempting to power cycle eMMC... Failed.
Module failed to load: Operation not permitted[/B]
BUT! if I try to just change the CID it gives me;
Code:
/data/local/tmp/gfree -c HTC__Y13
--cid set. CID will be changed to: HTC__Y13
Section header entry size: 40
Number of section headers: 44
Total section header table size: 1760
Section header file offset: 0x000138b4 (80052)
Section index for section name string table: 41
String table offset: 0x000136fb (79611)
Searching for .modinfo section...
- Section[16]: .modinfo
-- offset: 0x00000a14 (2580)
-- size: 0x000000cc (204)
Kernel release: 2.6.32.21-g6e170e7
New .modinfo section size: 204
Attempting to power cycle eMMC... OK.
Searching for mmc_blk_issue_rq symbol...
- Address: c02adc1c, type: t, name: mmc_blk_issue_rq, module: N/A
Kernel map base: 0xc02ad000
Kernel memory mapped to 0x40011000
Searching for brq filter...
- Address: 0xc02adc1c + 0x34c
- 0x2a000012 -> 0xea000012
Patching and backing up partition 7...
Done.
Which in my eyes looks ok. But after rebooting gfree_verify still tells me that my CID is 11111111.
I can connect to my carriers APN just fine, but work APN is a no-go.
WHAT TO DO?
in advance, many thanks!
UPDATE:I played around with a couple of other guides, and tried restoring the original backup again. Tried before but with no sucess. No idea why it gave me a bit more progress this time.
Code:
# /data/local/tmp/gfree -r part7backup-1323885190.bin
/data/local/tmp/gfree -r part7backup-1323885190.bin
--restore set. Partition 7 will be restored from file: part7backup-1323885190.bi
n
Section header entry size: 40
Number of section headers: 44
Total section header table size: 1760
Section header file offset: 0x000138b4 (80052)
Section index for section name string table: 41
String table offset: 0x000136fb (79611)
Searching for .modinfo section...
- Section[16]: .modinfo
-- offset: 0x00000a14 (2580)
-- size: 0x000000cc (204)
Kernel release: 2.6.32.21-g6e170e7
New .modinfo section size: 204
Attempting to power cycle eMMC... OK.
Write protect was successfully disabled.
Searching for mmc_blk_issue_rq symbol...
- Address: c02adc1c, type: t, name: mmc_blk_issue_rq, module: N/A
Kernel map base: 0xc02ad000
Kernel memory mapped to 0x40002000
Searching for brq filter...
- Address: 0xc02adc1c + 0x34c
[B] - ***WARNING***: Found fuzzy match for brq filter, but conditional branch isn't
. (0xea000012)
Backing up current partition 7 and restoring specified backup...
Error opening restore file.[/B]
UPDATE AGAIN: Installed newest OTA, started to get desperate, CID is now correct, no root, but it still tells me it's S-OFF. As far as APN connectivity I'm lost. Still no cigar.
Which Radio are you running? cause gfree needs a 26.03.xx.xx or lower (from memory) and a 1.32 rom.
-Nipqer
I'm not sure, as the update said in the first post, I went for the desperate OTA solution. And at work I called IT. Didn't want to tell them I rooted the phone, so I told them the OTA messed with my settings, told them my phone number and she probably added it to a whitelist. But it works now. Kinda regretting that I didn't try that with SuperCID and a rooted rom. Only strange thing is that I'm still S-OFF.
if you are still s-off you can just flash a custom recovery through fastboot and then a custom rom, and then call IT again
Haha, my first thoughts exactly! I'm really curious about what she did to make it work again. And why the hell use an own APN instead of VPN or just a regular login site. But then again, nothing makes sense at this company.
If I'm going to flash something again I need to wait a while. I can't be the guy with constant phone problems.
I go to run the very last command in http://forum.xda-developers.com/showthread.php?t=2221039 (HTC Desire HD Rooting Guide) and it shows this..
C:\Users\Administrator\Desktop\ace-tools>adb shell /tmp/gfree -f
--secu_flag off set
--cid set. CID will be changed to: 11111111
--sim_unlock. SIMLOCK will be removed
Section header entry size: 40
Number of section headers: 44
Total section header table size: 1760
Section header file offset: 0x00015398 (86936)
Section index for section name string table: 41
String table offset: 0x000151df (86495)
Searching for .modinfo section...
- Section[16]: .modinfo
-- offset: 0x000011cc (4556)
-- size: 0x000000c4 (196)
Kernel release: 2.6.35.14-cyanogenmod-ga63ac6f
New .modinfo section size: 216
Attempting to power cycle eMMC... Failed.
Module returned an unknown code (No such file or directory).
G-Free is known not to work well with the Desire HD...
I'd reccomend using the guide by Glevitan
Did I help you? Hit THANKS!
Galaxy S3 (BEAST, stock)
Desire HD (Retired, REVOlution)
Galaxy Note 10.1 (Big Bad Wolf, stock)
Hello,
I'm trying to root my phone after instructions from cynogenmod and brutzelstube.
I got tmp root i think? i've posted below my terminal:
Code:
# cd /data/local/tmp
# ./gefree -f
./gefree: not found
# ./gfree -f
--secu_flag off set
--cid set. CID will be changed to: 11111111
--sim_unlock. SIMLOCK will be removed
Section header entry size: 40
Number of section headers: 44
Total section header table size: 1760
Section header file offset: 0x000138b4 (80052)
Section index for section name string table: 41
String table offset: 0x000136fb (79611)
Searching for .modinfo section...
- Section[16]: .modinfo
-- offset: 0x00000a14 (2580)
-- size: 0x000000cc (204)
Kernel release: 2.6.32.21-g540976a
New .modinfo section size: 204
Attempting to power cycle eMMC... OK.
Searching for mmc_blk_issue_rq symbol...
- Address: c02a9508, type: t, name: mmc_blk_issue_rq, module: N/A
Kernel map base: 0xc02a9000
Kernel memory mapped to 0x40000000
Searching for brq filter...
- Address: 0xc02a9508 + 0x34c
- 0x2a000012 -> 0xea000012
Patching and backing up partition 7...
patching secu_flag: 0
Done.
# ./flash_image recovery recovery.img
# ./root_psn
./root_psn: permission denied
#
so i can't go further. Any help? do someone know what I'm doing wrong?
I got around this. dont know really why, but if it is working I'm happy
I worked on with this instructions
but gfree doessn't work:
Code:
# ./gfree -f -b hboot-eng.img -y recovery.img
--secu_flag off set
--cid set. CID will be changed to: 11111111
--sim_unlock. SIMLOCK will be removed
--hboot set. hboot image hboot-eng.img will be installed in partition 18
--recovery set. recovery image recovery.img will be installed in partition 21
Section header entry size: 40
Number of section headers: 44
Total section header table size: 1760
Section header file offset: 0x000138b4 (80052)
Section index for section name string table: 41
String table offset: 0x000136fb (79611)
Searching for .modinfo section...
- Section[16]: .modinfo
-- offset: 0x00000a14 (2580)
-- size: 0x000000cc (204)
Kernel release: 2.6.32.21-g540976a
New .modinfo section size: 204
Attempting to power cycle eMMC... OK.
Write protect was successfully disabled.
Searching for mmc_blk_issue_rq symbol...
- Address: c02a9508, type: t, name: mmc_blk_issue_rq, module: N/A
Kernel map base: 0xc02a9000
Kernel memory mapped to 0x40002000
Searching for brq filter...
- Address: 0xc02a9508 + 0x34c
- 0x2a000012 -> 0xea000012
Backing up current partition 18 and installing specified hboot image...
md5sum #1 = 43e1df3fb473f51a34021dbe5544f2c7
md5sum #2 = 2ce1bdd5e4c1119ccfcecb938710d742
Backing up partition /dev/block/mmcblk0p18 to /sdcard/part18backup-1452701984.bin ...
Writing image hboot-eng.img to partition /dev/block/mmcblk0p18 ...
md5sum #3 = 43e1df3fb473f51a34021dbe5544f2c7
md5sum #3 == md5sum #1 - the hboot image was not installed!
Probably the power cycle of the eMMC failed. Check the messages above.
You might join the IRC channel #G2Root on Freenode for further help!
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