yashsingh1/xdaforums huggingface dataset:
[HTC Wildfire S] BeciMester:
No, not really. If the command works on heavy_metal_man's (or anyone else's) S-OFF'ed phone, they could dump a hboot image for me to look at.
[HTC Wildfire S] hahahafr:
I understand. Now you don't look anymore for the secu_flag, rather just to tamper hboot.

By the way it's really named "secu_flag" with the underscore and everything:
[HTC Wildfire S] MrTaco505:
What is it to do once we find the secu_flag ?
[HTC Wildfire S] BeciMester:
No, I don't think you understand. As I've said before, I'd like to have a look at a 'live' hboot from a real phone, not a 'sterile' hboot image ready to be flashed. There are differences which were explained before, and those differences might lead us to the location of the flag.

Let's not turn this into a slagging match, I'm here to find a way to S-OFF this phone.
[HTC Wildfire S] no.human.being:
You might need the volatile memory contents of the phone instead of the persistent memory contents for this. Let me try to explain why ...

When the code is executed, it already resides in volatile memory and the image file you have is for the persistent storage. So there's code that gets executed before HBOOT that loads the HBOOT from the persistent storage into the volatile memory so that it becomes ready for execution. This code might load some other image from the persistent storage to the volatile memory location that HBOOT will then read. So you'd probably either have to get an image of the volatile memory of a phone that has HBOOT loaded (could probably be obtained via JTAG, don't see any other possibility) or find the code in the persistent storage that loads the HBOOT (and other stuff) into volatile memory and then begins to execute HBOOT so that you know how it is all laid out in volatile memory or from which part of the persistent storage the data that HBOOT later reads from volatile memory stems from. You know what I mean?

Well of course. You can zergRush a non-rooted Android into a rooted adb shell. The exploit I'm developing for S-OFF will most likely require root permissions to do its work and you cannot get permaroot on an S-ON phone as this is what S-ON was designed to prevent.

So first you'll have an unrooted, S-ON phone, then you root it with zergRush (this does not do anything persistent, as soon as you reboot the phone all privileges are lost) which gives you a root shell. Then my exploit has the privileges it needs to access the storage and turn the phone S-OFF.

Same goes for the dumping process. ZergRush the phone to obtain a root shell, then you run my dumping program on that shell and you'll obtain the dumps.
[HTC Wildfire S] meanmug:
That may not do any good since there's no value present for secu_flag, try searching again this time look for a value next to secu_flag.
[HTC Wildfire S] no.human.being:
We will actually require the MTD utilities for erasing the device's NAND before we can image back our patched image files so thanks in advance. We'll definitely need this at some point.

Won't be there. It's a string. It's 0x73, 0x65, 0x63, 0x75, 0x5f, 0x66, 0x6c, 0x61, 0x67 which is "@secu_flag", then there's 0x20 which is a whitespace, then 0x00 as strings are zero-terminated in C. It's probably part of a binary file of a utility that checks the secu_flag and outputs something like "@secu_flag 0" or "@secu_flag 1" depending on value so for outputting, it loads the string from that address, then puts some number behind, does strcat(...), then printf(...). Doesn't look THAT promising to me ...

I doubt that there will be "text" around the real flag, as the utilities know what they are looking for. Text is just for interaction with human beings (lol, quite a pun on my nickname :D ). If you were to carve all the contens of that file from the file system (which might be quite a pain) so that you have a complete binary again, and were to search for code accessing the memory location on which the string resides, you'd probably find that it calls another routine that checks the flag. However, expect this one to perform a call to a system library and expect this system library to perform a system call to the Android kernel and expect the Android kernel to have similar code in it as the HBOOT code that we've already found or code that interacts with the Radio somehow. Don't know of how much use this is.
[HTC Wildfire S] *se-nsei.:
Approximately, the last 40 pages hurt my brain.
[HTC Wildfire S] heavy_metal_man:
+1 :D but we seem to be making progress ;)
[HTC Wildfire S] heavy_metal_man:
So have we got a gameplan?
[HTC Wildfire S] humzaahmed155:
but first i need to update my branded tmo-uk phone to 2.3.5 which oddly isnt out yet :P, do you guys think i can get the htc europe software and extract the PG76IMG.IMG and do it on HBOOT? Or will it brick my phone?
[HTC Wildfire S] EJKasteel:
you can try i did multiple times and get error "wrong zipped image".

