Okay, I did some quick testing in the debugger just now.
Every call to FAES::DecryptData during the loading process (from firing up the EXE, through the various loading splash screens, up to the title screen that says to press ENTER) uses the same key parameters, those for the "https://ace7.acecombat.jp/special/
" key. There were probably several dozen calls in total.
Then, right after the title screen, I immediately start seeing a ton of calls to FAES::DecryptData from thread "SaveLoadThread0" that specify a key length of 0x20 and which specify the 32-character key string "M$KW=w4,knvovE8u0000000004100000". The data length always appears to be 0x200 (512 bytes).
I skipped over those, and then re-enabled the FAES::DecryptData breakpoint a bit later, once I was at the fully loaded-up menu screen. From that point forward, I did not observe any further calls to FAES::DecryptData. This was while browsing the menus, looking at various aircraft, loading up maps, playing missions with their cinematics, etc., all of which I assume would involve dynamically loading asset data.
So from that, I think it's reasonable to conclude that one of the following is true:
1. The individual asset files themselves are not
AES-encrypted. (Or at least, not AES-encrypted using the Unreal Engine AES functions
, but still possibly decrypted using functions elsewhere, perhaps.)
2. The individual asset files perhaps are
all AES-encrypted (maybe at least a small stub at the beginning), and the game goes through literally all
of its asset files' stubs during that time period between the title screen and the main menu and pre-decrypts that bit of header data.
I'll have to go back and see if I can get a reasonably quick complete breakpoint count on that complete second sequence of FAES::DecryptData calls.
For now, anyway, I seem to have unearthed a second AES key that's being used for something
, and I actually just realized, the cracked game version uses a fake steam ID of 0x4100000041000000 (or something like that... in any case, the SaveGames subdir name is 292733975847239680, which is decimal for that number). Combined with the fact that these AES decryption calls were coming from the thread named "SaveLoadThread0", and with the timing of "right before loading the main menu and no other times" (I didn't do anything that would have triggered a game save at any point, like completing a mission or unlocking an aircraft part etc), I think it's entirely reasonable to conclude that the "M$KW=w4,knvovE8u0000000004100000" AES key is in fact the user-specific savegame encryption key for user 0x4100000041000000. So that perhaps has some usefulness in determining the AES keys for the user-specific savegame file encryption. But it also strongly
points towards "the asset files themselves are not
AES-encrypted (at least not with the Unreal Engine functions)".