PWN! PWN! PANG! Part1

Foreword

Here are the PGR’s basic PWN learning notes, mainly studying the exploitation of vulnerabilities in ELF executable files under Linux

The content involves:

• Stack vulnerability exploitation, mainly stack overflow attacks

PS: Speaking of Stack Overflow, we must mention a famous IT forum of the same name abroad (it’s extremely, extremely, extremely useful)

Important things must be said three times XD

https://stackoverflow.com/

• Format String vulnerabilities in the C language Printf() function

• A little bit of heap exploitation

What is PWN?

PWN originally meant the “bang” sound when a hacker broke into a system. Here, we interpret it as binary vulnerability mining and exploitation

To explain step by step = = It can be summarized as the following points:

• Crack and exploit successfully (binary vulnerabilities of the program)

• Break into (devices, servers)

• Control (devices, servers)

ELF Files Under Linux

ELF files are executable files under Linux, they’re different from exe files under Windows

You can use the File command to check your file format:

However, there is an interesting point here. Since the File command judges the file type based on the file header, the file suffix does not affect its judgment of the file as an ELF file (even if a.out has been changed to a.zip)

However, if you double-click this .zip in the folder window, you will find that: this ELF file has been opened as a compressed file (this seems very similar to Windows)

It can be seen that in the process of changing the suffix, it has interfered with the system’s recognition of the file opening method = =

Structure of ELF Files

Seems we went off-topic = =

Now let’s take another look at this executable file “a.out”

We just accidentally opened it as a compressed file (as shown above)

We see a bunch of strange files:

• .got

• .got.plt

• .plt

• .text

• …

These files actually represent the various “sections” of this ELF file on the disk

And when the ELF is mapped into memory, there are “segments”

Segments and Sections

Here, let’s talk in detail about segments and sections

(Well = =, because I personally feel this knowledge has a big impact on later learning)

Here’s an important diagram:

From this diagram, we can see that the .data, .bss, and .got.plt sections are all mapped to the Data Segment

While .rodata, .text, .init, ELF Header are mapped to the Code Segment

Why?

• The first three sections (too lazy to write in detail) have a common feature: readable and writable. Because user data is saved here, it obviously can’t be non-writable = = . Obviously, you also can’t let it be executable, otherwise users can write any data and execute it (never trust user input is safe)

• The latter four sections are code parts, which are often little programs of their own, so they are readable and executable, but not writable = =

• Lastly, >__<, here’s another diagram;)

  

Organization of Program Data in Memory

Straight to the diagram()

Let’s assume everyone has a bit of C foundation here

Not going off-topic anymore

A few points to note here

• The stack grows downward from high to low address

• The heap grows from low to high address

• Data is written from low to high address

• BSS stores global variables

• The stack stores local variables

Assembly Alert!

For assembly, you only need to know the most basic instructions = =

Since we’ve written so much = =

Let’s continue…

Some Common Assembly Instructions

Usage

MOV DEST(ADDRESS), SRC(VALUE)  ; Transfer the source operand to the destination (similar to an assignment statement)
LEA REG, SRC                   ; Send the effective address of the source operand to the specified register (save SRC's address into…)
PUSH VALUE                     ; Push the target value onto the stack, while decreasing the SP pointer by 1 word length
POP DEST                       ; Pop the value from the top of the stack to the destination storage position, while increasing the SP pointer by 1 word length
LEAVE                          ; Instruction to restore the parent function's stack frame when returning from a function (destroy the child function's stack frame after the child function call ends)
RET                            ; Instruction to control the program execution flow to return to the parent function when returning from a function

Reference

translations by GPT-4