yashsingh1/xdaforums huggingface dataset:
[HTC Wildfire S] no.human.being:
Lol the DIAG utility is running directly "on the metal" with no operating system below and that the hardware allows random access is known (otherwise have fun implementing a file system on it). It's just that the Android kernels do not allow random access over the APIs. :D

And no it doesn't "tell HBOOT" to do anything. HBOOT just loads "DIAG" as a "kernel" and then "DIAG" can control the NAND hardware directly. :D

You don't have to run Linux as a kernel. In fact you can run any C program as a "kernel", you just have to handle all the hardware stuff yourself. No file system, no virtual memory, no timers, no scheduling, no interrupts, nothing. That's how DIAG works. :D
[HTC Wildfire S] theq86:
so maybe we could get insight by having a look into such diag. even if that would mean to mess with assembler instead of an API :D
[HTC Wildfire S] BeciMester:
Guys, I'm sure it's been answered before but the search "function" in this forum is utterly useless: does flashing a hboot delete any user data? :O
[HTC Wildfire S] heavy_metal_man:
what would happen if we loaded the diag file into the ram? would it execute it?
[HTC Wildfire S] no.human.being:
The problem is that I don't even know how NAND access is done in assembly. :D

Afaik internally the controller uses the protocol SPI (Serial Peripheral Interface) to talk to the NAND so it might be that there are "registers" for an "SPI controller" exposed and you have to make your software talk the "SPI protocol" to interface with the NAND.

Or it might be that the address space for RAM and NAND is "contiguous" so it just says something like "RAM goes from 0x00000000 to 0x1fffffff and NAND goes from 0xe0000000 to 0xffffffff" or whatever and when you read/write from/to a "low address" the MMU just passes it on to NAND and when you read/write from/to a "high address" the MMU subtracts the offset of 0xe0000000 and passes it on to the NAND.

At the moment I don't know.
[HTC Wildfire S] theq86:
could we run it at all? I mean it may not be an ELF executable but it consists of machine code ...
[HTC Wildfire S] heavy_metal_man:
if it was still restricted by the flexy sim cable stuff surly we could just edit it out of the code, or tell it to always tell it to say that it is there. we wouldnt need to still be signed by htc as it would be in the ram;)

and if it was to work it would be universial with all htcs?? as we would only need to edit the file and have the htcdev bootloader?
[HTC Wildfire S] theq86:
Well, nhb said hboot runs the diag. so what if the security is only implemented in hboot?
[HTC Wildfire S] no.human.being:
I'm not sure if it has a header on (have never seen a DIAG file). If it doesn't we'd probably have a hard time figuring out how it "wants to be loaded" (the header tells HBOOT to which physical RAM addresses the code has to be loaded, among others, these values have to be correct as the "jump" and "read/write" commands obviously supply RAM addresses and if the code is "somewhere else" it'll "read/write/jump" in the wrong places). If it has we can probably just "fastboot" it. :D

Erm, it's supposed to run as an operating system kernel. ELF only makes sense if it's supposed to be loaded by a "program loader". Obviously this is not the case here. The "bzImage" of our kernels begin with machine code right away. The "vmlinuz" kernels on my host also don't have a header. It might have the "ANDROID!" header that Android kernel images have, but certainly not ELF.

No. Afaik there are two checks. You can see on the xtc-clip when its "fake SIM" is queried since the LED will blink on the clip and it's definitely queried after you select "Clear S58". The "Clear S58" string is displayed by DIAG, not HBOOT. We have access to the phone's "unmapped memory" which contains HBOOT and there is no "Clear S58" string in in the phone's memory so it's not part of HBOOT. After DIAG is run, HBOOT won't execute any more. HBOOT is a "one way street". All it can do is load another "kernel" into RAM and pass execution to it. It's really "dumb" (it's only 512 kB large iirc). Once it runs another OS, HBOOT itself is "dead". It's not designed to "live" after having loaded an "operating system". So it's the DIAG software that queries the engineering SIM. HBOOT may query though before running DIAG and refuse when the SIM is not present, I'm not sure about that, but DIAG definitely queries on its own so hacking HBOOT is not enough.
[HTC Wildfire S] heavy_metal_man:
here is the file btw, just so you guys can observe it in more detail ;)

file has just been rar'ed so unzip as standard. was set to store not compress :)
[HTC Wildfire S] theq86:
Well, I guess the answer to all is just 42.

dec42 = 0x2A

this must be the flag :D

ok, just kidding.

damn we're kind of stucked again. last 2 days and 6 pages really brought us ahead :D

