Related
Spent a lot of time on it, trying to figure out what went wrong with mkrom when cooking 4.00.xx roms. finally figured it, well, almostly. here is a short step by step tutorial for people who do not want to set up the complicated kitchen but wish to use mkrom as in the good old 3.17 time.
I assume you already know the rom flush process already, if given a NBF file. also you need a linux box with perl.
I know quite a few people struggled and have not had a clue. and I believe there is some bugs in the mkrom package that gives the trouble.
1. download the newest mkrom from http://xda-developers.com/~itsme/download/mkrom_136.zip. this is the only piece of software you would need.
2. unpack it to, say mkrom, directory. then make directories cfg
3. get hold of a copy of rom file and its corresponding paramter files. the parameter files can be obtained from the demo kitch download ftp://kitchen:[email protected]/data look inside the "00_base ROM" and the parameter files should be under cfg directory of each rom directory. bascially the parameter files tells mkrom, where to start to put added files and how large space there is. there are two blocks of space that can be used. so the file has format
wincever=4
start1=81740000
size1=00040000
start2=81b00000
size2=003c0000
startbmp=81ec0000
startop=81b00000
the first three lines are same for all 4.00.xx roms, start2 varies for different roms, startbmp is also the same for all roms. startop should be the same as start2. size2 will be startbmp-start2, remember they are all in hex. you can calculate how large space there is once you get hold of the start2 parameter.
anyway, put the parameter files under the mkrom/cfg directory, with name "params"
4. copy a rom file (.nbf), say rom.nbf, into mkrom directory and run "./setup rom.nbf". this will creates several files under cfg.
5. mkdir a directory mkrom/romfile, enter it and make another directory file , then type "../dumprom ../cfg/rom.nb1 -4 -d file"
here comes the first bug. the setup.sh tells you that dumprom can only be used in windows box. but in fact, there is a compiled dumprom for linux in the directory (you might need to set it to be executable though). however, this linux version does not put extracted files into the "file" directory as it is supposed to, instead it just write file as "file\xxx" where xxx is the actual file name extracted from rom. it is a bug but as long as we know it, not a big deal. the is someone posted a correct version of dumprom in this forum though.
6. you should be able to find three files (or with the "file\" prefix added) with name default.fdf initobj.dat initdb.ini. these are the three files that needs to be process as indicated by setup.sh. follow the instruction to create the default.reg initobj.txt initdb.ini and copy them to cfg directory.
7. make a directory mkdir/files. you are ready to create a clean rom now by running "./mkrom output.nbf", the created output.nbf should be fine.
So far so good, followed the instruction of mkrom. next would need to add our files. then comes the problem. if you add files into the mkrom/files directory, and run "./mkrom output.nbf" again, it is almost definitely that the created rom is bad. I am not 100% sure why, but here is what I believe:
the mkrom script scan files in the "files" directory and put files in there into the "files1", "files2" directory, each of them is supposed to fill the two space in rom starting from "start1" and "start2" in parameter file. the size of files under "file1" should be less than "size1", similar "files2" and 'size2". when mkrom does this, it is highly possible that the three critial files "default.fdf, initobj.dat, initdb.ini" are placed into "files2" directory instead of "files1" directory and renders the rom bad.
here is what I did
edit the mkrom.sh, delete the line that splits files in "files" into "files1, files2" directory. change the three lines that convert the three critial files so that these three files are created in "files1" directory instead of "files" directory. then put your files into "files1" and "files2". just be careful, keep the size less than specified by "size1" and "size2".
then you can run "./mkrom.sh output.nbf" as before, and the resulted rom will be good.
hope this helps. however still a couple of problems
1. the fdf2reg.pl won't recoganize the default.fdf extracted from 4.00.21 rom or 4.01.00 rom
2. if i change the content of initobj.txt, the created rom won't boot. I might have done something wrong in initobj.txt though. but I used to be able to do this for 3.17 rom
3. I did not try to modify registry, as my only purpose is to put my files into ROM to save space. all registry can be done later by installing the software and choose not to overwrite existing files in ROM. must simpler.
the unix version of dumprom does not decompress files, that is why your default.fdf etc seem corrupted.
this is because I only have the decompression code in the form of a binary library, which I have not figured out how to link to under linux.
the only use of dumprom under unix is to find the offsets in rom where filepointers to default.fdf etc should be patched.
I should maybe disable the '-f' option in dumprom for the unix version, to make things less confusing.
but it looks to me that the dumprom under linux worked for pre- 4.00.16 rom. only not for after 4.00.21 roms. so are they different?
maybe the default.fdf was not compressed in the 3.x roms?
I am quite sure it does not work for compressed files under linux - I just did not implement the compression routines.
dumprom worked with 4.00.05 4.00.11 4.00.16 roms. I cooked 4.00.11 and 4.00.16 roms, and the rom was fine. I never used windows box during the process. only when i tried 4.00.21 and 4.01.00, there was error. anyway, i don't care, since I need as much rom as possible and 4.00.11 seems to be the best choice for me.
thanks for writting mkrom, a terrific tool. I don't like the way xda-developers.com promoting kitchen but not mkrom. mkrom is much simpler to setup and run, as long as you know about linux. the kitchen is much more complicated to get it to work and most people don't actually need such flexibility I believe.
ok i installed cygiwin and was with u till step 5, then i am lost.. when i run step 6 dumprom (in DOS) gives me an ewrror here atr the first few lines from dumprom( wiht latest ATT official release)
img 00000000 : hdr=8c0a1000 base=8c078000 commandlineoffset=8c077fe0
img 00040000 : hdr=800cdde0 base=80000000 commandlineoffset=7fffffe0
img 00180000 : hdr=8024db88 base=80000000 commandlineoffset=7fffffe0
img 00380000 : hdr=8039b334 base=80000000 commandlineoffset=7fffffe0
img 00670000 : hdr=80be2c40 base=80000000 commandlineoffset=7fffffe0
img 00c00000 : hdr=80e99400 base=80000000 commandlineoffset=7fffffe0
img 01050000 : hdr=813efc74 base=80000000 commandlineoffset=7fffffe0
img 01400000 : hdr=815d2ba4 base=80000000 commandlineoffset=7fffffe0
img 015f0000 : hdr=815f0650 base=80000000 commandlineoffset=7fffffe0
img 017c0000 : hdr=81bba0a4 base=80000000 commandlineoffset=7fffffe0
ERROR: could not find pointer for ofs 8c0a1000
invalid romhdr ofs 8c0a1000
ERROR: could not find pointer for ofs 00000000
7fffffe0 - 80000000 L00000020 unknown 30315750 452d3142 412d474e 2d30332e 2d353030 62373239 2d2d2d2d 2d2d2d2d
80000000 - 80000004 L00000004 romsection id=ea0003fe
80000004 - 80000040 L0000003c NUL
80000040 - 80000048 L00000008 'ECEC' -> 8c0a1000
errorsgalore...
so help me here how do i make sure the files extracted are all good also the size (as per ) windows explorer is 33+ not sure how all has been installed in the 32mb rom
did you get default.fdf initobj.dat initdb.ini out of dumprom. dumprom also reported tons of errors but as long as you get the three files out, it is ok.
Dumprom tries to figure out for each byte in the rom what it does. If it doesn't know it says 'unknown' this is not an error, just that dumprom could not determine the use of this byte. The 'could not find 00000000' message means that it encountered a NULL pointer somewhere in rom where it did not expect it, the other one is a pointer to RAM, which dumprom does not know exists. You can safely ignore these errors.
Dumprom was initially written to assist in figuring out what I did not know about the rom, so it tries to figure out stuff that is unknown. Later I added the code to extract files to it. Maybe I should split dumprom in one research tool, to do a detail examination of the rom, and one tool to only extract files.
Most files in rom are compressed, that is why they are more than 33M when uncompressed.
ok i understande the messages...
now here is what i did
ran ssnap and got a picture of the OS and did a compare and have a list of entries i want to add to registru and a folder with bunch of subfolders that need to be added on install
not sure how step 6 goes.. to convert the files to .reg and .txt and how/where do i add my files and registry entries....
any tips...
update...
i did fdf2reg and made a .reg file added my entries in there and then ran reg2fdf to recreatre the fdf...
i hope this is right now i need to fig out how to specify where the files i want added are to be copied i mean some go into windows some in new filders that need to be created...
plz tell me how to go forward.
you don't need to re-create the fdf file again, mkrom does it for you, you only need to take care of the default.reg file under cfg
I am not sure whether you can put files under directories other than \windows only. I did not try that. I suppose all files under /files1 and /files2 go to \windows directory just they happen to locate in different memory location in ROM
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).
Chinese Edition: http://www.coolcode.cn/andot/bin2nb-nb2bin-released/277
Hello, everyone. I find there is no tools can convert bin file to nb file or convert nb file to bin file. so I made these tools: bin2nb & nb2bin. They only can convert os.bin to os.nb, and os.nb os.bin, they can't convert gsm, spl or ipl nb file to bin file.
They are all command line tools, and easy to use.
if you want to convert os.bin to os.nb, you can type:
Code:
bin2nb os.bin os.nb
and then, you will get os.nb file.
when you want to convert os.nb to os.bin, you can type:
Code:
nb2bin os.nb os.bin
you will get the new os.bin file.
The default setting is Typhoon(Feeler/Amadeus), if you want to convert other device nb file to bin file, you can add two parameters:
Code:
nb2bin <file.nb> <file.bin> [offset] [partbytes]
offset is a hex number without prefix, for example, the offset of Typhoon is 80240000.
partbytes is the size of the partition, it is also a hex number without prefix, for example, the partbytes of Typhoon is 1b00000.
Excuse me,
I've a Toshiba G900, I've used the Grab_it tool to create a DUMP of the ROM.
I obtained a "dump.bin" file.
Now I've to create a .nb file from this .bin file.
Do you thing your tool could works?
I've to imput a different code becouse my device is not a Typhoon?
I hope you can help me.
Thanks.
davideuck,
Have you solve your problème? Because i have the same and bin2nb doesn't work for me (My device is a Samsung Player Addict)
Thank,
McCoy.
it doesn't support diamond NB files.... anyway, thanks
I'm looking for information on the format of Hermes nb files. I am aware that there are perl scripts to unpack these files, but they are not working on a diagnostic image i have in nbh and (converted to) nb format. When I try to unpack the nb file with rdmsflsh.pl I get: could not find imgfs header
The file has plaintext readable strings and begins with 0xB000FF.
Does anyone have technical information on this file format? I know the file is valid since it can boot into the image just fine.
-fluxist
fluxist said:
I'm looking for information on the format of Hermes nb files. I am aware that there are perl scripts to unpack these files, but they are not working on a diagnostic image i have in nbh and (converted to) nb format. When I try to unpack the nb file with rdmsflsh.pl I get: could not find imgfs header
The file has plaintext readable strings and begins with 0xB000FF.
Does anyone have technical information on this file format? I know the file is valid since it can boot into the image just fine.
-fluxist
Click to expand...
Click to collapse
There is a lot of good information about the NBH format (here) that may be useful. Also, the wiki in general may be helpful.
Hey Guys!
How can i Build a cab for my programs in vs2005 or have i to use another tool to do this?
thanks SciLor
WinCe cab manager does the job.
its not free though.
but its worth it
isnt there another tool i can use?
look in the Visual studio's help file on making an installer..i cant remember now but i did create a cab once..btw which version of VS do u use
This is from My VS 2008 Pro Documentation
This section describes creating CAB files for distributing ATL and MFC controls over the Internet. If you need more information about CAB files, see the Cabinet File Reference in the Windows SDK documentation (in MSDN Library/Setup and System Administration/Setup/Setup API/Overview/Cabinet Files).
To create a CAB file:
Create an INF file.
Run the CABARC utility.
Creating an INF File
The INF file is a text file that specifies the files (such as DLLs or other OCXs) that need to be present or downloaded for your control to run. An INF file allows you to bundle all the needed files in one compressed CAB file. By default, files with the same version numbers as existing files on the user's hard disk will not be downloaded. For more information about INF files and their options, including how to create platform-independent INF files, see About INF Files and Using INF Files in the Windows SDK documentation (in MSDN Library/Setup and System Administration/Setup/Setup API/Overview/Setup Applications).
As an example, the following INF will be used to create a CAB file for the ATL Polygon control. You can build POLYGON.DLL by downloading the ATL POLYGON sample files from the Visual C++ CD and building a MinSize version. If you build a MinSize version of the Polygon control, you need one additional DLL, ATL.DLL. Since ATL.DLL needs to be registered before POLYGON.DLL, put the ATL.DLL first in the INF file:
Copy Code
; Sample INF file for POLYGON.DLL
[version]
; version signature (same for both NT and Win95) do not remove
signature="$CHICAGO$"
AdvancedINF=2.0
[Add.Code]
polygon.dll=polygon.dll
atl.dll=atl.dll
; needed DLL
[atl.dll]
file-win32-x86=thiscab
FileVersion=2,00,0,7024
DestDir=11
RegisterServer=yes
[polygon.dll]
file-win32-x86=thiscab
clsid={4CBBC676-507F-11D0-B98B-000000000000}
FileVersion=1,0,0,1
RegisterServer=yes
; end of INF file
This INF specifies that ATL.DLL with the given version needs to be installed on the system. If ATL.DLL doesn't exist already on the system, it will be downloaded from the CAB file created with this INF. "thiscab" is a keyword meaning the CAB containing this INF. You can also download a needed DLL from an HTTP location by specifying an absolute or relative path, for example:
Copy Code
file-win32-x86=http://example.microsoft.com/mydir/NEEDED.DLL
The keyword "file-win32-x86" identifies the platform as x86 specific.
You can get the version number of a file by clicking the right mouse button on the file in Windows Explorer. Select Properties from the list that appears, then select the Version tab on the dialog box that appears. You will sometimes need to insert an extra 0 in the file version. For example, the version number for the ATL.DLL is shown as 2.00.7024 in the dialog box. This becomes 2, 00, 0, 7024 in the INF file.
The "DestDir" is where the directory where the file will be loaded: 11 specifies the system directory WINDOWS/SYSTEM or WINNT/SYSTEM32; 10 specifies the windows directory, WINDOWS or WINNT. If no DestDir is specified (typical case), code is installed in the fixed OCCACHE directory.
The "clsid" is the CLSID of the control to be installed.
Once you have created an INF file, run the CABARC utility (available in the Mssdk\Bin directory) to create the CAB file. You should run CABARC in the directory that contains your source files. On the command line, put the source files in the order they appear in the INF and the INF file last. For example, to make a CAB file for the Polygon control from the INF above, use the following command:
Copy Code
C:\MSSDK\BIN\CABARC -s 6144 POLYGON.CAB ATL.DLL POLYGON.DLL POLYGON.INF
The POLYGON.CAB file contains a compressed version of ATL.DLL and POLYGON.DLL along with the information needed to extract them in the POLYGON.INF file.
For an example of how to parse and extract component files from CAB files, see the CabView sample in the MSDN Online Code Center at http://msdn.microsoft.com/visualc/downloads/samples.asp (select the CabView link).
The DLL files you need to include with an MFC control are MSVCRT.DLL, MFC42.DLL, and OLEPRO32.DLL.
Running the CABARC Utility
The CABARC utility is available in the Mssdk\Bin directory. For example:
Copy Code
C:\MSSDK\BIN\CABARC -s 6144 n MYCTL.CAB NEEDED1.DLL NEEDED2.DLL MYCTL.OCX MYCTL.INF
CABARC creates a CAB file called MYCTL.CAB.
You should run CABARC in the directory that contains your source files (the INF, OCX, and DLL files). The files to be archived in the CAB file should be listed on the command line in the same order they are listed in the INF file. In the example above, the INF file should list NEEDED1.DLL first, then NEEDED2.DLL, and then MYCTL.OCX.
The -s option reserves space in the cabinet for code signing. The n command specifies that you want to create a CAB file. For a list of CABARC commands and options, type CABARC alone on the command line:
Copy Code
C:\MSSDK\BIN\CABARC
Click to expand...
Click to collapse
I found an older version of this online:
http://www.aperitto.com/content/view/14/159/
I have version 2.0 and it works great without registering the copy. Look into it
I can't find the original setup I used... sorry, I will keep looking... but I've heard good things about SPB's installatation creator
http://www.spbsoftwarehouse.com/products/ezsetup/index.html?en
It is easy with VS 2008 there you can create a CAB Builder