I'm working on a copy protection software and I'm trying to create a wrapper around any kind of executables (managed and unmanaged). This wrapper will then try to execute the wrapped executable without writing it to the disc like normal, and execute it with Process.Start().
I used .Net 4.0 Assembly and Appdomain to get it working, but as I've read and tested, it will only work with .Net executables. How would I go around and execute any kind of executable without writing it "naked" to the drive?
Can I execute it from within an encrypted compressed file for example?
or MemoryMappedFile?
Really you are wasting your time. You CANNOT stop someone from copying your executable, getting your code, or anything else. Even if you can perfectly protect the executable file on disk, the moment it starts running, someone can use a debugger to make a dump of the executable, even from a memory mapped file. This is how products like Xenocode, or .NET Reactor, or any other packer for that matter, are defeated.
The better option for you is to stop and think about what it is that you are really trying to achieve. Are you concerned about people violating a license agreement? Are you worried about your software appearing on The Pirate Bay? If you make useful software, both of these things are eventualities, not possibilities. Protect your software with copyright, and your algorithms with patents, if appropriate. Then you have legal recourse to go after violators.
Sorry to burst your bubble, but there is no technical solution that cannot be defeated. Dongles can be emulated, web services can be patched around, encryption keys can be sniffed, etc. Spend your time making your software great, not trying to protect what cannot be protected.
Related
I built a C# WPF (.NET Core 3.1) application using that has got some interest and I'm about to monetize it.
However, building any kind of license check in C# is pretty much useless, and any user would be able to use a decompiler such as ILSpy to crack it, thus rendering my work pretty much useless.
I took a long hard look on the .NET obfuscators, but ultimately concluded they did not fit my requirements because there are decompilers that can still retrieve the code from Dotfuscator, Babel, Obfuscar, etc. Simply obfuscating names and whatnot isn't really useful, as one could simple debug the code to the point where a license is required.
What I'm trying to do now is build a C/C++ launcher that will execute my .NET from memory.
My plan is to stream the bytes from a server, load them in memory, and run the program. I, however, don't know a whole lot about how I could achieve this.
I've tried VirtualAlloc to allocate all the bytes and changed set memory page to be executable, but it didn't work.
I've tried adjustments based on a few pieces of code that run PE from memory:
https://github.com/aaaddress1/RunPE-In-Memory
https://github.com/codecrack3/Run-PE---Run-Portable-Executable-From-Memory/blob/master/RunPE.cpp
https://www.codeproject.com/Articles/13897/Load-an-EXE-File-and-Run-It-from-Memory
The closes I got was a 0xc0000005 error when trying to run the executable from memory (an array of bytes that makeup my program).
How can this be done? I'd really like to avoid having to rewrite the whole thing in C/C++, specially because of the complex UI.
I'm trying to check if an application tries to manipulate a particular process (for ex. hooks itself to it). I couldn't find a proper approach to accomplish this. Is computing checksum over running process possible? If it's not how can i detect this situation?
Other process can't make hooks in your process, can modify memory but to make hooks this code must be in your address space, this can be done to injecting DLL to your process when is starting (at runtime inject dll is a hard one), you can easy check this by listing DLL's in your process and searching some ReadProcessMemory, WriteProcessMemory, OpenProcess, CallNextHookEx functions calls in their code. To do that get address (GetProcAddress) of function and search value in code (you can add some asm call predictions for that for tight range result).
You can check what is wrong with your PE file in disk and in memory, when DLL injection at startup time was occurrence then your PE file after was copied to memory from file should be corrupted, after last dll library you should have overwritten debug symbols with additional dll import. This modification can be done on file same as in memory.
The best method but probably will not easy for you when you are using C# language is obfuscate your code. I think this is a good method because you don't hook something that you don't know how work, because you don't know what hook you must do and where. But for good obfuscate C# code you must find good software for that and probably pay not low price.
I have a process that will have some important values in the memory. I don't want anyone to be able to read the memory of my process and obtain those values. So I tried to create a program that would look at the list of programs running and determine if any of them were "debuggers", etc. But I realized that someone could just write a quick program to dump the memory of my process. I know several process on my system have their memory protected. How could I also obtain this? (ps: I'm using C#)
Any application that runs under an user with enough privileged (eg. local administrator) can call ReadProcessMemory and read your process at will, any time, without being attached to your process debugging port, and without your processing being able to prevent, or even detect this. And I'm not even going into what is possible for a system kernel driver to do...
Ultimately, all solutions available to do this are either snake oil, or just a way to obfuscate the problem by raising the bar to make it harder. Some do make it really hard, but none make it bullet-proof. But ultimately, one cannot hide anything from a user that has physical access to the machine and has sufficiently elevated privileges.
If you don't want users to read something, simply don't have on the user machine. Use a service model where your IP is on a server and users access it via internet (ie. web services).
First of all, there will always be a way to dump the memory image of your program. Your program can only make it harder, never impossible. That said, there may be ways to 'hide' the values. It is generally considered hard to do and not worth the trouble, but there are programs which encrypt those values in memory. However, to be able to use them, they need to decrypt them temporarily and re-encrypt (or discard) them afterwards.
While encryption is easy with the .Net framework, discarding the decrypted value is not an easy thing to do in C#. In C, you would allocate a chunk of memory to store the decrypted values and clear that (by writing zero's or random data to it) before freeing it. In C#, there is no guarantee that your data won't be stored somewhere (caching, garbage collection) and you won't be able to clear it. However, as eulerfx noted in a comment, in .Net 4.0 SecureString may be used. How safe that is, I don't know.
As you may see, there will always be a short time where the value lies in memory unencrypted, and that is the vulnerability here.
I think the best way to do it is employ a commercial solution such as in this PDF brochure, this is their website. You may be better off going down this route if you really care about protecting the application from sniffing, IP theft etc instead of rolling up your own solution...
Edit: I would not go down the route in kidding myself that the solution I shall craft up will be tamper proof, crack proof, idiot proof. Leave that to a company like Arxan I mentioned (I aint a sales rep - I'm just giving an example), sure it might be costly, but you can sleep better at night knowing it is much harder for a cracker to break than having no solution at all...
I have a C# .NET app. This application is tightly coupled to a piece of hardware. Think ATM, drive up kiosk kinda thing. I want a way for my application to assure it is being run on our hardware. Our initial plan was to get the serial number of the CPU, OS, HD, or other hardware with WMI, digitally sign that, and ship that signature with the software. The application would then have the public key in it to verify the signature. Is there a better way to do this?
Update 1
We dont want a dongle or a hasp. Nothing external to the system.
Yes, you would have a semi-safe system. It can prevent running on different hardware. It will also prevent some forms of maintenance of that hardware.
It will, as usual, not prevent anyone from decompiling and changing your software.
We do something similar for software licensing by signing an XML file, although ours isn't tied to any hardware. The same concept applies. It works well.
You will also need to protect your .NET code using some kind of obfuscation tool, we use {smartassembly} but there are several others out there.
Keep in mind that no matter what you do, given enough time and resources, someone can bypass it.
That doesn't mean you should not protect your intellectual property, but there is a point where you get diminishing returns and cause more trouble to you and your customers that it's worth.
What is the logic behind disk defragmentation and Disk Check in Windows? Can I do it using C# coding?
For completeness sake, here's a C# API wrapper for defragmentation:
http://blogs.msdn.com/jeffrey_wall/archive/2004/09/13/229137.aspx
Defragmentation with these APIs is (supposed to be) very safe nowadays. You shouldn't be able to corrupt the file system even if you wanted to.
Commercial defragmentation programs use the same APIs.
Look at Defragmenting Files at msdn for possible API helpers.
You should carefully think about using C# for this task, as it may introduce some undesired overhead for marshaling into native Win32.
If you don't know the logic for defragmentation, and if you didn't write the file system yourself so you can't authoritatively check it for errors, why not just start new processes running 'defrag' and 'chkdsk'?
Mark Russinovich wrote an article Inside Windows NT Disk Defragmentation a while ago which gives in-depth details. If you really want to do this I would really advise you to use the built-in facilities for defragmenting. More so, on recent OSes I have never seen a need as a user to even care about defragmenting; it will be done automatically on a schedule and the NTFS folks at MS are definitely smarter at that stuff than you (sorry, but they do this for some time now, you don't).
Despite its importance, the file system is no more than a data structure that maps file names into lists of disk blocks. And keeps track of meta-information such as the actual length of the file and special files that keep lists of files (e.g., directories). A disk checker verifies that the data structure is consistent. That is, every disk block must either be free for allocation to a file or belong to a single file. It can also check for certain cases where a set of disk blocks appears to be a file that should be in a directory but is not for some reason.
Defragmentation is about looking at the lists of disk blocks assigned to each file. Files will generally load faster if they use a contiguous set of blocks rather than ones scattered all over the disk. And generally the entire file system will perform best if all the disk blocks in use confine themselves to a single congtiguous range of the disk. Thus the trick is moving disk blocks around safely to achieve this end while not destroying the file system.
The major difficulty here is running these application while a disk is in use. It is possible but one has to be very, very, very careful not to make some kind of obvious or extremely subtle error and destroy most or all of the files. It is easier to work on a file system offline.
The other difficulty is dealing with the complexities of the file system. For example, you'd be much better off building something that supports FAT32 rather than NTFS because the former is a much, much simpler file system.
As long as you have low-level block access and some sensible way for dealing with concurrency problems (best handled by working on the file system when it is not in use) you can do this in C#, perl or any language you like.
BUT BE VERY CAREFUL. Early versions of the program will destroy entire file systems. Later versions will do so but only under obscure circumstances. And users get extremely angry and litigious if you destroy their data.