Jump With Same Target
Jump with the same target is an anti-disassembling technique that involves using back-to-back conditional jump instructions that both point to the same target. This can make it difficult for a disassembler to accurately reconstruct the original instructions of the program, as the disassembler will not be able to determine the intended behavior of the program without actually executing it.For example, suppose a program contains the following instructions:
mov eax, 0x12345678
jz loc_512
jnz loc_512
In this case, the jz and jnz instructions are back-to-back conditional jump instructions that both point to the same target, loc_512. This means that the program will always jump to the loc_512 location, regardless of the value of the eax register. However, a disassembler that is working correctly would not be able to determine this intended behavior, as it only disassembles one instruction at a time and does not consider the behavior of the program as a whole.
In this case, the jz and jnz instructions are back-to-back conditional jump instructions that both point to the same target, loc_512. This means that the program will always jump to the loc_512 location, regardless of the value of the eax register. However, a disassembler that is working correctly would not be able to determine this intended behavior, as it only disassembles one instruction at a time and does not consider the behavior of the program as a whole.
This allows the code to demonstrate the intended behavior of the original instructions, which is to always call the my_function function, regardless of the value of the eax register. This technique can make it difficult for a disassembler to accurately reconstruct the original instructions of the program, as the disassembler will not be able to determine the intended behavior of the program without actually executing it.
C++:
#include <stdio.h>
void my_function() {
printf("Hello, world!\n");
}
int main() {
int eax = 0x12345678;
// Original instructions
if (eax == 0) {
my_function();
}
if (eax != 0) {
my_function();
}
// Obfuscated instructions using back-to-back conditional jumps
if (eax == 0) {
my_function();
}
my_function();
return 0;
}Obscuring Control Flow
Obscuring control flow is an anti-disassembling technique that involves using methods of flow control that are difficult or impossible for disassemblers and debuggers to follow. This can make it more difficult for analysts to understand the program's behavior and can also make it more difficult for other tools, such as debuggers, to accurately interpret the program.
One example of this technique is the use of the Structure Exception Handling (SEH) mechanism in the Microsoft Windows operating system. SEH provides a way to handle exceptions, which are runtime errors that occur during the execution of a program. It allows the programmer to define a set of exception handlers that are called whenever an exception occurs. These exception handlers can be used to handle the exception and continue the program's execution, or to log the error and terminate the program.
SEH provides a method of flow control that is difficult for disassemblers and debuggers to follow, because the exception handlers are not part of the program's normal control flow. Disassemblers and debuggers are not able to accurately reconstruct the program's original instructions when SEH is used, because they cannot determine the intended behavior of the program without actually executing it.
This code includes an exception handler that is called whenever an exception occurs. This exception handler calls the my_function function, which simply prints "Hello, world!" to the console. The obfuscated instructions use the SEH mechanism to obscure the control flow of the program, by raising an exception and handling it with the exception handler.
C++:
#include <Windows.h>
#include <stdio.h>
void my_function() {
printf("Hello, world!\n");
}
LONG WINAPI exception_handler(EXCEPTION_POINTERS *exception) {
my_function();
return EXCEPTION_EXECUTE_HANDLER;
}
int main() {
int eax = 0x12345678;
// Obfuscated instructions using SEH
__try {
if (eax == 0) {
my_function();
}
RaiseException(0x12345678, 0, 0, NULL);
} __except (exception_handler(GetExceptionInformation())) {
}
return 0;
}Call Trick
The call trick is an anti-disassembling technique that involves modifying the default function's return address. This can be used in conjunction with other techniques, such as the insertion of garbage bytes, to break disassemblers. Disassemblers that use recursive traversal or linear sweep may be particularly vulnerable to this trick, as they may be unable to accurately interpret the next instruction after the call, making them susceptible to other anti-disassembly techniques.
This code modifies the default function's return address to point to a different location, in this case 0x123456. It also inserts some "garbage" instructions (in this case, four no-op instructions) to break disassemblers that use recursive traversal or linear sweep. This makes it more difficult for disassemblers to accurately interpret the next instruction after the call, making them susceptible to other anti-disassembly techniques.
C++:
#include <stdio.h>
int main() {
// Store the current value of the return address
void *return_address = __builtin_return_address(0);
// Modify the return address to point to a different location
__builtin_return_address(0) = (void *)0x123456;
// Insert garbage bytes to break disassemblers
__asm__("nop\n"
"nop\n"
"nop\n"
"nop\n");
// Use the modified return address
return 0;
}Opcode Obfuscation
Opcode obfuscation is an anti-disassembling technique that involves modifying the opcodes of a program's machine language instructions in order to make it more difficult for a disassembler to accurately reconstruct the original instructions. This can be done in a variety of ways, such as by using equivalent but different opcodes for the same operation, by adding additional instructions or data to the program, or by rearranging the program's instructions in a non-standard order.
Opcode obfuscation is a common technique used by malware authors and other attackers to make it more difficult for analysts to disassemble and understand their programs. It can be used in conjunction with other anti-disassembling techniques, such as the call trick or the insertion of garbage bytes, to create even more effective and powerful exploits.
Disassembly Desynchronization
Disassembly desynchronization is a technique that is used to prevent disassemblers from accurately reconstructing the original instructions of a program. It involves the creative use of instructions and data in a way that breaks the normal, predictable sequence of instructions in a program. This can cause disassemblers to become "desynchronized" and generate incorrect disassembly output.
For example, suppose a program contains the following instructions:
mov eax, 0x12345678add eax, 0x00000004A disassembler that is working correctly would recognize these instructions and generate the following disassembly output:
0x00000000: mov eax, 0x123456780x00000004: add eax, 0x00000004However, if the programmer uses disassembly desynchronization techniques, they could rearrange the instructions in the program in a way that breaks the normal sequence of instructions. For example, they could insert some "garbage" instructions or data between the mov and add instructions, like this:
mov eax, 0x12345678nopnopnopnopadd eax, 0x00000004In this case, a disassembler that uses a simple, linear sweep algorithm might become "desynchronized" when it encounters the nop instructions and generate incorrect disassembly output. This can make it difficult for an analyst to understand the program's behavior and can also make it more difficult for other tools, such as debuggers, to accurately interpret the program.
Disassembly desynchronization is a well-known anti-disassembly technique that is commonly used by malware authors and other attackers to make it more difficult to analyze and understand their programs. It can be used in conjunction with other anti-disassembly techniques, such as the call trick or the insertion of garbage bytes, to create even more effective and powerful exploits.
C++:
#include <stdio.h>
int main() {
// Original instructions
__asm__("mov eax, 0x12345678\n"
"add eax, 0x00000004\n");
// "Garbage" instructions that break the normal sequence of instructions
__asm__("nop\n"
"nop\n"
"nop\n"
"nop\n");
// More original instructions
__asm__("mov ebx, 0x87654321\n"
"sub ebx, 0x00000004\n");
return 0;
}
did you even try to verify ANY of that...?