it aborts update process it did not brick my phone.
[HTC Wildfire S] hahahafr:
Yeah me too. I'm just trying to understand your thoughts.

I have little experience with reverse engineering, especially ARM assembly.
[HTC Wildfire S] dantdj:
You can do it, I did it last night, phone didn't brick. I'm not going to say it won't brick yours, but it definitely didn't brick mine. :p

Currently running the Cyanogen 7.2 port found on here!
[HTC Wildfire S] no.human.being:
It's actually much much easier to read than x86 assembly, as ARM is a RISC architecture and the instruction set is much simpler, less different instructions, addressing modes, etc.

The only things I'm not sure about is:

- How to reliably find out whether the processor is in Little or Big Endian mode as this can afaik be switched by code at any time.

- How persistent storage is accessed. I think it's accessed exactly as RAM (via a single address space) and the MMU tables decide which address ranges are mapped into volatile and which are mapped into persistent memory but I'm not 100% certain yet.
[HTC Wildfire S] heavy_metal_man:
still gutted those dump files didnt have what we needed :/

all that effort lol
[HTC Wildfire S] no.human.being:
Yeah. But at least they DID shed some light on the entire thing. Now we know for sure that XTC clip leaves the device firmware untouched and that the secu_flag resides in some sort of "unmapped memory" region that is not accessible once that Android has booted. Remember that the flag resides on a standard partition on the Desire S. This also explains why the Desire S has been cracked for so long and the Wildfire S has not. The Wildfire S in fact seems to have "extra security" that the Desire S doesn't have.

I'm not sure how difficult it is to map those memory regions back in. As you know, the Android kernel itself resides on mtd2, which is unprotected on the block device level, so we could modify the kernel to map the unmapped memory, then reboot the phone so that the modified kernel gets loaded and then we'll have obtained access to whatever we need. So this memory protection seems to be an operating-system level thing only, as you can bypass it by passing suitable arguments to the kernel. Remember you can't pass arguments to the kernel on a phone without an ENG HBOOT installed so this is not the way to go, but we could modify the kernel so that it "thinks" it got an argument passed even though in fact it wasn't. However, I'm not that much into kernel level development so I don't know how much work this will turn out to be. Could actually be a real pain to implement.

What we DO have access to however is that mysterious "misc" partition. It is mapped in as mtd0 and some sources claim that it's used by Android to communicate with the Radio. I don't know if we can use this circumstance for "asking" the Radio to turn security off. Probably not, as this would to be too simple, wouldn't it?

Seriously, I must admit that I'm actually quite "stuck" now. I'm left with uncertain ideas of how one "might" do "something" but I'm not having a real "roadmap" any more. For now, all I can do is keep pondering. Any ideas are welcome.

