Obfuscating methods

[cmurthy]

How are commercial Java softwares released by Oracle, Sun, etc?
What Java Obfuscators are used by the commercial Java products?

 

[Andrew Thompson]

How are commercial Java softwares released by Oracle, Sun, etc?
What Java Obfuscators are used by the commercial Java products?

Judging by the StackTraces returned for most Java API's,
I am guessing that few, if any of them, are obfuscated.
But then, usually they are written well enough that the
programmers are *not* embarrassed of their own code,
so it hardly matters*.

* There are two other reasons that obfuscators are generally
used. Making code harder to reverse engineer, which is
rather pointless, and reducing the size of the distributable,
which can be quite effective, but carries its own development/
debugging overhead.

--
Andrew Thompson
http://www.athompson.info/andrew/

Message posted via JavaKB.com
http://www.javakb.com/Uwe/Forums.aspx/java-general/200709/1

 

[cmurthy]

Judging by the StackTraces returned for most Java API's,
I am guessing that few, if any of them, are obfuscated.
But then, usually they are written well enough that the
programmers are *not* embarrassed of their own code,
so it hardly matters*.

* There are two other reasons that obfuscators are generally
used. Making code harder to reverse engineer, which is
rather pointless, and reducing the size of the distributable,
which can be quite effective, but carries its own development/
debugging overhead.

Hi,

Thank you for the response.

I'm not a hardcore JAVA programmer though.
But why aren't the code Obfuscated?
Above, did you intend to say that Obfuscating the code doesn't matter
to them at all?

Stating the issue i'm facing, I have created/used Java Wrappers around
a few API's written in C.
As a matter of Security issue, we need to use some kind of Obfuscation
for protecting the code from being reverse engineered.

Do you suggest any of the better Obfuscators being used commercially?

Thank you.

 

[Andrew Thompson]

cmurthy wrote:
...

I'm not a hardcore JAVA

Java is a word, so unlike acronyms or abbreviations,
only the first letter should be Upper Case.

..programmer though.
But why aren't the code Obfuscated?

You'd have to ask them. I can give you the reasons
I would avoid using obfuscation, if in their position.
- Getting meaningful StackTraces is a lot more helpful
for developers who need to use the API's.
- If someone really wants the code, they will either
reverse engineer it (despiteany obfuscation) or if that
looks to be too expensive/difficult, revert to getting a
bunch of people to sit down in front of the program and
describe the inputs and outputs, then give that description
to Java devlopers with the instruction to 'code that'.

Above, did you intend to say that Obfuscating the code doesn't matter
to them at all?

I cannot say. All I know is that generally they don't.

Stating the issue i'm facing, I have created/used Java Wrappers around
a few API's written in C.
As a matter of Security issue, ..

Who's security exactly? What is it, specifically, that
you wish to prevent the end user from doing? *
(e.g. Protecting the secret encryption key used to
wrap up the I/O with a banking server? Preventing
the user from directly accessing the C API's in
ways except as clearly defined in the Java program?
What..?)

..we need to use some kind of Obfuscation
for protecting the code from being reverse engineered.

Obfuscation will make it harder. *Nothing* can prevent it.

You are better to look to keeping sensitive code
entirely out of the end user's VM, if at all possible,
and instead offer it only through a web service.

OTOH, without knowing more details of exactly what
you seem to be being very coy about*, it is hard to
provide good advice.

* What is it all for?

 

[Hunter Gratzner]

I'm not a hardcore JAVA programmer though.
But why aren't the code Obfuscated?

Why should they? And please don't give us that "trade secret" thing.
The majority of all code varies from bog standard code to junk code,
and the only trade secret is the mediocre or disgusting code quality.
It is usually the junk code authors who think they need to obfuscate,
so they can hide the disgusting code quality. Another larger set of
people who thing they need to hide something are the ones using stolen
code, e.g. non-compliant usage of GPL code is becoming epidemic.

C code can be disassembled, Java code decompiled. The difference? Java
decompilation can be done faster than C disassembly. Obfuscation slows
down Java decompilation. But it does in no way prevent decompilation.
A villain can still get your oh so precious code. They can get it with
C code, they can get it with Java code, they can get it with
obfuscated Java.

Above, did you intend to say that Obfuscating the code doesn't matter
to them at all?

I don't know what Andrew intended. In my opinion obfuscation doesn't
gain you anything, except that it delays decompilation by a few days
or weeks.

Stating the issue i'm facing, I have created/used Java Wrappers around
a few API's written in C.
As a matter of Security issue,

Security? Did you say SECURITY? You have no fucking clue about
security if you think obfuscation of any kind will protect your APIs.
And we are not even talking about Java obfuscation here. A simple
assembler debugger can reveal your oh so precious C APIs. No one would
even have to look at the Java wrappers.

we need to use some kind of Obfuscation
for protecting the code from being reverse engineered.

No, you don't.

First, there is a great chance that there is objectively no secret at
all in your code worth protection.

Second, in the unlikely event that there is something to hide, then
you are vastly underestimating the abilities, talents, determination
and resources of people being interested in it. Whether it being the
proverbial lonely hacker, interested competing businesses or
government agencies.

Third, your best bet for protection is the law and product quality.
That first of all requires that your software adheres to the law (e.g.
no usage of GPL code without releasing all source, etc.).

Do you suggest any of the better Obfuscators being used commercially?

