yashsingh1/xdaforums huggingface dataset:
[HTC Wildfire S] no.human.being:
I have the impression that you're not reading what I am saying. You cannot overwrite NAND "in place". You have to

erase

it first. Erasure is an operation that's completely distinct from writing. When you read memory that has been erased, all bytes will read as 0xff. However, "physically", the states of "erased memory" and "memory holding the value 0xff" are

completely distinct

. Only when a page is in an erased state you are allowed to write to it.

We currently cannot erase the pages holding HBOOT (or any page that's part of the Radio partition) either, since they appear to be "corrupted" (either intentionally or simply because the Radio uses a different layout for the out of band area of the pages than Linux/Android does) and every kernel we know of (including CyanogenMod, ClockWorkMod, etc.) has a check in its mtd driver that refuses to erase these corrupted pages. Once we have a kernel that builds from source, we will simply remove these checks from the mtd driver, making the kernel perform every erasure that it is requested to perform, no matter if the page appears to be corrupted or defunct or worn out. After we boot that kernel, we will be able to erase the pages holding HBOOT and after they are erased, we will be able to write to them. (Question is whether we have to implement the "corrupted" format when writing to them, as the Radio may not be able to read pages written in "normal Linux/Android format".)

Writing to NAND pages when they are not in an erased state will either result in the data not being written at all (this is the best case) or it will result in data becoming entirely corrupted, so that neither the new nor the old values are gonna be in NAND, but only "junk". It's simply an operation for which the memory has not been designed physically, so

always explicitely erase

and

verify that the erasure has succeeded

before writing to NAND on the device level. How NAND behaves when writing to a page that is not in an erased state is completely undefined. The chip may literally do "whatever it wants" if you violate the read --> modify --> erase --> write "protocol".
[HTC Wildfire S] munjeni:
Dude, I understand you completely, but please understand me! I know that I need to erase page first before I write to nand, but how to erase it becouse flash_erase tool could not working in my device, so it is reason why I trying to understand you! So conclusion in my head is how you erased nand using flash_erase tool? And what kernel you used for your "boot" using fastboot command? I definitely tried everything including:

- one byte access (writing)

- fwrite (4096)

- erase page with flash_erase (got error -5)

- custom mtd driver function -> modified code inside msm_nand -> is_block_bad (tried to mark an block as bad and to write data to it block without sucess)

- flash_unlock (got function not implemented)

- writeb()

- writel()

So apsolutelly there no way to do anything on "protected area" and apsolutely no way to "change" or to "modify" (at least one one one one byte inside that protected area) and no way to brick device but I want to brick it!
[HTC Wildfire S] no.human.being:
It doesn't work for us either. This is the only reason why the WFS is not S-OFF yet. The "flash_erase" tool asks the kernel to erase the pages. The kernel looks at the "out of band" area of the page in question, sees that its format is "weird" and then refuses to erase it.

We currently can't erase either. This is the point where we're stuck. Everything else works, just erasure does not.

We're using CWM recovery as the operating system where we're running the exploit on. We'll have to get a kernel that successfully builds from source and runs on our devices, then we'll modify the source of the mtd driver in that kernel to make it erase the "corrupted" pages that make up the Radio partition (that HBOOT is part of) as well. Once we got that, we can run "flash_erase" on that kernel and then it will succeed. And once the erasure succeeded, we can write another HBOOT (e. g. the S-OFF patched HBOOT our exploit produces) back to NAND.

We're both stuck at the same point. I'm having a "solution", but I currently can't implement it, as I've never managed to build a kernel that successfully runs on our device. This is why the thread is titled "Kernel experts needed". We really need to get expertise into this in order to get a custom kernel built that successfully operates the device so that we can run our exploit upon. :D

Compare this:

#include <stdio.h>

int main(int argc, char** argv)
{
printf("Hello World!\n");
return 0;
}

To this:

class Main
{

public static void main(String[] args)
{
System.out.println("Hello World!");
}

}

Wow! So much more complexity in C! :D

But you're right that complexity will become greater in C the bigger the projects become. That doesn't mean that C is inferior to Java though. They're simply built for different purposes.

Java's strong side is that it is a garbage collected language, so most of the memory management is done by the virtual machine, while you have to explicitely "malloc(...)" and "free(...)" in C. It's also compiled into bytecode instead of machine code making it portable among lots of architectures without recompilation of the application code (only the virtual machine has to be ported over and then all the applications that are compiled to bytecode will start working). However, performance of "carefully hand crafted" C code may be higher ("trivial" C code is often an even worse performer, as the Java virtual machine itself is written in C and is carefully optimized). I've written great applications in Java, including one that predicts the orbit of a satellite and drives stepper motors rotating an antenna for keeping the transmission "beam" focused as the satellite "flies over". Java was very convenient for this purpose. Of course you could do it in C, but it would have been a pain, take more time to implement and probably not be very portable, as the libraries you're using when coding in C are often platform-dependant.

However, the real strong point of C is system level programming. You just can't write operating system level code (kernels, drivers, ...) in Java. And you usually can't write exploits in Java. :D
[HTC Wildfire S] munjeni:
I not understand you! You say:

but I see in previous post from ONeill123 inject log that flash_erase and flash_unlock working:

You confused my head completely now! Flash_erase working or not working? Or it working only with recovery kernel? If yes, where to look for source of that recovery kernel? ...etc
[HTC Wildfire S] no.human.being:
LOOOL! Who says that it's working? :D

Our exploit is calling "flash_erase" and I'm not aware that it provides any "return value" that indicates success or failure, so the exploit just "assumes" success, opens the file handle for writing and calls "fwrite(...)" (indicating "Step 6: Writeback ..."). The call to "fwrite(...)" claims that the data was successfully written, so we say "[ OK ] Done!".

As long as the calls don't return an error code, we assume success. That is the convention. We can't distinguish whether the operating system kernel really writes if we call "fwrite(...)" or if it just says "lol, never gonna write that for you" but nonetheless returns success. Fact is that it doesn't return an error code, so from the exploit's view it's a success. In reality, the NAND content is not changed as the erasure failed due to a kernel-level restriction. The exploit is not aware of that fact though, as the return value indicates success, so the exploit just moves on and eventually claims "success" as well. :D

I'm not aware of any kernel that will allow us to erase the corrupted pages. We'll have to take a kernel that works for our device and modify its mtd subsystem in order to make it erase corrupted pages. But currently, we're not having any kernel that successfully builds for our device, so we're stuck. That's why the thread topic claims "kernel experts needed".
[HTC Wildfire S] munjeni:
So if I understand, exploit is in preparation-stage for writing/erasing (but not working?) and you looking for way to hack kernel that will be used for inject program? And at least your program not writing to nand? Whole thread is only an theory?

Wildwire S do not have kernel source? Cyanogenmod kernel source?:eek:
[HTC Wildfire S] MrTaco505:
So nbh, are you sure the patch is correct because it looks like the flash_erase is working due to an automatic restart after the nand write so maybe you might need to revise it one more time

I'm still pissed off *se-nsei :mad:
[HTC Wildfire S] munjeni:
Sorry dude, my english is not good so maybe you misunderstanded me here, but I understand you now, you are here same as me, I have everything patched for htc hd mini, created hspl for htc hd mini, I know how to patch it to disable everything for example to flash diferent model id... etc but only problem I have is like problem you have here (last step - writing it back to flash), so please do not misunderstand me here becouse my bad english, I want to help and also need help, and I think msm7227 that is inside aria/gratia/hd mini/wildfire s...etc with other hardware parts that is inside is 90% the sime in booth decices (I confirmed it while run wince rom in aria), so I think if someone wind a way, he will find a way for all device that runing the same procesor, so Im here to help/learn and not to post funny things to developers that working hard, so Im sorry if you misunderstod me when I sayd "its teory", I thinked its done for wildfire... I realy want to learn/help, its my hobby. If you want I will try to modify mine kernel in order to test/try it for wildfire? Did you tried it allready and what kernel source you tried?
[HTC Wildfire S] no.human.being:
Your phone reboots after the exploit has written? Interesting. Mine doesn't. I also don't request a reboot from the operating system, so it's probably actually a "side effect" of the changes in NAND.

To check whether your HBOOT has been patched, dump it to the SD card (map it as "mtd7" and then "cat /dev/mtd/mtd7 > /sdcard/hboot.img" with your SD card mounted in CWM). In the dump, search for the following byte string with a hex editor.

10 40 2d e9 00 00 a0 e3 10 80 bd e8

It's one of the instruction sequences that gets "patched into the HBOOT image" by our exploit, so if you find it, our exploit succeeded and your HBOOT is modified, but we probably didn't patch the right subprocedure. If you don't find it, your HBOOT is not modified, most likely because the CWM kernel didn't erase your NAND before we wrote to it.

EDIT: There's an easier way of finding out whether your HBOOT was patched. Just run the exploit again on your device. The exploit won't run to "[ OK ] Success!" if the HBOOT on your device is already patched. Instead it will claim "Incorrect security code for HBOOT". This will save you from reviewing the HBOOT code with a hex editor.
[HTC Wildfire S] :
Yes, I was very pissed before, but now I've learnt to calm down. Please let me do the same for you. Forgive his amount of OT tolerance. We all want to get along here. If you must carry this on, take it the the PM thing. Because I'm saying this, you can be pissed with me to! But either way, It's not helping us get S-OFF.

Sent from a Time Lord, using his TARDIS.
[HTC Wildfire S] :
I know when I'm beaten. :(

Do you have a good place where I can learn C online? Maybe I should learn it too! Maybe both! I could be much more useful-ish if I learn both! Anyway, how's things going. Are you feeling OK?

Sorry, but I like to look out for good friends, so I can be sure they are OK! Next up! My future GF! But I don't think that's gonna happen. :(

Sent from a Time Lord, using his TARDIS.
[HTC Wildfire S] no.human.being:
Uargh long quote! :D

---------- Post added at 12:24 AM ---------- Previous post was at 12:09 AM ----------

I tried it using "vanilla" Linux kernels from kernel.org, both 2.6.35 and 3.2.5. The first was extremely bad quality. It had so many errors that I couldn't resolve, so I never got to build it. The second was better. Had to correct a few dozen lines of code and configure a lot but then it built. I then built an initrd containing a minimal GNU system around it and packaged it all together using "mkbootimg" from the Android SDK, then booted the image via Fastboot. However, the device always locked up with a white screen, not reacting to anything.

After that, someone had the idea that we could use CWM recovery for this purpose and so far it worked great, but it won't let us erase the NAND pages that have the "Radio memory format". Other "stock" Android or even "vanilla" Linux kernels won't let us erase them either, so the kernel not erasing them is not a "measure to distract us from hacking the HBOOT". It really seems to be a "security measure" preventing the kernel from erasing pages which are of a format that the kernel doesn't understand. It's just that HTC seems to "abuse" it for protecting the Radio area by making use of a "corrupted" format for this area.

Or maybe it's just that the Radio firmware, being an entirely different and much more primitive operating system than Linux is, simply makes use of a different memory format and it just gets in our way "as a side effect". After all, you can't expect that every obstacle that you come across has been carefully crafted by HTC or Qualcomm or Google or ... to distract us. Sometimes it's just a design decision that was done for a completely different reason and now randomly gets in your way. Anything else sounds too much like a conspiracy theory, doesn't it? :D

Whatever the case, as soon as we can build a kernel from source, we can try removing the checks that are performed prior to NAND erasure. This should enable us to literally erase anything that's in some way addressable. :D

---------- Post added at 12:41 AM ---------- Previous post was at 12:24 AM ----------

No problem. According to Bad-Wolf, my English is bad too. :D (Now before you start beating me, Bad-Wolf, this is only a joke. I'm not offending you for saying it. I know it's not perfect and I know you only made fun. However, I must admit that I'm writing quite "sloppy English" here. When I'm writing, say, a research paper, I tend to take much more care of the language, but in this forum I think it's ok as long as I get the general idea across. :D )
[HTC Wildfire S] MrTaco505:
I'm just saying that O'Neil's ers rebooted after the patch and still said s-on but nog sure if its true.

I'm still pissed off *se-nsei :mad:
[HTC Wildfire S] :
Do you know German? LOL.

BTW, what's initrd?

Sent from a Time Lord, using his TARDIS.
[HTC Wildfire S] pther:
Building a kernel

Hey guys. I can build a kernel from source, but cannot get it to actually boot. No idea (yet) what i'm doing wrong, but i'll share anyway:

Note that this will _only_ built a runnable kernel. It wil not be usable for any rom development, but may just be enough for our purposes.

get a toolchain. Mine is called arm-linux-androideabi-gcc etc. from the Android NDK. They must be in the PATH.

get kernel sources. Mine are the stock sources from htcdev.com (marvel-gb-mr-2.6.35-a66971c). Extract them.

get a kernel .config file to configure the kernel sources. Two ways to obtain this.

extract it from a running stock rom:

> adb pull /proc/config.gz
> gunzip config.gz
> mv config .config

extract it from the boot.img included in a stock rom zip-file. This scripts is included in the kernel-sources. This is what i did.

> sh scripts/extract-ikconfig boot.img

You put the config file in the kernel source root directory (probably called marvel-gb-mr-2.6.35-a66971c) and make sure its named '.config' (note the dot).

This file will make sure that the kernel you are compiled is configured exactly as the kernel you are running (given that you use the same sources).

run

> make ARCH=arm CROSS_COMPILE=arm-linux-androideabi- oldconfig

This configures the kernel source using the existing .config file. If the config file matches the kernel sources this should complete automatically. Otherwise you might get some nasty question about what drivers to support in the kernel.

run

> make ARCH=arm CROSS_COMPILE=arm-linux-androideabi-

to actually compile the kernel. Go drink a coffee. This makes a kernel image in: ./arch/arm/boot/zImage

create a ramdisk. The ramdisk image is a cpio-ed and gzipped filesystem containing an initial filesystem to boot from. The init.rc script in here is the first called after the kernel booted and will make sure all filesystems are mounted etc.

Eventually you could probably just include the exploit completely in this ramdisk.

I actually just took the ramdisk from the stock rom, for now. My research shows there is not that much difference between the ramdisks of most roms, except some interesting settings in build.prop

Boot the system

> adb reboot bootloader
> fastboot boot zImage ramdisk.img

This boots the kernel on my WFS, but it currently gets stuck on the HTC logo with no feedback at all. I'm quite sure there should be nothing wrong with the kernel or the ramdisk.
[HTC Wildfire S] *se-nsei.:
Jheeze man relax I'm sorry if I offended you. Just trying to push development that's all.
[HTC Wildfire S] no.human.being:
Well building is ok. I've even got a Linux 3.2.5 built some time ago (after a great amount of hacking around in the sources :D ). The problem is that it doesn't boot, but "locks up" before providing

any

output, so it probably locks up at a very early stage, before the framebuffer is initialized. That's why there's still the HTC logo (which firmware component draws that btw? the Radio?) on the screen.

It means "

init

ial

r

am

d

isk". It's what is loaded besides the kernel and contains the code that is first executed after the kernel has booted. Imagine the kernel boots the system and then what happens? The kernel can't interact with the user, it can't execute scripts. So you have to provide more code that will run "on the kernel" and do these things. This code, that gets executed when the kernel has just finished booting, is the "initrd".

When your system is small, you may actually put your entire operating system (most important the "init" process and the scripts it executes, but also the shell in "/bin/sh", all the tools in "/bin" and "/sbin", configuration files in "/etc", device special files in "/dev", mount points for special file systems like "/proc", etc.) in it (that's what we plan to do).

When your system is larger, you usually build an initrd that's "just smart enough" to bootstrap the "actual" operating system (that's what most ROMs probably do, they have an "initrd" that's "just smart enough" to mount the file systems on the device's NAND). :D

However, we want our system to be self-contained, so we're probably gonna stick with the "minimal system entirely in initrd" variation.
[HTC Wildfire S] theq86:
Yes. At least the splash image lays in the radio area and is probably showed by hboot or after hboot. but before control is handed to the android kernel.

you can flash it if you are eng-s-off with fastboot flash splash splahimage.nbh

Afterwards the kernel initializes and shows the bootsplash (which is the quitly brilliant animation. because the radio splash only supports static images)
[HTC Wildfire S] BeciMester:
Just some quick thoughts, I'm having a mad time at college ATM.

The subroutine we're currently patching is 100% the right one, I had a quick look at the patched hboot images for the Desire (Bravo), available from alpharev.nl, and they did it the EXACT same way I did. :D

As for erasing/flashing: obviously the hboot is able to do it, so we should take a closer look at how it's done there, and if we find out, incorporate the appropriate code into n.h.b's exploit. This is the road I'll go down as soon as I have a free afternoon.

As for kernel mods: instead of vanilla Android, just take the source of a custom kernel that's proven to build and boot, and search around in that for the parts that need to be modified. :) Or, since we boot into CWM via fastboot right now, just look at the CWM source.

Guys, this is a DEVELOPMENT thread. PLEASE quit the bickering, nobody's interested in it, there are other threads for that. Stop acting like 12-year-olds. Contribute ideas, code or research, organize help, THAT'S what your posts should be about. It's sad that it has to be pointed out again and again, but I'm sick of sifting through useless comments to keep track of progress. :( You know who you are.
[HTC Wildfire S] no.human.being:
Lol, so we're literally bringing Revolutionary to the WFS. :D

The problem is that HBOOT runs in "supervisor mode", but our exploit code is running in "user mode". The kernel we're running on runs in "supervisor mode". So our exploit code probably can't do what HBOOT can do. We have to make the kernel do it.

However, I'm not sure if we really have to do exactly what HBOOT does. It might be enough to get the pages "erased somehow". The reason we currently can't erase is that the memory format (the stuff on the NAND's "out of band" area) of the "Radio partition" (that HBOOT is part of) is different than what Linux (or Android) does on a standard "data partition". Our exploit asks the Android kernel of the CWM image to erase the pages holding the HBOOT. The kernel looks at the pages and sees that they are not in a format that it's supposed to understand and then ceases to erase them, probably in order to "avoid damage".

In order to get the pages erased, it would be sufficient to remove the "memory format" checks from the kernel's mtd driver. After that we should be able to erase everything that we can address. However, when we write our "patched HBOOT image" back to NAND after erasure, the Android kernel will of course write in "Linux memory format", not in "Radio memory format". I'm not sure if this actually is a problem, as it only affects "out of band" data, not the "actual data" on the partition, but the Radio might be confused when suddenly the HBOOT inside its partition has a different memory format (that the Radio probably won't understand, just like Linux doesn't completely understand the format that the Radio uses). If this is the case, we'll most likely have bricked the phone.
[HTC Wildfire S] pther:
Kernel

Got a running kernel!!

Apparently we need some different addresses for kernel loading and ramdisk loading:

kernel_addr = 0x12C08000

ramdisk_addr = 0x13C00000

second_addr = 0x13B00000

tags_addr = 0x12C00100

This means just booting a kernel with fastboot will not work.

I included a patched mkbootimg that will immediately create a correct boot.img.
[HTC Wildfire S] no.human.being:
Yeah, thanks. Do we need to adjust addresses in the kernel's config too? If I remember correctly there are also options for "base address" and stuff when you build the kernel from source.
[HTC Wildfire S] pther:
I edited the post above a few times since i was not completely accurate.

Anyway, i can just compile the stock kernel sources as i described a few posts earlier, then use my modified mkbootimg (in previous post). Then i can boot the resulting boot.img using fastboot.

I can verify that it runs indeed my modified kernel and ramdisk (since i made some slight changes).

---------- Post added at 11:37 AM ---------- Previous post was at 11:35 AM ----------

A quick grep on the HTC sources says: yes.