yashsingh1/xdaforums huggingface dataset:
[HTC Wildfire S] no.human.being:
I only used my stock image as a reference. I actually wanted to do the following:

- Look at which addresses my stock image contains the string "11111111".

- Look at which addresses the xtc-clipped image contains the string "11111111".

- The addresses that appear in the xtc-clipped image, but not in the stock are candidates for the location of the CID on the WFS because xtc-clip sets the CID to "11111111", but stock CID is different.

- Once we know where the CID is on the WFS, we might possibly be able to "guess" where the secu_flag and SIM-lock are stored.

- Once we know where all three values are stored on the WFS, I can almost certainly get a software S-OFF (like Revolutionary) done for the WFS by incorporating the correct offsets into my exploit and commenting in the third (critical) section, that flashes the patched image back to the phone NAND.

But the images actually seem to be entirely different. There are almost no bytes that match and those that do are probably a statistical thing only (well, there's only 256 possible values for a byte). I think that the comparison won't reveal a lot of useful information, but I'll probably try it nonetheless. I'm currently not having a better idea about where I should start.

No, we're not having S-OFF yet. What we're having is called "UNLOCKED S-ON". All it does is allow you to flash a custom recovery and you can use that recovery to flash a custom ROM afterwards. It does not allow you to modify the radio (although this is probably easy to achieve once you have modified the ROM), it does not work on SIM-locked phones and it requires you to register every single phone that you want to unlock to HTC, so HTC has the full control over the process and may stop unlocking at any time and there's nothing for us to prevent that. So the need for true S-OFF is still there.

Furthermore, the unlocking process is quite complicated and currently requires you to flash a radio update to the phone before the actual unlock and the only utility that HTC provides for flashing this is for Windows only, so currently no unlock using Linux/OSX/BSD/whatever only. (Or has anyone managed to unlock via HTCdev without using Windows yet?)
[HTC Wildfire S] sythe179:
The problem I saw with the comparing, is that the xtc clip uses a 0.81 hboot, and there was a lot that changed from that to 0.90 and 1.08.

Well, not much really changed, but they moved a lot around, and added stuff, so its harder to find...
[HTC Wildfire S] no.human.being:
Sorry, I'm not sure what you mean. Could you please explain a bit more?
[HTC Wildfire S] sythe179:
Well, during the first time HTC turns on the phone, an init script is run to configure folder permissions, and create other settings. I was wondering if you could re-start that init, and change stuff in it before you do, so that system for example, instead of being under the user system, be under root, so you can look at things through adb and stuff....

Well, just an idea..

Or the initial boot script....all kinda the same...

Files I'm looking at are init, and others I uploaded a few pages back....

Page 45 I think....
[HTC Wildfire S] no.human.being:
Eerm .. I can look at "/system", even on a locked phone on a stock ROM and without root.

If you zergRush, "/system" even gets mounted as "rw". However, if you attempt to write to it on the file system level (e. g. rename a file), weird things will occur (e. g. file will completely disappear from the directory listing but utilities may still find it under its old name) as the file system is probably exactly aligned in memory and writes change that alignment.

When you "overwrite" a file on a journalling (e. g. hpfs, ntfs, reiserfs, ext3/4) or log-structured file system (e. g. yaffs2, nilfs, ...), it does not get overwritten in-place, but the modified sectors are copied over to free space, then modified and after the modification is done, the pointers in the file system are updated to point to the new location.

This is why journalling file systems are so resilient against data loss. If a system crash occurs during the writing of the modified data, but before the pointers are updated, you have some garbage written to free space, but the file system metadata will still point to the sectors containing the old data, so that you have lost all modifications, but are still in some kind of "persistent state". But on "/system", this means that all writes are completely destroying the alignment of data structures on lower levels (e. g. block level addressing).

Because of this, you have to do changes to "/system" on a lower than the file system level (through the recovery). If this were not the case, you would not need an unlocked bootloader at all. All the unlocking does is allow you to flash a custom recovery, which in turn allows you to flash to "/system" on a very very low level that does not destroy alignment.
[HTC Wildfire S] josip-k:
Ok guys,i will ask devs on neopeek to help you,i couldnt even imagine how would it be if your phone is locked down.
[HTC Wildfire S] d33ps1x:
All the help we can get is great. Thanks.
[HTC Wildfire S] the Doctor:
Why is that necessary?

:confused:

I don't understand why closing the thread is necessary or even desirable. Development of a software S-OFF solution is progressing and still useful to many despite the recent release of the unlocked bootloader.

Actually, many people still have not gotten their bootloader unlocked, myself being one of them. I'd be thrilled if no.human.being and the guys got the S-OFF done.
[HTC Wildfire S] zyawoo:
eng-hboot

Yes, I agree.

I have got two WFS. One with S-ON/HBoot-0.90.0000/RADIO-7.46.35.08, another one with S-OFF/Hboot-1.08.0000/RADIO-.7.53.39.03.

I have done to flash the S-OFF one with a custom recovery.img and root.zip by SDCard.

But I wasn't able to root the S-ON one in this method. Then I tried to do this by fastboot mode and it was successful.

> fastboot flash recovery recovery.img

The recovery.img is a customer image with root access.

So now It seems that I have found a way to upgrade a customer rom from recovery for both of the devices.

But what I am still trying to do is, I am finding a way to flash(or patch) the hboot manually, then we would have more freedom for the device. I did try to use fastboot to flash the other hboot. (e.g. hboot_7225_1.01.0001_101117.nb0).

> fastboot flash misc hboot_7225_1.01.0001_101117.nb0

But it didn't work though there is no error messages. The hboot version is still no changed. So I think I did something wrong as the NAND FLASH is still being protected? It puzzled me.

If we have an eng-hboot, then I think it supports many oem commands which we could use them to do want we want. My "SHIP S-OFF" one just have few commands.

>fastboot.exe oem ?

... INFOcommand

INFOkeytest

INFOheap

INFOboot

INFOreset

INFOpowerdown

INFOrebootRUU

INFOheap_test

INFOrtask

INFOtask

INFOenableqxdm

INFOgencheckpt
[HTC Wildfire S] pat da punk:
Been watching these since the start of the S-off campain and its great what you guys are doing .keep it up it feel your getting closer. Onwards and upwards. :)
[HTC Wildfire S] no.human.being:
Yes. Basically what we are able to do now with our exploit code is dump and patch the data stored on the mtd devices, so we managed to overcome the main restriction of S-OFF which is "no access to protected memory".

