[E-voting] Testing REV systems. Was: UK shelves plans

Justin Mason jm at jmason.org
Fri Oct 28 17:59:04 IST 2005

Hash: SHA1

Brian O'Byrne writes:
> > There are common parts of the applet that are re-used with the
> > following considerations:
> > 1. we change the applet code frequently as part of maintenance
> > 2. we have used an "obfuscator" on the compiled java bytecodes.
> > This approach changes the applet bytecodes.  The reasons for this
> > that the applet is smaller afterward; the obfuscator replaces
> > variable names with noise so the bytecodes cannot be exactly
> > predicted from the source (which breaks an attempted bytecode
> > trojan or a trojan listening for a certain sequence of bytecodes in
> > the JVM) and decompiling renders very messy code.  The obvious
> > disadvantages of this are that it breaks the option to compare the
> > published applet with another compile of the source, and we have to
> > trust the obfuscator.
> An obfuscator provides very little protection against a determined 
> hacker. Given the ability of tools like Eclipse to rename methods and 
> highlight code problems you can give readable names to methods and 
> other members of a class very quickly. Obfuscation raises the bar, 
> but only very slightly.


I spent quite a lot of my teenage years reading obfuscated, compiled
bytecode (specifically, 6502 machine code). I also inserted my own code
into running applications, ran the apps in a monitor, and otherwise
subverted the app's author's intentions.

This was as a *teenager*! It's really not as hard as Craig seems to

The other techniques Craig describes have been common practice in the
anti-virus world for the last 6 years at least, where they're called

PS: *however*, on the topic of testing security via a "hacking
competition": as Bruce Schneier points out, even if a technology isn't
hacked during a contest, it doesn't prove that it's secure.

- --j.
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Exmh CVS


More information about the E-voting mailing list