yashsingh1/xdaforums huggingface dataset:
[HTC Wildfire S] Antagonist42:
Un-Erasable NAND? No. Correct Filesystem? maybe

Essentially I reckon we're asking for all the right Data from NAND but we're asking for information that only an 'Admin' user should be able to access (trying to explain it simply) and we're only the customers, the office staff (your service provider, phone provider - HTC,Samsung,etc) only pass on updates to the 'already' set up system so they have Login rights (to update etc) but the admin as it is (Qualcomm/Micron Technologies) provide as it is the hardware, the main OS (which is NOT written in Linux but BREWmp) which is compatible with Linux/Android then all we can do is alter what they allow though the Core.

Basically we need to know how the src\BREWSigVerify.c:795 and 812 are called and used, this probably gives read/write access but to what exactly is also what needs to be known as with the following:-

OneNAND Datasheet Info

.Invalid Block Operation.

Invalid blocks are defined as blocks in the device's NAND Flash Array memory that contain one or more invalid bits whose reliability is not guaranteed by Samsung.

The information regarding the invalid block(s) is called the Invalid Block Information. Devices with invalid block(s) have the same quality level as devices with all valid blocks and have the same AC and DC characteristics.

An invalid block(s) does not affect the performance of valid block(s) because it is isolated from the bit line and the common source line by a select transistor.

The system design must be able to mask out the invalid block(s) via address mapping. The 1st block, which is placed on 00h block address, is always fully guaranteed to be a valid block.

Due to invalid marking, during load operation for identifying invalid block, a load error may occur.

Essentially we NEED to know where the Originally programmed invalid blocks are or we screw the chip up by erasing them all so any later incurred bad blocks will be written to and lost, I don't think you can Re-Find them once the Invalid Block Table has gone.
[HTC Wildfire S] no.human.being:
Android phones are not running on Brew.

On our phones, on the lowest level, there is "processor specific" firmware by ARM Ltd. / Qualcomm shipped with the processor. This one basically "virtualizes" the processor, providing two "virtual machines" running on the same hardware with shared memory. One of these runs the Radio firmware (which is an Iguana operating system running on top of a Pistachio microkernel), the other runs HBOOT, which in turn loads the Android kernel into memory and passes control to it. After that has happened, HBOOT is "gone" and Radio + Android run in parallel, communicating via shared memory. That's it. There's not another firmware layer. Brew is not intended for use with smartphones.

No we don't need to know that. When a page/block is "bad" (I know one always talks of "bad blocks", but is it really done per block or rather per page?), the address space will always have a "hole" at this position. As long as the operating system does not work around this on the file system layer, all data in it is lost. The firmware has to be tolerant to that. There is no "remapping of pages/blocks" taking place for pages/blocks that are marked bad. The memory controller just can't do it. When you encounter a "bad block" (page?) programming, say, the Radio firmware, you have no option but leaving a 2 KiB (128 KiB?) "hole" in the Radio. Either the Radio can "live with that" or it can't. There's no way to "correct" it, as there's no layer that could remap bad blocks. So even when you mark it as "bad", all the Radio can do is say "ok this block is bad so we discard the 2 KiB (128 KiB?) that it's supposed to hold". So it can save the memory cells from being erased and written. However, it can't put the 2 KiB (128 KiB?) elsewhere, as the Radio is "raw" and does not have a file system. It either has to live with the fact that the 2 KiB (128 KiB?) have just "gone corrupt" or it has to "fail" somehow requiring you to replace your faulty hardware.

The "operation not supported" sounds like locking isn't supported on a lower level, so either the kernel-level driver doesn't support locking/unlocking pages or the NAND doesn't have "locked" flags in the out-of-band area of the pages where this information could be stored. If that is the case, the memory cannot be in a locked state and as such cannot have an "unlock" operation performed either. So I tried without "-u" supplied.

