Re: [SC-L] Source or Binary

2009-07-30 Thread Paco Hope
On 7/29/09 8:08 PM, silky michaelsli...@gmail.com wrote:

 Of course it's a binary, it runs by itself, when there is a java vm
 to run it. Just like you need a win32 vm to run a typical .exe.

You misunderstand the notion of virtual machines if you think of Win32 as a
virtual machine. There is nothing virtual about windows. It runs on the
real hardware (ignoring things like VMWare). Your Windows EXEs (except those
running in the .NET CLR) also run on the real x86 hardware. I.e., your
variables are loaded into CPU registers and operated on, etc.

The Java Virtual Machine is a theoretical machine, and Java code is compiled
down to Java bytecode that runs on this theoretical machine. The Java VM is
the actual Windows EXE that runs on the real hardware. It reads these
bytecodes and executes them. There is a very significant level of
abstraction between a Java program running in a Java virtual machine and
native code that has been compiled to a native object format (e.g., an
.exe).
 
 Realizing that java binaries hold a lot more is a mental shift that
 probably must be actively kept in mind.
 
 Hold a lot more what? This doesn't make sense.

It makes a lot of sense. Because Java is a string-based language, a great
deal of symbolic information (e.g., class names, method names, inheritance
hierarchies) remains in the class file, literally in string format, after
you compile. If you're in the C++ world and you compile and then strip your
binaries, that symbolic information is reduced a lot. If you use a java
decompiler (e.g., jad, jode, etc.), you can get .java files from .class
files and they are remarkably usable. While C++ decompilation is possible,
the fidelity of decompiled Java programs is significantly higher. I.e., they
match their original source, sometimes in astonishing accuracy.

Take a look at java decompilation and compare it to what you know about
native code decompilation. It is absolutely true that (ignoring
anti-reversing techniques like obfuscation), Java binaries carry a lot more
usable information to help in the dissection and understanding of their
execution than an equivalent native-code program would.

Paco

-- 
Paco Hope, CISSP, CSSLP
Technical Manager, Cigital, Inc
http://www.cigital.com/ ? +1.703.585.7868
Software Confidence. Achieved.


___
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
___


Re: [SC-L] Source or Binary

2009-07-30 Thread Wall, Kevin
In a message dated July 30, 2009 10:09 AM EDT, Paco Hope wrote...

 The Java Virtual Machine is a theoretical machine, and Java
 code is compiled
 down to Java bytecode that runs on this theoretical machine.
 The Java VM is
 the actual Windows EXE that runs on the real hardware. It reads these
 bytecodes and executes them. There is a very significant level of
 abstraction between a Java program running in a Java virtual
 machine and
 native code that has been compiled to a native object format (e.g., an
 .exe).

There's theory, and then there's practice. This is almost 100% accurate
from a practical matter with the exception of HotSpot or other JIT compiler
technologies that compile certain byte code into machine code and then
execute that instead of the original byte code.

I'm sure that Paco is aware of that, but just not sure all the other
readers are.

-kevin
---
Kevin W. Wall   Qwest Information Technology, Inc.
kevin.w...@qwest.comPhone: 614.215.4788
It is practically impossible to teach good programming to students
 that have had a prior exposure to BASIC: as potential programmers
 they are mentally mutilated beyond hope of regeneration
- Edsger Dijkstra, How do we tell truths that matter?
  http://www.cs.utexas.edu/~EWD/transcriptions/EWD04xx/EWD498.html


___
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
___


Re: [SC-L] Source or Binary

2009-07-29 Thread Kenneth Van Wyk

On Jul 29, 2009, at 4:17 PM, Brad Andrews wrote:
Realizing that java binaries hold a lot more is a mental shift  
that probably must be actively kept in mind.  Those with only Java  
experience may think it is obvious, but how many developers did not  
start with Java and have not purged this concept from their mind.


Fair enough, but understand too that a Java class file (like those in  
a typical jar file, which is just a fancy word for ZIP format) can be  
trivially decompiled into quite legible Java source.  Numerous open  
source Java decompilers (e.g., Jode, Jad) exist that make this  
extremely easy.


And FWIW, that's exactly how the Etisalat Blackberry software update  
was analyzed and proven to contain spyware last week.


Note that, there are many options to distributing these trivially  
decompiled class files...


Cheers,

Ken van Wyk




smime.p7s
Description: S/MIME cryptographic signature
___
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
___