Welcome to XDA

Search to go directly to your device's forum

Register an account

Unlock full posting privileges

Ask a question

No registration required
Post Reply

[KITCHEN] OS Builder V1.4.236 FULL (01.12.2012) - pro wm/wp7 kitchen by barin

OP HD2Owner

13th March 2012, 11:28 AM   |  #701  
tobbbie's Avatar
Senior Member
Flag Stuttgart
Thanks Meter: 240
 
1,408 posts
Join Date:Joined: Jan 2007
More
When dumping the ROM, it seems that the partitions are correctly identified and output to disk. No matter which way you do that step - how big is that XIP (2.bin for OS Builder here) file on your disk?

Speculations:
  1. you may have an Antivirus SW that blocks access to *.bin files: check if you can hex-read the output 2.bin file
  2. The author of the ROM may have manipulated the partition table for the ROM. Not sure if this has adverse effects on the funciton of the ROM (I guess no), but it would prevent dumping the ROM easily. It has usually the ULDR, the XIP and the IMGFS (eventually EXT). When dumping the os.nb, which are the sizes of these?
For sure you do not come to the real dump part of the actions yet. The XIP dump creates the ROM directory, while the IMGFS dump creates the OEM and SYS (and XCONT for what cannot be put there).


If any of the usual protection schemes are in the ROM (Farmer Ted has mentioned a few) you will not be able to re-cook anyway. There are some ways around the missing packages (recently I saw a tool here to re-create the packages, but never tried it out) but you cannot work around the missing .reloc sections if it applies to ALL modules.


Get to the author - really the best solution. Give him the credits he deserves if you publish a ROM based on his - naturally. My ROMs have a credit list that goes back to actions of 2007 - however I cook for real old stuff :)

Edit: Could you upload the .nbh somewhere (mediafire is a good place) - I could try to get it dumped and see what the problem is.
Last edited by tobbbie; 13th March 2012 at 11:30 AM.
13th March 2012, 03:06 PM   |  #702  
Senior Member
Thanks Meter: 89
 
2,371 posts
Join Date:Joined: Nov 2008
More
Quote:
Originally Posted by Digistras

How can I know weather is protected or not? Anyway to find out?

Look in the windows folder, and see if it has all the .dsm's and .rgu's. If there are only a couple of each, then they've been stripped out during the build, and you won't be able to recreate all of the packages in a dump.
14th March 2012, 02:00 PM   |  #703  
Digistras's Avatar
Member
Thanks Meter: 0
 
56 posts
Join Date:Joined: Dec 2010
More
Thanks for your reply tobbbie

Quote:

how big is that XIP (2.bin for OS Builder here) file on your disk?


The 2.bin file is 3.75MB in size. Illustration as shown:




Quote:

you may have an Antivirus SW that blocks access to *.bin files: check if you can hex-read the output 2.bin file


I used Xvi32 to to open 2.bin and was able to do so as shown below:




Quote:

The author of the ROM may have manipulated the partition table for the ROM. Not sure if this has adverse effects on the funciton of the ROM (I guess no), but it would prevent dumping the ROM easily. It has usually the ULDR, the XIP and the IMGFS (eventually EXT). When dumping the os.nb, which are the sizes of these?


Not sure what you mean by ULDR. Maybe you can explain it? When dumping os.nb, the dump did not complete as it encountered errors about the 2.bin file being in use which is the same error that I posted in my earlier post. I only managed to see 2.bin and XIP.bin after the error came out and both are 3.75MB in size.




Quote:

Edit: Could you upload the .nbh somewhere (mediafire is a good place) - I could try to get it dumped and see what the problem is.


Uploaded to MediaFire. Link as below:

http://www.mediafire.com/?u23aalme711hbvu
Last edited by Digistras; 14th March 2012 at 02:03 PM.
14th March 2012, 03:26 PM   |  #704  
tobbbie's Avatar
Senior Member
Flag Stuttgart
Thanks Meter: 240
 
1,408 posts
Join Date:Joined: Jan 2007
More
Sizes look reasonable, it seems OSB is doing something on 2.bin to create xip.bin or vice-versa before dumping the content. Is there a difference between these two?

The ULDR is not required for any cooking actions and can be ignored or even minimized or deleted in a final build. It was planned as part of a FW Update process over the air - or later automatic push installations. Afaik this was never used, though.

I can look after the .nbh only later today.


Mind that before OSB there were dedicated tools for all the steps of action:
- decrypt the .nbh
- dissect the resulting .nb in its parts (ULDR, XIP, IMGFS, others)
- dump the XIP
- dump the IMGFS
- build the packages from the dumps

So if OSB does not get further at step 2 - why not try others? It will be much more difficult though to set up the right kitchen structure then and as a newcomer you will most probably fail in that attempt.
If you could stay within the OSB workflow you have a chance - otherwise, good luck!

To get some basic idea about cooking, look in my signature and follow the link to the Beginners guide :)
14th March 2012, 04:19 PM   |  #705  
Digistras's Avatar
Member
Thanks Meter: 0
 
56 posts
Join Date:Joined: Dec 2010
More
I'm not sure if there is any difference between 2.bin and XIP.bin but both file size are the same though.

Thanks for taking the time to help me look at the .nbh. Hopefully it can tell you something.

