|
| There is an object store and filesystem in ram. It's a volume that mounted as root. I can open it via "\\VOL:". But, unlike other volumes, it can't be read via DISK_IOCTL_READ. It returns error 0xB7. Though it returns a correct info for DISK_IOCTL_GETINFO and DISK_IOCTL_GETNAME.
I thought that if i will dump the physical memory, then there will be a RAM file system. I did so, there a files, but the file data in ram is scrambled. I can't find where the filesystem starts and don't know how to parse it. Couldn't even find which filesystem is used to store data in RAM. |
|
| |
|
H/PC Sensei Posts: | 1,330 |
Location: | North of England | Status: | |
| You're deep into the internals of WinCE here. I suggest you have a very good look at all the stuff available on xda-developers.com, particularly in the wikis and by following the links in the wikis to the various tools available, some of which include source.
Please do report back with what you find. |
|
| |
|
Administrator H/PC Oracle Posts: | 18,011 |
Location: | United Kingdom | Status: | |
| Hexxx, you have possibly come a-cropper of the XIP compression, you have literally performed a binary dump of the ROM into RAM, and the data is corrupted because it is still compressed. You need to work-out the header offset and decompress it, or may be execute and clone?
Please do let us know what you find. |
|
| |
|
H/PC Oracle Posts: | 16,175 |
Location: | Budapest, Hungary | Status: | |
| i've never seen any info of the file system of ramdisk on xda dev.. i see he already used those tools to dump the RAM. all i noticed (it was never my goal to decrypt the ram filesystem ) is that this isn't an ordinary filesystem, it compresses the data you put into it. so you can put a lot more data in it than you'd think. 
C:Amie and Hexxx: maybe i'm lost, where is this about rom ? i can try to help if this is about dumping / extracting the ROM. |
|
| |
|
| At last somebody replies. I've asked that question at many forums including XDA. XDA is silent, nobody even interested in the things i say. This doesn't matter.
Here's what i see in the dump:
00085BF0 07004B09 004B0900 004D5A90 00030000 ..K..K...MZ.....
00085C00 00D20452 00FFFF21 B8920001 FD014052 ...R...!......@R
00085C10 01010101 0101FF01 01010101 01010117 ................
00085C20 010101E8 92030E1F BA000E00 B409CD21 ...............!
00085C30 B801024C 31546869 73207000 726F6772 ...L1This p.rogr
00085C40 616D2063 00616E6E 6F742062 65402072 am c.annot be@ r
00085C50 756E2069 1144004F 53206D6F 64652E10 un i.D.OS mode..
The string "This programm cannot be run in DOS mode" contains additional zeros. That's my exe file that i've uploaded to device. It's in the dump. It's not XIP. I've detected the approximate end of my file in the dump. It appears to be about 3 time smaller than real one. The file is really compressed.
The problem of decompression is not so important for now. At first i need to know how to find the files in dump. I had to do rather weird things to find my file in the ram dump. There must be some strict way to find them. |
|
| |
|
H/PC Sensei Posts: | 1,330 |
Location: | North of England | Status: | |
| From googling around on MSDN, I really can't see any decent documentation of how the object store works at an implementation level. I'd be tempted to look at source within Platform Builder to see if an implementation of the object store is there, and "forward engineer" the format from there. Or you never know, some structures and header files might help it to make sense?
I don't have PB on me right now, but you should be able to find a download for an evaluation version of PB4.x if you don't already have it? |
|
| |
|
H/PC Oracle Posts: | 16,175 |
Location: | Budapest, Hungary | Status: | |
| i would experiment with my own files in ram to find out the structure. i can send you the online installer for PB 4.2 eval which is good for 120 days of experimenting. |
|
| |
|
H/PC Sensei Posts: | 1,330 |
Location: | North of England | Status: | |
| Quote i would experiment with my own files in ram to find out the structure.
If I understand it correctly, hexxx has done that and can't explain the spurious extra characters, or apparent lack of size of the file. But starting with small files and working up might be a good way to hack at it as you say  |
|
| |
|
H/PC Oracle Posts: | 16,175 |
Location: | Budapest, Hungary | Status: | |
| yes i meant i would experiment with a lot of files in a systematic way.
btw, lack of file size? either a very good compression or that reminds me of roms, there parts of files often aren't in the same place. Edited by cmonex 2006-11-30 8:45 AM
|
|
| |
|
| After the MZ and PE headers there are usually a set of zeros in the exe files. Look, how they compressed that:
00085DA0 2E727372 63122544 17FB1217 84211867 .rsrc.%D.....!.g
00085DB0 24010101 4325FF92 27010101 01010101 $...C%..'.......
00085DC0 FF010101 01010101 01FF0101 01010101 ................
00085DD0 0101FF01 01010101 010101FF 01010101 ................
00085DE0 01010101 FF010101 01010101 01FF0101 ................
00085DF0 01010101 0101FF01 01010101 010101FF ................
00085E00 01010101 01010101 FF010101 01010101 ................
00085E10 01FF0101 01010101 0101FF01 01010101 ................
00085E20 010101FF 01010101 01010101 FF010101 ................
00085E30 01010101 01FF0101 01010101 0101FF01 ................
00085E40 01010101 010101FF 01010101 01010101 ................
00085E50 FF010101 01010101 01FF0101 01010101 ................
00085E60 0101FF01 01010101 010101FF 01010101 ................
00085E70 01010101 FF010101 01010101 01FF0101 ................
00085E80 01010101 01017F01 01010101 01010084 ................
00085E90 00000115 DE334303 004A0292 0020D200 .....3C..J... ..
At 00085E90 the code section started. It looks like RLE. |
|
| |
|
| By the way they compress data to the blocks of 8-bytes each. |
|
| |
|
Administrator H/PC Oracle Posts: | 18,011 |
Location: | United Kingdom | Status: | |
| The object store and it's compression system are Kernel services (NK compression), it'll be rather entertianing trying to engineer that in any direction - the source isn't provided for the kernel, it comes pre-wrapped as intermediaries. The compression ratio for the OS should be around 2:1, how big was your source file Hexxx?
The object store is Windows CE's own filesystem, it's database driven.
I want to reaffirm here: You are trying to dump the Object Store, NOT the execution memory, and NOT the ROM region?
If so, do ignore what I said about XIP compression, it is still compressed though: heaven knows what algorithm it uses to do it though.
What is you aim with this project; if you have one? |
|
| |
|
| The aim is to restore the erased files.
The ram filesystem can contain the erased files just like FAT on SD.
That's why i need the image of the file system, not only the existing files in ram.
I'll check if it's database driven. But i don't think that they will use the database to store the files.
The real file size is 4.5 kb, the compressed size is 2.5 kb the ratio is like xip. I'll try to decompress using xip algorithm. I'll try the code found in romdump util. |
|
| |
|
| Yes! It's a XIP compression. Managed to decompress first 0x400 bytes of the file. Though some bytes are different in the unpacked and the original file... I've got to find why it's so... |
|
| |
|
| It've decompressed only 0x400 bytes because memory page has ended. Though i have all physical pages in the dump, wince interacts with the virtual pages. And it's an additional difficulty to find the next memory page, where the file continues |
|
| |