EDIT: lool, we're on page 42, I didn't notice till now :D

EDIT2: "fastbooting" the diag did not work out :D
[HTC Wildfire S] heavy_metal_man:
fail. was worth a shot though.
[HTC Wildfire S] theq86:
well, even for the minimal probability it would work ...

if it had run the diag, we would still need eng sim :D

but I thought of a different attack method. code injection :D
[HTC Wildfire S] heavy_metal_man:
and how would this work??
[HTC Wildfire S] no.human.being:
Yes, there's no header on, it's just "raw machine code". Disassembling it via CodeSourcery works by the following command. When you know the base address where it wants to be loaded, you can probably stick a header to it using "mkbootimg" and then boot the resulting image via fastboot.

We can disassemble the DIAG file using the "objdump" utility supplied with the CodeSourcery toolchain.

arm-none-linux-gnueabi-objdump --disassemble-all PG76DIAG.nbh --target=binary --architecture=armv5te > PG76DIAG.txt

Have fun reading the code though, especially since we don't know where execution begins (who tells us that the first instruction that's executed is at address 0x00000000?) and of course for the processor there's nothing that distinguishes code from data.

Of course for the machine there's no while-loop, no for-loop, no if-condition, no switch-case. There's just "condutional jump" and "unconditional jump". :D

Grab a buffer whose upper bound is not checked and make it overflow (e. g. by sending a "very large Fastboot packet" via a customized Fastboot utility) so much that it eventually hits a code segment that will later be executed. It's a very common kind of attack and there's certainly vulnerabilities in the HBOOT one could use for it.
[HTC Wildfire S] theq86:
well, probably not at all. the theory is to inject a code into a running code. not sure if that would work. and we still had to find out which part of code in the diag sets s-off.

I hope we find a way to access the nand in a more "normal" way
[HTC Wildfire S] pihug12:
theq86 posted the MD5 of the first dump he made (which didn't have the right size) and I'm not sure if he posted the MD5 of the correct one then.

I swear I saw a link to download the dump of his radio but I can't find it anymore. :confused:

HBOOT-1.08.0099 + RADIO-7.53.39.03M (no.human.being)

50.069.504 Bytes = 47,75MB

MD5 : 48349adaf977ebd48ae6c48fe1f0bc35

HBOOT-1.09.0099 + RADIO-7.54.39.28M (pihug12)

40.632.320 Bytes = 38,75MB

MD5 : 1E91D5EA539C8C4106E9286BFDE210EB

Somebody can check the hash of his radio.img too ?

94,3% of the file is "FF". I'm kinda sure we could find some useful informations in a dump of a S-OFF device (with the correct HBOOT/RADIO) without having to wait for a XTC-Clip.
[HTC Wildfire S] theq86:
Yes, I deleted the link. I thought 2 hours are sufficient for downloading. I even don't want everyone to know my deepest radio secrets :D

here my radio md5sum (the correct radio)

6505299364424f0410591fc6c65a2b8f *radio.img

40.632.320 Bytes

Well, md5sum is good to check equality, but not the diffs.
[HTC Wildfire S] no.human.being:
It's not that unlikely at all.
[HTC Wildfire S] BeciMester:
Try 0x40000000 ;) it suddenly makes a lot more sense.
[HTC Wildfire S] theq86:
-----BEGIN PGP SIGNED MESSAGE-----

Hash: RIPEMD160

Well, I'm tired. Maybe tomorrow we will have a sudden

inspiration.

:D

-----BEGIN PGP SIGNATURE-----

Version: GnuPG v2.0.17 (MingW32) - GPGshell v3.78

iQIcBAEBAwAGBQJPTs2kAAoJELvT13/cLZuQqyIP/A1CQnC+yuLqFT0fKHN7bWLM

mYEl3TiMki7tUB3+mELLeIH9UwZDcs7HQ0azJU0iSBvZcXhKgYIRWcevDsNvtgFQ

74u+8r6UnVx+hd9wSp2Zw33pTNkUjfz0Lk9AtkQJtrHxcr4of8FF5knQ0+Kr6igr

YTHQ55Opv3VqKxNIOMINpxPO/QA41CcbGP1bUXpKCKumOVBEZdPKYgCdRDo9xC9E

ta4s/2XBOoIC93nL3l6luKZNKMsYNRqiIPfJ5LKPVHPbKR1dAj0PmhXFhDNrWwOG

iBjhLY2J/gLnBkFAnukj1sVoQ7ZrAOX3AWpmMOEPH620QxHjA4VSPfxO3MbouKne

