[edit] Making runtimes unreadable in Blender

For those naive people that think that posting a *.exe file rather than a *.blend file will keep people from reaching the *.blend file, you are sorely mistaken…

I have just successfully extracted a blend file straight from a runtime, and don’t think others can’t!

However, I was wondering, is there a way to safely secure the blend file?

(If this has already been posted somewhere, feel free to delete this post.)

A .exe file that has been made in blender can be opened in blender, its as simpel as that.

And most people know this. :wink:

lol beat u to it NOR.J :stuck_out_tongue:

No. Even without the “safely”.

Also, as NORJ pointed out, this is nothing new and actually well known…

Just by some secounds! :slight_smile: :smiley:
Lol this has happened before…
Sometimes 3 at a time(3 people thaught they were the first one posting :smiley: )

Lol, actually there’s a way to make your blend save for people trying to open it. The key.dat file is written in not binair, but something else. The only thing you need to find out is how the key is build, what’s the logic and so on. If you know that you can easely create your own with python. :smiley:

i know how i can protect my .blend files.
With python

and I know that way doesn’t work

in part because the python code is entirely visible if I open the file [in say, MS notepad], also in part because I can disable running python scripts when the file is loaded or whenever I want [particularly if I use my own build of blender]

a method I haven’t seen used [it probably isn’t worth the effort for anything coming out of blender] is to modify the .blend and your version of blender [with a hex editor if necescary] so that meshes get loaded corrupt, and probably textures too, if not being loaded using your routines.

but, like commercial games, if anyone really cares there is NOTHING you can do for this kind of thing

[but, something like what valve is doing with hl2, namely sending an encrypted 1Gb file prior to release is inheritly a lot more secure because the key and extraction method is not stored in some easily accesable place [they have it, and they are unwilling to give it away until the game comes out]]

once the game comes out, and the key becomes public there WILL be ways to work around the steam authentication that you actually bought the game, there is nothing that can be done

furthermore, some security options have become less feasable with xp service pack 2 [on 64 bit systems with these features] because it disables self modifying code [and buffer overrunns and underrunns], except on a per-application disabled basis

z3r0 d
I dont mean using python in the .blend file.
I am talking about encrypting the file.

make a pythonscript that encrypts the .blend file.
I have done that.

You’re right… you can encrypt a file. This is as good as the key you encrypted it with and the system you use to handle the key-value. Trouble is, if you want anyone to actually be able to play your game, you must give the the ability to de-crypt it. At which point they could, if they so chose, “open the unencrypted .exe file” (they copied it while the game was running, of course) and “there you are.”

You can get paranoid about this. Instead of making it difficult for people to get your game and play it and thereby fall in love with it, you want to make it easy. If that means they open it and look at what you did, then you win twice! :wink: Not only can they play this, God’s Own Gift to Gaming, they can also open it and stare, in open-mouthed adoration, at the paragon of programming talent! :wink: :smiley:

sundialsvc4
You are so right, why should we pasword protect or encryt our files? like you said ‘Not only can they play this, God’s Own Gift to Gaming, they can also open it and stare’. :smiley:

I just want to find out if i CAN encrypt my files. That dosent mean that i WILL do it in my games.

Life can be boring, and you get curius if you are good enaf to do things.
Personly i try things just to see if i CAN do it, If im smart enaf. Its like hackers, if you ask a hacker Why did you hack fbi(or something simular), they would say: Not WHY, its HOW.

:smiley:

Yes, there are many commercially and publicly available tools that will encrypt an executable so that it prompts you for a password in order to open its content; and does so with an algorithm that is actually cryptographically “real.” You don’t need to write it.

I’ve done a lot of searching, but the only programs I can find that can obfuscate the program require the source code… All it really does it scramble everything up (which can’t be reversed) so that understanding it would be nearly impossible, although the actual program, when run, remains the same.

Is there anyway to get the actual “source code” for the blend file? (That is, after it becomes an executable…?

sure, just open the .blend in a hex editior and export as an char array hex
[I’ve done this before]

of course, that means it will probably not be encrypted in the resulting executable [unless they copy to another memory location after extracting and try to exectue there, this will become more difficult when people move to 64 bit chips because of the NX [no execute] which forbids [if enabled] self modifying code like that]

what program can do that?

I’ve tried using programs that encrypt my exe directly it starts out ok but after yo get past the passcode screen or 30 day trial promps it usually crashes the game. If you are really concerned about people seeing your hard works, then copyright it all. Source code can be copywritten as well as patented. By the way just putting Copyright©2004 Company X will not work. The copyrights have to be filed (Whether poormans or legit) or that doesn’t mean squat. A good 90% of gamers don’t really care how you made the game as long as it is easly playable. So trying to figure a way to encrypt data may actually be too much of a pain on you as well as the player. If it is really important to you then create a setup file that has a security check before they can even install it first (This is what EA Games does).