* The Business of Software

A former community discussing the business of software, from the smallest shareware operation to Microsoft. A part of Joel on Software.

We're closed, folks!

Links:

» Business of Software FAQ
» The Business of Software Conference (held every fall, usually in Boston)
» Forum guidelines (Please read before posting!)

Moderators:

Andy Brice
Successful Software

Doug Nebeker ("Doug")

Jonathan Matthews
Creator of DeepTrawl, CloudTrawl, and LeapDoc

Nicholas Hebb
BreezeTree Software

Bob Walsh
host, Startup Success Podcast author of The Web Startup Success Guide and Micro-ISV: From Vision To Reality

Patrick McKenzie
Bingo Card Creator

Loading .Net application from Web vs reverse engineering

Does it make reverse engineering harder for hackers since they don't have the .exe code to start from ?

Sorry if this question is dumb...

Serge
Serge Send private email
Wednesday, April 24, 2013
 
 
Yes, it is much harder.  Basically they have a spec (ie a description of what the program does -- ie the finished product), and have to build from scratch.
Doug Send private email
Wednesday, April 24, 2013
 
 
When you say "loading a .NET application from the web" are you talkin about something like ClickOnce, or something like Silverlight that is a .NET based web technology?  Or event something like ASP.NET?
SteveM Send private email
Wednesday, April 24, 2013
 
 
Thanks doug.  Steve : A plain desktop application done with C# or VB.
 
In that case,  obfuscation and crypting tools like .Net Reactor would be less necessary ?
Serge Send private email
Wednesday, April 24, 2013
 
 
If the code is eventually run on the client CPU then it can be cracked, and if the language is a byte-code language (C#, VB.NET, Java, etc.) then a reasonable facsimile of the original source code can be "recovered" (without with non-compiled bits like comments, obviously).

Loading a module or exe dynamically via the web doesn't do anything to protect your code. Neither do obfuscators.
Wyatt O'Day Send private email
Thursday, April 25, 2013
 
 
Wyatt is right.  If you download the code, it can be cracked.  Web apps (where all the real work is done on the server, and only screens are sent to the client's browser) are quite popular for this reason (among others).

Whether they download your app as a .exe, .dll, in a web page or download and install doesn't matter -- they're all equivalent as far as cracking goes.

But trust me, getting people to care enough to want to reverse engineer your code is a pretty huge first step.
Doug Send private email
Thursday, April 25, 2013
 
 
The only true solution to preventing software piracy 100% is to make the app (exe) itself free, but the user has to pay for something else related to it that both (1) can't be copied and (2) that they can't be without.  Be that tech support, a physical object (printed book?), membership of something, etc.  No, I haven't any solution yet, but I do know it's a lost cause to try protecting the unprotectable.
Harry Phace Send private email
Thursday, April 25, 2013
 
 
I'll also add the .NET Reactor is famous for having ZERO support.




AC
Reluctantlyregistered Send private email
Thursday, April 25, 2013
 
 
"(1) can't be copied and (2) that they can't be without"
I think you are onto something.  A credit check would fit both requirements.  So data relevant to the client and no one else that the client needs before making a decision.
Howard Ness Send private email
Thursday, April 25, 2013
 
 
I was thinking of rock bands when I made my comment.  They make a lot of money from selling souvenirs and t-shirts and other uncopyable stuff, because they know selling just their music alone can be ripped as MP3s.  We as software coders need to think the same way, and stop the lost cause of trying to protect our exes.

An example would be selling a flight-sim with a force feedback joystick (which did occur years ago).  Sure people can copy the game, but only those who actually bought it would get the full experience with the force feedback.
Harry Phace Send private email
Friday, April 26, 2013
 
 
@Harry, I don't think it's good for software vendor to become a t-shirt seller.
Kuzmitskiy Dmitry Send private email
Sunday, April 28, 2013
 
 
There really are two different issues. Piracy vs protecting your code from other programmers. Preventing piracy is a lost cause. you can make it more difficult for someone to access your code though. obfuscation is not a silver bullet. But it makes it much harder to reverse it into human readable. Again, a programmer could use it without being able to read it.

If you have something that is really revolutionary , say a super algorithm , you can write it in c and use pinvoke to access it from .NET.  and then use obfuscation on the rest of it.

But really your time is better spent promoting your software. Real world results are counter intuitive. First version of Doom was truly revolutionary, sold millions of copies and was open source from day one. I imagine more than a few copies were pirated and more importantly, dozens of other engines copied the concepts from the code. Doom creator is still a millionaire though.
cn Send private email
Monday, April 29, 2013
 
 
>> "There really are two different issues. Piracy vs protecting your code from other programmers."


Yes, that's true.



>> "Preventing piracy is a lost cause. you can make it more difficult for someone to access your code though."


No, you have it backwards. If it's a byte-code compiled language then there's nothing you can to to protect your code. And no, changing function & variable names (e.g. "YourFunction" -> "MysteryFunction1") -- the *only* thing obfuscators can actually do that isn't completely and easily reversible -- doesn't not count as "doing something". I can explain why if you want me to.

As far as preventing piracy being a "lost cause", that's not true. Preventing *cracking* is indeed a lost cause, but that's a separate issue.

Preventing casual piracy (i.e. key sharing) can indeed increase revenue. We've seen this anecdotally from our customers and the Business Software Alliance puts out studies on this. Hardware-locked licensing is the way to prevent casual piracy: http://wyday.com/limelm/features/why/#hardware-locked
Wyatt O'Day Send private email
Monday, April 29, 2013
 
 
Oops, I wrote a stupid double negative: "doesn't not count as" should be "doesn't count as".
Wyatt O'Day Send private email
Monday, April 29, 2013
 
 
Hardware-locked licensing is BS.  I want to run my paid app at work, at home, and on my laptop.  How will that be permitted?
Harry Phace Send private email
Monday, April 29, 2013
 
 
"I don't think it's good for software vendor to become a t-shirt seller"

Ah, but you never know... it could be just the hardware dongle needed to increase sales.  It hasn't been A/B tested, but it could well be the holy grail to prevent piracy.  :)
Harry Phace Send private email
Monday, April 29, 2013
 
 
re obfuscation

A good obfuscator( I don't sell them) would not change the function to mysteryfunction1. It would try to name your function and variables to be as close to each other as possible

this is a pitiful but fast  example
function myfunction(int aaaaaaaa, int aaaaaaaaab, string aaaaaaaaac){
int aaaaaaaaabb=0;
aaaaaaaa(aaaaaaaa,aaaaaaaab,aaaaaaaaac);
aaaaaaab(aaaaaaaa);
aaaaaaac(aaaaaaaa,aaaaaaaab);
aaaaaaac(aaaaaaaa,aaaaaaaac,aaaaaaaaabb);
}

and so on for thousands of lines of code in many files.


it is trivial that all your public api delegates to private functions which could all then look like above. There is no "fully mechanical way" to reverse this to a meaningful human readable context. Does it protect your code from being used in another program? No. But it makes much harder to understand.

I did say that if you invent a quick way to factor primes , then you can make it much harder by writing it in c, compile it machine binary and call it with pinvoke which is pretty slow. but that is the trade off. Can that be reversed? sure. but it is much harder. and  you have know assembly pretty well to make sense of it.

But really the point of my comment was that all of this is not really necessary. I used to value the code above all else. I am beginning to think 90% of business is sales and marketing.
cn Send private email
Monday, April 29, 2013
 
 
it can also introduce lots of goto statements to obfuscate program flow. all of that makes it harder to read. just harder.
cn Send private email
Monday, April 29, 2013
 
 
Hardware-locked licensing does make it harder for the casual pirate. but it is also a deal breaker for me. I bought one a long time ago and a could not use it anymore 3 years later when I changed machine and the vendor had closed shop. I don't steal software but I don't want to depend on you staying in business to continue using my software. on different machines. I paid for it, I should be able to install it whenever I want as long as I am the only one using it.
cn Send private email
Monday, April 29, 2013
 
 
@Harry
>> "Hardware-locked licensing is BS. "

It's not.


>> "I want to run my paid app at work, at home, and on my laptop.  How will that be permitted?"


This is a common misconception. Just because hardware-locked licensing can lock a single key to a single computer doesn't mean you're forced to using the 1 key per 1 computer model.

For example, a handful of our customers choose to allow their product keys to be activated on more than 1 computer. So if you were using LimeLM for your products then when you generate the product keys you could set the number of "allowed activations" to 3 to allow customers to install and activate your app on their home computer, laptop, and work computer.

A well known example of this behavior is Microsoft Office's "Family Pack". They let users that purchase this special license activate on 3 computers.


----
@cn
>> "A good obfuscator( I don't sell them) would not change the function to mysteryfunction1. It would try to name your function and variables to be as close to each other as possible"

Every obfuscator does this. And "good obfuscator" is an oxymoron like "airline food" or "military intelligence".

Obfuscators serve no purpose. They don't protect code and they don't increase revenue.


>> "There is no 'fully mechanical way' to reverse this to a meaningful human readable context."

Yes, there is. Almost every automated de-obfuscator has "name un-mangling" as standard functionality. One well known example: https://bitbucket.org/0xd4d/de4dot/  (see: Rename symbols).



>> "I paid for it, I should be able to install it whenever I want as long as I am the only one using it."

I agree. That company left you to hang out to dry. Prior to their business ending, the company should've either sold their software to a responsible third party (for peanuts, even) or removed licensing from their software for their existing customers.
Wyatt O'Day Send private email
Monday, April 29, 2013
 
 
This is from the site
"Rename symbols. Even though most symbols can't be restored, it will rename them to human readable strings. Sometimes, some of the original names can be restored, though."

This refers to renaming symbols to human readable strings.
how does that help with understanding. Forget automation for a second-
what if I wrote "by hand" every function like this:

function myfunction(int aaaaaaaa, int aaaaaaaaab, string aaaaaaaaac){
int aaaaaaaaabb=0;
aaaaaaaa(aaaaaaaa,aaaaaaaab,aaaaaaaaac);
aaaaaaab(aaaaaaaa);
aaaaaaac(aaaaaaaa,aaaaaaaab);
aaaaaaac(aaaaaaaa,aaaaaaaac,aaaaaaaaabb);
}

how could you restore it to anything other than what I wrote
originally. I am not talking about using the code or reconstructing it to the format above. I am saying that the format above while in perfectly human readable form, is not useful for understanding
10,000 lines of code.
cn Send private email
Monday, April 29, 2013
 
 
That is if you are not Dr spock or Data
cn Send private email
Monday, April 29, 2013
 
 
>  Dr spock

Why would a child psychologist be good at reading obfuscated code?

Sorry - couldn't resist, I'll shut up now ;)
Jonathan Matthews Send private email
Monday, April 29, 2013
 
 
Sorry. didn't think of that. The Vulcan is the one I am referring to.
cn Send private email
Monday, April 29, 2013
 
 
@Wyatt

I'm confused. You say that obfuscation is 'snake oil', a waste of time, etc, but that hardware locked licenses are good.

In what way?

As a hacker (I'm not, btw), all I'd have to do is find out what methods in the code you use to 'phone home' or access the device information. It all ultimately comes down to a boolean result or, if enumerated, some known result, that allows the software to run. Unless the developer has self-obfuscated the function name, I think it would be pretty obvious.

Find out where the software 'phones home' and a minor change will remove *all* the licensing.

I have worked with enough companies to know that, especially for high-value software, hardware locking simply doesn't work and is trivial to circumvent. Obfuscation helps hide the obvious methods but, ultimately, in the world of binary, a true or false has to be returned at some point.

The closest I've seen, and worked on before we ran out of funding, was a set of device drivers that completely locked down the client system (all parts of the system) based on rules provided by a central server.  Absolutely no application could run on any of the client systems unless it was known and approved, and no files could even be seen/opened without permission, All network data was doubly-encrypted. All defined by rules.

Because it was based on kernel-mode code it wasn't even visible to the user via the OS and couldn't be uninstalled.

Not what you want for user software but, I'd say, pretty close to 'perfect licensing', and a world away from hardware locking...
YetAnotherAccountCosICantseemToLoginWithCurretn Send private email
Monday, April 29, 2013
 
 
@cn
>> "what if I wrote "by hand" every function like this: [...]"

Obfuscation when done "by hand" does not give it mystical powers -- it can be undone just as easily as automated obfuscation. "aaaaaaaa" becomes "Variable1", "aaaaaaaaab" becomes "Variable2" and so on.

So if your original function is "double GetSphereVolume(double radius){...}" the best an obufscator do is strip away the "friendly names". So, at worst, it becomes "double Function1(double var1){...}". Anyone looking to steal your code can either copy the function outright, or attach a debugger to the running app and learn that "Function1()" returns the product:

(4/3) * 3.14 * Math.Pow(var1, 3)

In other words, regardless of the name changes, the "meat" of the function is still there. Your GetSphereVolume(), after being put through an obfuscator, won't start calculating the surface area of a cylinder. (If it did your app would likely crash or output bad data for the user).

Ergo, obfuscators are worthless.


-----
@NewAcct
>> "You say that obfuscation is 'snake oil', a waste of time, etc, but that hardware locked licenses are good."


Yes. I thought I covered this point pretty well in this thread already. It's all about increasing revenue. Hardware-locked licensing can and does increase revenue for companies that use it. Obfuscation cannot  increase revenue for a company that uses it (nor is it sold on that promise).

Obfuscation is sold on the promise of stopping (or "preventing") cracking and/or source code theft. It can't do that.

Obfuscation does nothing. Hardware-locked licensing increases revenue.

Hardware-locked licensing can't stop cracking (nothing can). You seem to think because hardware-locked licensing can't stop cracking that it's worthless. That's a mistaken idea. Customers don't crack and crackers don't buy.

We cover this topic in-depth and at length on our website: http://wyday.com/limelm/features/why/

You can ignore the bits selling LimeLM and just focus on the broader ideas. (If it bothers you, then in your mind replace "LimeLM" with "well designed hardware-locked licensing").
Wyatt O'Day Send private email
Tuesday, April 30, 2013
 
 
@wyatt

I don't seem to be able to get my point across. You seem to have an all or nothing regarding these things. This "Good" that "Bad". You say hardware locking discourages "casual" pirate but won't admit  that obfuscation also discourages "casual" reverse engineering.

If you look beyond toy examples and think of actually reversing a  real library with thousands of lines into "meaningful" code that you want to incorporate and maintain you would not be so optimistic.

""aaaaaaaa" becomes "Variable1"
How does Variable1 provide context? how does it help me if i am dealing with thousand of files that turn into variable1s' and variable2 and so on. Think scale not toy problems

"Anyone looking to steal your code can either copy the function outright, or attach a debugger to the running app and learn that "Function1()" returns the product
(4/3) * 3.14 * Math.Pow(var1, 3)"

Yes. If they knew that was the volume of sphere to begin with. Except it will not be a toy problem, it will be  hundreds on lines that I have play jeporady "what is a ... "  using a debugger or pen and paper. either way they have to spend time and effort.

Please read my comment. I did say that it can be just used. Yes it can be reversed if you are planning to spend your time to play jeporady  with my code instead of writing your code .But it will not be easy or more effective than writing your own code. Not if we are talking scale. Not when we are dealing with kind of code that is not revolutionary. Most of what people write is not unique.
Not worth the effort.Toy problems don't count.

With that kind of determination, I can also trace your application and interject code in your application to bypass the licensing. Hardware locked or otherwise. Done all the time. By your argument that makes hardware locking worthless. But it is not. It discourages causal pirates which accounts for 99% of pirates.

The same goes for obfuscation or coding in c, etc. The goal is to discourage the casual.
cn Send private email
Tuesday, April 30, 2013
 
 
"Casual piracy" is a term our company uses. I believe I coined it, and I'm now regretting it. It's one of those terms that can be twisted (as I see you just did) to mean anything to anyone. However, as I originally defined it, and how I'm using it in this thread, *and* how we use it in our marketing copy for LimeLM, "casual piracy" means one thing and one thing only:

"Casual piracy" means "key sharing".

So what the hell does key sharing have to do with anything? Preventing key sharing increases revenue. Is key sharing a real problem? Yes. Am I going to continue to ask and answer my own questions? You bet.

Well designed hardware-locked licensing *does* prevent key sharing (a.k.a. "casual piracy"). Obfuscation does *not* prevent key sharing.

"Casual piracy" (key sharing) has nothing to do with cracking. It has nothing to do with "protecting code".




>> "I don't seem to be able to get my point across."

You are getting your point across just fine. You think obfuscation has a purpose. You are mistaken. Although, if it's any consolation, you're not alone in holding this mistaken idea.

If you're using a byte-code compiled language (C#, VB.NET, Java, etc.), then, as I said near the beginning of this thread, a reasonable facsimile of the original code (sans-comments) can be recovered. Obfuscators claim it can stop this. They're wrong; they can't.



>> "I can also trace your application and interject code in your application to bypass the licensing. Hardware locked or otherwise. Done all the time. By your argument that makes hardware locking worthless."


I've already covered this a few times in this thread. We've also covered it on our site in depth and at length (it's near the beginning of the "why LimeLM" article). So, no, that's not my argument.

Your series of posts shows that you're conflating loss reduction (preventing key sharing) with reverse engineering cracking prevention. These are 2 very separate issues.



Hardware-locked licensing has nothing to do with crack prevention. It has everything to do with preventing key sharing -- something well-designed hardware-locked licensing can actually accomplish.

But what about cracking? Nothing can stop cracking. Not hardware-locked licensing. Not obfuscation. Not "anti-cracking" / "anti-debuggers". Not "in-memory virtualization". Not even the world renowned Star Trek / Transformers / Child Psychology / Daytime-TV Judge super-team consisting of Spock, Dr. Spock, Lieutenant Commander Data, Optimus Prime, and Judge Judy can stop cracking.


Let's pause for tea, biscuits, and a haiku:

---
Hardware-locked license
prevents key sharing. Success!
Crack? Irrelevant.
---

I'll get off the topic of hardware-locked licensing. I think I've kicked that dead horse into a meaty pulp. (Burgers anyone?)

Let me address your questions about obfuscation.


>> "If you look beyond toy examples [....] How does Variable1 provide context?"

The "toy" example was to illustrate a point (that the functionality of code is not changed by obfuscators) without getting into the weeds. And yet here I am waste deep in weeds.

So how do these ugly names (variable1, function1, etc.) provide context? They don't. Running the app and setting a break point near the code you want to steal / analyze provides the context.

That bears repeating: debugging the de-obfuscated app provides the context.

Let me give you 1 example:
~~
You're a Chinese company without scruples. You steal code and clone ideas for breakfast. You're currently cloning a popular western-made app that does operations on datasets. (Exciting!). You already did the hard work stealing the graphics, UI layout, and copy. And you've already reproduced the "boilerplate" code (open files, outputting data, etc.).

However, there's thing you haven't stolen yet. You click a button that does super-secret-non-toy-operation on DatasetX. You don't have to wade through thousands of line of code to find the functionality. You don't even have to understand the code. (Understanding code is for chumps). Just add a breakpoint to the button click event and copy all the code that does operations on DatasetX and paste it into your app -- ugly names and all.

You test it. It works. You compile your app and sell it for a tenth of the price of the original app.
~~


The rest of your post was about how I don't see the big picture, how I'm making "toy" / straw men arguments, etc. I'll just say this: yes, I do indeed know how obfuscators are used in the real world. And yes, I know how easily they can be beaten in real life.

I'll be glad to respond to any specific "non-toy" examples that you have provided you state:

1. what you believe the obfuscator can protect.
2. the group you believe that will be thwarted by the obfuscator that wouldn't be already thwarted by simply compiling your app with a vanilla compiler.
Wyatt O'Day Send private email
Wednesday, May 01, 2013
 
 
"you could set the number of "allowed activations" to 3 to allow customers to install and activate your app on their home computer, laptop, and work computer."

And then when I want to run it on another PC for a while, such as a rented one while on business somewhere?  What happens then?  I can't run what I paid for?  Locked licenses are BS.  I paid for it.  Let me have it.
Harry Phace Send private email
Wednesday, May 01, 2013
 
 
""Casual piracy" is a term our company uses. I believe I coined it"

Your hubris is overwhelming. You coined casual priacy?

I don't think there is anymore point in this conversation.
cn Send private email
Wednesday, May 01, 2013
 
 
a google search for casual piracy returns over 1,400,000 results.
enough said.  I believe you are going to regret the statement " I coined that .." That one goes right next to "I invented the internet". That was my last word on the discussion
cn Send private email
Wednesday, May 01, 2013
 
 
@cn
>> "That one goes right next to 'I invented the internet'. "

How did you know I invented the Internet?



@Harry
>> "And then when I want to run it on another PC for a while, such as a rented one while on business somewhere?  What happens then?"


That's what floating licenses (a variation of hardware-locked licensing) are for. They cover this exact scenario.
Wyatt O'Day Send private email
Wednesday, May 01, 2013
 
 
""Casual piracy" is a term our company uses. I believe I coined it"

cn: "Your hubris is overwhelming. You coined casual priacy?

I don't think there is anymore point in this conversation."

He might well have.  I coined the word "minarchy" meaning a state of minimal government.  Years later, I discovered it was a term used by Libertarians.  At least two people coined it.

Sincerely,

Gene Wirchenko
Gene Wirchenko Send private email
Wednesday, May 01, 2013
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz