The answer to the title of this article is "impossible". At least it is impossible to me. With proper tools, we can compile any SWF files. So don't put important information in the SWF file. Do not include your personal account or password in the SWF file.
I will briefly discuss the history of "protection" technology, and how they fail, then I will explain the biggest efforts we can do. Chinese ancient languages have clouds, "rules can only prevent gentlemen, can't imitate small people."
Open file format
Before discussion, let's first know that SWF's file format is open. The disclosed file format means that the SWF file is not only generated by flash. Other companies can also produce SWF files that can play on the SWF player. The public file format means what information is well known, which means that each byte is well known. So if I have time to check the SWF file with one byte, I can learn all the details.
Of course, for a 2M size SWF file, I have no time to check one byte one byte. Therefore, I will do this with software. If the software encounters a problem, I will temporarily take over this work and check the byte of the problem. Fix it and continue. So, there is nothing to hide, and its restriction is just my time and my tolerance. If the rewards of a SWF file are hundreds of dollars, I think I will spend a few years to read it one byte by one.
Ok, the following is the history of war between anti-compilation and protection technology.
Prevent imported
With the appearance of Flash, Macromedia provides developers a "prevention imported password protection" feature. If you add an import password to the SWF file, this SWF file cannot be imported (except that the password is poured). The SWF file is not protected, where the vector graphics can be imported into the FLA file. This kind of protection is not used, just imaginary security.
Imagine that your SWF is played by the user's player, you can't use the user's player to protect your SWF file. So how is it to protect the SWF file? Very simple, this protection is in the Flash development tool you bought. Flash development tools cannot import SWF files with (import) passwords. It doesn't matter, right? I can open the SWF file with hexadecimal editing, delete the protection password, so that the protection function is removed.
So simple, so forget import protection.
Convert into projector files and compressed
Can I convert it into an EXE format projector file, can I be confined? Answer: Yes, the SWF file still exists. With software, you can easily release the SWF file from the EXE file. Compression can make the SWF file cannot be read by the hex editor, compressed is a protection measures? The compression algorithm is similar to the ZIP algorithm, it is easy to crack.
Flasm and the p-code
In the era of Flash5, two popular tools appeared, free "Flasm" and "ASV 2.0" of the business. Flasm is "Flash ASM", which interprets the bytecode in the SWF into the understandable brief code (P-CODES). For example, "A = 3" is displayed as "Push 'A', 3", "setvariable"; the bytecode in SWF is: "96 08 00 61 00 07 03 00 00 1d". This is a very valuable tool if you want to learn the "SWF format structure".
Programmers like to develop software with advanced languages (such as: C, C ), but when the efficiency is tested, they will mix using low-level assembly languages. Therefore, sometimes developers will use FLASM to write low-level P-Codes to increase efficiency. So, the ActionScript in Flasm editing SWF is powerful. You can refer to an example to learn how to use this technology to optimize 3D code, but with malicious users can "edit" SWF files, any protection in SWF can be removed. We don't need to know the password to remove protection. There is a universal, well-known technique to protect our movie is not stolen and display it within other ranges. We edit the script to check the _url property, if _url is not the range of our (legal), enables function to fail and display a message of "you are through". However, this scripting statement can be easily deleted with Flasm. This kind of protection measures can be broken without a minute.
ActionScript viewer and "void (a) <= b>" c "|| 0 (! 1 &&! 0)"
ActionScript Viewer can extract roles from SWF, such as::: sound, shape, and bitmap, etc., can be steadped.
It can also extract the ActionScript bytecode, and ASV 2 attempts to match P-CODES to high-level ActionScript. When you encounter "Push 'A', 3", "SetVariable"; "A = 3" is displayed in the language of ActionScript. However, we can create a code that does not match any modes, thereby destroying the resolution of ASV. With FLASM, you can easily prepare a code different from the standard mode, so that the ASV cannot match the job. A famous code that disrupts ASV 2 work is ";", this is a JUNG code. It doesn't make anything, but it can make the work of ASV 2.
However, when protecting the script, the author of the ASV (BURAKK) is of course not letting it. This protection technology is invalid for ASV 3.
Rapid development anti-compilation tool
After that, it is the arrival of the MX era, and many anti-compilation tools have accelerated the speed of Flash bad luck.
The current version of ASV 4 does not display the matching code in P-CODES in addition to displaying the matching ActionScript code. If interpreted as a P-CODES problem, the byte code in SWF will be displayed. It can also display the offset of the code in the SWF file, which means it won't fail. You can't disturb it, because at least it can display "bytecode" in the SWF file.
What's more is that Flash MX2004 provides a "FLA" file through the JavaScript API. That makes it possible to establish a FLA file that is sent into SWF format. At this moment, all things are there.
Don't say that sounds, shapes and bitmaps, theft doesn't like these things because they have easy to achieve. Theft likes to cut ActionScript because it hides the password because there is a script code that blocks the movie from normal play.
If the ASV can only compile the script into a zona code, it is useless for most thefts. So many people enter their maximum effort to prevent ASV 4 from compiling scripts into ActionScript or P-Codes. In fact, for most anti-compiler, the script does not match the match, and the anti-compilation tool is useless.
This is some technologies that have been used. When they release them on the Internet and are revealed by the anti-compilation organization, each technological protection effect will ultimately become very weak and the number of angles will be exhausted. Based on data size (sentence)
Most of the reasonable confusion or destroying the anti-compiler is due to the different behaviors of the player and the anti-chief. The player performs bytecode one by one, just like reading in the real world, a word, then the next word. However, the anti-compiler usually divides the byte chain into meaningful pieces, just like reading in the real world, one sentence, then next sentence.
This simple reason is that most of the P-CODE is compliant with data size. For bytecodes ("96 08 00 00 00 00 07 03 00 00 1d"), the anti-compiler encounters "Push what is" when the 0x96 represents "PUSH" operation? "Next byte (0x0008) indication Content: The contents of the contents in the 8 bytes are pressed into the stack, ie, press ("00 61 00 07 03 00 00") into the stack. Therefore, usually the anti-compiler cuts a short piece based on the data size, which will be explained as "push kindhers". 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, that is, "setvariable" 0x1D. Such an 8-byte "Something" will be further interpreted as a string "a" and a number "3".
Let's take a look at the byte size: ("99 02 00 05 00 96"). 0x99 means branch (or jump), where is the branch? The next thing is (0002), so the data is stored in the two bytes of the machine, and it is truncated at the two bytes below. In short, we know "99 02 00 05 00" is a sentence. The next thing is 0x96, representing the beginning of the next sentence.
Look at the third example, byte code: ("88 08 00 03 00 63 00 62 00 61 00 96 07 00"). 0x88 represents the defined constant, what is the constant content? Subsequent bytes (0008) indicate that constant content is stored in the 8 bytes of the subsequent. Therefore, sentence is: ("88 08 00 03 00 63 00 62 00 61 00"). Representing the next sentence ("96 07 00 ...) means that 7 bytes of data are pressed into the stack.
Therefore, the byte code is chopped into a separate sentence. Each sentence consists of commands and data, and heads with commands. Therefore, each sentence is a basic unit. In theory, there is no error in this method.
Let the player start reading data from the middle of the sentence
Let us begin to discuss the technology of destroying the anti-compiler of the player from sentences.
First of all, I will give an example of a real world:
John Says Good Morning. Mary Says Thank you. Now generates SWF files:
Skip 9 Words Tom Says John Says Good Morning. Skip 3 Words Back 7 Wordsmary Says Thank you. If you read one by one, the results are the same as that, however the anti-compiler is read according to the sentence, and there is an error in the sentence. First, it knows what TOM said, but the syntax is wrong, report an error; second, it didn't see the second "Skip" command, because it is in the middle of the sentence; third, when it is forced to return 7 words I feel confusing, I think it should be implemented from "Tom Said"; fourth, this error is in an infinite loop between the second line and the third row. In summary, we add "Tom Said" spam, and provides the error data size information of the entire sentence length. The length of this error covers the "SKIP" command.
To look at a real example, please note that these techniques need to operate bytecode, pure ActionScript is not possible.
example 1 :
The dead code containing invalid size data forward jumps.
Push True Branchiftrue Label2 Constants', 3Setvariable You Look carefully, you will find "constants' '" this line is spam, it is impossible to be executed. However, in theory, when the result of the second row is "not true", it will be executed. Therefore, the anti-compiler attempts to compile it.
Let's increase the "Sentence Size" behind "0x88 - Constants", including all bytes that know the script end. You know, the anti-compiler will cut the byte code to 3 sentences like this:
Push True Branchiftrue Label2 Constants Label2: Push 'A', 3 setvariable If you try to refine this SWF file, some anti-compiler will touch the wall according to the four errors mentioned earlier. Still some anti-compiler survive, but only display: "if (false) {};". The ASV 3 cannot also display this script, but the ASV 4 can display. In order to crack this SWF, we removed the dead code "constant xxxx", (0x88 and the following two bytes), and then all things have been contracted.
Here is the zip format file, which will explain how to make such a protected file.
Example 2:
The dead code containing invalid size data is jumped.
Push 'b' label1: push 'a', 3 setvariable branch label2 branch label1
Label2: push 'b' is a junk code, we will modify it, used to make the ASV 4 hit the wall. Let us modify the "Length of Sentence" of Push 'B'. Modify the two bytes of data behind "0x96" to increase the length of the sentence before the branch label1. In this way, the anti-compiler will use the byte code as 3 sentences:
Push Label1: Push 'A', 3 setvariable branch label2 branch label1 label2:
Now, the anti-compiler does not know what is pressing in the stack, and it will form a dead cycle between the first sentence and the second sentence. This technique will cause most of the anti-compilers to touch the wall. Flasm, ASV 4 is also invalid. In order to crack this SWF, we manually remove "Push B" (0x96 and 2 bytes of followed), so all things can be confined. When this technology is circulated, Burakk will modify the ASV 4 so that it can handle the dead cycle correctly. Such a next version of ASV can deal with this technology.
Here is the file of ZIP format, which will explain how to make such a protected document.
Non-display characters and obfuscors
In addition to hindering the techniques of the anti-compiler, we can also make the anti-compilation result is not readily read. You can browse the website about the obfuscator.
Basically, it is renamed the names of variables and functions.
Function -3 (-4) {trace (-4);} function -1 (0, -2) {IF (0 <-2) {- 3 (1);}}
Very sure is that the theft cannot be just copy, and the paste can use these code. The compiler does not allow you to make such names for a function.
The limitation of the obfuscator is that the name of the change function may bring trouble to the following script code.
Function myfun () {trace ("myfun");} a = "my"; b = "fun"; this [A B] ();
Another technology is that the name of the function is not displayed. For example, use Chinese characters as a function name, the anti-compiler may not display it well. Then we will see:
Function? () {?,?) {?.? = ?;}
The ASV 4 uses Unicode encoding display that cannot be displayed, so the result is easy to read, but it has only increased slight difficulty.
Self-protection
If you find a good way to protect your SWF, don't share this method with others, you don't want to disclose it on the Internet. Of course, it cannot be 100% anti-anti-rebound, at least for me. However, not all people have the format of SWF. Many, theft is only used to refine SWF only by means of software. So if your purpose is to steal your SWF as little steal, then protect your (White Tiger SWF) secret method.
Just remind you here, your SWF is unprotected. For those who are familiar with the SWF format, all things are unless. If your goal is just to protect "some functions", it should be safe. They may not steal your function, they will write their own functions.
General protection measures
We put a online game on the website. Unfortunately, many visitors just visited our site only once, and then use the downloaded version to get offline. Sometimes, we even discovered that our game appeared on other sites.
In order to avoid this, the following is the protection measures that can be taken:
1. Explore the field
Write script check _url, if _url is "http://www.mydomain.net/game.swf" to play movies, otherwise do not play or exit. When you are playing offline, _url should be like "file: // c | somesub / game.swf"; but it is in other Domain, _URL is like "http://www.nethers.net/game.swf" . Therefore, this technology can be appropriately coupled with some protection. Of course, it is useless for negative anti-compiler. Those scripts can be deleted or modified by Flasm. Although the SWF that is cracked in other publications may not be seen, the SWF that can be played offline can also occur.
2. Service port verification
Write scripts and load passwords from the server when starting the game. If the password is empty, stop the game or exit the game. This is easy to be crackled with malicious users, they only want to edit the SWF file, delete those scripts. Which scripts can't be deleted? When the game is started, the map data loaded from the server is a game must be made, so the user's poor user cannot delete these scripts. In order to make a game, it must provide these map data. Of course, it can select the map data from the data in the temporary folder, provide to swf, to activate the game. 3. Place SWF or variables in the server
This is the second technology extension, extension, which has been widely used. At first game (SWF) file is just a loader, another SWF file will be loaded when you click the play (or start) button. When the map file is required, the map data is loaded from the server. When the loading data is hindered, the hindered SWF file will be loaded from the service segment. The data on the new layer is also passed from the server.
From here. We can see a principle: the best way to prevent anti-compilation is "not".
If some stupid thieves download only download the game.swf file, he can't play this game. He needs to pick all SWF files and variables in the cache. Open all SWF files, edit the names of these variables, so that it is consistent with the names of the variables in the cache.
If our map is randomly generated by CGI, the thief may only have a map, he does not randomly generate the power of the map. If it is a maze game, it is charged, he can only play a maze, he does not "dynamically produce maze" function. If the adverse user playing this game will encounter a new hindrance because there is no new hindered SWF file in his cache, so you will not be able to play.
Therefore, many algorithms and functions are placed on the server, and that SWF file is only an interface. This is a perfect protection measures, but the defect is this CGI that turns a game to game work, not Flash. We are discussing the protection of SWF, this solution is not appropriate, because the SWF file is not protected himself.
(Finish)
Limited level, please criticize the correct. Mailtoxmanceo@yahoo.com.cn
