Some Bf3 File Info For Modding

[Mach10]

Thought I'd post some info for the current state of BF3 modding and opening files.

.toc are fairly simple, they're metadata structure format (shared with other files) that have a basic id/offset/size in two sections, bundles, and chunks.

bundles have string id/int64 offset/int64 size, and point to their respective locations in the .sb file.

chunks have hash id/int64 offset/int32 size (hash = uint8[16], md5?), and also point to their respective locations in the .sb file.

chunks seem to have varying data types (image data, etc), bundles seem to be a more complicated archive format (with actual compression).

-Rick from Xentax

New obfuscation on .toc is extremely simple.

If the first dword is 0x00CED100 (D1CE) then the file is obfuscated, otherwise it's normal.

Magic data starts at 0x128 and is 257 bytes.

Real data starts at 0x22C until end of file.

for (int i = 0; i < length; i++)
{
data[i] = data[i] ^ magic[i % 257] ^ 0x7B;
}

-Rick from Xentax

Files have been extracted to date.. just updating the news.

[Frankelstner]

Thought I'd post some info for the current state of BF3 modding and opening files.

Files have been extracted to date.. just updating the news.

Here is the current state: Extracting the sb files is not too hard once you get rid of the XOR encryption, here's my take on toc files:

toc fileformat

82 *filelength* 01bundles00 *bundlelength*

while bundles exist:
 82 *lengthoffile* 07id00 *pathlength* *actualpathstring*00 09offset00 *offset8bytes* 09size00 *size8bytes* 00
another 00 after the last bundle (even if no bundles exist)
offset: offset right after bundlelength bytes + bundlelength

01chunks00  *chunklength*
while chunks exist:
 82 *lengthoffile* 0fid00 *id16bytes* 09offset00 *offset8bytes* 09size00 *size8bytes* 00
another 00 after last chunk (even if no chunks exist)
offset: offset right after chunklength bytes + chunklength

another 00 at end of file
offset: offset right after filelength bytes + filelength  (= end of file)



the byte prefix for offset and size goes like this:
08 means 4 bytes, 09 means 8 bytes, 0f means 16 bytes and 07 might mean 0 or 1 bytes

numbers work in a 128 little endian system, if first bit 1 => read next byte too, else this is the last byte (same as dbx files)

It is kind of dull though because then you end up with

1) bundle files which are archives again, this time far more complicated

2) several thousand chunk files which have no name but merely an 16byte ID/hash and might be either compressed, encrypted or simply resource files

I've made some progress with bundle files, but I don't fully understand them yet.

bundle files:

0-3: unknown, last half byte is C
4-7: 970D1C13
08-0b number of 20byte IDs => offset for numbering: bytes in big endian * 0x14  +0x24 = absolute offset
0c-0f: number of uncompressed files
10-13: number of compressed files
14-17: number of prechunks (i.e. specified before chunkmeta, they have another 16byte ID there in addition to the 20byte ID)
18-1b: offset for file paths: bytes in big endian +4 = absolute offset
1c-1f: offset for 01chunkmeta before paths (null if it does not exist): bytes in big endian +4 = absolute offset
20-23: difference of the two offsets before (if both exist, else null)

number of 20byte IDs = number of uncompressed + compressed + prechunks (thus everything has a 20byte ID)


while IDs exist:
20byte IDs

while uncompressed or compressed exist:
#NUMBERING, NO PRECHUNKS
three 4byte parts
1. 4bytes: relative offset of path string
2. 4bytes: file length in archive
3. 4bytes: how large the file might be when extracted?


now different prefixes for the compressed type (might be the file extension?):
Q..S => the actual file starts with (examples from mp_subway_gameconfiglight_win32.bundle from MP_Subway.sb in the beta files)

000100000000952C 78DA DC7 D0
0001000000003238 78DA B5D D0
0001000000001C2B 78DA DD3 D0
and can be large files


\IT. => actual file starts with

