yashsingh1/xdaforums huggingface dataset:
[HTC Wildfire S] no.human.being:
As long as we patched the right function. For this I just did what BeciMester said, but it seems reasonable. :D

And we only need erasure. Reading already works perfectly and writing will work when the memory is erased. It already works (writes) on normal files and it will also work on devices using memory that's handled by the "mmcblk" driver instead of the "mtd" driver, since the "mmcblk" does the "read-modify-erase-write" on its own (in hardware). But, unfortunately, our phone uses a memory controller that implements the "mtd" protocol and as such requires explicit erasure.
[HTC Wildfire S] :
What have we achieved by me testing the exploit?
[HTC Wildfire S] MrTaco505:
Well I don't think you did it correctly but all we need is to find a way to erase the nand and we will see the end of the rainbow:D
[HTC Wildfire S] :
I did do it correctly. I did exactly what theq86 said. I think we found our that even though the mapping and the version string are different, the future exploit should still work if the option that covers the actual mapping is selected. I keep saying mapping. I have a good idea of what it means but then again I don't know about memory. LOL.

Sent from a Time Lord, using his TARDIS.
[HTC Wildfire S] no.human.being:
It's not that complex actually. The NAND has a "physical" address space of 0x00000000 to 0x1fffffff. At each of these addresses, a single byte of data is stored. At least for read access that is. Writing always happens in "pages", which are 128 KiB in size, so whenever you want to modify a single bit, you have to write at least 128 KiB, since that's the smallest amount of data that the memory can write "atomically". The memory chip itself can't write single bits/bytes/whatever, but only multiples of 128 KiB at once. This is because physically, the transistors that hold the 128 KiB share "common substrate". A FET (field effect transistor) has 4 "connections" called "drain", "source", "gate" and "substrate" and, on the semiconductor level, the "substrate" of a bit more than 1 million transistors (that's what you need to hold 128 KiB of data) are connected to each other. So this is a "limitation" that's due to how the memory is manufactured. The kernel then divides this "flat" (as it is called) physical address space into "partitions" (which you see as "mtd0", "mtd1", ...). To do so, the kernel needs to set up "page tables", which define the physical address where the partition begins (this will become the equivalent to virtual 0x00000000 then) as well as its size.

Let's say we tell the kernel that mtd0 begins at 0x00200000 physical and is 0x00040000 in size (this is just an example). When we then access mtd0 at address X (this is a virtual address), the kernel checks whether X is 0x00040000 or higher. If it is, we are outside the partition boundaries and the kernel will probably return an error. So usable addresses are always 0 to (SIZE - 1) virtual (so 0x00000000 to 0x0003ffff in our example) inclusive.

However, if the virtual address does in fact reside inside the partition bounds, the kernel adds the physical offset and then does the access for us (so it reads/writes/erases at 0x00200000 + X whenever we read/write/erase at X). That's basically all. Not all that "magic" actually.

I must say that I have no idea how NAND access is actually achieved by the kernel at the "machine instruction" level. There might be another, lower level address translation going on by the controller which puts RAM and NAND into a single "flat" address space, but this is just a guess.
[HTC Wildfire S] BeciMester:
Now I'm no expert on the matter by any stretch, but I reckon the hboot takes care of the page mapping in our case: I've found the page table in the hboot code the other day, so the hboot has something to do with paging as well. All credit goes to TJ, without his work it'd have taken much longer to figure out what I'm looking at. :D I'll post the info later tonight if there's any interest, the important bit is that it confirms that the hboot is at 0x00000000 physical/0x9d000000 virtual.

