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.
Hi all,
I'm an owner of FSC T830 Loox...
With the great help of bepe and mamaich I'm trying to cook my own rom... (thx guys, really!)
At the moment replacing even one module makes the device not to boot.
The problem is now upgrading the rom from aku 2.x to 3.x
As mamaich says newer AKUs have added new functions to coredll, therefore I need to port the XIP section...
I need help on this case:
I succesfully dump the XIP of my ROM
dump -o 0x00250000 myrom.rom xip.bin
dumprom -5 xip.bin -d xip
The question is: how can I port the XIP section from a newer AKU?
Thanks for all your valuable helps!
hi turchino,
do you find a solution for flash a loox t to a newer os version?
bg joy
Hi!
I'm also trying to port the xip section from a newer AKU to the T830.
It seems that none of the current tools is working correctly with that rom. Rommaster isn't working at all. Dumpromx can extract files, but not replace any (e.g. replacing a bigger file with a smaller ->not enough space...)
I've tried to manually replace coredll.dll in the t830 xip section with the newer one but it didn't want to boot. The strange thing is that t830's coredll.dll is much bigger than one from AKU 3.5.2. Any ideas about that? (maybe compression?)
I've also noticed one realaddr of a .pdata section from nk.exe is pointing out of the xip section?! (psize:00000000, dataptr:00000000)?
Also relocating a completely AKU 3.5.2 xip section to t830's base address and changing boot.hv isn't booting.
Any ideas how to get that running?
hey. bepe's xipport is designed for dealing with WM5/WM6 xip's.
with dumpromx you would need to increase the image file size by adding 00 bytes at its end before attempting to add anything. be careful, if the xip section grows too large then it may not fit in the partition in your nand flash....
also i'm not sure if it supports wm5/wm6 xip editing or just ce 4.x/wm2003/ce3.
rommaster is too buggy dont even try that one i think...
manual replacing isn't too tricky if you know what you're doing.... you need to know about PE header stuff. how did you try to replace it?
also, the new coredll should have the same base address as the original one or one that isn't conflicting with anything else.
did you make sure about that?
did you also edit romheader properly - because if this new coredll was larger than the original one the image is larger for sure and romheader needs editing.
don't forget about compression issues either. maybe that's why the original one is much bigger. but i would need to see the coredll's in question
anyway it is possible to do a coredll replace manually (did that before), no worries. but bepe's tool might make it easier
you say: "I've also noticed one realaddr of a .pdata section from nk.exe is pointing out of the xip section?! (psize:00000000, dataptr:00000000)?"
if psize is 0, then the .pdata section isn't really initialized data. it's a zero sized section and will only be existing when the loader loads the executable into ram.
but it sounds kind of strange to have a .pdata with 0 size, which file had this section?
edit: ok i see you meant nk.exe heheh. that's fine. it usually does have a zero sized section
you say: "Also relocating a completely AKU 3.5.2 xip section to t830's base address and changing boot.hv isn't booting."
how did you do the relocating?
xipport was the exactly the tool I was looking for. After a few modifications "realloc P" of the unmodified xip gave me exactly the same map.txt as the original t830 xip map.txt. After exchanging all kernel files (except hd.dll and osaxst0.dll which were needed to keep another oem file in the same location as it was before), reallocing and changing the header address in nk.exe it still isn't booting (it runs nk.exe but gets stuck somewhere in there). Maybe you can have a look at the whole thing (download here, with modified xipport)
As for the coredll, it turned out that dumprom missed a section.
I did the relocation by writing a little app which runs through all pointers and changes them, but this is also possible by editing romheader.txt from xipport.
ok I've changed the other dlls too (had the same size), but it still wont boot. Is there a kernelflag which I can set to get debug messages on the screen? Or do you know if the nandflash driver trueffs.dll from AKU2 is compatible with AKU3?
hey. sorry for the delay.
did you solve the problem yet?
if not, i'm going to check it for you soon.
about coredll. OK but how do you mean dumprom missed a section? i've never heard that before about it.
relocation: yeah, romheader.txt is the trick there. but, must be a nice app. i'll check it out (i see it's in the zip)
edit: OK i took a very quick look (i need to go now). the xips you uploaded have completely different romheaders and rom mappings (0x88xxxxx vs 0x80xxxxxx). what you said about relocation sounded like you already fixed that, but why did you upload this old version then? or did you upload original T830 and original AKU 3.5 from another device? i'd like to see your xip (that doesn't boot).
p.s.: did you make sure the hard coded romheader pointer in the kernel matches the romheader pointer/location in your xip ?
"edit: OK i took a very quick look (i need to go now). the xips you uploaded have completely different romheaders and rom mappings (0x88xxxxx vs 0x80xxxxxx). what you said about relocation sounded like you already fixed that, but why did you upload this old version then? or did you upload original T830 and original AKU 3.5 from another device? i'd like to see your xip (that doesn't boot)."
The xip in "xipport" is the modified t830 xip that doesn't boot. (btw. xip.bin in that folder is the original t830 xip). And the xip in "xipport aku3.5.2" is the xip I want to port to the t830.
The only success I had to now was getting the original wm5 aku 2.3 rom to run with the aku 3.5.2 coredll.dll. Is there anything else I have to do after I have replaced the t830 sys folder with an aku3.5.2 folder and building the reg/imgfs? Or does the kernel want to have some files at a specified address?
"p.s.: did you make sure the hard coded romheader pointer in the kernel matches the romheader pointer/location in your xip ?"
yep, the kernel always gives a me message when it has found the romheader and continues booting. Therefore I always know when I missed something
hey.
OK that sounds more clear now about which xip is which!
i'll look at it again soon.
until then: did you verify the copyentries are all OK? xipport sometimes has a silly bug regarding them.
easiest is to just delete hd.dll and osaxstxxxxx.dll - they are the ones that require copyentries apart from kernel. (kernel copyentry isnt screwed up by xipport anyway.)
but, they are not needed for a booting kernel, just debug stuff afaik. so deleting is easy..
btw, even if the copyentries are OK, using the wrong hd.dll/osaxstxxxx.dll will make the xip unbootable.
also pay attention to map.txt see if the base addresses overlap or not (usually not but worth checking), also if .data base addresses (the 0x01Fxxxxx ones) have not been changed. they should not be changed. another xipport bug sometimes.
new--->
update: i looked at your xip now.. none of the above seem to apply. i'll leave that stuff there though.
last thing i can think of is try editing physlast in romheader to point to last actually used byte in xip.. that shouldn't matter but who knows
can you tell me how far does your system boot. maybe the xip is fine and your IMGFS part is wrong. check for module overlaps.
what is last message you get from your kernel?
and, to answer your question about kernel wanting to have files at specified addresses. well, the kernel regions have to stay at the original addresses in the xip, except for the region that is copied out and for the discardable last region (same for the debug crap dlls)
Core_Z said:
"
The only success I had to now was getting the original wm5 aku 2.3 rom to run with the aku 3.5.2 coredll.dll. Is there anything else I have to do after I have replaced the t830 sys folder with an aku3.5.2 folder and building the reg/imgfs? Or does the kernel want to have some files at a specified address?
Click to expand...
Click to collapse
Hi Core_Z,
I'm trying to accomplish the same thing for our XDA Atom. I was wondering if you could describe how you achieve above. I, too, would like to replace the coredll.dll in our old AKU2.2 from the AKU3.X
These are the steps, I made using the modified XIPport (with realloc function):
1. coredll.dll comes from XIP of Atom Life which has same base address
2. replaced the modules and corresponding txt file into ATOM AKU2.2
3. new core is larger than the old one; so, I increase the ROMHDR.txt physlast to accommodate it.
4. realloc / write new maps.
5. move the rom header pointer in the nk.exe S000 module to the new one
6. built xip_out.bin
7. wrote the new bin to ROM image file
8. flash the device.
It won't boot. Did I miss anything?
cmonex said:
easiest is to just delete hd.dll and osaxstxxxxx.dll - they are the ones that require copyentries apart from kernel. (kernel copyentry isnt screwed up by xipport anyway.)
but, they are not needed for a booting kernel, just debug stuff afaik. so deleting is easy..
btw, even if the copyentries are OK, using the wrong hd.dll/osaxstxxxx.dll will make the xip unbootable.
Click to expand...
Click to collapse
Hello cmonex / core_z,
I followed this by removing the files you mentioned above. So, my current AKU2.2 XIP has the new coredll.dll from AKU3.X boots now. This means, that hd.dll / osaxstxxxx.dll is preventing my revised XIP to boot.
Question is: How do we restore this modules correctly?
Jiggs
I have another concern...
I have utilized the new XIP with new AKU3.X \SYS files, and rebuilt the ROM using the Scoter Kitchen. In the IMGFS section there is .ROM module wherein the ROM header is also described. However, there is one entry which is not clear to me... which is the e32_imageflags
The old AKU2.2 uses 0x00001e01, the new AKU3.3 uses 0x00002801. If I use the new values, the SDCard driver will not be loaded. If I use the old value, it will be loaded. What does this mean?
Now, because of this, after I build the ROM each time, I have to manually hex edit these values from 28 to 1e. Why? because not all entries of 28 has to be converted to 1e.
check this out Jiggs,
http://www.pxdxa.com/read.php?tid=40125&fpage=1&toread=&page=1
jiggs said:
Hello cmonex / core_z,
I followed this by removing the files you mentioned above. So, my current AKU2.2 XIP has the new coredll.dll from AKU3.X boots now. This means, that hd.dll / osaxstxxxx.dll is preventing my revised XIP to boot.
Question is: How do we restore this modules correctly?
Jiggs
Click to expand...
Click to collapse
hey! i'm back if you still need help: you dont need these dlls, they just take up space. if you really want them then you can do one of two things:
1) use the original dlls from the device's original xip
OR
2) rebase them but this can be more difficult than with ordinary dlls.
(i did not try either, because those dlls are just for debugging anyway.)
jiggs said:
I have another concern...
I have utilized the new XIP with new AKU3.X \SYS files, and rebuilt the ROM using the Scoter Kitchen. In the IMGFS section there is .ROM module wherein the ROM header is also described. However, there is one entry which is not clear to me... which is the e32_imageflags
The old AKU2.2 uses 0x00001e01, the new AKU3.3 uses 0x00002801. If I use the new values, the SDCard driver will not be loaded. If I use the old value, it will be loaded. What does this mean?
Now, because of this, after I build the ROM each time, I have to manually hex edit these values from 28 to 1e. Why? because not all entries of 28 has to be converted to 1e.
Click to expand...
Click to collapse
those values arent really e32_imageflags... i dunno why the imageinfo txt is created in that way for .ROM and .VM
thats to do with the imgfs memory space. probably the SD driver's image base is lower than the new imgfs memory space start address (which is what you were seeing)
to confirm that check the base address (e32 vbase) in imageinfo.txt for the sd dll.
cmonex said:
those values arent really e32_imageflags... i dunno why the imageinfo txt is created in that way for .ROM and .VM
thats to do with the imgfs memory space. probably the SD driver's image base is lower than the new imgfs memory space start address (which is what you were seeing)
to confirm that check the base address (e32 vbase) in imageinfo.txt for the sd dll.
Click to expand...
Click to collapse
Thanks for the info! I'll look at this later.
Here goes nothing: I've been trying to understand the whole porting process but no one ever posts on my threads, so I figured I'd post on this one since it's about the same thing. I'm reading the thread and I'm following... most... ok, half of it. I thought the process of porting the XIP and the SYS was as simple as well... this. If someone wants to correct me, by all means, please do so.
hi,
i have modified bepe's new rom kitchen (PRB) to suit my needs.
for months it's working flawlessly.
due to some updated rom tools, i have modified the kitchen batch to include the updated tools. i have updated all the folders in the kitchen (EXT, OEM, ROM, SYS, tools & toolset) with the latest packages, tools, etc.
then 2 weeks ago, i can't build a rom with my kitchen.
everytime prb executes, it is showing this platformrebuilder errorlevel: -1073740777.
today, i have managed to trim down the cause for this error.
if i have a module inside EXT folder, (i.e. EXT\COMMON\Scrolling\files\PhysicsEngine.dll - which is a module), prb throws the error.
however, if i move the module outside the files folder, (i.e. EXT\COMMON\Scrolling\PhysicsEngine.dll), or recmod the module (convert the module to file), there is no error. i can build a rom with success.
i have this packages with module before i modified my kitchen and i can build without error.
i would like to ask if you have also encountered the same error, or its just me and i would also like to know what could be the cause for the error.
thanks very much.
regards,
mike
Its trying to replace the module, and couldnt since its a module. Want to use the the one in EXT, then you will have to delete the one in OEM or SYS.
Yeah, I'm agree. I has a Mui file as a module (???) in an Oem_lang folder. This cause the error. I just change the module for a mui file and all goes ok.
thanks for the replies guys.
regards,
mike
I recall seeing that issue with certain versions of EVK. I also recall, ervius stating that he had fixed EVK to support both locations for modules:
.\packagename\<modulefile.ext>
.\packagename\files\<modulefile.ext>
A search through the EVK thread should bring up the particulars. Search using the internal search function by member name - his or mine (think it was me that brought it to his attention). Also, the module folder only needs to contain the imageinfo.* & S#### files - the .DLL/.EXE/.MUI/etc. file doesn't need to be present ... it will get created a build time.
HTH,
* EDIT *
http://forum.xda-developers.com/showthread.php?p=4243721#post4243721
hi,
after further investigation, i have found out that if the original module's attribute is not the same as the new module (i.e. PhysicsEngine.dll\imageinfo.*, S00x, etc.), prb will throw the error -1073740777. otherwise, no problem/error encountered.
so my conclusion is, if you have to overwrite a module, the new module should have the same attributes as the old module.
regards,
mike
twisted said:
hi,
after further investigation, i have found out that if the original module's attribute is not the same as the new module (i.e. PhysicsEngine.dll\imageinfo.*, S00x, etc.), prb will throw the error -1073740777. otherwise, no problem/error encountered.
so my conclusion is, if you have to overwrite a module, the new module should have the same attributes as the old module.
regards,
mike
Click to expand...
Click to collapse
So how do we correct the attribute?
ai6908 said:
So how do we correct the attribute?
Click to expand...
Click to collapse
i've done it manually, right-click the original file (i.e. S000) and check the attributes, should be the same with the new file (i.e. if original file S000 has attribute set to Hidden Read-only, the new file S000 should also be set to Hidden Read-only).
regards,
mike
I try to cook a ROM for my Acer neoTouch S200(F1), I could finish it for me, thanks hdubli, DimICE and rafyvitto
I just use a few tools but not GUI kitchen so that I could learn more about making ROMs:
xidump.exe for dumping
osnbtool.exe for dumping and rebuild the ROM
RecMod.exe
ImgfsFromDump.exe, BuildOS.exe, EXTReloc.exe
XIPPort.exe
f1extromtool.exe for ExtROM
At the same time, I'm porting EZInput CHT form HD2 Leo...
Of cause, I want to porting EZinput CHT in cab from, for anyone who don't use custom ROM besides HTC.
Questions:
1. I'm not sure that was RecMod disadvantage or bugs, it seems that the files after RecMod would lost the cert... (#2)
2. Then it could cause a ton of problems, such as how can I indicate files needed to re-sign? Any tools could port a cert to another file?
Or have to patch a ton of files even a whole OEM packages?
3. Would the modules at Slot 61 could reduces the actual free RAM of process (shown in the memory page), even the process not using these modules? Then, how to estimate the minimum RAM used?
You can't sign the modules - only the files.
utak3r said:
You can't sign the modules - only the files.
Click to expand...
Click to collapse
Then, could the SDKcert could be hacked for changing name of signer?
or how to make the cert for it?
Moreover, the difficult problems is that how to sign all the unsign dll and exe with SDKcert easier?
You can just cert patch the nk.exe and not have to worry about the problem (with EVK, just check a box). More to the point, what errors are you getting, and are you sure it's actually a certificate error and not a 'missing component' error?
Farmer Ted said:
You can just cert patch the nk.exe and not have to worry about the problem (with EVK, just check a box). More to the point, what errors are you getting, and are you sure it's actually a certificate error and not a 'missing component' error?
Click to expand...
Click to collapse
I'm not using EVK, because I'm cooking for Acer S200, then I just use a few tools...
Emmm, no any certificate error or 'missing component' error, just the services or programs could not be able to auto start.
Patch nk.exe could be a good choice for cook, but not the best for the user, I think.
However, for patch nk.exe, it still followes this thread?
http://forum.xda-developers.com/showthread.php?t=384137
Nagato Yuki said:
I'm not using EVK, because I'm cooking for Acer S200, then I just use a few tools...
Emmm, no any certificate error or 'missing component' error, just the services or programs could not be able to auto start.
Patch nk.exe could be a good choice for cook, but not the best for the user, I think.
However, for patch nk.exe, it still followes this thread?
http://forum.xda-developers.com/showthread.php?t=384137
Click to expand...
Click to collapse
so please tell us what is exactly your trouble... cause:
1.- cert patches are now a unusual issue cause the kitchens already has certs pkg included to void this things.
2.- use the xipporterexe in EVK to patch your nk.exe thats all then readd your nk to your kitchen.
3.- certs issues are
a) when you tap... it shows a dialog saying is not trusted signed or has missing compoenents...
a1.- this means (obviously after you add the certs pkg or enable the kit5chen option or whatever to fix it) that the lnk is pointed to a non complete PKG it has missed some files, due to "maybe" it needs the app files in program files or a bad pkg creation (app.reg or app.dat) (or initflash oem pkgs)
4.- why patch nk.exe is not the best option to users??? i guess is the best cause if they use a devs app it will works with a cert patched nk
5.- the service or apps wont auto launch.... mmmm you must to xplain better cause it seems not related to certs matbe autoshortcut.. initflashfiles or app.dat troubles or corrupted PKGS.
Advice: please please... post your device model, kitchen name and version, and sys oem version if posible
once you redesign your question i will change if you wish the name of the thread just have more help
keep it up
Much BIG THANKS for your reply
Because I am not use any GUI kitchens, at this time, it seems that no GUI kitchens for Acer S200, then I don't try EVR before.
(BTW, it seems that we lack of Universal GUI kitchens for any device? Because the process to make ROM could be much similar, except decompose and assemble back the ROM files. I'm trying to use osKichens... )
In my case, there no any dialog saying not trusted signed or has missing compoenents... It just doesn't run for apps.
For services, they could not be able to start automatically, but I could start them manually though Dotfred's TaskMgr, no any dialog happen also, but they could run correct functionally !
Then I sign with SDKcert, they work normally.
For patching nk.exe, it could be very difficult for users who just want to use official ROM, but want to use apps form dev. But sign the cert and import the sign could be much easier...
Then it leads the second question. I'm seeking any effect ways to Recmod and sign them with sdkcert ...
Of cause, I want sign them much look like OEM ones (subject's and issuer's names), but just using SDKcert only for running.
Moreover, XipporterEx for patching nk.exe, it seems that there is no standalone one for porting WM 6.5.x one. And also I'm not sure that besides EXTReloc, Is there any Reloc programs compatible for Acer S200/WM6.5?
p.s. I could try to modify my questions later, but if someone help could be much nicer. So, +Que, please feel free to change my topic for better one
I'm pretty new to the winCE scene - but I figured that someone in this forum probably has a really easy answer since it seems like the kind of stuff you guys do on a daily (or maybe even hourly) basis.
I've got a navigation device that's windows CE based - they put out a new update that now compresses the modules. All of the existing tools that are customized for the navigation system hacking seem to be subsets of the windows mobile hacking tools and use some of the same code:
Here are some of the tools people have used in the past to hack on these nav systems:
DumpNavi by bysin ( http://www.linuxkiddies.com/projects/navi/ ) is windows based and uses the native nkcompress.lib / cecompress4.dll to
handle compressed files - but doesn't handle updating modules (it will extract them ok, just not replace them) (I could update this to handle updating modules in a .bin and then this would probably work)
cerom ( http://code.google.com/p/cerom/ ) is linux port of bysin and will update modules inside a .bin - only it doesn't handle compressed modules. (I could update this to handle lzx compression perhaps - and then this tool would work)
cebin ( http://home.earthlink.net/~akonshin/files/cebin.0.6.zip ) has a nicer batch interface but doesn't handle the compression in the .bin file. I don't know where the source for cebin is so I don't think I can update this.
The file I want to update is HMIManager.dll inside of 09Touch2.bin - someone hosted the .bin file here:
http://www.4shared.com/file/364rDLnq/09Touch2.html?
I've already got the dll module patched the way I want it to - now I just need to find a way to get it back into the .bin file so I can load it on my nav device.
I can work on modifying the tools that are navigation-centric but I figured that I would first ask here if there are any existing tools that will do the job off-the-shelf. I looked at some of the romtools and wasn't sure if something like splitrom would help or maybe one of the other tools.
Any help is appreciated!
Hi , i am looking to do the same !
I have a Honda Alpine NAVI based on WinCE4.2.
With DVD 3.23 there isn't a "DVD Check" and with DVD 3.31 and more you can't backup DVD because the Navi see that is a backup.
Now my game is to compare all files in 3.23 with 3.31 and replace in 3.31 the file that check the DVD.
I've found many files that have been changed and one is : HMIManager.dll
How did you find this in your case ?
Do you have same game as me ?
Best regards
tbzdat00
Yep, I had to get nitty-gritty with the windows ce pe format, but I managed to update the business tool to be able to replace compressed modules with updated versions.
If the DLL isn't compressed then there are a few tools that will work.
The github repo for the updated bysin that will handle the compressed modules is here:
https://github.com/ryangardner/dumpnavi/
The best info is here: http://wiki.hive13.org/Honda_Navigation_Hacking
Mine used the "white disc" so it was different. I think patching your hmimanager.DLL is a better approach since it probably changed more than just DVD checking.
winCE.bin for Navi
Same situation here, although I'm using the Euro versions. The bin file to extract is 07avne2.bin and from a first look the images are also on different images, and I've only managed to identify 2 images. I'm still trying to "understand" IDA Pro to try to follow either the disc check and the OK button
best regards
Luis
Hey guys, would you mind sharing?
What is the system Honda uses to sniff out the backup copies?
I'm trying to do a backup with maps for my country WHICH Honda DOES NOT SUPPORT! and therefore has no right to ask 200$ for a new CD or update.
But so far I can't do a copy that reads as an original.
Please reply.