I'd like to know whether it's possible to encrypt the compiled code in a Unity3D build in a way that de-compiling dlls won't give access to the legible source code to a potential hacker.
Cosmore pointed out in this post that it's possible to
'encrypt the assembly dlls and modify the mono loader (libmono.so)'
My question is, has anybody done this? If so, how? And can it be done on Windows, Mac and Linux builds?
If this is not possible, is there another way?
But the hacker should be capable to run the build (ie. play the game)?
Then in principle it's not possible. While you can encrypt the code, you have to also provide the key, so people can play it (decrypt).
So you are just adding one more layer of obfuscation for hacker. A seasoned hacker will simply disassemble the dll loader and put a breakpoint to a place where the content is decrypted already, and dump that for further tinkering.
That said, not every hacker is a seasoned hacker, and few layers of (unexpected) obfuscation may turn them away. So practically some encryption/obfuscation is done by some people, even if in principle it's hopeless.
Related
i try to find a good combination of libraries for managing a real-time communication (client/server) using Haxe (only Haxe, not openfl or other framework base on Haxe) targeting flash (swf) for the client and no preference for the server except don't use neko.
The goal is to make a simple tchat and put a display representation of all clients on an aera. Each client can move his representation in this area, and the other sees the movement.
I find some Lib to make this :
https://github.com/soywiz/haxe-ws
https://github.com/MattTuttle/hxnet
haxe-js-kit
But I'm not sure of the best way to adopt.
Do you have any suggestion/remarks/tips to choose the better way ?
Disclaimer: I wrote the library that I am sharing here.
My somewhat new library mphx may be able to help you. It can manage 'rooms' of connections, allows client to server and server to client messaging in the form of events, and best of all, is cross platform. It also works in the web with websockets.
It was originally an extention of HxNet, however I wanted it to be easier to use. Connecting and sending a 'message' with data just takes a few lines.
I have a few examples in the github repository, the simplest being the 'basic' example. One of your requests you have is that it doesn't rely on one of the big libraries (open fl, etc) and mphx doesn't. The basic example proves that, and only runs in terminal. That being said, it can be used with haxeflixel, for that you can see the other examples.
It sounds like your main goal is to have simple, graphic multiplayer. For that you can look at the 'movement' haxeflixel example.
Documentation is still a little skim, and the code is alpha, so it might change or break. That can probably be said for most of the library's you listed though. The best way to install it is like this
haxelib git mphx https://github.com/5Mixer/mphx.git
That will not install the examples though. To run them, either download the repository as a zip, or just git clone it, and go into the examples folder.
Library: https://github.com/5Mixer/mphx
Old video's I made. A little outdated, most likely.
Video 1: https://www.youtube.com/watch?v=07J0wLXwH0g
Video 2: https://www.youtube.com/watch?v=MUx2CUtsnTU
I have a bunch of R scripts which I am running on a Windows machine and want to ensure that the code remains unread by those not intended to see it. On a Linux box, I could wrap the R code in a bash script #! and make an encrypted (and perhaps even a limited-life) executable shell script. What are my options to do something on similar lines under Windows?
My answer is a bit late, but I believe this is a good question. Unfortunately, I don't believe that there is a solution, or at least an easy one, at the present time.
The difficulty is common because, for most interpreted languages, including R, it is often possible to turn on logging and inspection of all commands being run. This can negate many tricks to obfuscate the code.
For those who prefer to think of code being open == good, one should know that a common reason to obfuscate the code is if one is consulting with a client that hires multiple vendors. It is not uncommon for a client to take scripts from vendor A and ask vendor B why it doesn't work with their system. (This may be done by a low-level IT flunkie, rather than someone responsible for the NDA contracts.) If A & B are competitors, A's code has just been handed to B. When scripts == serious programs, then serious code has been given away.
The ways I've seen this addressed are:
Make a call to a compiled language, and use standard protections available there.
Host the executable on a different server, and use calls to the server to execute the calculations. (In R, there are multiple server-side options.)
Use compiled (preprocessed / bytecode) code within the language.
Option 2 is actually easier and better when the code may be widely distributed, not just for IP reasons. A major advantage is that it lets you upgrade the code without having to go through the pain of a site-wide release process. If new libraries are needed, no problem - update the server.
Option 3 is done in Matlab with .p files, and can be done with py2exe for Python on Windows. In R, the new bytecode compilation may be analogous, but I am not familiar enough with it to address any differences between .Rc files in the R context and .p files in the Matlab context. For more info on the compiler, see: http://www.inside-r.org/r-doc/compiler/compile
Hosting computations on the server is great for working with unsophisticated users, because it is easier to iterate quickly in response to bugs or feature requests. The IP protection is simply a benefit.
This is not a specifically R-oriented strategy. (And it's a bit unclear what your constraints or goals really are anyway.) If you want a cross-platform encryption method, you should look into the open-source program TrueCrypt. It supports creating encrypted files that can be mounted as volumes on any machine that supports the volume formatting method. I have tested this across the Mac PC divide , since the Mac can read FAT files, but have no experience with how it might work across the Linux-PC chasm.
(Their TODO list for Windows includes;"Command line options for volume creation (already implemented in Linux and Mac OS X versions)". So I don't see any clear way to use this from within R without you running the program from the OS.)
I don't think this is possible because the R interpreter has to be able to decrypt and read the code in order to execute it which means that whoever is using that interpreter will also be able to decrypt and read the code.
I am by no means an expert, so I reserve the right to be 100% wrong about that statement.
I believe the best solution is to ensure value comes from the expertise and services provided by your company and it's employers---not from keeping secrets.
Failing that, you could try separating the code into a client/server model. That way the client just sends data and receives results---they never have access to the code that runs on the server.
However, the scientist in me just said "that solution sucks and I would never trust results provided under such conditions".
I have inherited a project from a previous developer. All the ASP .NET code behind files are contained within a .dll and the original files are unavailable. Is there any reliable decompiler out there that produces fairly readable code? I've heard mixed responses while browsing other forums - some say there are applications that will decompile .dll files, others say they just produce practically unusable assembly code. Thoughts?
Thanks!
You could try Red Gate's Reflector with the FileDisassembler plugin. Also your heritage seems a little strange. What did the previous developer do with the source code? Didn't he use source control, performed backups? The usability of the source code produced by disassembling a .NET assembly will depend on whether the person that wrote the source code obfuscated it when compiling.
You cannot produce maintainable, properly-designed source code by reverse-engineering a DLL. With clever hacking, you'll be able to alter it to do specific things. Typically, you'll find tutorials on how to bypass licensing/registration checks. (Some of them for stealing my software!)
But your effort will be probably 10x harder than if you had the source code. IMO, you're probably better off treating it as a black box, studying the inputs/outputs, behavior, design documents (if any), etc.. Reverse-engineer REQUIREMENTS from what you see the DLL doing and what the host application needs to do with it. And then get funding/approval for a new project to build a new one. With source code!
Otherwise, your "inheritance" is a liability that you should quickly distance yourself from.
Edit: I missed the part about .net. I don't know much about that, your mileage may be better than a native binary.
--
Chris
I use jetbrains dotpeek
Sometimes you just have to decompile
I'm working on a closed-source game that uses a scripting language for automation. Almost all of the game logic is handled by scripts. Scripts can be compiled to a bytecode format, but due to the nature of the language, identifiers must be preserved. Compiled scripts can be embedded in other text-based resource formats using a binary-to-text encoding.
I want to encrypt the compiled scripts to protect the source during distribution, but because the language, bytecode format, and binary-to-text encoding scheme are all proprietary, do I need to worry about encryption at all? If so, should I simply perturb some bytes and call it a day, or should I make use of a fully featured encryption solution? Encryption should not increase the size of the executable unduly, because scripts can be large and load times are important.
On Windows, the size of the executable has no impact on load times because the exe is just mapped into memory and then paged in as needed. I can't imagine why that would not be true for *nix as well.
So, if the scripts don't need to change separately from your .exe, you could imbed them into the .exe, that would make them difficult for users to change even if they could find them. I wrote a little tool once that turned data files into .obj files that made it really easy to imbed data into my exe - it turned out to be pretty easy to write an object file that contains only data.
Of course, if you really care about protecting this data than full encryption in your only choice, but if you are just trying to discourage casual hacking, making the files hard to get at might be good enough.
You shouldn't assume that people can't read binary proprietary formats. There are many people who are very good at reverse-engineering protocols without any documentation.
So if you want to keep your source safe, you need some real security. The only problem is that if you encrypt the files, you'll need to give your users the decryption key in order to play the game, and when you do that then its only a matter of time before someone works out how to get the key and use it to decrypt all the files.
So basically, there's not much you can do unfortunately. You could try obfuscating your code, but even that's not going to stop everyone.
What you're talking about isn't going to be encryption, because you're going to have to ship the decryption key with it. It's just obfuscation. No matter how much you try to hide the decryption key, if your program can find it, so can the user.
So once you understand that we're just talking about various obfuscation schemes, the question is how much obfuscation you need. Likely the proprietary byte-compiling is a higher barrier than the encryption would be, and I'd call it a day. Anyone who wants to trace the logic can just put a debugger on it whether you encrypt or not. If they've already reverse-engineered your run-time engine to work out the byte-codes, then they're already in the portion of the code that has the unencrypted data.
That said, if you find the identifiers in the file to be problematic you can mechanically converts them to random strings prior to byte-compiling.
Encryption would not buy you much here.
Basically, whatever encryption layer you add, the executable itself must be able to perform the decryption in order to run the scripts. You lock the door, but you leave the key in the lock. This is unavoidable.
What encryption does is that it somewhat raises the bar on who may access the data. It requires some disassembly skills. Simply embedding the files in the executable will already filter out the casual not-very-good hacker. Those who are not deterred by such embedding are also those who will be able to follow the data processing path, find the decryption logic, and siphon out the decrypted code at will. A layer of encryption may also increase the feeling of importance: that which was encrypted is certainly worthwhile. Hence, trying too funky things may just make your situation worse, not better.
On the other hand, embedding the files in the executable binary is probably a good idea. It would remove the need to locate them at runtime on the filesystem (locating things at runtime is known to be somewhat more difficult on Unix systems than on Windows, because of hard links: on Windows, an executable can easily obtained its own path, but on Unix the presence of hard links means that "the" executable path is ill-defined).
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
I've written (most of) an application in Flex and I am concerned with protecting the source code. I fired up a demo of Trillix swf decompiler and opened up the swf file that was installed to my Program Files directory. I saw that all of the actionscript packages I wrote were there. I'm not too concerned with the packages, even though there is a substantial amount of code, because it still seems pretty unusable without the mxml files. I think they are converted to actionscript, or atleast I hope. However, I would still like to explore obfuscation.
Does anyone have any experience with Flash / Actionscript 3 / Flex obfuscators? Can you recommend a good product?
The procedure suggested by maclema will not really stop any attacker from obtaining the source - the "wrapper application" will need to be unencrypted so the attacker will be able to find out that you use AES (or any other algorithm) and he will obtain the decryption key in a similar way (because it needs to be in plaintext somewhere). Once he has this, he will be able to decrypt your SWF file easily.
The only reliable solution (well...) is some kind of obfuscator - we use Amayeta which works for Flex in the latest version - please see http://www.amayeta.com/software/swfencrypt/ .
Here's what I would do.
Compile your application to a SWF file. Then encrypt the SWF using AES.
Make a "wrapper" application that loads the encrypted SWF into a ByteArray using URLLoader
Use the as3crypto library to decrypt the swf at runtime.
Once decrypted, use Loader.loadBytes to load the decrypted swf into the wrapper application.
This will make it a lot harder to get your code. Not impossible, but harder.
For AIR applications you could leave the SWF encrypted when delivering the application to the end-user. Then you could provide a registration key that contains the key used to decrypt the SWF.
Also, here is a link to an AS3 obfuscator. I am not sure how well it works though.
http://www.ambiera.com/irrfuscator/index.html
Well, in my opinion, the easiest and safest solution is a mix of maclema and Borek answer:
Obfuscating code can be a big headach if you did not include it in your process from the start and if your aplplication is quite big: it's likely that obfuscation make your application corrupted if you used remote packages (and did not declare this to the obfuscator) if you used to many unTyped variables in Objects or dynamic classes ....
So: if you do maclema's solution on your big application and use obfuscation on your wrapper (which is a small app likely to be very easy to obfuscate) you're code will be the safest and the hasle the least.
Only a very angry pirate would take the time to reverse engineer the obfuscation to then decrypt the package .... Well if someone wants your application code soo bad it's either CIA related or you're already very rich (or both)
thank you all for your answers
I recently released an iOS and Android game using Flash. I looked around the internet for a good free program to protect the source code in my SWF and couldn't find anything so I wrote one. It's still in development and it's "use at your own risk" but it worked for me.
It's released on github. Check it out and let me know what you think.
https://github.com/Teesquared/flasturbate
I uploaded a windows binary but I recommend you follow the instructions to build it yourself if you want to give it a try.
This obfuscator works directly on the SWF file. It currently only renames symbols but it is built on a framework that could support altering bytecodes in the future.