|
You are back up tomorrow! 
What was the solution? (I had nothing)
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Work == MAN (as in: Man the pumps!)
Work == OEUVRE (as in: A work of art.)
Work == MANOEUVRE (as in: Manoeuvre that lever into the open position.)
I think this clue was too obtuse and perhaps unfair. If so, I apologize. I did agonize over it some, but I thought it clever so I went with it anyway. Most clues seem to have a loose thread or hook to grab that can lead you to the answer (although I often don't see it). This may have been a bit too esoteric in that you almost had to start with the solution and work backward.
Let me know if you thought it unfair or invalid, and especially why you thought so. Don't worry about me, the hair may be thin but my skin is not! And thank you for any help!
Anyway, look at the bright side. It may have taken me 3 years to become the setter, bit you'll only have to wait through 3 days of my lousy clues. 
I'll try to make tomorrow's clue more traditional (if there is such a thing).
|
|
|
|
|
Great concept, though man and manoeuvre are somewhat dubious as synonyms for work.
|
|
|
|
|
|
Yeah, I think I was being too clever by half. I think what crossed me up was that synonyms aren't actually commutative, at least from a puzzle solving standpoint. I was able to find a synonym of "man" and "manouevre" that included "work", but the none synonyms or definitions of "work" include them.
Thank you to you and @GregUtas for your responses. Fail once, try again, fail better. 
|
|
|
|
|
You're welcome - it's a different ballgame writing clues than solving them - I've been doing cryptic crosswords for over fifty years but writing them correctly is a bigger challenge - I learnt to solve them largely from setters (and himself) that adhere to Ximenean rules - check him out for ideas on how to construct a clue - I admire your tenacity in both solving and now setting a CCC good luck
"Life should not be a journey to the grave with the intention of arriving safely in a pretty and well-preserved body, but rather to skid in broadside in a cloud of smoke, thoroughly used up, totally worn out, and loudly proclaiming “Wow! What a Ride!" - Hunter S Thompson - RIP
|
|
|
|
|
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... ?!
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
