yashsingh1/xdaforums huggingface dataset:
[HTC Wildfire S] meanmug:
@no.human.being, sounds like my old Ghost Recon days we had a program called GRBoom, it would send an overflow of packets to a game server and crash it, oh what fun. Sry for getting off topic just brought back some fun memories.
[HTC Wildfire S] hahahafr:
Are we sure the partition /mtdblock3 contain the (only?) flag? If we are and the system can support running with a blank partition, then theorically we (nohuman) solved this. Didn't we?
[HTC Wildfire S] BeciMester:
Yeah, the system can support running with a blank partition, but only as much as a heart transplant patient can support being without a heart. All it means it won't die immediately, but as soon as you reboot, it will. :D

Desire-Oxygen2.3.2 | WFS-stock
[HTC Wildfire S] Lt.Win:
Let's reboot the patient LOL

via HTC Wildfire S powered by CM7.2
[HTC Wildfire S] recluse2:
Learned more from this post about android security than I have from cruising these forums for weeks. Thanks!
[HTC Wildfire S] sythe179:
ok, for telstra users of this phone, dont know if this is good, or bad news....but after ringing telstra, and HTC, this is what i have....

19:53:52 [Jefrey] :
As per checking in our system, there will be an upgrade for HTC Wildfire S for Telstra but there's no exact release date yet.
19:54:02 [Jefrey] :
But it's going to be soon.
19:55:16 [Jefrey] :
I'm sorry but for now, there's still some test or calibration for the Telstra end users

.

19:57:47 [Jefrey] :
As for now, we're still doing some bug fix on the update because we want our users to receive the update bug free.
19:58:08 [Jefrey] :
Please bear with us more for the update will going to be available very soon.

20:23:04 [Jefrey] :
The upgrade is already there but there's no exact date yet of the release.

20:24:41 [Jefrey] :
The upgrade will be available tomorrow or the next or next week but for sure it will not going to take 2 months.
[HTC Wildfire S] Lt.Win:
What. -.-

via HTC Wildfire S powered by CM7.2
[HTC Wildfire S] sythe179:
So....if your phone provider is Telstra, you will have to wait from anyware from tommorow to march for your OTA update....

(2.3.5 software update)

And, Telstra is not going to be supported by htcdev, they signed an agreement with HTC that they will not be "Joining in with that organisation's actions due to warranty violations for End-Users"

Well, that's what two people from Telstra sales, and one from HTC general support....
[HTC Wildfire S] no.human.being:
Well theoretically.

What we have is basically the possibility to dump, patch and image back any of the partitions (mtd0 to mtd6). I have chosen mtd3, as it is what's mounted as "/system", is itself highly protected, so probably it's the right target. I'm not sure however, so if you have any indication that the security flag is on a different partition, please tell me. On the DS, it's on partition 7, but the WFS has a different partition layout that only has partitions 0 to 6. I'm quite sure that all of them are on the same partition and that there is no "redundancy" of information.

On the DS, we have to patch at 3 different offsets to obtain SuperCID, S-OFF and SIM unlock respectively. As far as I know, any of the S-OFF tools that are available patch all three, they are never patched individually, so I will patch them all as well, as something like a "SIM locked S-OFF phone" or an "S-OFF phone without SuperCID" might be something that was never designed to exist and the HBOOT may possibly freak out on it.

What we need however, are the offsets where we can patch these values. On the Desire S, they are as follows:

- CID: 0x00000200 - 0x00000207 (length: 8 bytes)

- S-OFF: 0x00000a00 (length: 1 byte .. well the actual secu_flag is just the least significant bit of that byte, so I'm reading the value of the byte from the original, flip the LSB, then write that value back .. probably there is no useful information inside the remaining 7 bits, but I'm keeping their original values around just in case)

- SIM-Lock: 0x00080000 - 0x000807ff (length: 2048 bytes)

