[RESOLVED] Protect my Game's program files

Hi.

I have a game with like a million of resource files (.PNG; .BMP; .WAV; .MP3; ETC) Iv been working on these files for like.. a Year, I don't want these wannabe litle kids, etc, to steal my work just like that.

So I was thinking of crypting the files, so that If my game need to load them I have to put something like this:

VBCode Code:

If (Check_If_The_File_Is_Crypted("c:\test.png") = False) Then
    MsgBox "Error"
    Exit Sub
End If
 
'// Decrypt so we can load it.
Decrypt_File ("c:\test.png")
 
'// Load the file:
Load_File ("c:\test.png")
 
'// Crypt it back.
Crypt_File ("c:\test.png")

By decrypting them when we need them, or at least adding some junk data to the header of each file, so that the user will get: Uknown format or corrupted file.

But... This is so amazingly slow, knowing that my game have to load like a thousand files, and with this it takes 3 times longer.
Anyone have a better (fast) idea, to stop the user from seeing my "program files"?


Thanks.

Put the files in a resource file.

BTW if you need an example, my Picture/video Viewer uses one.

加壳...........vm什么的，多加壳！！！！！还有反调试！

English only please.

Quote:

---

Originally Posted by reacen

...
But... This is so amazingly slow, knowing that my game have to load like a thousand files, and with this it takes 3 times longer.
Anyone have a better (fast) idea, to stop the user from seeing my "program files"?

---

Maybe your encryption/decryption routines are too slow or do too much.

When you decrypt a PNG, it appears you are rewriting the decrypted PNG to a file. A waste of time: read the encrypted PNG into memory, decrypt it, load the PNG from memory. Should improve loading time I would think.

Rewriting the decrypted data back to file, whether WAV or PNG or whatever, does allow the user to grab that information while your game is in play; because now it is not encrypted, correct?

For most of your file formats: PNG, BMP, WAV, etc, you should only need to scramble a few key bytes to make the file unreadable. If you are encrypting 100s of bytes, again, maybe a waste of time.

Last but not least, your game shouldn't need to load a 1000 files at once, load them when needed.

vb Code:

dim LMAGIC(31) as byte, X as long
rnd -1
randomize 101
 
'you can precompute this, to save some time
for x = 0 to 31
lmagic(x) = Int(Rnd * 255)
next x
 
dim bData(31) as Byte
dim bCrypt(31) as Byte
Open "c:\test.png" for Binary #1 'always binary!
  if LOF(1) > 31 then 'ensure we have enough data to encrypt
    Get 1,1, bData
    For x = 0 to 31
      bCrypt(x) = bData(x) Xor LMAGIC(x)
    Next x
    put 1,1, bCrypt
  else
    'file is under 32 bytes... this is probably not an image
  end if
close #1

:wave:

PS it both encrypts and decrypts with the same code

Quote:

---

Originally Posted by MartinLiss

Put the files in a resource file.

---

Good idea, but some functions I have need files from PATH location (c:\xxx.xx) and can't be loaded from memory [ie: LoadPicture() ].

Quote:

---

Originally Posted by winnip

加壳...........vm什么的，多加壳！！！！！还有反调试！

---

Uuumm.. Packers? Im not sure.

Quote:

---

Originally Posted by LaVolpe

When you decrypt a PNG, it appears you are rewriting the decrypted PNG to a file. A waste of time: read the encrypted PNG into memory, decrypt it, load the PNG from memory. Should improve loading time I would think.

---

Yes, you are right, but still can't load BMPs and WAVs, MP3s, from memory. :sick:
The functions, and APIs I have need a string PATH location to load them.

Quote:

---

Originally Posted by LaVolpe

Rewriting the decrypted data back to file, whether WAV or PNG or whatever, does allow the user to grab that information while your game is in play; because now it is not encrypted, correct?

---

Actually, once the file is loaded, it will be encrypted befor loading the next file.

Quote:

---

Originally Posted by FireXtol

(CODE)
it both encrypts and decrypts with the same code

---

Thank you for your peace of code, Maybe i can use something like it for speed when encrypting.

Quote:

---

Originally Posted by reacen

Good idea, but some functions I have need files from PATH location (c:\xxx.xx) and can't be loaded from memory [ie: LoadPicture() ]....

---

Once you have the picture (or whatever) in the resource file you no longer need to worry about any path.

Quote:

---

Originally Posted by reacen

Yes, you are right, but still can't load BMPs and WAVs, MP3s, from memory. :sick:
The functions, and APIs I have need a string PATH location to load them.

---