Now we have to find out which values to change inside the protected area to obtain S-OFF, so that you can continue with the known procedure, flashing custom recovery, then custom ROM.
[HTC Wildfire S] theq86:
That's great. good luck to find the right offset to make S-OFF

If that method works, we will also be able to flash stock hboot and stock radio after updating via htcdev.
[HTC Wildfire S] no.human.being:
What's wrong with the new radio and hboot? Only advantage I'd see is not having to rely on HTC, flashing ENG HBOOT and custom radio and ability to do it on an open platform (afaik the radio update can only be performed on a Windows machine), why would you want to return to stock?
[HTC Wildfire S] theq86:
well, just in case of guarantee.

and new hboot will not let you get FOTA.

So I don't expect HTC to release a next update, but if they do, all with new hboot from htc-dev can not receive updates.
[HTC Wildfire S] no.human.being:
They will not look at your HBOOT/radio, they will just check their database whether you have signed up your device to HTCdev for bootloader unlocking or not.

You usually unlock your bootloader to install a custom ROM and are then under the update policy of your custom ROM provider.
[HTC Wildfire S] :
Right what nohumanbeing said.

If they power your phone with power-volume down and see in big letters "unlocked", then they will know it!

However with s-off, some phones are shipped s-off, so you can have warranty when you have flashed a stock RUU.

And btw: that unlocked hboot screen is ugly also!!

S-OFF is much cooler and better!
[HTC Wildfire S] theq86:
if the phone is S-OFF everyone can go back to 1.08.0000 again ;)

just for cosmetic reason of course
[HTC Wildfire S] no.human.being:
They won't power the device in bootloader mode. They will just check the device serial against the devices that were registered at HTCdev for unlocking and if there's a match, well...