On the Wildfire S, they are different. If you read at 0x00000200 - 0x00000207, there is binary information there, which means no printable ASCII character. The CID, however, is stored as an ASCII value, so there's no CID at that offset and it's definitely the wrong place to patch. The other offsets are almost certainly different as well.

After the patching process, we'll need to clear the partition on which we performed the patching (so most likely mtd3), as NAND memory cannot be overwritten, it has to be erased, then written again. The erasure can be done via "ioctl" (I/O control) calls to the Android kernel. I'm still uncertain about some of their semantics, but I'll figure this out. After the partition is blank, the patched image can be written back to NAND. After the NAND contents are restored from the image, we should be able to shut down the phone, take the battery out and put it back in (to ensure that the contents of volatile memory are lost), power the phone up again while holding the "Volume Down" key to start it into HBOOT and see those all-important letters saying "S-OFF".
[HTC Wildfire S] sythe179:
Just checking, no.human, you did read my post three pages back about yaffs2 right?....just making sure...
[HTC Wildfire S] no.human.being:
Yep I did. That's why I'm so confident that the information resides at a fixed address. Thank you very much. :D

It's probably worse. It might die as soon as it's trying to access any system file and we can't really be sure when this access becomes imminent until it actually occurs and if it occurs, most likely it's too late and the phone will be "dead".

However, I really like that analogy. It just brought me to a brilliant idea. Let's implement a cardiopulmonary bypass for our phone. :D

What this means is: Maybe we can create a RAM disk (TempFS), copy the files from "/system" over to that disk, then mount that replica as "/system" so that "mtd3" is not mounted when we're doing the "surgery" (erasure/writeback thing, formerly known as "S-OFF Exploit Step 3"). As long as we're messing with "mtd3", the RAM disk will just take over the work of "mtd3".

Of course, if the system crashes during the process, the phone will still be dead, but at least "normal" access to system files could continue while our work is in progress. I'm not sure if we have the amount of RAM available that's neccessary to do so. If we could allocate 272.6 MB for the RAM disk, we'd be on the safe side, as that's the physical size of "mtd3".
[HTC Wildfire S] :
Could we not blind mount and ext partition on sd card too for system. We just need to crack open a ruu, get the system img and copy the files inside to the 2nd partition, then when we mount were good. Also if someone finds jtag we will be able to fix any brick
[HTC Wildfire S] hahahafr:
The WFS has 512MB of RAM. Same size as his 512MB of NAND Flash.
[HTC Wildfire S] no.human.being:
Yeah, but Android occupies a lot of ressources, that's why I'd like to put it onto the SD card.
[HTC Wildfire S] BeciMester:
Your output says it failed to mount as /dev/block/loop0, now on my WFS there are already loop0-loop13. Is that the problem, or I'm misinterpreting it?

Also. I'm hot on the heels of the secu_flag. I started from the subroutine that displays either S-ON or S-OFF on the white hboot screen, and I believe I've found the call that actually checks if the flag is set or not. I've traced the program to a location where it calculates an address that's outside the hboot, and jumps to it. So I need to know what's located right after the hboot in the ROM (is it the radio?). Could it be found out from your /system dump? If so, I'll make one myself using your program. Any ideas appreciated.

(Yes, I know I should be getting ready for my next exam, but I can't help myself. :D)
[HTC Wildfire S] no.human.being:
The "-o loop" should cause it to use any loop device that's currently not in use for mounting the image. On my computer there's loop0-loop7 and if I use such a command to mount an image of a drive, it uses the first loop device that's available (e. g. loop0 if I'm not using any of the devices yet) and mounts the image using that device.

That sounds very interesting. Where did you find that routine? Did you disassemble the HBOOT image? If so, which disassembler did you use and where did you get the HBOOT image from?

Dito. :D
[HTC Wildfire S] sythe179:
From what I have, there's over 60 loop devices, and it uses a fair few at any one time (curse of enbeded systems), and I pulled this out of a file I got, might help, night not.

