How to prevent SWF files from being deserialized

The answer to the question raised in the title of this article is "impossible". At least it's impossible for me. With the right tools, we can decompile any SWF file. Therefore, do not place important information in the SWF file. Do not include a personal account or password in the SWF file.

I will briefly discuss the history of "protection" technology and how they failed, and then I will explain the best we can do. The Chinese old saying has the cloud, "the rule can only prevent gentleman, cannot imitate the villain".

Open File formats

Before we talk, we need to know that SWF's file format is public. The open file format means that the SWF file is not generated only by Flash. Other companies can also make SWF files that can be played on the SWF player. The open file format means that what information is obtained from what location is well known, which means that each byte is well known. So if I have time to check SWF files for a byte-by-byte, I can learn all the details.

Of course, for a 2M size SWF file, I don't have time to check bytes by byte. Therefore, I use the software to do this work. If the software encounters a problem, I will temporarily take over the job and check the bytes that have occurred. Fix it, and then continue. So, there is nothing to hide, its limit is only my time and my patience. If the reward for deserializing a SWF file is $ hundreds of, I think I'll spend a few years reading it byte by bit.

Okay, here's the history of war between anti-compilation and protection techniques.

Prevent being imported

Along with the advent of Flash, Macromedia provides developers with a "password protection against import" feature. If you add an import password to the SWF file, the SWF file cannot be imported (except when you know the password is poured). If the SWF file is not protected, vector graphics can be imported into the FLA file. This protection is of little use, just hypothetical security.

Imagine that your SWF is being played by the user's player, and you can't use the user's player to protect your SWF file. So how does it protect the SWF file? Quite simply, this protection exists in the Flash development tool you bought. The Flash development tool cannot import SWF files with (import) passwords. It's okay, right? I can open the SWF file with hex Edit, remove the protection password, and remove the protection function.

So simple, so forget to import the protection function.

Convert to projector file and compress

If I convert it to a projector file in EXE format, can I also decompile it? Answer: Yes, the SWF file still exists. The software makes it easy to release the SWF file from the exe file. Compression can make the SWF file unreadable by the hexadecimal editor, is compression a protection measure? The compression algorithm is similar to the zip algorithm and is easily cracked.

FLASM and the P-code

In the era of FLASH5, there were two popular tools, free "Flasm" and commercial "ASV 2.0". Flasm is "Flash asm", which interprets bytecode in the SWF as an understandable short code (p-codes). For example, "A=3" is shown as "push ' a ', 3", "SetVariable", and the bytecode in the SWF is: "at." If you want to learn the SWF format structure, this is a valuable tool.

Programmers like to develop software in high-level languages such as C, C + +, but when it comes to efficiency, they mix low-level assembly language. As a result, developers sometimes use Flasm to write low-level p-codes to increase efficiency. So, Flasm editing the ActionScript in the SWF is powerful. You can refer to an example to learn how to use this technique to optimize 3D code, but a malicious user can "edit" the SWF file, and any protection in the SWF can be easily removed. We do not need to know the password to remove the protection measures.

Here's a generic, well-known technology to protect our films from theft and display in other areas. We edit the script to check the _url property, and if _url is not our (legal) range, it invalidates the function and displays a message "You're Thief". However, it is easy to remove this script statement with Flasm. This protective measure can be cracked in 1 minutes.

ACTIONSCRIPT VIEWER and "Void (a) <=b>" C "| | 0 (! 1 &&! 0) "

ASV (ActionScript Viewer) can extract roles from the SWF, such as: Sounds, shapes, and bitmaps can be stolen.

It can also extract ActionScript bytecode, and ASV 2 attempts to match P-codes to a high-level actionscript. When "push ' a ', 3", "SetVariable" is encountered, "A=3" is displayed This is equivalent to the language of ActionScript. However, we are able to create code that does not have any pattern to match, thus destroying ASV's parsing. With Flasm, it is easy to write code that differs from the standard schema so that ASV does not perform the matching work. A well-known code that disrupts the work of ASV 2 is ";", which is a Jung code. It doesn't do anything, but it can mess up ASV 2 's work.

However, when the protection script is well known, the ASV author (Burakk) will certainly not let it go. This protection technique is not valid for ASV 3.

Rapid development of anti-compilation tools

After the advent of the MX era, many anti-compilation tools appear, speeding up the speed of flash doom.

In the current version of ASV 4, in addition to displaying the matching ActionScript code, the matching code is not displayed in p-codes form. If a problem is interpreted as p-codes, the bytecode in the SWF is displayed. It can also show the offset of the code in the SWF file, which means it does not expire. You can't disrupt its work because, at the very least, it can show "bytecode" in the SWF file.

What's more, Flash MX2004 provides a "FLA" file through the JavaScript API. That enables it to create a FLA file that is published in SWF format. At the moment, everything is over there.

