yashsingh1/xdaforums huggingface dataset:
[HTC Wildfire S] no.human.being:
Well, of course they are not on a phone. However, simonsimons said they were "leaked", which sounded a bit like an HTC employee smuggled them out and published them.

If we have the public key, we know how large the public exponent and modulus are. 512 bit RSA has been broken in 1999.

1024 bit RSA has been declared insecure in 2003, even though I don't know of any case where it has actually been broken, probably since IT staff migrated to larger key sizes and the ability to break 1024 bit RSA became stale. These can almost certainly be broken with today's hardware, given there is a good implementation of the Pollard-Rho algorithm for the GPU.

2048 bit RSA is expected to take about 15 years to break and is regarded as secure for commercial applications.

4096 bit RSA is military-grade security. :D

However, even if it turns out that it's "just" 1024 bit RSA, it's probably way way easier to fake the method that HBOOT uses to authenticate with the Radio to get the NAND unlocked and thus gain write access to the protected NAND area than to break the signature.

EDIT: I was probably quite wrong about my claim that 1024 bit RSA may be broken on a GPU. There is a paper published on this subject which estimates the amount of money you'd have to pay if you were to break certain keys on a cloud service like Amazon EC2 and the estimates go to around 560 million dollar for breaking a 1024 bit RSA key in 3 years. So forget about it. HTC certainly won't use RSA keys smaller than 1024 bits and these are still out-of-reach. So let's forget about the signature thing and either figure out how to get a "hacked" HBOOT chainloaded or how to properly implement the missing "msm_unlock()" function in the kernel. :D
[HTC Wildfire S] sythe179:
After 2800 posts, we've gain q fair bit of knowledge, but yet still not enough....might see if I can get a hold of somebody...

Sent from my Wildfire S A510x
[HTC Wildfire S] no.human.being:
The problem is that we don't have a way of seeing inside the phone what's happening (aka JTAG). All we currently do is basically guesswork. If we could see where the "chainloaded" HBOOT is loaded, whether the "original" HBOOT actually branches into it, at which point the decision is made where it enters the "fallback", then we could most likely break it (by modifying our "patched" HBOOT image further so that the decision is not made).

Basically JTAG is like executing the entire operating system inside a debugger. You could use it to literally single-step through each and every instruction of both Radio and HBOOT and see what it does to the memory and to the registers, which branches it takes, etc. This would be SO INCREDIBLY useful.

If anyone either has a WFS and JTAG working or is that good at reverse-engineering that he "sees" from the code where HBOOT is doing the decision, then please let me know and we'll probably get still another step closer. Otherwise all I can do is continue "guessing" or trying to get a level-shifter built to shift that 0.9 V logic on the MSM7227 up to the 3.3 V logic that JTAG requires.
[HTC Wildfire S] sythe179:
There's a low voltage converter for jtag, but its +1.9, so still a bit high.

Also, if, you've got that hboot code, I'll have a look at it and see what its doing. Usually good at knowing what its doing.

Sent from my Wildfire S A510x
[HTC Wildfire S] anarche_diver:
Hi,

Call me a noob, but i really don't get why people are so obsessed with S-OFF.

I mean we can already change ROM's and root. What more do we need...
[HTC Wildfire S] :
Didn't you read the OP? We can't flash hboot or resize system partition! And we have no warranty.
[HTC Wildfire S] no.human.being:
I've attached an image of an "original" HBOOT as an encrypted archive. It's not patched. It's encrypted because HBOOT is proprietary software and I don't want to infringe intellectual property rights by "distributing" it. I've sent you the key to the archive via private message. The *.img file is the binary. It's just a raw NAND dump. The *.txt file is the souce in ARM assembly language.

We currently try to gain S-OFF by patching four instructions (12 bytes) starting at 0x8b68.

Execution seems to start at 0x800. The HBOOT code is executing from 0x9d000000 (virtual, RAM). You see lots of references to addresses from 0x9d000000 onwards.

Right when it begins what the instructions 0x800 to 0x82c do is zero out the memory range 0x9d074340 (inclusive) to 0x9d07d764 (exclusive). You can see the loop doing the actual zeroing from 0x818 to 0x824. It writes zero (content of r2) to the address pointed to by r0 (which was initialized with 0x9d074340), then increments r0 by 4 (4 bytes = 1 machine word) and checks whether r0 is equal to r1 (which was initialized with 0x9d07d764). If not, it jumps back to 0x818 (bne = branch if not equal), writes the next zero, increments r0 by 4 and so on. Once that r0 has reached 0x9d07d764, it loads the stack pointer with address 0x9d0fbffc (which is the word at address 0xbac) and then branches to 0xbc8.

Things get pretty complicated after that. :D

My goal is getting UBOOT (bootloader of Embedded Linux) running on the device. It's much more advanced than HBOOT and kernel devs could do lots of nice things with it (e. g. boot "vanilla" Linux on the phone instead of Android, programming NAND and RAM on the raw level, etc.).

I'd also like to replace the Qualcomm Radio with a "vanilla" build of Iguana (which is the open source software on which the Qualcomm Radio is based - you can say that the Qualcomm Radio is a "tuned", proprietary build of Iguana). The good thing about running the device on entirely open firmware is that you can review it regarding security vulnerabilities (or even deliberately placed backdoors). As long as we are forced to run proprietary software on the device (and without S-OFF you can't replace the Radio) we can never be that certain. And of course with open firmware you can customize it.
[HTC Wildfire S] csoulr666:
Question time

With UBOOT.........can we be able to use non-linux OS's as well???Or will it only be for the Linux ones??

