- #REAL EROGAME SITUATION SUB ESP FULL#
- #REAL EROGAME SITUATION SUB ESP SOFTWARE#
- #REAL EROGAME SITUATION SUB ESP CODE#
In other words it is the exact opposite of inlining.
#REAL EROGAME SITUATION SUB ESP CODE#
Outlining means that you take a certain code sequence that belongs in one function and create a new function that contains just that sequence. One interesting enhancement suggested in is to combine inlining with outlining in order to create a highly potent transformation. Reversers have no information on which parts of a certain function are actually just inlined functions that might be called from numerous places throughout the program.
#REAL EROGAME SITUATION SUB ESP SOFTWARE#
In the context of obfuscating transformations, inlining is a powerful tool because it eliminates the internal abstractions created by the software developer. This improves runtime performance because the overhead of calling a function is completely eliminated, at the cost of significantly bloating the size of the program (because functions are duplicated). Instead of having all callers call into a single copy of the function, the compiler replaces every call into the function with an actual in-place copy of it. Inlining is a well-known compiler optimization technique where functions are duplicated to any place in the program that calls them. In this particular situation, I think I would stick to the array-based approach from Listing 10.4-the OBFUSCATE macros wouldn’t be worth the huge performance penalty they incur. Remember that there’s usually no reason to obfuscate the entire program, only the parts that are particularly sensitive or important. Scattering 11 copies of the OBFUSCATE macro increased this number to about 12, which means that the heavily obfuscated version runs about 12 times slower than its unobfuscated counterpart! Whether this kind of extreme obfuscation is worth it depends on how concerned you are about your program being reversed, and how concerned you are with the runtime performance of the particular function being obfuscated. In a brief performance comparison I conducted, I measured a huge runtime difference between the original function and the function from Listing 10.4: The obfuscated function from Listing 10.4 was about 3.8 times slower than the original unobfuscated function in Listing 10.2. It would be borderline impossible for an automated deobfuscator to predict in advance the state of the array, and without knowing the exact contents of the array it would not be possible to properly analyze the code. In this case, the idea is to create several pointers that point to the array of indexes and have to write to several locations within at several stages. Aliases significantly complicate any kind of data-flow analysis processīecause the analyzer must determine how memory modifications performed through one pointer would affect the data accessed using other pointers that point to the same memory location. Pointer aliases are simply multiple pointers that point to the same memory location. The approach chosen in that study is to use pointer aliases as a means of confusing automated deobfuscators. The original implementation in is more focused on preventing static analysis of the code by deobfuscators. This enhancement makes this function significantly more unreadable to human reversers, and would also seriously complicate matters for a deobfuscator because it would require some serious data-flow analysis to determine the current value of the index to the array. This table contains the actual jump table indexes, and the index into that table is handled by the program in order to obtain the correct flow of the code. Instead of using direct indexes into the jump table, this implementation uses an additional table that is filled in runtime. The function in Listing 10.4 is an enhanced version of the function from Listing 10.3. Listing 10.4 The data-processing function from Listing 10.2 transformed using an arraybased version of the table interpretation obfuscation method. Other than the confusion macros, another powerful enhancement for the obfuscation of the preceding function would be to add an additional lookup table, as is demonstrated in Listing 10.4.
#REAL EROGAME SITUATION SUB ESP FULL#
Reversing a table interpretation function such as the one in Listing 10.3 without having a full view of the entire function is undoubtedly an unpleasant reversing task. That’s because these macros would prevent reversers from being able to generate a full listing of the obfuscated at any given moment. If made reasonably polymorphic, such macros would not be trivial to remove, and would really complicate the reversing process for this kind of a function. In a native code environment such as IA-32 assembly language, it might be beneficial to add some kind of disassembler-confusion macros such as the ones described earlier in this chapter. This transformation can be improved upon in several different ways, depending on how much performance and code size you’re willing to give up.
0 kommentar(er)
