Database Users

Actual size of file (extracted using dumprom) is not OK

Hi, I am trying to extract a file (actually, cplmain.,cpl) from a rom image. It all seems to work fine, but the size of the extracted file is lesser than the right one.
File seems to be truncated.
I did:
1) get the "B000FF" file (.bin), 24,856,907 bytes
2) Since dumprom seems not to "like" this format, I converted it using splitrom:
perl splirom.pl file.bin -wo file.rom
3) I don't know which format it generates to file to, but now dumprom works:
dumprom -d result file.rom > res.txt
4) A few snapshots of the file res.txt, regarding the file cplmain.cpl:
NOTE: section at fee73000 iso 00044000 for cplmain.cpl
806f5fe4 - 806f5ff0 L0000000c modname cplmain.cpl
8072d000 - 8076fe1c L00042e1c o32 region_0 rva=00001000 vsize=00042e1c real=02e61000 psize=00043000 f=60000020 for cplmain.cpl
80770000 - 8079e600 L0002e600 o32 region_3 rva=00048000 vsize=0002f000 real=02ea8000 psize=0002e600 f=40000040 for cplmain.cpl
808c7650 - 808c76bc L0000006c e32 struct 4 objs, img=212e entrypt=0000b408 base=02e60000 v4.20 tp9 cplmain.cpl
808c76bc - 808c771c L00000060 o32 struct cplmain.cpl
80a36870 - 80a36ff6 L00000786 o32 region_1 rva=00044000 vsize=00001800 real=01cd3000 psize=00000786 f=c0002040 for cplmain.cpl
80a4d0d8 - 80a4dffd L00000f25 o32 region_2 rva=00046000 vsize=00001ca8 real=02ea6000 psize=00000f25 f=40002040 for cplmain.cpl
80be2ed8 - 80be2ef8 L00000020 modent 20 00000005 01c3f9e1932529f0 486400 8119a000 cplmain.cpl
...............
5) Last line's "486400" is actually the *right* size of the file, but the real size of the extracted file (in directory "result") is 477,184.
I have not checked other files, since this is the one I am interested in.
Any idea?
Thanks in advance

XIP files would report incorrect size. Because they are XIP

If XIP files report wrong size (I guess you mean inside the very NB1 file), how can one fix this?
Spasiva!

I guess i am not using the same alignment of blocks in the reconstructed .exe file, as was used for constructing the rom.
it is not a really important issue, that the file is not exactly the same size.
there are also sections missing in the rom, that were in the original file, like the relocation information.
the main use of dumprom extracted modules, is that you can reverse engineer them with something like IDA. .. not that they are useful as real executables.
willem

Hi Willem,
Well the thing is that I need this file to be the right size. I agree that size is not important (that's what I actually say to my girlfriend ;-) ) as long as the extracted file's is greater, not lesser (which implies truncation) than the original's. The problem is that the file I got is smaller, so there is some missing data in.
Actually, I copy cplmain.cpl to the ppc as cplmain2.cpl, I do:
ctlpnl cplmain2.cpl,2 (for instance)
and it simply does not do anything.
Excuse my ignorance, but, what is IDA?
Dank u vel

IDA: http://www.datarescue.com/idabase/
you can't use a file extracted with dumprom on another device.
most executables and dll's ( and cpl's ) are fixed to work at a specific location in memory in one specific ROM. you can't use it on another device, it will most likely have a different memory layout.
willem

If you have two versions of the same DLL that are different only in code and data base addresses, you can restore the .reloc section and get a working DLL. I've wrote a simple program that when used with any relocation rebuilder tool would produce a working DLL. And even if DLL is not working, it is much easier to decompile it with IDA because it uses relocation information internally during analysis.
The DLLs should be exactly the same, for example they can be taken from the same ROM builds that differ only in language (of cause in this case DLLs should not be localized).

WM5 ROMfiles dumps [files, modules and registry]

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.

Samsung i607 Blackjack ROM cooking (Applies to i600 and other Samsung phones)

