FORUMS

[REF] Investigation Into PIT Files

2,023 posts
Thanks Meter: 780
 
By RyanZA, Senior Member on 22nd October 2010, 10:00 PM
Post Reply Email Thread
There is very little technical information on PIT files , so this thread is an attempt to find out some real details about PIT files, and perhaps eventually be able to create our own PIT files (by modifying Samsung ones, probably).

First, what we think we know PIT files do:

- PIT files only affect the 'STL' devices. That is, it affects the OneNAND and not the MoviNAND.
- PIT files appear to control the sizing (and maybe number) of STL devices that appear in Linux.
- PIT files appear to be used by Odin to map filenames inside .tar archives to STL partitions.


STL files are quite small, at under 2KB in size. Most of the file is made up of 0s. I have tried to compare the differences between the 512 513 and 803 PIT files we have available.

All the PIT files start with 76 98 34 12 0D - probably a signature to show it is a PIT file.

[Unimportant]

The 803 PIT file then has 00s all the way to the next common point. The 512 and 513 both have common data till the next common point - but this can't be too important as the 803 just has 00s.

The next common bit seems to read the following:
"oft IBL+PBL Server\90\To boot.bin inn; C:\Program Files\ESTsof
This probably indicates something to Odin. Strange that it has C:\Program Files\ - build path for the PIT file?

Next we have some 0s with common 1s inside them, followed by the word PIT, then more 0s, and then ries.pit. All common from here on with the words 'EFS' and 'efs.rfs'. Probably telling odin to map the efs.rfs file to the 'EFS' token. Tokens probably defined either in the kernel, or in the closed source STL library. More of the same of this, with 'SBL' 'sbl.bin', 'SBL2' 'sbl.bin' -- Both SBL and SBL2 map to the same sbl.bin file?

'PARAM' to 'param.lfs'
'KERNEL' to 'zImage'
'RECOVERY' to 'zImage' (this one is interesting - could we have seperate zImage and recovery? Could save some RAM here!)

[/Unimportant]

And now we'r onto the actual changes between the PIT files. 'FACTORYFS' maps to 'factoryfs.rfs'. However, before the FACTORYFS token, there are some bytes that likely control the partition sizes.

FACTORYFS
803 : A2 04 : 41476
512 : 7A 04 : 31236
513 : CA 04 : 51716

DBDATA
803 : F0 01 : 61441
512 : 18 02 : 6146
513 : C8 01 : 51201

CACHE
803 : 8C
512 : 8C
513 : 8C

MODEM
803 : 32
512 : 32
513 : 32

So there we have it. The only real changes between the PIT files are some seemingly garbage header information in 512/513 that is missing from 803, and FACTORYFS and DBDATA have different numbers -- probably sizes.

So assuming FACTORYFS maps onto /system, we can see that the only differences in the PIT files is moving space back and forwards between /dbdata and /system. The numbers themselves don't mean anything to me - can anybody work it out?
The Following User Says Thank You to RyanZA For This Useful Post: [ View ] Gift RyanZA Ad-Free
22nd October 2010, 10:06 PM |#2  
sztupy's Avatar
Inactive Recognized Developer
Flag London
Thanks Meter: 879
 
Donate to Me
More
The numbers are little-endian, so you need to read them backwards per bytes. So instead of A12 it's actually 120A, etc. If you do so, you can see that the difference between 803 and 512 are actually minor, 40 "units" are shifted between probably DBDATA and SYSTEM.

Btw: doesn't the heimdal project klnow something about the pit files?
22nd October 2010, 10:12 PM |#3  
OP Senior Member
Flag JHB
Thanks Meter: 780
 
More
Nice, that gives us

FACTORYFS
803 : 04 A2 : 1186
512 : 04 7A : 1146
513 : 04 CA : 1226

DBDATA
803 : 01 F0 : 496
512 : 02 18 : 536
513 : 01 C8 : 456

1186+496=1682
1146+536=1682
1226+456=1682

So we have a match.
Now to work out why the fat.format can work with 536, but not with 496

EDIT: Also, need to determine why some roms require certain PIT files. Only possibility I can see is that junk in the header - could be some type of allow list for firmwares. The 803 PIT should therefore work on all firmwares, since it just has 00s. Maybe.
22nd October 2010, 10:27 PM |#4  
Senior Member
Thanks Meter: 78
 
Donate to Me
More
In 803.pit (compared to the .512 one) the system partition size has been increased by 10MB, while DBDATA partition size has been decreased the same amount (10MB).

PS: Dump the BML2 partition. The dump contains current partition mapping.

Hope this helps
22nd October 2010, 10:27 PM |#5  
sztupy's Avatar
Inactive Recognized Developer
Flag London
Thanks Meter: 879
 
Donate to Me
More
Quote:
Originally Posted by RyanZA

Nice, that gives us

FACTORYFS
803 : 04 A2 : 1186
512 : 04 7A : 1146
513 : 04 CA : 1226

DBDATA
803 : 01 F0 : 496
512 : 02 18 : 536
513 : 01 C8 : 456

1186+496=1682
1146+536=1682
1226+456=1682

So we have a match.
Now to work out why the fat.format can work with 536, but not with 496

EDIT: Also, need to determine why some roms require certain PIT files. Only possibility I can see is that junk in the header - could be some type of allow list for firmwares. The 803 PIT should therefore work on all firmwares, since it just has 00s. Maybe.

I think the main cause is that some firmwares simply don't fit in the space reserved for them. Some of the m have larger system, some of them have larger dbdata partitions. Only a guess though, I think I start flashing pit files just for fun...
The Following User Says Thank You to sztupy For This Useful Post: [ View ] Gift sztupy Ad-Free
22nd October 2010, 10:29 PM |#6  
sztupy's Avatar
Inactive Recognized Developer
Flag London
Thanks Meter: 879
 
Donate to Me
More
Quote:
Originally Posted by RazvanG

In 803.pit (compared to the .512 one) the system partition size has been increased by 10MB, while DBDATA partition size has been decreased the same amount (10MB).

Hope this helps

10MB = 40 units... That would give us 1 unit = 256kbyte. Nice.
The Following User Says Thank You to sztupy For This Useful Post: [ View ] Gift sztupy Ad-Free
22nd October 2010, 10:47 PM |#7  
sztupy's Avatar
Inactive Recognized Developer
Flag London
Thanks Meter: 879
 
Donate to Me
More
So this means:

BOOT (bml01) = 01 = 1 = 0.25 MB (bootloader)
PIT (bml02) = 01 = 1 = 0,25 MB (the partition table)
EFS (bml03) = 28 = 40 = 10 MB (imei data and such)
SBL (bml04) = 05 = 5 = 1,25 MB (secondary bootloader)
SBL2 (bml05) = 05 = 5 = 1,25 MB (secondary bootloader backup)
PARAM (bml06) = 14 = 20 = 5 MB (the images shown when something is wrong)
KERNEL (bml07) = 1E = 30 = 7,5 MB (kernel image)
RECOVERY (bml08) = 1E = 30 = 7,5 MB (kernel image backup)
FACTORYFS (bml09) = 47A = 1146 = 286,5 MB (/system)
DBDATA (bml10) = 218 = 536 = 134 MB (/dbdata)
CACHE (bml11) = 8C = 140 = 35 MB (/cache)
MODEM (bml12) = 32 = 50 = 12,5 MB (software for wireless)

total: 501 MB
The Following User Says Thank You to sztupy For This Useful Post: [ View ] Gift sztupy Ad-Free
22nd October 2010, 10:51 PM |#8  
OP Senior Member
Flag JHB
Thanks Meter: 780
 
More
Quote:
Originally Posted by sztupy

I think the main cause is that some firmwares simply don't fit in the space reserved for them. Some of the m have larger system, some of them have larger dbdata partitions. Only a guess though, I think I start flashing pit files just for fun...

Not sure how true this can be -- Take 512 vs 513 for example. Newer Eclair roms stopped working on 513, and required 512. However, 513 has a smaller dbdata and larger system than 512. Since we know that a clean rom when flashed has a /dbdata of around 2mb, or 1% or so of available space, it can't be space related.

Must be more to than simple space allocations.

EDIT: And 501MB means we have space left over. Where is it hiding?
22nd October 2010, 11:04 PM |#9  
sztupy's Avatar
Inactive Recognized Developer
Flag London
Thanks Meter: 879
 
Donate to Me
More
Quote:
Originally Posted by RyanZA

Not sure how true this can be -- Take 512 vs 513 for example. Newer Eclair roms stopped working on 513, and required 512. However, 513 has a smaller dbdata and larger system than 512. Since we know that a clean rom when flashed has a /dbdata of around 2mb, or 1% or so of available space, it can't be space related.

Must be more to than simple space allocations.

EDIT: And 501MB means we have space left over. Where is it hiding?

Yes, but the flashed dbdata.rfs was probably actually a large partition, that didn't fit into the allocated space.

Yes, the missing 11MB is strange, unless there is a 1MB "safety" gap between two partition (12 partitions = 11 gaps), or some other data.

EDIT: No, dumped BML0, it's only 501MB in length. The missing part might still be some space needed for the BML and STL to work.
22nd October 2010, 11:47 PM |#10  
Member
Thanks Meter: 1
 
More
Hi. I'm sorry for hijacking this thread but I need professional help from some geniuses (genii) and apparently you guys are firmware gurus.
Once you guys figure out how PIT files work, can you please help me figure out how to force flash Korean firmware onto an international phone without bricking it? The reason why I would like to do this, is because the Korean version has some really nice features for example native call recording (3rd party call recorders have bad quality). I made a thread for it here

Thanks a lot, köszönöm szépen!
23rd October 2010, 01:17 AM |#11  
Senior Member
In the land of the blind
Thanks Meter: 78
 
More
Galaxy S I9000 PIT structure:

512.pit

PBL: 256KB (Primitive Bootloader)
PIT: 256KB
EFS: 10240KB (Non Volatile Memory)
SBL(1): 1280KB (Primary)
SBL(2): 1280KB (Backup)
PARAM: 5120KB
KERNEL(1): 7680KB (Primary)
KERNEL(2): 7680KB (Backup)
FACTORYFS: 293376KB
DBDATAFS: 137216KB
CACHE: 35840KB
MODEM: 12800KB

Total: 513024KB

513.pit

PBL: 256KB
PIT: 256KB
EFS: 10240KB
SBL(1): 1280KB
SBL(2): 1280KB
PARAM: 5120KB
KERNEL(1): 7680KB
KERNEL(2): 7680KB
FACTORYFS: 313856KB
DBDATAFS: 116736KB
CACHE: 35840KB
MODEM: 12800KB

Total: 513024KB

803.pit

PBL: 256KB
PIT: 256KB
EFS: 10240KB
SBL(1): 1280KB
SBL(2): 1280KB
PARAM: 5120KB
KERNEL(1): 7680KB
KERNEL(2): 7680KB
FACTORYFS: 303616KB
DBDATAFS: 126976KB
CACHE: 35840KB
MODEM: 12800KB

Total: 513024KB

In case there is backup blocks (e.g SBL and Kernel, Odin flashes them both while executing the flashing process).
Post Reply Subscribe to Thread

Guest Quick Reply (no urls or BBcode)
Message:
Previous Thread Next Thread
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes