Shulou(Shulou.com)06/01 Report--

Using the method of adding section in pe to add code to realize simple shell.

The general process is as follows

The goal to achieve is to add a new section and add your own code in the new section to let the program run its own code first.

And their own code is to unlock the previous encryption of the program and then continue to run the route of the original program.

Detailed steps

The first step

The first program will use the method of file mapping to load the exe to be modified to get all the information we need.

CreateFile CreateFileMapping MapViewOfFile (returns the file base address Pp_w_picpath)

GetFileSize (used to modify file size)

Step two

Initialize the peheader information DOS=PIMAGE_DOS_HEADER (Pp_w_picpath); other initializations

Verify the validity of pe MZ and PE

Step three

Start to add the section because the content of the section where eop is located will be modified later.

So first set the property of this section to readable and writable IMAGE_SCN_MEM_READ | IMAGE_SCN_MEM_WRITE

(it is very important to modify your own things. Fei Qiu has been unable to run the card for a long time after the modification. Remember)

Add knots

one

Find the address of the last section

PIMAGE_SECTION_HEADER lastsec = SECTION+ (FILE- > NumberOfSections-1)

Determine the address of the new section

PIMAGE_SECTION_HEADER newsec = lastsec+1

Add 1 to the number of section tables

FILE- > NumberOfSections++

Verify that there are 40 bytes from the end of the section header to the beginning of the first section.

(there are generally cases where there is not enough consideration.)

Verification method (mainly understand the true meaning of SizeOfHeaders)

NEWSIZE calculates (dos + dos stub) + nt + the total size of the newly added section header (the pure size is not aligned)

DWORD NEWSIZE = (DOS- > e_lfanew) + sizeof (IMAGE_OPTIONAL_HEADER32) + sizeof (IMAGE_SECTION_HEADER) * NumberOfSections

(don't forget that dos stub directly uses (sizeof (IMAGE_DOS_HEADER) although there is no influence, the facts must be calculated in this way.

Compare it with the original SizeOfHeaders

SizeOfHeaders is the total size of all dos+dos stub+nt+ section headers (aligned) that can be used as the starting position of the first section content

two

Initialize all attributes of the Singapore section after the size is satisfied (the UP function is the parameter 1 size 2 alignment granularity used for alignment)

Memcpy (newsec- > Name, ".NewSec", 8)

Newsec- > Misc.VirtualSize= actual size (size); the actual size of the section content SizeOfRawData uses

Newsec- > SizeOfRawData=Up (size,pe.OPTION- > FileAlignment); size in the file

The important RVA of newsec- > VirtualAddress in memory can be obtained by using the data in the previous section.

DWORD last = Up ((lastsec- > SizeOfRawData), pe.OPTION- > SectionAlignment) + lastsec- > VirtualAddress

DWORD last = Up ((LastSec- > Misc.VirtualSize), pe.OPTION- > SectionAlignment) + lastsec- > VirtualAddress

The two last are equal because the SizeOfRawData is Misc.VirtualSize aligned by file.

File alignment granularity 512 memory alignment granularity 4096, so it must be equal

But in order to use the latter accurately

In fact, this last is the total size SizeOfImage after the pe file is loaded into memory and aligned with SectionAlignment.

Newsec- > PointerToRawData=lastsec- > PointerToRawData+lastsec- > SizeOfRawData;

Newsec- > Characteristics=IMAGE_SCN_MEM_READ | IMAGE_SCN_MEM_WRITE; is readable and writable

The other properties have no effect, so they are all set to 0 until initialization is complete.

three

Parameters in other places that need to be modified

A (must) the total size of the file on disk is the value returned by GetFileSize in the first step plus 4096 of the page size

For CreateFileMapping to create file mapping object function, set the size to the modified size, that is, add the value after 4096

B (required) the total size of the file mapped to memory

OPTION- > SizeOfImage+=Up (size,pe.OPTION- > SectionAlignment)

C (unnecessary)

Pe.DATA[IMAGE _ DIRECTORY_ENTRY_BOUND_IMPORT]. Size=0

Pe.DATA[IMAGE _ DIRECTORY_ENTRY_BOUND_IMPORT]. VirtualAddress=0

Pe.OPTION- > SizeOfCode+=Up (size,pe.OPTION- > SectionAlignment)

Pe.OPTION- > SizeOfInitializedData+=Up (size,pe.OPTION- > SectionAlignment)

4. So far, the festival has been successful.

The fourth step

Take reverse

Because it is to reverse the content of the section where the eop is located, it is necessary to find the section where the eop is located.

Method to get eop= OPTION- > AddressOfEntryPoint, and then loop through the starting address of each section header to compare

For (int iTuno; iNumberOfSections; iTunes +)

{

PIMAGE_SECTION_HEADER sec = PIMAGE_SECTION_HEADER (SECTION+i)

If (eop > = sec- > VirtualAddress & & eopVirtualAddress+sec- > SizeOfRawData))

{return sec;}

}