LE10oQM6/cF4HLXHVMI3wyq0SGyigOUXe7BKeaNNO4u0iHdAZUfzz/1hqT+m1NwK

fPgH3dnHwIYG5/5UQlYLFUkGgVnHonfzdXh6p14ss5qFcUgu4Y2GkoVkbOULOwa2

yF5BpDjNVhplCsSNW8WqEj5MkKnzeJYmpBVqokeBnaJWUZMTtDzC9FJrW5YeSCB7

uoUyBwUXB+PFLPgAr0pXiRFTlsH2fuKOEzjT9c/maLKu8UICxe+bWb08hzKcFE8r

bIPL/0nG8Z949sy5uWhaS+4vLiXn73xQNu2UT69q26HsW+zSHtMkfK0K5XszCfVA

QHnzJ9QhRVEVbjFaSAmf

=m5MY

-----END PGP SIGNATURE-----
[HTC Wildfire S] no.human.being:
So you think it's loaded to 0x40000000 (RAM) before being executed? And then the first instruction that's executed is from 0x40000000 (RAM)?
[HTC Wildfire S] MrTaco505:
Here's a copy of an 1.08.0099 hboot and radio if you need it. I don't know if this might help.

http://www.sendspace.com/file/ze5o32

EDIT: this is an official copy of the .img files from an ruu
[HTC Wildfire S] no.human.being:
Ok, pihug12 and theq86 sent me their Radios and all the differences seem to be located between 0x024c0010 and 0x024d001f.

So definitely no "device identifier token" (which is probably generated as a hash of "something" with this "something" probably involving the device's serial number) and no "unlock key". So the "unlock key" is just verified by HBOOT, then the Radio flicks some flag and that's it.
[HTC Wildfire S] theq86:
At this time I not yet had the phone. so this event must be something that not a user has done.
[HTC Wildfire S] BeciMester:
Actually I might be wrong there. If you look at offset 0x300, there's stuff that's very similar to the hboot start. Objdump it from offset 0x3ffffd00, thus it's moved back in memory 0x300 bytes and it looks even better. ;) After that, the first readable piece of code (and I believe the entry point) is at address 0x40000410 (this part has loops, it looks like it's copying stuff somewhere), and the bulk of the code starts from address 0x40000800.
[HTC Wildfire S] no.human.being:
pihug12 said it might be the day he booted the phone for the first time (which might make sense to store for warrenty reasons).

So either "someone" has booted the phone before you got it (possibly it was returned to the vendor because the first customer didn't like it and then got shipped to you) or the theory is wrong and the date is for something else (when HTC has programmed the firmware to the phone or whatever).

You must certainly crunch assembly 24/7 to recognize such things, are you working as a system level programmer? :D
[HTC Wildfire S] theq86:
It was no returned phone. Nor was it an exhibition model. But it could be, that it has been booted before in order to update the firmware. I never started with a 0.9 hboot, I had 1.03 from the beginning.

so it might be true
[HTC Wildfire S] BeciMester:
Haha I wish. :) I coded demos on the C64 when I was 14-15, I had to learn to "think" assembly.
[HTC Wildfire S] theq86:
I also had a C64. But it was programmed with BASIC.

or did you program it on the very hardware level?
[HTC Wildfire S] pihug12:
No, I was wrong. I just checked : I got my phone in the end of november. I don't know what this date is. Maybe the day it got manufactured ?

Don't you think It could be interesting to have a dump of a S-OFF phone (with HBOOT-1.09.0099 + RADIO-7.54.39.28M) to check if there are changes before 0x024c0010 ?

If your guess is true, then we could find the address we are searching easily.
[HTC Wildfire S] no.human.being:
Of course. We already know the differences between "pihug12 <--> theq86", so if we got a hypothetical "S-OFF phone", we might compare "S-OFF phone <--> theq86", then we'll find differences as well. Then all the differences that are both between "pihug12 <--> theq86" and "S-OFF phone <--> theq86" we can ignore since the first two are both S-ON. I think there will only be few differences that will occur between "S-OFF phone <--> theq86" but NOT between "pihug12 <--> theq86" and one of those will be the secu_flag.
[HTC Wildfire S] theq86:
The best would be someone also having HTC_EU firmware. Everything else could cause confusion
[HTC Wildfire S] BeciMester:
OK I should have copped on earlier. The PG76DIAG file is basically an engineering hboot, version 0.81.2000.

