 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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] dev null> 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
|
|
| |
| |
|
|
|
|
| |
|
|
