yashsingh1/xdaforums huggingface dataset:
[HTC Wildfire S] :
It's a conspiracy, mate. It's a big damn trick. This entire operation here is rigged to blow. They have this phone wired. It goes like this

if xda hackers get exploit
initiate sequence (C4)

New sequence = C4;
(detonate): C4/1/C4/2;

after sequence (C4) return #affirmative#
then;
system.out.println("From HTC and Qualcomm: In your face, XDA hackers!");
run sequence (corrupt all partitions);
run sequence (fuse data connections);
run sequence (short power sources/self destruct);
code end;

Man, that felt good. Sorry for the OT, but I needed to light things up again.

Btw, does OEM_SPL ring a bell? We brought it up previously, but there wasn't an answer.
[HTC Wildfire S] Antagonist42:
Don't forget that mARM sets up a secure area in IMEM during boot sequence way before android boots and neither mARM or aARM have access from what I can gather so maybe the NAND's MMU has access to this area only needing to access the IMEM secure area on a NAND address's read_secure_area or a write_to_NAND thus NAND MMU has access to the secure IMEM area when mARM and aARM don't therefore no need to totally lock down the radio if you don't know how to manipulate the NAND's MMU (is it an MMU? been way too busy today and just unsure what? :confused: )

Rooted Xakep E320/C6 EUU Hacked Update
[HTC Wildfire S] no.human.being:
So you claim that NAND access is not exclusive to mARM and carried out by mARM on aARMs request via RPCs, but common to both via an MMU that does address translation, synthronization and enforcement of permissions?

If this is so then we can be certain about reading actual NAND content, since an MMU won't "manipulate" anything but addresses. :D
[HTC Wildfire S] seaskyways:
@nhb , I say 95 % i am sure that the "guys" have hidden something , if the secure_flag wasn't found in the radio as all the other phones , where should it be ?? they're hiding something ...
[HTC Wildfire S] *se-nsei.:
Mate please please reduce that signature. It hurts my eyes.
[HTC Wildfire S] theq86:
The WFS has not had that much developer support like other phones did. We're the only handful people trying to s-off this phone. even revolutionary team did not really want eagerly to get this done.

So, many other devices have been "easily" s-offed. Why should the WFS be the only phone where they have hidden something more strongly? makes no sense, makes less sense if you see that our phone is classified as an android starter phone.

It's just we have not found out where the flag is and how to change it.

And when the first successful JTAG reverse engineering has been done, I guess S-OFF will be simple and we will be sitting here facepalming ;-)
[HTC Wildfire S] *se-nsei.:
Who's planning to do that reverse jtag stuff?
[HTC Wildfire S] Antagonist42:
Something like that seeing as mARM boots the phone and hands over to aARM, mARM sets IMEM up with a 'secure' area neither ARM can access directly without using authenticated sig/software so it's either the NAND has specific blocks locked at boot as standard and needs the write enable on NAND bringing up or down to write or maybe the NAND's MMU asks for an address write to NAND to either a/mARM to access the secure area of IMEM as a bit like the MMU asking for a RPC to write to NAND, neither a/mARM are then requesting the write which would otherwise be denied as they cannot access the secure IMEM area, only indirectly.

Just need the guys who know how to manipulate the busses to verify this could be done maybe at low level --- I'm only a tinkerer lol :p

Rooted Xakep E320/C6 EUU Hacked Update
[HTC Wildfire S] Antagonist42:
I don't know how much the NAND MMU can do on that respect but going off my ACER it seems just as locked down as WFS, trying to get data out of it is murder lol

As for reading from the NAND I'm not 100% sure figures we read are 100% true if data from SMEM/IMEM can be stored and brought back up at reboot :confused:

Rooted Xakep E320/C6 EUU Hacked Update
[HTC Wildfire S] tacromx:
JTAG

@ se-nsei.

Im on jtag duty, build in progress, order for parts to farnell going in on monday, all schems and layouts complete, meanwhile....reading up on open jtag
[HTC Wildfire S] ctt812:
Is there any possible way to downgrade the Hboot version to 0.90.0000?:confused:

It is possible to S-off the Wildfire S by flashing the ROM1.zip extracted from the Official Bootloader unlock RUU. After S-off, the bootloader version will remained 0.90.0000.

If it does, then we could use the official unlock RUU to s-off. :D
[HTC Wildfire S] munjeni:
I not have time to play with nand but I found something interested about NAND CONFIG while erasing/writing nand using jtag... I think right key to enable WE (write enable) flag to nand is right nand config (we dont have complete msm_nand.h-eaders msm_nand.c-lib and possible/other commands for nand in any kernel out of here... "msm" enginers hide it to us!). Here is log during nand erase and during nand write so maybe some of you have got an idea for possibility to enable WE on. If you have found something please PM me! This is log from htc aria and phys offset taken from my procedure was from 0 to 0x2600000.... And here is my idea to convert erase_log to simple c code:

void msm_nand_hack_test(void)
{
unsigned *pa;

pa=ioremap(0xA900026C, 4096);	pa[0]=0x00000009;	iounmap(pa);
pa=ioremap(0xA0A00000, 4096);	pa[0]=0x00000034;	iounmap(pa);
pa=ioremap(0xA0A00010, 4096);	pa[0]=0x00000001;	iounmap(pa);
pa=ioremap(0xA0A00000, 4096);	pa[0]=0x00000034;	iounmap(pa);
pa=ioremap(0xA0A00010, 4096);	pa[0]=0x00000001;	iounmap(pa);
pa=ioremap(0xA0A00000, 4096);	pa[0]=0x00000034;	iounmap(pa);
pa=ioremap(0xA0A00010, 4096);	pa[0]=0x00000001;	iounmap(pa);
pa=ioremap(0xA0A00020, 4096);	pa[0]=0xAA5400C0;	iounmap(pa);
pa=ioremap(0xA0A00024, 4096);	pa[0]=0x00000001;	iounmap(pa);
pa=ioremap(0xA0A00000, 4096);	pa[0]=0x00000031;	iounmap(pa);
pa=ioremap(0xA0A00010, 4096);	pa[0]=0x00000001;	iounmap(pa);
pa=ioremap(0xA0A00024, 4096);	pa[0]=0x00000001;	iounmap(pa);
pa=ioremap(0xA0A00020, 4096);	pa[0]=0xAA5400C0;	iounmap(pa);
pa=ioremap(0xA0A00024, 4096);	pa[0]=0x000A7476;	iounmap(pa);
pa=ioremap(0xA0A00004, 4096);	pa[0]=0x00000000;	iounmap(pa);
pa=ioremap(0xA0A00008, 4096);	pa[0]=0x00000000;	iounmap(pa);
pa=ioremap(0xA0A00024, 4096);	pa[0]=0x00000001;	iounmap(pa);
pa=ioremap(0xA0A00004, 4096);	pa[0]=0x00010000;	iounmap(pa);
pa=ioremap(0xA0A00008, 4096);	pa[0]=0x00000000;	iounmap(pa);
pa=ioremap(0xA0A00000, 4096);	pa[0]=0x00000031;	iounmap(pa);
pa=ioremap(0xA0A00010, 4096);	pa[0]=0x00000001;	iounmap(pa);
pa=ioremap(0xA0A00000, 4096);	pa[0]=0x00000034;	iounmap(pa);
pa=ioremap(0xA0A00010, 4096);	pa[0]=0x00000001;	iounmap(pa);
pa=ioremap(0xA0A00000, 4096);	pa[0]=0x00000034;	iounmap(pa);
pa=ioremap(0xA0A00010, 4096);	pa[0]=0x00000001;	iounmap(pa);
pa=ioremap(0xA0A00000, 4096);	pa[0]=0x00000034;	iounmap(pa);
pa=ioremap(0xA0A00010, 4096);	pa[0]=0x00000001;	iounmap(pa);
pa=ioremap(0xA0A00000, 4096);	pa[0]=0x00000034;	iounmap(pa);
pa=ioremap(0xA0A00010, 4096);	pa[0]=0x00000001;	iounmap(pa);
pa=ioremap(0xA0A00000, 4096);	pa[0]=0x00000034;	iounmap(pa);
}