Not to mention the sounds, shapes and bitmaps, thieves don't like these things because they're easy to get. The thief likes to cut the ActionScript because it hides the password because it has script code that prevents the movie from playing properly.

If ASV can only decompile the script into bytecode, it is useless for most thieves. So many people go into their best efforts to prevent ASV 4 from recompiling the script into ActionScript or p-codes. In fact, for most anti-compilers, the script does not match, and the decompile tool is useless.

These are some of the techniques that have been used, and when they are published on the internet and revealed by an anti-compilation organization, the protection of each technology eventually becomes very weak and the number will be exhausted.

Block decompile based on data size (sentence)

Most are able to successfully confuse or corrupt the anti-compiler because of the different behavior of the player and the anti-compiler. The player executes the bytecode one after the other, just like the real-world reading, a word, and then the next word. However, the anti-compiler usually divides the byte chain into meaningful fragments, like reading in the real world, a sentence, and then the next sentence.

The reason the anti-compiler behaves so simply is that most p-code follow the data size rule. For bytecode ("$ 1D"), the anti-compiler would like to "push what" when it encounters the 0x96 that represents the "push" operation? The next byte (0x0008) indicates that the contents of the 8 bytes are then pressed into the stack, i.e. ("00 61 00 07 03 00 00 00"). As a result, the anti-compiler usually cuts the short fragments into pieces based on the data size, which is interpreted as "push something". Therefore, ("96 08 00 00 61 00 07 03 00 00 00") becomes a sentence. The next byte is the beginning of the next sentence, which represents the 0x1d of "setvariable". Such a 8-byte "Something" will be further interpreted as a string "a" and a number "3".

Let's take a look at the bytecode: ("99 02 00 05 00 96"). 0x99 means branch (or jump), where does it branch? The next is (0002), so the data is stored in the two bytes of the machine down, and it is truncated at the following two bytes. In short, we know that "99 02 00 05 00" is a sentence. The next is 0x96, which represents the beginning of a sentence.

