I have a DLL which I intend to send to a 3rd party and I'd like to protect it by restricting it to run only if a specific USB device is connected.
I'm using the setupapi to get the device's serial number (by calling SetupDiGetDeviceInstanceId()).
I would like to make the verification hard to track in case someone disassembles the DLL.
for example, a simple call to SetupDiGetDeviceInstanceId is trackable and if someone wants to use my DLL without the proper serial from the USB, he could easily look for my strcmp in the assembly code and change if(strcmp(...) == 0) to if(strcmp(...) == 1).
What would be a good (and preferably "easy") approach for protecting my code against reverse engineering? Is there maybe a different API (other than setupapi) I could use that would take care of that?
Thanks in advance!
I find restricting software like that usually comes and bites you later. The work of finding a way to implement it in a "fool proof" manner is often underestimated and could also unintentionally cripple the product in the end annoying legit customers. Better to instead to provide good support and do frequent updates. Any protection can be circumvented so I wouldn't spend too much time on that.
You clearly cannot just read the serial number and compare to a known-good value -- that's trivial to find and remove.
To make things a bit more difficult, use a cryptographic hash (e.g., SHA-256) of the serial number to a cryptographic hash of the correct serial number. Make sure the code for the hash is generated inline, so you a fairly large mess of "stuff" between reading the serial number and doing the jump based on the comparison of the hash value. This won't stop a determined attacker, but it'll stop most people who just glance at the code in a debugger and aren't willing to spend a lot of time on reverse engineering it.
If you want to make things more difficult still, store some of your code in encrypted form, with the correct serial number as the key. At run time, read the serial number and use it to decrypt the code. If it's wrong, the result will be bad code, which you can either execute as is (knowing it will quickly crash and burn) or you can do some sort of checksum to verify the result, and fail a bit more gracefully (i.e., display an error message and die) if the code didn't decrypt correctly.
In my opinion it cannot be easy for you and hard for the 3rd party. An id check is too easily found and disabled. I would try to move some essential, hard to figure out computation of your DLL into the external device.
Related
I am doing a project on IT security, my project involves data encryption and decryption. I have an idea of generating a truly random key which cannot be re-used using a one-time-pad. But i would not like to start from the scratch in writing the code since i am not an expert in the python programming language. I need the code which is written in python. As well as the code should be executable on windows OS. since i am using windows 7 and 8.
A true One-Time-Pad is impractical for your purpose. The key cannot be recreated at the receiving end, but must be transmitted to the receiver. Since the key is as long as the message, and must be kept secure, then you must already have a secure way to transmit something of the same length. So ignore the key and just securely transmit the message.
99% of all "improved" OTPs turn out to be stream ciphers. I suspect that your design is no different. Research stream ciphers for ideas.
You cannot generate cryptographically good randomness from a Pseudo-Random Number Generator, which is almost every computer based RNG.
In Python, you can use random.SystemRandom if your system provides the service, and it will take longer than your patience because the system takes a while to gather entropy.
For a class exercise, a OTP of 0x00000000… or 0x01020304… might be perfect for demonstration purposes. It might even be better because by-hand verification is much easier.
Indeed, an OTP of all zeros, as Randall Munroe shows is a perfectly random OTP
A truly random key is impractical and impossible to generate. What you need is a cryptographically random key. In python this can be generated by os.urandom(n) which is used by random.SystemRandom as user msw suggested.
Although creating your own random function would be the best, this should suffice.
I'm working on a utility that would enable me to identify what interfaces/adapters are available for use on windows, using c++.
My question is are there any functions or programs already available to identify interfaces or adapters(bluetooth, wifi, wifi-direct, nfc) available with simple output (Either I have it or I don't have it, true/false, etc).
While there exists functions that enumerate interfaces (See: http://msdn.microsoft.com/en-us/library/windows/desktop/ms706749%28v=vs.85%29.aspx) , the data returned from calling these is much too excessive and or unique, I'm simply looking for a true/false on whether the system has bluetooth, wifi, wifi-direct, and/or nfc, before I begin attempting to create sockets / call services from them.
It looks to be an uphill battle at the moment to do this, which makes me curious if this is not already available to me by calling some more convenient functions, or has been done by someone else. I've considered that simply trying to connect could give me an error which I could use as "proof" that there isn't some interface available, but this seems very inappropriate and error prone.
If not I will begin writing it but it's looking like I'd be running through more output than should be necessary for something this simple.
Any information would be useful, and thank you!
EDIT: Jerry Coffin's suggestion works, although I'm waiting on getting hardware to so I can test it against wifi-direct and nfc.
I'm currently programming a chat system based on a server - client model and using TCP as the communication protocol. Although it's working as expected, I'd like to further optimize important parts on the server side.
The server uses four extra threads to handle new connections, console input, etc, without blocking normal chat conversations. Well, there is only one thread for all messages that are being sent from client to client, so I assume it would be good to optimize the code there, as it would be the most obvious bottleneck. After reading the data on each client's socket, the data has to be processed using different steps. One of those steps would be to check for blocked words. And that's where my original question starts.
I played with std::string::find() and the strstr() function. According to my tests, std::string::find() was clearly faster than the old C-style strstr() function.
I know that the std::string is very well optimized, but C-style char arrays and their own functions always seemed to be somewhat faster, especially if the string has to be constructed over and over again.
So, is there anything faster than std::string::find() to scan a series of characters for blocked words? Is std::string::find() faster than strstr(), or are my benchmarks lousy? I know that the gain may be negligigle compared to effort needed to keep C-style char arrays and their functions clean, but I'd like to keep it as fast as possible, even if it is just for testing purposes.
EDIT: Sorry, forgot to mention that I am using MSVC++2010 Express. I am only targeting Windows machines.
Have you benchmarked to verify that lots of time is in fact being taken in the check for blocked words? My completely naive guess is you're gonna be spending lots more time waiting for RPCs than any local processing...
Have you tried the regular expressions library in either C++11 if you use that, or Boost if you don't? I'm not sure about the speed, but I believe they perform quite well. Additionally, if you are using this as a form of profanity filter, you'd want regular expressions anyway to prevent trivial circumvention.
There exist faster searching-algorithms than the linear search typically used in STL, or strstr.
Boyer-Moore is quite popular. It requires preprocessing of the target-string, which should be feasible for your usecase.
Exact string matching algorithms is a free e-book with an in-depth description of different search-algorithms and their tradeofs.
Implementing more advanced algorithms could take considerable effort.
As said in the other answers, It is doubtful that string-searching is a bottle-neck in your chat-server.
Hello fellow developers,
assume I had a program that required authorization granted to him by a server over the network. Obviously, at some point within my code there would be something along the lines of:
if (serverResponse == expectedResponse){
//Continue as the authorized user
}
This system has a very, very unlikely weakness. If anybody were to actually modify the executable file and change the code of that if (which I assume to be some sort of branching instruction) to code, that always branches to the true-case. Is there a way to detect such a modification from within my program?
To me this sounds like a psychologist checking his own sanity. If this is not possible, how would such a thing be done? How does software like Punkbuster check for manipulation of game code?
I guess it might be very relevant that this program of mine is written in C++ and compiled with the GCC compiler.
The trick here is not to rely on a simple if statement. As you say that is easily circumvented by someone who can reverse engineer your code. Instead you should use the value returned from the server for some vital function of your program. For instance the response from the server could be used as a key to decrypt some vital data on the client. That would be much harder for a reverse engineer to circumvent.
One approach is to take the address of the function and obtain the CRC of the memory at that address. This isn't very flexible however, because you have to either calculate the size of the function every time you modify it, or use a disassembler library like the magnificent and free BEAEngine to dynamically calculate it. But then there's the possibility of the reverse engineer modifying your CRC code. Or the checksum it's checking it against. They can also modify the server's response before your program gets it and change it to the expectedResponse. So you really can't win.
There are also softwares such as the free UPX which will pack your executable (and obfuscate it if you tell them to) and make it very difficult for people to read and modify to achieve the correct result they are going for.
However, if someone has enough time and skill, there's really nothing you can do. As we used to say, the client always wins; all you can do is make the game more difficult.
I've seen a lot of discussion on here about copy protection. I am more interested in anti-reversing and IP protection.
There are solutions such as Safenet and HASP that claim to encrypt the binary, but are these protected from reversing when used with a valid key?
What kinds of strategies can be used to obfuscate code and throw off reversers? Are there any decent commercial implementations out there?
I know most protection schemes can be cracked, but the goal here is to delay the ability to reverse the software in question, and make it much more blatant if another company tries to implement these methods.
There are solutions such as Safenet and HASP that claim to encrypt the binary, but are these protected from reversing when used with a valid key?
No. A dedicated reverse engineer can decrypt it, because the operating system has to be able to decrypt it in order to run it.
Personally, I wouldn't worry. Admittedly I don't know anything about your business, but it seems to me that reverse engineering C++ is relatively difficult compared to languages like Java or .NET. That will be enough protection to see off all but the most determined attackers.
However, a determined attacker will always be able to get past whatever you implement, because at some point it has to be turned into a bunch of CPU instructions and executed. You can't prevent them from reading that.
But that's a lot of effort for a non-trivial program. It seems a lot more likely to me that somebody might just create a competitor after seeing your program in action (or even just from your marketing material). It's probably easier than trying to reverse engineer yours, and avoids any potential legal issues. That isn't something you can (or should) prevent.
hire some of the people I've worked with over the years, they will completely obfuscate the source code!
Read this
http://discuss.joelonsoftware.com/default.asp?joel.3.598266.61
There are two main areas on this:
Obfuscation - Often means renaming and stripping symbols. Some may also rearrange code by equivalent code transformations. Executable packers also typically employ anti-debugging logic.
Lower level protection - This means kernel or hardware level programming. Seen in rootkits like Sony, nProtect, CD/DVD copy protection.
Its almost impossible to truely obfuscate code in such a way that it will be totaly impossible to reverse engineer.
If it was possible, then computer virus would be absolutely unstoppable, no one would be able to know how they work and what they do. Until we are able to run encrypted code, the encryption is at some point decrypted and "readable" (as in, someone that can read machine code) before it can be executed by the cpu.
Now with that in mind, you can safely assume that cheap protection will fend off cheap hackers. Read cheap as in "not good", it is totaly unrelated to price you pay. Great protection will fend off great hackers, but ultimate protection doesn't exist.
Usually, the more commercial your solution is, the more "well-known" the attack vectors are.
Also, please realise that things such as encrypted applications imply extra overhead and annoy users. USB dongles also annoy users because they have to carry it around and cost a fortune to replace. So it also become a trade-off between you being happy that you've been protected against a handful of hackers and all of your customers which will have to carry the hindrances your protection method bears.
Sure, you can go to all sorts of clever lengths to attempt to defeat/delay debuggers and reverse-engineering. As others have said, you will not stop a determined attacker, period...and once your app is hacked you can expect it to be available for free online.
You state two goals of your desired protection scheme:
1) Make it hard to reverse engineer.
2) Make it blatent somebody is ripping you off.
For #1, any obfuscator/debugging-detector/etc scheme will have at least some impact. Frankly, however, the shrinking % of engineers who have ever delved into compiler output means that compiled C/C++ code IS obfuscated code to many.
For #2, unless you have a specific and legally protected algorithm/process which you're trying to protect, once the app is reverse engineered you're sunk. If it IS legally protected you've already published the protected details, so what are you trying to gain?
In general, I think this is a hard way to "win" and that you're better off fixing this on the "business-side" -- that is, make your app a subscription, or charge maintenance/support...but the specifics are obviously dependant on your circumstances.
You need to set a limit of how far you will go to protect your code. Look at the market and what your are charging for your solution. You will never secure your product 100% so you should evaluate what method will give you the best protection. In most cases, a simple license key and no obfuscation will suffice.
Delaying reverse engineering will only 'delay' the inevitable. What you need to focus on is deterring the initial attempt to breach copyright/IP. A good legal Terms and Conditions notice on the About page, or a bold copyright notice warning that any attempts to reverse engineer the code will result in a pick-axe through the spinal column...
Most people will back off attempting to rip something off if there is a chance they will be served some legal action.
We use SafeNet and our clients see it as 'official' protection. That in itself is a good deterrent.