Ethical Hacking

Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package.
Computer Forensics Training at InfoSec Institute

Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors.




Network Security Vuln-Dev
[Top] [All Lists]

Re: Cracking String Encryption in Java Obfuscated Bytecode

Subject: Re: Cracking String Encryption in Java Obfuscated Bytecode
Date: Fri, 24 Nov 2006 17:24:38 +0100 (CET)
Hi,

1) If you are deploying Java on the server you are protected by so many
layers, code obfuscation is not critical

If you want to distribute your app without people getting access to the
code itself, being on client or server is not relevant. Whatever the 
reason for wanting to do so. 

2) If you are deploying Java Applets for enterprise applications, you
are nuts. They are inherently insecure and Java applets have a long
history of critical problems.

So have cookies and javascript based web applications. Yet cookies are
used everywhere for anything/everything and "ajax" is the new big boy in
town. It is not because something is insecure that people don't use it in 
the real world, not the perfect secure one. 

You would be amazed of how many times I heard "it's useless to check again
the data on the [php|java|asp|perl] side, we already did it in JS" or "why
add a java middle-tier server side, we can obfuscate the jar file and have
the client PC talk directly to the database" (yeah sure, I'll make a 
public, unencrypted, access for you guys).

From a security *threat* point of view, I agree that we could/should more 
of these issues. 

With the continuous move towards bytecode type of languages (with java
and .NET being the prime examples)
Same goes with PHP BTW.

JG



<Prev in Thread] Current Thread [Next in Thread>