Obfuscation of application code

In addition to runtime encryption or bytecode conversion, many code obfuscation techniques focus on changing the control flow of applications. These technologies aim to gain excess profits, whether in an abstract state or in a too abstract state. Complexity is always a problem at both ends of the structure pedigree. To do this, you can use the following policies:

• Internal and external
• Reordering
• Use Exception Handling transfer control
• Code staggered
• Centralized Function Distribution  

Inline replaces each function call with the function body. In this way, the program can avoid overhead of building stack frames and redirecting around the memory. Inline is a fairly standard optimization technique, which maximizes the speed of switching between large and small numbers. Try to improve the execution speed of the final executable file, but it is still relatively large. This is a convenient technology that does not require much time (usually you only need to switch the compiler configuration options), but at the same time it can generate benefits, it destroys the program structure that is strongly enhanced by the advanced programming language.

External Connection is another situation. In order to change time by space, it tries to integrate repeated parts of the program logic into dedicated functions. The program requires less space, but because of the overhead of new function calls, the program will take more time to run. Because the memory of the embedded system is a scarce product, anyone who uses the embedded system will immediately approve of this policy. If it is used excessively, this approach will convert each statement into its own function call. If inline functions are not introduced, and external functions are introduced only, both extremes can confuse analysts.

The reordering operation depends on the fact that not all statements in the function are sequential dependencies. This technology can be better utilized by identifying these statements that are relatively independent from each other and mix them as much as possible. To enhance the effect, you can combine the re-sorting and staggered use. However, this technology may cause a lot of confusion at the source code level, so we recommend that you perform Command Re-sorting at the machine code level.

Most developers can use exception handling in some way. Our Mentor generally fails to tell us that exceptions can be used to perform sudden global jumps between functions. This feature of remote jump can lead to extremely subtle program control transfer. This is especially true when the jump looks like an unexpected situation rather than a formal re-routing of the current execution path. This is a scenario where a floating point exception actually works.

Code interleaved is implemented by the following steps: they include extracting two or more programs, then splitting the program's composition statements, and finally compress various statements to integrate them into a single routine. The best way to understand this process is to look at the figure (see figure 1 ). The key to reconnecting separate statements and resetting them to their routines is to use opaque predicates.

A predicate is a condition statement that evaluates whether it is true or false. An opaque predicate is a predicate that knows the result in advance. That is to say, it always returns the same result even if it does not look like it. For example:

(Index * null> 0)

The preceding statement is an opaque predicate that is always false.

 

(Figure 1)

 

An opaque predicate is essentially an unconditional jump that seems to be a conditional jump. This is what we want, because we want to keep our analysts in a state of imbalance and darkness as much as possible.

One way to enhance code interleaved is to call all routines through a central distribution routine. The more functions that are merged together, the better. In extreme cases, you can use an independent distribution routine to merge all the routines in the executable file. This centralized call policy is the basic idea behind Armadillo's nanomite technology.

The distribution routine maintains its own address table. The Address Table returns the address mapped to the specified function. In this way, the scheduler knows the ing Between Routines and callers. When a program is called, the code executing the call passes its return address on the stack. The distribution routine checks the returned address and uses its address table to determine the function to which the program should be re-routed (see figure 2 ). From the Analyst's perspective, no matter what happens, all callers seem to call the same sample program.

 

 

(Figure 2)

 

From http://www.dcscms.com/article/content.php? SEQ = 12