Related
hello..
is there a chance to do it ?
writting the nb1 file to SD card directly from the PPC device its self without need to buy a card writer/reader ?
why not ? out PPC can write & read the card, so any chance to do it ?
best regards
Yes, this possibility exists. Nobody has written code to do it though.
We're toying woth the idea of a whole new tool which allows many more operations directly to the device. If only we could find either a lot of time, or some sharp volunteer coders with too little on their hands...
yes, it is possible. just didn't have the time to write a program to do it yet.
I did write some test code, to see how it works
source + exe here
btw, warning - the write function will erase what ever was on your sdcard.
hello again..
well thank u all XDA developers, i wanna know is it just a raw writting of nb0 & nb1 on SD card starting from block 0 to the end of nb1 ?
best regards
for 5.14, 5.15, 5.22 the first sector contains a string specifying the cardtype:
"HTC$WALLABY00" - bootloader ( nb0 )
"HTC$WALLABY11" - wince image (nb1)
"HTC$WALLABY22" - bootloader(nb0) + wince image(nb1)
"HTC$WALLABY33" - diagnostics card(nb2)
"HTC$WALLABY44" - gsm
"HTC$WALLABY55" - gsm + wince image
starting at the 2nd sector, the data is written.
these last 2 we have not experimented with yet.
for 5.17 the layout is a bit different, the first sectory contains the string 'HTC FLASH KEY', the 2nd sector starts with the md5sum of the cardid, the 3rd sector has a 4 byte counter value, the 4th the md5sum of this counter, the 5th contains 'N'
starting at the 6th the about HTC$WALLABY string + bootloader/wince images are written.
a bootloader is always 512 512byte blocks or 256k
a os image is always 65024 blocks, or 31.75M
see xdarit source for more details
thanx alot XDA developer
my WALLABY boot loader is v5.15
I'm on my way to write xdirt for PPC, many thanx for ur information.
best regards
Hi...
Can't wait to get my hands on your code...hoping it works with 5.17.
Is the idea behind your program to prepare the SD card with the .NB0 / .NB1 files so we can upgrade our PPC's to 2003 through an ActiveSync connection?...yes, I'm a complete novice at this...sorry
G
Hi!
So what it's all about?
There are so many projects dedicated to porting linux to WM devices.
Mostly the only way to boot into linux and kick windows mobile out of RAM is the haret tool.
For thoose who never heard of it is a linux bootloader (it is even more), that is started from within windows mobile.
This is the result of the fact that the native bootcode of the device could not easily be replaced.
Apart from that, there are to many things to consider to rewrite own bootcode for a closed device.
So what if the native bootcode "thinks" it boots in windows mobile again, but it in fact jumps into linux kernel code?
Whaaat, you might think and i thought a lot of it in the last few weeks:
The idea is, to embed a linux kernel in a XIP container and boot it with the native bootloader
So that's crazy stuff and it's even more crazy, that some insane hackers already did some successful attempts.
The project aims to port Android to a device called Meizu M8.
Step into this thread and start reading:
http://www.meizume.com/modding-development/9014-project-port-android-meizu-m8-18.html
One of the developers already has started to push some GIT-repos of the toolset here:
http://gitorious.com/~banxian
Of course there's a lot to investigate and other things to consider:
1. The injected code must be in good shape (kernel needs excellent hardware support)
2. The device will need to be hard-SPLed (no security check)
3. The files must match the Flash layout of the bootcode
4. JTAG support for the device would be mandatory for testing
5. Lots of information about internal Flash structure is required
....
Please tell me what you think about it!
Cheers,
scholbert
That's an excellent idea!
Multiboot would seem to be a better (albeit more complicated) alternative to me though... In their current stage, Linux ports to WM devices tend to be unstable and rather limited in functionality. Replacing a fully functional WM with a semi-functional Android on one's primary device is not as tempting as having both at the same time.
I'd say the first step in this direction is bootstrapping custom XIP from RAM with a patched SPL. Flashing XIP nbX every time custom XIP is patched is slow and tedious. Once a working XIP with booting Linux kernel is available, it should be relatively easy to switch SPL back to normal booting from NAND. Also ULDR XIP can be used as a container for the custom XIP rather than the WM kernel XIP. This way one can boot WM by default and then reboot to ULDR/Linux if required (not quite multiboot, but something close).
The caveat here is that when HaRet is used to boot Linux kernel from under WM, some hardware init could have been carried out by WM kernel at boot time. When WM kernel/XIP was never ran, there's a good chance some of the hardware that works when booting Linux via HaRet won't work anymore Completely bypassing WM kernel initialization means more initialization may have to be done in Linux kernel/custom XIP.
The progress that Meizu people made is certainly impressive, but there's a long way from a 100-byte piece of code that fills the framebuffer to a fully working Linux kernel. I'm not being sceptical here, on contrary I'm pretty sure this is possible, but it will take a lot of time and dedication to make this happen. At any rate, good luck and I'm sure you'll find plenty of support here.
This project, is cool, i am waiting any progress, i want put the android in the MS20(Brazillian KS20 without wifi and 3G)
Hi again,
thanks for the feedback so far
@ stepw:
I really share your thoughts concerning long and dusty road of development.
So perhaps i was in kind of euphoria when i decided to post it yesterday.
Anyway, let's see what the future will bring us
Maybe we should start with some kind of ramloader and place it in XIP area.
BTW, could you be more specific about this ULDR XIP thing?
Sounds interesting and to be honest, never heard of it...
Please consider the thread as a starting point for an open discussion.
Anyway, i will need help, because i'm a horrible hacker.
So maybe i should have written IDEA not PRJ
Have a nice day!
scholbert
As per http://channel9.msdn.com/wiki/CEDeveloper/BSP/
ULDR and IPL
For BSPs that are for Windows Mobile products, the ULDR and IPL are required parts of the BSP.
“ULDR” stands for “Update Loader”, and is part of the Image Update system. This system allows deployed devices to be updated with new software after they ship. The Update Loader reads a configuration stored in persistent memory and downloads and installs new versions of operating system or OEM files.
“IPL” stands for “Initial Program Loader”. This piece of code is launched by the bootloader or executed directly at startup if a bootloader has been removed from a board. The sole job of this program is to choose whether to execute the ULDR software, or load and execute the operating system that is currently on the device. If a user has downloaded new versions of operating system or OEM files, the IPL will be configured to launch the ULDR. Otherwise, it will load and launch the OS.
===
Da_G's thread http://forum.xda-developers.com/showthread.php?t=520009 has plenty of information about ULDR, although it's more about keeping it rather than about using it for something else.
Replacing ULDR is a valid way to inject another item into NAND partition table. Unfortunately with WM all 4 primary partitions are used in the MBR by default, so taking ULDR out allows for reuse of one of the parition slots for other purposes. IPL already has a way to bootstrap either ULDR or OEM XIP (WM kernel), it should be possible to control boot partition selection from each of the OSes. Manipulating partition type and flags should make it possible to choose the default OS too.
ULDR partition is typically fairly small, but it can be expanded to store Linux ramfs image or even the filesystem. Alternatively, FATFS partition in NAND could be mounted at boot and filesystem image could be located there. Yet another location for it is IMGFS partition, but that calls for a file system driver (read-only at least) that I don't think exists for Linux. Anyway, if at least FATFS can be mounted, access to all user files accessible from WM should also be possible from Linux/Android once it's booted.
Sorry for deviating from the original topic
Hey stepw!
Sorry for deviating from the original topic
Click to expand...
Click to collapse
Hey we got an open discussion here...
Thanks for all this useful information so far!!
I knew about starting up WM platform and i also looked deeper into IPL and stuff. What i am missing a little is just these information about XIP and WM image in general.
So i think i'll first step through Da_G'S thread, it looks very promising. Great stuff!
Again leave your technical comments here, because i think it's the only way to get best solution
Best regards,
scholbert
Hi,
I've been working on this for a few days now and have a simple bootloader that loads and runs a kernel on my vogue. Unfortunately the kernel doesn't boot properly because it can't initialise all the hardware correctly but it definitely runs. Attached is my code and a script to insert it into an xip payload with a kernel.
Woooow.....
Hey dzo,
this is a real breakthrough or whatever you may call it.
Really great stuff!
Maybe this won't reach peoples interest right now,
but let me forecast, that someday this will give us the opportunity
to wipe out windows mobile completely if we like to
Anyway i think it would be nice to get some stuff pointed out more clearly.
So let me sum up:
1. Let's assume we got excellent kernel zImage to support the hardware of our device.
We will need to initialize even parts of hardware in this kernel,
that we did not even know about, while testing with haret.
2. We need some hard-SPL bootcode on our device, because we need to avoid security check of the image.
3. We got WM ROM for our device and we got some kitchen to extract it and work with it.
The starting point will be the file OS.nb.payload, because this is pure binary.
(the image like it is stored in NAND flash memory).
The image (OS.nb.payload) itself is organized in different parts and partitions.
At the moment we don't care much about it, because we leave it mainly untouched.
We need to find the entry point from the WM kernel, which is pure XIP code (XIP.bin).
4. We inject a tiny loader for elf binaries at this point, which is also compiled as XIP code (tinboot).
5. We step a bit further and place the kernel zImage (which is an elf file) at a certain offset.
At least this should be the address the tiny loader points at (e.g. offset + 0x8000).
6. We use some kitchen tools to reconstruct a flashable image.
7. We flash this image to our platform, using the same tools we use to flash a cooked ROM.
8. We boot into linux!
Please correct me if i forgot something or made a wrong assumption here.
Would be really nice to get some more hackers and ROM cookers over here to benefit the discussion.
Thanks again dzo!
Best regards,
scholbert
Hi again!
A little research at the forum gives some more details about OS.nb.payload:
http://forum.xda-developers.com/showthread.php?t=446506
This maybe all well known, but should help to point at it again for a better understanding.
So if we use mtty and type the info 8 command on HTC loaders this prints out these partitions (should be all the same on HTC devices):
Partition[0], type=0x20, start=..., total=... BOOT (ULDR)
Partition[1], type=0x23, start=..., total=... RAWFS (XIP)
Partition[2], type=0x25, start=..., total=... IMGFS (SYSTEM)
Partition[2], type=0x04, start=..., total=... FATFS
TBC
scholbert
dzo said:
Hi,
I've been working on this for a few days now and have a simple bootloader that loads and runs a kernel on my vogue. Unfortunately the kernel doesn't boot properly because it can't initialise all the hardware correctly but it definitely runs. Attached is my code and a script to insert it into an xip payload with a kernel.
Click to expand...
Click to collapse
That's some excellent progress! Did you build your kernel yourself too? Is it mission critical hardware that fails initalization or some minor stuff?
Where is the BIOS in this thing? I get that it has /boot /system and /recovery but where is the firmware that the device very first utilizes?
Does the streak even have any type of NVRAM memory?
webdawg said:
Where is the BIOS in this thing? I get that it has /boot /system and /recovery but where is the firmware that the device very first utilizes?
Does the streak even have any type of NVRAM memory?
Click to expand...
Click to collapse
What are you attempting to do?
Understanding and Hacking
I am trying to understand the device and search for potential exploit vectors. If I take out the inner SD card what type of data does the device still have on it?
It has to have something that starts the boot from the inner SD card. Does this something insert anything into the running code on the device? Can it?
Can, if the device has the type of storage I am talking about, the device record and store even a small amount of data?
I have heard of reference to NAND backups and even seen a quote about how the NAND backup util included in the recovery utils does not backup something. The something I am referring to is not the external SD card.
Web...
Strephon Alkhalikoi said:
What are you attempting to do?
Click to expand...
Click to collapse
Why would you need exploit vectors when the system is completely open/unprotected?
the innerSD holds the /data and /cache partitions
It is like I am not making myself clear enough. A computer has a BIOS which passes boot to the OS/bootloader. Would not the phone have the same thing. If you do not know this answer do not ask anymore questions.
Stop asking why I am asking.
TheManii said:
Why would you need exploit vectors when the system is completely open/unprotected?
the innerSD holds the /data and /cache partitions
Click to expand...
Click to collapse
webdawg said:
It is like I am not making myself clear enough. A computer has a BIOS which passes boot to the OS/bootloader. Would not the phone have the same thing. If you do not know this answer do not ask anymore questions.
Stop asking why I am asking.
Click to expand...
Click to collapse
Unfortunately for you it seems you don't know what you're doing or why you're even asking about it
Sent from my GT-I9100 using Tapatalk 2
Okay Then
cdzo72 said:
Unfortunately for you it seems you don't know what you're doing or why you're even asking about it
Sent from my GT-I9100 using Tapatalk 2
Click to expand...
Click to collapse
Please. Unless you have an answer please do not reply. I know exactly what I am talking about. If the device does not have any NVRAM in it that one could flash to and only internal memory via SD card then just say this.
webdawg said:
It is like I am not making myself clear enough. A computer has a BIOS which passes boot to the OS/bootloader. Would not the phone have the same thing. If you do not know this answer do not ask anymore questions.
Stop asking why I am asking.
Click to expand...
Click to collapse
Manii knows far more about the Streak than you do, so if you want your questions answered, I suggest you check that attitude of yours at the door.
Strephon Alkhalikoi said:
Manii knows far more about the Streak than you do, so if you want your questions answered, I suggest you check that attitude of yours at the door.
Click to expand...
Click to collapse
Your right. Did not realize it was him, work has an affect on my attention. Sorry Manni.
I am at home now. Let me try and expain myself.
I just do not get it. All the pages I have read and the research I have done everything tells me that everything is stored on the internal SD card.
But I still have this nagging thought from this page: http://www.rdtk.net/2011/06/25/using-streakmod-recovery/ that says this: the firmwares reside on the nand but in an entirely separate area. only stock recoverys can write to them under normal circumstances, you can probably read/write them manually but it’s dangerous as you can super-brick if you don’t know what you’re doing
What the hell is that guy talking about? The way I read it is that an entire subset of firmware exists on the device that only that one webpage has ever talked about. (That I have read)
I have read alot about BIOS hacks and how they function inserting code into Windows. Even legitimate code for paid services. Computrace.
I know about the Carrier IQ software. What I do not know about is the software outside the rom, recovery, boot partitions and such that exists on the Dell streak or any Android device.
I suppose my attitude comes from the ton of forum posts that I read with unanswered questions because people wanted to know why the OP is asking such a question.
I took Manii's post the wrong way because of your question Steven. Not to offend you and I understand why you ask. For example I just hate going into support channels and asking questions about an iptable rule and being told that I should relearn Linux networking because...well just because I did not understand one concept. I took it the same way here.
I apologize to all.
Web...
MTD based nands are more complicated then eMMC nands in this aspect, as MTD nands you simply cannot read from the 'hidden' portions of the nand. eMMC ones you can.
eMMC devices you can always read from any eMMC partition, so you can likely make complete backups including your modem (though no custom recovery does this by default, it's still a bad idea)
Fortunately for us, MTD seems to be 'obsolete', every device that launched with GB installed or newer uses eMMC.
Dell Streak 5/Partition layout - XDA wiki
Dell Streak Pro/Partition layout - XDA wiki
The S5 is a MTD device, the SPro is eMMC, note how the SPro has many more partitions.
The majority of them also exist on the S5, but the only way to access them (safely) is though a stock recovery.
You can write to them with fastboot, but some of them must be unpacked by an updater in the stock recovery. Simply flash them (specific ones) and you'll super-brick that would require JTAGging at a minimum to fix.
You simply cant read the other MTD partitions without JTAGing (it might be possible with a specificly modified kernal, but you dont gain anything doing this, if at all), assuming that the hidden parts are MTD partitions even. For all we know the controller could be directly writing onto NAND pages with their locs hardcoded (which would kinda be like partitioning, but without the formal partition tables(?) )
There's also is a small amount of memory that can only be written (afaik) via JTAG.
It contains your device's ID, such as Service tag and IMEI.
On tegra devices (at least the S7 and S10) it's the WP1 and WP2 partition.
It could be possible that it's on the NAND as a MTD partition, but if it is we dont know about it. It would be insane (and illegal, as changing your IMEI is illegal in most countries) to write to it, but so there's never been an example of it. I dont know where they are on the SPro, i'd need a live device to check.
The modem OS itself is stored on the nand, the modem processor knows (or the bootloader knows) how to feed it it's OS image.
Location breakdown:
NAND: <everything on the partition layout above, including the below>
/system
/firstboot
boot.img
recovery.img
amss.mbn
appsboot.mbn
dbl.mbn
dsp1.mbn
fsbl.mbn
osbl.mbn
DT.img
The innerSD
/data
/cache
Modem storage (lock state)
Device unique data (IMEI and Service tag)
RTC (the clock)
I dont know the exact terminology or the exact order of booting on qualcomm snapdragons (it's likely to be the same with all at least in the same generation)
But it's something like:
Press power button
CPU powers up
IPL loads <hardwired onto cpu>
Check if innerSD is valid (this is streak specific, device also locks up if it fails as the loader isnt robust enough to work around it)
Init modem and it's firmware <amss.mbn on older devices, non_hlos.bin on newer devices> (FYI modems are themselves complete 'system's in that they have their own ram and OS, basebands are complete OS images in most devices)
Check what button combos are pressed
Start booting:
If you pressed the recovery mode combo:
Load recovery SPL <dbl.mbn? + DT.img>
Display SPL menu:
Reboot
Load Recovery ("update from update.pkg")
Read from recovery.img and load it
Caliberate screen
If you pressed fastboot mode combo:
Load the fastboot loader <fsbl.mbn?>
If you pressed the download mode combo:
Go into download mode (for QDLtool)
If you did not press any combo: begin booting normally
Load dsp1.mbn
Load boot.bin
Linux kernal mounts and starts reading:
/system
/cache
/firstboot
/data
Android boots normally
Boot completes, you're at the lockscreen/home screen
I'm just making educated guesses at which *.mbn does what, as noone's really studied them to the point that they are willing to modify them.
Regardless they're signed so you cant modify them (we dont know per-se that the CPU checks the signatures on *.mbns, but I dont think any is willing to risk their device to try anyway)
The kernal images arnt signed, you can simply toss any kernal that is valid (otherwise it wouldnt boot)
When your device boots, the logo flashes 4 times:
1st logo: IPL and it's logo (possibly hardwired onto chip)
2nd logo: SPL and it's logo (stored in one of the *.mbns)
3rd logo: UBOOT and the kernal logo (stored with the kernal, sounds like a band name)
4th logo: bootimage.zip (whatever boot splash is with the installed rom
TheManii,
Thanks for the information. This is everything I wanted to know. If I have anymore questions I will ask later.
Web...
SOLVED the best way.. See post #5
Hello
I have asked this in other threads, but have not gotten an answer that I can manage to make work yet. I'm also hoping that this thread may help the many others out there with this same problem.
I have an Iconia A500 that has the bad sector problem. I cannot get it to format partitions through any of the EUU's out there,or even the Babsector .bat's . Same thing every time-read/write failure. I have seen mention in a thread or two about guys who have used the "rawdeviceread" and "rawdevicewrite" commands in NvFlash to "map out" any bad sectors on the EMMC chip, and create "dummy" partitions over them so that the tablet will function again, at least until more sectors die anyhow.
Can someone please explain this process, including describing the files needed, exact commands, and the rest of the process to make this happen? I have seen member "Yaworski" describe the basis of it, but again his commands are no-go for me. It would also be great if a partition could be created, but not formatted, completely bypassing any possibility of NvFlash failure.
Thanks in advance By helping me I'm sure you wil also help many others. It seems many a500's are starting to suffer form this same exact issue.
Anyone? I have read thru this post: http://forum.xda-developers.com/showthread.php?t=1691729&page=3 , and seen a couple recommendations to it in other threads, but no dice on making it work .. or even being able to map out the bad sector/s. I know this'lll fix me up at least temporarily...
I need help with this as well. There doesn't seem to be a step by step guide anywhere :\
Sent from my SGH-T769 using xda premium
dynospectrum said:
I need help with this as well. There doesn't seem to be a step by step guide anywhere :\
Sent from my SGH-T769 using xda premium
Click to expand...
Click to collapse
I've been asking around about a possible process of mapping out bad sectors, and not just members in here, but engineers and technicians I know as well. First, the NAND has this sort of embedded firmware that directs it to remap or bypass bad sectors “spontaneously,” if you can call it that. When you're stuck with “write errors” or where the NVflash even fails to create and format a partition, it suggests that this part of that firmware is not working. Why the loose fit, or lack thereof, I don't know.
Second, The FCK guys mention that you can write a dummy file and make the device read back so you can see where the data is missing and circumvent it altogether. But they also state that if Sector 0 – which NVFlash is slated to access – is kaputt, then it would hang, as probably in your case and certainly in mine.
Given that the Boot Configuration Table is 4Kb tiny while the NAND is 16Gb large, I can't imagine the latter being damaged so badly as not to have a continuous space of 4Kb to accommodate such partition. As a matter of fact, I did have someone with special equipment probe my NAND “physically” and the initial report indicated that the first half (50%) of it had less than 3% of its sectors that was bad. NVFlash, however, could neither create nor format, let alone write on it.
So, either one must have the appropriate hardware to do a very low level format to restore the NAND in full or in part, or NVFlash has to be hacked to command writing at a Sector different than 0. Until that happens, I doubt it that a step-by-step guide grounded in current programs would be viable.
I know that neither the custom ROMs nor the custom Bootloaders and Recoveries are remotely the cause, because this occurred way before any of it came onto the scene. But in light of the frequency at which this happens to some of us, it seems ironic to term this device bullet-proof. I'd like to think it's not incurable, but what the FCK do I know? (Sigh) Anyone with the essential hardware know-how to tackle this?
SOLVED..well the "easy" way....
I sourced out a broken A500(strangely the screen is fine though lol), re-soldered the power button on it(PITA), and put it into my A500.
I plan on taking it easy with the flashing on this one. A500s seem to have a growing history of EEMC chip failure from over-flashing. My old board had been flashed MANY times by the previous owner, and a few by me before it died. The "new" tab was only flashed enough to get it to Stock ICS. Now it has the V8 bootloader and Civato's Re-Flexx ROM(Best out there IMHO).
So there you have it.. this seems to be the best way to fix this problem on the A500---Replace the Darn motherboard. I'd imagine mapping/skipping sectors is only a temporary fix that will probably lead to the tablet dying when its needed most.
Hello all..
i have a serious problem with a industrial knitting machine. This machine works on a Windows CE 3.00 platform that for it's own turn, is compiled on a 16MB DiskOnChip. Unfortunatly. This DiskOnChip (from MSystems) has a damaged boot (or so it seems).. and no longer boots the machine. We actually don't know if it is the boot... but sure it seems so.
So.. what is the problem.. you may say? Well.. the Italian knitting machine's manufacturer has gone bankrupt... and the machine no longer has support. We have no software for it or Operating System for it! Also.. the MSystems is no longer available... and although it has been acquired by sandisk, sandisk does not give support has well on data retrieval.
All we have is a raw flash dump that we made on the diskonchip's Samsung k9f2808u0b NAND IC. This is based on TFFS .. but although i have read almost everything that there is on the web about this (including XDA) i seem to be unable to extract the internal NAND image files. I have used, RvSkills, NAND extractor, etc... without success..
When we open the raw dump with a hex editor... the data seems to be there... but i don't seem to be able to retrieve the file structure. We really need this machine working.. and this is our only solution.. any help would be highly appreciated.
Any XDA's Diskonchip Wizard reading this post or any WinCE Master over here that can help us? We really don't know what else can we do to retrieve the data from the NAND RAW dump.