|
I highly appreciate your input!![Rose | [Rose]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/rose.gif)
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....
|
|
|
|
|
there are commercial tools that will encrypt your DLL, and only allow decryption if the user has that product's Runtime installed, and a certain hardware- or software-based license is available on the system that tries to run it.
This might be too much investment for a small company, but whether it makes sense for you or not depends on your industry and the price / value of your product.
If you make high-value hardware/software and need to manage client licenses etc, then CodeMeter by Wibu Systems is worth a look. There are plenty of less complicated alternatives, as well.
|
|
|
|
|
thank you very much for CodeMeter info!
diligent hands rule....
|
|
|
|
|
Sorry for the late post.
If a hacker were to reverse engineer your C++ code, they would use IDA Pro by Hex Rays.
Cleaning up the disassembly result and re-constructing your algorithm would take about a day or so.
I have a good mathematical function
Are you sure about that?
In my experience, every algorithm in existence has been written in C++ already.
If pseudo-code exists for it --> it has been written in C++.
If a white-paper exist for it --> it has been written in C++.
If you can do it in MATLAB --> it has been written in C++.
The only area where I could imagine a novel algorithm would be worth anything, is the industrial IoT niche.
Or the embedded hardware niche, if we're talking handicapped chips handling edge cases.
Anything general purpose has been done to death a million times over.
|
|
|
|
|
thanks for your comments!
what I want to protect is a series of data points can be used to forecast future events in a specific domain.
I plan to wrap it up into a function in C/C++.
diligent hands rule....
|
|
|
|
|
So.. flow dynamics for industrial process control? Or something in that ballpark?
If you want to protect a proprietary dataset, the best approach would be to store it encrypted, and decrypt it based on a personal license or hardware key. This implies some level of OS interaction. To cut to the meat of it: C++ is, generally speaking, too low-level for that.
Start with identifying your target OS, look up what mechanisms are provided for signed/tamper proof applications, and try to design your application within the constraints of those examples.
E.g. for a Windows platform you would need to look at guides for creating tamper proof applications with .NET, but you could do the same on MacOS, or Java. The thing is, you need some type of encryption, and OS level support that is impractically hard to circumvent. At the end of the day, it's all just bits and bytes when it runs, nothing can obfuscate the data way, you can only make it impractical to intercept it.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