# mount mtd partitions
# Mount /system rw first to give the filesystem a chance to save a checkpoint
mount yaffs2 mtd@system /system
mount yaffs2 mtd@system /system ro remount
mount yaffs2 mtd@userdata /data nosuid nodev
mount yaffs2 mtd@cache /cache nosuid nodev
[HTC Wildfire S] w()$k:
35% disassembled with IDA 6.1 hboot_1.08 View attachment hboot_1.08.0000_7c2ddb69cf.rar

to be continue...
[HTC Wildfire S] no.human.being:
Errm .. it's a binary file. Was expecting some kind of "*.asm" or something similar.

But nonetheless, thanks for your enormous effort. Disassembling with IDA is a real pain.
[HTC Wildfire S] csoulr666:
Small question...... why don't you guys disassemble the ENG HBOOT too???? Maybe it will help
[HTC Wildfire S] sythe179:
Maybbe its an outdated hboot, and we know its pached to not look for the flag, not tell us where it is?...
[HTC Wildfire S] BeciMester:
I started working on the hboot 0.90 which my phone still has. I'm reluctant to upgrade in case they patched something in the new hboot that makes finding the secu_flag even harder. Got the hboot file from the RUU version 1.30.401.0 in Football's thread. Once the image is extracted it can be processed directly, it's not even compressed or encoded or anything.

As for a disassembler, following this tip I first looked at the GNU binutils (arm-linux-gnueabi) that I installed in Ubuntu 11.10 from the Software Manager. I started messing with it but I couldn't get it to disassemble correctly, it always exits with a segmentation fault error. Then I signed up for CodeBench Lite for Windows and that's what I'm using now: I exported the strings from the hboot into a text file, the disassembled code into another (I handle these with Notepad++), and I use Frhed for hex browsing. I have a few ARM opcode sheets open for reference. It's clunky as hell, but it works. :D Still open to suggestions that would make my life easier.

I also downloaded the IDA 5.0 free version, which naturally doesn't support ARM :rolleyes: and the IDA 6.2 demo, which accepts .elf files that I can generate with objcopy, but only lets me load them to 0x0 instead of the offset I need; if I relocate the .elf with objcopy it doesn't load it at all, and as a bonus it keeps spamming my working folder with a series of ~150MB files until I shut it down from Task Manager. :mad: Otherwise it does look nice, but it's not very useful for me in the current form.

@w()$k: this may be of help for you. I did manage to figure out that the hboot image gets loaded from 0x9d000000 in memory, as it has a lot of hardcoded addresses and once I relocated it with objcopy, everything started to fall into place :). Try to load it into IDA from that offset (it seems possible, the option is there in the demo but it's greyed out), it should be a hella lot easier from there (assuming the new hboot you're working on is still located at the same place, but I can't see why it wouldn't be).

The following refers to the 0.90 hboot:

The string " S-OFF" (note the space before it) is located at 0x9d070168. If you recall your hboot screen says "MARVEL PVT SHIP S-ON". Now, right after printing "SHIP", a decision is made at 0x9d034c14 whether to print " S-ON" or " S-OFF": a subroutine at 0x9d008698 is called, and if the answer is not 0, it branches to the part that prints "S-ON", otherwise it goes on to print "S-OFF". This 'decision part' (0x9d008698) is called from 22 different places in the hboot.