Well, heavy_metal_man is S-OFF... ;) Since the state of the secu_flag doesn't change after S-OFF, can we get him to flash the newest radio and dump it? Would that help?

As close to the hardware as possible. ;) A much much simpler machine than the WFS. :D Direct access to the screen memory, hijacking interrupts to do your bidding etc.

Edit: I'm packing it in for tonight lads, I'm showing signs of sleep deprivation. :o Just some food for thought: if I remember well and the radio update doesn't change the secu_flag, how come it's not overwritten when flashing? The logical answer would be that it's not in the radio area. :confused: Are we sure that every corner of the NAND is mounted?
[HTC Wildfire S] no.human.being:
@BeciMester: You were the one who found the function that returned whether the secu_flag was on or off in the HBOOT image. However, if you remember, I asked you how you'd know that this is the only relevant function, as there are lots of functions in the HBOOT which do the same (following the pointer to a pointer, then reading a word and returning the least significant bit).

If you're actually sure that this is the right (and the only) subroutine to patch in the 1.08.0099 and 1.09.0099 HBOOTs, we might do the S-OFF now, even though it'll only be "Revolutionary S-OFF" (HBOOT patched) and not "xtc-clip S-OFF" (Radio patched).

What do you think, is this what we should do?
[HTC Wildfire S] theq86:
how can we do it NOW?

hboot is also in the radio image

however, I think it's not the real deal
[HTC Wildfire S] no.human.being:
Yes, but we don't know where the actual secu_flag is. However, BeciMester claimed to have found the function that is called whenever some software wants to know whether the phone is S-ON or S-OFF.

HBOOT, for example, calls this function, then does a conditional branch based on the return value branching either to code that's writing "S-ON" to the screen or to code that's writing "S-OFF" to the screen (remember the first line is "MARVEL PVT SHIP S-ON").

Given that this exact function is always called whenever any software component (e. g. the Android kernel before writing to "/dev/mtd/mtd3" or the HBOOT before flashing a "PG76IMG.nbh" to the recovery partition) needs to know whether the phone is S-ON or S-OFF, we could modify the code of that function to always return the value 0 (which is S-OFF).

The actual flag won't have changed but the only function that checks the flag has been patched not to check it but always return zero. Result will be the same (given that the secu_flag is really always checked by calling exactly this function). :D

Revolutionary does it this way. They don't patch the Radio, but only the HBOOT. At least they state so on their website.
[HTC Wildfire S] theq86:
Well, the one radio is not the other radio.

/radio (the partition) holds the radio that is flashed, the hboot that is flashed but it also holds a part of the firmware that is never touched.

---------- Post added at 04:20 AM ---------- Previous post was at 04:17 AM ----------

but therefore we still need to find a way to write to the nand.