000000800000003 E 78DAE3628000 2 E28CDC0 C2C0C2C8C008 643032CC33890EB8B0A05FE2C3E167C147458A8E33300830900F0418942B8C56BAA4A62596E694C0450168FD0D0D
000000800000003 E 78DAE3628000 2 E28CDC0 C4C0C4C8C008 6430323C33DB763464494FE8A6768EDC5F6BBDE63330B030900F58189C97C91ABAA4A62596E694C045016DDA0CCE
000000800000003 9 78DAE3628000 4 E28DDC0 C008 860C40EC5EB82BA5ECDAD97D021D0205E6F9AB63199818C80740BD164CDA375C52D3124B734AE0C20031B40C11
000000800000003 E 78DAE3628000 2 E28CDC0 C4C0C4C8C008 643032F417F02E95CFE4EF78F15EB43D7089C85206061606F2010B834DB5DE7297D4B4C4D29C12B82800CE410B66
000000800000003 A 78DAE3628000 2 E28CDC0 C8C008 4460C6CC6DF7670AF39DDF5A77A0B464E1FBAAD30C60717201238328E7123D97D4B4C4D29C12B82800A49A0D39
000000800000003 5 78DAE3628000 2 E28ED00 848C40 C800C4899F55A7B12C0C987B8E57647281F5EFFD0C020CE403A05EEB156B78423D51850126E10A79
000000800000003 F 78DAE3628000 2 E28CDC0 C4C0C4C8C008 643032BC9D1AA5F3FDD793FEDB61B9B7A69A2F8C66606061201FB0309CD2997CC625352DB134A7042E0A00E12F0EEA
000000800000003 C 78DAE3628000 4 E28CDC0 D8C0C008 84400643F8C5EE9A46A76C817DE2BAAEF55685F90C0C4C0CE4032686E5973BF6B8A4A62596E694C04501E4D20C6C



lots of nullbytes after the prefixes; many prefixes result in many nullbytes, but the exact rule does not seem to be that simple



while prechunks exist:
#PRECHUNKS
16byte ID
three 4byte parts
1. 4bytes: usually null
2. 4bytes: file length in archive
3. 4bytes: usually null


#CHUNKS
01 chunkMeta 00 *length till begin of path strings (little endian 128)*

usually (sometimes it is not 821208):
while (pre)chunks exist (I think this is still related to prechunks actually; either that or files with \IT. prefix):
821208 h32 00
4bytes (another ID?)
02 meta 00 01 00 00



while path strings exist:
path strings with 00 at the end


while uncompressed files exist:
uncompressed files, the file length specified always seems to be multiples of 16 so there is no padding required

while compressed files exist:
compressed files, the files might end anywhere, padding with nullbytes till multiple of 16 (so that the next file always starts at the very left if your hex editor shows 0x10 bytes per row)

while prechunks exist:
prechunks, size given in prechunks section

[rhysm_08]

It's good to see interest in cracking the bf3 files. I hope we can learn more into the files, but more onto editing them

[Frankelstner]

Here's some stuff for the first file type (which I had labeled "uncompressed" before; some text format definitely) in sb archives:

general structure:

0x30 byte header

hashes (length 0x20 probably)

name strings terminated by nullbyte each (nullbyte padding after the last terminating nullbyte so the following unknown assignments start at a multiple of 0x10)

00s: 0x10 bytes each, many patterns though, 81B50200000000000000000000000000 is always the first line and 81B502 appears a few more times usually
04/10s: very similar to the one before, but for these assignments the byte 9 is either 04 or 10
3x4bytes 1: three parts with 4 bytes each, padded at the end, probably related to unknown 1
3x4bytes 2: three parts with 4 bytes each, padded at the end, they are related to unknown 2: part1->relative offset, part2->number of assignments, part3->assignment type

path strings: padded at the end

unknown 1: nothing useful known yet
unknown 2: it seems that the first line (or the first few bytes) of an assignment always defines the length (which is defined in part2 of 3x4bytes 2 anyway); 
to compensate for that first line/bytes however you need to add a few bytes to get the correct length of an assignment



header:

split the header into pieces of 4bytes and read them little endian; the matrix below is about what you see in a hex editor:

abcd
efgh
ijkl

a: 0FB2D1CE
b: absolute offset for path beginning
c: length from path beginning to end of file
d: number of hashes; however with 0 there is one hash (so 1->2, 2->3 etc.) or whatever it is, the second half of that first hash sometimes appears in the last section
e: 00000000
f: number of 3x4bytes 1
g: number of 04/10s
h: number of 00s
i: length of name section including padding
j: length of path section including padding
k: number of 3x4bytes 2
l: length of unknown 1; the start of unknown 2 seems to be (path offset + path length + length of unknown 1 - 0x10)

thus you can keep track of the assignments in unknown 2 if you calculate (path offset + path length + length of unknown 1 - 0x10 + part2 of 3x4bytes 2)

Edited November 1, 2011 by Frankelstner

[Frankelstner]

3x4bytes1: 
part1->00000000
part2->number of assignments in unknown 1 (these assignments all have equal length)
part3->number of 04/10s involved

04/10s:
are sort of the beginning/headline of a 00 block
byte 8 defines the number of 00s that belong to this 04/10
byte 4 is just the sum of all byte 8 so far
bytes cdef defines the where the 04/10 ends in the unknown 1 section (take the last 04/10 as defined in part3 of 3x4 bytes1 and the length given there plus 0x10 for the hash is the length of that assignment)
byte a is some kind of assignment type