So reverting to old bootloader AFTER you have signed up for HTCdev won't give you anything as they already have your device registered as unlocked, even if you do true S-OFF and revert to stock HBOOT and lock it again they will know it. So I'd say once registered at HTCdev equals warrenty lost, no matter what you do afterwards.

So my phone for example won't be covered by warrenty anymore, even if I S-OFF it now and return to the stock HBOOT and ROM.
[HTC Wildfire S] *se-nsei.:
Well even if your serial does match up, they can never know for sure. Why? Because you only use HTC servers to register and receive the unlock bin file via email.

They can never know if you've actually used the file to unlock or not, unless they look at your hboot screen... if it says S-OFF - then how would they know? :)
[HTC Wildfire S] pat da punk:
my thoughts exactly:D
[HTC Wildfire S] no.human.being:
Yes but I think from the legal point registered = warrenty void and that's all they will care for.
[HTC Wildfire S] BeciMester:
Well they'll be like: if it was S-OFF to begin with, why did you register and download the unlock bin? :o

Good thing I haven't done mine yet. I'll ride this S-OFF thing out, see how far we get. ;)

On topic: I'm in the middle of investigating the new hboot to see what the story is with the offsets. My plan is to find the function that checks the @secu_flag and displays either S-ON or S-OFF. I've already found the S-OFF text (offset 0x0006c178), now I need to find code that references this address. It's a slow and painful process as I don't have an ARM disassembler (can anyone recommend one, besides the commercial -and expensive- IDA?), so I have to research the hex values of the possible instructions and trying to find them in the hex dump. :eek: Also my first college exam is on this coming Friday. :(
[HTC Wildfire S] ebblbid:
disassemble

GNU objdump
[HTC Wildfire S] w()$k:
BeciMester, i dissassemble hboot 1.08 too. And i set name for 20% unknown funcs..

I process it with ida 6.1

I want to find adress which responsible for secu_flag
[HTC Wildfire S] BeciMester:
Thank you good sir! Looks great already. :D

Also: major google fail, I had. :(
[HTC Wildfire S] sythe179:
What are yous using for browsing memory locations of files?...

All I have is a hex editor...
[HTC Wildfire S] BeciMester:
That's all I have too, or rather had, now I also have my new toy the disassembler, linked a few posts above. For hex ed I use Frhed, search for it on Sourceforge, it's brilliant.

Desire-Oxygen2.3.2 | WFS-stock
[HTC Wildfire S] sythe179:
From what I can tell, after 90EC106, its the standard apps of the system partition.

Address.Dec = 151,961,862

If you don't know where that is, its marked by a heap of "yyyyyyyy"

Might be an idea to split the file so you can open it faster after that address decimal, but write the full file to the NAND, NOT THE HALFED ONE!
[HTC Wildfire S] no.human.being:
Now what I find confusing is that the block devices (e. g. "mtd3", where we assume the secu_flag, etc.) are primarily holding file systems (e. g. "yaffs2"). System updates seem to be performed on the file system level (the recovery installs from a zip file on the SD that contains other files) and not on the block device level (it does not install a memory image). Since "yaffs2" is a log-structured file system, as you write to a file, the information is not overwritten in-place. Instead, new blocks are allocated to accomodate the updated information, then the file system is updated to point to these new blocks. So when viewed from the block device level, information is constantly "moving" as it is being manipulated.

On the other hand, the information we want to patch (CID, secu_flag, SIM-lock) seems to be located on a fixed address and not part of a file, otherwise the "patching" at fixed offsets would be moot right? So from the file system point of view, this information seems to be some kind of "out of band". Nonetheless, the file system somehow has to be "aware" of that information, otherwise the blocks where the information is held could be allocated by the file system at some point in time and that information would be destroyed. I don't quite understand how this is done yet and this is currently a real head scratcher for me.
[HTC Wildfire S] zyawoo:
where

CID,secu_flag,SIM-lock were stored in radio, I think.
[HTC Wildfire S] w()$k:
i try to understand this fact too.. I think this adresses may be decoded with hardware decoder to activate read/write smth register of emmc(NAND). but it does not seem to be true %)

I continue to disasm Hboot1.08.nb0
[HTC Wildfire S] BeciMester:
Could it be marked as a bad/faulty block in the file system so it never gets overwritten? It could stay in one place forever...
[HTC Wildfire S] sythe179:
With a yaffs2 file system, it can bypass the write logic process that yaffs uses, therefore can overwrite specific data without changing old structures on the device.
[HTC Wildfire S] no.human.being:
Ok, so we can still expect the information to reside in a fixed location, right? If this were not the case, all our efforts were doomed to fail.

I have also found that we still need to change the "writing back" (step 3) part of the exploit, as we first have to erase (!!) the NAND before writing to it again. NAND is not designed to have data overwritten in-place. What will happen when you write to a block without erasing the memory first is undefined.

Should not be too difficult to erase the memory (should be a simple system call), but the question is whether the operating system (and with it our application) will even continue running when the entire phone memory is suddenly getting erased in the process.
[HTC Wildfire S] m1ndh4x8r:
good luck with it. crack some wildfire s a**. to s off it. I hope you have the tools.
[HTC Wildfire S] BeciMester:
Do we have to erase the whole memory, or just the block our target resides at? We should put some research into the way the RUU does it.

Edit: I understand w()$k is in the middle of doing just that. As much as I'd love to have a look myself I have 2 exams scheduled for Friday and Tuesday, so I can't promise any progress before that. :(

Desire-Oxygen2.3.2 | WFS-stock
[HTC Wildfire S] no.human.being:
Theoretically, you can erase single blocks. However, I somehow dislike the idea of performing modifications "in-place". Instead, I am currently dumping the contents of the entire mtd3 device to a file on the SD card, then patch around in that file. I would then erase the entire mtd3 device (if it is possible to do so, the question is whether Android will be able to continue running when mtd3 is wiped clean while the system is booted, remember the kernel and drivers and everything probably resides on mtd3) and then restore it from the image.

Of course, erasing the entire device and restoring it from the image file means additional write cycles on the NAND and embedded memory usually wears out way quicker than "discrete" NAND, but you're expected to do the S-OFF thing just once in the life of your phone, so causing some wear on the memory seems tolerable. The question is whether erasing the memory will disrupt a booted Android, preventing our application to complete the process of writing back the NAND contents from the image file, leaving you with a completely blank mtd3 partition, which will almost certainly result in an entirely bricked phone.
[HTC Wildfire S] hahahafr:
It would be a brick because the s-on flags prevents writing in the bland partition or I don't understand? If the partition is white, then there's no flag?
[HTC Wildfire S] *se-nsei.:
Stop with the constant random support posts please. They're not helpful.
[HTC Wildfire S] no.human.being:
You can definitely write to the NAND on the block device layer. S-ON does not mean anything on this level. S-ON is not hardware ROM protection. S-ON only causes the bootloader (HBOOT) to check signatures before flashing a custom recovery, so you can't flash CWM while S-ON unless you have an unlocked bootloader, that's all. And as long has you're having a stock recovery, you can't flash a Custom ROM, that's why you need S-OFF (or unlocked bootloader, which allows you to flash custom recovery even though it's S-ON) for all these things. This is how it works together. If you break any part of that chain, you can write to the NAND memory and break all the others.

The S-ON/S-OFF flag is part of the regular data on the NAND. It is probably located in the radio image. On the other hand, ROM protection information is "out of band" data, that will never appear on regular reads/writes. So, one more time, S-ON is NOT hardware ROM protection, please finally get this right, I can't stand it anymore. I have no idea where this myth is coming from, but I am absolutely certain that S-ON is NOT a hardware memory protection.
[HTC Wildfire S] d33ps1x:
So how do I make an image of my radio section including this "out of band" data for you? Got a new script for me to try? ;)
[HTC Wildfire S] no.human.being:
There's no point in dumping the "out of band" data, because there is nothing in it that would be of any interest. Our devices do not make use of hardware NAND protection, it is all enforced on the software level by directly checking the secu_flag, which is part of the radio image and as such "ordinary" data. That's what I tried to state, but no one seems to notice that we have already figured this out over and over again.

