yashsingh1/xdaforums huggingface dataset:
[HTC Wildfire S] no.human.being:
No it is not. It is reading a pointer (another address) from address 0x9d080b24 first. Then it adds 0xfc000 + 0xe0 to the address obtained in the previous step (NOT to the 0x9d080b24 but to the value which was read from there), treats it like a pointer again and reads an int from it.

You see the code is "return * (* 0x9d080b24 + 0xfc000 + 0xe0);". The asterisk ("*") is the "dereference operator" in C. It means "follow the pointer" (in this case "read from the address"). The dereference operator has higher operator precedence than addition, so 0x9d080b24 gets dereferenced first (which means the word stored at this address is read). Then 0xfc000 and 0xe0 get added to the result obtained from the dereference operation and the result of that operation is dereferenced again (so the value stored at THAT address is read).

To prove let's decompose the statement.

It all starts with the value 0x9d080b24.

0x9d080b24

This value is dereferenced (the value stored at the address is loaded).

*0x9d080b24

The values 0xfc000 and 0xe0 are added to the result of the dereference operation (so to the value that was read from 0x9d080b24, not to the value 0x9d080b24 itself).

(*0x9d080b24) + 0xfc000 + 0xe0

The brace is just for clarity that the dereference operation is performed first and THEN the two other values are added to the result obtained. As the dereference has higher operator precedence than addition, we may omit the brace. The following code will do exactly the same as the former.

*0x9d080b24 + 0xfc000 + 0xe0

Then the result of this entire chain of operations is dereferenced again. Since dereferencing has higher operator precedence than addition, we need to put our expression in braces to cause the dereference operation on the entire expression built so far. If we were to omit the brace, we would dereference 0x9d080b24 two times and then perform the addition, which is not what we want to do, so we write the following.

*(*0x9d080b24 + 0xfc000 + 0xe0)

Finally we return the result of the dereference operation from our function.

return *(*0x9d080b24 + 0xfc000 + 0xe0);

Which is exactly what you decompiled. So it's not address "0x9d080b24 + 0xfc000 + 0xe0" (which is 0x9d17cc04) that is accessed. Instead, address 0x9d080b24 is accessed, which is where another address is stored. The offsets 0xfc000 and 0xe0 are added to the address obtained from 0x9d080b24 and the result is again treated as an address from which a word (int) is loaded. This int is finally returned by the function.
[HTC Wildfire S] munjeni:
Thanks... so I think now as thinked before, it looks like msm_shared_ram_base+fc000+xx ... fc000 is offset most used with shared ram base in htc hd mini developmment for battery and many other functions we used for that phone... I will try in next few days...
[HTC Wildfire S] no.human.being:
Mind that the splitting of the addition to "something + 0xfc000 + 0xe0" might not have a real meaning, but may merely be due to restrictions in the ARM instruction set.

ARM instructions have a fixed length of 32 bits and ARM has 32 bit word/register size. This means that you cannot encode arbitrary 32 bit constants into an instruction, since some bits are already used to encode what operation to perform, which operands are registers, which operands are constants. Then there's only few bits left to encode the actual values, e. g. the value to be added to the address. Because of this, you may not, for example, say, add 12003. Instead you might have to add, say, 8000, then you add another 4000 and finally you add 3 or something like that. Of course in the real instruction set the values are not going to be something like 8000 and 4000, but powers of two or values composed of few powers of two, like 192, which is 2^7 + 2^6.

Because of this restriction you will often find that constants are not encoded into instructions, but appended after the end of a function and then loaded into a register relative to the instruction pointer and then that register used as an operand in some operation. So often the compiler will generate something like this.

0x1000: ldr r0, [ip + 0x14]
0x1004: add r2, r1, r0
0x1008: ...
0x100c: ...
0x1010: bx lr
0x1014: <constant that is loaded into r0 at 0x1000>

Instead of, say, encoding the constant into the "add" operation.

EDIT: Btw, I've stumbled across an entirely Free and Open Source baseband (Radio) firmware implementation. So far it only supports some exotic processors from TI ("exotic" meaning not OMAP which is probably the most popular ARM processor from TI) so we currently cannot use it to replace the Qualcomm Radio on the WFS. However, it might be worth looking at nonetheless since it may help understanding how Radio firmware operates. In particular it includes a tool called osmoload which is used to write the Radio to Flash memory.
[HTC Wildfire S] sythe179:
Hey, its m again.

