Hi,
Does anyone have any information regarding the vol file formats (primarily 3.x but any v will do as a start)? I'd like to be able to read from them programatically.
Ta
file .vol should be database.
use EDB API funtions to open and read values inside.
ps: EDB for WM5, CEDB for WM2003
i hope this help you
bye
Related
Hello.
History:
My Qtek9090 running WM5 has good CPU, fast graphics and very, very slow filesystem. I'm looking for something, may be for fatfsd.dll extracted from another PDA. And I cann't find it
There exists very handy utility WM5 Files Dumper [thanks buzz_lightyear ]
I think it is a good idea to upload dumps of all files from our PDA's. It would be a good source of information and source of code bricks to cook patches and updates.
Such a dump should contains all files and modules [extracted both from bootloader and OS] and full dump of registry. It should be as clean as possible - just after hard reset, before entering PIN, before adding any contacts and any patches.
Tommorow I will try to upload WM_5_03_02_WWE_built_1337_42_BlueAngel_by_mamaich.zip.
And again - thanks to our master hackers
I'm looking for something, may be for fatfsd.dll extracted from another PDA. And I cann't find it
Click to expand...
Click to collapse
And even if you'll find it - it would not work on your device. It is always XIP.
And it would not speedup your device - it has a slow ROM.
mamaich said:
/me said:
]I'm looking for something, may be for fatfsd.dll extracted from another PDA. And I cann't find it
Click to expand...
Click to collapse
And even if you'll find it - it would not work on your device. It is always XIP.
Click to expand...
Click to collapse
Probably you are right I'm a lame, but I afraid, that it is true.
But: as I understand: XIP means "eXecute In Place". Dll's as modules are executed from slow ROM [and there is no shadow RAM] [and there is no way to cache them]. Dll's as files are loaded into RAM, and then executed. Correct me, if its not true.
We have plenty of RAM, so [probably] it is possible to load a lot of dll's into RAM instead executing them from [slow] ROM.
Dlls created with "WM5 Files Dumper" - looks good. I would have to analyze them several times, I would have to ask master hackers is it true, but I would try to load them into RAM.
mamaich said:
/me said:
I'm looking for something, may be for fatfsd.dll extracted from another PDA. And I cann't find it
Click to expand...
Click to collapse
And it would not speedup your device - it has a slow ROM.
Click to expand...
Click to collapse
Yes, of course.
But SPB benchmark told me:
Reading files from \somewhere is 4 times slower then WM2003. It is a good value.
Write files into \somewhere is 6 times slower then WM2003. It is also a good value.
But:
Copy files [OS level] is two times faster than read them and write back. It is not good value.
Retrieve filenames from huge directory is 10-12 times slower, than WM2003. It is also not a good value [it should be comparable to reading files, ie. 4 time slower]
There are two ways:
1. there is something wrong within fatfsd.dll,
2. overhead of executing fatfsd in place is not acceptable,
3. my benchmarks are wrong [I have not enough time to benchmark filesystem without cache
/me said:
Tommorow I will try to upload WM_5_03_02_WWE_built_1337_42_BlueAngel_by_mamaich.zip.
Click to expand...
Click to collapse
It is here: ftp://xda:[email protected]_WWE_built_1337_42_BlueAngel_by_mamaich.zip
If you think it is a good idea to share WM5 code bricks, upload your your clean dump into
ftp://xda:[email protected]/Uploads/RomFiles_dumps
UserName and Password is here: http://wiki.xda-developers.com/index.php?pagename=BA_FTP_Site search for "xdaupload".
baniaczek said:
But: as I understand: XIP means "eXecute In Place". Dll's as modules are executed from slow ROM [and there is no shadow RAM] [and there is no way to cache them]. Dll's as files are loaded into RAM, and then executed. Correct me, if its not true.
Click to expand...
Click to collapse
There are 3 types of DLLs used on WM5. First type - normal files, they are loaded into RAM, fixups are processed, etc. They are slow to load (due to fixup processing), but would execute from RAM. Second type - XIP, which are executed directly from ROM and would work slowly. In BA this set of files is executed directly from ROM:
Code:
device.exe
filesys.exe
nk.exe
busenum.dll
cecompr.dll
ceddk.dll
certmod.dll
coredll.dll
crypt32.dll
devmgr.dll
diskcache.dll
fatfsd.dll
fatutil.dll
fsdmgr.dll
fsreplxfilt.dll
hd.dll
imgfs.dll
msflash.dll
mspart.dll
osaxst0.dll
pm.dll
regenum.dll
relfsd.dll
It is much less than was in WM2003.
And WM5 added a new filesystem - IMGFS. It contains compressed modules split to sections, but they are fixed to specific addresses in RAM, they are decompressed to these constant areas and executed from RAM. They are similar to XIP as they also don't contain relocations, but would work fast. I don;t know the correct termin for this type of files.
To replace files in XIP section you'll need this tool - http://forum.xda-developers.com/viewtopic.php?t=33321
if you overwrite any of files I've wrote here by a CAB file or other method without modifying ROM - their old versions would be used instead because they are loaded much earlier than all filesystem drivers.
Thanks mamaich
Registry Question
thanks for the files baniaczek!
does anyone know which file or how the other OS registry entries (the ones not in the boot.hv) get created? There are so many more in a full registry.
thanks!
P.S. thanks mamaich for the great tools!
Re: Registry Question
OS imports *.RGU files on hard reset, and it also reads mxip_*_*.provxml files that also can setup registry items. On Universal and similar devices registry can be set by CAB files in extended ROM.
If you add a new RGU file to OS image it would not be processed. Maybe they should have DSM file with the same name, or be mentioned in [HKEY_LOCAL_MACHINE\System\ObjectStore\RegistryUpdate] key or in packages.sof. I don't know. I always add keys to default.hv/user.hv or edit existing RGU files.
I am seeking some wisdom on the subject of Pocket PC ROM files...
The purpose of my enquiry is to ask if anyone would know how one might be able to extract a ROM image from a Pocket PC in such a way as to preserve the file structure and make it possible to extract (copy) specific files that normally sit in the \windows directory but are read only and unable to be copied from the PPC. An ideal would be to be able to read the ROM and write the file structure onto either an SD/CF card or simply to the flash RAM in the device itself.
The reason I am trying to do this is to extract either just the codec or if necessary the .exe and .dlls needed to be able to run Windows Media Player 10 Mobile on my Toshiba e830. This would enable playing .wma Lossless audio files - better than the Variable Bit Rate capability of the WMP9 codec.
I have an iPaq hx4700 which had WM10 mobile included in its original SE build and also the WM5 upgrade image that has since been installed on this device as a suitable source. I have looked through the WM5 ROM in a hex editor (UltraEdit-32) but cannot identify which parts of the code are relevant.
Through browsing the threads on this forum I have found and tried various of the Grab-It tools. I hoped that maybe it would be possible to find / extract the WMP10 hex from the WM5 ROM Image and transplant into an image of the e830 saved with Grab-It. Unfortunately I simply get repeated error messages >> Cannot create file! <<when trying to run Grab-It - I have tried (all) of the versions on both the hx4700 (with WM5) and the e830 (WM2003SE) with the same results.
Any suggestions you have as to how this could be accomplished would be greatly appreciated !
Best Regards,
Kevin
hi everyone,
i was'n able to find the file(s), where the incomming sms-data is stored. are they accessable directly from the xda/pda/... or via activesync-connection? can i get any access to these sms?
i'm using the excalibur with wm6.
thanx, dess
-UP-
no ideas?
They're not just in a folder. They're stored in some kind of datafile.
I don't know where unfortunately. You can find more info on this at the MSDN.
Hmm, seems that \PIM.VOL contains the contacs etc. but it seems, like this file don't saves the SMS.
So any suggestions, where to find the "SMS"-datafile?
By the way, does anybody know where to find some information about the structure of PIM.VOL?
Regards, dEsS
For the info about the PIM.VOL structure you have to be at the MSDN. There you can find all information about how to access them. (this is also possible with .NET Compact Framework)
Edit: maybe you'll find something usefull over here: http://search.msdn.microsoft.com/se...ery=access+sms+store&refinement=55&lang=en-us
\CEMAIL.VOL as far as i know, look into that file name, are you trying to backup your sms's ?
Can I modifiy database .vol as pim.vol?
Wich software?
Use Pocket Outlook Object Model.
Its more better then functions for (C)EDB format - http://msdn2.microsoft.com/en-us/library/ms886013.aspx
Thansk for your reply.
But i'm not able to coding.
There is a software that do this?
You can try database explorer -http://www.sweb.cz/eXEden/Download/CeDbExplorer.ARM.CAB.
Hovewer I don't know if db explorer works as expected on Windows Mobile 5,6..
hi buddies, does anyone one know how to hack an app? for example, change a predefined （hard coded) path like "\storage card" to any other locations. I tried to use hex editor but couldn't find any paths hard coded. I know there's a program called "Olly Debugger" for Win32 which can change binary code to machine code. However it doesn't support PPC applications. Can anyone help?
Many thanks!!
If the path does not appear in the executable then it is not hard coded in the program.
Hard coded strings, string tables, static data and the like, get bundled together by the linker into a separate data segment. They would all appear in the same area within the exe.
The program is probably using FindFirstFlashCard() and FindNextFlashCard() functions to emumerate storage devices. "Storage Card" would be returned by this/these function(s) at run time.
Another reason may be that the executable has been 'signed'. In this case the code is encrypted with the certificate so the hard coded stuff cannot be seen. Altering the code here will invalidate the checksum and the operating system will refuse to run it.
hi stephj, thanks for your info! finally i can figure out the location is hard coded in a dll file instead.
btw do you know how to convert a module (in the form of folders) into a binary dll?
thanks!!
Not quite certain what you mean. A DLL file is the same structure as a .EXE except that it does not have a WinMain() function that a .EXE file has that the loader calls once it is loaded.
Once a DLL is loaded the loader can resolve the real address(es) of its exported function(s).
sorry, i was talking about the modules in rom cooking. after dumping the rom, some DLLs appear in the form of modules (which are folders). what I want to know is the ways to convert these folders into binary files.
In that case it's over to the chefs. My expertise is in the area of application development.
Thanks stephj!!
To convert module to file, look for recmod
It will give you a plain .exe/.dll you want to modify.
After you do it, restore it using reversmod