E.g. take these 3x4bytes1:

00000000 33000000 01000000
00000000 12000000 07000000

and the 04/10s can be ordered this way:

726C7EE4 00000000 00043500 08000000 # this one is a bit strange because it has no 00s at all; this applies to the first 04/10 in every file
83530791 00000000 05043500 18000000 # the section ends after this line because of 01000000 in the 3x4 bytes1

7C72260A 05000000 01044100 04000000 # 2
EED5FC90 06000000 01042900 60000000 # 3
7C72260A 07000000 01044100 04000000 # 4
BD05234B 08000000 01043500 08000000 # 5
8FAF9D66 09000000 01043500 08000000 # 6
BAAAA05A 0A000000 06043500 64000000 # ends after this line because of 07000000 in the 3x4bytes1


Taking a closer look at the "first" 04/10 block (I tend to ignore the very first 04 due to its lack of information, thus the block is just a single 04/10):

83530791 00000000 05043500 18000000 


The length of the entire assignment in the unknown 1 section is 0x18 + 0x10 = 0x28 and using the 33000000 from 3x4bytes1 there must be 0x33 assignments of this length (still in the unknown 1 section)

Additionally there are five 00s that belong to it, and these are the first five 00s of the file. These 00s are:

81B50200 00000000 00000000 00000000
284026AB 3DC10000 08000000 10000000
ADE8900D 41000200 0C000000 14000000
7064F940 41000400 10000000 18000000
848C75F4 BDC00000 14000000 1C000000

As the 04/10 has the assignment type 35 the first 00 of the block starts with 81B50200. 41 on the other hand has B5ED8257 and 29 has 00D7877C.

Basically part3 in 3x4bytes1 somehow bundles 04/10s which then again contain some 00s each. And all these together define the structure in unknown 1.

[Frankelstner]

00s:
4parts of 4bytes each
part1 is unknown (though there is no doubt that it is related to the variable/field which is assigned a value or something like that)
part2 is the assignment type: 3dc1 means 4byte float, adc0 is a 1byte bool; there seems to be padding so floats start at multiples of 0x4 at least
part3 is the offset in unknown 1; ignore the 0x10 byte hash at the beginning and this tells you where the assignment starts. Note that it starts at null again for every section of 04s (plural; basically part3 of 3x4bytes1).
part4 is a bit odd, it kind of goes parallel to part3, just to suddenly become smaller; not sure about it

The nyan archives are fun though as everything is uncompressed. I searched a weapon for 31 (as in ammo count; initially I tried 30 and failed, quite annoying) and modding the first reasonable match got me 1000 rounds per magazine: http://imgur.com/D6Oen

It worked without modifying any sha1 hash.

I've looked up the MagazineCapacity in the 00s in two different assault rifles.

ab1b7e7c 29001500 6c040000 68010000

ab1b7e7c 29001600 6c040000 68010000

So 29 means integer and ab1b7e7c probably means MagazineCapacity.

Even the tank main cannon has

ab1b7e7c 29001e00 6c040000 68010000

though the position of the word MagazineCapacity in the name section is different and there are other new tank related things in that section too. There also hasn't been any match between the hashes at the beginning comparing the tank gun and an assault rifle. So the step MagazineCapacity -> ab1b7e7c does not take any parameters but is some kind of fixed algorithm; or just a dictionary entry, I can see lots of manual work there.

Or maybe the unknown 2 section has some use at last (very unlikely though).

Never mind that. ab1b7e7c does not refer to MagazineCapacity but rather the entire ammo section. I'm not perfectly sure about that either though. Comparing a really short file with another file almost as short has revealed however that UIAsset -> 89AD580C without a doubt. I guess that's a start.

Edited November 12, 2011 by Frankelstner

[rukqoa]

Thanks for the tools. I've used the tools to make some changes within the graphics. For example, disable the shadowmaps on low settings in initfs_win32 will disable shadows in the game.

Edited November 11, 2011 by rukqoa

[Frankelstner]

Thanks for the tools. I've used the tools to make some changes within the graphics. For example, disable the shadowmaps on low settings in initfs_win32 will disable shadows in the game.

Interesting. Quite honestly I didn't expect that file to have any use actually. When a file is (more or less) directly accessible there must be a catch.

Wait a sec, that is online? What the hell?

Edited November 11, 2011 by Frankelstner

[wtflol07]

Thanks for the tools. I've used the tools to make some changes within the graphics. For example, disable the shadowmaps on low settings in initfs_win32 will disable shadows in the game.

I've tried that but didn't work, it keep hanging when I'm entering the server

Could you upload your file?

Edited November 11, 2011 by wtflol07

[Frankelstner]