Though loading from memory may not always be an option, Bmps and WAVs (depending on API used to play it) can be loaded from memory. Not sure about MP3s.

Quote:

---

Originally Posted by reacen

Actually, once the file is loaded, it will be encrypted before loading the next file.

---

So your code is reading, decrypting, loading, encrypting, writing? If so, maybe this will speed some things up?
1. Load file into array
2. Copy to another array, keep encrypted data temporarily
3. Decrypt 1st array and then load the file
4. Write the 2nd array back to the file
The idea is that you don't do the encryption twice. However, if your encryption routine is very fast; this won't be a time saver.

BTW in my Picture Viewer app a JPG named leaves.jpg shows up as the background for Help|About. While that file is supplied in the project's zip file, it's not needed because it's already in the resource file.

Making the images into resources doesn't protect them at all. Anyone with a resource editor can still get to all your icons, cursors, and bitmaps(etc.), and even change them!

You'd be far better off making your own simple file format(then they'd have to decipher it themselves, instead of having readily available programs), or you could even use one of many archivers(with a password), that only your application knows(definitely choose one for speed).

GDI+ supports loading files from streams(a byte array). LoadPicture is buggy, but is not really an issue if you don't use user-supplied images(and have verified it works with all of yours), and, of course, if it supports all your desired file types. One of the bugs will make your program freeze, while other decoders work just fine.

Well, I have this function that I use to load BMP files to hDc memory, if It can load from memory (instead of file path) without using GDI+. That would be great. :D

vb Code:

Public Function LOAD_BMP(PATH As String) As Long
 
    Dim BUFFER As Long
 
    Dim X1 As Long: X1 = GetDC(0&)
 
    BUFFER = CreateCompatibleDC(X1)
    SelectObject BUFFER, LoadPicture(PATH)
 
    DeleteDC X1
    LOAD_BMP = BUFFER
    
End Function
 
'// ---- And when using it:
 
Dim MyBMP_hDc As long: MyBMP_hDc = LOAD_BMP("c:\test.bmp")
 
'// When drawing in a loop:
Bitblt stuff, stuff, stuff, ..., MyBMP_hDc, stuff, stuff...
 
'// And when Im finish with the picture:
DeleteDC MyBMP_hDc

Can I make this function load a BMP from a Variable, that contains the BMP file's binary DATA ??? Without the GDI+ (PLUS).
This way I'll append all the BMP files I have in only one file, then split that file when loading, Im sure it'll be like 10 times faster when loading. :)

Statements like load from memory should be clarified: load from stream/array is what I was referring to in earlier posts. Look at this function: ArrayToPicture. That function is basically the same as VB's LoadPicture but uses an array vs. a filename. GDI+ is ideal for PNGs.

Yay! Your function is working great, and its fast. This is sooo cool thanks LaVolpe! Now I can have only one big heavy file that contais all the BMPs (That i'll crypt only once) :D
I'll google the rest. Thank you all guys.

But whats this:

Quote:

---

LaVolpe says: If array is invalid or does not contain a valid picture, lock up can occur
---------------------------------------------------
I have sample GIFs that will lock up VB's LoadPicture() function too

---

What do you mean by lock up? The game will freez, crash or something?

Quote:

---

Originally Posted by reacen

...But whats this...

What do you mean by lock up? The game will freez, crash or something?

---

YES! If you can't use VB's LoadPicture with the file, then do not use ArrayToPicture with the file's bytes. If you have GIFs that will lock up VB, then those GIFs are not well-formatted (probably missing an encoded block terminator).

Quote:

---

Originally Posted by FireXtol

Making the images into resources doesn't protect them at all. Anyone with a resource editor can still get to all your icons, cursors, and bitmaps(etc.), and even change them!...

---

Well sure if you distribute the source code along with the resource file, but if you create an installation package I don't believe there's any way to get at the resource files. BTW if I'm wrong I'd be interested in how it's done.

Quote:

---

Originally Posted by MartinLiss

Well sure if you distribute the source code along with the resource file, but if you create an installation package I don't believe there's any way to get at the resource files. BTW if I'm wrong I'd be interested in how it's done.

---

One such program is called eXeScope(there are others, though). Unless you obfuscate the PE structures(UPX, for instance)... or encrypt the resources, eXeScope will have no troubles retrieving, and modifying them directly from an EXE.

It doesn't seem to be able to identify a picture that has been loaded into a Picturebox(at design time, though I've also seen programs developed specifically for VB programs which can), but it has no problems with resources(the RESOURCE fork of the PE). Which includes version information, cursors, icons, bitmaps, custom, etc.