How to prevent SWF files from being refined?
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 one
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 compress
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, there have been two popular tools, free "Flasm" and business "ASV.
2.0
"
. Flasm is "Flash ASM", which interprets the bytecode in the SWF into the understandable brief code (P-CODES). For example, "a =
3
"
The bytecode in SWF is: "96 08 00 00 61 00 07 03 00 00 1d" in SWF is: "96 08 00 00 61 00 07 03 00 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 sign good morning.
Mary say Thank you.
Buy SWF files now:
SKIP 9 Words
Tom Says John Says Good Morning. Skip 3 Words
Back 7 Words
Mary say 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 a mistake in the case. 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 ''
Label2:
Push 'a', 3
Setvariable
If you look carefully, you will find that "constants ''" is a junk code, 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 refract this SWF file, some anti-compiler will hit 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 zip format file, which will explain how to make such a protected file.
Limited level, please criticize the correct.
E-mail: xmanceo@yahoo.com.cn
related articles:
How to prevent SWF files from being refined? (two)
