In some of my recent articles I detailed the architecture and some implementation of a video player swapper - that is a video player that can play different kinds of videos, assuming that the videos required specific unique players. After creating the architecture and wrappers for all of the different players, and profiling that finished piece to make sure it performed well and had no memory leaks, it performed beautifully, and still does to this day on www.fancast.com.

But soon a requirement came to make this player architecture syndicatable - that is, a stand alone player that can be shared and embedded on different pages anywhere on the internet. The only problem with that was certain players were dependent on JavaScript that lived on the page - one of the players was an externally loaded SWF from a third party that we were contractually obligated to use to play their videos, the other used Windows Media Player.

At first the dependency on external JavaScript looked to exclude the possibility of making the player syndicatable, until I came across the idea to use code injection to inject the necessary JavaScript into the parent window via ActionScript.

Wikipedia is pretty hard on the concept, saying the following:

Code injection is the exploitation of a computer bug that is caused by processing invalid data. Code injection can be used by an attacker to introduce (or "inject") code into a computer program to change the course of execution.

It then goes on to list several types of code injection attacks, and even lists some potential benevolent uses for it, but even there says its a kludge. I feel that's more than a little inaccurate.

Code injection isn't a new concept, and has been pretty common practice well before being used as an exploit. Developers working on embedded systems have a standard practice of injecting Assembly from C code to achieve things that are either not possible in pure C or have better performance as ASM. See here and here for reference.

Wikipedia looks kindlier at this practice:

In computer programming, the inline assembler is a feature of some compilers that allows very low level code written in assembly to be embedded in a high level language like C or Ada. This embedding is usually done for one of three reasons:

Optimization: when assembly language is inlined for optimization, the most performance-sensitive parts of an algorithm are replaced by hand-written assembly. This allows the programmer to use the full extent of their ingenuity, without being limited by a compiler's higher-level constructs.

Access to processor specific instructions: some processors offer special instructions, such as Compare and Swap and Test and Set — instructions which may be used to construct semaphores or other synchronization and locking primitives. Nearly every modern processor has these or similar instructions, as they are necessary to implement multitasking. To name a few, specialized instructions are found in the SPARC VIS, Intel MMX and SSE, and Motorola Altivec instruction sets.

System calls: high-level languages rarely have a direct facility to make system calls, so assembly code is used.

But really isn't this just another way of looking at code injection, especially the way I wanted to use it? Isn't this really just embedding one language inside another for interpretation or compilation by the interpreter or compiler?

Now that I've prefaced the idea and hopefully suitably defended the potentially controversial architectural choice, in my next article I'll outline the implementation.

Read more from Tom Barker.