On 7/19/07, Jon Bradley <[EMAIL PROTECTED]> wrote:
On Jul 19, 2007, at 8:29 AM, Mark Winterhalder wrote:
> But I wonder, did anybody compare haXe vs AS3 bytecode yet? A
> decompiler is likely to assume AS3 has been used, and maybe haXe
> creates sufficiently different bytecode to confuse it.
That doesn't really matter. If it's FP9, it's AS3. The bytecode has
to be AVM2 bytecode no matter where it comes from.
I'm not so sure about that. The generated bytecode patterns for things
like loops might be different. Stuff like that. There are many ways
how to use opcodes in sequence to achieve a certain result. IIRC, it
confused decompilers when you did manual optimizations with flasm for
the old VM.
The general point is - intrinsic methods in the Player are hardcoded
and available. References or calls to those methods can be followed,
no matter if they're named funky or not.
Exactly. That's why, if somebody would add encryption to the main SWF,
'loadBytes' would be the string I'd search for...
Let's say you call "blahblah.mask = something" and that gets
obfuscated to _3457._3 = _537. Any sufficiently designed decompiler
will be able to mark that as _3457.mask = _537. Following those
references, a decompiler could then figure out the raw type of _537
and _3457 and mark those as maybe "spriteInstance1" or
"shapeInstance45" or whatever.
Then, the decompiler results in spriteInstance1.mask =
shapeInstance45. Legible enough to work with. I don't believe that
scenario can be avoided, no matter what compiler/obfuscator you use.
Yeah, I totally agree. It's just about making it non-trivial.
Mark
_______________________________________________
[email protected]
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Brought to you by Fig Leaf Software
Premier Authorized Adobe Consulting and Training
http://www.figleaf.com
http://training.figleaf.com