I would love to run Meego on my phone :)
[HTC Wildfire S] no.human.being:
I think it can basically boot anything. For example it can boot from RAM (of course you'll have to load the kernel to RAM before), from NAND and even over the network (e. g. WLAN interface) via TFTP. However, it has special support for Linux, so it can for example pass kernel parameters to a Linux kernel. While it may "load" just any executable system-level code you could imagine, it's probably unable to pass kernel parameters to other kernels due to their different ABIs (application binary interfaces).

However, it can most likely "chainload" a proprietary bootloader (e. g. HBOOT :D ) from NAND, even though this would defeat the purpose a bit. :D

One of the biggest drawbacks is that you will lose Fastboot support when using UBOOT so you'll have to replace some of your Android SDK tools with appropriate tools for UBOOT and some things may get more complicated. UBOOT kernel images are not Android kernel images, so you'll have to specifically build your kernels in a way that allows them to be booted by UBOOT. So most people yould probably want to "chainload" a proprietary bootloader anyhow, so that they can use these tools again. The only advantage that UBOOT gives you in this case is that it grants you unrestricted low-level access (e. g. read-write-access to the entire NAND) when you need it. The drawback of course is that it takes away yet another portion of NAND and you'll have to repartition everything.
[HTC Wildfire S] csoulr666:
WP7???
[HTC Wildfire S] no.human.being:
Not sure but I think as long as it basically runs on the device. I imagine that WP7 ships with its own bootloader, that UBOOT should be able to "chainload". Don't want to guarantee anything though. :D
[HTC Wildfire S] csoulr666:
No problem................was just clearing what i had in my mind

Anyway any progress on the JTAG voltage problem????
[HTC Wildfire S] no.human.being:
No. Unfortunately not. I haven't found a commercial solution so it will probably require custom hardware. Think of a circuit board with two JTAG pin headers and a header for power supply (one supplying the 0.9 V, other supplying the 3.3 V). Connect one JTAG header to the JTAG adapter on the phone. Connect the other to the JTAG interface. A pair of MOSFETs in each signal trace to do the shifting (one MOSFET for an inverting shifter, which is basically a logical NOT gate and will require a second one to invert again). Another pin into each of the traces to be able to tap them more easily.

The signals are called:

TDI <- Trace Data In

TDO -> Trace Data Out

TMS <- Trace Mode Select

TCK <- Trace Clock

RTCK -> Return Trace Clock

nTRST <- Trace Reset

nSRST <- System Reset

DBGRQ <- Debug Request

DBGACK -> Debug Acknowledge

Green ("<-") is from JTAG interface to processor (so input on processor side) and red ("->") is from processor to JTAG interface (so output on processor side). Green would probably need downshifting from 3.3 V to 0.9 V (even though the processor seems to accept the 3.3 V as logical high, but it's probably "better" for the processor if we don't constantly exceed it's I/O voltage threshold during debugging). Red will need upshifting from 0.9 V to 3.3 V since the interface will not read the 0.9 V as a logical high. DBGRQ and DBGACK seem to be 5 V logic and probably don't need shifting.

So 5x downshifting, 2x upshifting. 14 MOSFETs (plus a bit of other stuff) should do it. The problem is that I don't have a facility for etching circuit boards and wiring it all by hand seems a bit tedious. Let's see if we can get HBOOT chainloaded somehow.
[HTC Wildfire S] *se-nsei.:
:confused:
[HTC Wildfire S] iuss:
For a chainload, you'll also need to prefix hboot with a small copy loop, to move it from the regular kernel loadaddr to 0x0, to avoid overwriting the old hboot image before it jumps to the 'kernel'. While it succesfully gets to the main drawing/input-handling loop of the 'new' hboot, it's quite unstable (e.g. a subsequent kernel load results in a crash).

That aside, why don't you just use mdb/mdw to patch hboot in-place...? Should be the easiest way.
[HTC Wildfire S] no.human.being:
This is actually a nice idea. Are you sure this is actually required though?

Remember that the image we load is almost exactly identical to the (HBOOT) code that's already there. So basically we overwrite the memory with identical values. As long as the HBOOT doesn't "zero out" or otherwise "prepare" the memory before writing our image there, this shouldn't do any damage, right? I mean say it overwrites the memory word by word (so 4 bytes at a time). It just writes the values that are already there. Some instructions are changed, but these are almost certainly not executing while loading a kernel via Fastboot.

Where should we jump when we copied the "new" HBOOT into place? To the first instruction of the HBOOT image? Or to offset 0x800 relative from the beginning of the HBOOT image? The latter seems to be where execution starts when the device is booted up, but it appears that the MMU is already set up at this point (the code is referring to addresses starting from 0x9d000000 which are definitely virtual). The instructions beginning at 0x0 don't make a lot of sense to me. When tracing through the code starting from 0x0 I end up in "no man's land". In particular, I don't see the code that sets up the MMU.

How do you know?

What's "mdb/mdw" please? Sounds like "modify byte" and "modify word" respectively. Are these "commands" that can be passed to HBOOT? If so, how? Via Fastboot? What do they do? Modify the contents of RAM one byte/word at a time?

Btw, I just established a shell to the Radio firmware. I did a "fastboot oem rtask C", then the phone locked up (stayed in the Fastboot screen but did no longer respond to anything) and a new device called "Qualcomm Inc. Wireless Modem" appeared on the host under "lsusb" together with a new "/dev/ttyUSB0" device file. You can then use "screen /dev/ttyUSB0" to talk to the Radio. Be careful though! Every key you hit is transmitted to the Radio and interpreted even though you might not get any visual response for most of the things you type. I've successfully queried the Radio for things like its version ("AT+RADIOVER"), secu_flag ("AT@SIMLOCK?AA"), CID ("AT@CID?"), IMEI ("AT@IMEI?"), board ("AT@PID?"), etc.

If you type "ATE1" followed by a newline character, the Radio will echo your keystrokes back to you, which makes it easier to type. Nonetheless mind that your keystrokes are immediately interpreted, so there's no such thing as "correcting by pressing the backspace key". You still have to be very careful, it's just that you get confirmation that your key presses were received.

When you transmit the string "AT$QCPWRDN" followed by a newline character, your connection will be closed and the device will power down.
[HTC Wildfire S] iuss:
Much of the code is the same, though slightly offset due to code changes. It will break any running hboot if you overwrite it in place.

As for virtual memory, the first 0x800 bytes mainly consist of coprocessor poking (notably mmu setup).

Annotated snippet:

LDR:00000090 ADR R0, pg_descs
LDR:00000094 BL setup_page_table
LDR:00000094 ; ---------------------------------------------------------------------------
LDR:00000098 pg_descs pg_desc <0x40000000, 0x12C00000, 212>
LDR:00000098 ; DATA XREF: LDR:00000090o
LDR:00000098 pg_desc <0x4D400000, 0x20000000, 128>
LDR:00000098 pg_desc <0x55400000, 0x28000000, 128>
LDR:00000098 pg_desc <0x9DF00000, 0x2A00000, 2>
LDR:00000098 pg_desc <0x9D000000, 0, 1>

Format of pg_desc is <u32 va, u32 va, u32 num_sections). As you can see it maps 0x9d000000 to 0x00000000 (note: one section spans 1 MB).

Once the mmu has been setup, setup_page_table branches to 0x9D000800, which zeroes bss, sets up the stack pointer and jumps to main.

Emperical evidence (another device though)

munjeni said these were present (I meant mb/mh/mw though, without the b). The marvel hboot I looked at (1.09.0099) doesn't contain them though. Must be a version thing (his is labeled 6.02.100).

The syntax is 'mdb <addr> [<num bytes/halfwords/words> <value>]' I think. Without the optional parameters it just dumps memory. See if you can get that to work, then patch get_secflag (assuming I/D-caches aren't in the way, I really wouldn't know). If you need help on that, first figure out how to use mdb to perform a write (I don't have the device) then get me a copy of your hboot and I'll supply the patch details..
[HTC Wildfire S] no.human.being:
We do not change the layout of the code at all. We only patch single instructions. Otherwise, we'd have to adjust all addresses like branch targets etc. Everything remains in place. Nothing gets "offset". However, it's probably better if we "prefix" our patched HBOOT with a piece of code that copies it in place from where it was loaded as a kernel and then let the "original" HBOOT load it to the "default address" of where an Android kernel is loaded and pass execution to it. The "prefix code" then copies it from this place over to 0x00000000 physical, overwriting the "original" HBOOT in memory and then branches there.

Makes sense, even though I don't understand all of it. However, I don't see how execution finally arrives at 0x800. I can't see it branching or otherwise getting there.

Ah nice to know that format.

Yes, at 0x800 the code starts making sense again.

800:	ea000001	b	0x80c
804:	9d074340	stcls	3, cr4, [r7, #-256]	; 0xffffff00
808:	9d07d764	stcls	7, cr13, [r7, #-400]	; 0xfffffe70
80c:	e51f0010	ldr	r0, [pc, #-16]	; 0x804
810:	e51f1010	ldr	r1, [pc, #-16]	; 0x808
814:	e3a02000	mov	r2, #0
818:	e5802000	str	r2, [r0]
81c:	e2800004	add	r0, r0, #4
820:	e1500001	cmp	r0, r1
824:	1afffffb	bne	0x818
828:	e59fd37c	ldr	sp, [pc, #892]	; 0xbac
82c:	ea0000e5	b	0xbc8

This writes zeroes from 0x9d074340 (inclusive) to 0x9d07d764 (exclusive) word by word. (Is this the BSS section? How did you find out that it is?) Then it sets the stack pointer to 0xbac (probably rather 0x9d000bac when executing from virtual memory) and then branches to 0xbc8 (main?).

Well I couldn't establish a connection to this shell yet. In "HBOOT USB" mode, I don't know what to do with the device (it won't recognize as a ttyUSB device).

In "FASTBOOT USB" mode, I can of course supply Fastboot commands. If I supply "fastboot oem rtask C" from this mode, the device will lock up and appear as a serial device ("/dev/ttyUSB0") on the host. I can then use this device for talking to the Radio. Is there any "task" or "rtask" command that makes a serial device appear for talking to the bootloader? I think you have to establish a serial connection to the bootloader to set off commands like "mdb". Or is there any way to patch HBOOT from the Radio? Probably not, since the address spaces of mARM and aARM are separate.

That said, I wasn't able to reproduce what munjenji did. I can talk to HBOOT via Fastboot and to Radio via serial, but not to HBOOT via serial. Might need a different Linux kernel on my host to establish the serial link to HBOOT.
[HTC Wildfire S] iuss:
Whoops, you're right. For some reason the chainloading got me confused (as you'd typically load something completely different).

You should find a 'mov pc, rn' at the end of the setup_page_tables I described earlier.

It is (by definition). As for SP, it dereferences (note the brackets) a PC-relative address, so the actual SP initliazer address should be located at 0x9d000bac.

That's really strange (especially since I've only had issues getting serial working after issuing rtask - some qualcomm modules interfering. a plain hboot shell just works after modprobing usbserial). Are you sure you got the vendor/product id right (it differs from the fastboot/post-rtask ids!)?
[HTC Wildfire S] no.human.being:
But it's probably safer to prefix it with a code that moves it to 0x00000000 physical and get the "original" HBOOT to load the code somewhere else, right?

Oh yeah I got it.

4d4:	e59f0010	ldr	r0, [pc, #16]	; 0x4ec
4d8:	e3500000	cmp	r0, #0
4dc:	ee011f10	mcr	15, 0, r1, cr1, cr0, {0}
4e0:	e1a0f000	mov	pc, r0
4e4:	e1a00000	nop	; (mov r0, r0)
4e8:	fff00000	; <UNDEFINED> instruction: 0xfff00000	; IMB
4ec:	9d000800	stcls	8, cr0, [r0, #-0]

At 0x4d4 it loads the address 0x9d000800 from 0x4ec into r0 and then it sets the program counter to the value loaded into r0. Oh man, I should become more accustomed to the fact that there are lots of ways to achieve similar things on the machine level. I always look for branch instructions but you're right. This is where it happens. :D

Yeah, of course you're right again. I got the dereferencing thing right where it loads the lower and upper bounds of the memory segment it zeroes out, but I missed it on the other part. So the stack pointer gets initialized to 0x9d0fbffc.

bac:	9d0fbffc	stcls	15, cr11, [pc, #-1008]	; 0x7c4

I do not load any modules after the "rtask" either. My operating system recogizes it all automatically and the device just "appears" as "/dev/ttyUSB0". Shouldn't it be the same for the HBOOT case? I already tried what munjenji said but it seems that I cannot probe for the correct modules with my kernel. I think I need a different kernel for this to work. This is strange, however, since I can talk to the Radio and I thought that both Radio and HBOOT are emulating "RS232 over USB"-type devices so I thought that either both work or both do not, however apparantly one does, but the other does not.
[HTC Wildfire S] Antagonist42:
Glad you're making progress with help from people who can talk your language :victory: it's right now you guys totally lose me (I may over think it or it's 'too' simple for me to grasp but I just don't get it :confused: - anyways updated a couple more docs if they help and a couple of Lauterbach for JTAG which may help (seems like they do the JTAG for HTC among others) as to do with all the Voltages etc... happy reading ;)
[HTC Wildfire S] munjeni:
You can not load hboot without modifying it, its not possible! You need first (as I done when hard dumped Cottula soft spl from memory and compared it with stock spl - than I successfully created/loaded "my version" soft sspl - before that I was unsucesfull to load an spl): To compare SSPL (soft spl -modified stock spl) and SPL (unmodified spl) for htc hd mini (see my post there) you will see why booting an spl (or hboot) is not possible! SPL (as like hboot) have "memory offset" check so if you want to boot hboot via "something" it will fail because its not right memory offset that is expected, you need to by pass it, seccond, you need to by pass (to disable) another thing (function that turning phone peripherals on) because your modified hboot (hboot that you tried to load to memory and execute) can not "double" turn peripherals on because its allready "on" by hboot that still is allready executed, so another fail is there... etc, you can look in the htc hd mini thread, where I modified jumpspl (spl loader for htc hd mini - sucesfully ported it!) , you can hex compare soft spl and stock spl (to get "all modifications offsets for comparation in disasemble"... you can find sspl and spl here -> http://xdaforums.com/showthread.php?t=1507320) and you will see what thing is_patched/you_need_to_patch to get it bootable... allso you can try to port jumpspl for android (its still in wince format now) -> https://gitorious.org/jumpspl-photon/jumpspl-photon ...if you sucesfully port it I will be glad to play with hboot (I tried to port jumpspl for android compatible but without success - its still fail to compile on an thing that not exist in android cross compiler, its still only in windows CE cross tools)...etc...etc. When you see/understand/hex_compare/disasemble/compare_disasembled_things from soft spl with disasembled things from stock spl, you will be able to boot an modified hboot (maybe with fastboot boot *, or maybe with an another software, or maybe with an kernel module like ->https://gitorious.org/ics-cyanogenm...aria/ics/trees/master/drivers/staging/splboot)... this is for surre possible but first we need an working "andrid compatible" loader for hboot like jumpspl... I think jumpspl will work in wfs too for surre because aria/wfs/htc hd mini is with the same chipsets...