I was trying to cook a modded ROM for the i607, I was able to extract the nb0 from the bin file using cvrtbin & viewbin > then Mamaich's prepare_imgfs > viewimgfs > dump > modify/add/delete files > buildimgfs > makeimgfs and I know this is basically what you do with the Hermes ROM, however making it back to a BIN file has proven to be a "no go". I have tried splitrom.pl, rommaster, xipbin, etc, but I am afraid without the right utility this will not happen.
Does anybody know if there is a Tool to convert the cooked nb0 back into WMx B000F bin file? There is an old tool for Mobilpro xipbin.exe, however the block size and lenght of ROM does not match. Doing the splitting in sectors and retrieving the checksum manually is going to take a lifetime...
Just an idea: Could it be possible to use a blank CE.BIB with only the start and offset of the ROM and romimage from MS PB builder together with the nb0 file above?
Any good ideas are welcome.

I tried using romimage with no results
I tried to use Romimage from MS platform builder, and after many attempts I gave up. I basically used a minimal CE.BIB and the patched ROM (nb0) file as the source to be inserted. It creates the Run-time BIN file with 4K blocks where it should be making it 128Kb ones.
TO Do:
Try an HEX editor with macro or script capabilities, to perform the following process
1.- Strip the HEADER+RECORD section from the original FLASH file
2.- Strip all zeroes preceding the patched ROM (NB0) before the start point
3.- Cut the patched ROM in 128K chunks (about 500 pieces) called blocks or records
4.- Calculate the Checksum 32 of everyone of these chunks and annotate it
5.- Make the HEADER of the RECORD annotating (in little endian) : Start Address - Lenght(Block Size) - Checksum 32 for every record
6.- Join the HEADER to the respective record. Iterate this process until finished (some 500 times)
7.- Insert the above joined (HEADER+RECORD) section into the stripped flash file in step 1
8.- Here comes the scary part : flash the phone with this MOD (just the PDA section)
9.- If successful, make a program to automate steps 1 to 7
Wish me good luck...
On other comment: according to Texas Instruments, in the Code Composer Studio for OMAP processors, it can be connected to the phone via a COM port using HyperTerminal. Alternatively I think if we can flash the phone using this method and a ROM type NB0.... Perhaps no, as the flash program just connects to the phone using the Serial port qhen in Flash mode. This program also accepts img files, I tried to rename the nb0 file to img and didn't work. Does anybody know what these Samsung's img files are?
Is anybody interested on this matter? Please don't just read the post, start replying... If we really want to MOD this phone, being it the BlackJack i607 or the European i600, we need to start doing some Reverse Engineering..., the people at xda-developers had started this way to master the HTC and similars.

hey, i replied to your email. hope it will be helpful. especially if you give me a link to the image

cmonex said:
hey, i replied to your email. hope it will be helpful. especially if you give me a link to the image
Click to expand...
Click to collapse
Thank-you, however I haven't received your reply yet. I'll send you the link to the ROMS via private message .
Regards,
trinca

The modded ROM
Cmonex:
I have uploaded the modded ROM and is located at:
http://rapi*****/files/42779528/XXGD1_pda.nb0.html
******************W A R N I N G *********************
For everybody else following the thread, please be advised
this above file is a plain binary, it must be converted to a
MS WMx BIN format with a B000FF header before flashing any BJ.
Please do not attempt to flash your phone with it!
**************************************************

I haven't received your e-mail
cmonex said:
hey, i replied to your email. hope it will be helpful. especially if you give me a link to the image
Click to expand...
Click to collapse
Hi, Cmonex:
Can you please resubmit?
TKS
trinca

For those of you who would like to start cooking this ROM
I was able to extract the plain image using cvrtbin (MS tool that comes with visual studio) you may grab a copy from here:
http://www.toradex.com/colibri_downloads/Linux/linux_to_wince/?D=D
Then you will be able to use the common tools from xda-developers such as prepare_imgfs (with the switch -acer) from the WM5 kitchen made by itsme (first sticky in this forum) and so on.
Making the ROM back to the B000FF format is going to be the trouble... So far there is not an easy come back... yet!
There is also an excellent article on Mobilepro BIN roms made by cmonex, you can get a copy of that tutorial inside his Romtool package, get it from here:
http://hpcmonex.net/nec900/files/releases/romtoolpack.zip
Be informed the Mobilepro ROM is very different in the way the Runtime file is organized, however the tutorial is the best resource I have seen so far.
Besides, there are some really good tools inside that package
Best regards and start cooking!
trinca