Not sure if its useful at all,but I stumbled across this for the vision, and thought it might be relevant.

http://tjworld.net/wiki/Android/HTC/Vision/RadioAnalysis
[HTC Wildfire S] no.human.being:
Btw, the Radio firmware, also known as REX, is "heavily based on" (quite an euphemism for "stolen from" huh? :D ) Iguana, which is Open Source software. Grab the sources and look inside the "wombat" folder. Looks quite familiar, right? Seems to be a stripped-down Linux kernel. :D

Does anyone know how to build Iguana from source? I don't see any "root level" Makefile. It could be the foundation for a compatible "vanilla" Radio build without any Qualcomm modifications.
[HTC Wildfire S] sythe179:
Amazingly, that's what I thought...
[HTC Wildfire S] :
Nice. Next let's find a Pistachio based radio.

Sent from my TARDIS
[HTC Wildfire S] no.human.being:
Did you even read what we wrote? The Qualcomm Radio is a build of REX, which in turn is a (modified) Iguana and Iguana is an operating system for which Pistachio is the kernel.

So let's grab the Iguana sources and build a Radio from source with all the proprietary Qualcomm stuff removed. No idea how much stuff on which Android depends will be missing though.
[HTC Wildfire S] munjeni:
Its very hard for porting to our msm7227 device... I think its wasting of time! Any one know if is posible using qemu emulator and loading complete firmware into it including radio, hboot...etc?
[HTC Wildfire S] no.human.being:
@munjeni: You can write kernel-level code?

That's very cool actually! What happens when ...

1. ... you pass an "erase" command erasing the pages containing HBOOT from the kernel?

2. ... you pass an "unlock" command unlocking the pages containing HBOOT from the kernel?

3. ... first do step 2 and then step 1?

4. ... first pull WP low from the kernel, then do step 2 and then step 1?

5. ... first pull WP low via hardware (shorting it to ground?), then do step 2 and then step 1?
[HTC Wildfire S] munjeni:
Step 1,2 (this step is not working... msm_nand kernel modul have no implemented unlock option!),3 as I say no way to erase/write to hboot partition! Step 4,5 how to do it?
[HTC Wildfire S] no.human.being:
Couldn't we implement the unlock option? We have the datasheets for the NAND chip. Unlock is just a command to the NAND chip like "read" or "write" or "erase". Apart from "unlock", there's also "lock" and "lock tight". However, I'm not sure whether aARM can directly issue commands to the NAND or if only mARM (Radio) can.

Pulling WP (write protect) low is neccessary for getting the NAND out of the "lock tight" state in case the Radio enables it. After pulling it low, NAND will be entirely "locked" (all blocks!), but will accept "unlock" commands again, while it won't accept "unlock" commands while in "lock tight" state. If WP happens to be under mARMs control, so that we cannot drive it low, we could either consider shorting it out on the hardware side should the trace be accessible on the circuit board in any way or driving it low using JTAG. However, if we get JTAG access, then things should get a whole lot easier anyhow, since we will then have the ability to directly control the processor and program the NAND without restrictions. We could trap the Radio before it makes the lock tight and then execute some code or whatever. JTAG access is the master key. But at the moment we don't have it and I'd also like to have a solution that doesn't require it for performing the S-OFF, so I'd just use it for testing and development, but not in the actual procedure of S-OFFing.

Here are lots of proprietary datasheets for components commonly used in Android phones. It's the "NAND or OneNAND + RAM pdf" datasheet in the "Micron" section. Page 42 to 48 describes the major security features of the chip.
[HTC Wildfire S] :
Ohhhhhhh yeaaaaaaaaahhhhhh...... *strokes chin*

Sent from my TARDIS
[HTC Wildfire S] schlund:
the unlock procedure described in the document sounds very similar to the known wire trick http://androidforums.com/evo-v-4g-all-things-root/561401-s-off-wire-trick.html

