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

Am 24.07.2014 13:00, schrieb Le_Forgeron:

> 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.

... and you have obfuscated the hell out of your chip design. And burnt 
the chip design documents. And shot the chip designer. At point blank 
range. With a .50 BMG round. Or two, just to be sure.

Post a reply to this message

On 24/07/2014 13:31, Orchid Win7 v1 wrote:
> 
> 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.

If it does not work, as a honest customer, it makes a difference.
At least, it's a bad experience, even if the cause is not identified.

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

Not at all. DVD DRM have multiple weakness, including now leaked keys.
The impact of DVD is limited to the support and its reader.

BRD DRM are far more painful, as they propagates along HDMI.
Let say you have a fully working setting (reader---tv set).
One day you had a new device on an unrelated entry of the tv set, and
the reader stops displaying your movies.

More interesting: you just have reader+tv, you play a disc, and from
that moment, your tv will refuse to display any protected content. (disc
can contains revocation lists... your tv have been revoked due to some
decision about the brand... bad luck, you're toasted, it is your tv, but
not the one you think you bought anymore)


-- 
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

>> 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 ;-)

Well played, sir.

(Actually, most Haskell beginners find that almost everything they write 
utterly fails to compile. The saying "when it compiles, it's usually 
bug-free" exists for a reason...)

Post a reply to this message

On 24/07/2014 03:03 PM, Warp wrote:
> 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?

1. C# and Java are both "compiled languages". You don't (usually) 
compile them to machine-code, but they're certainly compiled.

2. You obfuscate ANY language, compiled or not, to make it harder for a 
human to figure out what it does.

It's a lot more obvious why you'd want to obfuscate, say, JavaScript. 
(It's trivial for anybody to read the source code.) But I'm sure a quick 
Internet search will turn up software that can transform machine code 
back into valid C or C++ source code. (It won't be identical to the 
original of course - THAT is provably impossible - it it'll be vaguely 
readable.)

Post a reply to this message

> Why would you want to obfuscate a compiled language?

To avoid hackers reverse engineering your code too easily? For example 
if you have a game that used "int money=5000;" it will be trivial for a 
hacker to scan memory and find which location holds the amount of money, 
then change it. It would be better to have an obfuscated way of storing 
the amount of money that makes it hard for a hacker to figure out.

The same probably applies to things like decryption keys and licensing 
information in a business application. I guess having something like:

bool DemoVersion;
...
DemoVersion = !IsLicenseValid();
...
if(!DemoVersion)
{
  ... stuff only allowed in the full version
}

...is a really bad idea, as again it would be trivial to scan memory and 
find the location of the DemoVersion variable and modify it. Or even 
manually look at the machine code with a disassembler and look for the 
"if(!DemoVersion)" instruction and bypass it.

Post a reply to this message

scott <sco### [at] scottcom> wrote:
> bool DemoVersion;
> ...
> DemoVersion = !IsLicenseValid();
> ...
> if(!DemoVersion)
> {
>   ... stuff only allowed in the full version
> }

> ...is a really bad idea, as again it would be trivial to scan memory and 
> find the location of the DemoVersion variable and modify it. Or even 
> manually look at the machine code with a disassembler and look for the 
> "if(!DemoVersion)" instruction and bypass it.

The only way to obfuscate the usage of a boolean would be to put more
complex code everywhere that uses that boolean, instead making it do
more complicated operations.

This sounds like a difficult thing to do without breaking the program
(especially since in C++ you can use booleans in all sorts of funny ways).
Also, if the obfuscator blindly converts all the booleans and other
integrals this way, it will ostensibly make the program less efficient,
if it starts obfuscating tight inner loops doing heavy calculations.

Anyways, it seems a poor way to protect your compiled binary. A determined
hacker is going to hack it no matter what.

-- 
                                                          - Warp

Post a reply to this message

> The only way to obfuscate the usage of a boolean would be to put more
> complex code everywhere that uses that boolean, instead making it do
> more complicated operations.

Indeed, that is what I was getting at.

> Also, if the obfuscator blindly converts all the booleans and other
> integrals this way,

Yes, it's probably not a good idea to just blindly obfuscate every 
boolean and integer this way, only the ones you want protected from 
external tampering.

> Anyways, it seems a poor way to protect your compiled binary. A determined
> hacker is going to hack it no matter what.

I think that's only true if it's a really popular piece of software (eg 
decoding blurays or Adobe/MS products etc), if it's something obscure 
then you only want to make it hard enough that they give up and move on 
to something else. Especially if you randomly change the obfuscation 
algorithm every time you release an minor update, the hackers simply 
can't be bothered to keep up.

Post a reply to this message