I've deciphered 681 of the 8940 hashes in use. Below are some of the shorter ones. One thing of interest might be "Fov" and "FOV" showing different hashes, thus the hash is case sensitive. This should have been assumed anyway, but it's good to know nevertheless. I haven't checked where these pairs below come from exactly, but I assume they are from pretty different places. Yet the hashes for strings of the same length are pretty similar. Maybe this will help with the rest.

It's also interesting to note that ab1b7e7c indeed means Ammo and not MagazineCapacity itself.

'A', 'e4b5 0200'
'B', 'e7b5 0200'
'D', 'e1b5 0200'
'X', 'fdb5 0200'
'Y', 'fcb5 0200'
'z', 'dfb5 0200'


'Id', '0873 5900'
'In', '0273 5900'
'Hz', 'f773 5900'


'End', '2aa3 870b'
'FOV', 'dab3 870b'
'Fov', 'dab7 870b'
'Key', '52ed 870b'
'Out', '4bdf 870b'
'Sid', 'db10 880b'
'SKU', 'c814 880b'
'Yaw', 'ca18 880b'


'Ammo', 'ab1b 7e7c'
'Axis', 'e674 7e7c'
'Base', 'd0a9 807c'
'Desc', '1491 7f7c'
'Drag', '95d6 7f7c'
'Gain', '6414 7f7c'
'Icon', 'ee64 827c'
'Mass', '693f 807c'
'Mesh', '7650 807c'
'Pose', '0c9d 8a7c'
'Roll', '3886 897c'
'Slot', '611f 8a7c'
'Size', '0029 8a7c'
'Step', '37ba 897c'
'True', '1317 887c'
'Time', 'd065 887c'
'Vec3', '064d 877c'
'Wave', '00d7 877c'
'Zoom', 'd2a7 8d7c'


'Count', 'c62d a90c'
'Curve', '9217 b00c'
'Depth', '08bd 710c'
'Event', 'e98a 010c'
'Group', 'dad1 670c'
'Index', '9b27 c90c'
'Items', '0374 d70c'
'Label', '6307 000d'
'Level', 'f36b 020d'
'Mixer', '6ed1 830c'
'Nodes', '36c4 dc0c'
'Pitch', 'a342 dd0d'
'Pivot', 'b139 dd0d'
'Prone', 'e31f d30d'
'Range', '3a3e b70d'
'Ratio', 'e4d0 b60d'
'Stand', '29ef c00d'
'Teams', '2b00 930d'

So taking a look at the infamous four in the beginning:

['DataContainer', '$', 'Name', 'Asset'] -> ['726c7ee4', '82d8827c', '81b50200', 'f5f1460c']

Considering the findings above these can be assigned already:

$ -> 81b50200 (because of 0200)

Name -> 82d8827c (because of 7c)

Asset -> f5f1460c (because of 0c)

DataContainer -> 726c6ee4 (because there are no other options)

Edited November 12, 2011 by Frankelstner

[rukqoa]

Interesting. Quite honestly I didn't expect that file to have any use actually. When a file is (more or less) directly accessible there must be a catch.

Wait a sec, that is online? What the hell?

I wasn't expecting this either. You can also change some ANT/Havoc physics settings and some miscellaneous stuff like render/view distance. Nothing too gamebreaking but disabling shadows really helps you out indoors.

Yup. Online. PB/game doesn't do a hash check against the file. What can I say? lol

I've tried that but didn't work, it keep hanging when I'm entering the server

Could you upload your file?

I just changed the settings for Ultra instead of adding a new option.

The file size has to be exactly the same before and after the edit. So if you change "true" to "false" you need to delete another character somewhere down the file. Like a period in the comments or something. Trick I learned from modding Breach.

Edited November 12, 2011 by rukqoa

[Frankelstner]

The hashes are calculated as follows:

wort = "Actions"
v14 = 5381

for pos in range(0,len(wort)):
   v15 = ord(wort[pos])
   v14 = v15 ^ (33 * v14)

hash = v14 & ((2**32)-1)

print hex(result)[2:-1] # gives 164355e8 which is e8554316 in the game files

Now it's just putting pieces together, will do it in a few days.

[rukqoa]

The hashes are calculated as follows:

wort = "Actions"
v14 = 5381

for pos in range(0,len(wort)):
   v15 = ord(wort[pos])
   v14 = v15 ^ (33 * v14)

hash = v14 & ((2**32)-1)

print hex(result)[2:-1] # gives 164355e8 which is e8554316 in the game files

Now it's just putting pieces together, will do it in a few days.

Sweet! I'm not proficient in file compression methods, but does this mean we'll soon have a method to decompress the elusive .cas and .sb files into human readable form?

[Frankelstner]

Sweet! I'm not proficient in file compression methods, but does this mean we'll soon have a method to decompress the elusive .cas and .sb files into human readable form?

To be honest cas have appeared to be the simplest file format possible. I've extracted them with 20 lines of code. The things here are mainly about the binary text file type inside. And it's pretty cool now that the hashes are done. E.g. this is part of what I am currently working with. Note that it does not contain much information but merely specifies how many floats/integers are to be found ELSEWHERE in the file (on the other hand, the strings here are in the correct order in which they are used by the game; and will most likely appear in this order in a human readable text file). I'm not perfectly happy with the cas extractor though because there seem to be file paths inside the binary text files which in turn make a nice folder structure. However when I just return the first string with a slash in it as a path it will not work correctly all the time. Thus I hope digging deeper into the files will help me understand the paths better to improve the cas extractor.

Number of assignments of type below: 1
array	17000000 01044100 04000000
member	29000700 00000000 00000000

FiringDispersionData	18000000 04042900 10000000
MinAngle	3dc10000 00000000 00000000
MaxAngle	3dc10000 04000000 04000000
IncreasePerShot	3dc10000 08000000 08000000
DecreasePerSecond	3dc10000 0c000000 0c000000

SoldierWeaponDispersion	1c000000 08042900 44000000
StandDispersion	29000700 00000000 00000000
CrouchDispersion	29000700 10000000 10000000
ProneDispersion	29000700 20000000 20000000
JumpDispersionAngle	3dc10000 30000000 30000000
ProneTransitionDispersionAngle	3dc10000 34000000 34000000
MoveDispersionAngle	3dc10000 38000000 38000000
MoveZoomedDispersionAngle	3dc10000 3c000000 3c000000
DecreasePerSecond	3dc10000 40000000 40000000

array	24000000 01044100 04000000
member	29000a00 00000000 00000000

FireEffectData	25000000 0a102900 b0000000
Effect	35000000 00000000 40000000
Offset	29d00b00 50000000 10000000
Rotation	29d00b00 60000000 00000000
ZoomOffset	29d00b00 70000000 30000000
UseZoomOffset	adc00000 80000000 44000000
ZoomRotation	29d00b00 90000000 20000000
UseZoomRotation	adc00000 a0000000 45000000
DisableDuringZoom	adc00000 a1000000 46000000
UpdateTransform	adc00000 a2000000 47000000
StopLoopingEffects	adc00000 a3000000 48000000

Vec3	2f000000 031029d0 10000000
x	3dc10000 00000000 00000000
y	3dc10000 04000000 04000000
z	3dc10000 08000000 08000000

ShotConfigData	32000000 11102900 40030000
InitialPosition	29d00b00 00000000 00000000
InitialDirection	29d00b00 10000000 10000000
InitialSpeed	29d00b00 20000000 20000000
InheritWeaponSpeedAmount	3dc10000 30000000 30000000
MuzzleExplosion	35000000 40000000 34000000
ProjectileData	35000000 10010000 38000000
SecondaryProjectileData	35000000 d0010000 3c000000
Projectile	35000000 90020000 40000000
SecondaryProjectile	35000000 dc020000 44000000
SpawnDelay	3dc10000 28030000 48000000
NumberOfBulletsPerShell	0dc10000 2c030000 4c000000
NumberOfBulletsPerShot	0dc10000 30030000 50000000
NumberOfBulletsPerBurst	0dc10000 34030000 54000000
RelativeTargetAiming	adc00000 38030000 58000000
ForceSpawnToCamera	adc00000 39030000 59000000
SpawnVisualAtWeaponBone	adc00000 3a030000 5a000000
ActiveForceSpawnToCamera	adc00000 3b030000 5b000000

FireLogicData	43000000 18042900 9c000000
HoldAndRelease	29000e00 00000000 00000000
BoltAction	29000f00 1c000000 1c000000
Recoil	29001000 2c000000 2c000000
FireInputAction	89001100 50000000 50000000
ReloadInputAction	89001100 54000000 54000000
CycleFireModeInputAction	89001100 58000000 58000000
TriggerPullWeight	3dc10000 5c000000 5c000000
RateOfFire	3dc10000 60000000 60000000
RateOfFireForBurst	3dc10000 64000000 64000000
ClientFireRateMultiplier	3dc10000 68000000 68000000
ReloadDelay	3dc10000 6c000000 6c000000
HoldOffReloadUntilFireRelease	adc00000 70000000 96000000
HoldOffReloadUntilZoomRelease	adc00000 71000000 94000000
ForceReloadActionOnFireTrigger	adc00000 72000000 95000000
ReloadTime	3dc10000 74000000 7c000000
ReloadTimeBulletsLeft	3dc10000 78000000 80000000
ReloadThreshold	3dc10000 7c000000 74000000
PreFireDelay	3dc10000 80000000 78000000
AutomaticDelay	3dc10000 84000000 8c000000
ReloadLogic	89001200 88000000 88000000
ReloadType	89001300 8c000000 90000000
FireLogicType	89001400 90000000 84000000
FireLogicTypeArray	41001500 94000000 70000000
AlwaysAutoReload	adc00000 98000000 97000000

HoldAndReleaseData	5b000000 07042900 1c000000
MaxHoldTime	3dc10000 00000000 00000000
MinPowerModifier	3dc10000 04000000 04000000
MaxPowerModifier	3dc10000 08000000 08000000
PowerIncreasePerSecond	3dc10000 0c000000 0c000000
Delay	3dc10000 10000000 10000000
ForceFireWhenKilledHolding	adc00000 14000000 18000000
KilledHoldingPowerModifier	3dc10000 18000000 14000000

BoltActionData	62000000 07042900 10000000
BoltActionDelay	3dc10000 00000000 00000000
BoltActionTime	3dc10000 04000000 04000000
HoldBoltActionUntilFireRelease	adc00000 08000000 08000000
HoldBoltActionUntilZoomRelease	adc00000 09000000 09000000
ForceBoltActionOnFireTrigger	adc00000 0a000000 0a000000
UnZoomOnBoltAction	adc00000 0b000000 0b000000
ReturnToZoomAfterBoltAction	adc00000 0c000000 0c000000

RecoilData	69000000 09042900 24000000
MaxRecoilAngleX	3dc10000 00000000 00000000
MinRecoilAngleX	3dc10000 04000000 04000000
MaxRecoilAngleY	3dc10000 08000000 08000000
MinRecoilAngleY	3dc10000 0c000000 0c000000
MaxRecoilAngleZ	3dc10000 10000000 10000000
MinRecoilAngleZ	3dc10000 14000000 14000000
MaxRecoilFov	3dc10000 18000000 18000000
MinRecoilFov	3dc10000 1c000000 1c000000
RecoilFollowsDispersion	adc00000 20000000 20000000

EntryInputActionEnum	72000000 46048900 04000000
EIAThrottle	00000000 00000000 00000000
EIAStrafe	00000000 01000000 01000000
EIABrake	00000000 02000000 02000000
EIASwitchPrimaryInventory	00000000 03000000 03000000
EIAYaw	00000000 04000000 04000000
EIAPitch	00000000 05000000 05000000
EIARoll	00000000 06000000 06000000
EIAFire	00000000 07000000 07000000
EIACameraPitch	00000000 08000000 08000000
EIACameraYaw	00000000 09000000 09000000
EIAFireCountermeasure	00000000 0a000000 0a000000
EIAZoom	00000000 0b000000 0b000000
EIAJump	00000000 0c000000 0c000000
EIAChangePose	00000000 0d000000 0d000000
EIAProne	00000000 0e000000 0e000000
EIAReload	00000000 0f000000 0f000000
EIASelectWeapon1	00000000 10000000 10000000
EIASelectWeapon2	00000000 11000000 11000000
EIASelectWeapon3	00000000 12000000 12000000
EIASelectWeapon4	00000000 13000000 13000000
EIASelectWeapon5	00000000 14000000 14000000
EIASelectWeapon6	00000000 15000000 15000000
EIASelectWeapon7	00000000 16000000 16000000
EIASelectWeapon8	00000000 17000000 17000000
EIASelectWeapon9	00000000 18000000 18000000
EIASwitchPrimaryWeapon	00000000 19000000 19000000
EIAGrenadeLauncher	00000000 1a000000 1a000000
EIAStaticGadget	00000000 1b000000 1b000000
EIADynamicGadget1	00000000 1c000000 1c000000
EIADynamicGadget2	00000000 1d000000 1d000000
EIAMeleeAttack	00000000 1e000000 1e000000
EIAThrowGrenade	00000000 1f000000 1f000000
EIASprint	00000000 20000000 20000000
EIACrawlSpeed	00000000 21000000 21000000
EIACycleFireMode	00000000 22000000 22000000
EIAInteract	00000000 23000000 23000000
EIAToggleParachute	00000000 24000000 24000000
EIACycleRadioChannel	00000000 25000000 25000000
EIAToggleCamera	00000000 26000000 26000000
EIAScoreboardMenu	00000000 27000000 27000000
EIAGearUp	00000000 28000000 28000000
EIAGearUpOrToggleWeaponLight	00000000 28000000 28000000
EIAGearDown	00000000 29000000 29000000
EIAGearDownOrExitSupportedShooting	00000000 29000000 29000000
EIAClutch	00000000 2a000000 2a000000
EIAHandBrake	00000000 2b000000 2b000000
EIAGiveOrder	00000000 2c000000 2c000000
EIABreathControl	00000000 2d000000 2d000000
EIAMapZoom	00000000 2e000000 2e000000
EIAChangeVehicle	00000000 2f000000 2f000000
EIAChangeEntry	00000000 30000000 30000000
EIAChangeEntry1	00000000 31000000 31000000
EIAChangeEntry2	00000000 32000000 32000000
EIAChangeEntry3	00000000 33000000 33000000
EIAChangeEntry4	00000000 34000000 34000000
EIAChangeEntry5	00000000 35000000 35000000
EIAChangeEntry6	00000000 36000000 36000000
EIAChangeEntry7	00000000 37000000 37000000
EIAChangeEntry8	00000000 38000000 38000000
EIAThreeDimensionalMap	00000000 39000000 39000000
EIAShowCommoRose	00000000 3a000000 3a000000
EIAShowLeaderCommoRose	00000000 3b000000 3b000000
EIAQuicktimeInteractDrag	00000000 3c000000 3c000000
EIAQuicktimeFire	00000000 3d000000 3d000000
EIAQuicktimeBlock	00000000 3e000000 3e000000
EIAQuicktimeFastMelee	00000000 3f000000 3f000000
EIAQuicktimeJumpClimb	00000000 40000000 40000000
EIAQuicktimeCrouchDuck	00000000 41000000 41000000
EIAUndefined	00000000 80000000 80000000
EIANoInput	00000000 80000000 80000000

