 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 24/07/2014 08:02 AM, clipka wrote:
> I guess you don't want to obfuscate a large codebase manually. Not only
> because it is a lot of work, but also because there is a high risk of
> breaking the code...
>
> ... oh, wait...
BOOM!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 24.07.2014 09:07, schrieb Orchid Win7 v1:
> On 24/07/2014 06:06 AM, Warp wrote:
>> Orchid Win7 v1<voi### [at] dev null> 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.
...
> Really, if you want to copy our product, it would be quicker to look at
> what it does and write your own one from scratch than to try to figure
> out how ours works internally. The most likely scenario is somebody
> wanting to reverse-engineer our stuff just to disable the license checks.
That, most probably.
> All the obfuscater actually does is to take every class and rename all
> it's methods to A(), B(), C(), etc. And insert lots of complicated flow
> control into the method's actual code. It appears in this instance, it
> accidentally (!!) renamed two events to the same thing. Oops...
I guess it's plenty of fun to wade through obfuscated code to figure out
exactly how the hell the 'fuscator fucked it up...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 24/07/2014 09:07, Orchid Win7 v1 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.
>
So, you are on the poor-side of companies. Richer companies have a
full-time team with lawyers to track and sue such events.
> ...which is interesting, really. We make software for idiots. Idiots
> generally aren't the type of people you'd expect to be
> reverse-engineering computer software. Our software doesn't *do*
> anything particularly complicated; it just puts a user-friendly GUI in
> front of a bunch of existing tools. That might *sound* easy, but it's
> actually surprisingly time-consuming.
>
> Really, if you want to copy our product, it would be quicker to look at
> what it does and write your own one from scratch than to try to figure
> out how ours works internally. The most likely scenario is somebody
> wanting to reverse-engineer our stuff just to disable the license checks.
>
> All the obfuscater actually does is to take every class and rename all
> it's methods to A(), B(), C(), etc. And insert lots of complicated flow
> control into the method's actual code. It appears in this instance, it
> accidentally (!!) renamed two events to the same thing. Oops...
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.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
