OBFU: A Flash Actionscript obfuscator

09.02.02-

Oh, what?  People are still looking at this?  Sorry, I should have left a
note- seems various versions of the flash player don't like obfu'ed code.
Maybe they try to make an offset list of instructions before running
bytecode or something?  Anyway, the code's still here in case you're
interested in how it [doesn't] works.  But I wouldn't recommend actually
using obfu.


01.07.01-

Hrm, ASV does a much better job at untangling control flow structures than
my decompiler code ever did.  Here's the new plan: just put a jump over a
broken opcode at the beginning of each action block.  It'll be easy for
them to work around, but it does seem to work.  It's a start, at least.

Of course, the best obfuscator would be a good optimizer..

Download: unix - windows


Why OBFU?

As you probably know, a variety of actionscript decompilers exist that
allow people to turn the compiled bytecode in an SWF file back into
working actionscript.  Whether this is a good thing or not--and I'm not
saying either way--the coder has no choice whether their code is in
public view.

Well, that hardly seems fair..


How it works:

Decompiling actionscript bytecode requires two separate steps: first,
bytecode is aggregated into lists of statements; second, the flow control
is translated from simple branches into higher-order control statements
like ifs, fors, and whiles.  Either step can be done first, but unwinding
the control flow is considerably more difficult.  So that's what we'll
try to break.

OBFU spikes the code with branch statements that don't actually change the
program flow.  Currently, it only adds a non-op branch that look like:

  1.skip the next instruction
  2.jump to some random location

at a random location in function definitions, "with" blocks, clip event
handlers, and normal actionscript blocks.  (So that's ten bytes added for
each of these.)

All other jumps in the bytecode have to be relocated to accommodate the
extra ten bytes.  That was a real joy to program, ah tell you whut.  But
it actually seems to work.

Speed impact on your code should be minimal, unless the "spike" happens
to hit a tight, speed-critical loop.  I suppose I could add a command-
line argument listing functions to leave unspiked.  Or hey, here's the
code, you do it.. :)


License 'n' stuff:

This code is released under the GNU Public Licence, AKA intellectual-
property-crushing pinko-commie thought virus from hell.  It's open source
for two reasons: first, to acknowledge that security by secrecy is a
losing proposition; if OBFU actually renders decompilers useless, the
decompiler coders will come up with a workaround.  (And why shouldn't
they?  It's a fun problem to solve!)  Second, keeping the code open
source will make it useful past the next iteration of decompilers, as
long as there's someone who takes the time to figure out a new
obfuscation method.  So, yeah.  That's what it's all about.

I am not responsible for any bad things that happen.  Ever.  But
specifically with regard to this code; if it wipes your hard drive--hey,
sorry.  As the lawyers say:

This code is distributed in the hope that it will be useful, but without
any warranty; without even the implied warranty of merchantability or
fitness for a particular purpose.  This code is provided as-is and you use
it at your own risk, if at all.


Linkage:

Buraks ActionScript Viewer


-Dave <dave@opaque.net>

http://www.opaque.net/