|
I have a good mathematical function and plan to wrap it up in a DLL by VC++.
just wonder how easily it is reverse engineered...
is there any better way to protect my DLL? I know it is a very old topic.
diligent hands rule....
|
|
|
|
|
Anything can be reverse engineered given enough effort. The key is determining how much effort you want them to have to go through.
I'd start by considering the amount of loss you would incur if it were cracked and copied.
If it's not providing a significant revenue stream I wouldn't necessarily do anything to it, as C++ is already quite difficult to reverse engineer given modern optimizing C++ compilers. They really tangle your asm up something fierce. However, the more you export from that DLL, the more "hooks" a potential black hat has to figure out what your code is doing.
If you want to protect from that marginally, *and* make your DLL more accessible to other languages, consider wrapping your API with a flat C api and exporting that instead. That way the hooks only point to the wrappers and you have to give less information about the arguments you take and such because C doesn't mangle. If the wrapper is thin, it's not much of a barrier to reverse engineering, but it's something.
Beyond that you can use obsfucators to shroud your assembly further, but even most commercial companies don't bother. In practice, very few people are going to even attempt it, fewer still will be successful, and even then a cracked version is only going to get limited distribution, meaning it's not necessarily going to noticeably impact the money you are making.
To err is human. Fortune favors the monsters.
|
|
|
|
|
honey the codewitch wrote: If it's not providing a significant revenue stream I wouldn't necessarily do anything to it
|
|
|
|
|
thanks for your precious input. I love this C api way. Would you share some good example or articles on this topic?![Rose | [Rose]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/rose.gif)
Quote: If you want to protect from that marginally, *and* make your DLL more accessible to other languages, consider wrapping your API with a flat C api and exporting that instead. That way the hooks only point to the wrappers and you have to give less information about the arguments you take and such because C doesn't mangle. If the wrapper is thin, it's not much of a barrier to reverse engineering, but it's something.
diligent hands rule....
|
|
|
|
|
I don't have one in the pipeline but the idea is simple.
A c++ member function is just a function that takes a pointer to the class as the first argument. C++ hides it but in C you'd just add a pointer to the struct as the first argument to each function, and then make them static.
To err is human. Fortune favors the monsters.
|
|
|
|
|
I highly appreciate your input!
diligent hands rule....
|
|
|
|
|
Wrap your code in an encrypted space.
Keep your so called wonder algo private, then host it. No wonders there.
Bastard Programmer from Hell 
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
thank you! this way is very interesting to me...
diligent hands rule....
|
|
|
|
|
As the Codewitch says, anything can be reverse-engineered or decompiled with sufficient effort.
Unless your code is of interest to the NSA or some such, I doubt that anyone will bother. It's typically too much effort for too little result.
Most commercial companies would rather invest their efforts in producing something similar than reverse-engineering. The legal risks are much smaller.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
If you have a good mathematical function then you should make it public domain. You know, for the progress of mankind...
"In testa che avete, Signor di Ceprano?"
-- Rigoletto
|
|
|
|
|
I try to make money first and then think about other ways...
diligent hands rule....
|
|
|
|
|
Is it the mathematics you are protecting, or the coding? If the latter you are wasting your time - what one fool can do another fool can equally do. If you have devised some novel and original mathematics you should publish it - ask yourself this: how much is it built on techniques, principles, theorems and other mathematical knowledge etc made freely available to you by countless other mathematicians over the centuries? Then ask yourself how moral it is to keep it to yourself for monetary purposes.
|
|
|
|
|
The DLL will have some well defined inputs and outputs to be useful.
This is the biggest clue as to what's in the black box.
If it serves the user well, they will probably not care what is inside.
Now, if your algorithm is really valuable to you, a convoluted C API (not hard to do with C) will probably offer security to a point. But, as been said, "almost anything can be reversed engineered given time, money and intellect".
So, write your DLL, make as much money as you can and be satisfied until it's hacked (if it's hacked).
|
|
|
|
|
for me it is indeed to try this way...
diligent hands rule....
|
|
|
|
|
Binary code generally ain't terribly easy to reverse-engineer and C++ tends to make things extra hard. Unless you go great lengths to program the DLL C-style, but why would anyone sane do that?
Anyway, if you want to go the extra length, take a look at http://ithare.com/merits-of-anti-reverse-engineering-for-mogs
It's a series on articles on that topic, both theoretical observations & practical considerations.
|
|
|
|
|
your link is great and I will buy one book from that site.
thank you for great resource!
diligent hands rule....
|
|
|
|
|
Real world story:
At a previous job, most work was done in C#. We did have some proprietary algorithms/approaches that we wished to protect, so we used a combination of (one of various) obfuscators (no, not dotfuscator, stuff that was supposed to be much better) for the C# code, and for stuff we really wanted to protect we wrote in C++ under the presumption that it would be too hard to decompile.
After years of this misguided perception, I decided to confirm our assumptions. ALL of the C# code could easily be decompiled back to almost verbatim source using one or two free/open source readily available tools. No C# protection tool was worth anything, the could all be easily decompiled in a matter of minutes.
At least our important stuff was C++ compiled binaries, that should be safe, right? WRONG!
I used a tool called Hex-Rays that decompiled the C++ binaries back to almost perfect C++. It wasn't perfect, but it was close enough so that anything that we considered proprietary was plainly and easily visible. A couple $K and a few minutes and I had all the source I needed.
We soon after abandoned any (false) precept that code (compiled or otherwise) could be sufficiently protected.
|
|
|
|
|
cool
could de-compiled be recompiled without too much intervention?
|
|
|
|
|
Decompiled was pretty straightforward. Fiddling w/ some of the switches to improve this or that, but within an hour or two I was an (sufficient) expert to be decompiling all of our presumed secrets...
Recompiling, trying to remember... I think for the most part it was correct generally compilable code. I didn't spend too much time on recompiling since that wasn't a primary objective...
Regardless, for compiled C++ code, I was pretty much floored at how well it did.
One other point, if you did actually have debugging symbols available, the decompiler would use that and produce near verbatim code compared to the source. But no one ever ships debugging symbols, right... ?!
|
|
|
|
|
Not knowingly so. I use debugger only during development. I compile as release from time to time to make sure it behaves as expected.
I use CodeBlocks with GNU CC compiler. Started with C99, I am using C11 (no C++ for my project). Haven't moved up to C17 yet. In any event, the cycle from development to users is short and direct. But the code is getting old and so am I. It's uses GLFW to great extent but link direct (no DLL's).
|
|
|
|
|
BTW, I hate DLL's. They are nothing but lose ends as far as I am concerned. I want as few dependencies as possible when I deliver .exe
|
|
|
|
|
this experience is precious for me.
diligent hands rule....
|
|
|
|
|
I am curious as to how you plan to sell this, and to whom you would offer it...
Is it worth the effort to be a "product"?
Will you serialize the DLL?
One of my favorite techniques is simply that of a Custom KEY that enables the function to work.
So, you call this method, you pass in the key to an initialization function. That sets the flag so the function will work,
and potentially how it will work. (For example, you can make a demo version that requires the DLL to be unloaded and reloaded after EACH or Every 10 uses).
And finally, you can create a custom version of the DLL, signed to a specific customer. And let them know it is duly signed. I would make it work such that their key works with ONLY that signed object.
Now, if you EVER catch a version floating in the wild. You stand a chance of knowing where it leaked out from.
if I were selling this for $200k/license. This would be a no-brainer.
at $20/license... Not sure I would bother.
this is where you analyze your risk/reward... Because it might be a great "function", but are people willing to pay for it?
And will those people tend to "SHARE" or "VIOLATE" their license agreement?
|
|
|
|
|
Encrypt the DLL with Social Security/government ID of the purchaser and have it embedded in each custom built DLL.
No one will ever share their copy!
Say it is “blockchain” and it will sell!
|
|
|
|
|
it is a very good idea, feasible for me.. :
diligent hands rule....
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
