yashsingh1/xdaforums huggingface dataset:
[HTC Wildfire S] no.human.being:
Writing it back won't be too hard once you got the NAND erased without killing Android. :D

However, your CID will most likely occur in more than one place. There will be one place where YOUR CID is stored and there will be other places where CIDs are stored that HBOOT will use for comparison. Obviously, you'll only want to change your very own CID.

We are. Basically we found a way to write to the phone NAND even though S-ON is in place. However, this involves very low (device/ioctl) level access to the memory. Now it's all about finding three offsets (one for CID, one for secu_flag, one for SIM-lock) in the phone memory. We're disassembling the HBOOT image for this purpose. The addresses in there will probably be RAM addresses and once we have these, we'll have to find a way of mapping these to the addresses on the persistent storage (mtd devices).

Afterwards, I can probably get the exploit finished. The problem is that it involves erasing the phone NAND while the phone is booted (it has to be erased as this type of memory cannot be overwritten in-place) and we don't know whether Android will continue running from the RAM with an erased NAND or whether it will crash (which would result in a bricked phone as we'll have no way of getting the NAND contents back to the phone). It will "probably" continue running from the RAM, but it would be more "secure" to change the mount point of "/system" (and others if "mtd3" is not the only device we have to touch) to a loopback device over the dumps we have performed first. But for some reason, Android won't change the mount point.

That won't neccessarily prevent us from successfully patching the phone, but it increases the risk of bricking the device in the progress, so I'd prefer to get this done also.

However, I don't want to promise a "release date" yet as I don't know how long it will take to analyze the HBOOT to find the correct offsets. In this context, I'd like to show my sincere appreciation for all of you who are bringing this project forward.
[HTC Wildfire S] sythe179:
Release date: before we quit.
[HTC Wildfire S] d33ps1x:
Do you need another dump of an S-OFF system?
[HTC Wildfire S] no.human.being:
We will have to find where HBOOT checks the device security. The memory dumps of distinct phones are far too different to be of any use. Finding correlation is almost impossible at this level.
[HTC Wildfire S] BeciMester:
Actually, I'd like to look at a RAM dump of any device, as I don't think the hboot is changed on an S-OFF system, it'll still check the flag but finds that it's off. I want to see those addresses outside the hboot area that the program points to, I reckon they're populated at boot. OR I'd like to see one of those 'loading tables' I linked earlier.

Desire-Oxygen2.3.2 | WFS-stock
[HTC Wildfire S] rozokr3w:
I've S-OFF my A510e - WITHOUT XTC CLIP - From Virginmobile canada (sim card) hboot 0.90

I flashed an EU rom a while ago so i guess it debranded my phone, So when i tried to unlock the bootloader via htc dev i couldn't update my hboot. Virginmobile is a branch of bell but the file didn't work, it told me that i didn't have the right model. So i tried the EU one since i did flash my phone with a EU RUU but again same thing, so the message was different, i can't remember what it was but i was something like i was already up-to-date.

Then i saw a post on XDA, someone had the same problem as me. I manage to get the two zip file in the TEMP folder that the .exe use to update the phone, rom_1 and rom_2. i renamed rom_1.zip to PG76IMG.ZIP and after the reboot i was S-OFF. i never flashed rom_2.

is that of any help ?
[HTC Wildfire S] no.human.being:
The HBOOT is not changed by turning the phone S-OFF that's right. However, the NAND (not RAM, we're currently able to dump persistent storage only) contents of two distinct phones with identical Android/HBOOT/RADIO/MICROP versions will be entirely different, even if they are both still S-ON. The phones are probably programmed on the file system level instead of the block device level and the file system is doing some (random?) allocation strategy. Would explain why the NAND contents seem to be vastly different on the block device level. You won't see anything useful by doing a comparison at this level. The contents may have identical meaning on a higher level when interpreted, but the data will probably be scattered in entirely different locations at every single specimen. So don't expect anything useful to be discovered at this level. It's just a big mess.

So all I wanted to say is: Dumping the NAND of two "identical" phones (one S-ON, one S-OFFed say via xtc-clip) won't yield anything useful as the phones will have entirely different NAND content even before one of them was S-OFFed. It was my first idea to do it this way, but it doesn't yield anything useful. You probably won't find two phones with similar NAND contents. Only thing that might be useful would be dumping the NAND of a phone, then S-OFF it via xtc-clip, then dump it again from the same device and do a comparison.
[HTC Wildfire S] hahahafr:
What we should have is a dump of an S-ON phone. Then a dump of the *same* device but S-OFF this time. Then we compare. Profit??
[HTC Wildfire S] sythe179:
Nice job repeating what he just said.......
[HTC Wildfire S] no.human.being:
Actually it depends.