This is where I start to hit walls as stuff outside the hboot area is referenced.
[HTC Wildfire S] w()$k:
I`m know it, but thanks.

Who really know what exist after hboot in mem at offset 0x9d080000?

in hboot much more reference to offset 0x9d06xxxx- 0x9d08000 which consist in *.nb0 as "0xff".

I think at updating nb0 it undefine data may interchange with correct data. or while loading device at this offset in memory may load smth else data

Sorry for bad English..

P.s. What we must doing if tomorrow forum will be closed by SOPA?
[HTC Wildfire S] eoghan2t7:
I'm setting up a temp forum until xda is back online ;)
[HTC Wildfire S] d33ps1x:
It's not closed by SOPA.

It's closed to protest SOPA for 12 hours.

It will be back up. In the meanwhile I'll just have to...leave the...house... :eek:
[HTC Wildfire S] sythe179:
With that sopa an ip act...

Couldent Facebook get yelled at for having illegal pictures on there servers a lot more?..
[HTC Wildfire S] cloudzxz:
Any possible solution now ?
[HTC Wildfire S] no.human.being:
Still looking for the offsets probably.

@devs currently looking into HBOOT: First, thank you very much for your enormous efforts. I know this reverse engineering stuff is incredibly time-consuming. What is the reference point for all of your addresses? Is it absolute (address as get passed to phone NAND)? If it is, do you know how the mtd devices map to absolute addresses? E. g. "device mtdX covers 0x???????? to 0x???????? of the phone NAND"?

If we have all this information and find the secu_flag/CID/SIM-lock (do we really need all three or will secu_flag suffice? every exploit I know changes all three, so possibly this is required) in memory, I will update the exploit. Only challenging thing left will be getting the ioctl calls right for erasing the mtd devices. If we got all this, then we will have software S-OFF.
[HTC Wildfire S] trampi:
Is the CID the property you get over:

adb shell
$ getprop ro.cid
O2___102

If yes, i could dump mtd3 and do a ASCII-Search for the cid i get.

The offset where (in my case) "O2___102" resides should be the offset for the cid, right? Is the cid in all cases 8 byte long?

Could do this today if it helps.

If i get the code compiled that dumps mtd3 and if my idea makes sense.
[HTC Wildfire S] ONeill123:
This is the CID, yes. And the CID is every time 8 Bytes long.

If the cid is near the secuflag, then your idea is good, but idk if it is so.
[HTC Wildfire S] no.human.being:
I have already posted a compiled version. I'll be back to tell you where to find it, my notebook battery is very low atm. :D

It is not exactly "near", but at least it should be on the same mtd device.

EDIT: Nope, I was wrong. I did not post a compiled version of the most recent exploit yet. I've attached it to this post. It will dump "/dev/mtd/mtd3" to "/mnt/sdcard/dump.img", perform the patching at the offsets of the DS (this is not useful obviously) and save that result as "/mnt/sdcard/patch.img". Then it tries to mount "/mnt/sdcard/dump.img" (the unmodified one) as "/system" via a loop device (this will fail for whatever reason) and terminates, as the "destructive" steps (erasing NAND and writing the patched image back) are currently commented out, so it will not brick your phone.

Just push it to your phone via "./adb push patch /data/local/patch", then go "./adb shell" (I expect you to have a root shell via adb, if your phone is not rooted yet, temproot via zergRush first), do "cd /data/local", then run the exploit "./patch" and watch it all happen.

When the exploit is through, you should have two files on your sd card called "dump.img" and "patch.img". The first one is a dump of "/dev/mtd/mtd3", the other one can be ignored for now.

Thanks.
[HTC Wildfire S] trampi:
I'll try it in about 6-7 Hours, i'm learning for exams right now. Or atleast i should... :D

Will post the results then
[HTC Wildfire S] no.human.being:
I'm at university right now. No problem ... :D

Just kidding. Good luck for your exams.
[HTC Wildfire S] BeciMester:
Guys, don't bother with the CIDs, there are a lot of them in one bunch in the hboot image, possibly for every carrier that sell the phone (I'd tell you exactly where they are but I'm away from my PC, I recall Telstra, lots of Vodafones, lots of T-Mobiles, generic HTC ones etc). What we need to find is the piece of code that looks them up and displays them, based on some condition. There is a string saying "SuperCID" as well, we should probably start from there.

@no.human.being: I base my addresses on the fact that a lot of them are hardcoded in the hboot in jump statements, code that behaves like a switch statement (based on some condition, it loads an address from a table and jumps to it, and all the values in the table point to the 0x9d0xxxxx area), most of the strings are directly referenced etc. These tables are scattered in the code, most of the time right after the code that uses them, so if the code is moved around in memory it must take some serious work to fix all these. Unless I'm missing something (which is possible, I've just began to learn ARM), I'm pretty confident this code runs at 0x9d000000 and nowhere else. :) I've no idea where and how it is stored in ROM, but I remember reading something about a table that specifies what loads where at boot. I'll update this post when I get home to the comp and find it again.

EDIT: here it is, credits to TJworld.net:

(table linked in quote) It refers to the Vision (Desire Z) but the principle should be the same. Right? Right...?

Desire-Oxygen2.3.2 | WFS-stock
[HTC Wildfire S] trampi:
It wouldn't be as clean as your suggestion, but you could get the CID for your phone and only patch this one to the SuperCID specific.

At least it would be much easier!
[HTC Wildfire S] BeciMester:
You don't understand. The CID is a number, stored somewhere, that the hboot checks and based on that number, it picks out the string to display. In theory you could change the string to your own name if you wanted to - it still wouldn't change the actual number which we need to change.

Desire-Oxygen2.3.2 | WFS-stock
[HTC Wildfire S] no.human.being:
The actual CID value (not the thing that HBOOT displays) is internally stored as a "string" (zero-terminated or not?) in ASCII-printable characters. On the Desire S, it is located on partition 7, offset 0x000200 and it is 8 bytes (so 8 characters) long. Exploits that set "Super CID" write the ASCII string (not the numerical value!) "11111111" to partition 7 offset 0x000200 to 0x000207 on the Desire S.

From the size point of view, the string "O2___102" would fit (it's 8 bytes long). I don't know whether it's stored as "85424831" internally and mapped to "O2___102" by HBOOT, but it's definitely a "string" internally (containing only decimal numbers?) and not, say, an "integer".
[HTC Wildfire S] trampi:
Im on my way home (studied too long :P). Will run it when I'm home. Will edit this post.
[HTC Wildfire S] no.human.being:
Ok, seems the CIDs aren't all "numerical" values as the SuperCID is.

You can find lists with CIDs on the internet. I've just stuck some of these together, which should cover a great deal of the values used. Not sure if this helps us much though.

11111111 --> SuperCID
HTC__622 --> Asia-HK-CHT
CWS__001 --> ATT
BM___001 --> BM
BOUYG201 --> Bouygues-Telecom
BSTAR502 --> Brightstar-PTB
BSTAR301 --> Brightstar-SPA
CHT__601 --> Chunghwa-Taiwan
HTCCN702 --> CT
HTCCN703 --> CU
DOCOM801 --> DCM
DOPOD701 --> DOPOD
T-MOB009 --> Era
FASTW401 --> Fastweb-IT
GOOGL001 --> GOOGLE
H3G__F05 --> H3G-DAN
H3G__402 --> H3G-Italy
H3G__003 --> H3G-ROI
H3G__G04 --> H3G-SWE
H3G__001 --> H3G-UK
HTC__037 --> HTC-Asia-SEA
HTC__044 --> HTC-Asia-SEA-WWE
HTC__023 --> HTC-Australia
HTC__E41 --> HTC-BE
HTC__C24 --> HTC-Czech
HTC__F08 --> HTC-Denmark
HTC__E11 --> HTC-Dutch
HTC__032 --> HTC-EastEurope
HTC__N34 --> HTC-ELL
HTC__203 --> HTC-FRA
HTC__247 --> HTC-FRA-Bouygues
HTC__J15 --> HTC-GCC
HTC__102 --> HTC-GER
HTC__038 --> HTC-India
HTC__405 --> HTC-ITA
HTC__Y13 --> HTC-Nor
HTC__H10 --> HTC-Norway
HTC__B25 --> HTC-Poland
HTC__506 --> HTC-PTG
HTC__A07 --> HTC-Russia
HTC__304 --> HTC-SPA
HTC__G09 --> HTC-Sweden
HTC__M27 --> HTC-Turkey
HTC__001 --> HTC-WWE
HUTCH001 --> Hutch-Australia
O2___102 --> O2-DE
O2___001 --> O2-UK
HTCCN701 --> Open-Channel
OPTUS001 --> Optus-Australia
ORANG113 --> ORANGE-AT
ORANG012 --> ORANGE-BE
ORANG203 --> ORANGE-CH-FRA
ORANG104 --> ORANGE-CH-GER
ORANG309 --> ORANGE-ES
ORANG202 --> ORANGE-French
ORANGB10 --> ORANGE-PL
ORANG008 --> ORANGE-PO
ORANG006 --> ORANGE-SK
ORANG001 --> ORANGE-UK
ROGER001 --> Rogers
SMCVD001 --> SMC-Voda-HK
TELEF301 --> TELEF-Spain
TELST001 --> Telstra
TELUS001 --> TELUS
TIM__401 --> TIM-Italy
T-MOB102 --> TMA
T-MOB004 --> TMCZ
T-MOB101 --> TMD
T-MOB007 --> TMH
T-MOB006 --> TMHR
T-MOBL11 --> TMMK
T-MOB003 --> TMNL
T-MOB008 --> TMSK
T-MOB005 --> TMUK
T-MOB010 --> TMUS
HTC__621 --> TWM-TW
VIRGI001 --> VIRGIN-UK
HTC__016 --> VODA-Africa-South
VODAP021 --> VODA-Australia
VODAP102 --> VODA-Germany
VODAP006 --> VODA-Greece
VODAP019 --> VODA-Ireland
VODAP405 --> VODA-Italy
VODAP120 --> VODA-Mobilkom
VODAPE17 --> VODA-Netherland
VODAP022 --> VODA-New-Zealand
VODAPD18 --> VODA-Portugal
VODAP024 --> VODA-Proximus
VODAP026 --> VODA-SA
VODAP203 --> VODA-SFR
VODAP304 --> VODA-Spain
VODAP110 --> VODA-Swisscom-DE
VODAP212 --> VODA-Swisscom-FR
VODAP416 --> VODA-Swisscom-IT
VODAP015 --> VODA-Swisscom-WWE
VODAPM27 --> VODA-TR
VODAP001 --> VODA-UK
[HTC Wildfire S] MrTaco505:
I'm confused, Srry for being a noob but are we getting close to an s-off for the WFS?
[HTC Wildfire S] sythe179:
From system file from /system

ro.aa.maincid=TELST001
ro.aa.modelid=PG7612000
ro.aa.project=Marvel

Page 35 I posted it aswell...

Could that mean you could change it on there and start what ever that gets used in?
[HTC Wildfire S] hahahafr:
This is awesome. For example I have a WFS from Orange-French, shouldn't I simply search for the ASCII string ORANG202 and change it to 11111111 to miraculously have SuperCID?
[HTC Wildfire S] sythe179:
Probably should be a bit harder than that....

And would still have to write the dump back to the NAND.
[HTC Wildfire S] trampi:
I've attached all locs of the dump where my CID occurs.

Hope this helps.

HBOOT-1.03.0000

Offsets:

0x99a850 [not null terminated, an xml-file, also attached, is a utf8 encoded. Attached as O2___102.xml]

0xa6885f [not null terminated, i think its not that relevant, seems to be a mapping from SKU to CID. seems to be in a utf8 file. Attached as Mapping.txt - this file is also available on my phone under /system/customize/resources/CCInfo.txt

0xd0a80a [a reference to O2___102.xml, maybe its the XML-File at 0x99a850 ? Probably not relevant]

0xd14a30 & 0xd14b36 [seem to be a configurationfile, i've attached it as config.txt. My CID occures two times in it, setting ro.aa.cidlist and ro.aa.cidlist. I think this one is not relevant]

0x2a5a9de [surrounded by strings, configuration?]

0x537c7e1 [surrounded by strings, configuration?]
[HTC Wildfire S] sythe179:
Why not just post the memory locations?..
[HTC Wildfire S] trampi:
Added them.