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

Craig Burton craig at e1c.net
Sat Oct 29 12:29:08 IST 2005


>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.
>  
>
Obfuscation was not a critical part of our security as any applet can be
deparsed and one can piece together what is going on from the derived
source, it only buys time.  Still, you don't have unlimited time to
deparse and examine the applet, build a trojan, distribute it.  The
source goes out after close of nominations.  The compiled applet goes
out on open of early voting or on voting day itself.  You may have 12
hours or you may have 6 days depending.

The applet is obfuscated mainly as a bi-product of class clipping, as I
haven't found a non-obfuscating class-clipper to date.  Class clipping
(perhaps is has other names) was used to reduce the size of the applet.

>This was as a *teenager*! It's really not as hard as Craig seems to
>assume.
>
>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
>"polymorphism".
>  
>
I refer to a trojan being embedded in the JVM and parsing/hunting for an
expected sequence of byte code, like the ACM example waiting for the C
source of login( ).  Polymorphism is the virus modify itself so that its
signature does not match what we are looking for.   I think this is
different?
http://kb.iu.edu/data/aehs.html

Regarding virus signatures, a polymorphic virus would be a waste of time
as any vote virus presumably won't have a signature anyway if it is
released close to the election.  If it is released early (one that waits
to be told what to look for in the final voting applet) then it could be
polymorphic, but this only makes it harder to signature, not impossible
or we'd know nothing about them.

Obfuscating the applet has its pluses and minuses for security.  We are
yet to weigh up how hard obfuscating the applet bytecodes or mucking
with the control flow in the source makes hunting for any sequence of
bytecodes.
Perhaps you know?  I assume the JVM functions in a linear manner and we
can observe the sequence as it is being executed and intervene.  I am
yet to find an example of an exploit like this.

>
>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.
>  
>
Brian proposes the testers have a retainer.  This at least feeds them
while they work.  It may also be fruitful to propose the competition at
a university as an assignment.
Best,
Craig.




More information about the E-voting mailing list