ReloadLogic	b8000000 02048900 04000000
rlWeaponSwitchCancelsUnfinishedReload	00000000 00000000 00000000
rlReloadUnaffectedByWeaponSwitch	00000000 01000000 01000000

ReloadType	ba000000 03048900 04000000
rtSingleBullet	00000000 00000000 00000000
rtMagazine	00000000 01000000 01000000
rtMagazineWithPossibleShorterReload	00000000 02000000 02000000

FireLogicType	bd000000 07048900 04000000
fltSingleFire	00000000 00000000 00000000
fltSingleFireWithBoltAction	00000000 01000000 01000000
fltAutomaticFire	00000000 02000000 02000000
fltBurstFire	00000000 03000000 03000000
fltHoldAndRelease	00000000 04000000 04000000
fltDetonatedFiring	00000000 05000000 05000000
fltCount	00000000 06000000 06000000

array	c4000000 01044100 04000000
member	89000000 00000000 00000000

AmmoConfigData	c5000000 09042900 24000000
MagazineCapacity	fdc00000 00000000 00000000
NumberOfMagazines	fdc00000 04000000 04000000
TraceFrequency	0dc10000 08000000 08000000
AmmoPickupMinAmount	0dc10000 0c000000 0c000000
AmmoPickupMaxAmount	0dc10000 10000000 10000000
AutoReplenishMagazine	adc00000 14000000 20000000
AutoReplenishDelay	3dc10000 18000000 14000000
AmmoBagPickupDelayMultiplier	3dc10000 1c000000 1c000000
AmmoBagPickupAmount	fdc00000 20000000 18000000

OverHeatData	ce000000 05102900 c0000000
HeatPerBullet	3dc10000 00000000 00000000
HeatDropPerSecond	3dc10000 04000000 04000000
OverHeatPenaltyTime	3dc10000 08000000 08000000
OverHeatThreshold	3dc10000 0c000000 0c000000
OverHeatEffect	29000a00 10000000 10000000

WeaponSwayData	d3000000 01043500 08000000
$	00000000 00000000 00000000

GunSwayData	d4000000 14043500 40030000
$	00001800 00000000 00000000
Stand	29001a00 08000000 10000000
Crouch	29001f00 20010000 28010000
Prone	29001f00 b8010000 c0010000
ProneToCrouch	29002100 50020000 58020000
ProneToStand	29002100 64020000 6c020000
CrouchToProne	29002100 78020000 80020000
CrouchToStand	29002100 8c020000 94020000
StandToProne	29002100 a0020000 a8020000
StandToCrouch	29002100 b4020000 bc020000
SuppressionModifierUnzoomed	29002200 c8020000 d0020000
SuppressionModifierZoomed	29002200 e8020000 f0020000
Modifiers	41000300 08030000 10030000
DeviationScaleFactorZoom	3dc10000 0c030000 14030000
GameplayDeviationScaleFactorZoom	3dc10000 10030000 18030000
DeviationScaleFactorNoZoom	3dc10000 14030000 1c030000
GameplayDeviationScaleFactorNoZoom	3dc10000 18030000 20030000
ShootingRecoilDecreaseScale	3dc10000 1c030000 24030000
FirstShotRecoilMultiplier	3dc10000 20030000 28030000
CameraRecoil	35000000 24030000 2c030000