/sdcard/mtdutils # ./flash_erase /dev/mtd/mtd7 0 0
Erasing 256 Kibyte @ 0 -- 0 % complete libmtd: error!: MEMERASE64 ioctl failed for eraseblock 0 (mtd7)
error 5 (Input/output error)
flash_erase: error!: /dev/mtd/mtd7: MTD Erase failure
error 5 (Input/output error)
Erasing 256 Kibyte @ 40000 -- 50 % complete libmtd: error!: MEMERASE64 ioctl failed for eraseblock 1 (mtd7)
error 5 (Input/output error)
flash_erase: error!: /dev/mtd/mtd7: MTD Erase failure
error 5 (Input/output error)
Erasing 256 Kibyte @ 40000 -- 100 % complete
/sdcard/mtdutils #

It says "ioctl failed for eraseblock". The "ioctl" is a kernel call. So I'm quite sure that we're hitting a kernel restriction now.
[HTC Wildfire S] SeeKai:
Which means we need a new (custom) recovery kernel? Is that within your area of expertise? I know how to build a custom kernel for my linux server but have'nt done anything like that for a HTC phone, yet... And that's apart from the additional recovery thingy.
[HTC Wildfire S] no.human.being:
No I can't do it. I tried porting a Linux 3.2.5 kernel to the phone, but it didn't go very well. Getting the kernel to compile was a pain (sources are full of bugs and you need to touch a few dozen lines just so that it's proper C code, kernel devs seem to be really sloppy people :D ). Then the MSM7227 chipset was not supported, closest were MSM7201 and MSM7230. I decided to go for the MSM7201, as I expected the MSM7227 to be backwards, but not neccessarily forwards compatible. However, the kernel didn't boot. It always locked up the phone with a white screen, not reacting to anything. All you could do was pulling the battery.

Best thing that could happen to us would be Alquez building a CM kernel with the restrictions removed from the mtd driver.
[HTC Wildfire S] SeeKai:
Maybe it's available in the 3.3 kernel... :)

I dunno how the ranks work here at xda or at cwm, to get any assistance on this from someone who can, do you?

Edit: Could you contact Alquez? You could probably give him a better explanation of what we are running into atm than I can... And hope he has access to the driver source (ie not a binary).
[HTC Wildfire S] no.human.being:
I did contact him in the first half of February this year. He told me to contact PabloPL, who was trying to get Linux 3.x running on a Qualcomm chip. PabloPL told me to try to connect to an on-board UART (special kind of serial connection) where the kernel seems to output "debug information". However, connecting to this UART requires you to perform modifications on the phone's hardware (soldering around etc.) and I wasn't really willing to dig into this.

Best thing would be someone modifying the mtd driver within Alquez' CM kernel to ignore bad/locked/whatever blocks, then building a minimal GNU system around Alquez' CM kernel (CM itself is not self-contained, it requires a lot of data from the phone's NAND) and running the exploit from there instead of CWM.

Problem is finding this "someone". :D
[HTC Wildfire S] :
OK, I got those web addresses that Antagonist42 was talking about. This is in his own words:

I got it off him.
[HTC Wildfire S] no.human.being:
Yeah. And this is a datasheet of a processor that's as close to ours as it gets. It's from the ARM 1136JS. The MSM7227 is basically a replica of the ARM 1136EJS. Didn't find datasheets for that one, but as the model numbers are so close, there shouldn't be too much of a difference. Couldn't find out what's the exact difference though. The ...EJS seems largely undocumented. Most of ARM's web presence only deals with the ...JS.
[HTC Wildfire S] Antagonist42:
Kinda right, had a look at the MSM7227 Boot Process doc

ARM1136JF-S 600MHz (app arm) - http:// infocenter.arm. com/help/topic/ com.arm.doc.ddi0211k/ DDI0211K_arm1136_r1p5_trm.pdf

ARM926EJ-F 400MHz (modem arm) - http:// infocenter.arm. com/help/topic/ com.arm.doc.ddi0198e/ DDI0198E_arm926ejs_r0p5_trm.pdf

QDSP5000 320MHz (apps)

QDSP4000 122.88MHz (modem)

shame there's not more written in English but the most important stuff I'm sure you understand :D ;)

WW docin com / p-244286234 . html

remove spaces for links
[HTC Wildfire S] :
All I can suggest is to contact them.

Sent from a Time Lord, using his TARDIS.
[HTC Wildfire S] Antagonist42:
Updating NAND Possible Danger Q-fuses

Firstly I must admit I don't know all the ins and outs of reading and writing to NAND chips, just very basically how it's done, Q-Fuses no idea except once they're bown you can't revert it, so with this in mind and what I've read through on the Data Sheets the Q-Fuses on the MSM7227:-

1. PRI_HW_KEY (128 bits + FEC) - contains primary hardware key value that can be programmed after packing. Once this chain is programmed its contents must be protected from observation or modification, so a CONFIG chain fuse is provided to disable JTAG access to it. Secure software may read it's value by accessing the SMC memory map.

2. SEC_HW_KEY (same as Primary) - contains the secondary hardware key (all #1. comments apply).

3. BOOT_ROM_PATCH (2256 bits) - contains Boot ROM Patch information that is programmed and tested before packaging. Once this chain is programmed it's contents must be protected from observation ormodification, so a CONFIG chain fuse is provided to disable JTAG access to it. There is no direct software access, but secure software may indirectly access its contents by reading the Boot ROM content.

4. CONFIG (143 bits + FEC) - contains miscellaneous configuration information that can be programmed after packaging. Additional programming by handset designers (or their production staff) is allowed, if they weren't already blown by Qualcomm. A fuse value of 1 means it has been blown.

Blowing more fuses makes it more secure, there is no DEBUG_ENABLE, CONFIG has shadow registers for fuse sense operations and latching is done in security mode control block.

If n.h.b. knows if you can get around that to re-flash then all is good, if not then I think it may be gain access through creating our own EUU/RUU/etc on the back of official updaters, I think that is why my recovery was overwritten as ran malez after starting then pausing/stalling official EUU to gain access.

So would I be right in thinking that trying to erase NAND and flash could be making it harder to get through the security or is the area we are trying to flash not connected with this? :confused:
[HTC Wildfire S] SeeKai:
You'd propably NEED to erase/write NAND in order to get a new hboot in place. The quirk is in getting the permission from the hw to do it, either friendly by providing the right credentials or (if possible) to bypass it completely. Dunno if that can be done when UART access is available. Unfortunately that's not in my area of expertise. (WAY out of my league)

If you intervene in the RUU process you still need to know where to look to read the credentials in order to copy them. And you might need UART just for that!

Ask PabloPL if he is in for it and gather funding for a hack-device?
[HTC Wildfire S] theq86:
We can not use the RUU for that. The RUU is just uploading the files to be upgraded and the bootloader takes care of the flashing. So the RUU is not directly modifying the firmware. If it was so, I guess we would have cracked the **** some time ago.
[HTC Wildfire S] seaskyways:
Actuallly , yes , I have been looking in the RUU files , it contained fastboot , adb , lots of txt files , and most importantly rom.zip , which contained whatever needed for flashing , so probably it does the following when pressing the final next :

fastboot oem rebootRUU

which will reboot the phone into the RUU mode with the black screen and white htc then sends the file and flashes it through the bootloader via :

fastboot flash zip rom.zip

well , I wanted to ask in this case , the RUU flashes many stuff in a time , well , maybe if possible after sending the signature , we can modify the rom.zip hboot.img while the RUU is sending the thing , or by modifing the command line of the RUU that it waits a certain amount of time good enough for exchanging the images before sending the files ... so what do you say guys ??

EDIT : to find the files contained in the RUU all you have to do is run it , press on the view readme , if you have office word you can simply press on the open file location button in the File tab or menu , and with notepad you can press the save as button or any other to copy the directory then open this file WHILE THE RUU IS OPEN , there you can find the rom.zip , fastboot , adb , etc ...
[HTC Wildfire S] mhrsolanki2020:
i quite agree with you .. :D :D that might be possible but then if you change the ruu's content wont it be as good as unziping the contents of a signed zip and then reziping it ?? means you will have to re sign the ruu and if the signing is not apropriate (idk if signing of an .exe file is in our(refferd to nhb cuz m a total noob in this as i only read over here and try things and dash to the dead ends of faliure) expertise ) the ruu mode on cell wont accept the installation ..
[HTC Wildfire S] :
I've mention the rebootRUU thing earlier. Has anyone experimented with tty? Very useful, in some cases.
[HTC Wildfire S] theq86:
No guys, that won't work. See, this is how it works:

RUU uploads rom.zip to the phone.

then the hboot (in RUU mode respectively) verifies the signatur and flashes the rom.zip like a PG76IMG.zip.

Changing the rom.zip will not work. Either you screw the signature by changing the rom.zip, or it is too late to upload it.

The ruu mode does only give progress information back to the ruu. all checks are made by the phone.
[HTC Wildfire S] :
So, NHB, what are your latest attempts?
[HTC Wildfire S] :
Also, when you were compiling the kernel, what were you using as a base?

Sent from a Time Lord, using his TARDIS.
[HTC Wildfire S] Antagonist42:
RUU and updating

Agreed, using the RUU to update may not work but if an RUU is used to open up the signatures to be able to write then you can update what we would need to under their signatures, if this wasn't the case then I have no way of explaining how I cannot manage to flash anything using adb/fastboot except to UserData which you can do through PC, tried to install malez through PC and nothing, ran EUU, let it get as far as the EUU running CheckHTC.exe and stopping after that, ran the malez and installed it:confused:

Fair enough it locked the phone up but if, as with the EUU, we're trying to flash anything in but don't turn off AMSS (as CheckHTC.exe does) we wouldn't be able to write anything in or the EUU wouldn't update and we would I'm sure have found a location to do with security from the update files. If as nhb said the modem chip and app chip run in tandem then they have to be verifying each other making them secure, turn one off and you can write in what you need without any verifying from the other (best way I can explain it).
[HTC Wildfire S] ratafak_plachta:
SeeKai, what are the outcomes when using -N but not -u flags for flash_erase?
[HTC Wildfire S] hahahafr:
http://www.tomshardware.com/news/linux-linus-torvalds-kernel-3.3,15048.html

Is this worth a retry with a 3.3 linux kernel?
[HTC Wildfire S] :
You know, at school we had to do a role models assembly. My role model was Linus Torvald. When his picture came up, everyone was like, who is that! And I was like "Little f**uckers". LOL. So, how far have we gotten?

Sent from a Time Lord, using his TARDIS.
[HTC Wildfire S] no.human.being:
Yes I think it's worth a try. This one made me laugh:

Yeah, more than 3.8 TB of memory on ARM! Finally I can hook my monster RAID array to my smartphone and not suffer from storage limitation. :D
[HTC Wildfire S] BeciMester:
Probably that's why none of the links work... Try reuploading them, I'd like to have a read.

EDIT: Works perfectly now, thanks! :)
[HTC Wildfire S] SeeKai:
Same difference I'm afraid...

./mtdutils/flash_erase -N /dev/mtd/mtd7 0 0
Erasing 256 Kibyte @ 0 -- 0 % complete libmtd: error!: MEMERASE64 ioctl failed for eraseblock 0 (mtd7)
error 5 (Input/output error)
flash_erase: error!: /dev/mtd/mtd7: MTD Erase failure
error 5 (Input/output error)
Erasing 256 Kibyte @ 40000 -- 50 % complete libmtd: error!: MEMERASE64 ioctl failed for eraseblock 1 (mtd7)
error 5 (Input/output error)
flash_erase: error!: /dev/mtd/mtd7: MTD Erase failure
error 5 (Input/output error)
Erasing 256 Kibyte @ 40000 -- 100 % complete

FYI

./mtdutils/flash_erase --help
Usage: flash_erase [options] MTD_DEVICE <start offset> <block count>
Erase blocks of the specified MTD device.
Specify a count of 0 to erase to end of device.

-j, --jffs2 format the device for jffs2
-N, --noskipbad don't skip bad blocks
-u, --unlock unlock sectors before erasing
-q, --quiet do not display progress messages
--silent same as --quiet
--help display this help and exit
--version output version information and exit
[HTC Wildfire S] pihug12:
I don't know if it's useful but eoghan2t7 just posts his kernel : https://github.com/eoghan2t9/HTC-Wildfire-S-Kernel

The functions in /drivers/mtd/devices/msm_nand.c seem interesting but I think you already know these.

static int
msm_nand_read_oob(struct mtd_info *mtd, loff_t from, struct mtd_oob_ops *ops) {
}

static int
msm_nand_read(struct mtd_info *mtd, loff_t from, size_t len, size_t *retlen, u_char *buf) {
}

static int
msm_nand_write_oob(struct mtd_info *mtd, loff_t to, struct mtd_oob_ops *ops) {
}

static int
msm_nand_write(struct mtd_info *mtd, loff_t to, size_t len, size_t *retlen, const u_char *buf) {
}

static int
msm_nand_erase(struct mtd_info *mtd, struct erase_info *instr) {
}

static int
msm_nand_block_isbad(struct mtd_info *mtd, loff_t ofs) {
}

static int
msm_nand_block_markbad(struct mtd_info *mtd, loff_t ofs) {
}

static int msm_nand_suspend(struct mtd_info *mtd) {
}

static void msm_nand_resume(struct mtd_info *mtd) {
}

static int param_get_vendor_name(char *buffer, struct kernel_param *kp) {
}

static int param_get_nand_info(char *buffer, struct kernel_param *kp) {
}

static int param_get_page_size(char *buffer, struct kernel_param *kp) {
}

int msm_nand_scan(struct mtd_info *mtd, int maxchips) {
}

void msm_nand_release(struct mtd_info *mtd) {
}
[HTC Wildfire S] :
LOL. You see, that's the problem with people. They're not technical. If they did know about tech, they'd think this is the most funniest joke ever!

Anyway, how's the stuff with the kernel, or whatever you're doing. Are you trying to write the mtdblock drivers?
[HTC Wildfire S] pther:
mtd in kernel

Hi Guys,

Long time lurker here, and very interested in getting a S-Off WFS.

Haven't posted much, and probably won't in the future, but might give some insight in the kernel:

I think what you are looking for is in the kernel sources in /drivers/mtd/mtdoops.c

it has a function mtdoops_workfunc_erase that does the actual work of checking for bad blocks before erasing.

As expected, it does not actually erase when there is a bad block:

static void mtdoops_workfunc_erase(struct work_struct *work)
{
struct mtdoops_context *cxt =
container_of(work, struct mtdoops_context, work_erase);
struct mtd_info *mtd = cxt->mtd;
int i = 0, j, ret, mod;

/* We were unregistered */
if (!mtd)
return;

mod = (cxt->nextpage * record_size) % mtd->erasesize;
if (mod != 0) {
cxt->nextpage = cxt->nextpage + ((mtd->erasesize - mod) / record_size);
if (cxt->nextpage >= cxt->oops_pages)
cxt->nextpage = 0;
}

while (mtd->block_isbad) {
ret = mtd->block_isbad(mtd, cxt->nextpage * record_size);
if (!ret)
break;
if (ret < 0) {
printk(KERN_ERR "mtdoops: block_isbad failed, aborting\n");
return;
}
badblock:
printk(KERN_WARNING "mtdoops: bad block at %08lx\n",
cxt->nextpage * record_size);
i++;
cxt->nextpage = cxt->nextpage + (mtd->erasesize / record_size);
if (cxt->nextpage >= cxt->oops_pages)
cxt->nextpage = 0;
if (i == cxt->oops_pages / (mtd->erasesize / record_size)) {
printk(KERN_ERR "mtdoops: all blocks bad!\n");
return;
}
}

for (j = 0, ret = -1; (j < 3) && (ret < 0); j++)
ret = mtdoops_erase_block(cxt, cxt->nextpage * record_size);

if (ret >= 0) {
printk(KERN_DEBUG "mtdoops: ready %d, %d\n",
cxt->nextpage, cxt->nextcount);
return;
}

if (mtd->block_markbad && ret == -EIO) {
ret = mtd->block_markbad(mtd, cxt->nextpage * record_size);
if (ret < 0) {
printk(KERN_ERR "mtdoops: block_markbad failed, aborting\n");
return;
}
}
goto badblock;
}

As far as i can see this is the only place where this check is in place and i think patching it should do the job. This is also the actual code called by the mtdutils.

Unfortunately i don't have the toolchain lying around to compile and verify it.
[HTC Wildfire S] theq86:
no problem, nhb has a toolchain and already compiled a custom mtdtools version. maybe changing the code and recompiling it solves our problem.
[HTC Wildfire S] no.human.being:
Yep, I'm having CodeSourcery toolchain set up. However, remember that so far we have never got a "custom" kernel running on the device. I'll check out egohan's kernel sources though.
[HTC Wildfire S] seaskyways:
what do you call the CWM kernel ? or m1ndh4x8r's or eoghan's kernels ?? aren't these custom ?? sorry for the noobiness cuz i am not that much in kernels , just basic things ...
[HTC Wildfire S] no.human.being:
What I mean is that, until now, we haven't got a single kernel running that was specifically built from source for the purpose of S-OFFing the WFS, even though we tried that a lot some time ago. All the kernels we got running so far were "compiled by a third party" for a different purpose (e. g. for use in a ROM) and only provided to us as a binary. This includes things like the CWM kernel, the CM7.2 kernel by Alquez, etc.
[HTC Wildfire S] munjeni:
Guys sorry but I want to ask you. Whats going in this thread? You looking for kernel driver that will be ussed to erase/write to nand protected parts of memory? If yes please give me progress of your development... I working with that for a long time but without success :(... Did you menaged to write to protected area?

Another question:

Anyone have source of the ./inject --disengage-the-safety program? Or it is closed source? Is this is used to patch spl or it is used to call mtdutils tools?

And last question is for no.human.being... I realy not understand how you managed to get write enable flag to protected area + how you got nand_write and flash_erase working with protected areas... I realy need info (at least by pm) and realy want to help aria/wildwire/htc_hd_mini users to get custom nand tools... If you seen my posts in aria forum, I doing this by jtag and I have runing windowsCe rom in native android phone htc aria :), but I no want to use jtag, I want to use software, but its not possible in this time :(, so I realy need help to get it possible! And I will publish it "opened" if you have info or at least source for "inject"...

I have some works on msm_nand.c but have no luck to disable protection on protected areas! If you want to see what I have done and what I tried, here is my nand driver -> http://paste.ubuntu.com/904018/ look in function msm_nand_block_isbad, there I tried to overwrite spl but without luck, look in full_nand_partition_info for how I loaded hboot partition and how I managed/increased system partition using that kernel booth for recovery and android... I have apsolutely no way to erase/write to protected area... but I want to help htc hd mini users to give him way to install aria flash to his phone, I allready created hspl (tested and fully working) but I have no way to overwrite spl with hspl using software tools... waiting your help, thanks!

---------- Post added at 04:07 PM ---------- Previous post was at 03:48 PM ----------

I forgot to say:

I found nand driver from codeaurora and interested thing is that there is some "hidden" definitions in nand header that not exist in "standard" msm_nand driver -> http://paste.ubuntu.com/904026/ so maybe we will get something from that? I think key is in cfg0 and cfg1 !!!