and why do hboot s-off, if someone can help us with a clip`?
[HTC Wildfire S] no.human.being:
I think there's a "nandwrite" utility in CWM. Obviously it can write to the NAND as NANDroid backup uses it.

Ok, if we get that image of course we'll patch the Radio.

However, we'll have to do this again for every Radio version that's available, so we'll have to find more people who are S-OFF with different Radio versions on their phone.
[HTC Wildfire S] theq86:
okay, again. because I don't get it ...

real secu_flag is on /dev/mtd/mtd7 aka /radio

hboot is on /dev/mtd/mtd7 aka /radio

so what's the practical difference? We have no way of selective access yet.

---------- Post added at 04:30 AM ---------- Previous post was at 04:24 AM ----------

That's what I said some pages earlier, too :P

Well, I doubt that secu flag is in range of the radio files that are flashed. and first, we should concentrate on the latest radios. people can downgrade after s-off either
[HTC Wildfire S] no.human.being:
Well the entire radio partition (!!) changes size when you flash another radio and the "WiFi related stuff" moves around, the HBOOT moves around, all the other partitions move around too.

So if we were to patch the HBOOT we'd certainly have to provide different patches for different Radio versions, since flashing the Radio will move the HBOOT to another physical address.

Right. The entire radio partition is around 40 - 75 MiB large (depending on version) while radio images are 24.5 MiB large. So there's a lot in the radio firmware that's not touched while "flashing the radio".
[HTC Wildfire S] theq86:
and another fact is, that radio always begins @0x00000000

so regarding the fact, that radio partition changes size and offsets of the radio parts, I assume that the secu flag is one of the first megabytes because there is guaranted, that it never changes (as I assume)
[HTC Wildfire S] no.human.being:
We already know where the function is that checks the secu_flag, but we have no idea where the secu_flag is.

Just looking at the function doesn't tell us where the flag is, since the following is done:

- The "real" secu_flag resides in NAND (in the Radio firmware).

- When the phone boots, the Radio firmware gets copied into RAM by "the controller" (this is a "hardware thing" so we can't look up how this is done, there is no software that's doing this, it's "hardcoded logic" that we don't know and cannot alter) since code can't be executed from NAND but only from RAM. Of course this "copy" in RAM will also include the secu_flag.

- There's a function in HBOOT that checks the "copy" in RAM and returns its value. BeciMester thinks that whenever any part of the firmware has to know the status of the secu_flag, this exact function is called.

Now by looking at the HBOOT we only know where the "copy" of the secu_flag lies (actually it's more difficult .. the Radio actually contains "a pointer to the copy of the secu_flag" and we only know where that pointer lies .. of course this pointer is also just a "copy" of the "original pointer" in NAND) and since we have no way of finding out how this "copy" is crafted, we can't use that information for finding the "original".

However, we can change the code that checks the "copy" so that it doesn't really check, but always returns 0.

Now you understand why patching HBOOT is easier than patching the Radio? (No the patching is actually not easier, but with the HBOOT we already "know what to patch", at least if BeciMester is right that this function is always called every single time the secu_flag has to be checked, but we "don't know what to patch" with the Radio.)
[HTC Wildfire S] theq86:
yes, this is the reason why it would be best if someone we have a radio dump from would clip the phone. so we have a direct comparison and only the xtc clip changes.

I guess it's not too hard to find someone. At least not so hard to give up the radio patching :D
[HTC Wildfire S] no.human.being:
Yes. But you see that we could patch the HBOOT to S-OFF "now" (as long as BeciMester is sure that this is the only function that checks the secu_flag and knows its address in both HBOOT 1.08.99 and 1.09.99). We got everything we need to do it. There's really nothing left that could come in our way (apart from some really "weird kernel twitches" that no one could have expected :D ). So the chance of successfully completing this hack to S-OFF has risen to approximately 99.98 % at this point. :D
[HTC Wildfire S] theq86:
everything except a way to write the changes ;)
[HTC Wildfire S] no.human.being:
"nandwrite" will do it. It's what is used for NANDroid backup. Personally I've never restored a NANDroid backup but I really think it's gonna work. :D
[HTC Wildfire S] theq86:
so what is "nandwrite"? is it a concrete binary or just a way to express cwm is able to do it? :D

edit: I found it, it's a binary within CWM

aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaand what did I say? It's like flash_image origining from the mtdutils. :P
[HTC Wildfire S] no.human.being:
Still any doubts? :D
[HTC Wildfire S] theq86:
I tried to make nandwrite writing my boot partition. seems not to work.

nandwrite -s 0x02BC0000 /dev/mtd/mtd2 /sdcard/boot.img
nandwrite: not enough space in MTD device
[HTC Wildfire S] no.human.being:
Well if we want to write the ENTIRE partition (sequentially) then we can do it via the standard fopen/fwrite/fflush/fclose API. Just have to find a way or erasing the partition before as this API doesn't allow to overwrite.

It was at 0x00000a00 physical on the Desire S, so that was really "early". CID was at 0x00000200 on the Desire S, so it was even earlier. And SIM-lock related code was at 0x00080000 to 0x000807ff on the Desire S. The GFree exploit that patches all this is open-source.
[HTC Wildfire S] theq86:
I now wrote "AFFEAFFEAFFE" and backup and see where it comes.

maybe the @start parameter is relative to the device and if we want to write to the beginning we have to use 0
[HTC Wildfire S] no.human.being:
Needs further explanation.

1. You've done what?!

2. @start parameter to what?! kernel? nandwrite? ...?
[HTC Wildfire S] theq86:
Here I used 0x02BC0000 (what is my /boot starting offset)

-s is the parameter that tells nandwrite where to start.

Obviously, the bootimage was too big to be written from 0x02BC0000 to end.

and then I thought, maybe the -s param does not want the starting of the partition, but the starting within the partition.
[HTC Wildfire S] no.human.being:
Yes of course. "nandwrite" will never see the physical addresses. Only the kernel does.
[HTC Wildfire S] theq86:
strange behavior...

echo "AFFEAFFEAFFE" > affe
nandwrite -p -s 0 /dev/mtd/mtd2 affe

and output from offset 0 of boot.img:

41 46 44 40 41 40 44 01 40 42 06 00 00 00 00 00 | AFD@A@D.@B......

am I doing something wrong?