I am not Andrew, but I don't suggest obfuscation. It is a waste of
time and money. And even worse, it gives you a false sense of
security.

 

[Roedy Green]

. Obfuscation slows
down Java decompilation. But it does in no way prevent decompilation.

Have a look at a disassembly of Jet natively compiled Java source
code. At the very most you might have the patience to take apart a
method or two.

see http://mindprod.com/jgloss/jet.html

 

[Andrew Thompson]

Hunter Gratzner wrote:
...
(OP)

Why should they? ...
.. Another larger set of
people who thing they need to hide something are the ones using stolen
code, e.g. non-compliant usage of GPL code is becoming epidemic.

That angle had not occured to me. I must be too
'innocent and honest' (sounds better than 'pig
ignorant and clueless').

As an aside, were you referring to server side
code, or code intended for the client-side?

I would imagine there was a 'swords edge' problem
with using code illegally in apps., in that if the app.
became widespread and well known, surely the
legal owners of the code would be able to both
establish and prove* that the code, even obfuscated,
was ripped, wouldn't they?

Or have I vastly underestimated the power of
obfuscators?

<DWS>
Oh, unless of course the illegal app. was distributed
with a 'no reverse engineer' caveat in the licence.
That'd sure stop the legal owners from finding out.
</DWS>

* To the satisfaction of a court specialised to deal
with copyright/patent matters.

 

[Hunter Gratzner]

Have a look at a disassembly of Jet natively compiled Java source
code. At the very most you might have the patience to take apart a
method or two.

First, it is not unlikely that the hypothetical trade secret is hidden
in just one or two methods.

Second, hypothetically assuming I have a need for analyzing such a
binary I won't do that by myself. I would shell out $100 or maybe
$1000 to some coder in a low-wage country. $1000 can buy month of work
there.

 

[Hunter Gratzner]

That angle had not occured to me.

Misusing GPLed code? Generally speaking, independent of what the OP is
doing, GPL violations have become epidemic.

As an aside, were you referring to server side
code, or code intended for the client-side?

As I see it, number one in GPL violations are devices of Asian origin
with embedded Linux. A (chip) design house creates a SoC, a reference
design, and delivers a firmware SDK with some Linux exclusively for
its cusomers. OEMs adapt the reference design, assemble the SoC on
some mainboards and get some firmware adaptation done, often by
another company. Often proprietary software is added, like device
drivers. Everything has to happen fast and cheap. The boards are sold
to other OEM companies. These do customisation, put the boards into an
enclosure and a box. Someone imports the devices. If not branded
already, someone might again customize / brand them, adds AC/DC power
supplies, creates one of these fine operation instructions we all
love, etc. Someone acts as reseller. Finally they end up in a shop.

Already at the second or third step no one cares about the GPL any
more.

Number two is Windows software, typically produced on a budget by
outsourcing companies. It is just so tempting to link in an existing
library instead of writing the code from scratch. Particularly if you
lack the necessary skills to implement something by your own at all.
For example, very recently a well known game producer silently bundled
a DOS emulator with the re-release of a classic games bundle.

Server software is usually no problem, at least not with the GPLv2.
Running customized GPL software on a public server is, at least under
the GPLv2, not regarded as a distribution of that software. And
without the distribution on is not required to deliver the source
code. I have been told that this has been partly changed with the
GPLv3, but I am not a lawyer.

I would imagine there was a 'swords edge' problem
with using code illegally in apps., in that if the app.
became widespread and well known, surely the
legal owners of the code would be able to both
establish and prove* that the code, even obfuscated,
was ripped, wouldn't they?

The problem is the cost for an individual to take legal measures,
particularly in foreign countries. Businesses are better equipped to
protect their interest, but an individual often can only try to name
and shame the violators. However, such naming and shaming often does
not leave the open-source circles, so it has little impact on the
public image (and sales figures) of the violators. End-users are also
very insensitive to such violations. In times when "sharing" music has
become a national sport it is hard to see something bad in using
software that is in fact unlicensed, particular if one paid for it or
for the device it powers.

Or have I vastly underestimated the power of
obfuscators?

No. There are, for example techniques developed that don't care about
obfuscation when it comes to the detection of similarities in
executable code http://www.st.cs.uni-sb.de/birthmarking/

Oh, unless of course the illegal app. was distributed
with a 'no reverse engineer' caveat in the licence.
That'd sure stop the legal owners from finding out.

There are countries in the world where reverse engineering for various
purposes is legal and can't be restricted by a license, so that is not
the biggest problem. And IMHO the above cited birthmarking is not
reverse engineering in my book, but IANAL.

 

[Guest]

Judging by the StackTraces returned for most Java API's,
I am guessing that few, if any of them, are obfuscated.

It is obviously never used in any of the open source stuff and
that count for a lot of Java code.

But I have seen it frequently in commercial code from Borland,
IBM etc..

Arne

 

[Andrew Thompson]

Hunter Gratzner wrote:

(A.T.)

No. There are, for example techniques developed that don't care about
obfuscation when it comes to the detection of similarities in
executable code http://www.st.cs.uni-sb.de/birthmarking/

That* reminds me to note that the figures shown, seem
to support that even an obfuscated app. could be easily
recognised.

* Or rather, Arne's follow-up to another part of the thread.

--
Andrew Thompson
http://www.athompson.info/andrew/

Message posted via JavaKB.com
http://www.javakb.com/Uwe/Forums.aspx/java-general/200709/1