yashsingh1/xdaforums huggingface dataset:
[HTC Wildfire S] no.human.being:
I've just successfully run the zergRush exploit on my WFS, getting a privileged debugger shell and "/system" mounted as "rw". However, strange things happen when writing to "/system".

- When you attempt to create a new file, it says there is no free space.

- When you rename a file in "/system", the file will disappear from the directory listing. It won't appear under its old name anymore and it won't appear under its new name. It just seems to be "gone".

- When you use "cat" to access the file using its old name, it still seems to work, even though it is not listed any more.

- When you use "cat" to access the file using its new name, it will not exist.

- When you reboot the phone, you lose all your privileges (as you would expect) and the file reappears under its old name.

I assume this is due to the "yaffs2" driver getting confused, as its writes do not take effect due to the NAND lock. I imagine that it writes blocks of new data and still reads old data back and then just goes crazy and does funny things.

Btw, I'm having access to a JTAG debugger now. Still need to get hold of a suitable adapter though, as the phone obviously won't have the standard 2x10 pin "jumper style" JTAG connector (as this would be far too large for a device like this).

I'll likely also need lots and lots of time for figuring out all this JTAG-related stuff as this gets deeply involved with all the low-level properties of the phone microcontroller and you can probably damage the phone very easily if you don't know what you're doing.

I don't know when I'll have the time to work this all out, as my studies take up very much time at the moment. However, as soon as I'll have the time to figure all this JTAG stuff out, I'll try to perform a dump of the phone's NAND memory, perform a disassembly and have a look at what exactly the bootloader is doing when checking the device security flag and, quite importantly, how this is all laid out in memory. We will need this for developing the S-OFF itself.
[HTC Wildfire S] csoulr666:
All of us are here to support you man!!!!I don't know much of this stuff but here's something that might help

Hope this helps.....and keep up the good work

---------- Post added at 05:15 PM ---------- Previous post was at 05:01 PM ----------

almost forgot... :D
[HTC Wildfire S] ash98:
Great to see we're making some progess! :) Thanks for your work no human being!
[HTC Wildfire S] munjeni:
Thanks, so if I understand, I need to "fopen" mtd device and than...

Yes, I have maped mtd0 as a hboot (but not by fastboot), and I not passed kernel parameters (but I allready tried passing via command line-system.img), I maped it direcly in msm_nand.c... see:

dev: size erasesize name
mtd0: 00080000 00020000 "hboot"
mtd1: 000a0000 00020000 "misc"
mtd2: 00420000 00020000 "recovery"
mtd3: 002c0000 00020000 "boot"
mtd4: 0f000000 00020000 "system"
mtd5: 02800000 00020000 "cache"
mtd6: 0b920000 00020000 "userdata"