I did try OsKitchen before coming to OS Builder. I believe OsKitchen is going through the same process.

I've taken a look at the Beginners Guide and kind of understand the architecture but will still need to read up more. Thanks for the guide.
15th March 2012, 10:17 AM   |  #706  
tobbbie's Avatar
Senior Member
Flag Stuttgart
Thanks Meter: 240
 
1,408 posts
Join Date:Joined: Jan 2007
More
I had the same problems in dumping the .nbh with OSB. It seems that not all exceptions are caught the right way and the resulting error message is misleading. I have decomposed the .nbh with DaG's nbimagetool and then dumped the imgfs with OSB. The resulting content is (as expected) free of any packages so you cannot re-cook this.
Added: you can see this yourself with the ROM loaded as the windows directory had no *.dsm and *.rgu files.

I have not further done anything to the XIP. ULDR is already only a dummy one (124k).
Please contact the author of the ROM if he is willing to share the kitchen with you.
15th March 2012, 02:23 PM   |  #707  
Digistras's Avatar
Member
Thanks Meter: 0
 
56 posts
Join Date:Joined: Dec 2010
More
Hey tobbbie

Thanks for helping me to confirm that the IMGFS is not able to be dumped.

I used ImgfsFromNb.exe to dump IMGFS and the generated output is 0 bytes.

How are the *.dsm and *.rgu files created?

Also, I saw this on your beginners guide:

"OEM parts stay usually unchanged through all cooking and porting activities, so that also means that a WM5 device will keep all the OEM parts even if the OS version is WM6.5. OEM parts are in both, the XIP (nk.exe and some OEM modules) and the IMGFS. You will especially not gain any advantage of the enhanced memory allocation scheme if your device does not have a native 6.5 kernel (nk.exe)."

Does it mean that I can just use the IMGFS and XIP of official ROM (WM 6.5) and use it on this cooked ROM (WM 6.5.5)?

I also saw this: http://forum.xda-developers.com/show...320504&page=49

but I'm missing the buildos+packagetools2.0b1.exe (link dead) as it contains 319'880 buildos+package_tools-2.0b1.exe. Not sure if that method works though.

Do you happen to have it?
15th March 2012, 02:38 PM   |  #708  
tobbbie's Avatar
Senior Member
Flag Stuttgart
Thanks Meter: 240
 
1,408 posts
Join Date:Joined: Jan 2007
More
Quote:
Originally Posted by Digistras

How are the *.dsm and *.rgu files created?

The are not created, they are there from the start. A package is defined by a set of files and related production configuration files - the dsm and rgu. The DSM (Device Side Manifest) are used to set properties of the files/modules when the IMGFS is constructed and the RGU (Registry Update) are used to update the registry with relevant settings. Each package has a unique GUID identifying it.
The DSM and RGU are not needed on the device but they are mandatory if you want to go back and re-cook. No way to recover this with a sane outlook to success. Hence stripping these in the cooking process "protects" the ROM.

Quote:
Originally Posted by Digistras


Does it mean that I can just use the IMGFS and XIP of official ROM (WM 6.5) and use it on this cooked ROM (WM 6.5.5)?

This is the basic idea. You have the OEM parts of your device and replace the XIP and SYS with that of a "donor". It is however not simple copy as several hooks need to link together in the right way. OS Builder has dedicated supporting tools and procedures for XIP and SYS porting.

Quote:
Originally Posted by Digistras

Do you happen to have it?

No, sorry.

Sad for you is that you cannot use the ROM in question as your base. If you want to start cooking, get your shipped ROM, dump it and try to re-cook it. If you get that mastered, then you can think of XIP and SYS porting.
15th March 2012, 08:23 PM   |  #709  
Digistras's Avatar
Member
Thanks Meter: 0
 
56 posts
Join Date:Joined: Dec 2010
More
I've dump the .nbh using DaG's nbimagetool and then using the same tool to dump os.nb which then IMGFS can be seen and is 127MB in size.

Below are the steps that I have done:

1. Dumped .nbh using DaG's nbimagetool.



2. Used DaG's nbimagetool again to dump os.nb and imgfs.bin and xip.bin was extracted. File sizes are as shown:




3. Dump imgfs.bin using ImgfsToDump.exe (with cecompr_nt.dll). I followed the instructions and tools from http://wiki.allshadow.com/index.php/...ng_to_ROM_dump




As you can see that after dumping the imgfs.bin, a dump folder and memory map is created.

So from here, is there anyway that I can package the dump folder to create a .nbh with the proper imgfs.bin and xip.bin so that OsKitchen is able to load? Not sure if I'm on to something here though.
Last edited by Digistras; 15th March 2012 at 08:29 PM.
15th March 2012, 11:48 PM   |  #710  
tobbbie's Avatar
Senior Member
Flag Stuttgart
Thanks Meter: 240
 
1,408 posts
Join Date:Joined: Jan 2007
More
Why do you want to continue here? The IMGFS (and the XIP most probably as well) does not have package information left. You cannot alter anything of the content in the way any kitchen works.

Stop with this protected ROM and pick up your actions with a shipped ROM where the packages are still intact or with a kitchen of that ROM where the packages are still there.

There is no magic or other tooling that will bring you back the packages. There is also no other kitchen that can do anything with this ROM.

Post Reply Subscribe to Thread
Previous Thread Next Thread
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes