Well with Battlefield 4 by one of my most favorite studio’s Digital Illusions CE (better known as DICE) releasing within 24 hours has released.. I think I should share some information here, just to be nice to everyone involved.
Before we begin, I’d like to say that this will sound very similar to Halo’s format (Blam Engine) way of explaining things. From content like images and sounds being called raw, metadata being called meta, and Ebx, and other “describing” formats being called tags. From my observations they have seemed to take a more centralized approach to storing all of their information. They have moved all of the raw data, and certain central ebx files into the cascat format. The cascat format had been used in Battlefield 3 base, but it seems like it was neglected after release. Cas stands for Content Addressable Storage and how it pretty much looks is, you have a catalog file which contains offsets, file sizes, and a SHA1 hash of all of the data inside. (And by all of the data, I mean each file that is within a cas file has a SHA1) The way that I have reversed it, it appears that you contact for certain things a CAS handler class which will then look up the file, raw, whatever that is in it based on SHA1. In Battlefield 3, these SHA’s were not in any kind of order and that caused the game to take forever to load on original maps even if you had an SSD because it was re-computing SHA1’s or looking them up in a unorganized manner. This problem most likely still exists in Battlefield4, unless the cas building tool sorted the hashes before hand. I have not actually looked into if hashes have been sorted.
In the BF4 Alpha Trial, Frankelstner noticed there was a different ebx header for the ebx data. Ebx data is Binary XML in a nutshell. I took a look into the matter and a quick IDA review showed that some of the information in the header had changed sizes, by that I mean it went from a 32bit integer, to a 16bit integer in certain locations. Quick modification to previous source code got us pass that. Even better yet, upon analyzing the dumped Alpha Trial executable, I noticed that certain things that I could rely on for finding the ebx process function had changed, the most notable is the string “Bad EBX Partition Header” or something similar to that. So that got me a bit interested. After a few hours up comparing functions to the previous ebx reading code I was able to find and update most of the functions. DICE still uses a giant switch statement (Thanks Hex-Rays 🙂 ) as a partition reader, which whoever wrote that should be spanked (not really, but its frustrating to reverse). But there was something different about it all.
In Venice (Battlefield 3) and Medal of Honor Warfighter and previous Frostbite 2 based games, the ebx reading code (binary xml) is called StreamingPartition blank, where blank would be Reader, Array, etc. In Warsaw (Battlefield 4) its just called EbxPartition blank, where blank means the same as before. There are minor changes throughout but it caused me to separate some of the code into 2 different sections within “IceEditor”. There is a reason I put IceEditor in quotes for now. Along with ebx code changing certain things in the header, having a 64-bit alignment also became an issue. Its not a major issue because well screw alignment.
tl;dr; IceEditor is now called Project Rime and will probably be a open source project near its completion. Since once all of the base framework is finished it won’t be that hard to properly add support for new games using the Frostbite engine. There will also be backward compatible support eventually if someone wants to step up for the project. (BC2, BC1 support) There has been many many hours lost in reformatting without backing up the project, source control servers deciding to go poop and losing all data. lada lada.