If you have better idea or you have idea :D, pm me! Here https://gitorious.org/ics-cyanogenm...s/blobs/master/drivers/char/memdump/memdump.c is my module... if you have programers skills to convert erase_log to c I will be glad to test it on my device!!!!!!!
[HTC Wildfire S] theq86:
not true, diag hboot may not have a "clickable" solution, but it supports many more fastboot commands.

2 interesting diag commands are writecid and writesecureflag. With writesecureflag you can write any value to the flag.
[HTC Wildfire S] munjeni:
I can disasemble wince spl but I can not disasemble android spl (hboot)... maybe dumped hboot from memory can be disasembled?
[HTC Wildfire S] no.human.being:
I think if that worked, there would already be lots of S-OFF WFSes out there, as probably a good share of them came shipped with HBOOT-0.90.0000. Mine came shipped with that version too, later I updated it to 1.08.0099 via RUU since the latter was unlockable and the former was not. Not sure with which version they're currently shipping it. Iirc, the bootloader will just "claim" S-OFF (for whatever reason), but not actually "act" S-OFF.

Btw, I read that there's also an HBOOT-1.03.0001 for the WFS. When was that and is it any different from HBOOT-0.90.0000? Afaik both are not unlockable.

Ah k, didn't konw of that. So yeah, then it's most likely in NAND (Radio) itself.

@tacromx: What debugger software are you using for the JTAG? OpenOCD? If so, could you share your chip and board script files with us and show me a quick session on how to set it all up correctly, have it connect to the processor, halt and resume execution, setting breakpoints, reading from and writing to registers, RAM, NAND, dumping disassembly? I'd love to try this myself, but it's a bit hard to figure it all out from the datasheets and manuals.

Also, what voltage does the MSM7227 run on? Iirc, something like 3.3 or 1.8 (?) V are common and if the JTAG supplies the wrong (or just when it supplies a too high?) voltage you will damage the processor. Wanna prevent that from happening, obviously. :D
[HTC Wildfire S] munjeni:
NoICE for ARM + Segger jlink EDU for debuging is good choice! I use revskills + seger edu to write and read to flash...
[HTC Wildfire S] no.human.being:
Mmh, I see several problems with that configuration.

1. I already have a JTAG interface for ARM using an FTDI FT2232H as UART.

2. NoICE is commercial software for Windows. I'm a Free Software guru with a Linux-machine and, backed by what I think is most likely the best toolchain in the world (GCC really kicks ass :D ), I'm truly not willing to pay for a debugger. :D

Have you already tried writing one of our patched HBOOTs to NAND? Expect it to be at either 0x02b00000 or 0x02400000 physical and be 0x00080000 in size. Dump it either via JTAG or via CWM + Fastboot using the procedure described here. After you have obtained a dump, place it on your phone's SD-card, then run "./inject --disengage-the-safety /sdcard/hboot.img" on it ("inject" utility is custom-designed and attached to the same post). This will patch the HBOOT image in file (will only work for HBOOT-1.08.0099 and HBOOT-1.09.0099 though) and turn it S-OFF (like Revolutionary does). Only problem is that we haven't found a way to write it back to NAND in software yet, but patching in file works. I'd say that if you write the image that our tool generates back to where your original HBOOT resided (so either 0x02b00000 or 0x02400000 physical) via JTAG, your phone should be S-OFF. This would probably make you the owner of the first WFS that is S-OFF, but was neither shipped S-OFF nor clipped S-OFF. :D

Just make sure you consider the OOB area somehow. Patching requires HBOOT image without OOB and generates HBOOT image without OOB, so if JTAG reads memory with OOB, you have to first strip the OOB off somehow and if JTAG needs OOB supplied and NAND will not generate it on its own (not sure about that) you'll have to somehow generate the OOB for the patched image again (since OOB data will be different for the modified image) before writing. But you probably know better what to do than I do. :D
[HTC Wildfire S] ctt812:
I remembered someone had told that using the official bootloader unlock RUU, he found that the phone was s-off when flashing one of the ROM.zip that was extracted from the RUU.

I give it a trial last night as my bootloader is version 0.90.0000. The supported RUU contained 2ROM.zip files, i.e. ROM1.zip and ROM2.zip. I renamed the ROM2.zip to PG76IMG.zip and put it on my goldcard, it skipped the bootloader update and update the radioV2 only. When I went into the bootloader, nothing special happened, it's still s-on. The bootloader version remained 0.90.0000.

Then I renamed the ROM1.zip to PG76IMG.zip and put it on my goldcard, it updated the radiov2 again. It didn't mentioned skipping the bootloader this time. When it's done, I got into the bootloader and found that it was ship s-off.

I just wondered whether it's not true. Just few minutes ago, I try to flash the CWM recovery V5.0.2.8 today with my goldcard, it succeeded. Then I rooted my WFS with the root.zip put on my goldcard again.

And now my phone is s-off, rooted with CWM recovery installed.

If we're able to downgrade the hboot of WFS to 0.90.0000 by any means, I think the ROM1.zip of the official bootloader unlock RUU is the key! However, the EU RUU had already have only 1 ROM.zip instead of 2. And it seems that this method only work with those having hboot 0.90.0000 and I haven't heard of anyone mentioned s-off during the unlock process with other version.

I don't know if this information can help in the s-off quest of our WFS as I was a noob in all those programming/engineering, but I think you DEV may be able to do that.

By the way, my WFS is on stock rom updated via OTA to 2.3.5 and running sense 2.1.

My software : 2.17.832.1

initial radio : 47.23a.35.3035H_7.53.39.03M

after update radio : 47.23b.35.3035H_7.54.39.08M

I used the RUU for my WFS i.e. HKCSL_CHT
[HTC Wildfire S] theq86:
this is already known ;-)

problem is, that we have no way to downgrade to 0.90.0000.

trying it will make hboot show "bypassing hboot upgrade"
[HTC Wildfire S] Lt.Win:
But tell me, wouldn't

http://xdaforums.com/showthread.php?t=1540952

+

http://xdaforums.com/showthread.php?t=1301388

=

HBOOT 0.9?
[HTC Wildfire S] theq86:
no. maximum downgrade version is 1.03.0000

every older hbood downgrade will be bypassed
[HTC Wildfire S] Lt.Win:
Ah, I see.

Thanks for the enlightenment. :D

There was me, getting excited. :p
[HTC Wildfire S] no.human.being:
Do you know what HBOOT version phones are currently shipped with? I mean if you bought a WFS today and wouldn't perform any firmware upgrade, would you be on HBOOT-0.90.0000? Mine still shipped with that version but that's more than a year ago. :D

Another thing: Do we know what cryptographic methods are used for signature generation? I mean usually you feed the data you want to sign through a cryptographic hash function, then sign it with your private key. Your public key gets published (or embedded in firmware in our case). When the device wants to check the signature, it applies the public key. In case the signature has not been tampered with, this will yield the original crypographic hash. Then the verifier hashes the data again and compares the hash values.

Now the asymmetric algorithm used seems to be RSA with a key length of 2048 bits, which is guessed to take about 15 years to break. This is not using brute force, but using large integer factoring algorithms - asymmetric algorithms are much weaker than their keyspace suggests, since they rely on mathematical problems that are considered "hard" to solve, yet there are much more efficient algorithms than trying all possible combinations. However, because of the 15 years, providing they didn't do any major fault while implementing the algorithm, we can consider it "unbreakable" in our case. (I guess not a lot of people will be interested in this phone 15 years from now. :D )