Samsung i60x ROM: Extracting the OS payload from the Upgrader exe single file
The Upgrader program contains 3 payloads: Eboot, Phone and O/S. To extract the O/S payload follow this procedure:
1. Open the exe upgrader file using the Hex editor of your choice.
2. Locate the ASCII string B000F followed by 0x0A. The complete sequence you should look for is 0x4230303046460A. You should find 3 occurrences of the above string. Concentrate on the last one.
3. Copy from this start address all the way up to the string 0x060000EA3B, which is the start of the phone ROM.
4. Make sure your cut includes 12 trailing zeroes 0x000000000000 as they indicate the loader the end of the Runtime of the pda image.
5. Name your file ending with a bin extension. (i.e XXGD1_pda.bin)
6. Proceed with cvrtbin to extract the absolute (or plain) ROM image (ending in nb0.
7. You are ready to start cooking.
I was able to sucessfuly extract in this way the ROMS for i600 releases: XXGC6 and XXGD1 and for i607: UCGB4 and UCGD2.
How did I find out? I got the chance of getting the XXGC6 upgrade package, which included the eboot, phone and pda sections separated. Further reading in the forums indicated the B000FF is followed by 0x0A, the start address of the ROM (00000000) and the end address. From there it was easy to locate the payloads in the Upgrader single exe file.
Good luck extracting your ROMS.

Samsung i607 Service Manual
Below is the link for the SGH-i600 service manual URL. Does anybody have the service manual and/or schematics for the SGH-i607?

BIN B000FF runtime image file format
Does anybody have a detailed description of the arrangement of headers and records in this file format? The best reference I have found is this page:
http://www.devpia.com/MAEUL/Contents/Detail.aspx?BoardID=60&MAEULNO=23&no=242&page=1
Unfortunately I do not understand Korean...

hey, i again sent you an email. i'll quote it in PM too just to be sure.
btw, the rom tutorial that i wrote and that you linked to, fully details B000FF format. what is not clear about it?

The tutorial is right
There is nothing wrong with your tutorial, I had to use the HEX editor several times until I got that right.

cmonex said:
hey, i again sent you an email. i'll quote it in PM too just to be sure.
Click to expand...
Click to collapse
Do you know if isotherm may share the source code for xipbin? Do you have a way to contact him? I tried to contact him at hpcfactor with no results.

Trinca - ok, let's imagine you got all the needed files to B000F format. How do you plan flash it back to your i607?

Creating the B000FF Runtime image
After cooking the ROM...how to re-create the B000FF Runtime image back? That is the $1M.. question, I am still navigating uncharted waters...
Producing the Flashable runtime image back is what I am now concentrating on, as I see it there may be 4 possible ways:
1) Manually
-a) Splitting the nb0 file in [n] 128KB chunks (for a ~64MB image, there are over 500 x 128KB chunks)
-b) adding the chksum32 at the beginning of each chunk
-c) adding the address and offset to the beginning of the above.
-d) merging it all together
-e) adding B000FF, start address and offset at the beginning of the merged files
You can use an Hex editor with scripting properties such as 010Editor and write a script to accommodate a) thru e)
http://www.sweetscape.com/010editor/
Still a pain in the neck and the scripting language is similar to C, if you know this language it will be easy for you to automate the above. Still experimenting with it.
2) Using XIPBIN, made by somebody AKA isotherm, this utility will make a B000FF runtime file good for a HP/NEC mobilepro, the record length is made 0x40000 bytes long, different from 0x1FFE0 record length of the original ROM, according to cmonex, this should not be a problem provided the record is made of different length and has the right checksum per record, but I already have made several attempts and it does not work for me, when flashing the phone it gets stuck at the very beginning. You may research further here.
3) Modify xipbin and make it produce records 0x0001FFE0 bytes long, as the source code for this utility is not available, cmonex says isotherm had disappear. I am still hacking into this utility...
4) Create our own program using VC or VB, I may probably work on this one as well, as I get some time available.
I am attaching a copy of xipbin.exe, however if you have followed my instructions, you may probably have it already, please let me know of any success (or failure, we all learn from these ones too).
usage:
xipbin [myrom.nb0] [start address for myrom.nb0] [myrom.bin] [start address for myrom.bin]
For Samsung's B000FF ROMs the command will look like:
xipbin myrom.nb0 0 myrom.bin 0
myrom.bin is then recreated from scratch.
Also according to cmonex, you may do the following:
a) Get an original B000FF ROM
b) use cvrtbin.exe and obtain a nb0 ROM
c) use xipbin with this nb0 and re-create a runtime bin file.
d) apply again this cvrtbin utility to the re-created runtime bin file
e) compare the result with above b) step
f) If they match you may have a candidate procedure, if they don't do not attempt to flash the phone with the procedure above.
I will include the new viewbin and cvrtbin, which now works with start address 0 on this type of ROMs
Usage:
cvrtbin -r -a [start address] -l [length of ROM] -w [8, 16 or 32] [romfile.bin]
cvrtbin -r -a 0 -l [the length of your ROM] -W 32 [myrom.bin]
Good luck!

