Am 23.07.2014 22:30, schrieb Orchid Win7 v1:

> When we actually found the root cause, it was truly horrifying. It seems
> that the automated code obfuscation system we run our code through is
> BREAKING OUR CODE!

Which one do you use? For which programming language?

I'm just curious. :-)

Lars R.

Post a reply to this message

Orchid Win7 v1 <voi### [at] devnull> wrote:
> On 24/07/2014 06:06 AM, Warp wrote:
> > Orchid Win7 v1<voi### [at] devnull>  wrote:
> >> automated code obfuscation system we run our code through
> >
> > I think this is the real WTF.

> The idea is to make it less trivial to reverse-engineer our code and 
> steal all our secrets.

Because security by obfuscation has always worked so well...

What programming language are we talking about, btw?

-- 
                                                          - Warp

Post a reply to this message

>> The idea is to make it less trivial to reverse-engineer our code and
>> steal all our secrets.
>>
>
> So, you are on the poor-side of companies. Richer companies have a
> full-time team with lawyers to track and sue such events.

Still doesn't stop people stealing the secrets thought - pretty much 
every piece of software from "rich" companies has been "cracked" to 
bypass any licensing.

Post a reply to this message

> I guess it's plenty of fun to wade through obfuscated code to figure out
> exactly how the hell the 'fuscator fucked it up...

It's simple, really. There are two events that coincidentally have the 
same name, and the obfuscater has mistaken them for being THE SAME 
event. They aren't; they're in different namespaces.

Of course, without the source code to the obfuscater, knowing what the 
problem is doesn't help.

Meta: I wander if the obfuscater is obfuscated?

Also: I hear "writing your application in Haskell" is a good way to 
obfuscate stuff. The generated machine code doesn't follow the usual C 
calling conventions, which confuses the **** out of reverse engineering 
tools. That and the multiple, multiple levels of indirection. Then 
again, it's easy to *say* such things, I wonder if anybody has ever 
actually put it to the test?

Post a reply to this message

>> The idea is to make it less trivial to reverse-engineer our code and
>> steal all our secrets.
>
> So, you are on the poor-side of companies. Richer companies have a
> full-time team with lawyers to track and sue such events.

You can't sue somebody unless you catch them.

Given that we can't even tell which (if any) of our *paying* customers 
are still using the product... you get the picture.

> Maybe interpreted language is not the right choice if you want to
> protect your code. That's where compiled language have an advantage: the
> compilation with full optimisation is already an obfuscation. There is
> decompiler... like there is deobfuscater. And they are pretty smart on
> small code.
>
> It's one of the three Java issues (Java is about sharing... keeping
> secret is not sharing, so the choice of the language for your project
> was an error), at least for secretive software. But that's another story.

It's not Java, it's C#. And it's not interpreted, it's a hybrid; compile 
a high-level language into a lower-level language, and then interpret 
(or rather JIT-compile) that. I gather that in early versions of C#, it 
was utterly trivial to recompile CIL back into valid C#, but in later 
version of C# it has become a lot less trivial.

But hey, you try explaining that to the PHB. All he wants to hear is "we 
spent 8 years developing this stuff, I don't want somebody to press one 
button, and be able to steal all our hard work". Not, of course, that an 
obfuscater necessarily does that; I hear there are 1-click deobfustation 
tools out there...

Post a reply to this message

>> The idea is to make it less trivial to reverse-engineer our code and
>> steal all our secrets.
>
> Because security by obfuscation has always worked so well...

The goal is to make it too much effort to be worth bothering, not to 
make it impossible. (Clearly if the code runs, it MUST be possible to 
reverse-engineer it if you try hard enough.)

Given the tiny market our product targets, there probably aren't too 
many people who are going to bother.

> What programming language are we talking about, btw?

C#.

I gather it used to be "trivial" to decompile CIL back into C#, but 
since lots of code auto-generation has been added to C#, it's now a lot 
less trivial.

As I say, I suspect all anybody really cares about is can they hack our 
licensing code? (The answer is pretty much "yes", obfuscation or not.)

The C++ code is also obfuscated, but so far we haven't run into any bugs 
with that.

Post a reply to this message

On 24/07/2014 12:14, Orchid Win7 v1 wrote:
> But hey, you try explaining that to the PHB. All he wants to hear is "we
> spent 8 years developing this stuff, I don't want somebody to press one
> button, and be able to steal all our hard work". Not, of course, that an
> obfuscater necessarily does that; I hear there are 1-click deobfustation
> tools out there...

Changing requirement at the end... a classical of bad management (hence
PHB :-). It's not about "the code should not be stolen", but "how much
are we willing to invest in to deter people from stealing it."

If really worth it, smart part of the code is inside a dongle, whose
chip is kept alive by a small battery, with decryption keys in the ram
part of the chip only, the whole thing in resin block. And the chip is
made by your company and never sold to third-party.

Unplugged dongle for too long: death of battery, ram content is lost, no
more decryption, so program is dead.
Trying to extract the components... it requires a lot of caution to not
open the circuit with the battery.

Short of that, you are just following the same path as Bluray's DRM:
making life of honest customer painful, while adding nearly nothing
against pirates. That's why I won't buy or even use a Bluray.

-- 
IQ of crossposters with FU: 100 / (number of groups)
IQ of crossposters without FU: 100 / (1 + number of groups)
IQ of multiposters: 100 / ( (number of groups) * (number of groups))

Post a reply to this message

On 24/07/2014 12:00 PM, Le_Forgeron wrote:
> On 24/07/2014 12:14, Orchid Win7 v1 wrote:
>> But hey, you try explaining that to the PHB. All he wants to hear is "we
>> spent 8 years developing this stuff, I don't want somebody to press one
>> button, and be able to steal all our hard work". Not, of course, that an
>> obfuscater necessarily does that; I hear there are 1-click deobfustation
>> tools out there...
>
> Changing requirement at the end... a classical of bad management (hence
> PHB :-). It's not about "the code should not be stolen", but "how much
> are we willing to invest in to deter people from stealing it."
>
> If really worth it, smart part of the code is inside a dongle

You know, this technology already exists.

In order to run Steinburg Cubase, you have to plug in a little USB 
device. If you unplug it, the software instantly exits, losing all your 
work.

Now, I'm sure there's some way of defeating this protection system if 
you try hard enough. (Again, it comes down to finding the license code 
and removing it.) But it seems to work pretty well. No fiddly numbers to 
write down or license authorisation to manage. If you upgrade your PC, 
no problem. You want to run Cubase on your laptop? Sure! You only 
physically have one USB device, so you can only ever run one copy of the 
software, no matter how many times you install it...

The PHB has decided that this technology is too expensive for us to 
implement in our product. (To be fair, I have absolutely no idea what 
this stuff actually costs...)

> Short of that, you are just following the same path as Bluray's DRM:
> making life of honest customer painful, while adding nearly nothing
> against pirates. That's why I won't buy or even use a Bluray.

First, whether the code is obfuscated or not makes absolutely no 
different to the honest customer. None whatsoever. If anything, it just 
makes *my* life more painful when it doesn't work right. Second, I 
seriously doubt anybody will bother trying to pirate our software - so 
long as we make it too much hassle, that is. If you could just put the 
install DVD into 20 PCs and it works, people would PIRATE THE HELL out 
of it! But that doesn't work, and I suspect most of our customers are 
too stupid to work out why. And that's probably good enough.

If we were making Microsoft Word or something, this would NOT be good 
enough... but our product has a much smaller target audience.

Also: Isn't BRD DRM exactly like DVD DRM? (I.e., trivial to bypass.) Do 
you refuse to buy DVDs for the same reason?

Post a reply to this message

Am 24.07.2014 12:06, schrieb Orchid Win7 v1:
>> I guess it's plenty of fun to wade through obfuscated code to figure out
>> exactly how the hell the 'fuscator fucked it up...
>
> It's simple, really. There are two events that coincidentally have the
> same name, and the obfuscater has mistaken them for being THE SAME
> event. They aren't; they're in different namespaces.
>
> Of course, without the source code to the obfuscater, knowing what the
> problem is doesn't help.
>
> Meta: I wander if the obfuscater is obfuscated?
>
> Also: I hear "writing your application in Haskell" is a good way to
> obfuscate stuff. The generated machine code doesn't follow the usual C
> calling conventions, which confuses the **** out of reverse engineering
> tools. That and the multiple, multiple levels of indirection. Then
> again, it's easy to *say* such things, I wonder if anybody has ever
> actually put it to the test?

Yeah; and if /I/ were to obfuscate my stuff by writing it in Haskell, 
the result would certainly be broken code, too ;-)

Post a reply to this message

Orchid Win7 v1 <voi### [at] devnull> wrote:
> The C++ code is also obfuscated, but so far we haven't run into any bugs 
> with that.

Why would you want to obfuscate a compiled language?

-- 
                                                          - Warp

Post a reply to this message