someone with a dissasembled device should measure the resistance between those two pins and the WP# pin of the nand chip.
[HTC Wildfire S] meanmug:
I had an epiphany while reading the last comment by schlund, would it make it allot easier to view the unlock sequence with the JTAG while connected to the phone and the xtc-clip. Not sure if it's been mentioned or not, apologies if it has.
[HTC Wildfire S] schlund:
a simple idea would be checking the pins with the scope while flashing a stock rom, if we can see a unlock sequence it should be quite simple to add a while loop with the unlock command to that lil program that someone has made (dont remember the name) and advise the user to set that pin to ground
[HTC Wildfire S] Antagonist42:
Docs Docs and more Docs

This is the latest one found, have a few more although they may be in need of translation and 'fixing' as the document 'fell to pieces' after downloading it, went from text in a possible pdf viewer to component gibberish afer downloading :laugh:

This is the best out of them up to now the...

AMSS 7x27A Linux Release 2.0.35 (Modem, Multimode) for Android™ Platform-Enabled MSM7627A Devices Release Notes for M76XXUSNEKNLYM2035 80-N8519-9 A cool thing is it's Dated March 21, 2012

Posted here under MSM7627 section worth a read as mentions build environment, Primary and Auxiliary JTAG, USB Trace32 and a few more bits and pieces for NAND :cyclops:

** Sorry not been that active trying to keep a dying PC going without losing everything is sooooo much fun :laugh: .... :eek: **
[HTC Wildfire S] :
What are your specs?

Sent from my TARDIS
[HTC Wildfire S] munjeni:
Yes, thats what I waiting from all you... in document there is step by step procedure with a lot of commands, but I not understand completely in document how to implement it in "software"... but with your help I will try... lets start colecting here interested parts of the nand document and lets start "converting" it to kernel bassed code! Here is my old idea that I not finished but I think its possible (especialy while we implement something from nand datasheet). http://xdaforums.com/showpost.php?p=26580368&postcount=2451 -> In that module for sure "nand base" is 0xa0a00000 so implementing an part from datasheet to nandump module I think will give something for us, or at least porting something from my jtag log into module allso will do something for us, allso do not forget nand mpu (part in datasheet explaining how nand mpu is configured "there is defined offsets from/to defined to have: read or write or read_and_write flag"... so lets start and let start analysing document and let start dumping these from phone and analyse them :) I tried to dump nand mpu but its not possible (have only write flag?), but writing to mpu is possible... Next time when I conect device to jtag I will dump a0b00000 offset with NoICE soft and will post it here for analyse. I'm glad to have "one click" solution, instead of using jtag, for switching between android or windows 6 (I confirm it working in htc aria) or (do not forget new windows 8 that coming to mobile devices:))
[HTC Wildfire S] munjeni:
Let start porting things for nand from this document -> http://dl.dropbox.com/u/69550833/1_3152094__2__80-VA736-2_RevB_MSM7200_Software_Interface_Manual.pdf

Compare values from document with this https://gitorious.org/ics-cyanogenm...s/blobs/master/drivers/mtd/devices/msm_nand.h and you will see its the right document for us :)
[HTC Wildfire S] Antagonist42:
Phew!!! :eek: Luckily I'm not bricked....

SKU could hold a key to gaining access to NAND....

I flashed the (stock 1.008.00 ORGUK initially) updated FOTA 1.013.00 ORGUK with a ROM from club-acer.ru from Xakep which appeared to be for E320 was actually based on E310 .hex files (yet to check if any similarities with these phone versions) as I've been playing around with the system and generally screwing it up (:confused: noob!) managed to get the basic Xakep ROM without ROOT installed, then recovery with Xakep's T.W.R.P. recovery, trying to get Orange's EUU to flash continually replied it was the wrong SKU for the phone (this area I have not ventured into so have no idea except maybe region specific releases).... here's how simple it was to get it back.... used all main files/drivers from Xakep EUU, copy in the .hex files from Orange EUU, edited the FileList.txt and VerList.txt from Xakeps files to Oranges files ...... Now Running the Orange update as before I flashed over it, none of the .hex files relate to each other in file name or size, Orange update is EMEA_ORGUK and Xakep EMEA_GEN1.

As the Xakep EUU was able to update, edit it and reflash files through fastboot would it be an idea that an earlier version of WFS stock or early update if any (don't know if or how many there are) may open up a timestamp/crc/sha1 check and pass it, this is where I believe the WDOG_EN and BOOT_SCUR are maybe held low (security passed) and able to flash to NAND as tracing GPIO95_BOOT_SCUR through to the PACDN1408CG (Transient Voltage Suppressor) which is then connected through to WDOG_EN (dedicated pin on MSM7xxx) the other two connections on PACDN1408CG are for camera.

What I am unsure of is *when* the WDOG_EN is implemented either before, during or after PBL reads off-chip boot configuration data from flash memory or if it processes configuration data setting up clocks and memory access first? as it's part of MSM7xxx is it simply on when powered up?

That said it leads me to believe (if I read the info correctly) that because they are driving the GPIO95 pin high/low that the QFuse for FORCE_TRUSTED_BOOT has not been blown otherwise GPIO95 would just be a GPIO and not tied to WDOG_EN ....if we can gain control over or direct WDOG_EN to suspend or go low you should have control over NAND read/write but the way the system is built I think a on system/app approach maybe nigh-on impossible as to how the circuit and chips are wired, although not to be ruled out ;)

Acer Liquid Mini E310 - probably same internals except maybe NAND/RAM type and running 200Mhz slower than E320
[HTC Wildfire S] munjeni:
I not understand next things in document. Nand things in documen is:

[U][SIZE="5"]NAND Controller Software Interface (page 359)[/SIZE][/U]
Number of word addresses: 32
EBI2 NAND memory space: 0xA0A0 0000 - 0xA0AF FFFF
EBI2 NAND address range: 19:0
MPU memory space:0xA0B0 0000 - 0xA0BF FFFF
MPU address range: 19:0

than folowing page 411:

[U][SIZE="5"]MPU registers[/SIZE][/U]
0x100000 NAND_MPU_ENABLE
Type: Read/Write
Clock: Bus clock
Reset State:0
The MPU_ENABLE register controls when the MPU starts and stops filtering bus
requests.

Stop here. Address 0x100000 . Is this direct offset or its offset mpu_addr+0x100000 or its ebi2+0x100000 ??? I'm not surre because ebi2 and mpu have space of the 0xFFFFF , but offset 0x100000 is out of space... so question is what is 0x100000 ?

Next thing. MPU is used for filtering or stop filtering bus reguests. So next part of document about permisions for each bus/partition explaining how it is defined! The same that I not understand is offset, but interested part is 0x100018 NAND_MPU_DEF_PART_PERM_AARM, 0x100028+0xNAND_MPU_PARTn_PERM0, n=[0,1]... here is defined permision for each bus/partition(n)

The MPU_PARTn_PERM register assigns the access permissions for all bus masters (ID
31 through 0), except those assigned to the aDM and mDM for partition n.

So again I not understand only this "offset" before NAND_MPU.XXX XXX X...etc But if you folow for example 0x000004 NAND_ADDR0 and compare it with msm_nand.h you will see its 0x000004 in msm_nand.h so it mean its used in kernel like 0xa0a00000+0x00000004, but if you folow 0x100000 NAND_MPU_ENABLE and definition in document (EBI2 NAND memory space: 0xA0A0 0000 - 0xA0AF FFFF) or (MPU memory space:0xA0B0 0000 - 0xA0BF FFFF), 0x100000 have no sense in document and that offset is out of space! Is this bug in document (missing something?), (carefully bugged in document?)?
[HTC Wildfire S] munjeni:
Edit:

Whatewer I try after nand_mpu off, memory protection off...etc and using dd, nanderase flash_erase, nandwrite...etc, I allways getting "fail on oob and error -5" in dmesg, so I think hacking nand is not possible without modifying "msm_nand.c" module (I think its designed only for "userspace" partitions "boot, cache, userdata, system, misc" that still use oob data!!!). But when I used (ported part of jtag log and converted it into c kernel 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);
}

my system partition is broken, thebucket stoped working, no busybox comands, new bad blocks...etc, so lets analysing jtag_log posted here and analyse sequence/steps in comparation with nand_ebi2 addr + offsets defined in msm_nand.h and current document for nand! Lets see manualy what steps is performed in erasure/write procedure in jtag log... and than create an module that will do the same thing that is in jtag log ... do you want to help me or not?
[HTC Wildfire S] Antagonist42:
NAND and EBI2

Number of word addresses: 32

EBI2 NAND memory space: 0xA0A0 0000 - 0xA0AF FFFF

EBI2 NAND address range: 19:0

MPU memory space:0xA0B0 0000 - 0xA0BF FFFF

MPU address range: 19:0

Essentially you are not accessing the NAND data directly it is the NAND chips MPU (Memory Processing Unit) which is made of Registers and Data Movers so depending on what Command you are using dictates your access to either the Register, say for access to

set partitions

on the NAND chip, or the DM {Data Mover} say to

read/write

data to and from the NAND.
[HTC Wildfire S] munjeni:
Yes! You can read and write to nand registers, you can set up nand mpu, you can setup nand offset that you want to program, you can set offset for erasure... but first you need (as a me) to understand how it still working in real way (using an userspace aplication)! Its good explained in document (some parts is not clean but more parts from document is in msm_nand.c and h allready!!!)... good example is in memdump module, there is allso example how to access 0xa0a00000 nand ebi2 address and read nand cfg, nand id, nand status...etc. Good log about erasure procedure is in jtag log... but first we need to understand how to do it, it will be better to enable more debug logs in kernel when we erase for example block 305 and compare log with msm_nand.h and document...etc and try to do the same erasure on block 305 with nandump module, than we will understand how its performed...

You can do it, for example, I will try everything on my device, I will write module in kernel, one from you will enable more debuging in msm_nand.c, one of you can analyse posted logs, one of you can watch our comunity and give more ideas, one of you...etc...etc... we need team to start working on it... if you are interested we will do it!

I will enable more loging in nand module, will erase boot partition and will post dmesg, so we will analyse everything in dmesg about erase procedure performed in that time. Any one still working on kernel for WFS ?

Edit:

First look in msm nand. Why there is staticaly defined:

#define MSM_NAND_CFG0_RAW 0xA80420C0

#define MSM_NAND_CFG1_RAW 0x5045D

First step we need for example to look in document and see why cfg0 and cfg1 is 0xA80420C0 and 0x5045D and what that mean
[HTC Wildfire S] Antagonist42:
I'm not sure but I think the following from page108 2.Security Registers

may

apply to the whole document

Note that the addresses here are generic. They must be multiplied by either 2 or 4
depending on whether the MPU instantiation is using a 16 or 32-bit interface respectively.
They must also be offset properly for the specific MPU.

This could be why addresses don't add up.
[HTC Wildfire S] rezo609:
The EVO 4G LTE just got their S-OFF via LazyBear method
[HTC Wildfire S] munjeni:
Guys, need help here -> http://xdaforums.com/showthread.php?t=1739477

Allso, do you know if WFS have an hboot that have diferent partitions than other WFS hboots??? Need to analyse them!
[HTC Wildfire S] no.human.being:
Doesn't seem to work on WFS.

# ./fastboot oem listpartition 0
...
(bootloader) [ERR] Command error !!!
OKAY [ 0.006s]
finished. total time: 0.006s
#
[HTC Wildfire S] munjeni:
Try without 0
[HTC Wildfire S] no.human.being:
Already tried with 0 and 1 and with and without the "oem". All variations are doomed to fail.
[HTC Wildfire S] no.human.being:
The Wildfire S was released in May 2011 and is still not supported by official HTC unlocking service. Just check the device list. The devices HTC was willing to unlock until now are:

Furthermore, this will only allow flashing of Custom ROM, no flashing of the Radio and probably no flashing of Custom Recovery.
[HTC Wildfire S] Lt.Win:
The rezound, explorer and many new devices have been unlocked via htcdev even if they're not in the list. :-( WFS won't get anything I guess
[HTC Wildfire S] pihug12:
Maybe this could help : pocketmagic.net/?p=1462 [Android C native development using the NDK under Windows]

(can't post the complete URL, you know what to add before it)

Just my two cents.
[HTC Wildfire S] *se-nsei.:
Well HTC have only just announced that all 2011 devices can be unlocked - but these news items are misleading. Anyone wanna try out the HTCdev method once more time to check?
[HTC Wildfire S] ONeill123:
I have checked with hboot 0.9 and anyone tested with newest hboot, but nothing work.

And the bootloader must understand these commands and that only with new hboot.
[HTC Wildfire S] *se-nsei.:
What about the newest? hmm