True, but compared to designing, developing, debugging and maintaining?
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Pavel A.
Sent: Friday, October 01, 2010 11:52 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Obfuscators for drivers?
“M. M. O’Brien” wrote in message news:xxxxx@ntdev… > +1 > > I would never do this, but if you (op) feel you must do this, at least > consider buying the feature and spending your time on your code. > Keeping the conversation reasonable, no matter what it costs, it’s not > going to even chart compared to what it will cost you to implement and > maintain a product that will now be less mature as a result of the > time tradeoff. > > mm
Buying requires spending time to studying and evaluation, besides of money. It may be a “do or die” situation, especially in these damn days /me recalls couple of urgent calls to obfuscate code (that we did not plan to do so from the beginning), before demoing in a certain country known for dealing with IP issues liberally. –pa
> -----Original Message----- > From: xxxxx@lists.osr.com > [mailto:xxxxx@lists.osr.com] On Behalf Of David Luxford > Sent: Friday, October 01, 2010 9:13 PM > To: Windows System Software Devs Interest List > Subject: Re: [ntdev] Obfuscators for drivers? > > I would recommend not obfuscating. While I was at Symantec, we never > would have considered this for symevent/savrt because of the > supportability problems it creates. IMHO, your time is better spent > writing better product than protecting IP. > > On 10/1/10, Pavel A. wrote: >> wrote in message news:xxxxx@ntdev… >> >>> Interetsting, among all projects on sourceforge, there are none >>> obfuscators for low level code >> >> Just think a moment about jailbroken Apple devices, Xbox and others. >> This is more or less same type of code that is found in drivers, made >> specially with some “security thru obscurity” >> in mind. >> Motivated people and organizations will break your stuff. >> >> Serious obfuscation is hardware assisted. For example, you can make >> for your firmware side a private instruction set, unknown to IDA; new >> FPGA based processors (Altera…) endorse this. >> >> On the idea of obfuscation of kerrnel code in general - try to ask in >> Linux forums >> >> Regards, >> --pa >> >> >> >> — >> NTDEV is sponsored by OSR >> >> For our schedule of WDF, WDM, debugging and other seminars visit: >> http://www.osr.com/seminars >> >> To unsubscribe, visit the List Server section of OSR Online at >> http://www.osronline.com/page.cfm?name=ListServer >> > > – > Sent from my mobile device > > — > NTDEV is sponsored by OSR > > For our schedule of WDF, WDM, debugging and other seminars visit: > http://www.osr.com/seminars > > To unsubscribe, visit the List Server section of OSR Online at > http://www.osronline.com/page.cfm?name=ListServer > >
With a few exceptions, drivers do not contain IP.
They merely contain plumbing to provide access to a piece of hardware.
It’s the hardware that has the IP.
But the exceptions you point out make the rule. The (now broken)
encryption used in HDMI connectors, Satellite receivers, WiFi chipsets,
GSM receivers, and Macrovision are examples of this. It can actually be
a regulatory issue in some cases.
The fact that there are plenty of them doesn’t mean the entire concept
isn’t stupid. But I digress.
Agree. No amount of obfuscation is going to prevent anyone even vaguely
determined from figuring out what makes your driver tick. Virtualisation
makes this even easier for hardware based drivers.
I agree that obfuscating hardware driver seems to be quite usless
idea.
But not all drivers are hardware …
Let’s assume hypotetically (!), that I wrote a driver which is a part
of
security system and I don’t want it to be analyzed because competitors
may get
some ideas from my code :). I patented my technology, but I still
don’t want
it to be analyzed or at least I want to make life of bad guys a little
bit
more complex.
How should I proceed?
Buy some sheep and take up farming?
Making it “a little bit more complex” for the bad guys will not even
measurably slow them down.
With the controversy over binary blobs and possible GPL violations, I have
been wondering whether companies couldn’t just obfuscate their
to-be-released source code by running it through a preprocessor that
strips all comments, removes all line breaks, non-obligate whitespace and
brackets, and renames all private functions, variables, structures, etc.
to random but legal gibberish.
Wouldn’t this technically meet the requirements of the GPL while being
only marginally easier to figure out than assembly… and also be a great
way to make friends?
On Sat, 02 Oct 2010 07:44:20 +0300, James Harper
wrote: >> On the idea of obfuscation of kerrnel code in general - try to ask in >> Linux forums >> > > And if you do that, please post a link to the mailing list archive back > here. Should be fun to watch > > James
With the controversy over binary blobs and possible GPL violations, I
have
been wondering whether companies couldn’t just obfuscate their
to-be-released source code by running it through a preprocessor that
strips all comments, removes all line breaks, non-obligate whitespace
and
brackets, and renames all private functions, variables, structures,
etc.
to random but legal gibberish.
Wouldn’t this technically meet the requirements of the GPL while being
only marginally easier to figure out than assembly…
You aren’t the first one to come up with this idea - but aside from
being obviously against the spirit of the GPL, I think it also is
against the letter of the GPL. You simply aren’t releasing your source
code, your are releasing a ‘compiled’ version of it. Whether you compile
it to assembler, java bytecode, .net bytecode (I forget what it’s
actually called), or obfuscated-C, it is no longer really your source
code.
and also be a great way to make friends?
If you mean the type of friend who might hurl a brick through your
window at 3am to show how much he cares then yes
>You aren’t the first one to come up with this idea - but aside from being obviously against the spirit of the GPL,
I think it also is against the letter of the GPL.
Well, as long as your code is in compilable form it DEFINITELY does not violate the “letter”. For example, if you replace meaningful do_something() into gibberish like “hfdrehshjhg()” everywhere in your code you will still be able to compile it, right. Concerning the " spirit"…well, I think it is exactly in the UNIX tradition - after all, cryptic names are just traditional in the UNIX world, don’t you think…
On Sat, Oct 2, 2010 at 2:12 PM, wrote: >>You aren’t the first one to come up with this idea - but aside from being obviously against the spirit of the GPL, >> I think it also is against the letter of the GPL. > > Well, as long as your code is in compilable form it DEFINITELY does not violate the “letter”.
It definitely does, to quote from the GPL:
“The “source code” for a work means the preferred form of the work for making modifications to it.”
Surely obfuscated source code is not the preferred form of making modifications to it.
> cryptic names are just traditional in the UNIX world, don’t you think…
> Surely obfuscated source code is not the preferred form of making modifications to it.
First you have to give your definition of “obfuscated source code”…
What makes my imaginary hfdrehshjhg() more obfuscated than, say, rcu_qsctr_inc() or d_add_ci() ??? No, I am not making it up - these are real function names from Linux kernel sources…
On Sat, Oct 2, 2010 at 2:44 PM, wrote: > >> Surely obfuscated source code is not the preferred form of making modifications to it. > > First you have to give your definition of “obfuscated source code”…
Any translation of the original source code does not fit within FSF definition of source code, which I quoted above, therefore a better definition of obfuscated code is not even needed. The preferred form of making modifications to a program is it’s original source code, regardless of how convoluted or bad it is, so you can GPL brainfuck programs, which are always obfuscated by the virtue of the fact that they are written in brainfuck.
> What makes my imaginary hfdrehshjhg() more obfuscated than, say, rcu_qsctr_inc() or d_add_ci() ???
You develop(ed) on the original source, not the translated source, therefore that is the preferred form of making modifications to it.
> No, I am not making it up - these are real function names from Linux kernel sources…
Surely Linux is a great example if you want to bash UNIX, but UNIX is not only Linux, you know. You mentioned “cryptic names are just traditional in the UNIX world, don’t you think”. Maybe you should have mentioned Linux (and/or BSD? Not much experience with that) instead of UNIX. The UNICES I work on are not like that.
> Maybe you should have mentioned Linux (and/or BSD? Not much experience with that) instead of UNIX.
The UNICES I work on are not like that.
Oh, I see…
You must be working on UNICes that don’t support POSIX then, so that you don’t use functions like brk(), stnicmp() and all other cryptic stuff from POSIX C
> You aren’t the first one to come up with this idea - but aside from
being
> obviously against the spirit of the GPL,
> I think it also is against the letter of the GPL.
Well, as long as your code is in compilable form it DEFINITELY does
not
violate the “letter”. For example, if you replace meaningful
do_something()
into gibberish like “hfdrehshjhg()” everywhere in your code you will
still be
able to compile it, right. Concerning the " spirit"…well, I think
it is
exactly in the UNIX tradition - after all, cryptic names are just
traditional
in the UNIX world, don’t you think…
Just to clarify, the parent’s point is that if your release cycle goes:
And you release (b) and (c) and claim to be complying with the GPL then
you Fail as (b) is a result of a ‘compilation’ (even if you call it a
pre-processor) and isn’t really your source code. This might be hard to
prove without having access to the hypothetical ‘real’ source code (a)
assuming the author is willing to perjure themselves in court.
I think you’ve taken the line that (a) never existed and (b) is what you
actually develop with, in which case yes you are GPL compliant. But also
possibly insane.
> > Surely obfuscated source code is not the preferred form of making
> modifications to it.
First you have to give your definition of “obfuscated source
code”…
What makes my imaginary hfdrehshjhg() more obfuscated than, say,
rcu_qsctr_inc() or d_add_ci() ??? No, I am not making it up - these
are real
function names from Linux kernel sources…
Familiarity with the subject matter is what makes it more obfuscated.
That should be obvious.
Anyone working on RCU under Linux would be able to figure out what the
rcu_qsctr_inc did, and even if they had to google it, it would be easy
enough to remember from that point on as the function name contains
jargon or abbreviated jargon from that subsystem.
Anyone working with the dcache code would know what d_add_ci() did. ‘ci’
would normally imply ‘case insensitive’ but I’m not sure in that case as
I haven’t looked up the function.
Unless it’s some really long acronym (in which case you aren’t really
obfuscating), hfdrehshjhg is completely different as you’d have to
remember it by rote if you were working with the code, and someone like
myself would never remember whether I should be calling hfdrehshjhg() or
hfdrehshihg().
So you should have said POSIX not UNIX. POSIX was a political effort
not a design (having been on the committee for a few years it truly was
political), and the weird names were a result of the big firms (HP, Sun,
IBM, AT&T) each arguing that you can’t use name “DoTheRightThing” unless
it meets the semantics of our system, so “DoTheRitghtThing” became
“DTRT” to be a name no one had used.
> > Maybe you should have mentioned Linux (and/or BSD? Not much experience with that) instead of UNIX. > > The UNICES I work on are not like that. > > Oh, I see… > > You must be working on UNICes that don’t support POSIX then, so that you don’t use functions like brk(), stnicmp() and all other cryptic stuff from POSIX C > > Anton Bassov
On 10/2/10, James Harper wrote: >> >> > You aren’t the first one to come up with this idea - but aside from > being >> > obviously against the spirit of the GPL, >> > I think it also is against the letter of the GPL. >> >> Well, as long as your code is in compilable form it DEFINITELY does > not >> violate the “letter”. For example, if you replace meaningful > do_something() >> into gibberish like “hfdrehshjhg()” everywhere in your code you will > still be >> able to compile it, right. Concerning the " spirit"…well, I think > it is >> exactly in the UNIX tradition - after all, cryptic names are just > traditional >> in the UNIX world, don’t you think… >> > > Just to clarify, the parent’s point is that if your release cycle goes: > > (a)‘working’ source code -> (b)obfuscated source code -> (c)binary > > And you release (b) and (c) and claim to be complying with the GPL then > you Fail as (b) is a result of a ‘compilation’ (even if you call it a > pre-processor) and isn’t really your source code. This might be hard to > prove without having access to the hypothetical ‘real’ source code (a) > assuming the author is willing to perjure themselves in court. > > I think you’ve taken the line that (a) never existed and (b) is what you > actually develop with, in which case yes you are GPL compliant. But also > possibly insane. > > James > > > — > NTDEV is sponsored by OSR > > For our schedule of WDF, WDM, debugging and other seminars visit: > http://www.osr.com/seminars > > To unsubscribe, visit the List Server section of OSR Online at > http://www.osronline.com/page.cfm?name=ListServer >
As in case of C/C++ app/driver we ship a binary with assembly code, and code level obfuscation will not really make any difference for a reverse engineer. I have seen expert guys reverse engineering such an app (will come to it later) with same ease as any other. Though it took some time to start of this app but once done it was as same as any other app.
The said app was having major code portion encrypted in PE, This app use to create a try/catch block and first instruction in try used to create an exception, which catch will receive, it than check for certain things (like debugging flag in PEB) & if every thing is as it expects it decrypts that specific code portion and re execute the instruction.
Obviously as the code is encrypted IDA or any other static debugger does not have any chance on it, but you just can not avoid reverse-engineering if you want to execute and they want to reverse it
I always thought that this whole obfuscation thing relates more to languages which can be de-compiled (or which get converted into some mid language, C#, Java), As I believe it is possible to generate exact source code from that mid-level language,code level obfuscation make sense.
>>Let’s assume hypotetically (!), that I wrote a driver which is a part of security system and I don’t want it to be analyzed because competitors may get some ideas from my code :).
Well, the problem is that you want to execute this code & doing so will open it for dis-assembling, you can write code to fool IDA but eventually they will read it.
>I patented my technology, but I still don’t want it to be analyzed or at least I want to make life of bad guys a little bit more complex.
Just Patent it and leave it, in case some one use it, let your legal dept decide about it. Technically you can not stop it.
And you release (b) and (c) and claim to be complying with the GPL then you Fail as (b) is
a result of a ‘compilation’ (even if you call it a pre-processor) and isn’t really your source code.
Let’s say I never release (c) - I release only (b), along with installation script, so that (c) gets actually produced on the target machine when installation script calls make config -> make -> make install sequence. Are you still claiming that I am not GPL-compliant???
> Let’s say I never release (c) - I release only (b), along with installation script, so that (c) gets actually produced on the target machine when installation script calls make config -> make -> make install sequence. Are you still claiming that I am not GPL-compliant???
Yes, GPL doesn’t licence code (like CDDL), it licences programs,
higher level abstract entities. The source code is what you write, not
what you release. Since you don’t release the original source,
understood in terms of GPL as the preferred form for doing
modifications you are not GPL-compliant.
/me