As far as I know, xtc-clip will actually change the value of the secu_flag, but Revolutionary (and predecessors AlphaRev/Unrevoked) will patch the code that reads the secu_flag to always return zero, while the actual value of the flag in memory stays untouched. So you may not be able to find the code that reads the secu_flag on a phone that has been S-OFFed via Revolutionary, as the software is probably achieving S-OFF by tampering around in exactly that procedure's code.
[HTC Wildfire S] BeciMester:
Well, are we happy with the 'Revolutionary way', ie. patching the hboot code? I could do that right now. If you figure out a way to write it back in place, it can be done today. Maybe look for a byte pattern that's unique to the hboot in the dump your program creates, and copy the new code over it...?

If we decide we want to go the whole nine yards (flip the actual flag) that'll take longer (no idea how much longer).

Desire-Oxygen2.3.2 | WFS-stock
[HTC Wildfire S] no.human.being:
I can principally dump any mtd device, patch any byte sequence in it, erase the NAND (*), put it back on.

(*) If we manage to build this tool for erasure. I haven't tried yet. Don't know if all the dependencies will build. If we can build it, then I can call it from my code before writing the dump back.

So principally, if you know on which mtd device the HBOOT is located and if the offsets on the device are the same as in "your" patch (or you can tell me how to map them), we can probably get it done in the next days.

EDIT: This is the latest source and binary of my exploit. If you know where to patch, please modify the "patch(...)" function. If you know how to build the erasure tool, please do so and tell how you did.
[HTC Wildfire S] sythe179:
So....guess I should start this course of embeded systems security and protection I just got in?...
[HTC Wildfire S] humzaahmed155:
Will Erasing everything BUT Android help, like if you mount the file system to linux and work around Android?
[HTC Wildfire S] d33ps1x:
Instructions and you shall have your info.
[HTC Wildfire S] *se-nsei.:
@no.human.being

Sorry, been very busy lately.. I will update the first post very soon. What would you like me to put there?

Thanks in advance. Hope development is going smoothly!
[HTC Wildfire S] hahahafr:
If I understand correctly we currently have 3 potential way to have S-OFF.

1. Compare the partition of the same device before and after an xtc-clip S-OFF

2. The hboot patching thing, the "revolutionary way" without touching the actual flag

3. Miraculously find the offsets manually
[HTC Wildfire S] sythe179:
All using no.human.being's exploit to re-move and replace the said partitions involved.
[HTC Wildfire S] hahahafr:
Dumb question: why can't we just erase the nand pages we want and rewrite them instead of the whole partition? I read somewhere that nand flash has 4kb pages (can't modify less than that).
[HTC Wildfire S] sythe179:
Something I asked a while ago.

But I got a responce about yaffs file systems not being able to be changed like that.

Lucky these are yaffs2 file systems....

Well, no.human.being will tell you why I guess.

/edit

BTW... What's at these locations:

D250

13f097a

{ffffffff@26}
[HTC Wildfire S] humzaahmed155:
Nice job copying what I just said :-\
[HTC Wildfire S] BeciMester:
Last night I was doing some exploration on a live WFS. If i do

# cat /proc/mtd/

it tells me the boot partition where the hboot should sit is mtd2, but if I dump it with

# cat /dev/mtd/mtd2 > /sdcard/mtd2.img

it's not even similar to the .nb0 file that I'm disassembling. Is it down to yaffs, or is it stored compressed? EDIT: do I have to use no.human.being's tool to dump it?

Btw I found a great page with source code to do nanddump/nandwrite. :)

Is it possible to dump RAM content??

(I'm on my phone...)
[HTC Wildfire S] no.human.being:
No, I don't think you have to. There's nothing special about it. It's just that on "stock" Android "dd"ing/"cat"ing the mtd devices failed without an obvious reason (said the device "had a negative size" or something like that), so I wrote a routine that does "fopen" on the device and then copies the blocks and it succeeded. Basically, when cat/dd works for you, there should be no need to use my tool for dumping. Both methods should yield the same results. In the end, I just want to provide an "all in one" solution for dumping, patching, erasing and writing back so that "non-dev" people don't have to mess around too much but have an "automatism" that does it all.

I'd suggest you to use "dd" with a resaonable block size (say "bs=4k", my tool uses 4096 byte blocks) though, as it will greatly improve speed and probably reduce the memory wear by ensuring that every block is written just once. When you write in chunks that are smaller than an erase block (and dd usually defaults to very small block sizes), the NAND might write the first chunk into the block, then the write command for the next chunk arrives and it will read the contents of the erase block, erase the entire block, integrate the second chunk, write the entire block, etc. until the block is "full". This could cause unneccessary wear on the memory of the "target" device (so on the SD card if you're dumping the mtd device to SD card) and of course it will take longer.

Should be possible via JTAG. Don't know if it's possible via software. Probably not, as Android makes use of memory protection.
[HTC Wildfire S] sythe179:
Think he ment like this....but tell me if I'm wrong.

Normally -

If sec_flag = 0@ffffffff

Do stuff

Else

Do stuff we like

End

Patched -

If patched_val = 0

Do stuff

Else

Do stuff we like

End

But again...probably wrong.

(Not making any guesses but who's to say they dident make the value a 1.. would throw us off...)
[HTC Wildfire S] BeciMester:
It's even simpler: we don't mess with the part that checks for the flag, we skip it completely. As far as I can tell, the original part returns 0 in R0 (register 0) if the flag is off, and something else if it's on. So all we have to do is overwrite the first few bytes of the 'checking part' with the assembly equivalent of 'return 0;' so the whole 'look-at-hidden-location-and-see-how-the-flag-is-doing' part doesn't happen, the answer will always be 0. Even the hboot itself will report S-OFF even though we don't even know where the actual flag is. Fake S-OFF ftw. :D

(I'm on my phone...)
[HTC Wildfire S] hahahafr:
It will also affect SuperCID and simlock, or just the secu_flag?
[HTC Wildfire S] BeciMester:
Just the secuflag for now, the rest needs further reversing.

(I'm on my phone...)
[HTC Wildfire S] ONeill123:
And i think it is easier to change the rest with s-off?!

But now concentrate for the solution to get s-off :)
[HTC Wildfire S] no.human.being:
Yep, in principle this will work.

I first thought that the Radio might verify the signature of the HBOOT, as I found a site that claimed that the Radio is verifying the signature of the so-called OSBL (Operating System Boot Loader) before passing the control over to it. However, this OSBL is not the HBOOT. The HBOOT seems to be called APSBL (Application Processor Secondary Boot Loader) and it is in turn loaded by the OSBL. So as long as the OSBL doesn't do signature verification on the HBOOT (which is not stated anywhere), there's probably nothing wrong with modifying the HBOOT code.

This is why I was strictly against modifying the HBOOT itself. I thought that the Radio would verify the HBOOT code and would stop the device from booting when it finds a modification. (The Radio is booted BEFORE the HBOOT and it can interrupt the further boot process.) However, as this is not exactly what the site is saying (it just says that the Radio verifies the APSBL, but the APSBL is not HBOOT, the APSBL is what loads HBOOT into memory and we won't need to modify this) modifying the HBOOT is probably a credible method as well. So yes, if it's easier to find the check in HBOOT and patch that, we can probably do it as well.
[HTC Wildfire S] sythe179:
not sure if this is usefull or not..

but during boot,

specificly at bootanimation, it checks for the CID...

D/HtcBootAnimation( 137): Get cid:TELST001

D/HtcBootAnimation( 137): filepath:/system/customize/CID/TELST001.xml

D/HtcBootAnimation( 137): Load /system/customize/CID/default.xml

^from my WFS....

again, not sure if thats useful...or if it was needed to be said at all..
[HTC Wildfire S] BeciMester:
It checks the CID to know which boot animation to display, as you can see it's customizable by carriers. If it's a Telstra CID, that's what you get, if it's eg. HTC__001 like mine, I get the standard green/white 'quietly brilliant' screen.

(I'm on my phone...)
[HTC Wildfire S] no.human.being:
@beci_mester:

Well there is one problem with patching the HBOOT.

You're probably on HBOOT 0.90.0000 right?

My phone for example is already on HBOOT 1.08.0099 and there are possibly still other HBOOT versions around.

Overwriting the function calls that HBOOT is doing to check for the secu_flag will most likely be specific for exactly one HBOOT version. So you'd either have to build lots of different exploits covering different HBOOT versions or you'd have to "select" the one you're willing to support. In the latter case, your 0.90.0000 will probably be the worst option ever. It's probably the oldest HBOOT revision that's around on the WFS and "downgrading" HBOOT is probably unsupported.

So I'd really prefer to patch the secu_flag itself, as it resides in a fixed location.

Of course, we could overwrite the entire HBOOT with one specific version that we patched, but that would require us to ship an HBOOT image with the exploit and HBOOT is probably copyrighted software.
[HTC Wildfire S] BeciMester:
Yeah I thought about that. To be honest I haven't looked at the differences between hboot versions yet, but now I know what to look for in the new ones. :)

I've found a site that claims the boot and recovery partitions are compressed on the NAND. I'll have to look into that, hopefully tonight.

EDIT: here's the link: http://android-dls.com/wiki/index.php?title=HOWTO:_Unpack,_Edit,_and_Re-Pack_Boot_Images

(I'm on my phone...)
[HTC Wildfire S] sythe179:
Well, we could make a few versions of the exploit......if it gets to that....I guess....

Or make a script that patches any version by searching through the specific file for the nessisary code....

But not sure about that...
[HTC Wildfire S] BeciMester:
...or just support the newest one, get everyone to upgrade to that, and be done with it. That is, if the newest version is patchable. But why wouldn't it be?

(I'm on my phone...)
[HTC Wildfire S] sythe179:
Not all of the older ones can be upgraded atm.....
[HTC Wildfire S] no.human.being:
Uff. That might make the stuff a bit harder.

That's right.

Well finding the actual secu_flag would be fantastic, but afaik even Revolutionary gave up on that and settled on patching HBOOT. :(

My WFS runs stable @787 MHz btw. I've set 120 - 787 MHz with "ondemand" governor. This should save quite some amount of battery power. If you were able to get still higher freq. you could probably save even more. Mine crashes @806 MHz when running a benchmark app, so I've gone down to 787. Saving battery by overclocking CPU might seem counterintuitive, but there's a phenomenon that's called "race to idle". It makes you save battery by getting the work done quicker on the overclocked CPU so that the amount of time where its clock is maxed out is less than on the non-overclocked CPU and it can get to low-power state earlier.

I'm already curious how much battery this will save.
[HTC Wildfire S] humzaahmed155:
But don't you have to be soff to over clock the CPU or be rooted, temproot didnt work with overclocks
[HTC Wildfire S] no.human.being:
Yes my device is permarooted (but still S-ON). I updated the phone's Radio, then unlocked it via HTCdev, then installed CWM, then Drowningchild's Android 2.3.7 kernel. However, I'm still committed to this "S-OFF" thing, as I'm very much into IT security stuff, so I'm doing it for the challenge.

In addition, I want to help all the people out that cannot unlock via HTCdev because of carrier restrictions.
[HTC Wildfire S] hahahafr:
Thank you, we are à lot in this case. I wish I could help.
[HTC Wildfire S] sythe179:
No.human, and others like you make this possible.

If I was the only one, probably be back at writing your exploit....after learning c#....
[HTC Wildfire S] no.human.being:
Huh? C#?

C# is an object oriented language developed by Anders Hejlsberg (Borland) and released 2001. The language was later acquired by Microsoft for use in their .NET Framework. C# code is compiled into intermediate code designed for execution on a virtual machine. The intermediate code is called CIL ("Common Intermediate Language"), the virtual machine is called VES ("Virtual Execution System") and it is part of the CLI ("Common Language Infrastructure"). It's very very similar to Java, that is compiled into "bytecode", then executed on the JVM ("Java Virtual Machine"). The intermediate codes of both languages are portable and allow you to run the same code on every platform for which an implementation of the virtual machine exists (an execution system for CIL for POSIX compliant systems is developed and maintained by Novell) without recompiling.

The exploits are written in pure C, which is an imperative language that was developed 1969 - 1973 and is directly compiled to native code (machine code) for the ARM processor of the handset. It's a very "low level" language, that does not provide much abstraction from the underlying machine. Exploits usually need to run "on the metal" to achieve their effect.
[HTC Wildfire S] benjamingwynn:
...hasn't htc done this for us?
[HTC Wildfire S] *se-nsei.:
No.

They've still got restrictions on radio and other things. We want full S-OFF so people can retain their warranty.
[HTC Wildfire S] m1ndh4x8r:
no.human.being start making custom roms your a good programmer and can make more mods for gb2.3.5. Thanks for working in Soff but a lot already unlocked using htc dev. soff will be good only if your in a gsm locked carrier like change sim cards :¶
[HTC Wildfire S] csoulr666:
What HTC has done is just unlock the bootloader and that too with some exceptions..... AFAIK no.human.being is doing it as a challenge for him.... this will also help the people who are not able to unlock their bootloaders(software reasons or noobish ones)
[HTC Wildfire S] *se-nsei.:
And what about the warranty? hm?
[HTC Wildfire S] sythe179:
Ok....ill look into c then.

And I wish people would read at least 2 pages back before posting....
[HTC Wildfire S] benjamingwynn:
Okay keep your hair on! I was only asking.
[HTC Wildfire S] csoulr666:
I have a suggestion......we should try look at the unlock codes we got from Unlocking from HTCDev.com and modify them to get an S-OFF........But this method isnt universally applicable as a few WFS models arent supported yet
[HTC Wildfire S] hahahafr:
Thank god no.human.being knows what he's talking about. Reading all the other recent posts here makes me sad.
[HTC Wildfire S] d33ps1x:
Coffee...keyboard...

Sent from my cm7.2 Wildfire S
[HTC Wildfire S] ONeill123:
Hi giys. What is with this thread:

Http://xdaforums.com/showthread.php?t=1457992

He has set s-off using the radio of the htcdev ruu. Maybe we can see the diferences between the real radio and this radio. Or we find a way to downgrade to hboot 0.9
[HTC Wildfire S] *se-nsei.:
Yep, think no.human.being should have a look at this. Anyone able to extract the radio from the HTCdev RUU package for us?

Btw, we've found more reasons for full S-OFF. The HTC unlock doesn't support system memory partitioning.
[HTC Wildfire S] d33ps1x:
Here's the ROM1.zip and ROM2.zip files.

Here are the extracted radio images...

Comparing the two in HexFiend now.
[HTC Wildfire S] humzaahmed155:
I Am prepared to try this, the only thing thats stopping me is the fact that it could brick my phone, and i dont want this to become a paperweight, is there a guarantee that it Wont damage my phone?
[HTC Wildfire S] d33ps1x:
ROFL. Sorry. Just gimmi a sec to recover...Oh..Ouch...That hurts.

Umm...No
[HTC Wildfire S] no.human.being:
The radio images are quite similar in the beginning. The further you get into them, the more different they become. I'd try to disassemble them to see what those differences are in code, as most is probably just difference in memory layout and not in functionality but I'm currently busy with the exams at university.
[HTC Wildfire S] hahahafr:
Take your time. Most of us are student and also have exams in this time of year.
[HTC Wildfire S] heavy_metal_man:
i have an idea

hello guys, my name is Heavy_metal_man and ive stumbled over here from the wildfire forum due to series of long events. to begin with me and some others are trying to find a way to remove the simlock on the htc wildfire (Buzz) http://xdaforums.com/showthread.php?t=1448972 and mostly with no success. i managed to come across this thread and i really like the ideas going on here and would like to help out. i have a xtc clip, and my friend has a htc wildfire s (marvel) if you guys would still want it i can post you those dump files from before and after, in an aid to help you guys find the secure flag, cid and sim unlock.;)

i only have one question, my friend was stupid enough to not ask me first and went to the htcdev bootloader ect to *unlock* so i would like to know if it is possible to flash old hboot and radio ect? if not then i will try and get you guys the dumps anyway but i dont know how much use that will be. hopefully a downgrade will be possible.

if not then if we can find someone close to me with a marvel who is willing to have their dumps taken then we could go down that route. i only ask that if no.being.human or anyone else has any ideas on how we can remove the simlock from our htc wildfire (buzz) with revelutionary hboot s-off then please let us know :) i hope that these file will lead to a decent method for locating the important files are on any htc device. (i know its unlikly but i can dream :rolleyes:) if all goes well i will see my friend with his marvel around the begining of febuary (we live in different countrys :P) and if someone could post a step by step guide on how to do this dump on windows, or pm me then i will help out all i can.

from Heavy_metal_man.

keep up the good work guys :)
[HTC Wildfire S] theq86:
if the phone is s-off, downgrading hboot is as easy as flashing a new rom or recovery.
[HTC Wildfire S] heavy_metal_man:
as far as i know the phone is currently *unlocked* s-on by htc dev.