The "out of band" data will also contain error correction (ECC) information to compensate for "read disturbs" and stuff like that. When you read from NAND memory, you have a small possibility of flipping some bits with every read. This is called "read disturb". You can detect and correct these errors via ECC after the read and if you had to correct anything, then write the corrected version back to that cell again to refresh the cell's levels and make them "stable" for the next dozen reads.

Also not exactly interesting for our purpose.
[HTC Wildfire S] sythe179:
I noticed that the same thing gets posted like 5 times before people notice.....
[HTC Wildfire S] eoghan2t7:
See if I was to dump the radio and hboot will it still have HTC signification on them then pack it into the pg76img.zip so users can flash to become s-off?
[HTC Wildfire S] no.human.being:
No. The signature does not get written to ROM. It's just inside the image file, verified by HBOOT, then discarded.

Please let's get on with the exploit we have, instead of inventing dozens of new ways to S-OFF. You won't have to get anything signed. The exploit will just disable the secu_flag and with it the signature check of HBOOT, so afterwards, you can just grab the regular CWM, get it flashed, then flash custom ROM via CWM.

I was talking to one of our professors here at my university. He's doing embedded development. He's not exactly familiar with Android. However, he's familiar with the MSM7227. He meant that we could "probably" erase the NAND once the system was booted without the system or our application crashing. (He wasn't exactly sure, however.)

