I'm currently researching a subject and I honestly lack the knowledge to even be sure whether it's possible at all.
I want to find out if it is possible to understand the process memory of a .NET application when I don't have the source / the PDBs. With understand I mean if I can reconstruct an object graph if I find some starting point, like a known string value.
We want to protect a program configuration that is deserialized from encrypted config files. It is unencrypted in memory. The single values in the configuration graph aren't really secret, but the graph itself is of value.
The questionis if it is possible to reconstruct the graph from the process memory only?
Given the attacker knows how to use something like dnSpy to reconstruct the assemblies (that we protect on disk too) and that we don't want to obfuscate the config assemblies (which would require a lot of changes), can the attacker reconstruct or understand the instances based on the raw memory of our process?
I tried researching this, but I cannot find the right direction / good keywords for what I'm looking for.
I understand that tools like CheatEngine exist or that I could simply dump out the whole memory and try to make sense of that.
But I'm trying to understand if there's a .NET tool that automates the process:
Read the decompiled assemblies with the config classes
Attach to the process and dump the memory
Make sense of the bits and bytes and combine with the decompiled classes to reconstruct the instance hierarchy
My main goal is to decide whether or not additional protection of the in memory config graph is needed. If it's not easy to reconstruct the graph, then I think it's not needed. But if it would be as easy as decompiling the source code of a .NET application, I think some protection would be required.
"it is possible to understand the process memory of a .NET application when I don't have the source / the PDBs."
Yes, it is possible. In .NET there is a concept called garbage collection. The garbage collector needs to know how the memory looks like, otherwise it can't do his job. And this needs to work on customer's machines, which don't have PDBs and don't have source code.
There is a DLL called MSCORDACWKS, which is MS for Microsoft (probably), COR for .NET and DAC for "data access control" and WKS for "workstation". The DAC in this name is what you need.
Typically you don't do that yourself, but use a debugger (Micosoft WinDbg) and a .NET extension (SOS) which knows how to deal with the DAC to understand the memory.
For examples and other questions regarding these topics, see windbg and sos. It is in fact very easy. Try !dumpheap -stat to get a list of all .NET objects.
The questionis if it is possible to reconstruct the graph from the process memory only?
With !gcroot you can start building an object graph, if you like.
For object graphcs, you might better look into existing tools that build such graphs, like memory leak tools such as Jetbrains dotMemory.
The single values in the configuration graph aren't really secret, but the graph itself is of value.
This could be a case to call GC.Collect() in code to force a garbe collection, so that the graph is gone. However, with a debugger it's possible to stop the process before that call.
whether or not additional protection of the in memory config graph is needed.
IMHO, yes. And implemented in a native language like C++.
Related
so I am trying to protect my game from memory scanners without using a server the protection doesn't need to be 100% but I want to try and protect them from most of the cheats I have an idea to try and change the address of the variable once a few seconds or maybe even on the onUpdate method but I don't know how to do that on the code without breaking the game, I know that has to be possible since there are some add-ons in the unity store that gives you classes like ProtectedInt that are like the original data types but can't be detected by software like cheat engine I can buy the addons but I wanna try to do without buying it..
is there another way I can protect my variables is my idea is possible to do without breaking or losing the value of the variable?
This is a simple little tutorial on protecting variables, prefs and such. Utilizing ILSpy for validation. It's a great read. At the least you should install ILSpy.
https://www.alanzucconi.com/2015/09/02/a-practical-tutorial-to-hack-and-protect-unity-games/
You might try using Windows Data Protection API exposed in .NET through System.Cryptography.ProtectedMemory, quick tutorial can be found here. Another writeup of the method includes a relevant note about copies of the unencrypted array being left in memory as a result of garbage collector defragmentation process.
General approach to protect different objects in your application would involve using binary de/serialization into an array, which you would then protect using the above method. Check out this answer to see how to do that. Once you have MemoryStream, use its method ToArray() to get the array.
I am embedding IronPython into my game engine, where you can attach scripts to objects. I don't want scripts to be able to just access the CLR whenever they want, because then they could pretty much do anything.
Having random scripts, especially if downloaded from the internet, being able to open internet connections, access the users HDD, or modify the internal game state is a very bad thing.
Normally people would just suggest, "Use a seperate AppDomain". However, unless I am severely mistaken, cross-AppDomains are slow. Very slow. Too slow for a game engine. So I am looking at alternatives.
I thought about compiling a custom version of IronPython that stops you from being able import clr or any namespace, thus limiting it to the standard library.
The option I would rather go with goes along the following lines:
__builtins__.__import__ = None #Stops imports working
reload = None #Stops reloading working (specifically stops them reloading builtins
#giving back an unbroken __import___!
I read this in another stack overflow post.
Assume that instead of setting __ builtins_._ import__ to none, I instead set it to a custom function that lets you load the standard API.
The question is, using the method outlined above, would there be any way for a script to be able to be able to get access to the clr module, the .net BCL, or anything else that could potentially do bad things? Or should I go with modifying the source? A third option?
The only way to guarantee it is to use an AppDomain. I don't know what the performance hit is; it depends on your use case, so you should measure it first to make sure that it actually is too slow.
If you only need a best-effort system, and if the scripts don't need to import anything, ever, and you supply all of the objects they need from the host, then your scheme should be acceptable. You can also avoid shipping the Python standard library, which will save some space.
You'll want to check the rest of the builtins for anything that might talk to the outside world; open, file, input, raw_input, and execfile come to mind, but there may be others. exec might be an issue as well, and as it's a keyword it might be trickier to turn off if there are openings there. Never underestimate the ability of a determined attacker!
I have embedded Iron Python in apps before and shared similar security concerns. What I did to help mitigate the risk was to create special objects just for the scripting run-time that were essentially wrappers around my core objects that only exposed "safe" functionality.
Another benefit from creating objects just for scripting is that you can optimize them for scripting with helper functions that make your scripts more terse and tidy.
Appdomain or not, there is nothing stopping somebody from loading an external .py module in their script.... Its a price you pay for the flexibility.
I want to run a thread that checks the memory image of the current executable, for protection reasons. Any ideas how to do CRC on the current memory executable (WinAPI or .NET way)? My app is written in .NET.
Signing your assemblies will give you as good verification as you can get with relation to verify CRC of .Net assembly (see Rodrigo's answer).
If you are worried that someone will patch assembly at runtime you probably worried too much. It requires better understanding of runtime to in memory patch IL for a method that is already JIT'ed compared to simply disassembling your .Net code and fixing it up (including removal of your CRC checks).
If you doing it more for fun than you shoud be able to find base address where assembly is loaded and compute CRC of some sort... or see if pages are marked as modified...
I think that's going to be quite difficult in .NET. When an executable is loaded, it can potentially be split up and loaded into several different regions in memory. You'll need to acquaint yourself with the Window's Executable format:
http://www.microsoft.com/whdc/system/platform/firmware/PECOFF.mspx
as well as the Windows executable loading process.
You'll might also want to concern yourself with depenency dlls as well. You'll be making so many native calls, that you might want to consider doing this in C.
Not much of an answer, I'm afraid.
Any runtime check you do will have the following drawbacks:
False positives. Because this is .NET, you cannot assume the runtime doesn't modify your in-memory code. You may detect a hack where there is none.
Any run-time check you make will be no more secure than the code you are trying to protect. This includes any runtime mechanism you create in your app such as periodic CRC checks, sentinel processes, or even checking with a server where the request can be faked.
You will decrease performance in your legitimate application, where the pirated version will run better without all these checks
You will do nothing to solve patching your EXE.
I understand that you are just trying to make it as hard as possible, even though it's not 100% uncrackable. But the solutions you propose (and likely any solution you can implement yourself) will do extremely little to thwart any average cracker.
Because this is such a demanded feature though, I would look for 3rd party solutions where they have put forth the effort for a sophisticated solution which can be updated as cracking techniques evolve. I cannot recommend any personally though.
I am not aware of a way to do this in .NET.
If you are interested in protecting you executables, you can generate a new key with sn and add it to AssemblyInfo.cs, so that if the application is modified at least it will not run.
Jon Skeet's Miscellaneous Utility Library contains a method to compute the Adler32 checksum on a stream. Its usage would be:
MiscUtil.Checksum.Adler32.ComputeChecksum(stream);
As for creating a memorystream out of the assembly that is currently running... I don't know if that is even possible (or advisable).
We are about to use Code Protectors (Obsfucation as well as Native Compilation), I assume ORMs will be dependent little bit on Reflection and I am worried will Obsfucation and Native Compilation protection techniques create any problems?
Has anyone tried successful ORM and Code Protection for any good desktop application? We are having WPF Desktop Application.
Our primary language for development is C# and we are using our custom ORM but I want to evaluate any commercial ORM or ADO.NET EF etc as well.
Question is not about what is Code Protection and which one I should use, I am trying to ask about the effect of protection on ORM.
If your code is using Reflection, most probably the obfuscated assembly will not work. You will need to exclude from obfuscation those entities referenced by their original name. Take a look at Crypto Obfuscator which will analyze your code during obfuscation and show all methods and line numbers where potentially breaking methods (such as Reflection ) are called. This is a huge timer-saver since it pinpoints the exact location and helps determine the properties/classes you need to exclude from renaming.
Try .Net Reactor. Available at http://www.eziriz.com/
Its a LOT cheaper than some of the others around, and it can do a lot more. You can also disable certain options (like obfuscation, to preserve the use of reflection) and only have certain options enabled like ILDASM Suppression, which will still protect the code.
Cheers
Redgate acquired Smart Assembly not too long ago, which is what I'd look at if I had a need to do this.
A while ago I trialed CodeViel to look at obfuscating/encrypting code with some degree of success. I think if you’re serious about doing this it’s not as simple as dropping an assembly in one end and it popping out a protected assembly. You will have to consider portions of your code (ie Namespaces, Classes, Methods, Fields, Properties, Structures, Events, and Resources) which are only to be used internally, and those that need to be exposed to other resources and libraries. In the case I was looking at I was able to encrypt (or use native compilation) to hide some method implementations, but left the class definition (name, methods, properties untouched). In some cases I left whole namespaces untouched as they contained only simple POCO objects required by other libraries.
It really seems to be a careful case by case basis as to what strategy you use where, some internals you could obfuscate to make decompilation/reverse engineering hard and that would be enough. Other cases you could use the encryption/native compilation to simply hide a method implementation. And you will also get cases where you are excluding portions of an assembly from being touched at all. Most of these programs will give you some recommended defaults and options that you can start from, but you will need to tweak and change these until you can produce results that protect your core IP but don't restrict your end users.
How do I protect the dlls of my project in such a way that they cannot be referenced and used by other people?
Thanks
The short answer is that beyond the obvious things, there is not much you can do.
The obvious things that you might want to consider (roughly in order of increasing difficulty and decreasing plausibility) include:
Static link so there is no DLL to attack.
Strip all symbols.
Use a .DEF file and an import library to have only anonymous exports known only by their export ids.
Keep the DLL in a resource and expose it in the file system (under a suitably obscure name, perhaps even generated at run time) only when running.
Hide all real functions behind a factory method that exchanges a secret (better, proof of knowledge of a secret) for a table of function pointers to the real methods.
Use anti-debugging techniques borrowed from the malware world to prevent reverse engineering. (Note that this will likely get you false positives from AV tools.)
Regardless, a sufficiently determined user can still figure out ways to use it. A decent disassembler will quickly provide all the information needed.
Note that if your DLL is really a COM object, or worse yet a CLR Assembly, then there is a huge amount of runtime type information that you can't strip off without breaking its intended use.
EDIT: Since you've retagged to imply that C# and .NET are the environment rather than a pure Win32 DLL written in C, then I really should revise the above to "You Can't, But..."
There has been a market for obfuscation tools for a long time to deal with environments where delivery of compilable source is mandatory, but you don't want to deliver useful source. There are C# products that play in that market, and it looks like at least one has chimed in.
Because loading an Assembly requires so much effort from the framework, it is likely that there are permission bits that exert some control for honest providers and consumers of Assemblies. I have not seen any discussion of the real security provided by these methods and simply don't know how effective they are against a determined attack.
A lot is going to depend on your use case. If you merely want to prevent casual use, you can probably find a solution that works for you. If you want to protect valuable trade secrets from reverse engineering and reuse, you may not be so happy.
You're facing the same issue as proponents of DRM.
If your program (which you wish to be able to run the DLL) is runnable by some user account, then there is nothing that can stop a sufficiently determined programmer who can log on as that user from isolating the code that performs the decryption and using that to decrypt your DLL and run it.
You can of course make it inconvenient to perform this reverse engineering, and that may well be enough.
Take a look at the StrongNameIdentityPermissionAttribute. It will allow you to declare access to your assembly. Combined with a good code protection tool (like CodeVeil (disclaimer I sell CodeVeil)) you'll be quite happy.
You could embed it into your executable, and extract and loadlibrary at runtime and call into it. Or you could use some kind of shared key to encrypt/decrypt the accompanying file and do the same above.
I'm assuming you've already considered solutions like compiling it in if you really don't want it shared. If someone really wants to get to it though, there are many ways to do it.
Have you tried .Net reactor? I recently came across it. Some people say its great but I am still testing it out.
Well you could mark all of your "public" classes as "internal" or "protected internal" then mark you assemblies with [assembly:InternalsVisibleTo("")] Attribute and no one but the marked assemblies can see the contents.
You may be interested in the following information about Friend assemblies:
http://msdn.microsoft.com/en-us/library/0tke9fxk(VS.80).aspx