Just some additions. I've extracted the beta sb files without any issues, but as mentioned in a post above, they merely contain bundle archives which are to be extracted again (which I did as well to a certain degree; I managed to extract the binary text format only though there were three distinct file types). Cas is simple enough and actually I haven't had any experience with archives before working on the bf3 ones (even though as I noticed later, the BC2 archives for example are simpler than the BC2 dbx files).

The hashes I mentioned are for the binary text format and finally make the connection between names and values which is of course the crucial part to understanding. Before that the lines above wouldn't have a word on the left but rather a 4byte hash (yay more bytes!). As I modded the ammo count already I can probably use this knowledge plus the deciphered hashes to figure out these text files entirely.

I'll post my scripts at some point. But right now I'm more into analyzing things and have 20+ Python files for analyzing purposes only with misleading names (e.g. cascatNONdice extracts dice files; dice being the binary text format). Besides I'm not such a great programmer myself. I've never had any formal education in these kinds of things and thought maybe someone with more knowledge would use the pointers given above to write decent tools; but I have no issues giving away my code once I've tidied up things a bit.

Edited November 14, 2011 by Frankelstner

[sirnaut]

I like the work your doing, thanks for putting the time in to it

[mistan]

Thanks for the tools. I've used the tools to make some changes within the graphics. For example, disable the shadowmaps on low settings in initfs_win32 will disable shadows in the game.

Would it be at all possible for you to share with me exactly how you are able to change the graphics settings? I'm having a hard time trying to follow. I've been dying to change rendering distances and LOD while playing online. I've been researching this since the game came out and this is the 1st place that I've found that is actually making stuff like this possible! I just want to increase the graphics beyond "Ultra".

If it's not too much, I'd really appreciate your help

[zoologist134]

I wasn't expecting this either. You can also change some ANT/Havoc physics settings and some miscellaneous stuff like render/view distance. Nothing too gamebreaking but disabling shadows really helps you out indoors.

Yup. Online. PB/game doesn't do a hash check against the file. What can I say? lol

I just changed the settings for Ultra instead of adding a new option.

The file size has to be exactly the same before and after the edit. So if you change "true" to "false" you need to delete another character somewhere down the file. Like a period in the comments or something. Trick I learned from modding Breach.

I have already done this but the game is still joining server.I change "true" to "false",then deleted one period in the file and the file size is really exactly the same

[mistan]

I have already done this but the game is still joining server.I change "true" to "false",then deleted one period in the file and the file size is really exactly the same

It worked when I started using Notepad++ to make the changed rather than notepad/wordpad.

[zoologist134]

It worked when I started using Notepad++ to make the changed rather than notepad/wordpad.

I also used Notepad++ ,so strange.Do I need to change initfs_Win32 in update/patch,too?

Could you give me your initfs_Win32 ,please.

Edited November 26, 2011 by zoologist134

[mistan]

I also used Notepad++ ,so strange.Do I need to change initfs_Win32 in update/patch,too?

Could you give me your initfs_Win32 ,please.

Yea! You have to change the initfs_win32 in the update/patch/data folder. Dont even worry about the one in the original data folder anymore. I deleted that one. Make sure to back it up just in case. My initfs_win32 file is a bit of a mess right now. I'll see what I can do when I clean it up a bit.

Also, does anybody know of any more console commands other than the 2000+ that were leaked already. A lot of commands seem to be missing. Stuff dealing with the emitter system and the shaders.

Edited November 26, 2011 by mistan

[zoologist134]

deleted

Edited November 27, 2011 by zoologist134

[aresyx]

Use a hex editor so the file size stays the same. Please do not post modified inifs_win32 files, because they will eventually be leaked onto cheating websites prompting EA and punkbuster crack down on game modification. A simple md5tool check on gamefiles and this method will be dead.

Edited November 27, 2011 by aresyx

[zoologist134]

Ok,I delete my file.

Actually,it is a original inifs_win32,also thank you for your method.I succeed.Thank you!

Edited November 27, 2011 by zoologist134

[Subtellite]

hey guys iam new here and into things like game modding (i dont wanna know things about hacks or so) and i want to know how i can change the player models from BF3. lets say i want to switch the russians with the americans or the americans with the terrorists playermodels. so it would look like the russians are fighting against russians (to make an easy understandable example). i have googled around and registered at some sites, downloaded hexeditors and some other tools (like the BF3 editor) but i dont get any success in what i want to do. also i want to know how to enable the spectator mode so i can make some videos without using that ammobag/medikit bug.

thanks in advance

Sub