yashsingh1/xdaforums huggingface dataset:
[HTC Wildfire S] gauravjuneja01:
My DEvice..

HBOOT:- 1.08.0099

Radio:- 7.53.39.03M

Thank You...
[HTC Wildfire S] mobilescooby:
No worries will fire up the old phone now and report!

Thought as its just gonna be melted down for the metals inside it might as well die as a s-off or at worse a phone that so much wanted to be lol

I have same version of hboot and radio as well
[HTC Wildfire S] mobilescooby:
Booting laptop up now! Gimme 5 mins and ill report

Get the beers on ice
[HTC Wildfire S] no.human.being:
I'm so excited, can't believe it! :D
[HTC Wildfire S] theq86:
I'm hibbelig :D
[HTC Wildfire S] no.human.being:
I'm actually very confident that the exploit is alright. If it fails (device not bricked but still S-ON) it's almost definitely gonna be CWM kernel intervening and then I'd see no other option but going vanilla.
[HTC Wildfire S] theq86:
well, if we exploited really the right function and if there are no side effects by others, yes.

*waiting*

I gave you all my thanks for today in advance :D
[HTC Wildfire S] gauravjuneja01:
All steps Completed...

Bt at end.. It says....

sbin/sh: inject: not found
[HTC Wildfire S] mobilescooby:
Failed to detect HBOOT error
[HTC Wildfire S] theq86:
are you in /sdcard directory?

Does your prompt look like this?

/sdcard #

---------- Post added at 03:42 AM ---------- Previous post was at 03:41 AM ----------

when did you see that?
[HTC Wildfire S] mobilescooby:
Gonna try this again just to make sure! Standby
[HTC Wildfire S] theq86:
@gauravjuneja01

please don't try further yet.
[HTC Wildfire S] gauravjuneja01:
Yes i am in SD Directory...
[HTC Wildfire S] no.human.being:
The exploit aborts with message "[ERROR] Failed to detect HBOOT!" when the code that resides at the memory address that it wants to patch doesn't contain the "unmodified" HBOOT code which we'd expect at that address. This is a safety measure to prevent us from patching in the wrong place. If it occurs your HBOOT partition is probably not mapped correctly (wrong kernel parameters while booting the recovery via fastboot, e. g. typing mistake or partition map for the incorrect HBOOT version).
[HTC Wildfire S] mobilescooby:
Attempted again and its saying incorrect base signature from hboot!

Only thing I've noticed is my erasesize is different to what you state!

Could it be that?
[HTC Wildfire S] theq86:
aah, it's one of your err messages. couldn't find this string in radio.

so his phone is still alive.
[HTC Wildfire S] no.human.being:
Erasesize is more or less irrelevant. The "size" is relevant and the offset address that you supplied to the kernel via Fastboot (unfortunately this is not visible at all when the system is booted).

All HBOOT images start with the bytes "0x12, 0x00, 0x00, 0xea". When the exploit doesn't see these bytes at offset 0 at the partition, it claims "Incorrect base signature for HBOOT".

Yes, the message means that I haven't written anything.
[HTC Wildfire S] gauravjuneja01:
It is saying that

inject not found

i am giving this command

/sdcard # inject --disengage-the-safety /dev/mtd/mtd7
[HTC Wildfire S] theq86:
this is probably the most important thing to check before
[HTC Wildfire S] no.human.being:
You must type "./inject --disengage-the-safety /dev/mtd/mtd7". The command line starts with "./" (dot slash).

Right.
[HTC Wildfire S] theq86:
must be ./inject --disengage-the-safety /dev/mtd/mtd7
[HTC Wildfire S] BeciMester:
I'm in bed for the last hour or so, should be sleeping, but damn I'm glued to my phone's screen... :D

(I'm on my phone...)
[HTC Wildfire S] mobilescooby:
Followed word for word, the mappings are there the size is right.

Trying again

okay gonna try the 1.09 mappings even tho i'm on 1.08
[HTC Wildfire S] theq86:
No, this would definately not work. Even if you'd could write the base addresses are completely different.
[HTC Wildfire S] gauravjuneja01:
Everything worked fine.....

It patched Successfully.....

Bt....

After Restarting phone... It is stall saying.. S-On...

What is it now??????
[HTC Wildfire S] mobilescooby:
oh that was lucky, i just refreshed the page before i issued the inject statement lol
[HTC Wildfire S] no.human.being:
I got the impression that we got another one with an "exotic" Radio at hand. Remember Bad-Wolf had the old Radio with the memory layout of the new.

The exploit is relatively safe, it performs all kinds of checks before it starts writing to NAND. Maybe we're "too strict" at the moment, but we really wanted to be certain that we won't brick a device.
[HTC Wildfire S] theq86:
please go again in recovery as you did before. then do the following:

dump_image hboot /sdcard/hboot.img

and upload it so we can see if the hboot was really patched
[HTC Wildfire S] mobilescooby:
So we have 2 testers, 1 completes successfully but no s-off and the other wont even patch the hboot
[HTC Wildfire S] MrTaco505:
Same hboot and radio
[HTC Wildfire S] mobilescooby:
Well if we wanna go FULL NO PROTECTION!! you write it and i'll flash it lol
[HTC Wildfire S] gauravjuneja01:
Where should i insert this command????

Sorry.. M beginner...
[HTC Wildfire S] BeciMester:
Good thing that the phone booted at all, no brick, nhb's safety checks seem to be working. :)

(I'm on my phone...)
[HTC Wildfire S] theq86:
instead of the inject command.
[HTC Wildfire S] mobilescooby:
Hang on............i dont know if this is relevant

i went on the day of the unlocking of the bootloader to go and get s-off via the clip

I never got it! i'm wondering if when i unlocked the bootloader something had been patched?

Just seems strange that 2 technically same phones arent providing the same results
[HTC Wildfire S] no.human.being:
If it said success then everything worked as expected. The exploit really does check a lot so once it claims "[ OK ] Done!" (this is the exact message), then you'll know it was absolutely certain where to patch and patched exactly that.

So the code is probably patched as BeciMester suggested, but perhaps it's not the only routine that checks the flag. Ok, I'd say we better abort this now, what do you think theq86?
[HTC Wildfire S] theq86:
well, it's a paranoia version. :D

---------- Post added at 04:15 AM ---------- Previous post was at 04:13 AM ----------

For now, yes. Maybe again looking over the hboots and see what it does.

and maybe you also should delete your inject package for now. :D
[HTC Wildfire S] no.human.being:
For all those who tried, could you perhaps post the log messages from the exploit? With "log messages" I mean all the lines that start with an opening "[" and claiming either "[ERROR] ..." or "[ LOG ] ..." or "[ OK ] ..." together with your Radio and HBOOT version please. Thank you!

I'll run this on my phone as well .. after a NANDroid backup of course. :D
[HTC Wildfire S] theq86:
Well, just an idea: maybe it reports s-on but behaves like s-off :D
[HTC Wildfire S] gauravjuneja01:
Here is the Link...

http://www.mediafire.com/?i14qog4dbczi1an
[HTC Wildfire S] theq86:
thx. @nhb: please check if it is patched :)

edit: downloaded it. doesn't look like a hboot at all o.O
[HTC Wildfire S] no.human.being:
Lol, no. The function that we patched is actually the one that is called right before "S-ON" or "S-OFF" is printed to screen, so it's more likely to "report S-OFF and behave like S-ON" than the other way round but obviously it still reports "S-ON". :D
[HTC Wildfire S] gauravjuneja01:
When i tried 2nd time... it said.....

incorrect base signature...........

Am i S-OFF with showing status "S-ON"?
[HTC Wildfire S] imlgl:
So is mine. I have the beta version with just the pcb. It is identical to the other version except colour and the software which has been updated to unlimited. All you needed was the other lead to plug a 9v battery into.
[HTC Wildfire S] no.human.being:
I'm not having a JTAG debugger yet. I first thought about accessing one at the laboratories of my university, but I have ordered my own on Tuesday so I can access it at any time without having to wait for a slot on this precious device that our university seems to have.

The one I've ordered is an ARMUSBTINYH from Olimex Ltd. It seems to be supported by OpenOCD. You also need an adapter to connect it to the phone, as the phone obviously won't have a standard JTAG pin header on the board (they are just far too large physically :D ). I have only found a Polish supplier for these adapters, but I'll re-check with my university. Don't want to do the international bank transfer and pay for international shipment if there is a local supplier for these adapters. However, if this is the only option, I'll order it from the Polish supplier.

Check this youtube video. They even have a special software running on their PC that was supplied with the xtc clip. Additionaly, wasn't there a "pay for unlock"-version of the xtc clip? How would they do this, if the unlocking wasn't done over the internet, where they can keep track of your unlocks on some kind of "account" bound to the "ID" of your specific device?
[HTC Wildfire S] ONeill123:
Hmm, thats a good question, but not with the internet, maybe only the software has the counter?

Bc you must create the goldcard for every device if u use not the same sd card. Hmm, idk :(
[HTC Wildfire S] no.human.being:
xtcclip.com mentions two very interesting things.

So yes, it seems to be a goldcard generator, and ...

The latter is why I thought that the unlock is performed server-side.
[HTC Wildfire S] ONeill123:
Hmm, but i think, only the software has internet connection, bc the clip alone haven't got internet connection ;)
[HTC Wildfire S] no.human.being:
Of course the clip doesn't have internet access. There certainly won't be an UMTS transmitter and SIM card inside. :D

But that doesn't matter. The software will use the clip to read the device serial using the SIM interface. It will transmit the serial (possibly along with some authentification data) to the servers of xtc, they will generate a device-specific goldcard image and stream it back to the software, which will use the SD card writer inside the clip to burn it to SD. You insert the SD into your device, HBOOT finds it is a goldcard and turns device security off, because it thinks you are an HTC employee (e. g. a developer).

We won't be able to make use of the xtc stuff as the "interesting part" (the gold card generation) is done on their servers, which lie outside our control.
[HTC Wildfire S] imlgl:
Unlock is not server side ffs. If it was why do they provide an attachment to plug in a 9v battery so you can unlock the device when you are not at a pc.
[HTC Wildfire S] no.human.being:
xtcclip.com explicitely states that you cannot unlock without internet connection. They are telling lies?
[HTC Wildfire S] MindBurn010:
Just my opinion. I haven't seen XTC Clip but for what I have found and read in internet i think that the software needs Internet just to update the firmware of the CLIP if newer phone is not supported by the CLIP, I think that the Internet is needed only to add more instructions for new models and no Internet is needed by the CLIP ! What do you think ?!?
[HTC Wildfire S] imlgl:
Do you want me to video the process of unlocking a phone using a 9v battery. Unless I magically unlocked it with some unknown method. You need the internet connection to update it.
[HTC Wildfire S] ONeill123:
Maybe, but this isn't topic here. We want s-off without xtc clip ;)
[HTC Wildfire S] no.human.being:
Sorry pal. I really didn't want to insult you, I just quoted what was stated on their web presence and they state that the unlocking process is not possible without internet access. They don't say you need internet access to update the clip's "firmware" or to ensure it supports the newest models, but explicitely that unlocking is impossible without, so that looked very much like they did the unlocking server-side to protect their IP from being reverse-engineered. If this information is false or inaccurate .. well possible it is, but this is not my fault. :D

Now let's get back to topic please. This is for developing a free software S-OFF, not for starting a war about the mode of operation of the xtc clip. :mad:

Thank you very much. :D
[HTC Wildfire S] *se-nsei.:
To end the OT: XTC Clip uses the PC only for power. It recommends internet for updating purposes.
[HTC Wildfire S] no.human.being:
Thanks, really. Let's focus again on the problem at hand. :D

Possible, but the lock must be software-side and enforced by Android when booted up. S-ON/S-OFF itself is a "feature" of the bootloader and the bootloader is out of control as soon as the OS is booted.

Additionally, Android is able to perform "over the air" updates, even on S-ON devices. If the Flash was somehow write-protected by hardware means, this would not be possible. So it cannot be a hardware lock either. It must be a lock enforced by Android, as Android itself is obviously not restricted by it.

What this means is that, if we are able to escalate privileges so far that we could somehow bypass this lock enforced by Android or bootstrap another kernel, which disregards all the permissions, we might have a chance of writing to "/system". I agree with you in that this does not seem like a good solution though, as it seems to be like 10x harder and 10x less worth than the first method, but it still remains possible.
[HTC Wildfire S] ONeill123:
The s-off isn't a feature if the bootloader. If it is so, and u have unlocked with xtc clip, then after a hboot update or downgrade you have still s-on. But another user in german have tried and he has s-off already. So min. The secruity flag value is outside the hboot.
[HTC Wildfire S] no.human.being:
Sorry, seems my post was a bit ambiguous. I didn't mean that the value itself is part of the bootloader. I meant that it is the bootloader and Android itself enforcing the S-ON/S-OFF "policy", even to root users (as MindBurn010 mentioned you cannot mount "/system" as "rw", even on a rooted phone). Android itself is not restricted by S-ON, it can still update the kernel and everything, so it cannot be a hardware side lock, like a real write protection to the ROM section enforced by the memory itself. So it seems that, contrary to a "normal" Linux, the root user in Android is not "almighty". This might be important for privilege escalation, as this might indicate that there is a privilege level "beyond root" (even though this might not really exist as a privilege level in Android itself) we might be able to obtain using privilege escalation.

Contrary to this, some embedded processors have a real "hardware lock" feature for high-security applications. This is usually called "ROM protection". But this feature would really prevent all writes to the ROM and can never be reset again by firmware, so obviously this is not what S-ON/S-OFF is doing, as Android can be updated even when the device is S-ON. If S-ON/S-OFF were "ROM protection", over-the-air updates (or any firmware updates through anything except JTAG) would not be possible. But obviously they are possible, so "S-ON" is definitely not "hardware side ROM protection". All S-ON does is tell the bootloader not to flash unsigned ROMs and tell Android to write protect "/dev/mtdblock3" (this is the yaffs2 partition mounted to "/system", at least on my phone) even from the root user.

This will be my last post, at least until I return back home Sunday evening. Stay tuned.
[HTC Wildfire S] Ko_Ka:
From what I remember when the guy used the XTC clip on mine, he did have it connected to the net, and im pretty sure it sent him some form of hashcode to him, then he pasted that into the XTC software, whilst it was connected to the clip....

The clip definitely had a 9v battery on the end, whether it was in use or not I am not so sure.... :(
[HTC Wildfire S] imlgl:
Doesn't matter. 9v battery is for portable use if people use it at markets etc. There is no hashcode sent to the clip. It is a simple thing with nothing like that.
[HTC Wildfire S] d33ps1x:
This isn't correct. The gold card generation process has nothing to do with the phone or it's unique serial #.

The entire process is actually done without the phone even present. The phone comes in later...I've used the same gold card on three different Wildfire S's and it worked for all of them.

You simply choose your model and hboot version in the software. In the case of the Wildfire S there is only one goldcard image for ALL hboot versions. You create the goldcard at this point without the phone being a part of it.

THEN you clip in the SIM card cable into your phone from the XTC clip and the XTC clip via USB to the computer or via the 9 volt adaptor to a 9 volt, insert the goldcard, (made WITHOUT the phone being involved), and POWER/VOL down, then VOL down for DIAG (DO NOT FLASH!!!), then clean 58 and done.

It's already verified that the process works without the SIM aspect of it on SIM'less US Wildfire S's but not on SIM carded GSM devices like Canada, Europe, etc.

There is indeed something odd about the goldcard itself I believe though because an image I took of it from a 2 gig stock SD card would only compress to 350 MB or so even though the PG76DIAG.zip is only 7 MB.

If you're interested in checking it out it's in this thread here...

Wondering if there is something in the code that if it sees a SIM slot present and no SIM cable present and powering it it errors out but if it doesn't see one it proceeds.

Wondering if the DIAG file could be edited to bypass the error on no SIM cable present and perform the same process to S-OFF.

I would think the only reason to have the SIM cable inserted is to unlock the phone for multiple network sims but that there is something in the code that doesn't let it bypass this feature of the XTC clip if none is present in a GSM phone and simply leave it network SIM locked but S-OFF'd.

Obviously it bypasses this routine fine with CDMA phones...

Just noodling...

Regards,

DS
[HTC Wildfire S] no.human.being:
First of all, thanks for your detailled description of the unlock process using xtc clip.

From what I know, the "special" thing about a goldcard is in the first few bytes or so. These few bytes usually contain the boot sector and the partition table, if the SD card is formatted with a partition table on it. (*) I found a goldcard image on the net some weeks ago and there was an instruction on the site to write it to the SD's "raw device" file using dd. This will overwrite as many bytes as the image contains, which was about the size of a boot sector. I verified that both, the phone and the PC, will still recognize it as a valid file system and not do anything special about it, but the first few bytes are entirely different from a standard formatted SD card. Standard SD will contain recognizable patterns when viewed from a hex editor, while goldcard just looks entirely random (well, it won't actually be random, as this would be pretty odd, but it might contain a hash value or something similar).

(*) Windows will always format SD with partition table and it will usually also come preformatted like this. On Linux, creating partition table and formatting are different things so you can create a file system starting directly on block zero from Linux using mkfs on the plain device and then you will have a drive without a partition table.

Probably, as long as you haven't explicitely "zeroed out" the SD card prior to creating the goldcard, you had "data remnants" on your SD card from what was written there before. Formatting only kills the file system, not the data itself (formatting is actually called "mkfs" on Unix, "make file system", which is what it is actually doing). Not a good idea to upload such an image to the internet, as it might be possible to reconstruct "deleted" data from it using forensic methods, but it would explain why the image had some "random" size, as it probably contained all the data floating around in the SD card's "unallocated space". You usually can't be sure how much entropy is in there, so it might compress to anything, depending on the data patterns that were written to the SD before.
[HTC Wildfire S] no.human.being:
No, when it claims "incorrect base signature", it didn't find an HBOOT image on the "mtd7". It only patched the HBOOT when it claimed "[ OK ] Done!" in the end.

No. Sure it would abort when it would see that. No chance it got patched.
[HTC Wildfire S] gauravjuneja01:
Your cammand gave me this file....

Is it not the right thing you want??????
[HTC Wildfire S] theq86:
No, probably not. But according to how your hboot looks like I'm wondering your phone still works :D
[HTC Wildfire S] no.human.being:
Did the exploit report "Success!" or did it report "[ERROR]"? I'm sure it did report "[ERROR]" and did not patch provided you let it run on the same memory (same device provided as parameter and same mapping provided to the kernel). It doesn't look like HBOOT at all. HBOOT starts with a quite "individual" 32-bit word followed by lots of version strings and these are all checked by the exploit before it patches anything.
[HTC Wildfire S] gauravjuneja01:
My phone is working very good...... As usual....

I think there is mistake in typing command that you told me.....

Is that was the right file u want?????

that i uploaded????

---------- Post added at 08:59 AM ---------- Previous post was at 08:57 AM ----------

In my First Try... (Approximate, not pure remember)......

It said....

Reading....

Patching hboot....

PAtched successfully....

Done..... (like it)...

I thought i patched successfully...

Bt i restarted....

It still S-ON......

No luck...
[HTC Wildfire S] theq86:
well, it should be. although it looks awkward.
[HTC Wildfire S] mobilescooby:
have checked and double checked every step 5 times. i simply cannot get this script to patch the hboot :(

[ LOG ] Step 1: Reading from mtd ...

[ LOG ] Step 2: HBOOT analysis ...

[ LOG ] Incorrect base signature for HBOOT-1.08.0099

[ LOG ] Incorrect base signature for HBOOT-1.09.0099

[ERROR] Failed to detect HBOOT!

HBOOT-1.08.0099

MICROP-0451

RADIO-7.53.39.03M

Nov 28 2011,19:09:21
[HTC Wildfire S] gauravjuneja01:
@nhb...

After the Pure Success.....

Mine is showing same...
[HTC Wildfire S] theq86:
can you please also provide us with your hboot dump?

instead of inject command type:

dump_image hboot /sdcard/hboot.img
[HTC Wildfire S] no.human.being:
Ok, I've done it on my own phone.

[ LOG ] Step 1: Reading from mtd ...
[ LOG ] Step 2: HBOOT analysis ...
[ LOG ] Incorrect version string for HBOOT-1.09.0099

[ LOG ] HBOOT-1.08.0099 detected.
[ LOG ] Step 3: Patching ...
[ LOG ] Step 4: NAND unlocking ...
[DEBUG] ./mtdutils/flash_unlock /dev/mtd/mtd7
[ LOG ] Step 5: NAND erasure ...
[DEBUG] ./mtdutils/flash_erase -q -u 0 0 /dev/mtd/mtd7
[ LOG ] Step 6: Writeback ...
[ OK ] Done!

So the exploit gets through, but the phone is still S-ON. So it's probably not the right thing to patch, but at least it doesn't seem to do any harm to HBOOT either. :D
[HTC Wildfire S] theq86:
please dump and be sure hboot got patched and is no "working garbage"

I find it strange that gauravjuneja01 device still works :D
[HTC Wildfire S] gauravjuneja01:
@nhb..

Mine shows the same buddy....

Fortunately you have snapshot and i have not .....

Thnk You.....
[HTC Wildfire S] mobilescooby:
Here you go, hope this helps
[HTC Wildfire S] gauravjuneja01:
Now what is the status buddy????????

Will we get S-OFF???

One thing sure that our device will not be bricked.....
[HTC Wildfire S] theq86:
okay, both of you guys hboots are md5: 53368ced64bc511f8cd1a0c74cdd193e

I think this "garbage" - and it obviously WORKS is the exotic variation of HBOOT.

So no wonder that the exploit did not want to patch. But their hboots are identical.
[HTC Wildfire S] gauravjuneja01:
What does it means????????????/

M sorry for bad Terminology Problem....
[HTC Wildfire S] theq86:
That means you and mobilescooby both have the exact same hboot. (actually logical, because your versions are the same)

BUT:

Your versions do not "look" like a normal HBOOT in binary view mode.