yashsingh1/xdaforums huggingface dataset:
[HTC Pico (Explorer)] no.human.being:
The secu_flag (S-ON/S-OFF) is most likely not part of the entire NAND address space that's visible from aARM (doesn't have a virtual address assigned). It's only visible from mARM. At least that's how it is for the Wildfire S (MSM7227, also NAND device). S-ON and S-OFF device looks completely identical, even if you take into account the "unmapped memory" (a memory region that's shared between aARM and mARM and most likely used by the virtualization layer for internal purposes). Only mARM can see the secu_flag and aARM can call a function in the Iguana kernel (running on mARM) via RPC (remote procedure call) to let Iguana read the flag and return the value to aARM. HBOOT e. g. does this before deciding whether to print "S-ON" or "S-OFF" to the screen or when deciding whether to verify signatures or not.

On eMMC devices, the secu_flag is visible in a special "config" partition. It's the least significant bit of a 32-bit word and is a binary 1 for S-ON and a binary 0 for S-OFF.

On NAND devices, it is similar, it's just that this "config" partition is only visible from mARM or by physical access to the NAND (e. g. via JTAG). If you have JTAG, you can just flip that bit to zero (if you know where it is located) and have an S-OFF device. This is why NAND devices are so hard to hack. You want to change a value that you cannot even access because it resides in a page that doesn't even have a (virtual) address assigned by the MMU.

What we tried to do instead is patch the HBOOT so that it doesn't do the proper RPC call to Iguana, which causes it to read and return the secu_flag, but call a function that definitely returns zero instead. To do this, we developed an exploit (called "chainloader") that allowed us to execute arbitrary (unverified) boot code on aARM. To do so, it exploits a security vulnerability in the Android Fastboot protocol. However, for some reason, HBOOT (the "tampered" HBOOT that WE LOADED!!) recognizes that "something's wrong" (the exploit probably leaves some registers/etc. is some "weird state" which HBOOT then notices, but since we don't know how a "cleanly initialized" aARM looks like, we can't really "fix" this) and jumps back to SBL, which then loads a "clean (signed) copy" of APSBL (HBOOT), puts the processor back into a "secure state" so nothing's won.

Since we have complete control over the boot code we load, we could in principle patch that "fallback" behaviour out of HBOOT, then we've won. However, we have absolutely no idea where this happens. We'd need JTAG debugging (single stepping) for this to verify at which point the branch back into the SBL code happens. However, we don't have this facility.
[HTC Pico (Explorer)] RohAb:
Any latest news about s- OFF have u reach any point:thumbup::thumbup::thumbup::thumbup:
[HTC Pico (Explorer)] #define:
I, for one, am not working on it anymore..
[HTC Pico (Explorer)] RohAb:
Why:confused::confused::mad:
[HTC Pico (Explorer)] #define:
I dont have the necessary equipment, or the knowledge to crack it..
[HTC Pico (Explorer)] no.human.being:
Seems as if no one has JTAG debugging on a phone. I tried it on an HTC Wildfire S (Marvel), which uses an MSM7227 (ARM11, ARMv6) processor, for which I purchased JTAG equipment. However, the processor's I/O voltage was too low. I'd have to shift the voltage levels up and down between what JTAG uses (3.3 V) and what the processor uses (0.9 V). Never got that going.

Without JTAG, you can't debug system-level code.
[HTC Pico (Explorer)] thewisenerd:
Is there any way that the hboot can be modified, so as to "re-partition" the internal NAND?

As for now, and for future android versions, the /system partition is too small to be of any use, and we have to spend a hell lot of time, trying to slimmer the ROM.

Is it possible by modifying the HBOOT?

And, many of the users use "memory increasing scripts", so doesn't matter if the internal /data partition or the /cache partition (not used much), can be slimmered down to a meagre 5 to 10 MB, so that we get "enough system space" (that should give the /system partition ~400MB), enough for ROMs to fit in.

I remember seeing the Nexus One using patched HBOOT with "re-sized partitions"...
[HTC Pico (Explorer)] kirmaniarslan:
try to decompile Hboot.img with tool chain n check files but I dont think its possible as every partition in NAND gives its own address :(
[HTC Pico (Explorer)] thewisenerd:
the boot sequence takes a command that goes something like "mtd_partitions=" or similar usage. I'm guessing that's being parsed somewhere in the hboot. In case that's "hacked" correctly, partitions can be derped with :p
[HTC Pico (Explorer)] Antagonist42:
Could be possible but only if your MBR and EBR are aligned, meaning there are no partition overlaps or shortfalls.

Ran parted on HTC desire C and the partition that contains the RADIO is actually "split" and has a partition marker around the middle of it, making those two partitions:

1. Dangerous to calculate partition sizes and maintain program integrity around.

2. The first partition and part of RADIO is uneditable as it's size and location is governed by the MBR, which is uneditable due to S-ON.

Without a signature or key it ain't goin' nowhere unless you exploit it.

Without going into the exploit code for hTC desire C my guess is they've found a breach possibly to do with the power supply W_DOG pin for the nand (it has to be volted + or - to access nand writting through MSMxxxx) hence that's my guess for the 7 vibrator buzzes at boot.

One location the secu_flag could be is within the first 2 or 4 (can't remember off top of my head) bits of the oob data which is programmable by a vendor and can be used for ?x? as it's unused by oob.

Bashing away at my HTC Desire C

---------- Post added at 07:04 PM ---------- Previous post was at 06:28 PM ----------

Also to look at is something like mmcblk0p3 or 4 for

.NK^4.x

This is (I believe) the unseen and unnoticed OS QNX that is keeping separate the mARM and aARM whilst using the same IMEM space seeing as the data contained in it resembles a MBR and EBR which would make sense as QNX is a micro-OS so calls to the RADIO are only passed via QNX which is as OS to itself running between aARM, mARM, MSMxxxx, NAND and running possibly before HBOOT.

At least that's my idea how the first 4 or 5 partitions are laid out with the MBR and EBR within them.

Bashing away at my HTC Desire C
[HTC Pico (Explorer)] Ulumia:
From here on in more detail

I want to get S-OFF on my Wildfire S
[HTC Pico (Explorer)] SifJar:
The fastboot boot command is not needed for that. The fastboot oem unlock command is used for that.
[HTC Pico (Explorer)] immortal_yash:
Will try it out tommorow...:thumbup:
[HTC Pico (Explorer)] #define:
Sry for the slowness guys... m a bit busy with term work right now..
[HTC Pico (Explorer)] dexterdongle:
HBOOT 1.01.0000

RADIO 1.10.80.13M2 oct 06 2011

here
[HTC Pico (Explorer)] DanceOff:
My boot is 1.00.00..and some more zeros
[HTC Pico (Explorer)] #define:
haha.. it should be 1.00.0000...

But anyway, it'll take some time as I have to install ubuntu all over again..

Will do it in the diwali vacations..
[HTC Pico (Explorer)] Hpsgill:
my hboot is 1.03 can i help u

and can we s-on again after s-off our phone
[HTC Pico (Explorer)] #define:
Yes u can do a lot of stuff after s-off... See the link in the 1st post of the thread..

And right now my system's messed up, plus i have my term end, so lots of assignmnts to write.. so i hv to put it aside for a couple weeks nw..

Sent from.....well...doesnt matter
[HTC Pico (Explorer)] satvik7star:
Hey bhargz16 i also have hboot 1.00
[HTC Pico (Explorer)] #define:
In the meantime, if someone knows how to do it, then scan the hboot.img file with a hex editor, and tell me the physical address at which the hboot is loaded during execution... Should be at offset 0xc... Thank you... Any hboot version will do....

Sent from.....well...doesnt matter
[HTC Pico (Explorer)] cute_prince:
Buddy, our kernel loads at physical address 0x12C00000
[HTC Pico (Explorer)] #define:
Thanx man.... Thats all i needed to know!!... Now as soon as my pc is up and running, i'll make a modified hboot and try it...

Sent from.....well...doesnt matter
[HTC Pico (Explorer)] #define:
Unless someone wants to give it a shot... I'll give you the files and instructions...

Sent from.....well...doesnt matter
[HTC Pico (Explorer)] cute_prince:
PM me all the files and instructions .. I'll test it

I am already excited because I got kernel 3.0.16 loaded successfully now..though i am getting problems from user space
[HTC Pico (Explorer)] sebastaxi:
hello! no news?
[HTC Pico (Explorer)] #define:
Sorry buddy.. No news as of now..

I am a bit busy with college at the moment.. Will do something after college gets over..
[HTC Pico (Explorer)] sebastaxi:
thank you! I will look in the forum! First things first: Good:
[HTC Pico (Explorer)] 7alvi:
my hboot version is 1.0000 and some zeroes...if u need need testors for this version, im willing enough!!

all the best :good:
[HTC Pico (Explorer)] #define:
Conversion...

Does anybody know how to convert an hboot.img file into a .bin file???

Simply changing the extension isnt the answer here.. :P
[HTC Pico (Explorer)] arunsai123:
dump tool can be used to make bin file from firmware.
[HTC Pico (Explorer)] #define:
Can you link me to any dump tool??
[HTC Pico (Explorer)] arunsai123:
I dont know about it.my friend uses it to create bin file by connecting jtag to setup boxes, nokia phone ,ps2 etc to copy firmware.

abritus72.com/opeldumptool.html
[HTC Pico (Explorer)] #define:
We just have convert to a bin file.. not create it.. thanks anyways.. :)
[HTC Pico (Explorer)] Sachin Thomas:
What's the difference between an img file and a bin file?
[HTC Pico (Explorer)] #define:
An img file is file we flash or install on the phone.. for eg, when you wanna flash a recovery, you use a recovery.img file.. in short, it is a file from which the phone can read data.. a bin file, or binary file, is for the computer to understand the contents of it(as you know, a computer can only understand binary language).. hence to convert the file from phone readable to computer readable, we need to convert the hboot.img file into a binary file.. to extract the machine code from it, so that we can attach it with the chainloader exploit(which is also machine code) and make a modified hboot.img file, which will give us temporary S-OFF...
[HTC Pico (Explorer)] Sachin Thomas:
We can disassemble and patch the hboot.img using IDA Pro.

http://www.hex-rays.com/products/ida/index.shtml

But how are you going to flash the modified hboot?
[HTC Pico (Explorer)] #define:
Thanks man... Thanks a lot.. But IDA is very costly.. 1000 USD!!!!

I'll not flash it, i'll directly boot from it.. using the 'fastboot boot ...' Command...

The phone wouldnt allow us to flash a modified hboot, since the signature would be messed up...
[HTC Pico (Explorer)] Sachin Thomas:
There's a trial version try it and check whether it's helpful :D
[HTC Pico (Explorer)] sebastaxi:
hello! 1 question as HBOOT sack my phone or my recovery?

thank you!
[HTC Pico (Explorer)] Sachin Thomas:
The Wildfire S people are using "arm-none-eabi-objdump" for disassembly. I think it's simpler than IDA for our purpose.
[HTC Pico (Explorer)] #define:
Yes.. I'm using their "chainloader exploit" only.. We just need to change two things to gain S-OFF from their exploit.. The physical address at which the kernel loads(we have this, thanks to cute_prince)... And the address in the hboot.img file, where the S-ON/S-OFF check is stored(This, I dont know how to find & need help with)... But before doing S-OFF, we need to check whether the exploit works correctly on our phone or does it need more modification.. For this, I'm preparing a modified hboot.img, in which i'll change some value(for eg, version of hboot displayed), and if it works, then we can find the S-ON/S-OFF check in the hboot.img file and change that..
[HTC Pico (Explorer)] Sachin Thomas:
What tool are you using to modify hboot.img?
[HTC Pico (Explorer)] #define:
Bless Hex Editor for now...
[HTC Pico (Explorer)] #define:
Guys, I need help.. I'm trying to locate where the S-OFF check in the hboot lies.. Could someone help me check it?? I'm uploading an hboot analysis(with strings)..

The 1st 8 digits(along with 'ROM:') is the address of the string.. The next 8 digits is the length of the string.. The "C" is the code, ie, its C lang(i think).. Whatever comes after C is the string value.. Can someone help me look for the S-OFF check??

Thanks..

http://www.mediafire.com/view/?a1bjr2q8op2h82p
[HTC Pico (Explorer)] Sachin Thomas:
How can we find the code by looking at strings? We should look at the disassembly
[HTC Pico (Explorer)] #define:
Yes, but if we know what those strings are referring to, it'll be easier to find the code...
[HTC Pico (Explorer)] #define:
Here's the machine code of an hboot.img... This is well beyond my understanding... For the next 3 months atleast...

http://www.mediafire.com/?djaz55uap3clv3j
[HTC Pico (Explorer)] Sachin Thomas:
I found some magic cryptographic constants in hboot.img at following offsets

7F7A1: found const array PKCS_DigestDecoration_SHA256 (used in PKCS_SHA256)
7F7DC: found const array Rijndael_Te4 (used in Rijndael)
7FBDC: found const array Rijndael_Td3 (used in Rijndael)
7FFDC: found const array Rijndael_Td0 (used in Rijndael)
803DC: found const array Rijndael_Td1 (used in Rijndael)
807DC: found const array Rijndael_Td2 (used in Rijndael)
80BDC: found const array Rijndael_Te0 (used in Rijndael)
80FDC: found const array Rijndael_Te3 (used in Rijndael)
813DC: found const array Rijndael_Te1 (used in Rijndael)
817DC: found const array Rijndael_Te2 (used in Rijndael)
81BDC: found const array Rijndael_Td4 (used in Rijndael)
81FE0: found const array SHA256_K (used in SHA256)
85DB8: found const array CRC32_m_tab (used in CRC32)

Does the S-OFF checking code use any cryptographic algorithms? If yes, then that code region must refer to these constant arrays
[HTC Pico (Explorer)] #define:
I think it uses RSA...
[HTC Pico (Explorer)] #define:
Some progress...

Alright guys, we've made some progress..

We were able to successfully change the hboot version that is displayed, with the help of the code that the people over at the Wildfire S forum gave us..

Here, the we is Sachin Thomas and myself..

Ofcourse a special mention to 'no.human.being', the genius who wrote the code..

The hboot we boot from, hangs up.. making the phone unresponsive to the buttons, as well as usb.. So we have to restart the phone by yanking the battery out..

Now, for S-off we have to change the value of the secu-flag check to always return 0.. Aftr that, we'll get S-OFF.. Fortunately, i have some leads.. And so does Sachin Thomas..

Once we achieve s-off, the only problem left to solve will be the phone hanging(this will take some time)..

Here's a picture..

Notice the version changed to 1.13.0000, from 1.03.0000(version we tested on)..

Also notice the "security warning" displayed, which means the code works..
[HTC Pico (Explorer)] DanceOff:
How do you get locked ? Did you managed to get that !

Wow That's amazing :eek:
[HTC Pico (Explorer)] #define:
Well, when we unlock the bootloader, in the process, htc changes a value in the hboot code that displays "unlocked"..

We did this experiment on an hboot.img file that was directly extracted from an RUU.. Now RUUs are supposed to be completely "Stock"..

So the bootloader by default is locked in an RUU.. Hence you see Locked..

If we did this with the hboot.img extracted directly from the phone, it would show unlocked, if your phone has unlocked bootloader..

Hope this clears it up..
[HTC Pico (Explorer)] Hpsgill:
Wow maaaan u are great hope we will get s off soon
[HTC Pico (Explorer)] DanceOff:
Apart from s-off, we can also lock the bootloader to regain warranty.

That is some awesome development going on !

Thanks
[HTC Pico (Explorer)] #define:
I appreciate the support... :D
[HTC Pico (Explorer)] Hpsgill:
Any progress?????
[HTC Pico (Explorer)] #define:
Not tonight bro... Busy with some stuff tonight(writing)..
[HTC Pico (Explorer)] DanceOff:
If you are ready to explain the progress and what did you do I am also in !
[HTC Pico (Explorer)] #define:
Sure.. our progress so far is that we can boot from a modified hboot, although we arent able to flash it(we never will, because of signature problems).. And in our modified hboot, we have changed the version of the hboot displayed.. this is just a simulation to check if the code runs.. the code here, the exploit, was originally written by 'no.human.being', a dev over at the Wildfire S forum.. They are also trying to achieve S-OFF for over a year now.. So what he did was, he wrote a code that, when attached to an hboot image, can be booted from on the phone.. You must've heard/read about revolutionary/alpharev/xtcclips, etc, ie, different methods to achieve s-off.. What the WFS people did was much similar to the revolutionary method for S-OFF.. Now, they have already found and patched the S-ON/S-OFF function call to always return 0 (0 means S-OFF, any other value means S-ON).. But when we boot from the code, the fastboot usb and phone stops responding.. Thats their progress so far....

Now, us..

We are only one step behind them now.. We know that the code is now working on our phones(explorer) as well, and we've successfully managed to change the hboot version displayed on screen.. Now what we have to do, is find the S-ON/S-OFF check, and make the function always return 0... After that, we have to solve the problem of the phone not responding when booting from the code..

Now, the S-OFF function will be patched, but the harder phone not responding problem will take some time to solve out.. this is our progress..

Now, for helping out.. You can inspect an hboot.img file using a hex editor and see if you can find anythig related to S-OFF.. If you can, post here.. I am using this.. If you can get your hands on it, then you can inspect the hboot strings as well, see what address they are referring to, and change the values to whatever desired in either hboot.img file, or in machine code, ie, hboot.s file.. Now changing machine code, compiling it back into an hboot.img file(from hboot.s), compare it with original, and change the corresponding values in original using a hex editor would be easier.. So if you know how to read machine code(direct machine code), please help out..
[HTC Pico (Explorer)] zgintasz:
Maybe if you don't make function always return 0 and instead you change a variable which contains s-off state it won't stop responding. Do you decompile code, change value and then compile again or just change some values in hex editor or something like it? If decompile, change, compile, then maybe it doesn't compile properly :?. By the way, upload hboot.img please.
[HTC Pico (Explorer)] #define:
Actually decompiling and recompiling doesnt work as it messes up the htc signature while recompiling.. htc signs these images in a very weird way.. it seems that the 1st few bytes of the data is intentionally corrupted, but in reality, its a scrambled signature.. And its most probably RSA encryption(if i remember correctly)..

If you have android toolchains, then you can try this on an hboot.img file.. run this in terminal..

arm-none-eabi-objdump -D -b binary -m armv5 hboot.img > hboot.s

And open the file with a text editor.. That is the coding of the hboot.img..

And also, there are no variables.. or loops, or any function calls.. its pure machine code.. just registers.. and conditional branches..

which hboot would you like me to upload?? the modified one?? in that theres nothing special..just version change and security warning.. although sachin has told me that he doesnt get the security warning like i do.. he just gets locked, and changed version string...
[HTC Pico (Explorer)] zgintasz:
You can upload original and modified. If there is no variables, where are info saved? If in registers, then maybe you should change it like a variable(if it's possible).
[HTC Pico (Explorer)] #define:
Oh so you wanna compare?? Ok.. I'll upload tomorrow.. And yes.. we have to deal with registers only.. for eg, if a value 2 is to be stored in register r1, but you wanna store it in r0, then instead of "mv r1 #2", we write "mv r0 #2".. we just have to change it.. nothing else.. just change it and recompile it.. and then change the corresponding value in the original using a hex editor..
[HTC Pico (Explorer)] DanceOff:
I wish there was sort of a logcat for hboot.

I will also try, Can you PM me the main part ie. What code you changed!
[HTC Pico (Explorer)] #define:
I didnt understand.. which main part??
[HTC Pico (Explorer)] Hpsgill:
Its code he changed:rolleyes:
[HTC Pico (Explorer)] cute_prince:
@bhargz16 good work bro :thumbup:

glad to see that modified hboot.img worked :)
[HTC Pico (Explorer)] DanceOff:
I mean what did you actually do with boot.img I have no clue so I was asking how did you open that file and what code you changed ?
[HTC Pico (Explorer)] #define:
I opened it with a hex editor and changed the values according to strings displayed with what i wanted it to display..
[HTC Pico (Explorer)] Gladiator00:
So changing one or two numbers changes the whole Hboot? :eek:
[HTC Pico (Explorer)] Sachin Thomas:
No, its not like that. We did not try to change the whole hboot.

The Wildfire S team has created an exploit, which allows us to boot form an unsigned hboot image. We have only confirmed that this exploit works on our device too, by modifying an uncritical value (the version string). Now we need to disassemble the hboot.img and locate the code that checks for S-OFF and patch it to return always S-OFF. This is not easy because we don't have devs who are experienced in disassembly :D
[HTC Pico (Explorer)] cute_prince:
@Sachin: Can you post here the disassembled hboot code (hboot.s)
[HTC Pico (Explorer)] Sachin Thomas:
http://www.mediafire.com/?o3tqg9k8czrctlq

It's not perfect. The disassembler mistakenly identifies some data as code
[HTC Pico (Explorer)] #define:
In the hboot.s file, check out the following references..

79344; 89a98 - these two refer to "hboot pre update".. So this can probably solve the hboot not responding issue..

89148 - this refers to "sign verification"..

96420 - this is the S-ON string..

96428 - " " " S-OFF string..

98a54; 98a78 - these are where the "readsecureflag" function refers to.. 'a54' is ON, and 'a78' is OFF..

9b310 - this address refers to the bootloader status.. whether to display "Locked", "Unlocked" or "Relocked"..

9b1cc; 9b198 - these 2 have something to do with "secu_flag"..

This could narrow down our search criteria..
[HTC Pico (Explorer)] Sachin Thomas:
We have the offset of those strings :good:

Now we need to find the instructions (the code) that refers to these strings.That's where I'm stuck. If we find that code, we can trace back to the function that does "some magic" as NHB described
[HTC Pico (Explorer)] DanceOff:
Can you upload the hboot you are working on for me !

One question bro :

My current hboot is sometging 1.00.00... so if I flash another hboot will I brick my phone ?

Or if I flash a messed up hboot so I will hard brick my phone ?