I create a Program, and I want to make a Rent option, and need secure it from RE,
I want that a user that rent the Program I created will have any authentication that even if the User Reverse it, the software wont work,
What should I do? What should I add?
Looking for suggestions to how secure my program that will have the option to rent
edit:
change it from c# to c++
It possible?
edit2:
I see it not possible, What can I do to make the RE harder?
I have website that i can use to authentication.
This is a common desire. First and foremost, understand that you can never truly make a program that cannot be reverse engineered. Most "anti-reverse engineering" techniques are aimed at making the job of a reverse engineer harder, and are likely only going to be very effective against amateurs. I'll list two popular techniques I've been exposed to from reverse engineering malware. This is a field of reverse engineering that likely sees some of the most sophistication in anti-RE methods as malware authors are constantly improving techniques to make their original code less accessible and less readable.
Anti-debugging & Anti-disassemblers. This involves including code in your program that will cause known (common) debugging or disassembling software to either malfunction or crash if the program is run through them. OR the ability to prevent code from running, disabling itself, or even crashing the OS if a disassembler or debugger is found to be installed on the machine when the program is run. See: IsDebuggerPresent function (msdn), "Stack Necromancy: Defeating Debuggers By Raising the Dead", and "Anti-Disassembly techniques used by malware (a primer)".
Code obscurity. This involves writing the original code in confusing and distracting ways (spaghetti code) to make it difficult to determine the intent and behavior of the program. Keep in mind this could backfire if implemented incorrectly as making your code difficult to make heads or tails of will obviously affect both parties. See: "Obfuscation (software)" and "Cryptographic obfuscation and 'unhackable' software".
For an actual implementation guide of these techniques, see: "An Anti-Reverse Engineering Guide".
Please keep in mind however that using anti-RE techniques on legitimate software (although sadly common) is a bad security practice and is frowned upon by the security community. Not to mention that if something is hard to break into, it typically presents itself as a challenge. See: "Security through obscurity" and "Hacker ethic".
Related
I developed a special business algorithm into a static library, and my other developers write non-critical code which will link to this static library when compile. I want to restrict only my company computer(Linux) can link this static library, to prevent this static library from being stolen and abused.
if not a good solution,any other suggestions is appreciated!
Thank you very much!
Very difficult to do this in a way that isn't easily bypassed by someone with some skills in doing such things. A simple solution would be to check the network card MAC-address, and refuse to run if it's "wrong" - but of course, anyone wanting to use your code would then just patch the binary to match their MAC-address. And you have to recompile the code whenever you use it on another computer.
Edit based on comment: No, the linker won't check the MAC-address, but the library can have code in it that checks the MAC-address, and then prints a message.
A more likely to work solution is to request permission from a server somewhere. If you also use some crypto-services to contact the server along with a two-part key, it can be pretty difficult to break. There are commercial products based on this, and it that didn't work, then they wouldn't exist - but I'm sure there are people who can bypass/fake those too.
As always, it comes down to the compromise between "how important it is to protect" vs. "how hard is it to break the protection". Games companies spend tons of money to make the game uncheatable and hard to copy, but within days, there are people who have bypassed it. And that's not even state secrets - government agencies (CIA, FBI, KGB, MI5, etc) that can have 100 really bright people in a room trying to break something will almost certainly break into whatever it is, almost no matter what it is - it just isn't worth the effort unless it's something REALLY important [and of course, then it is also well protected by both physical and logical protection mechanisms - you don't just log onto an FBI server from the internet, without some extra security, for example].
I have embedded Lua in a C++ application. I need to be able to kill rogue (i.e. badly written scripts) from hogging resources.
I know I will not be able to cater for EVERY type of condition that causes a script to run indefinitely, so for now, I am only looking at the straightforward Lua side (i.e. scripting side problems).
I also know that this question has been asked (in various guises) here on SO. Probably the reason why it is constantly being re-asked is that as yet, no one has provided a few lines of code to show how the timeout (for the simple cases like the one I described above), may actually be implemented in working code - rather than talking in generalities, about how it may be implemented.
If anyone has actually implemented this type of functionality in a C++ with embedded Lua application, I (as well as many other people - I'm sure), will be very grateful for a little snippet that shows:
How a timeout can be set (in the C++ side) before running a Lua script
How to raise the timeout event/error (C++ /Lua?)
How to handle the error event/exception (C++ side)
Such a snippet (even pseudocode) would be VERY, VERY useful indeed
You need to address this with a combination of techniques. First, you need to establish a suitable sandbox for the untrusted scripts, with an environment that provides only those global variables and functions that are safe and needed. Second, you need to provide for limitations on memory and CPU usage. Third, you need to explicitly refuse to load pre-compiled bytecode from untrusted sources.
The first point is straightforward to address. There is a fair amount of discussion of sandboxing Lua available at the Lua users wiki, on the mailing list, and here at SO. You are almost certainly already doing this part if you are aware that some scripts are more trusted than others.
The second point is question you are asking. I'll come back to that in a moment.
The third point has been discussed at the mailing list, but may not have been made very clearly in other media. It has turned out that there are a number of vulnerabilities in the Lua core that are difficult or impossible to address, but which depend on "incorrect" bytecode to exercise. That is, they cannot be exercised from Lua source code, only from pre-compiled and carefully patched byte code. It is straightforward to write a loader that refuses to load any binary bytecode at all.
With those points out of the way, that leaves the question of a denial of service attack either through CPU consumption, memory consumption, or both. First, the bad news. There are no perfect techniques to prevent this. That said, one of the most reliable approaches is to push the Lua interpreter into a separate process and use your platform's security and quota features to limit the capabilities of that process. In the worst case, the run-away process can be killed, with no harm done to the main application. That technique is used by recent versions of Firefox to contain the side-effects of bugs in plugins, so it isn't necessarily as crazy an idea as it sounds.
One interesting complete example is the Lua Live Demo. This is a web page where you can enter Lua sample code, execute it on the server, and see the results. Since the scripts can be entered anonymously from anywhere, they are clearly untrusted. This web application appears to be as secure as can be asked for. Its source kit is available for download from one of the authors of Lua.
Snippet is not a proper use of terminology for what an implementation of this functionality would entail, and that is why you have not seen one. You could use debug hooks to provide callbacks during execution of Lua code. However, interrupting that process after a timeout is non-trivial and dependent upon your specific architecture.
You could consider using a longjmp to a jump buffer set just prior to the lua_call or lua_pcall after catching a time out in a luaHook. Then close that Lua context and handle the exception. The timeout could be implemented numerous ways and you likely already have something in mind that is used elsewhere in your project.
The best way to accomplish this task is to run the interpreter in a separate process. Then use the provided operating system facilities to control the child process. Please refer to RBerteig's excellent answer for more information on that approach.
A very naive and simple, but all-lua, method of doing it, is
-- Limit may be in the millions range depending on your needs
setfenv(code,sandbox)
pcall (function() debug.sethook(
function() error ("Timeout!") end,"", limit)
code()
debug.sethook()
end);
I expect you can achieve the same through the C API.
However, there's a good number of problems with this method. Set the limit too low, and it can't do its job. Too high, and it's not really effective. (Can the chunk get run repeatedly?) Allow the code to call a function that blocks for a significant amount of time, and the above is meaningless. Allow it to do any kind of pcall, and it can trap the error on its own. And whatever other problems I haven't thought of yet. Here I'm also plain ignoring the warnings against using the debug library for anything (besides debugging).
Thus, if you want it reliable, you should probably go with RB's solution.
I expect it will work quite well against accidental infinite loops, the kind that beginning lua programmers are so fond of :P
For memory overuse, you could do the same with a function checking for increases in collectgarbage("count") at far smaller intervals; you'd have to merge them to get both.
Please state if you are developing on the front end, back end, or if you are developing a mobile/desktop application.
List your development stack
Language, IDE, etc..
Unit Testing or no Unit Testing
Be sure to include any AOP frameworks if used.
Tell me if it is easier for you to use a debugger or to using logging during development, and why you feel it is easier.
I'm just trying to get a feel for why people choose to use a debugger or logging based on their development stack.
[Front end and Back end. Desktop]
As usual: it depends....
Debugging is better if you are investigating behaviour at a distinct place in the code and/or you don't know what objects you will need to inspect and you don't mind interfering with the natural speed/order of code flow
Logging is better if there is a known variable or variables you need to monitor often over a wide swath of the flow AND when you want the code to run naturally without interruptions. Logging is also a useful addition to unit testing.
It entirely depends on the type of problem. A lot of the work that I do currently is done on the back-end (C#, WCF-services). I typically find it easiest to use logging to get a rough idea on where and when a problem occurs, then I try to tailor a test that provokes the behaviour, and then use debugging in order to fix it.
I mainly use logging and unit testing, though I think my greatest weakness as a programmer is that I am not proficient in using gdp. I can do the basic stuff (breakpoints, watches) but don't really know enough to really tap into the power it really has.
I feel some discord in the question. Debugging—according to Wikipedia—is:
Debugging is a methodical process of
finding and reducing the number of
bugs, or defects, in a computer
program
Logging is an automatic writing of trace text records while program is running.
So I use logging as a part of debugging. And I think many people are. Otherwise, what are logs were made for? Well, maybe for further numeric analysis, but that's another story.
I'm a student who's learning C++ at school now. We are using Dev-C++ to make little, short exercises. Sometimes I find it hard to know where I made a mistake or what's really happing in the program. Our teacher taught us to make drawings. They can be useful when working with Linked Lists and Pointers but sometimes my drawing itself is wrong.
(example of a drawing that visualizes a linked list: nl.wikibooks.org/wiki/Bestand:GelinkteLijst.png )
Is there any software that could interpret my C++ code/program and visualize it (making the drawings for me)?
I found this: link text
other links:
cs.ru.ac.za/research/g05v0090/images/screen1.png and
cs.ru.ac.za/research/g05v0090/index.html
That looks like what I need but is not available for any download. I tried to contact that person but got no answer.
Does anybody know such software? Could be useful for other students also I guess...
Kind regards,
juFo
This is unrelated to the actual title but I'd like to make a simple suggestion concerning how to understand what's happening in the program.
I don't know if you've looked at a debugger but it's a great tool that can definitely vastly improve your understanding of what's going on. Depending on your IDE, it'll have more or less features, some of them should include:
seeing the current call stack (allows you to understand what function is calling what)
seeing the current accessible variables along with their values
allowing you to walk step by step and see how each value changes
and many, many more.
So I'd advise you to spend some time learning all about the particular debugger for your IDE, and start to use all of these features. There's sometimes a lot more stuff then simply clicking on Next. Some things may include dynamic code evaluation, going back in time, etc.
Have a look at DDD. It is a graphical front-end for debuggers.
Try debuggers in general to understand what your program is doing, they can walk you through your code step-by-step.
Doxygen has, if I recall, a basic form of this but it's really only a minor feature of a much bigger library, so that may be overkill for what you want. (Though it's a great program for documentation!)
Reverse engineering the code to some sort of diagram, will have limited benefit IMO. A better approach to understanding program flow is to step the code in the debugger. If you don't yet use a debugger, you should; it is the more appropriate tool for this particular problem.
Reverse engineering code to diagrams is useful when reusing or maintaining undocumented or poorly documented legacy code, but it seldom exposes the design intent of the code, since it lacks the abstraction that you would use if you were designing the code. You should not have to resort to such things on new code you have just written yourself! Moreover, tools that do this even moderately well are expensive.
Should you be thinking you can avoid design, and just hand in an automatically generated diagram, don't. It will be more than obvious that it is an automatically generated diagram!
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.