recompiling a blitz exe?
Blitz3D Forums/Blitz3D Programming/recompiling a blitz exe?
| ||
| Hello, Is it possible to recompile a blitz exe? Or in other words, If I have a compiled Blitz EXE file, Is it possible to turn the compiled code back into a readable sourcecode? Can I get sure that nobody can read secret data stored in the exe file? thanks in advance :) |
| ||
| No. Or at least, not unless someone wanted to go through each of the millions of machine codes and try to work out what they do... but there's no reliable way for them to reconstruct anything resembling a Blitz program from that. The one exception is that strings (Local s$ = "My String Literal") will appear unencrypted in the final exe. So if anything important is kept in strings, it will be readable as plaintext to anyone who opens the file in a hex viewer (or text editor!). Obviously this only applies to strings actually written out in the program source, not ones constructed at runtime - so you could for instance store things in encrypted form and decrypt them before the program runs. You really don't need to worry about this. |
| ||
| Thank you very much yasha. If someone here has a different opinion, please let me know. |
| ||
| No But I dont think its as impossible as Yasha made out. But no |
| ||
| thank you. You say its not as impossible as Yasha made out. But then under wich circumstances do you think would it be possible? |
| ||
| A lot of people working on it |
| ||
| how much people? 2-3 or 20-30 and how long would they probably need? Hours, Days or Weeks? And what would this people do to get the sourcecode? thanks again for your help:) |
| ||
| Depends on the size, but for a project big enough for you to care about them stealing it (~tens of thousands of lines) you're talking weeks or months of work for a decent-sized team of experienced hackers. The reasoning is quite simple: Blitz3D is a "high-level" language. It contains features such as functions, types, variables, loops etc. to make code structured and readable. Machine code doesn't have those things; in simplistic terms, machine code really doesn't offer much beyond If, Goto, and numeric memory addresses. So the best even a team of experienced hackers could do is get some code with no variable names, and no functions or control structures because everything is done with Goto (if they're really clever, they might be able to represent the functions as Gosubs). There is no way they would ever get source code that actually looked like the original, because that level of information simply isn't preserved by the compilation process. Seriously. You don't need to worry about this. There's nothing you could possibly produce in Blitz3D that it would be easier for someone to decompile, than to simply spend a few million dollars, hire a development team of several hundred, and crank the clone out from scratch. That's how hard this task is. Simple example:
While a < b
a = a + 1
Wend
...becomes (at best)... .L_0 If V_0 < V_1 Then Goto L_1 V_0 = V_0 + 1 Goto L_0 .L_1 Now crank that level of uglification up by an order of magnitude to also account for functions, nested loops, arrays and types (neither of which exist, so you're dealing with raw memory address calculations), and so on. Even a slightly more complex application than the above becomes nightmarish to understand, especially for anyone who is trying to work out what it means rather than knowing in advance. A far better idea than worrying about this is to simply attach a copyright notice to your code, and let the law protect your intellectual property if you think someone is stealing your work. Last edited 2011 |
| ||
| If on the other hand you are just worried about people finding the "Read" data in the middle of the exe. That is they dont need to figure out the function types and stuff, just find somewhere to have gone data1: 1,34,46,33 etc Then one person being lucky, and preknowing something about the data, (say a map for example), then two hours comfortably. |
| ||
| We can expand on Yasha's post to also cover media assets: There is no evidence that renowed game companies encrypt their media files for the sole purpose of preventing people from opening them. Still, you can't just go and open a model file from a triple-A game - it's not like it's in .XSI or .MD2, it's a different format. There are two main reasons for game files to be released in these 'not clearly readable' formats: • Compression: more important in removable-media games (such as CDs and cartridges) where developers have a limited space in which they can store data. They compress their original asset files with proprietary tools that use proprietary compression schemes. Some of these schemes might even be directly implemented in hardware, such as specialized compression for textures, video etc. and are blazing fast to operate. You can also see how the Quake series uses PAK files which are simply all the asset files compressed and bundled in a single pack. Modders can open these PAKs and modify them as they wish. • Memory Structure: when you load an asset in your game you also create and populate a custom structure with this loaded asset and any pertinent information (say, for instance, a mesh class that holds vertex declarations, triangle indices etc.). What developers do is process their assets with tools that create binary files of these populated structures. They grab the data currently in memory and write it as a file. What you get for each processed file is a 'blob' of data that can be loaded in a single sweep and is ready to be used by the engine, which is incredibly faster - the engine doesn't have to seperately load the asset (parsing whatever specification the asset uses, such as 3DS or OBJ) then build a structure and populate it with data at load-time. So when they release their game, they won't include any original asset files, just these processed binary files. These two reasons indirectly contribute to the 'not clearly readable' formats we find in professional game files, while their purpose is optimization and efficiency, not protection. With this in mind: You're much better off investing time in writing a clear and broad license to protect all your intellectual property. While encryptions can be broken, a concise license is your ultimate defense in case someone does actually breach your terms with actions that do not constitute 'fair use'. |
| ||
| There are a few games where assets have been encrytped purely to try and stop people using them outside of the game. One of the main reasons for using large packages containing several files is for updating - its a lot more efficent to check they have the latest package file than checking individual files - even if your updater then works on individual files within the package to update it. Proprietary data formats are usually used for either supporting features not found in generic/common formats or for efficency i.e. Quake 2 MD2 used integer coordinates for performance (as it mostly works within the scale of the game without that noticeable issues) whereas most commonly used mesh data formats will use floating point coordinates. |
| ||
| unassembly is a very hard thing, but as H&K says, if one is looking for a particular sequence, knowing some thing about what we are looking, then ins't so hard to do. Antivirus software looks for some specific "signatures" and the like trying to recongnize some specific set's or sequences of bytes, not trying to decode anything (it's not only this and so simply, but is something that they do) i remember to read (yes many year ago) in some "gamers publications" to open some file with "debug", then do some very extrange commands like: e 22A3 3A, F3 (enter) and then W.... many years later i realize what about this actions can do: open a .dat (or similar file) write in a new value (for the Lives, armor, ammo etc) and then saves (W) the newly modified values on the file, so the next time you play the game, you were invencible, or in the level 10 that never reached! i think that the ones that posts this articles in this publications wherent investing much money on that, simply know specifically what they are looking for. it isn't an imposible task, to do but in a general form: say from exe to .bb I don't belive that such a thing could be done in a reasonably time/cost. But if looking for a particullar thing, like "licence key", well only do some Google and you will find millions (or at least the one you are looking for) of Cracked soft all over the net. the question is, "did I a soft that any/some hacker want/need to crack?" if the answer is no then there will be no problem, Juan |
| ||
| ^^ Yeah dis-assembling software to work out specific features is difficult but far from impossible. A complete decompile of the executable to get the original source code is impossible generally but it is possible to decompile large segments of working code that do the same thing as the original source even if its not the exact same construction. Last edited 2011 |
   |