The format of MS BIN B000FF runtime image file
According to several sources I have consulted, including MS documentation and insights given by cmonex, plus heavy HEX editing sessions, this is my impression on how the B000FF Runtime image format looks like:
Byte------>--1--2--3--4--5--6--7--8--9--A--B--C--D--E--F
Record 0 -> 42-30-30-30-46-46-0A--<Strt add>--<ROM lgth> * * * * * * * * * * * (42-30-30-30-46-46 = B000FF in ASCII ; 0x0A = end of header B000FF)
Byte------>--1--2--3--4--5--6--7--8--9--A--B--C--<-----128KB of nb0 image------>
Record 1 ->--<Strt Add>--<Rec lgth>--<CHKSUM32>--<--Chunk Nbr 1 of nb0 image--->
Record 2 ->--<Strt Add>--<Rec lgth>--<CHKSUM32>--<--Chunk Nbr 2 of nb0 image--->
v - v
v - v
v - v
Record n-1>--<Strt Add>--<Rec lgth>--<CHKSUM32>--<---Last chunk of nb0 image--->
Last Rec-->-00-00-00-00-00-00-00-00-00-00-00-00 .* * * * * * * * * * * * * * * (The last record always ends with 12 bytes set to 0x0)
**************************************
Please note:
Record 0 and the last one are different
All data are encoded Little Endian!
**************************************
Using the command:
viewbin -r [myrom.bin]
Will give you the record content of your runtime image file.

Trinca - just ran viewbin on samsung i750 image. chunks sizes are not 128kb each. looks like chunks are actually files from ROM in XIP format (executable in place, it is usual PE files but missing reloc table and something else). I bet we should use file deleting/adding/injecting utility like romtools one for ROM image manipulation which reamins intact B000F header! I see no other way to recreate B000F.

Well, I guess your runtime differs from that on the i60x. In any case I know of a tool made by bepe the name of xipport, you can look at this thread and download it here:
http://forum.xda-developers.com/showthread.php?t=315030
The best thing I can recommend you to do, is to try to get the appropriate format of your runtime image.
trinca

unfortunately all version of xipport just crash with errors on my ROM dump.

ROm Dump
JugglerLKR:
Let's get acquainted with your procedure, and do not pretend to modify something, just to find out if the tools work:
a) Have you dumped the ROM from the phone or you just extracted it from the updater executable?
b) If you have just cut the ROM out of the executable, use the new cvrtbin posted before (which runs fine at start address 0)
c) Run Mamaich's prepare_imgfs, there are 3 possible options:
prepare_imgfs [yourROM.bin] will produce imgfs_raw_data.bin and imgfs_removed_data.bin
prepare_imgfs [yourROM.bin] -nosplit will produce imgfs_raw_data.bin and an empty imgfs_removed_data.bin
prepare_imgfs [yourROM.bin] -acer will produce imgfs_raw_data.bin and an empty imgfs_removed_data.bin, but this one is the only which has worked for the i60x
d) Now if you use viewimgfs then the dump directory will be created and the files will be extracted. It is only after this confirmation you may be assured the ROM extracted has the correct structure for manipulation. I got so much trouble using the old version of cvrtbin, that I am telling you to run these extra steps.
Now try to run the xipport tool on the above *.nb0 file. and tell us if you were successful. At this point if you are not able to run the xipport tool, then you may not have something usable. RomMaster and dumprom/dumpromx are also alternatives for working with xip modules, please remember all these tools are highly experimental and not bug-free!
trinca

