Talking about how to fix the DUMP of the shelled ELF File

Talking about how to fix the DUMP of the shelled ELF File

In the previous article (http://www.bkjia.com/Article/201505/402725.html), I have introduced how to debug the shelled ELF, which is not described here, directly entering the subject, taking a reinforcement as an example, how to DUMP and fix the shelled ELF so that it can debug and load.

Shelling ELF Header and Program Header

Let's take a look at the Header and Program Header of the shelled ELF.

 

 

First, let the debugger stop at X 3860.

When I started my DUMP repair journey, my first DUMP solution continued the idea of PE and failed.

The reason for failure is not wrong, but a problem occurs in details.

The first DUMP method:

1. Abolish the section that does not affect loading (directly enter 0 for the struct). Only the PT_LOAD and PT_DYNAMIC types of sections are concerned.

2. Calculate the maximum value of the DUMP file

align_up(0x28ca4, 0x8000) = 0x31000

3. Change the offset and va values to equal values. The filesize and memsize values are aligned according to align.

4. DUMP the data according to the PT_LOAD section and put the DUMP data into the file.

There should be two pieces of data based on the description.

PT_LOAD : 0 ----align_up(0x12044, 0x8000) = 0 ----- 0x1B000PT_LOAD : align_down(0x28ca4,0x1000) = 0x28000 ---- align_up(0x28ca4, 0x8000) = 0x31000

Because Android is also the Linux kernel, The Memory Page alignment granularity is 4 K (0 × 1000)

After dumping DUMP according to the above method, let's look at the JNI_ONLOAD after IDA Loads

 

Look at the red part. It's strange. Where should I go with the code ?? The address 0x221b0 is invalid, but the code is clearly displayed in the dynamic Debugger:

 

Check the Program Header and check the address 0x221b0. The address is not described in the PT_LOAD section.

Therefore, the failure is in this place. The shell code must contain mmap memory, which stores the decrypted data and modifies the Memory attribute.

By tracking the shell code, we can find that the shell code uses svc 0 to call two functions: mmap and mprotect.

mmap(0x3000, 0x23710, 0x3, 0x32, 0xffffffff, 0x0)

Map page attribute: PROT_READ | PROT_WRITE

mprotect(0x3000, 0x23710, 0x5)

Modify page attributes: PROT_READ | PROT_EXEC

For more information about the parameters, see the help documentation.

Starting address: 0x3000 size: align_up (0x23710, 0x1000) = 0x24000 end address: 0x3000 + 0x24000 = 0x27000

0x221b0 is in the range of 0x3000-0x27000.

Through the above process, resummarize the DUMP method as follows:

1. Abolish the section that does not affect loading (directly enter 0 for the struct). Only the PT_LOAD and PT_DYNAMIC types of sections are concerned.

2. Calculate the maximum value of the DUMP file

align_up(0x28ca4, 0x8000) = 0x31000

3. retain only one PT_LOAD segment, from 0 to 0 × 31000

DUMP the entire data and directly write it to the file. Change align to 0 × 1000 and flag to RWE.

4. Modify the offset of the PT_DYNAMIC section, which is equal to that of VA.

The repaired section table is as follows:

 

Kill the INIT or INIT_ARRAY segments.

The last note is to kill the INIT or INIT_ARRAY segments.

The INIT method is used to locate the data offset described by INIT. The data offset is increased by 8 bytes.

Method for killing INIT_ARRAY: locate to VA and fill the data with 0xffffffff or 0 according to the structure.

Check that the INIT segment does not exist.

 

Let's open IDA and load the repaired file to see the effect:

 

 

Complete data. Let's take a look at the effect of dynamic loading.

 

Loaded successfully ~~~

Haha, now the repair is complete.