Thursday, August 14, 2014

AS3 Eval/Scripting Engines

AS3 Scripting Lib:

Compile AS3/JavaScript at runtime within the Flash Player
Execute compiled code in the scope of any object
Control which classes and functions are exposed to the script domain

The D.eval API brings the eval() functionality to ActionScript3 programming.

Runtime expression evaluation in ActionScript:

ActionScript 3 Mathematics Expression Parser:

Lua for Flash: (Lua for Flash via Alchemy) (Lua for Flash via CrossBridge) (Another Lua for Flash port using CrossBridge) (Lua for Flash in pure AS3)

ActionScript 3 Eval Library:
As3Eval is a library that packages the Tamarin ESC compiler to work within a run-of-the-mill flash player.

Governor is a script engine written in AS3. It provides all functions and operators you know from AS3; operators, math functions, math constants. Additionally it provides multithreading functionality for parallel execution of code. !The flash player is design as a single thread application, so governor is providing green threads!

BISE Scripting Engine:(Recommended)
The AS2-based engine could run a subset of ECMAScript, and it allowed users to write interpreted scripting for Flash games or applications. It also had some useful features, such as coroutines, a type of function that had the ability to suspend in the middle of its scripting. (AS3 Port) (AS2)

eval() for Actionscript 3:

AS3 Commons Bytecode:
AS3Commons-bytecode is an open-source library providing a ABC bytecode parsing and publishing and bytecode based reflection API for ActionScript 3.0.

XML to ActionScript(asXML):

TinyBasicAS: Flex version of TinyBasic

Java runs in Flash-Waba VM Alchemy:

The brainfuck programming language interpreter:


Parse and evalutate Haxe expressions. Haxe script is a complete subset of the Haxe language.

Simplified JavaScript interpreter:
A JavaScript interpreter you can embed in your Flash ActionScript 3 projects. Can parse and execute most JavaScript and support async "await" statement that pauses the VM until a Promise is fulfilled.

Wednesday, August 13, 2014

Test Notes on Emscripten

Recently, I tried the Emscripten compiler, which can compile C/C++ to HTML5/JavaScript. Also based on LLVM, it is a similar tool as the Adobe CrossBridge, but targeting a different platform. With Emscripten, it's possible not to write even a single line of JS for creating an HTML5 application. But for CrossBridge, you may still need to write some AS3 to make things work. Emscripten has very good SDL and OpenGL support, so you can compile your SDL/OpenGL application into JS without getting hands dirty of JavaScript.

Emscripten is similar to CrossBridge, in may aspects. For Emscripten, like the CrossBridge, you also need to break the C/C++ main infinite loop and use "emscripten_set_main_loop()" to run the loop content frame by frame. However, CrossBridge supports multi-threads and background workers, which is actually an advantage of AS3 over current JS. Both use similar inline asm (AT&T style) for interlope with the targeting languages. Their ways of dealing with the file system are similar - both use a virtual system to simulate C/C++ reading & writing processes and both provide tools for packaging assets. Besides, both CrossBridge and Emscripten can be used as code obfuscators, Emscripten even use the closure compiler for optimizing and obfuscating the generated JavaScript.

I thought the Emscripten SDK is mature enough. Even Unity3D and Unreal engine are using it for publishing HTML5, after they abandoning FlasCC and the flash platform. Also see the Porting Examples and Demos, especially the amazing Cube2 engine demo (The CrossBridge Cube2 port is not yet rendering correctly). However, in my test, for the latest Emscripten SDK (emsdk-1.21.0-web-64bit.exe), if you want to port your SDL applications or games, very likely, you will fail. That's because the support of SDL, although is working for many cases, is far from complete. What's more, the officially supported SDL version is SDL 1.3, while most old games/application are based on SDL 1.2 and most new ones are based on the latest SDL 2 (There're many API differences among these versions). Many SDL functions are not supported or implemented, such as very commonly used "SDL_DisplayFormat", "SDL_ConvertSurface". So when you compile, you may get "unresolved symbols" warnings and a black screen - the compiled application will just not run. Although there is an unofficial SDL port for Emscripten, I'm not sure whether it is worthy of trying.

Fortunately, Emscripten SDK is under very active development, unlike the almost abandoned CrossBridge. I'm looking forward to a future version with more features and great improvements. By the way, there is an unofficial fork of the CrossBridge SDK, which pulled many things together and collected lots of  examples:, I'm also watching on the project, hope it will continue to involve.

I think, the same problem for both CrossBridge and Emscripten is, there are not many games/applications written in C/C++ there waiting to be ported to the browser platform, so only a few people are actually using these cross language compilers. The reason is most games written in C/C++ are not designed for the browser platform. So if there exists a tool can compile AS3 to JavaScript, I believe it will be very, very popular. And one factor that Emscripten will be more popular than CrossBridge is that JavaScript is not a suitable language for programming large scale games and applications, but AS3 itself is good enough to handle many large projects.

Sunday, August 3, 2014

Using CrossBridge/FlasCC for Code Obfuscation

One advantage of using CrossBridge is that, because your source code is written in C/C++, it's very hard to decompile.Although some decompilers can give you the decompiled ActionScript code from the swf file, it is impossible to recover the original C/C++ source code. What's more, the decompiled ActionScript code is almost unreadable.

See what the official CrossBridge document says:

FlasCC is not designed to be an obfuscator for either ActionScript or C/C++ code. Although the generated ActionScript bytecode should be no easier to reverse engineer than natively compiled machine code the FlasCC engineering team makes no strong claims about this, nor do they test whether this is true.
By default the mangled C++ name of every source function will be trivially visible in both the decompiled output and also in ActionScript debugger and profilers. To hide the names of any generated C/C++ functions you can pass -fllvm-opt-opt=-strip to gcc so that any function names not listed in your exports.txt file will be renamed to a symbol of the form __unnamed_N. Functions that need to be called from ActionScript, which you must protect by listing in exports.txt, will not be renamed.
So to ensure the encryption strength of CrossBridge, you can just pass the option "-fllvm-opt-opt=-strip" to gcc when compiling, this will obfuscate all the function names. By the way, it's possible to use some C/C++ source code obfuscators first before compiling with CrossBridge.