but its not posible erasing/writing to hboot partition (but I'm abble to dump it!), other partition is abble! So this is reason why I asked you for explaining
[HTC Wildfire S] :
Yes, we need as much help as knossible!

If you do choose to help, then here's some info, about the rest of us.

The currently known devs that are working hard on this project are:

no.human.being (we call him NHB)

theq86

heavy_metal_man (I call him HMM)

Antagonist42 (I think)

munjeni (hopefully! :D)

Bad-Wolf (ughhh..... fine, I'm not!!!! :mad:. I am learning Java though. Apparently, that won't help)

Then we have testers. We test out the exploits that the devs make! Here they are:

Bad-Wolf (defo this time. LOL. :D)

MrTaco505 (but I think he said that he left)

rezo (he's a daredevil! He was so willing, that he nearly badly bricked his phone!)

And a big bunch of other people!!!!!

Also, some of us, like me, have what NHB calls them "exotic" memory layots/partitions/whatever. So basically, you can have the version string of your HBOOT/Radio, but the actual memory layout is newer! Or vice versa. So, when the exploit comes out, you have to get the one that is compatible with the MEMORY LAYOUT, NOT the version string! It's best if NHB explains it to you.

---------- Post added at 05:47 PM ---------- Previous post was at 05:43 PM ----------

Firstly, the exploits work with the mtd7 partition, not the mtd0 partition.

Secondly, we are doing what we are doing so that we can write to those partitions. :D

------------------------

Can you explain how you mapped the hboot as mtd0 in an "advanced newbie" way. I've got all the tools, Fedora, blah blah blah. Love to know.

Thank you!!

---------- Post added at 05:58 PM ---------- Previous post was at 05:47 PM ----------

Here's a tip for your English:

Instead of saying "I'm having the (object)" say "I have the (object)"

If you found this offensive, I'm very sorry. I didn't mean to bring you any offence. I just thought that it would help you improve your English. Again, I didn't mean any offence.

After all, you did say:

Thank you for understanding.
[HTC Wildfire S] heavy_metal_man:
thought.

just a thought, the revolutionary team. how do they

do there hboot patch to the wildfire(buzz)? is it possible that they found a way to drop the protection, but still found it difficult to write to the unmapped area, and made a kernal to be pushed via fastboot to do the job? what is this caroline they send in??
[HTC Wildfire S] pihug12:
I don't know if you did it on purpuse but a part of your memory is still unmapped.

You got the 512KB of the HBOOT but you're missing the whole "radio part".

He has a HTC Aria. The memory layout is not the same as our device.

Revolutionary uses an exploit that can't be used on our device. This patch doesn't use such low level trick that we have to deal with right know. So I think the memory isn't protected at all on these "old" devices.
[HTC Wildfire S] no.human.being:
For the exploit we're only mapping the 512 KiB of the HBOOT. We only mapped the Radio for finding where the HBOOT is. The HBOOT is actually "part of the Radio", Radio goes from address 0 (inclusive) to address z (exclusive), HBOOT goes from address x (inclusive) to address y (exclusive) and 0 < x < y < z. So the HBOOT area is a subset of the Radio area. Problem is that x and y are changing (actually z is also changing), so you have to calculate z (it's: ("highest physical address" + 1) - "sum of all mtd partition sizes"), then you have to map 0 (inclusive) to z (exclusive) as a partition (say "mtd7"), dump that, skim through it to find the offset where HBOOT begins (this is x), then add 512 KiB (this is y). Then you can reboot the device, mapping x < "mtd7" <= y as partition instead of 0 < "mtd7" <= z and with this mapping you can run "./inject --disengage-the-safety /dev/mtd/mtd7".

It's actually the other way round. It's "protected" on "old" (MSM7xxx) devices (like Wildfire S, MSM7227). It's "not protected" on "new" (MSM8xxx) devices (like Desire S, MSM8255).

I say "not protected", but actually it is protected. However, the protection has been broken. When you look at the GFree exploit that can S-OFF the Desire S, there is this obscure "needle and haystack" algorithm in it. I don't know how it works, but I think it somehow "maps" the Radio partition while the system is booted, while we're doing it by passing parameters to the kernel via Fastboot. There may be a way to do it while the device is booted, but the Fastboot method is currently the only one we know of.
[HTC Wildfire S] *se-nsei.:
So much information flying around. Hope everything is going well atm NHB.

Btw, Bad-Wolf, I've come to the conclusion that your posts are actually moving the thread along. But just one tiny request for me? PLEASE please please SHORTTEN THATT SIGNATTUUREE !!!!! :D
[HTC Wildfire S] munjeni:
Thanks guys, tomorrow I will try this that you posted here... I tried today inject:

Other contributors and fellows from xda: d33ps1x, Bad-Wolf, benjamingwynn

Thanks to Cyanogen, Alquez and Drowningchild for their work on the kernel.

Thanks to the bands Kampfar (Fredrikstad, Norway) and Trivium (Orlando, Florida)
for their inspiring music!

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

[ERROR] Failed to detect HBOOT!

but I not need to use inject, I need to understand how it works and than create something for htc hd mini or aria (but not need for aria becouse aria allready have revolutionary)...

:) sorry for my english... yes it's very bad, but I think you understand me completely?
[HTC Wildfire S] :
NOOOOOO! I LOVE THE CONAN QUOTE!!!! NOOOOO!

