Corrupted DataFile.terra with C++ 14.32.31332

[theguly]

On a fresh windows10 install, with latest Visual Studio Community, I've observed what I tracked down to be a corruption on DataFile.terra

I tracked down the issue to be the version of C++ redist doing some cross-test:

• freshly installed VS, launching Terra.exe it dies with an Exception code 0xc0000374
• on an older setup I've been able to generate a Terra.exe that opens up a reverse connection to my c2
• changed windows version (21H2/1908) with no relevant changes, every new setup generates a terra.exe that dies with same exception
• moved a DataFile.terra from working box to a "broken" one, the compiled Terra.exe is valid
• the issue is probably on the generated terra file, meaning that GenerateRsrc.exe is someway broken
• tracked down main differences, the old setup had vcredist 14.32.31326 when newer ones have 14.32.31332
• removed 14.32.31332 from a "broken" setup and installed 14.32.31326, recompiled GenerateRsrc.exe, new DataFile.terra, Terra.exe works as expected

Latest Visual Studio comes with C++ redist version 14.43.31332 and based on my observation this breaks the compilation of DataFile.terra

[NUL0x4C]

@theguly hello, thanks for the details :)
DataFile.terra is a file that contains [16 byte key + the payload encrypted with rc4], i dont see how it can be broken, since its just reading - encrypting - writing, the heap corruption is possibly from the injection way, this loader is doing some messy calculations to write the payload, my best guess is NtWriteVirtualMemory's sNumberOfBytesWritten parameter ...
while i dont have the same setup, and kinda busy to do this experiment, can u try using "InjectPayload" instead of "InjectPayload2" in the main file here and let me know what happen (try it with the environment that was crashing)

[NUL0x4C]

and if you want to more details, you can enable uncomment this for debug mode

[theguly]

@theguly hello, thanks for the details :) DataFile.terra is a file that contains [16 byte key + the payload encrypted with rc4], i dont see how it can be broken, since its just reading - encrypting - writing, the heap corruption is possibly from the injection way, this loader is doing some messy calculations to write the payload, my best guess is NtWriteVirtualMemory's sNumberOfBytesWritten parameter ... while i dont have the same setup, and kinda busy to do this experiment, can u try using "InjectPayload" instead of "InjectPayload2" in the main file here and let me know what happen (try it with the environment that was crashing)

thanks for the reply.

it doesn't make so much sense to me as well, but given the tests i've done that looks like to be the reason.
hopefully it will be easily confirmed /denied by any other user that runs latest c++ redist package, let's just wait for a comment here :)

i'll try to give a deeper look using some debug info but i will probably can't do more digging very soon.