(I'm on my phone...)
[HTC Wildfire S] a.s.j:
Maybe a stupid idea.. but you asked for experts... Try to look into the Kaiser section, we managed to put Android on WinMo6 device with totally custom kernel. Maybe they can help too... at last with some ideas..
[HTC Wildfire S] seaskyways:
Guys , i will make a call for linux and kernel experts at the Android hacking forum , maybe this will help !
[HTC Wildfire S] :
Thanks NHB! Very informative. It's only a tiny bit confusing!!

Just a question. In a hex editor, I can see stuff like:

2f 2f 8e etc..

So is one 2 digit part:

2f

a byte?

and a one digit part a bit?

---------- Post added at 07:09 PM ---------- Previous post was at 07:05 PM ----------

Ah..... My uncle had a Kaiser. But it broke, so he got another phone from insurance, and sold it to get money to get an iPhone 4.

I've got a TyTn (Hermes), with WM6. Little less advanced then Kaiser.

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

How far are we.
[HTC Wildfire S] theq86:
1. Yes. One tuple is a Byte.

2. Not bit, a single hex value is half-a byte.

e.g

(hex) F F means (binary) 1111 1111 (decimal) 255

the decimal system is the number system we commonly use. decimal means we have 10 'characters' being able to form a number. those characters are:

0, 1, 2, 3, 4, 5, 6, 7, 8, 9

then there is the binary system. in that system we only have two characters to form numbers. those are:

0, 1

the hexadecimal system uses 16 chars to form numbers. but we only have 10 arabic characters do describe numbers because we use the decimal system. the 6 missing characters are represented by the 'numbers' a, b, c, d, e, f. So the pool of characters for describing a hexadecimal number are:

0, 1, 2, 3, 4, 5, 6, 7, 8, 9, A, B, C, D, E, F

If you want to know how the numbers are calculated you should take a read on wikipedia e.g.
[HTC Wildfire S] no.human.being:
It's definitely NOT at 0x00000000 physical in NAND. There is the Radio. It's at 0x02b00000 physical (HBOOT-1.08.0099) or at 0x02400000 physical (HBOOT-1.09.0099) in NAND. What you mean is probably RAM addresses. When it's executed, it's already loaded to RAM by a lower level firmware so whenever HBOOT accesses anything "within itself", of course it accesses RAM, so you see RAM addresses, not NAND addresses. What we were talking about were physical NAND addresses (as we actually patch the NAND content) and HBOOT is either at 0x02b... or at 0x024... there.

@Bad-Wolf: Yes, "2b" is one byte (we sometimes write it prefixed with "0x" to make clear it's hexadecimal). One byte can have values from 0x00 (0 decimal) to 0xff (255 decimal) for a total of 256 different values. The first digit (the "2" in this example) represents the most significant "nibble" (one "nibble" = 4 bits), the second digit (the "b" in this example) represents the least significant "nibble" (4 bits). So it's like in our number system. 123 (decimal) means 1 * (10 ^ 2) + 2 * (10 ^ 1) + 3 * (10 ^ 0) and 0x2b (hexadecimal) means 2 * (16 ^ 1) + 11 * (16 ^ 0). So the 0xb is 11. Of course 0x9 is 9, then comes 0xa (10), then 0xb (11) and so on up to 0xf (15).

For values greater than one byte (e. g. the word size of ARM is 32 bit or 4 byte) it's a bit more confusing. The processor can operate in "big endian" (most significant bits at lowest memory address) or "little endian" (least significant bits at lowest memory address) mode. What you see in your hex editor is low (left) to high (right) addresses, so when the processor is in "big endian" mode, something like ...

0x01234000: 8b f2 3c cd

... when read as a (32 bit) word from 0x01234000 is interpreted as 0x8bf23ccd. However, when the processor is in "little endian" mode (where it almost always seems to be, all the values I've seen in Radio/HBOOT/Android seemed to be "little endian"), it is interpreted like 0xcd3cf28b, like if the bytes were read "from high to low addresses". So basically you have to read the bytes "from right to left" but the two digits within the same byte "from left to right". It seems a bit awkward at first, but you actually get used to this quite quickly.
[HTC Wildfire S] seaskyways:
This is kinda outta topic but actually i wanted to say something:

I knew these where arabic ! Here in Lebanon they teach us 1 , 2 ,3 as English numbers @: ... and moreover , the "arabic" numbers that they teach us are persian ....
[HTC Wildfire S] mobilescooby:
Guys I believe I have one of those exotic memories as mentioned before on my old wfs which has broken touch! You may remember I helped testing the original exploit!

You want me to test without safety? And report back?

As mentioned before I'm mazumaing it anyway so makes no odds if it bricks!

Regards
[HTC Wildfire S] no.human.being:
You can test it with "./inject /dev/mtd/mtd7" and it'll either claim "Done!" (success) or an error.

In the former case, your firmware is already supported and would get patched (turning your handset S-OFF) if you supplied the "--disengage-the-safety" parameter and mtdutils could erase the NAND (which they probably can't do at the moment, so almost certainly no S-OFF at the moment).

In the latter case, your firmware fails one of the many checks that the exploit performs. In this case you could post why it's failing (just post the error message or the entire output if you like) and we could try diagnosing what went wrong. In this case we'd most likely need a Radio dump if we were to support your firmware as well.

However, I'm not sure if we should already "go broad" (supporting many firmware versions) or if we should stick with the two configurations we're currently supporting until we get it done for them (keeps things simple and might make it easier to debug) and "go broad" afterwards.
[HTC Wildfire S] seaskyways:
Did you try to write a single byte just to test it ?? and then recover this byte , just that we make sure the flash_write utility works fine , and then we'll be stopped at either the flash_erase , or both the flash_erase and the kernel ... but we have to ensure something successful first , shouldn't we ??
[HTC Wildfire S] theq86:
at the moment 1.0X.0099 where only two exists (x=8; x=9) are the only ones we CAN support, remember? Can't run our custom parameter kernel without unlocked state and won't unless bootloader is cracked (which is a totally different story)

However, we found out that "exotic" people may be able to use the partition mapping from the other version since partitioning not depends on hboot version.

We can only write pages or blocks. even if we'd change a block only consisting of 0x00 or 0xFF it can not be forseen which effect it had.
[HTC Wildfire S] mobilescooby:
Okay I'm away from computer at moment so I will try tomorrow and report back!

Regards
[HTC Wildfire S] no.human.being:
Exactly.

Remember each NAND block also has an associated "out of band" area and the kernel stores ECC (error correction / parity) information there. In theory you can overwrite pages without erasing them, as long as the "new" value is a "subset" of the old value (has 0s everywhere where the old value also has them) as changing 1s to 0s is possible without an entirely new erase-program-cycle on the physical level.

However, since the kernel stores this redundant information and we can't really control this, it'll become corrupt even when just overwriting 1s with 0s on the "normal" data area, since the parity in the "out of band" portion probably won't only change 1s to 0s.

And "pages" and "blocks" are not exactly equivalent, even though I use both terms quite interchangably since you rarely have to deal with "pages" and almost always deal with "blocks". "Blocks" are 128 KiB and "pages" are 2 KiB. So each "block" consists of 64 "pages". "Blocks" can be written in a "random access" manner, but all "pages" within the same "block" have to be written to in sequential order. Writing less than one "page" is basically impossible. You'll have to fill it up with zeroes or whatever and once you've done that, you can only write to the next page. In practice, you'll almost always program a "block" at once, since you cannot "randomly" program "pages" so the advantage of being able to sequentially program "pages" without programming the entire "block" is negligible.
[HTC Wildfire S] seaskyways:
I am just having a general question , if the hboot was damaged , couldn't it be recovered by the RUU or flash_image ??
[HTC Wildfire S] no.human.being:
I don't see any problem with that, as long as it's not SO MUCH damaged that the system doesn't boot. Remember that HBOOT is what the RUU uses to write to the phone NAND. HBOOT is basically the "server" running on the phone and the RUU only sends it the data over the USB cable that HBOOT then writes to NAND. If your HBOOT is so severely damaged that it doesn't boot anymore, you'll have to resort to JTAG repair (unless the Radio can somehow flash the HBOOT, remember the Radio is even more low level than HBOOT so Radio can run without HBOOT, but HBOOT can't run without Radio).
[HTC Wildfire S] MrTaco505:
so what are we doing right now because i really dont see progress

SO QUIET! O_O
[HTC Wildfire S] no.human.being:
Wait, what have I just said? RUU = Radio Update Utility, right? So it's designed to update the Radio, right? Wouldn't it be strange if a "higher level component" (HBOOT) could update a "lower level component" (Radio)?

:confused:

Is the RUU really "installed"/"flashed"/whatever only by HBOOT?
[HTC Wildfire S] theq86:
I don't think the radio has flashing capabilities for HBOOT. Since the executed hboot is in ram it can flash itself without violating it's running state. the radio is just what it's name refers to.

I read on a page which has had a list of radio functions and commands. the only interface the radio has is a serial modem interface allowing AT commands to be passed to the radio. none of the AT commands is meant to flash anything. So even if you still could get serial radio access via usb, you could not use it to flash anything.

And then the only other way would be JTAG.
[HTC Wildfire S] no.human.being:
But which component updates the Radio? HBOOT? :confused:

Radio is actually "closer to the metal" (from a software layer view) than HBOOT is. HBOOT is already "application domain" (not to be confused with "user mode", it's definitely "kernel mode", but it's "application domain", while Radio is "baseband domain", which is lower/more privileged/closer to the hardware). It's on the same level as the Android kernel actually, since basically all it does is "prepare" the controller for Android to run, then load it into memory. As soon as Android runs HBOOT is "dead", so booting Android basically "replaces" HBOOT in the software stack.

But Radio is "beneath" both. Radio has full access to hardware (especially transceivers, as that's what it's designed to control) while HBOOT and Android need to talk to the Radio via shared memory mechanics if they want to access and I/O on the controller.

Wouldn't it be "strange" if HBOOT was updating the software it is running "on top of" (Radio)? I mean from a "CPU ring" level they actually run "side by side" (both in privileged mode within their own virtual machine), but Radio has hardware access and HBOOT/Android use remote calls to Radio for hardware access.

Well it's definitely gonna become even more quiet, much more quiet possibly, since I'm getting much busier with my studies from .. eerm .. TODAY on. :D
[HTC Wildfire S] :
No. Despite the fact its not, let's just say that HBOOT is one of the first things that boots.

Think of it like this:

#######

#######

#######

#######

It's like a building, with levels. The top level is the high level people, Android. The bottom is the kernel, like the backstreet electricians, making sure things work. If a real brick was to fall through this building, depending on the brick, people on different levels, starting from the top, will die. Therefore making the level a brick. Although, the backstreet electricians and their friends might survive, and they have the special stuff for new blocks (parts of a building) to go through, rebuilding the organisation. Despite all this, if a very strong heavy brick brick falls and destroys all the levels, you are then left with a perma-brick. Unless you can afford it, you can get a JTAG or something, and rebuild the entire building, part by part. You would be rewriting the EPROM, the very core of the building. Aka, the NAND. Unless you are a thickety thick head, bricking this is proper hard, but you can use NAND to recover it, you'd need a lot of code though. The only way to brick it permanently, is to go to a DIY store, buy a brick, and make the NAND go ka-put!

I hope that was easy to understand! LOL. :D

Sent from a Time Lord, using his TARDIS.
[HTC Wildfire S] theq86:
As I see, yes. RUU will take the phone into RUU mode. You can manually do this with

fastboot oem rebootRUU

This (along with other functions) is provided by hboot. (or at least something HTC calls the hboot mode)

Even this hboot mode can be accessed by a serial connection.

The RUU does upload the rom.zip file that was extracted from the package. and then it is flashed like a PG76IMG file. The only difference is, that the ruu modes returns status and progress messages to the ruu executable. HBOOT is working behind and the black RUU screen is just an overlay. you can check this by enabling RUU mode and unplug the cable. what happens? HBOOT is showing up, stating to be in RUU mode

edit:

since radio and hboot are on the same nand, hboot could execute commands being on the radio (nand) even if the radio (loaded into the ram) has been removed from the ram.
[HTC Wildfire S] :
True. Is ruu mode low level?

Sent from a Time Lord, using his TARDIS.
[HTC Wildfire S] :
I think its actually ROM update utility.

Sent from a Time Lord, using his TARDIS.
[HTC Wildfire S] theq86:
yes, since it it a part of hboot.

but hboot takes a place in between what we call "low" and "high" level.
[HTC Wildfire S] :
So basically its medium level. What's the most low level. And why can't we just download a soff radio and change parts of it like imei to match ours and flash it directly to mtd7, whatever partition its in. That way we can avoid signature verification. Also, where'd the Sig stored?

Sent from a Time Lord, using his TARDIS.
[HTC Wildfire S] no.human.being:
Yeah. Basically from the "processor view" it's like this.

[Android apps] (highest)
[Native apps][ Dalvik ]
[Android system libraries ]
----------------------------------
[RADIO][ HBOOT/Android kernel ]
[ ARM FIRMWARE ]
[ HARDWARE ] (lowest)

The line denotes the separation between privileged (kernel) and unprivileged (user) mode of the processor. So everything "above" the line is user mode, everything "beneath" it is kernel mode.

So from the "hardware view" both Radio and HBOOT/Android (depending on whether the system is booting or already successfully booted) run "side by side" on a hardware-supported "virtualization" provided by the ARM firmware.

From the "software stack" view, however, you can consider Radio to be "lower level" than HBOOT/Android, since it can directly access all hardware, while HBOOT/Android need to communicate to the Radio to ask it to access hardware for them via remote procedure calls. This is true for all "peripherals" (display, transceivers, ports, etc.), but not for memory. Memory can be accessed by both operating systems. However, the control of NAND memory is "handed over" from Radio to HBOOT/Android after Radio has finished initializing. ARM firmware only "lets HBOOT run" after Radio has signalled that it finished initializing. After that "signal", Radio does not access the NAND any more (however it still has the capability to do it, it just doesn't do it anymore to avoid race conditions between the two operating system kernels running in parallel on the same processor) and relies on remote procedure calls to the Android kernel should NAND access be required.
[HTC Wildfire S] theq86:
well, there is no rule what is low level, what is high level.

In our case, to make things easy we call "low level" the things we have no influence to or things which occur before the user, the "real person" can interact with the phone.

high level is anything we can change, have access to and can interact with.

since hboot is the first we have access to (by pressing buttons e.g) but also is the one talking to the radio it is not really high, nor low level.

Why can not only download an s-off radio? The secu_flag is probably not inside the flashable radio images.

And remember. Remember REMEMBER :D

We still can not write to the radio area. We can not flash any radio or hboot yet.

We are not S-OFF. So this is no option.

EDIT:

I think hboot has a way to RPC the radio to flash into the radio area. thus it can indirectly flash the radio. we can't because the hboot frontend checks signatures and stuff. If we'd know how to RPC the radio we'd be able to do everything.

The hboot is acually quite too small to implement all the features as one.
[HTC Wildfire S] no.human.being:
Our kernel can (at least for HBOOT, on the other hand Radio area looks really corrupt in some places) it's just that we can't erase the b*tch for some reason, but this could be a mtdutils-(so userspace)-only problem or it could be a kernel restriction. But essentially we can replace both, userspace utilities and kernel via "fastboot boot", so it's just getting the tools right and then there's nothing stopping us from using them. :D
[HTC Wildfire S] :
Sorry! :(

What are we doing now?

I wish we had a leak, who worked for HTC. He could help us. We could call him Gemeni! Guess where I got that from!

BTW, should I install the latest OTA update, maybe an older version might be helpful. I wish that option would disappear!

Sent from a Time Lord, using his TARDIS.
[HTC Wildfire S] no.human.being:
They didn't design any of these software components, they just "licensed" them. HBOOT is basically a slightly modified Android reference bootloader (that Google created) and most of the Radio firmware actually seems to stem from University Karlsruhe, Germany. :D
[HTC Wildfire S] theq86:
sorry again, are you reading all through ?

nhb said we can write but not erase.

We will have to find a way to unblock the hboot area, erase it and then we are able to write to it.
[HTC Wildfire S] no.human.being:
Better. We will make the mtdutils erase it even though it's "blocked" (I think the flag is actually called "locked"). Of course the erasure will clear the "locked" flag as well and the check is performed by either just mtdutils or by mtdutils + kernel, both of which we can replace. (At least theoretically. :D )

Actually we can't write unless we have erased (luckily, else my phone would have become a brick). But we're gonna be able to write as soon as we've erased. :D
[HTC Wildfire S] :
Anyway, I'm going to sleep.

Good night no.human.being! Sleep tight! Don't let the Sycorax bite!

Good night theq86! Sleep tight! Don't let the Daleks exterminate!

Dream about having a fight with SON and punching him do hard he turns into a girl (SOFF)

Sent from a Time Lord, using his TARDIS.
[HTC Wildfire S] theq86:
Let's say we have done it successfully. Should we re-mark the memory "locked"?

Maybe a lower level checks for the locks?
[HTC Wildfire S] Will32:
Hey guys, I try to read as much as I can here, and I try not to post because I'm not a pro and I don't wanna waste yalls time. I read todays posts and haven't seen anything about this. Unknownforce had a major breakthrough last night in the EVO 3d forums. He successfully downgraded our 1.5 hboot to 1.4 so that we can s-off. He intentionally radio bricked, then revived through emmc mode or something.

I don't know how much this device and the 3d have in common, but they're both HTC, so this might help a little.

If yall know about this and it useless to you then sorry, just trying to be helpful :)

Here's the thread link. It's in EVO 3d development in the stickys.

http://xdaforums.com/showthread.php?p=23633951
[HTC Wildfire S] heavy_metal_man:
:eek::eek::eek: that must have took balls to work out!!! fair play to that man!