After finding the section, you want to modify the contents of this section on disk, so get the

PVOID address = sec- > address of the PointerToRawData+p_w_picpath; / / file

DWORD lenth = sec- > size of the SizeOfRawData; / / file

Inverse function

Void _ stdcall QF (PVOID address,DWORD len)

{

DWORD iTunes 0

PBYTE buf= (PBYTE) address

For (iTuno; iVirtualAddress) + p_w_picpath)

Then copy the machine code of the parameters into the stack to form a structure and directly send the machine code to the Singapore section.

2 the copy parameter from right to left is the length of the first copy section length

Initialize the structure made by yourself first.

MOV_EBX.address=secofeop- > length of the section in which SizeOfRawData; / / resides

MOV_EAX.address=secofeop- > VirtualAddress+pe.OPTION- > ImageBase; / / the starting address of the section va+400000

PUSH_OLD_EOP.address=pe.OPTION- > AddressOfEntryPoint+pe.OPTION- > ImageBase; / / original eop+400000

And then in the content of copy to Singapore Festival

Memcpy (begin,&MOV_EBX,sizeof (mov_eax)); / / length of the section in which it resides

Memcpy (begin+sizeof (mov_eax), & MOV_EAX,sizeof (mov_eax)); / / the starting address of the section va+400000

Memcpy (begin+sizeof (mov_eax) * 2) eop+400000 (push_old_eop))

DWORD lenofcode= (DWORD) end_qf- (DWORD) start_qf

/ where start_qf and end_qf are the first and last addresses of the inverse function to calculate the length of the code. Note that a few bytes after the last address have to be added (important).

/ / the two values were found manually when I wrote the program and debugged the program. I don't know how to dynamically get the instructions to be seen by Daniel.

/ / calculate the length of memory required by the code, plus the length of at least the returned instructions, which is 2.

/ / if it's too much, it's okay to automatically fill it with CC.

Memcpy (begin+sizeof (mov_eax) * 2+sizeof (push_old_eop), (PVOID) start_qf,lenofcode+2); / /

The important step is to change the eop entry point address to the newly added rva.

OPTION- > AddressOfEntryPoint=newsec- > VirtualAddress; / / modify the entry point address to the rva of Singapore section

At this time, the decryption is over.

Step six

Wrap-up work

First of all, learn a little bit of knowledge on the Internet.

In order to improve speed, the system caches the data pages of the file and does not immediately update the disk image of the file when operating on the mapped view of the file. If you need to ensure that your updates are written to disk, you can force the system to rewrite some or all of the modified data to the disk image by calling the F l u s h Vi e w O f F i l e function:

BOOL FlushViewOfFile (

PVOID pvAddress

SIZE_T dwNumberOfBytesToFlush)

The first parameter is the one-byte address of the view contained in the memory-mapped file. This function circles the address you pass here into a page boundary value. The second parameter indicates the number of bytes you want to refresh. The system will round this number up so that the total number of bytes is the integer of the page.

1 "do not update the disk image of the file immediately when you operate on the mapping view of the file" so when will it be updated? My program will be updated before exiting normally, right? If the program ends unexpectedly (such as a computer crash), is it possible that the changes cannot be written to disk?

1. Write to disk when UnmapViewOfFile, CloseHandle, and system reclaim physical memory.

When the process ends (both normal and abnormal), the system automatically closes all Handle opened by the process, so it is written to disk. Unless the kernel code is abnormal, causing the panic, it is possible that it is not written at this time.

2 is it not necessary for us to use FlushViewOfFile as long as the program does not end unexpectedly? Otherwise, under what circumstances is it necessary to use it?

2. FlushViewOfFile is provided to realize the program's own control of writing to disk, and you will realize its value only when you really encounter this need.

The code implemented by this program is as follows

BOOL success = FlushViewOfFile (Pp_w_picpath,FileSize); / / flushes all data written to the file mapping buffer to disk

If (! success)

{return false;}

Success = UnmapViewOfFile (Pp_w_picpath); / / Unmap a file-mapped object in the current application's memory address space

/ / lpBaseAddress Long, which specifies the base address of a file to be unmapped. This address was obtained earlier with the MapViewOfFile function

CloseHandle (hMap)

Return true

It's over.

The program architecture is mainly Jango's way of thinking, and I slowly digested a lot of problems, but there are also some new problems and solutions that I have discovered.

At the same time, I would also like to thank Lao Niu for his tireless Chunchun teaching and supervision that have helped me solve a lot of problems.

Feeling that a team is good.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.