FIFA 16 attribdb

[Hels The Ronin]

So, I know for good that @papinho81 did a mod for FIFA 16 that changes attribdb, and I've been said that this is the same that PES dt18, or, what I suppose, the same than editing the newer FIFA/EA FC EBX. So, if there's someone known in the matter, you yourself papinho or anybody else, could confirm this? My reasons to think like this is that when I edited the EBX in FIFA 23, they were under a tree of several folders, one of them named attribdb, so I guess that it is the same shit, but since I don't know how one can edit that in FIFA16 I am not sure and I need some guidance. In case that indeed it is the same, I'd be interested into knowing how to edit those, since I get that there's no tool available for such purpose.

My interest for doing this is that I managed to get some FIFA 16 good base for simulation football, but I'd need to correct some of the behaviours of the players, and maybe if there's some way of traspassing the knowledge I got in FIFA 23 editing into FIFA 16, which has better foot planting and general speed and animation, it could be quite a blast so... yeah, I'd be quite interested in doing such a thing if someone can give me some guidance.

 

[papinho81]

So, I know for good that @papinho81 did a mod for FIFA 16 that changes attribdb, and I've been said that this is the same that PES dt18, or, what I suppose, the same than editing the newer FIFA/EA FC EBX. So, if there's someone known in the matter, you yourself papinho or anybody else, could confirm this? My reasons to think like this is that when I edited the EBX in FIFA 23, they were under a tree of several folders, one of them named attribdb, so I guess that it is the same shit, but since I don't know how one can edit that in FIFA16 I am not sure and I need some guidance. In case that indeed it is the same, I'd be interested into knowing how to edit those, since I get that there's no tool available for such purpose.

My interest for doing this is that I managed to get some FIFA 16 good base for simulation football, but I'd need to correct some of the behaviours of the players, and maybe if there's some way of traspassing the knowledge I got in FIFA 23 editing into FIFA 16, which has better foot planting and general speed and animation, it could be quite a blast so... yeah, I'd be quite interested in doing such a thing if someone can give me some guidance.

The attribdb gameplay something files handle part of the gameplay together with the exe. But no one has been to decrypt them to date.
The only thing I have been able to do is to swap those files from one game/game version to another. It does change the gameplay but in 16 it results most of the time in crashes or some buttons mapping on the controller to be wrong.

 

[fifaccitiu.com]

AttribSys vault resources act as a database which holds attributes for stadium resources, gameplay, configs. They are split into the vault, which holds information needed to access the data, and the bin, which holds the actual attribute data. Vaults work with the AttribSys schema found in the executable.

Structures​

CgsResource::AttribSysVaultResource​

32-bit​

Offset	Length	Type	Name	Description	Comments
0x0	0x4	uint8_t*	mpau8VltData
0x4	0x4	uint32_t	muVltSizeInBytes
0x8	0x4	uint8_t*	mpau8BinData
0xC	0x4	uint32_t	muBinSizeInBytes

64-bit​

Offset	Length	Type	Name	Description	Comments
0x0	0x8	uint8_t*	mpau8VltData
0x8	0x4	uint32_t	muVltSizeInBytes
0xC	0x4			Padding
0x10	0x8	uint8_t*	mpau8BinData
0x18	0x4	uint32_t	muBinSizeInBytes

Common substructures​

Attrib::Array​

Offset	Length	Type	Name	Description	Comments
0x0	0x2	uint16_t	mAlloc	Number of entries allocated
0x2	0x2	uint16_t	mCount	Number of entries used
0x4	0x2	uint16_t	mSize	The length of each entry
0x6	0x2	uint16_t	mEncodedTypePad	Padding

Attrib::RefSpec​

Offset	Length	Type	Name	Description	Comments
0x0	0x8	Key	mClassKey
0x8	0x8	Key	mCollectionKey
0x10	0x4	Collection*	mCollectionPtr		Always nullptr in resource
0x14	0x4			Padding

Vault​

The vault is a set of structures with ChunkBlocks which are read sequentially. In FIFA, these are:

• Vers: The version
• DepN: The dependency node
• StrN: The start node
• DatN: The data node
• ExpN: The export node
• PtrN: The pointer node

Attrib::Vault::ChunkBlock​

Offset	Length	Type	Name	Description	Comments
0x0	0x4	uint32_t	mType	A type ID similar in form to a magic number
0x4	0x4	uint32_t	mSize	The total size of the chunk

Version​

Attrib::Vault::VersionNode​

Offset	Length	Type	Name	Description	Comments
0x0	0x8	ChunkBlock		Base class
0x8	0x8	uint64_t	mVersion	Version hash

Dependency node​

Attrib::Vault:ependencyNode​

Offset	Length	Type	Name	Description	Comments
0x0	0x8	ChunkBlock		Base class
0x8	0x8	HashInt	mCount	Number of dependencies

This structure is immediately followed by the hashes of the dependency strings, then the offsets of the strings relative to the start of the first string, then the strings themselves.

Start node​

Offset	Length	Type	Name	Description	Comments
0x0	0x8	ChunkBlock		Base class
???

Size is 16 bytes, but the final 8 bytes is always null. This node appears to not be read by the game.

Data node​

Offset	Length	Type	Name	Description	Comments
0x0	0x8	ChunkBlock		Base class

This is followed by several collections.

This node is not read directly. Pointers in other nodes read the data that lies in this node.

Attrib::CollectionLoadData​

Offset	Length	Type	Name	Description	Comments
0x0	0x8	Key	mKey
0x8	0x8	Key	mClass
0x10	0x8	Key	mParent
0x18	0x4	uint32_t	mTableReserve	Amount allocated for entries
0x1C	0x4	uint32_t	mTableKeyShift
0x20	0x4	uint32_t	mNumEntries	Number of entries
0x24	0x2	uint16_t	mNumTypes	Number of types
0x26	0x2	uint16_t	mTypesLen	Amount allocated for types
0x28	0x4	void*	mLayout		Always nullptr in resource
0x2C	0x4			Padding

This is always followed by the types, then the entries.

Attrib::CollectionLoadData::AttribEntry​

Offset	Length	Type	Name	Description	Comments
0x0	0x8	Key	mKey
0x8	0x4	void*	mData
0xC	0x2	uint16_t	mType
0xE	0x1	uint8_t	mNodeFlags
0xF	0x1	uint8_t	mEntryFlags

Export node​

Attrib::Vault::ExportNode​

Offset	Length	Type	Name	Description	Comments
0x0	0x8	ChunkBlock		Base class
0x8	0x8	HashInt	mCount	Number of exports

Followed by export entries of an amount defined by mCount.

Attrib::Vault::ExportEntry​

Offset	Length	Type	Name	Description	Comments
0x0	0x8	ExportID	mID
0x8	0x8	TypeID	mType
0x10	0x4	uint32_t	mDataBytes	Size of the data node entry
0x14	0x4	uint32_t	mDataOffset	Offset of the entry in the data node	Relative to vlt start

Pointer node​

Attrib::Vault:ointerNode​

Offset	Length	Type	Name	Description	Comments
0x0	0x8	ChunkBlock		Base class

Followed by several PtrRefs.

Attrib:trRef​

Offset	Length	Type	Name	Description	Comments
0x0	0x4	uint32_t	mFixupOffset	The offset at which to write the offset	Relative to the beginning of the dependency. The area pointed to is normally null and allocated specifically for this
0x4	0x2	uint16_t	mPtrType	Pointer type	See type.
0x6	0x2	uint16_t	mIndex	Which dependency the value is relative to	0 is normally the vault 1 is normally the bin
0x8	0x8	anon_union_0	field_3	Value

Attrib:trRef::anon_union_0​

Length	Type	Name	Description	Comments
0x8	ExportID	mExportID
0x8	HashInt	mOffset

Bin​

The bin is entirely made up of data. The individual structures within are pointed to by the vault.

In general attribdb, there is one ChunkBlock at the beginning of the bin, StrE (string exports), which contains a list of null-terminated strings. Each individual string is pointed to by the vault. The ChunkBlock itself is not read and likely only exists as a byproduct of how the AttribSys is created.
In gameplay attribdb the strings are included in the exe, so is hard to determine the references.

 

[Hels The Ronin]

AttribSys vault resources act as a database which holds attributes for stadium resources, gameplay, configs. They are split into the vault, which holds information needed to access the data, and the bin, which holds the actual attribute data. Vaults work with the AttribSys schema found in the executable.

Structures​

CgsResource::AttribSysVaultResource​

32-bit​

Offset	Length	Type	Name	Description	Comments
0x0	0x4	uint8_t*	mpau8VltData
0x4	0x4	uint32_t	muVltSizeInBytes
0x8	0x4	uint8_t*	mpau8BinData
0xC	0x4	uint32_t	muBinSizeInBytes

64-bit​

Offset	Length	Type	Name	Description	Comments
0x0	0x8	uint8_t*	mpau8VltData
0x8	0x4	uint32_t	muVltSizeInBytes
0xC	0x4			Padding
0x10	0x8	uint8_t*	mpau8BinData
0x18	0x4	uint32_t	muBinSizeInBytes

Common substructures​

Attrib::Array​

Offset	Length	Type	Name	Description	Comments
0x0	0x2	uint16_t	mAlloc	Number of entries allocated
0x2	0x2	uint16_t	mCount	Number of entries used
0x4	0x2	uint16_t	mSize	The length of each entry
0x6	0x2	uint16_t	mEncodedTypePad	Padding

Attrib::RefSpec​

Offset	Length	Type	Name	Description	Comments
0x0	0x8	Key	mClassKey
0x8	0x8	Key	mCollectionKey
0x10	0x4	Collection*	mCollectionPtr		Always nullptr in resource
0x14	0x4			Padding

Vault​

The vault is a set of structures with ChunkBlocks which are read sequentially. In FIFA, these are:

• Vers: The version
• DepN: The dependency node
• StrN: The start node
• DatN: The data node
• ExpN: The export node
• PtrN: The pointer node

Attrib::Vault::ChunkBlock​

Offset	Length	Type	Name	Description	Comments
0x0	0x4	uint32_t	mType	A type ID similar in form to a magic number
0x4	0x4	uint32_t	mSize	The total size of the chunk

Version​

Attrib::Vault::VersionNode​

Offset	Length	Type	Name	Description	Comments
0x0	0x8	ChunkBlock		Base class
0x8	0x8	uint64_t	mVersion	Version hash

Dependency node​

Attrib::Vault:ependencyNode​

Offset	Length	Type	Name	Description	Comments
0x0	0x8	ChunkBlock		Base class
0x8	0x8	HashInt	mCount	Number of dependencies

This structure is immediately followed by the hashes of the dependency strings, then the offsets of the strings relative to the start of the first string, then the strings themselves.

Start node​

Offset	Length	Type	Name	Description	Comments
0x0	0x8	ChunkBlock		Base class
???

Size is 16 bytes, but the final 8 bytes is always null. This node appears to not be read by the game.

Data node​

Offset	Length	Type	Name	Description	Comments
0x0	0x8	ChunkBlock		Base class

This is followed by several collections.

This node is not read directly. Pointers in other nodes read the data that lies in this node.

Attrib::CollectionLoadData​

Offset	Length	Type	Name	Description	Comments
0x0	0x8	Key	mKey
0x8	0x8	Key	mClass
0x10	0x8	Key	mParent
0x18	0x4	uint32_t	mTableReserve	Amount allocated for entries
0x1C	0x4	uint32_t	mTableKeyShift
0x20	0x4	uint32_t	mNumEntries	Number of entries
0x24	0x2	uint16_t	mNumTypes	Number of types
0x26	0x2	uint16_t	mTypesLen	Amount allocated for types
0x28	0x4	void*	mLayout		Always nullptr in resource
0x2C	0x4			Padding

This is always followed by the types, then the entries.

Attrib::CollectionLoadData::AttribEntry​

Offset	Length	Type	Name	Description	Comments
0x0	0x8	Key	mKey
0x8	0x4	void*	mData
0xC	0x2	uint16_t	mType
0xE	0x1	uint8_t	mNodeFlags
0xF	0x1	uint8_t	mEntryFlags

Export node​

Attrib::Vault::ExportNode​

Offset	Length	Type	Name	Description	Comments
0x0	0x8	ChunkBlock		Base class
0x8	0x8	HashInt	mCount	Number of exports

Followed by export entries of an amount defined by mCount.

Attrib::Vault::ExportEntry​

Offset	Length	Type	Name	Description	Comments
0x0	0x8	ExportID	mID
0x8	0x8	TypeID	mType
0x10	0x4	uint32_t	mDataBytes	Size of the data node entry
0x14	0x4	uint32_t	mDataOffset	Offset of the entry in the data node	Relative to vlt start

Pointer node​

Attrib::Vault:ointerNode​

Offset	Length	Type	Name	Description	Comments
0x0	0x8	ChunkBlock		Base class

Followed by several PtrRefs.

Attrib:trRef​

Offset	Length	Type	Name	Description	Comments
0x0	0x4	uint32_t	mFixupOffset	The offset at which to write the offset	Relative to the beginning of the dependency. The area pointed to is normally null and allocated specifically for this
0x4	0x2	uint16_t	mPtrType	Pointer type	See type.
0x6	0x2	uint16_t	mIndex	Which dependency the value is relative to	0 is normally the vault 1 is normally the bin
0x8	0x8	anon_union_0	field_3	Value

Attrib:trRef::anon_union_0​

Length	Type	Name	Description	Comments
0x8	ExportID	mExportID
0x8	HashInt	mOffset

Bin​

The bin is entirely made up of data. The individual structures within are pointed to by the vault.

In general attribdb, there is one ChunkBlock at the beginning of the bin, StrE (string exports), which contains a list of null-terminated strings. Each individual string is pointed to by the vault. The ChunkBlock itself is not read and likely only exists as a byproduct of how the AttribSys is created.
In gameplay attribdb the strings are included in the exe, so is hard to determine the references.

Wow, thanks for the detailed explanation! I will be trying to understand all you told me here, cause now I feel a bit like an idiot. XD But I guess I understand your main point. The AttrybSys has some structures made, which are the ones you gave on top, that give the direction of the vault, or the structure of the vault to work, and then the vault which is, essentially, a set of pointers and other values that point to the addresses of memories where are stored the values of the bins. But the bins itself are unaccesible. Am I right?

The attribdb gameplay something files handle part of the gameplay together with the exe. But no one has been to decrypt them to date.
The only thing I have been able to do is to swap those files from one game/game version to another. It does change the gameplay but in 16 it results most of the time in crashes or some buttons mapping on the controller to be wrong.

Question here... Would it be possible to decrypt it? Specially that now exe has been decrypted for cracking it. I mean, probably has no much to do, but if it could be broke in some sense, maybe now it can be decrypted in some other way like FIFA 21/22/23 and so on had been decrypted? I mean, I suppose that for that matter it would be needed to talk with the people of the frosty toolsuite, that are the ones that decrypted the newer FIFA's, but I wonder if they could provide an SDK for us to work with. I'll ask anyway in their discord what's preventing FIFA 16 to be decrypted, cause I am quite curious.

 

[fifaccitiu.com]

Wow, thanks for the detailed explanation! I will be trying to understand all you told me here, cause now I feel a bit like an idiot. XD But I guess I understand your main point. The AttrybSys has some structures made, which are the ones you gave on top, that give the direction of the vault, or the structure of the vault to work, and then the vault which is, essentially, a set of pointers and other values that point to the addresses of memories where are stored the values of the bins. But the bins itself are unaccesible. Am I right?


Question here... Would it be possible to decrypt it? Specially that now exe has been decrypted for cracking it. I mean, probably has no much to do, but if it could be broke in some sense, maybe now it can be decrypted in some other way like FIFA 21/22/23 and so on had been decrypted? I mean, I suppose that for that matter it would be needed to talk with the people of the frosty toolsuite, that are the ones that decrypted the newer FIFA's, but I wonder if they could provide an SDK for us to work with. I'll ask anyway in their discord what's preventing FIFA 16 to be decrypted, cause I am quite curious.

There are two attribdb. One for gameplay and one for graphical resources (stadiums, etc). The one for stadium has string that could be used to guess which parameters are available (like FMT with gameplay attribs). The one for gameplay doesn't have those descriptive strings inside but probably could be found inside the exe, that makes almost impossible to edit.
I don't think frosty guys are interested in old fifa editing.. probably the only one that could do something, having interest in Fifa 16, is Rinaldo...

 

[Hels The Ronin]

There are two attribdb. One for gameplay and one for graphical resources (stadiums, etc). The one for stadium has string that could be used to guess which parameters are available (like FMT with gameplay attribs). The one for gameplay doesn't have those descriptive strings inside but probably could be found inside the exe, that makes almost impossible to edit.
I don't think frosty guys are interested in old fifa editing.. probably the only one that could do something, having interest in Fifa 16, is Rinaldo...

Dunno, but it would be quite amazing cause the thing here, essentially, is that I have a very good gameplay but CB_Jockey is already present in FIFA 16, but maybe if attribdb files regarding gameplay, would be editable, then maybe marking reaction could be reworked and make players follow more their marks in the area in the situations when CB Jockey occur instead of simply jockeying back, and that would be quite an achievement, to the point where we could have the most complete gameplay to the date... Might ask with this Rinaldo, to see what he thinks about it.