However, how about the hash? Something in the area of 128 - 160 bits (say MD5 or SHA-1) could probably be broken on today's hardware using GPGPU methods. With my workstation and my server alone I could supply about 1 TeraFLOP of computational power. Say in the end we find 10 people willing to donate computational power, then we split the keyspace in 10 parts and let each one scan. Basically what we would do is put additional "junk" at the end of the patched HBOOT image (which will of course never get executed, since no one is branching there) and modify that "junk" until we find a patched HBOOT that produces the same hash as the original. Then we could flash that HBOOT from within an "original" HBOOT.
[HTC Wildfire S] munjeni:
Revskills + segger is good "free" choice, and have option to write with or without oob data, allso you are abble to do a lot off manually things to your device (in comparation with comercial box and automated processes you are not abble to write to an offset that you want, allso you need to pay credits to stupid boxes), so I'm happy with revskills and I'm abble to write to offsets that I want . Its not problem. Your theory is ok, but no one software...etc can write to nand (from 0 to spl or hboot offset)... I have htc aria native android device, but I hacked aria and installed wince 6.5 -> http://xdaforums.com/showpost.php?p=22592946&postcount=7 using jtag, allso I installed a lot of stufs using jtag, but I wanted to hack phone using software writer but its really imposible (nand have "read only" flag at 0 to ~0x2480000, don't know how to break it!). Allso, I have project for htc hd mini (HSPL - hard spl) and project is done and is tested on device by jtag, but, no way to install that hspl to nand using software metod... so you and me have same problem! We need to break protection! But how? And where? And what is protection?
[HTC Wildfire S] theq86:
I bought my phone in november 2011. It was shipped with HBOOT 1.03.0000.

It is highly dependent on your purchasing source. Some merchands do firmware updates on all phones before selling them, some don't.

But I thought of something different. secuflag may be in NAND. The rom_01.zip that turns a 0.90.0000 S-OFF updates only one part of the radio. That means:

a) the secuflag lies in the radio_v2 image and changed it's location. hboot 0.90.000 is too old and looks only for the old secu flag address. thus thinking it's s-off

b) the secuflag lies outside radio_v2 image, but the RPC call that reads secuflag got a new entry point which hboot 0.90 is not aware of.

Any other idea WHY hboot would claim S-OFF?
[HTC Wildfire S] no.human.being:
Eerm the difference is that you have "low level" access via JTAG, so you can run "supervisor mode" code and there's no firmware "beneath" you, while we only run "user mode" code and have two operating system kernels (Pistachio from the Radio and "Linux" from Android) beneath us that shield us off. You should be able to directly drive the processor's memory bus somehow. Don't ask me how, I really don't know, but I know that JTAG is used for "boundary scans" and that these work by something like toggling all I/O pins of the chips and see along which traces the signal goes, so that you can find errors in the PCB like broken traces or short-circuits using this method. There's probably a much simpler method using the processor's official I/O commands.

You could also try trapping the processor directly after power-up and then single-step through HBOOT to find the loop where it unlocks the NAND pages that we're supposed to have write-access to (e. g. everything from 0x24000000 or 0x2b000000 onwards), figure out which commands it does and then execute these commands for the area that is still locked as well.

Or you could trap directly after power-up, then upload our patched HBOOT to the processor's volatile (RAM) memory and have it execute. The device will be "volatile S-OFF" then, so it will be S-OFF but only until you reboot. You then boot it into HBOOT mode and flash the patched HBOOT to persistent memory as well using "fastboot flash hboot hboot.img" or something like that.

C'mon some of this MUST work. JTAG can de-brick phones that don't even react to the "power" button anymore because their low-level firmware is completely screwed. Don't tell me that there's any way that firmware can actually enforce "access permissions" against the JTAG debugger. Just halt the firmware before HBOOT's "NAND unlocking loop" exits and execute further "unlock" code before the lock is made "permanent" or toggle the NAND's "WP" flag after it has been made "permanent", as this will reverse the "lock-tight" state and turn into "fully locked" (actually ALL pages locked), but accepting "unlock" commands again. Or modify the HBOOT code so that signature check always passes (which may be as simple as making a conditional branch unconditional or NOPing it out).

