Manual shelling of aspack compression shelling-random base address

Source: Internet
Author: User

First, tools and shell introduction
Second, shelling
1, ESP law shelling
2, single-step tracking shelling
3, address relocation of the repair one, tools and shell introduction
    • Using tools: ollydbg, Peid, Importrec, LOADPE, 010 Editor
    • View pending shelling procedure

    • View section information specific to the Aspack shell

    • Summary: infer from the linker version that the to-be-shelled program should be vs 2013 written
Second, shelling 1, esp law shelling
    • Using the Od loader, find the pushad instruction, judge the program has been packers, here can use ESP law shelling

    • Hardware breakpoints under ESP when stepping over Pushad instructions

    • Let the program run, the place where the program breaks is Popad, after a few steps, you can usually find the original Oep

    • Discover call and JMP combinations after a few steps

    • Find several functions specific to the VS 2013 program after entering call using carriage return, confirming arrival at Oep

    • View the module base address at this time (exe base address)

      Note: This is 11000000(may not be the same each time the system restarts)

    • At the original Oep dump file, use the Od plugin ollydump

      Modify start address to base, ingress address as original OEP address and cancel rebuild input table option

    • After dumping the file, use the Import Table Repair tool (IMPORTREC) to fix the import table

    • Dump file after running shelling program

      The discovery program cannot run, and the import table fix has no problem, that basically can be determined to be a random base address problem

    • Use 010 Editor to locate the feature (40 81) to modify the tag bit of the mechanism, and run the program

2, single-step tracking shelling
    • Aspack the Oep at the end of the shell, there are flower instructions.

    • 1117007 code in the first byte will never execute the instruction, fill it into NOP instruction to remove interference

    • Reload the application to be shelled, when we step into the trace, the function encountered Getmodulehandlea, and we found that the parameter is Kernel32.dll, call this function to obtain the information Kernel32.dll the base address

    • With Kernel32 's base address, you can get any other function of this module, and the next call should be GetProcAddress

    • Continue one-step tracking and find the third function call

    • Here the VirtualAlloc function appears, generally with the decompression decryption code has a certain association, continue to trace

    • Found another call to the VirtualAlloc function, which continues to trace the analysis. Found a function call, view internal calls found very cumbersome, can only analyze the parameters, after analysis found this function great article.

    • Analysis parameters found 4 parameters and we want to find the decompression code function very similar to the application of the memory address, the size of the code snippet (code snippet size of the first look at the value of the size, the second look after the call after the situation, because it has been analyzed before, so the code snippet size is very easy to determine), single step but this function Analysis buffer, found in 190000 is really the extracted code

    • This function does not need to trace inside, continue to step down analysis. Be able to see a piece of code looking for E8 or E9, and then fix the value behind E8 or E9, meaning that the entire code snippet call and JMP will be repaired

    • Observe the repaired value and the fixed value, found that the repaired value is the original code, and the value of the repair is converted, this value appears to cater to the compression algorithm for the conversion, analysis to this, do not need in-depth analysis, summed up, The most valuable of the code we've analyzed so far is the code to understand the pressure and fix the code.

    • After the corrected code loop, continue tracking down, you can find the code to copy the extracted code to the original code snippet.

    • Once the copy is complete, the requested memory is useless, so one-step trace discovers the function that frees the memory

    • Continue one-step tracking and find an upward jump

    • One step at a time this code found that it was in the Loop decompression code, data and other sections

    • Continuing the trace, the code accesses the relocated section, and the analysis finds that the code is being relocated

    • Where there is a line of code to clear the relocation information, it is with this line of code, we shelled, the random base can not be supported, so in the shelling, should be the line of the code to NOP off.
    • After you reposition the code, continue to step through the analysis and discover that there are such a set of calls.

    • This set of operations is only available when the IAT is repaired and continues to be analyzed

    • Found the place to fill the IAT, so far the shell part of the code is basically analyzed, we can look at the code snippet and data segment.
    • Code snippet has been restored

    • The IAT function calls are also restored

    • Then continue to trace, the last is to modify the memory properties of each section, populate the original Oep address, jump to the original Oep

    • The final jump to the original Oep, and then the dump, modify and so on can be done

3. Fixed Address relocation
    • In a single-step trace, we noticed that there was a relocation-related code, and that the existing operation to clear the relocation table

    • We can identify the information of the in-memory relocation table, as long as large tracts of Word data beginning with 3, generally is the base relocation information, the base address RVA is 16000

    • Place a breakpoint at the location where the relocation information is cleared, observe the value of the register and what the register points to

    • You can see that the data in the relocation table is cleared, and you can then make it NOP

    • Then you need to analyze the total size of the base relocation, and after looking at the memory, I find the maximum should be 0xc72

    • To summarize, the RVA of the base relocation table is 16000, the size is 0XC72, the program will be dump out, using LOADPE to modify the base address relocation item in the Data Catalog table

    • Complete the modification, run the test, the program supports the random base address perfectly

Personal Summary: ESP law shelling is very simple, behind the shelling proceduresupport for random base addressesVery important. Attachment:

AsPack.exe

From for notes (Wiz)

Manual shelling of aspack compression shelling-random base address

Related Article

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.