Someone was asking on this thread, whether the erasure of the NAND will turn the phone S-OFF. Well, basically when the NAND erase is through on your phone, your phone will neither be S-ON, nor S-OFF, as it simply won't have any firmware on it that could check secu_flag. :D

If you were to restore the dump of your S-ON phone after the erasure, of course you'd be S-ON. But the idea is patching the dump to S-OFF, restoring from the patched dump and achieve S-OFF this way.

So next thing will be: Create code for erasing the NAND after the dump and patching of the image file was performed and subsequently restoring NAND contents from the patched dump. I'm not sure yet how all the low level I/O control works that is required for erasing the NAND, but it's definitely possible to get this control from within Android via the official APIs.

The other obstacle is finding out WHERE to patch the image (offsets).

We can't do much trial-and-error here either. Once we have the NAND erased, we'll have to immediately restore a functional dump or the phone becomes a paperweight. So basically we'll have like one shot on this. You'll almost definitely require a JTAG repair in case of a failure.

Like I said, I'm currently not having that much time for development efforts, as I'm preparing for the exams at university, but I'll definitely keep a certain amount of development time up.
[HTC Wildfire S] sythe179:
Well....I'm still looking through...
[HTC Wildfire S] meanmug:
I digress, and please disreguard my statement towards closing threads. I'll be the first to admit when i'm wrong, and I was wrong.

---------- Post added at 07:58 PM ---------- Previous post was at 07:49 PM ----------

Can anyone try to decompile zergrush and see why it is so effective, maybe we can recompile zerg with the PG76DIAG.nbo file from the cdma s-off. Ofcourse phone would have to be rooted already.
[HTC Wildfire S] no.human.being:
The source code of the zergRush exploit is available to the public. See here.

I do not quite understand all the details of it, but it seems to be a "return to libc"-based attack. So basically you're causing a buffer overflow in a privileged process, that causes the return address on the processor's stack to be overwritten with some value you control. You set that address to a place that's mapped to a spot within the libc, that contains exactly the instructions you need to elevate your privileges. It's actually quite an advanced attack.

There's probably another exploit that gets you root privileges on Android. It's based on a so-called "fork bomb". A "fork bomb" is a process that repeadetly calls the POSIX system call "fork", which causes the address space of the current process to be duplicated, resulting in two almost identical processes being run afterwards. (Only the return value of the "fork()" call differs to enable the programmer to distinguish the "original" process from the newly created one.) The process table of Android can hold a limited number of processes only and there is the myth that the process that occupies the last slot in the process table will always be run as root. But I'm not sure if that is actually true, I never tried it out, as you have to carefully control the spawning of new processes as creating TOO many will just crash the system. So the processes all have to connect via sockets and communicate their status, so that they all stop forking once the "critical mass" was reached. It's a real pain to get this down, but I've heard it could also give you root. I first thought that this is actually what zergRush is doing, but if you take a look at the code, it does not fork, it writes a lot of stuff to the stack, so it's most likely a return-address based attack. It also searches the memory for libc, so it's most likely a "return to libc" attack as described above.