Find the HBOOT code that flashes RUU, trap there, run an RUU on the phone, then continue until the checks are through and flashing begins. Make sure to trap there again, then replace the RUU code in memory and resume execution.

C'mon be a bit creative! There are so many things you can do with JTAG, there's no way to protect against it. Physical access has always been unlimited access. Don't tell me that this has changed with the advent of Android. :D
[HTC Wildfire S] munjeni:
Hboot can not run with hackish method by copying to volatile memory and runing it, it can not boot! Its same with spl for wince. Spl was runing only after patch. But spl is not striped like hboot, and spl is better readable from disasemble than hboot. Hboot is totaly unreadable (only good asm skill can do it)

revolutionary hboot installer can do it by software method
[HTC Wildfire S] no.human.being:
I have read HBOOT for creating the exploit. Not while in RAM but while on NAND. Well it's large but I don't think it's obfuscated. Does the code get "more obfuscated" while/after it is loaded to RAM? Is there some part in it that is "self-modifying"?
[HTC Wildfire S] munjeni:
I dumped revolutionary software parts from memory, and this file in attachment is a file who patching hboot! See my progress with revolutionary here -> http://xdaforums.com/showthread.php?t=1489031
[HTC Wildfire S] munjeni:
I don't tried, but maybe hboot from ram is de-obfuscated?
[HTC Wildfire S] no.human.being:
No what I meant was: HBOOT in NAND is certainly not as "unreadable" as you claim. It's compiler-generated code without debug symbols, probably optimized and with inlining and such stuff, but it's certainly not "obfuscated" or if it's supposed to be obfuscated then the obfuscator was not very effective lol. :D

I find ARM machine code much more readable than, say, x86 code. It's almost a pleasure. When it comes to x86 code I usually don't get far. Too complex instruction set, too many addressing modes, etc. :D
[HTC Wildfire S] munjeni:
Yes, I allso think its striped without debuging symbols so I leave it after opening. But I found function from aria hboot "isSecurityOn" when I compared asm code from an hboot.idb from google search, issecurityon in aria hboot 1.02.0000 is:

sub_6E74	; CODE XREF: sub_29B4+3ECp
; sub_31A8+1F8p ...
STMFD	SP!, {R4,LR}
BL	sub_43DC4
CMP	R0, #0
MOVNE	R0, #1
LDMNEFD	SP!, {R4,PC}
BL	sub_5FAC
MOV	R0, R0,LSR#5
AND	R0, R0,	#1
LDMFD	SP!, {R4,PC}
; End of function sub_6E74

I tried to find function for partition layout (tried to increase userdata) but without luck :( Did you maybe know is there a way to call an function from hboot by simple asking it from an offset?
[HTC Wildfire S] no.human.being:
If you want to turn security off, go 0x00008b68 (HBOOT-1.08.0099) or 0x00008b58 (HBOOT-1.09.0099) into the code from where HBOOT is loaded to (so add HBOOT's "base address" in RAM to the values to determine physical RAM address), then change 3 machine instructions (each 32 bit long) to the following ("big endian" notation, so "low addresses" are "left" and "high addresses" are "right"):

For HBOOT-1.08.0099:

0x10402de9

0x4ec600eb

0x000050e3

For HBOOT-1.09.0099:

0x10402de9

0xbdc600eb

0x000050e3

Afterwards security should be off, but it's volatile. Beware that the Radio area is protected even on S-OFF phones, but you might be able to flash our patched HBOOT images to NAND permanently after you got an S-OFF HBOOT in RAM.
[HTC Wildfire S] munjeni:
OK, I can/was allready added spl to iomap, and changed some parts inside spl in memory, but hmmm, whats use of it, how to call something and debug an call?