Fine!!!!

I'll see what I can do.......

EDIT:

There we go, nice and sleek-ish.

Anyway, NHB, have you had even the slightest success?

EDIT:

I made the 200th page!!!!!!!!!!!!

---------- Post added at 07:34 PM ---------- Previous post was at 07:32 PM ----------

I was talking to NHB. But, then again, it applies to everyone. LOL. :D
[HTC Wildfire S] no.human.being:
It works like this:

1. Map the HBOOT as an mtd by passing suitable parameters to the kernel. (This is currently done via Fasboot, so it's not part of the "inject" utility.)

2. Perform some self-testing to make sure the exploit itself is consistent. :D

3. Obtain a file handle to the HBOOT partition by "fopen"ing the mtd for binary reading ("rb").

4. Determine the partition size by "fseek"ing to the end of the device. If it differs from 512 KiB, abort.

5. Gain temporary workspace by "malloc"ing a 512 KiB buffer in RAM.

6. Dump the HBOOT partition into RAM by "fread"ing it into the buffer.

7. Release the handle to the HBOOT partition by "fclose"ing.

8. Find out where the routine resides that checks the secu_flag by analyzing the HBOOT code that's residing in the buffer. This is basically our "special sauce" that should enable our tool to adapt to changing HBOOTs, so that it's no longer trivial for HTC to release an "incompatible" HBOOT. :D Because of this flexibility, they'd have to severely modify the bootloader in order to "break" our exploit. Should the algorithm not be "absolutely sure" where to patch, abort, since S-ON is better than bricked. The routine is found by following pointers from a so-called "pivoting area" in the HBOOT image. We also store the address where this "pivoting area" resides. This algorithm was created by analyzing dozens of Radio dumps obtained from several actual WFS devices. It's very deeply tied to the actual device firmware, so if you want to apply the exploit to a different device you're going to have to do all the reverse-engineering effort again.

9. Overwrite the routine that was determined with the ARM machine instruction equivalent for "return 0;". This ensures that HBOOT will always report (and behave) S-OFF.

10. Modify the contents of the "pivoting area" to reflect our changes. This step is not neccessary, but I'm doing it for completeness.

11. Call the "nand_erase" tool on the HBOOT partition for erasure.

12. Obtain a file handle to the HBOOT partition by "fopen"ing the mtd for binary writing ("wb").

13. Commit the changes to NAND by "fwrite"ing the patched HBOOT image back from the buffer.

14. Do an "fsync" to make sure that the changes hit the actual NAND and are not stuck in some device-specific volatile buffer.

15. Release the handle to the HBOOT partition by "fclose"ing.

The complexity only comes from the fact that we patch the HBOOT that's already on the device. If you are willing to ship "pre-patched" HBOOT images with your exploit, it basically simplifies to mapping the HBOOT as an mtd partition, erasing the corresponding pages on the NAND and finally writing the patched HBOOT to them. One might even do this from a shell script, as long as a build of the "mtdutils" is shipped along with it.
[HTC Wildfire S] :
Excuse me for asking, but I got Fedora, but I don't use it much. This is because I'm not experienced with linux. Can you give me a beginners guide so I can understand the basics of linux (terminal, all the other necessary stuff) then tell me how to get all the dev tools set up (fastboot, adb, etc.). I'm a Windows user. All of my deving stuff happens on Windows, like C&C ROM.

Sorry for asking, but it's very important to me. Maybe then I can make a thread explaining it all, so other users can find it.
[HTC Wildfire S] munjeni:
Big thanks dude! But aria is allready s-off!!! Thats problem! flash_erase nor nandwrite could not working! I want to write, I have whole hboot partition in mtd0 (but I can move it to mtd7 but does it matter if I not using inject?) and double checked/hex compared dump from mtd0 to hboot from nbh and its the same! So only this part I not understand why it can not be tached. Maybe something special gone if kernel parameters is passed via fastboot? Did you tried to overwrite hboot setting kernel parameters via mkbootimg instead of setting kernel parameters via fastboot? Maybe fastboot_to_kernel parameter is the key? Maybe something happened in hboot after fastboot_to_kernel parameters? In any way I'll try fopen/fwrite from an simple kernel module...
[HTC Wildfire S] :
I use CMD. Very used to it.

You won't catch me compiling for ARM, I don't know C! Wish I could learn it though. But writing a Hello World in C seems to take forever!

I'll probably only have the Android SDK toolchain and one that can compile Java.

In Windows you can set paths permanently. Can that be done in Fedora?

Also, can you explain the "man" thing a bit more clearly please? I didn'y understand it properly.
[HTC Wildfire S] Antagonist42:
Replica?

The MSM7227 isn't a replica, it actually 'Contains' the ARM 1136JF-S (the application processor) and the ARM 926EJ-F (the modem 'RADIO' or AMSS).

;) Check the docs I found and posted here

if you know of any more chip/ref i'll hunt and post as will do shortly for the RTR6285 (RF Transciever IC)
[HTC Wildfire S] Antagonist42:
Tell me am I wrong if the data sheets saying this?

SECURE BOOT SEQUENCE

**taken from MSM7227 modem pdf here (abridged).**

MSM power-up is coordinated by the PMIC. Once the supply voltages, clock signals, and PON_RESET-N signals are established, the MSM device begins it's start-up process, or 'boot' process. The modem ARM (*ARM926EJ-F* mARM) controls the boot, it starts executing code from the internal boot ROM. This code is called the primary boot loader (PBL).

As the PBL runs, it accounts for some external control settings defined by the IC's pins and Q-fuses. The PBL is contained within the MSM device, it is pre-programmed in silicon and cannot be changed.

**> essentially a basic boot program to boot up and I guess not hboot as these can be re-written as other phones use the same MSM7227 (as does my old LG GT450) and (if memory serves me right *don't quote me lol*) I updated hboot on that phone. <**

Handset designers are accommodated by using external boot memory (either NAND or OneNAND) that interfaces with the mARM via EBI2. Its boot-supporting code is called the secondary boot loader (SBL). Since this code is external, it cannot be trusted and must be authenticated by the security authentication code that resides in the internal boot ROM's PBL.

**> so I guess having a phone shut down, booting phone into fastboot or recovery the mARM is up and running and so is accessing NAND through EBI2 (low speed bus to NAND/LCD/other periferals and EBI1 High speed as for DDR RAM) data bus making NAND secure as is 'in use', the only other way to access is through using secure or 'signed' software as finding the keys I think will be nigh-on impossible as the following .... <**

BOOT ROM

The 64kB boot ROM holds the modem ARM primary boot loader and the eleven 2048-bit public keys. Eleven keys are believed sufficient, but as many as 32 can be supported by adding more keys to the boot ROM. Public keys are selected by the 5-bit PUBLIC_KEY_SELECT fuses in the CONFIG chain. Boot ROM implements a slave AHB interface and is connected to the modem bus.

**> So even in fastboot/recovery the modem/AMSS/RADIO processor is running from phone switch on even before hboot starts so that NAND is actively in use and so security is started with the modem mARM as it starts PBL, has access to NAND through EBI2 which in turn has access to aARM/app ARM or ARM1136JF-S <**

So I reckon we NEED to run an EUU/RUU but only as far as the updaters program runs CheckHTC.exe and not execute any other programs/transfers to do with the update itself (not even to complete) as I said the CheckHTC turns off the AMSS/RADIO/mARM :D
[HTC Wildfire S] Antagonist42:
Are THESE what you're after?

When I know what I'm after I'll find something useful :cool:

ARM1136JF-S and ARM1136J-S Reference Manual 840 pages

ARM926EJ-S Technical Reference Manual

PM7540 Qualcomm Power Management

:D :p :rolleyes:

will be updating docs as they are found here.
[HTC Wildfire S] Antagonist42:
But from what I've been reading through MSM7227 on booting and what's going on with NAND unless you have the secu info or the keys or the original programmer for the phone/chips the problem is .... mARM boots Phone PBL, mARM runs hboot (which resides in aARM) aARM takes over booting with access to security keys etc for system which reside in mARM (which are protected from accessing unless you have relevant secu/keys/etc) mARM may hand over booting process to aARM but aARM is accessing (by hook or by crook) security keys in mARM, this will halt any writes to NAND as the security is running (mARM) turn it off you'll probably find you can write to NAND (as you'll know more where to put anything ;-) ) or even more basic stick su on phone

ARM926EJF - BinText'ed the files from my EUU for phone and started from there, Data sheet for SMS7227 came up trumps ;-)
[HTC Wildfire S] munjeni:
Ok, but what kernel you used to do it? My kernel is cianogenmod kernel and not stock!

Another one. Is here pbl?

Partition-Info :
------------------

0:MIBIB
---------------------------------------------------------
Page:	0x0
Size:	0xA
Address:	0x00000000 - 0x00140000
Block:	0x00000000 - 0x00000280
Flash:	0x00000000

0:QCSBL
---------------------------------------------------------
Page:	0xA
Size:	0x4
Address:	0x00140000 - 0x001C0000
Block:	0x00000280 - 0x00000380
Flash:	0x00000000

0:OEMSBL1
---------------------------------------------------------
Page:	0xE
Size:	0x6
Address:	0x001C0000 - 0x00280000
Block:	0x00000380 - 0x00000500
Flash:	0x00000000

0:OEMSBL2
---------------------------------------------------------
Page:	0x14
Size:	0x6
Address:	0x00280000 - 0x00340000
Block:	0x00000500 - 0x00000680
Flash:	0x00000000

0:HTC
---------------------------------------------------------
Page:	0x1A
Size:	0x10
Address:	0x00340000 - 0x00540000
Block:	0x00000680 - 0x00000A80
Flash:	0x00000000

0:AMSS
---------------------------------------------------------
Page:	0x2A
Size:	0xC0
Address:	0x00540000 - 0x01D40000
Block:	0x00000A80 - 0x00003A80
Flash:	0x00000000

0:EFS2
---------------------------------------------------------
Page:	0xEA
Size:	0x2C
Address:	0x01D40000 - 0x022C0000
Block:	0x00003A80 - 0x00004580
Flash:	0x00000000

0:FOTA
---------------------------------------------------------
Page:	0x116
Size:	0x8
Address:	0x022C0000 - 0x023C0000
Block:	0x00004580 - 0x00004780
Flash:	0x00000000

0:RESERVED
---------------------------------------------------------
Page:	0x11E
Size:	0x2
Address:	0x023C0000 - 0x02400000
Block:	0x00004780 - 0x00004800
Flash:	0x00000000

0:APPSBL
---------------------------------------------------------
Page:	0x120
Size:	0x6
Address:	0x02400000 - 0x024C0000
Block:	0x00004800 - 0x00004980
Flash:	0x00000000

0:MISC_MFG
---------------------------------------------------------
Page:	0x126
Size:	0x2
Address:	0x024C0000 - 0x02500000
Block:	0x00004980 - 0x00004A00
Flash:	0x00000000

0:WLAN
---------------------------------------------------------
Page:	0x128
Size:	0x2
Address:	0x02500000 - 0x02540000
Block:	0x00004A00 - 0x00004A80
Flash:	0x00000000

0:SPLASH1
---------------------------------------------------------
Page:	0x12A
Size:	0x9
Address:	0x02540000 - 0x02660000
Block:	0x00004A80 - 0x00004CC0
Flash:	0x00000000

0:SPLASH2
---------------------------------------------------------
Page:	0x133
Size:	0xE
Address:	0x02660000 - 0x02820000
Block:	0x00004CC0 - 0x00005040
Flash:	0x00000000

0:APPS
---------------------------------------------------------
Page:	0x141
Size:	0x278
Address:	0x02820000 - 0x07720000
Block:	0x00005040 - 0x0000EE40
Flash:	0x00000000

0:EXT_ROM
---------------------------------------------------------
Page:	0x3B9
Size:	0x47
Address:	0x07720000 - 0x08000000
Block:	0x0000EE40 - 0x00010000
Flash:	0x00000000
[HTC Wildfire S] boalos:
I cannot find the attachment exploit and inject

I cannot find the attachment exploit and inject, and in the main thread the attachment is not there
[HTC Wildfire S] Antagonist42:
DAAAAAmmmmnnnn!!!

Many thanks n.h.b. :o

Well really I wasn't that far off being right..... after reading through the Data sheet, reading up on the NAND, knowing what my phone wouldn't do ...... Almost Bang on :D

EXCEPT

for the 8, 10 or 12 steps I never knew about lmao

To put a compliment very bluntly ''Damn! you know your **** dude!" :cool:

*and yes I now copied that lot down, will print out 100 times and beat myself round the head 'til I know it off by heart*
[HTC Wildfire S] munjeni:
Yes, it gives all parts inside nand + all phys offsets :) but this is from htc hd mini. If you want to see full nand parts for wildfire s, just install trial software from revskills.de and load radio.img to firmware_forensis/show_partition_info and list will be displayed!

I tried your dump.c code but in reverse order, and I must to say it definitely not working, so now I think its imposible! Do you used stock kernel for recovery while setting fastboot comand_to_kernel, or you used an custom kernel? And do you have link to that kernel? Here is small part from dmesg.log when I executed dump:

<3>[ 9480.342089] msm_nand_write_oob 0 1000 0 failed -5
<3>[ 9480.342231] msm_nand_write_oob 0 1000 0 failed -5
<3>[ 9480.342366] msm_nand_write_oob 0 1000 0 failed -5
<3>[ 9480.342504] msm_nand_write_oob 0 1000 0 failed -5
<3>[ 9480.342639] msm_nand_write_oob 0 1000 0 failed -5
<3>[ 9480.342774] msm_nand_write_oob 0 1000 0 failed -5
<3>[ 9480.342911] msm_nand_write_oob 0 1000 0 failed -5
<3>[ 9480.343048] msm_nand_write_oob 0 1000 0 failed -5
<3>[ 9480.343186] msm_nand_write_oob 0 1000 0 failed -5
<3>[ 9480.343324] msm_nand_write_oob 0 1000 0 failed -5
<3>[ 9480.343459] msm_nand_write_oob 0 1000 0 failed -5
<3>[ 9480.343594] msm_nand_write_oob 0 1000 0 failed -5
<3>[ 9480.343731] msm_nand_write_oob 0 1000 0 failed -5
<3>[ 9480.343871] msm_nand_write_oob 0 1000 0 failed -5

I'm definitely confused how you sucesfully done writing to nand using fwrite
[HTC Wildfire S] ONeill123:
Sorry if this exploit of no.human.being is old or something else, that this post is unuseful, i lost the connection near page 175 ;)

I have tried this:

http://xdaforums.com/showpost.php?p=23269580&postcount=1541

First with the error, that the hboot isn't detect. Ok, i used the code for the HBOOT 1.08.0099.

Then i tried (just for fun) the code for HBOOT 1.09.0099 with my 1.08.0099-HBOOT!!!

And then following message in cmd/terminal (is windows):

Then restart, but unhappily s-on :( Maybe it helps, maybe not ;)
[HTC Wildfire S] :
All that for a Hello World!!!!!!!! That is exactly what I mean by "writing a Hello World seems to take forever". That's pretty much why I drink Java, and not Coffee. LOL. That makes no HTC Sense!

For the folks out there who don't know how to program but think that Hello World was simple, eat this!

system.out.println("Hello all the people who have no programming experience but think writing Hello World in C is simple!!!!!");

Yes, yes. I know I lied. You have to write all the stuff about the classes and methods! But guess what! NetBeans does that for you!!! Also, devs who write Android apps do ALOT of that!!