Obfuscator for compiled lbraries?
September 11, 2008 8:39 AM Subscribe
Is there such a thing as an obfuscator for compiled libraries?
This sounds like a weird question, and one that's easily answered with a minute on the Google, but hear me out:
My company ships a Java application has to be activated (via internet or phone) within 30 days, or it stops running. About a year ago, we got wind of the fact that someone had started distributing a version that had been run through cavaj, and had been declawed by replacing the authentication routine with a simple "return true;". Thinking we could avoid that kind of shenaniganry down the road, I moved all the code handling authentication (which is essentially a state machine that relies on a system call to determine how long it's been installed) into a compiled C++ library, with a JNI call out to it for every function that involves sensitive content (we decrypt content at runtime based on user credentials).
That seemed like it was bullet-proof to all but the most dedicated of attacks, and I didn't figure anyone would want to invest the time it would take to decompile the library and step through the logic it uses to determine activation status. Turns out I was wrong... someone posted a modified DLL last week which declaws the activation check by replacing every conditional branch in the critical subroutine with NO-OPs, so the 30 day timer stops running. We're re-vamping most of the security features, and generally locking down everything we can with CRC checks and calls home whenever it's possible, but the final step I wanted to put into place would be making the sensitive functions really difficult to understand by stepping through them with a debugger. Since performance isn't hugely critical, I'd love for some easy way to make the function call go jumping merrily from hither to yon, building string variables that are never used, swapping registers and memory addresses, and generally creating the most complicated, ever-shifting memory environment that we can manage. Since it's probably a 15-year-old JavaScript hack who's decompiling the binaries, this might be enough of a deterrent to keep him from even trying to break the next version, and even if it's not, it ought to make it damned near impossible to figure out which variables are the important ones.
Is there a tool that latches onto your compiler and does that for you, based on not-crazy input source? All I've been able to find is source code obfuscators, which don't really help--I need something that complicates the actual compiled code.
This sounds like a weird question, and one that's easily answered with a minute on the Google, but hear me out:
My company ships a Java application has to be activated (via internet or phone) within 30 days, or it stops running. About a year ago, we got wind of the fact that someone had started distributing a version that had been run through cavaj, and had been declawed by replacing the authentication routine with a simple "return true;". Thinking we could avoid that kind of shenaniganry down the road, I moved all the code handling authentication (which is essentially a state machine that relies on a system call to determine how long it's been installed) into a compiled C++ library, with a JNI call out to it for every function that involves sensitive content (we decrypt content at runtime based on user credentials).
That seemed like it was bullet-proof to all but the most dedicated of attacks, and I didn't figure anyone would want to invest the time it would take to decompile the library and step through the logic it uses to determine activation status. Turns out I was wrong... someone posted a modified DLL last week which declaws the activation check by replacing every conditional branch in the critical subroutine with NO-OPs, so the 30 day timer stops running. We're re-vamping most of the security features, and generally locking down everything we can with CRC checks and calls home whenever it's possible, but the final step I wanted to put into place would be making the sensitive functions really difficult to understand by stepping through them with a debugger. Since performance isn't hugely critical, I'd love for some easy way to make the function call go jumping merrily from hither to yon, building string variables that are never used, swapping registers and memory addresses, and generally creating the most complicated, ever-shifting memory environment that we can manage. Since it's probably a 15-year-old JavaScript hack who's decompiling the binaries, this might be enough of a deterrent to keep him from even trying to break the next version, and even if it's not, it ought to make it damned near impossible to figure out which variables are the important ones.
Is there a tool that latches onto your compiler and does that for you, based on not-crazy input source? All I've been able to find is source code obfuscators, which don't really help--I need something that complicates the actual compiled code.
Basically, no matter what you use, breaking the security is easy. At some point, the processor has to execute instructions. The user of your software can easily pick-and-choose which ones.
Anyway, what kind of market are you in? Is your product being sold to legitimate corporate users? If so, they are probably not hacking your protection. It is easier for them to just pay you. Plus, if they *are* hacking your stuff, a quick letter from your legal team to their legal team should put a stop to that.
The 15 year old kid that's hacking your software wasn't going to buy it anyway. The people using his hacked version weren't going to buy it anyway. So to me, I think it's better to spend your time adding value for people that are giving you money instead of making things hard for the 15 year old.
I don't know of any piece of software that's not been pirated. You are not going to be the first person to do it.
posted by jrockway at 9:50 AM on September 11, 2008 [1 favorite]
Anyway, what kind of market are you in? Is your product being sold to legitimate corporate users? If so, they are probably not hacking your protection. It is easier for them to just pay you. Plus, if they *are* hacking your stuff, a quick letter from your legal team to their legal team should put a stop to that.
The 15 year old kid that's hacking your software wasn't going to buy it anyway. The people using his hacked version weren't going to buy it anyway. So to me, I think it's better to spend your time adding value for people that are giving you money instead of making things hard for the 15 year old.
I don't know of any piece of software that's not been pirated. You are not going to be the first person to do it.
posted by jrockway at 9:50 AM on September 11, 2008 [1 favorite]
Since it's probably a 15-year-old JavaScript hack who's decompiling the binaries, this might be enough of a deterrent to keep him from even trying to break the next version, and even if it's not, it ought to make it damned near impossible to figure out which variables are the important ones.
Are you sure? If the application is high profile enough that cracking groups are on the case, you're in trouble because there are some extremely talented and dedicated people in the cracking scene.
As pmdboi said, there are commercial products available but as far as I know none of them are fool-proof. If you want to continue developing your own home-grown defensive code you might want to read up on tools and methods crackers use such as SoftICE.
My experience as a shareware developer is a little outdated, but beating crackers is generally a game that you can't win. Microsoft has huge bundles of money to throw around and even they can't keep crackers from defeating their activation schemes. If you really want to keep up the fight, be prepared to spend a lot of time and energy on it that you could otherwise be spending making the application better, without any real benefits.
posted by burnmp3s at 9:51 AM on September 11, 2008
Are you sure? If the application is high profile enough that cracking groups are on the case, you're in trouble because there are some extremely talented and dedicated people in the cracking scene.
As pmdboi said, there are commercial products available but as far as I know none of them are fool-proof. If you want to continue developing your own home-grown defensive code you might want to read up on tools and methods crackers use such as SoftICE.
My experience as a shareware developer is a little outdated, but beating crackers is generally a game that you can't win. Microsoft has huge bundles of money to throw around and even they can't keep crackers from defeating their activation schemes. If you really want to keep up the fight, be prepared to spend a lot of time and energy on it that you could otherwise be spending making the application better, without any real benefits.
posted by burnmp3s at 9:51 AM on September 11, 2008
Response by poster: You're right, at the end of the day, we can't make it bullet-proof, and I'm not all that worried about doing so. If we can make it take 4 months from release-time to widespread availability of a crack, I'll call it a win... we license to a lot of individual professionals (not corporate--those are handled exclusively through web access), and the overlap of people-who-would-pay and people-who-would-download-from-warez-sites has to be tiny, but it unfortunately landed on my desk, and I'm just going to give it my best shot, with the expectation that it's a cat-and-mouse game that we'll never outright win.
So far as I can tell, we're not high-profile enough to have attracted the attention of any serious cracking groups (like I said, I was really surprised that someone had actually gone through the effort to decompile the DLL: dude, it's $300 for a license), so I'm operating under the assumption that it's an uncoordinated effort by someone with a lot of time on his hands. If it turns out to be something more sophisticated, I'll probably have to change tactics entirely.
Thanks for the input, all.
posted by Mayor West at 10:02 AM on September 11, 2008
So far as I can tell, we're not high-profile enough to have attracted the attention of any serious cracking groups (like I said, I was really surprised that someone had actually gone through the effort to decompile the DLL: dude, it's $300 for a license), so I'm operating under the assumption that it's an uncoordinated effort by someone with a lot of time on his hands. If it turns out to be something more sophisticated, I'll probably have to change tactics entirely.
Thanks for the input, all.
posted by Mayor West at 10:02 AM on September 11, 2008
Back in 2001 I used Zelix KlassMaster to obfuscate a bunch of Java code. It works on the bytecode, not the source. That's a nice feature in a tool chain by the way; it comes late enough in the build and ship process to not disturb all your other software tools. Anyway, ZKM worked great and seemed to have some smart obfuscation features. I also liked that (at the time at least) it was not well known; seemed less likely that the bad guys would know about it.
posted by Nelson at 10:50 AM on September 11, 2008
posted by Nelson at 10:50 AM on September 11, 2008
« Older Intense Excel Question: Calculate a rolling... | how to be supportive for anxious daughter Newer »
This thread is closed to new comments.
posted by pmdboi at 9:22 AM on September 11, 2008