The best way to prevent software cracking with distorted transform encryption

First, generally speaking, encryption is the shell we often consider, an executable file, how to encrypt to be safe? The usual means is the Packers. The working principle of the Shell tool is to encrypt the code and data of the executable file as data storage. The generated target file entry code is the anti-trace code prepared by the Packers software. After a long code, the code of the original executable file and the Data section restore, and then jump to the original entrance, continue to run. The disadvantage of this is that no matter how strong your encryption, anti-tracking code many cows, as long as a run, in memory will be all restored. Just dump the memory image and disassemble it. There are even tools to save the dump of memory as an executable file directly. So the encryption fails completely. Simple packers are unsafe, as everyone knows. We generally call the above simple shell method "compressed shell". So now the shell software in the above "compressed shell" based on a number of work done, such as: * To prevent memory from being dump. This is actually impossible. Because the Windows operating system is not a security system, how can you do it without being dump? Once there was a shell, I used a variety of methods dump is unsuccessful. But finally found a way to successfully dump. I just marvel that there are so many ways to dump the original. * Modify the file entry code. Because General software is compiled with several commonly used compilers. If the shell software knows what compiler you are using (which is easy), break the entry code and replace it with another piece of code that is similar. This dump code is more difficult to find the right entrance, directly saved as an EXE is much less likely. But it will be disassembled. * There are additional shell software that supports encryption of one or several key functions. Even use a virtual machine. But they can only focus on the encryption of a few functions, it is impossible to encrypt all functions. And there are a lot of requirements for this function. This can be imagined. If you write a function with a remit, it may not even be able to find the end address of the function, how can it be encrypted? Although the shell software can use the above multiple techniques to prevent being tracked, analyzed, and restored, I think they are still not getting rid of this central idea of the shell. These techniques are just some minor episodes under the premise of "shell". It is still unsafe for two, twisted compiled ideas to make a metaphor. Shell protection is like a treasure on your desk, and to protect it, you have a circle of barbed wire outside the house. As soon as someone breaks through the barbed wire and enters your house, one sees the baby on the table. Of course it's not safe. Key function of the idea of encryption, like, my house outside a circle of barbed wire, I also put the baby into the safe. If someone breaks through the barbed wire and enters the house, a safe is seen at a glance. Though the safe won't be easy to beatOpen, but what if he moves the safe and analyzes it slowly? It's not safe enough. The safest is to go into the house and find nothing. There is no goal, this is the most annoying. Now the compiler is the pursuit of generating efficient running code. The pattern of these codes is fundamentally unchanged. Experienced programmers see the disassembly code as simple as looking at the source, no secrets to say. If we have a compiler, its compiler goal is not to be efficient, but to prevent being read, that would be good! I have C + + source code, I can understand. Once compiled, no one can see through the disassembly to understand what I want to do, or difficult. Unfortunately, such a compiler is not yet. What if we make up one of these compilers ourselves? Unrealistic. The workload is too great. Even find an open source C + + compiler to change the workload. It's not going to work directly as a cryptographic compiler. Once you have compiled the connection to generate an EXE, you can only add the shell. Is there no way? I came up with the idea of encrypting the intermediate file obj, outputting the asm file, compiling it into obj with ML, and then connecting to link! This method has several advantages: * obj file format is relatively simple. It's not as much work as working with C + + source files. * obj file retains a lot of source file information, such as symbol name, code and data, marking and so on. Easy to encrypt. Much of this information was lost in Link's process. So link for EXE after processing is extremely inconvenient. * It's a whole new thought! The encryption of the code is not limited to the Packers, but the encryption of each function, each instruction. No more glance of the assembly. * can easily set the strength of the encryption. You can encrypt a portion of your code as needed, and then encrypt the other part of the code with emphasis. * You can nest encryption. Reuse several cryptographic transformations to inflate the code indefinitely. * Because it is encrypted obj file, so regardless of dll or EXE can be successfully encrypted, the driver can also be based on this idea, our encryption software is about to come out! We'll call it a twisted converter. 1.0 three, twisted converter with the idea, it began to code. Originally thought obj file format is documented, the project schedule should be very fast. I didn't think there was a lot of content to consider. Often say this is the last question, the solution is OK, but always deferred. It was written for almost half a year. Main technical problems encountered: * Assembler ML will put all the code in a paragraph, this is not possible. CL is usually a segment of a function. * Assembler ml cannot generate comdats segments. Although the document says it supports common, adding this keyword has no effect. * Assembler ML does not support weakextern * Assembler ml only supports defaultlib this one drectve keyword, other export, incluDe and other keywords are not supported. In short, CL compiles obj many of which are not generated by ML. Microsoft's MASM really should be upgraded. There are also some questions: * Confusing code with data. Data segments are definitely data, but the code snippet may not be code, it's data. Then if you try to disassemble it, you make an error. * ????? Anyway, these problems are solved (don't ask me how). Code-distorting approach: * Use JMP to disrupt code. This is no new trick, but it still works. * Use JMP to wrap multiple functions together. This allows the analyst to find out where the function starts and where it ends. * Get rid of call. The cracker is very sensitive to call, which allows him to find no one called. For example, I can change call sub1 to: mov eax, offset sub1 + 3 push offset @1 sub eax, 3 jmp eax to get rid of ret. The cracker is extremely sensitive to RET, which allows him to find no ret. For example, I can write ret: push ECX mov ecx, [esp+4] Add esp,8 jmp ecx* change the condition jump. Conditional jumps are also extremely sensitive directives, such as we can put: CMP reg1, REG2 jge l_dst l_next: Writing: Push EAX mov eax, reg1 sub eax, REG2 shr eax, 1fh neg eax and eax , l2-l1 add eax eax l1:pop eax jmp l_dst l2:pop: Look at this, can you understand what it means: Push offset eax 23h JMP L_1L_2:JZ l_3 ret 4l_3:add dword ptr [esp+4], offset l_3-23h add esp,4 retl_1:call ... Call and Ret appear here, but not as expected. Call here does not mean that you have found a function invocation. The RET here does not represent the end of a function. * Use a stack instead of a register. For example: Mov EAX, DWORD ptr [ecx+0ad8h] PUSH EAX MOV ECX, DWORD ptr [EAX] can write: Push EAX push ECX MOV EAX, DWORD ptr [ESP] ADD EAX, 0ad8h mov EAX, DWORD ptr [EAX] mov dword ptr [esp+04h], EAX PUSH DWORD ptr [esp+04h] mov EAX, DWORD ptr [ESP] mov dword ptr [esp+08h], EAX mov EAX, DWORD ptr [ESP] mov EAX, DWORD ptr [EAX] mov dword ptr [esp+04h], E AX mov EAX, DWORD ptr [ESP] MOV ECX, DWORD ptr [esp+04h] ADD ESP, 08h can you read it? Obviously, this transformation is irreversible. Because it used which registers, there is no way to know. * ...... You can also think of many ways to distort the transformation. There is only one way to simplify the process, and there are infinitely many ways to simplify it. There are also functions: * in C, use #pragma code_seg (". Code$curve_nochange") to indicate that the following code does not do any encryption. Because sometimes some code contains a lot of loops, encrypting it can seriously affect efficiency. * In the C language, use the #pragma code_seg (". Code$curve_max") to indicate that the following code focuses on encryption. For example, the following is related to the registration algorithm. Now the twisted converter I call it 1.0 version, has been very stable. I use it to VC6 the library file lib have been processed, and then use the LIB.exe tool to write back to the Lib file, we have a set of encrypted library. If you use this library to link your software, it is very difficult for analysts to find from the assembly which is printf which is strcpy,ida and cannot recognize the MFC statically linked library functions. It's not wrong to encrypt VC6 's library, I believe it's strong and stable. Using it to encrypt a shared software we do, no one ever writes a registration machine. It is inconceivable to read a large number of code that passes through the above transformations. But still someone burst, really admire him. I will continue to enrich the encryption method, let the mob give up. Now the twisted converter only supports obj in the COFF format used by VC6, the next step is to analyze the VS2005 obj format and support it as soon as possible. There are a few: * This software is temporarily not published, only their own use. If a friend wants to encrypt their code, you can send the obj file to me for encryption. Prevent all software to use this encryption, we will IDA will have no food to eat:( * Now only supports VC6 obj format,Is COFF. The next step is to support the VS2005 obj format and encounter problems. VS2005 Debug Compilation obj or COFF, but release compiled obj do not know what format, can not find data. Who can help solve this problem? Thank you. We use the username 12345678 Error Registration code 33333333 For example, at 40147E. As we can see, the program calculates our registration code as a 16-in-System AF AF AF and then continues, counting our registration codes at 40180A to B6 B7 B8 B9. Then we show our username in 405310 to 31 32 33 34 35 36 37 38. So far, in the stack, our username, registration code is shown as stack address 12ff18. Pseudo-Registration Code Part 16: Number of AF AF AF af-B6 B7 B8 B9 1D 1E 1F of Be BF C0 C1 C6 C7 C8 00. User Name section: 31 32 33 34 35 36 37 38 31 32 33 34 35 36 37 38 31 32 33 34 35 36-37. After the expansion is the user name and registration code mixed operation, at 40226A can see the results of the operation (this process is the most complex, indeed no time for careful analysis, so did not look at) at 4083DD we can see SUB Eax,3467abde this is the blasting mouth, change him into MOV EAX, 00 BLASTING SUCCESS!!!! Anyway is blasting 4083DD, he changed to B8 00 00 00 00, run on OK!!! Zhao Zhaoyi@51cto.com TEL: (010) 68476636-8001 to force (0 Votes) Tempted (0 Votes) nonsense (0 Votes) Professional (0 Votes) The title party (0 Votes) passing (0 Votes) Text: Distorted transform encryption to prevent software cracking best way to return to network security home