I'm working on converting a game originally developed to run on Windows for the web. I have a bunch of artwork for the game received from the artist in .tga image files which open fine in Photoshop. However I don't have the complete set of artwork and it cannot be found.

I also have a distribution of the Windows game which consists of .dlls, .lua files and a lot of .tga files. The .tga (Targa) files in the game distribution are named the same as the .tga files in the artwork I have received so I think it's safe to assume they are the same images. Even the images that I'm missing from the supplied artwork are present in the game distribution. Bingo! Well actually no…

The .tga files from the game won't open in Photoshop or Preview (mac) or Pixelmator (mac). So I think something has been done to the game .tga files to protect them and I want to reverse engineer them back to normal .tga files.

First I need to discover what the new files are and how they've been modified. Here's what I've tried so far:

Using linux file command:

  • rockExplosion.tga (from artwork).
    • Output: rockExplosion.tga: Targa image data - RGB 100 x 43
  • rockExplosion.tga (from game).
    • Output: rockExplosion.tga: data

Inspecting using hex viewer and diff

The two files are exactly the same byte length. The last ~15% of bytes are identical in each file and the first ~85% are completely different.

Binwalk didn't tell me anything for either file.

  • What other techniques exist for reverse engineering unknown file formats?
  • Is there a standard way of protecting images in .NET applications that could have been used?
  • What other tools could I use to probe further?
  • Working out a totally unknown file format is hard, but you got a huge advantage in that you also have unencrypted (possibly) versions of the files. Can you post one or more original/encrypted pairs of files on a public server? There are lots of approaches – in this case, since the file sizes are the same, I'd probably start with a few variations of binary differencing and see what it tells me.
    – Jongware
    Aug 5, 2015 at 8:39
  • .. that said, those percentages are not telling anything useful. The final 26 bytes are a fixed footer (wikipedia) and so it would only be relevant if the entire file is 173 bytes long, which could indicate the image data is encrypted but the metadata is not.
    – Jongware
    Aug 5, 2015 at 8:48

2 Answers 2


If you can, you should post links to 2-3 of your real targa images, and the corresponding game targa images (beware of license issues though). Sometimes, looking at the files rings a bell, and i could have checked much of what i'm going to say if it works for your files or not.

That said:

  • Are some of the tga files referenced from Lua? There is Lua source code out there to load targa files, maybe your lua has a variation on that that does the decryption.
  • Because the files have the same length, i'd assume they're not converted to a different format, but encrypted somehow instead.
  • It's unlikely to be a kind of encyption that's used elsewhere and that's well known, since that would defeat the point of encryption.
  • If this is a simple way of encryption, then the first few bytes (the header of the tga file) should be the same for all of the encrypted files, since they're the same in the original files. Check the targa file format for details; for example, image width/height should be different, most other header fields should be the same.
  • It could be interesting to know where exactly the different bytes stop and the identical bytes start. Is that always on a block boundary, i.e. a multiple of 512 bytes, with only the last block (that's smaller than 512 bytes) unencrypted? (Replace 512 with 1024, 2048, 4096 for likely block sizes.) Or is it always on a certain logical position in the file, for example start of the extension area, or start of the developer area?
  • Do all of the files have a developer area? If so, it might contain an encryption key. (Unlikely since the file size doesn't change)
  • What happens if you xor the bytes from the original file with the bytes from the encrypted file? Do different pairs of files yield the same xored pattern? Does this pattern repeat, and after how many bytes?

If all of this fails, you'll have to reverse engineer the game code, learn how the executable code loads the tga files, and implement the algorithm yourself.

  • That's a good answer. If I had to guess, I'd say that this encryption has somehow reversed the file. As you said, If this is a simple way of encryption, then the first few bytes (the header of the tga file) should be the same for all of the encrypted files. Since @Matt Harrison said that The two files are exactly the same byte length. The last ~15% of bytes are identical in each file and the first ~85% are completely different., I would assume that this 15% are the file header, and that the whole file has been reversed. But that's only a guess, nothing more...
    – Hackndo
    Aug 5, 2015 at 7:04
  • 1
    Seems we disagree about "The last ~15% of bytes are identical in each file" - does this mean "all encrypted files are equal" or "every encrypted file has the same bytes as the original file". Which is why posting examples is a good idea, it clarifies these inconsistencies quickly. Aug 5, 2015 at 7:15
  • Oh, and welcome to the site Hackndo, I've seen some good answers from you already. Aug 5, 2015 at 7:16
  • 1
    I'd say that "15%" is not really accurate, and maybe it was a fixed number of bytes N. Assuming this is what it is, then maybe tga files have N common bytes at the beginning. But that's a lot of if. You're right, examples would be great. (And thank you for this welcome !)
    – Hackndo
    Aug 5, 2015 at 7:22
  • Thanks so much for your information. I'll try all your suggestions out today and post back later. Unfortunately I don't think I'll be able to share the images, which is no fun! Aug 5, 2015 at 9:45

Don't be fooled by the .tga extention. Some developers add an extention to their files to throw people like us off.

Your files could easily be either, a different image type, an archive (zlib as an example) or an encrypted data. (In your case they just might be actual tga files.)

One method you could use to get the images that you are looking for is to go around the encryption. If theses files are indeed enceypted, then you could use its original engine to open the files as usual (boot the game). Then you could open the applications memory using a memory editor (such as CE). If you can locate the game data in memory, (at which point it would be decrypted) then you could ripp it out and rebuild it as the correct file type. You may have to do research on the tga file structure first.

Moreover, you could try poking around in the dll files (look for plain text in the header), and try to research their origin or functions, for all you know, those dlls could actually be compression or encryption libraries.

Lastly, I recomend a debugger like ProcessExplorer, pay attention to the offsets when the .tgas are loaded. That way you can determine it's structure.

You might wanna explore ollydbg, that way you could see the steps the application goes through before decryption.

Hope this helps.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.