Look at the third example, bytecode: ("88 08 00 03 00 63 00 62 00 61 00 96 07 00"). 0X88 represents the definition of constants, what is the definition of constant content? Subsequent bytes (0008) indicate that the constant content is stored in a subsequent 8 bytes. So, the sentence is: ("88 08 00 03 00 63 00 62 00 61 00"). On behalf of the next sentence ("96 07 00 ... ), which means that 7 bytes of data are pressed into the stack.

Thus, the bytecode is chopped into separate sentences. Each sentence is made up of commands and data, and begins with a command. Therefore, each sentence is a basic unit. Theoretically, there is nothing wrong with this approach.

Let the player start reading data from the middle of the sentence

Let's start by discussing the "is the player reading data from the middle of the sentence" technique of destroying the anti-compiler.

First, let me cite a real-world example:

John says Good morning. Mary says thank you. Now generate the SWF file:

Skip 9 words Tom says John says good morning. Skip 3 words back 7 wordsmary says thank if you read the word one by one, the result is the same as the original, but the anti-compiler reads it by sentence, and the error naturally occurs. First, it knows what Tom said, but the grammar is not correct, reporting error; Second, it did not see the second "skip" command because it was in the middle of the sentence, and thirdly, when it was forced to return 7 words, it was puzzled that the whole sentence should start from "Tom said"; This error causes it to fall into an infinite loop between the second row and the third row.

In short, we added the "Tom said" garbage code and provided the error data size information for the entire length of the sentence. The length of the error overrides the "Skip" command.

To take a look at a real-world example, note that these techniques require the manipulation of bytecode, which is not possible with pure ActionScript.

Example 1:

A dead code that jumps forward that contains invalid dimension data.

Push True branchIfTrue Label2 constants ' Label2:push ' a ', 3setVariable if you look closely, you will find that "constants" is a garbage code that cannot be executed. In theory, however, it will be executed when the result of the second row is "not True". Therefore, the anti-compiler attempts to decompile it.

Let's increase the "sentence size" after "0x88-constants", which includes all the bytes that know the end of the script. You know, the anti-compiler will hack the bytecode into 3 sentences like this:

Push True branchIfTrue Label2 Constants Label2:push ' A ', 3 setvariable if you try to decompile this SWF file, according to the 4 errors I mentioned earlier, some anti-compilers will hit the wall. Some of the anti-compilers still survive, but only show: "if (false) {};". ASV 3 also cannot display this script, but ASV 4 can display it. In order to crack this SWF, we removed the dead code "constant xxxx", (0x88 and then two bytes), and then all the things were decompile.

Here is a zip file that will explain in detail how to make such a protected file.

Example 2:

The dead code that contains invalid dimension data has been jumped successively.

Push ' B ' label1:push ' A ', 3 setvariable branch Label2 Branch Label1

Label2:push ' B ' is a spam code and we'll modify it to make ASV 4 a hit. Let's modify the "length of sentence" Of the push ' B '. Modify the 2-byte data after "0x96" to increase the length of the sentence before the branch Label1. In this way, the anti-compiler will use the bytecode as a 3 sentence:

Push Label1:push ' A ', 3 setvariable Branch Label2 Branch Label1 Label2:

Now the anti-compiler doesn't know what to put on the stack, and it will form a dead loop between the first sentence and the second sentence. This technique will cause most of the anti-compiler to hit the wall. Flasm, ASV 4 is also invalid. To crack this SWF, we manually delete "Push B" (0x96 and 2 bytes later) so that everything can be deserialized.

When this technique is circulated, Burakk will modify ASV 4 so that it can properly handle the dead loop. So the next version of ASV will be able to deal with this technology.

Here is a zip file that will explain in detail how to make such a protected file

　　

Non-display characters and obfuscation

In addition to blocking the anti-compiler technology, we can also make the results of the anti-compilation is not easy to read. You can browse the website about the obfuscation.

Basically, it is renaming the names of variables and functions.

Function-3 ( -4) {trace ( -4);} function-1 (0,-2) {if (0<-2) {-3 (1)}}

To be sure, thieves cannot use the code simply by copying and pasting. The compiler does not allow you to name a function like this.

The limitation of the obfuscation is that changing the name of the function may cause trouble to the script code below.

function Myfun () {Trace ("Myfun"),} a= "my"; b= "fun"; this[a+b] ();

Another technique is to make the name of a function non-visible. For example, using Chinese as a function name, the anti-compiler may not be able to display it well. Then we will see:

Function? （）{？ ，？ ）{？。？ = ；}

ASV 4 Displays non-displayable characters using Unicode encoding, so the result is easy to read, but adds slightly more difficulty.

Self-protection

If you find a good way to protect your SWF against anti-compilation, do not share this method with others, at least do not expose it on the Internet. Of course, it can't be over 100% anti-decompile, at least for me. However, not all people are familiar with the SWF format. Many, thieves only use the software to decompile the SWF. So if you're aiming for as few thieves as possible to steal your SWF, then protect your secret method (White Tiger swf).

Just here to remind you that your SWF is unprotected. For people who are familiar with SWF format, everything is completely obscured. If your goal is to protect only "some functions", it should be safe. They may not steal your functions, they will write their own functions.

General protection measures

We put an online game on the website, unfortunately, many visitors just visit our site only once, and then use the downloaded version to play offline. Sometimes we even find that our games appear on other sites.

To prevent this from happening, here are the protective measures that can be taken:

1. Field inspection

Script Check _url, if _url is "" Play the movie, otherwise do not play or exit. When playing offline, the _url should look like "file://C| Somesub/game. SWF "; But when it is in other domain, the _url is like" ". Therefore, this technique can be properly added with some protection. Of course, it is useless for a bad anti-compiler. Those scripts can be deleted or modified without checking by Flasm. Although it may not be possible to see the cracked SWF file in other public places, SWF that can be played offline can occur.

2. Server-side password verification

Write the script and load the password from the server when you start the game. If the password is empty, stop the game or quit the game. This can easily be cracked by malicious users, who simply edit the SWF file and delete those scripts. Which scripts can not be deleted? When the game starts, the map data loaded from the server is required for the game, so it is not possible for undesirable users to delete the scripts. In order to play, it must provide these map data. Of course, it can pick up the map data from the data cached in the Temp folder and provide it to the SWF to activate the game.

3. Place the SWF or variable on the server

This is the second technology extension, extension, the technology has been widely used. The original game (SWF) file is just a loader, and when you click the play (or Start) button, another SWF file is loaded. When a map file is needed, the map data is loaded from the server. When loading data is blocked, the blocked SWF file is loaded again from the service segment. The data on the new layer is also transmitted from the service side.

From here. We can see a principle that the best way to prevent anti-compilation is to "not give".

If some stupid thief only download the game. SWF file, he can't play this game. He needs to pick out all the SWF files and variables in the cache. Open all the SWF files and edit the names of the variables so that they match the names of the variables in the cache.

If our map is randomly generated by CGI, the thief may only have a map, and he does not have the power to generate the map randomly. If it is a maze game, at best, he can only play a maze, he does not have a "dynamic maze" function. If you have a bad user playing this game will encounter a new obstacle, because in his cache does not have this new blocked SWF file, so will not play.

Therefore, many algorithms and functions are placed on the server side, the SWF file is just an interface. This is a perfect protection, but the flaw is that it produces a CGI, rather than a flash, that turns into a game job. We are discussing the protection of SWF, which is inappropriate because the SWF file itself is not protected

How to prevent SWF files from being deserialized