I'd really love to JTAG that b**ch and watch it initialize up to the point that HBOOT is loaded in single step mode. Not sure if ARM supports single stepping, but if it does, then this will really explain all the "dark magic" that happens BEFORE HBOOT takes control. There'll be code by ARM Ltd. running on the processor that initializes the controller, probably sets up some page tables, then loads HBOOT into memory. This would be really interesting to see because it will probably explain what's in that memory region that HBOOT later reads. Would also be interesting to read the memory at the physical (!!) level to obtain the contents of all those "protected" and "hidden" and "unmapped" regions. I'm having a JTAG interface for ARM here, just need a suitable adapter as the phone's JTAG connector is not standard. :mad:
[HTC Wildfire S] humzaahmed155:
Nah, it just says: FAIL [INCORRECT CID] PRESS POWER TO REBOOT.
[HTC Wildfire S] heavy_metal_man:
i suppose. bloody htc, couldnt just let it be as easy as the desire could they?:(

is it safe to assume the the old wildfire would have the same sort of unmapped partition for the secureflag?

and finally :p where would you get the correct jtag adapter? i assume you cant just find them in the local shop like?

will help if i can:D
[HTC Wildfire S] BeciMester:
I don't know where you are located, but: UK seller, Polish seller.

I'd love to be able to afford toys like JTAGs and XTC-clips. :D

For the life of me, I can't get the nanddump/nandwrite source to compile. Not under Ubuntu, anyway. Will try with Windows later; 2nd semester started and work is piling up already. :(
[HTC Wildfire S] no.human.being:
CID checks can be overcome via Goldcard. This is not a recommendation, I don't know whether what you plan to do will brick the phone but certainly the CID check should not be what's preventing you from doing it.
[HTC Wildfire S] hahahafr:
Great finding. I can donate 5e if someone is willing to buy one of these.
[HTC Wildfire S] no.human.being:
Yep, I already knew about the second one from university. Have just contacted them for payment/shipping conditions for my country.

The JTAG interface itself cost 49 €, but it's not specific for the Wildfire S or for the Quallcomm chip, but it's generic for all ARMs and I'll certainly need one of these more often as a computer scientist so ...

However, it was difficult to find a seller that sells the interfaces to end users. Most were only willing to sell them to commercial customers. :mad:
[HTC Wildfire S] benjamingwynn:
I wish I could help you guys... I couldn't think of why not in real words so I made this...​

',',',',',',',',',',',',',',',',',',',',',',',',',',',',',',',',',',',',',',',',',',',',',',',',',',',' <- This is the lawn, that's where users live

',',',',',',',',',',',',',',',',',',',',',',',',',',',',',',',',',',',',',',',',',',',',',',',',',',','

[][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][] <- This is the mud, that's where ROM dev's live

[][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][]

[][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][]

[][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][]

[][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][]

[][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][]

[][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][] <- This is stone, that's where kernel dev's live

[][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][]

@-41094114{RQWPIOKORJDA(!)$Q*)!($_*!%(*!()_(¬_)

$!()!$£*(%IREJWFIWEOI)$_(%!)_(%!_)*%!IEOEIRIRIR <- This is the earth's core, it's where you guys live :D

WEIJKRWEJSKWRFESJWEKORWJEIOJFWESWRI
[HTC Wildfire S] trampi:
I would also donate 5 Euro
[HTC Wildfire S] no.human.being:
Sorry guys, I have no means of accepting donations. :D
[HTC Wildfire S] trampi:
And if i buy the JTAG -> Wildfire Adapter and ship it to you?
[HTC Wildfire S] no.human.being:
C'mon, forget it. The adapter is 8.00 € + VAT + shipping. I'm not sure how much the shipping from that distributor in Poland is but it shouldn't be THAT much of an expense. Shall we ever meet buy me a beer and everything's all right. :D
[HTC Wildfire S] heavy_metal_man:
Seems we are very determined ;) what would we do if jtag failed to reveal htc's dirty secrets? Cry? :-p
[HTC Wildfire S] hahahafr:
The JTAG interface is the master key, I believe that.
[HTC Wildfire S] *se-nsei.:
Never mess with a computer scientist. :D
[HTC Wildfire S] heavy_metal_man:
I`d love too :D but how will i get familiar with them?....:o can you recommend a program that can open them up, as i no longer have access to the device:(( holiday is over:()

and which hboot images? any i normally use for my widfire i just take from the ruu's.

also what is the likelyhood that the wildfire s-0n information will be in the same place as the wildfire s stuff? do you think they would have changed it?
[HTC Wildfire S] no.human.being:
Sorry, got the wrong person. BeciMester was the one who got the HBOOT images and disassembled them. Sorry for the confusion! :D

So @BeciMester: I should have JTAG access to my device soon. Could you please get familiar with HBOOT-1.08.0099 and OpenOCD and tell me where you got the HBOOT images from? I'd really like to get a view on them as well. We should try to read the Radio and HBOOT, as well as the initialization code that loads both into memory from the device's Flash via JTAG, then disassemble them. We should also be able to dump/modify RAM, single-step the CPU through the HBOOT code, etc. This should literally reveal everything to us.

---------- Post added at 09:04 PM ---------- Previous post was at 08:35 PM ----------

The problem is that the memory is "unmapped" (no longer accessible) during Android's boot process so we can't read/write there, only the Radio can (needless to say that the memory where the Radio resides is also "unmapped"). That's why there was not much interesting stuff in the dumps you provided (sorry, it's not your fault, you see I didn't know either .. well actually I did know .. kinda .. Revolutionary said that secu_flag is in "unmapped memory" but I didn't really trust them as it is in "standard", "visible" memory on the Desire S, but now we know for sure that they told the truth). BTW the memory where HBOOT resides is also "unmapped" so no "patching the HBOOT" either.

0. We could modify the Android kernel so that it doesn't unmap the memory. It is possible but I really don't want to go that deep, so I'd rather either ...

1. Ask the Radio to turn the secu_flag off and it'll probably do so. That's exactly what the DIAG utility from the xtc-clip does. That you need the actual clip hardware (which emulates a special testing SIM) is probably just because the DIAG software requires it. If we were to ask the Radio, it'd probably just do it, no questions asked. The problem is that we don't know how we can talk to the Radio. When communications happens via the mtd0 memory area, we can do it. However, it's also possibly that it uses a communication channel that only the Android kernel can access, then we're back at item 0 and modifying the kernel. :D

2. Find a way around the memory protection so that we are the ones who can turn it off and not the Radio. :D

The entire JTAG thing will assist us in understanding how this is all layed out in memory on the physical layer and will enable us to tinker around (modify ROM and RAM contents without restrictions, halt and resume program execution, modify contents of processor registers, etc.) with all the firmware. It's basically like running the entire firmware inside a debugger. With JTAG access, there's nothing they can hide and there's nothing that we can't change without them noticing.

BTW, to point 1. There is a ressource that claims you can talk to the Radio via a virtual tty device, but I couldn't get this device to show up. When trying to register the device it says that it couldn't find a driver suiting the vendor of that device.
[HTC Wildfire S] heavy_metal_man:
fair enough buddy :) if i can help in any other way let me know ;)
[HTC Wildfire S] BeciMester:
I extracted the 0.90 hboot image from this RUU: RUU_Marvel_HTC_Europe_1.30.401.0_Radio_47.10.35.3029H_7.46.35.08_release_183799_signed.exe found in Football's thread, and extracted the 1.08.0099 image from rom_02.zip inside the RUU used for unlocking the phone: PG7610000_Marvel_hboot_1.08.0099_20111216.exe, downloaded from the HTC site.

Can we do anything with the kernel-command-line-hack that was linked earlier?

I've downloaded the OpenOCD document and had a read. What exactly do you want me to do with it if you have the device? :confused: Also I'm all over the "new hboot" 1.08.0099, trying to find out what does what, as much as I can. I've already found the subroutine that I believe to check for the @secu_flag status, the same that I was on about a few days ago. Anything specific we're looking for?
[HTC Wildfire S] hahahafr:
After reading your entire post, I feel the excitement.
[HTC Wildfire S] *se-nsei.:
If it's possible, it would be incredible. ;)
[HTC Wildfire S] BeciMester:
Offtopic: Could you guys stop quoting huge posts, please? :( If you're answering to something, quote that specific part and delete the rest. I'm using the xda app on my phone and it's a pain in the backside to scroll over pages and pages of quote and handpick the relevant bit. I didn't intend to offend anyone, but it's something I always wanted to mention.

(I'm on my phone...)
[HTC Wildfire S] *se-nsei.:
sure, my bad.
[HTC Wildfire S] no.human.being:
Just one more thing to think about. Not sure yet if it makes much sense. If we can load another kernel via fastboot, can't we load an entirely different operating system (say a Linux kernel)? Getting rid of Android code will get rid of Android's (artificial) restrictions.
[HTC Wildfire S] :
In this case *se-nsei had to so that users could understand what no.human.being's going on about.

---------- Post added at 12:17 AM ---------- Previous post was at 12:14 AM ----------

Probably. Remember, nothing is impossible (I think :D)

Where did you learn all this stuff? Yes, I'm quite a technical person, but I need to know more if I am to cope! Please tell me!!!!! I just need to know the critical thing (the memory system (which I know little about), maps, datasheets, etc.) Please!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

My future is in your hands...............

(I am really not joking. I seriously need to know!)
[HTC Wildfire S] BeciMester:
Well if someone with XTC-clip S-OFF is willing to flash an engineering hboot (I think it's available isn't it?), s/he could execute those commands that don't work on stock... I don't think the partitions would differ a lot in the eng hboot so we'd still get an accurate picture.

Or... According to IntuitiveNipple, the hboot should contain the page tables, at least in the Desire Z's case. He has source code up for retrieving them.

Or... We could put together some custom software that acts as a kernel, is this what you have in mind? It wouldn't have to be a full-blown kernel, just retain the bare minimum of functionality; we don't need everything to work on the phone for this task. :cool: Is this the new direction then?
[HTC Wildfire S] no.human.being:
Exactly. The mapping is passed from HBOOT to the kernel as "kernel arguments" (how do kernel arguments get passed "physically" in memory?). We could build a software that retrieves the arguments and prints them on "stdout" (if there is already such a thing at this stage). I'm not sure if this is actually needed though, see below.

Not really. First we still have to find out where the flag is physically located, which means reverse-engineering HBOOT, later on the physical device with JTAG support. If we were to boot Android on the device, we'd need to figure out the partitioning so that, along with our "new" partition covering the entire memory, we can still pass the "standard" partitions that Android will require for booting.

However, if we're to build a custom OS for the S-OFF thing anyhow, we don't need to figure that out at all. We just map the entire memory of the phone (or just the Radio, as long as it resides in a fixed location) as a single contiguous mtd partition and put everything that our operating system and exploit needs (exploit itself, libraries, scripts for starting the exploit and rebooting the phone afterwards) into the system's initrd. So basically we bootstrap our own "self-contained", lightweight firmware into the device's RAM, let it boot, let it perform the exploit, let it reboot the handset and done. We won't need to know how the partitions are laid out, as we don't need access to the file systems on the partitions. The entire system will be self-contained. Sounds easy, probably is hard work, but should definitely be possible. What do you think?

So probably next step in our "new branch" of development: Build a kernel (e. g. Linux) for ARM and boot it on the device via fastboot. This doesn't mean that the HBOOT analysis and JTAG stuff is stopped. We'll need both in the end and both are independant and as we all know from developing multi-threaded applications, stuff that's independant can be done in parallel. :D

By "doing it in parallel", I don't mean that I want to "divide" the work between us two. Both things are probably difficult tasks in which we should definitely cooperate and throw our expertise together. But it means that we can do both without one blocking the other, so we may "switch" between doing the one task and doing the other at almost any time. This will actually come in handy when we're stuck at an issue with one of the two tasks. We can then bring the other one forward and probably, in the course of that, a new idea will come to mind for the first one and so on. If you've followed most the discussion in this thread, you will have seen that I've always tried to keep multiple paths open and work on multiple things "at the same time". This definitely keeps you very productive, as the chance of "being stuck on multiple items" is actually quite low.
[HTC Wildfire S] heavy_metal_man:
sounds like a plan man :cool:
[HTC Wildfire S] MrTaco505:
Wish I knew all this stuff.
[HTC Wildfire S] no.human.being:
On how to create the initrd. Sounds possible.

Now only three things open:

- Find the exact physical location of the secu_flag on the physical device. (This is probably blocked until JTAG adapter arrives.)

- Build a Linux kernel that suits our devices. (?!?!)

- Write a program that runs on that kernel and flicks the flag in memory and integrate it into the initrd. (Shouldn't be too hard once we got the first two done.)

Any specific suggestions on how to get started on the second one?

I can almost feel the secu_flag under my fingertips while typing this. :D

EDIT: Well .. I think I got it. Kernel is currently building. This takes like forever. Let's hope it gets through.
[HTC Wildfire S] MrTaco505:
so there has to be a specific kernel to allow you to use the JTAG? im confused, reading 89 pages would fry my brain, lLITERALY :)
[HTC Wildfire S] no.human.being:
So why are you quoting it at all?
[HTC Wildfire S] theq86:
@n.h.b

have you included the kernel modules that contain the drivers for the phone hardware? if we want to use a custom kernel we have to at least be able to access nand and ram and stuff. i don't know if specific drivers for the phone have to be added to the kernel.