Decompilation

Decompilation is the reverse of compilation—it's the process of turning what is produced by a [compiler into what is given to a compiler. Typically, the goal is to turn an executable into source code using a human-readable programming language.

This process can be done by hand, but almost all the time it's going to involve some automation, with at least a disassembler of some kind, though full-blown executable-to-human-readable-programming-language decompilers do exist, with varying degrees of success depending on many factors (such as the quality of the decompiler itself, but also the nature of the executable or machine code in question, et cetera).

In the context of sprite animation, it mostly refers to SWF decompilation.

SWF decompilation
As described briefly in the Adobe Animate page,  files are somewhat similar to the, mostly in that a lot of high-level (that is, closely related to source code) information is retained in those resulting files. That information can then be used to infer what the source may have looked like with a much higher degree of accuracy (though in practice you still should expect this to be a lossy process).

Of interest to animators, as graphics in Flash are usually composited as the animation plays ("at run-time"), they are typically stored in s separated from each other, enough that they can be extracted and re-used much like the asset extraction process that makes (fan-made) sprite animation viable in first place. Similar concerns apply to sounds, and really any other part of a Flash movie that involves interpretation and mixing (by the Flash Player) of pre-processed graphics/audio/code/data.

Much ink has been spilled on the matter of decompilation, whether one should do it or not, its potential for damage to fellow animators, among other such topics. However, the important part is that it's impossible to avoid unless the  format is avoided in its entirety, for example, by converting a Flash movie to a video format like , and only distributing this resulting video file. At that point, only equivalents to the analog hole can really be exploited. The reason SWF decompilation is impossible to avoid is that, so long as the data is separated out somewhere inside the bytes of a file, its organization can be deduced. In the case of Flash, Adobe has published official documentation detailing the inner workings of  files, but that is not necessary, though it does help decompilation efforts.

Commonly used SWF decompilers include, but are not limited to:


 * JPEXS Free Flash Decompiler
 * Sothink SWF Decompiler

Obfuscation
Sometimes, in order to thwart decompilation efforts, obfuscation is employed, which for our purposes can be understood as structuring files such that they are valid (with respect to some target interpreter, such as Flash Player) but strange-looking (ideally to the point of incomprehensibility) compared to files produced by usual means.

This does not impact the feasibility of decompilation as the file necessarily has to be "understood" by at least one entity (in this case the target interpreter), thus all it can do is slow down the decompilation process.