[APP] IITP - imageinfo.txt producer

IITP - imageinfo.txt producer
version 0.1 - 2009.06.18
IITP is the tool for generating imageinfo.txt files from imageinfo.bin files, found in modules. It's mainly for people who still use XIPPort
Usage:
Code:
iitp [ -p physfirst ]
The param -p is optional. The value of PhysFirst has to be given in hex form, but both 0x1234abcd and 1234abcd notations are accepted.
If the param is not given, it looks for romhdr.bin file in the current directory, from which it takes this value (and while it's there, it generates ROMHDR.txt file, too).
WARNING:
As of now, it generates incorrect info for nk.exe! The same goes for modules from imgfs space.
Correct info is generated as of now only for XIP modules (with the exception of nk.exe).
Fixing these two things are on the TODO list
Many thanks go to globalbus for the theory help and to c_shekhar for pushing me to develop this little tool. Thanks guys!
Project home page:
http://code.google.com/p/iitp/
Changelog:
2009.06.18
- Initial release

great work indeed. Shall download to test... kudos to you...

great job! didn't think this was possible
thanks

Excellent tool!! Thank you very much.. can't wait for the version that will parse NK.exe correctly
edit: Is it possible to also generate the other txt files which XIPPORT requires? e.g. busenum.dll.txt which contains:
Module name: busenum.dll
dwFileAttributes: 00000007
ftTime: 01C9E411213D1D00
nFileSize: 00002DB0
lpszFileName: P+0007BFEC
ulE32Offset: P+00180F68
ulO32Offset: P+001A16A8

inertiax3 said:
can't wait for the version that will parse NK.exe correctly
Click to expand...
Click to collapse
Yeah, it's on its way - although you should have this file already It's the modules from MSXIPKernel package, which are changing... OEMXIPKernel stay the same - unless you get a new kernel from somewhere.
Nevertheless, it will be available very soon.
inertiax3 said:
edit: Is it possible to also generate the other txt files which XIPPORT requires?
Click to expand...
Click to collapse
I'll try, after I'm done with those two other things

utak3r said:
Yeah, it's on its way - although you should have this file already It's the modules from MSXIPKernel package, which are changing... OEMXIPKernel stay the same - unless you get a new kernel from somewhere.
Nevertheless, it will be available very soon.
I'll try, after I'm done with those two other things
Click to expand...
Click to collapse
That's specifically my case.. a new NK.exe (specific for the device).. Thank you in advance!

DSM Dependency Dumper

UPDATED FILES!!! SEE POST #3
I have built a quick and dirty DSM Dependency Dumper ... It will dump dependencies from a ROM dump, or a single DSM file.
Simple to use:
1) Click 'Load Dump' or 'Load DSM' and select the Folder or File respectivly
2) Click 'Dump Deps' and select output file (output is CSV)
3) Click 'Dump PKGs' and select output file (output is CSV)
As you will find (well its what I found) ... NO ROM has the DSM dependencies correct! I have attached my analysis of Verizon's MR2 update for the HTC Titan. More dependencies are missing then are there!
What does all of this mean? I have no idea!!! Should we (I) work on correcting the dependencies in the DSM files? Want to see something interesting? Open the XLS file in the example.zip, Filter 'Package Name' on 'Entertainment', and you will see three (3) missing deps. Now drop that filter and filter 'Dep Package Name' on 'Entertainment', and you will see three (3) VALID deps ... 'Entertainment_Lang_0409', 'Entertainment_DPI_96', and 'Entertainment_Lang_0409_DPI_96'. Interesting.
Anyone have anything more? Can anyone find a ROM with 100% correct deps?

Hi friend;
.dsm can also contain an Interface GUID
Associations (dependencies) can be tied to this interface GUID as well,
This defines a 1-to-many relationship,
I suspect the "missing dependencies" you are talking about are really associations to the interface GUID..
These interface GUID's are used in the case of languages and DPI's, where multiple packages may satisfy a dependency (any langauge package, related to that common package, for example)

Da_G...
Thank you for your help ... You were dead on! I have updated my utility to export the Interface GUID as well, and found all of my "missing" dependencies!
I don't know if anyone cares, but I have attached the updated utility, as well as my analysis files.