Analysis of syscall and shellcode in Linux and FreeBSD

Source: Internet
Author: User
Analysis of syscall and shellcode in Linux and FreeBSD

Created on:
Article attributes: original
Article submission: 7all (sgh81_at_163.com)

= Www.cciss.cn. =
= Bbs.cciss.cn. =

Analysis of syscall and shellcode in Linux and FreeBSD

| = --------------- = [Syscall and shellcode of Linux and FreeBSD] = ------ = |
| = ----------------------------------------------------------------- = |
| = --------------- = [7all <bloodfall_at_msn.com>] = ------------------ = |
| = ----------------------------------------------------------------- = |
| = --------------- = [Copyright: www.cciss.cn] = ----------------------- = |

--] Overview
It was another sleepless night. In fact, this document should not be published because of the confidentiality principle, but I carefully
There are no similar articles on Google, and the documents published won't be considered as top secret materials,
However, I have hidden many problems that may exist at the kernel level. I will simply elaborate on the structure of the assembly code.
Linux and FreeBSD are more fun in the end. Or the running speed will be faster :)
I think after reading this document, you may know that Linux is stable? Or is FreeBSD solid?
In the last part of this article, the shellcode problem is added, but it is not specifically discussed.
Note: This point of view only represents my personal point of view. If there is anything wrong, you are welcome to correct it :) to improve your level.

--] Compilation and debugging
A: compilation options
Linux: gcc-gdwarf-2 ***. C-o ***
FreeBSD: CC-gdwarf-2 ***. C-o ***
For convenience of debugging, I used the above options.
--------------------------------------
The compilation options for writing shellcode are:
Linux: gcc-static-O ******. c
FreeBSD: CC-static-O ******. c
B: debugging tools
The debugging tool for Linux/Unix is GDB, but the kernel-based debugging of GDB is insufficient, because the debugging of GDB is
Based on the user mode ).
I have used other debugging tools here, so the debugging code we see below is quite special, which is stated in advance here.

--] Linux syscall tracking
Anyone who has written shellcode knows that syscall is a necessity for shellcode writing. :) of course, this concept is only applicable to Linux/Unix.
It only exists under the OS. Recently, because of a "small problem", the kernel level of Linux kernel and FreeBSD has been
Tracking and debugging, and then discovering a very interesting problem, I feel that this problem may be different from the Linux shellcode and
The shellcode differences under FreeBSD are also slightly related to the system architecture. The following content is
The following is a compilation of syscall code.
In Linux, the application uses the following code to call syscall:
420d4330 55 push EBP |
420d4331 89e5 mov EBP, esp |-> stack framework
420d4333 83ec18 sub ESP, 00000018 |
420d4336 897dfc mov dword ptr [EBP]-04, EDI |
420d4339 8b4d0c mov ECx, dword ptr [EBP] + 0C |
420d433c 8b7d08 mov EDI, dword ptr [EBP] + 08 |-> syscall Parameter
420d433f 8975f8 mov dword ptr [EBP]-08, ESI |
420d4342 8b5510 mov edX, dword ptr [EBP] + 10 |
420d4345 895df4 mov dword ptr [EBP]-0C, EBX
420d4348 e81014f4ff call near32 PTR 4201575d
420d434d 81c3835f0500 add EBX, 00055f83
420d4353 8d77ff Lea ESI, dword ptr [EDI]-01
420d4356 83fe02 cmp esi, 00000002
420d4359 8d75f0 Lea ESI, dword ptr [EBP]-10
420d435c 0f477514 cmova ESI, dword ptr [EBP] + 14
420d4360 53 push EBX
420d4361 89fb mov EBX, EDI
420d4363 b81a000000 mov eax, 0000001c // system call number value
420d4368 CD80 int 80 // call 0x80
420d436a 5B pop EBX
420d436b 3d00f0ffff CMP eax, fffff000
420d4370 89c6 mov ESI, eax
420d4372 760e jbe short PTR 420d4382
420d4374 f7de neg ESI
420d4376 e8c912f4ff call near32 PTR 42015644
420d437b 8930 mov dword ptr [eax], ESI
420d437d beffffffff mov ESI, ffffffff
420d4382 85f6 test ESI, ESI
420d4384 782a JS short PTR 420d43b0
420d4386 85ff test EDI, EDI
420d4388 7426 je short PTR 420d43b0
420d438a 83ff03 cmp edi, 00000003
420d438d 7721 ja short PTR 420d43b0
420d438f e8b012f4ff call near32 PTR 42015644
420d4394 c70000000000 mov dword ptr [eax], 00000000
420d439a 8b45f0 mov eax, dword ptr [EBP]-10
420d439d 8b5df4 mov EBX, dword ptr [EBP]-0c
420d43a0 8b75f8 mov ESI, dword ptr [EBP]-08
420d43a3 8b7dfc mov EDI, dword ptr [EBP]-04
420d43a6 89ec mov ESP, EBP
420d43a8 5d pop EBP
420d43a9 C3 retn
---------------------------------------------------------------------
For simple analysis, let's look at the code here:
420d4330 55 push EBP |
420d4331 89e5 mov EBP, esp |-> stack framework
420d4333 83ec18 sub ESP, 00000018 |
420d4336 897dfc mov dword ptr [EBP]-04, EDI |
420d4339 8b4d0c mov ECx, dword ptr [EBP] + 0C |
420d433c 8b7d08 mov EDI, dword ptr [EBP] + 08 |-> syscall Parameter
420d433f 8975f8 mov dword ptr [EBP]-08, ESI |
420d4342 8b5510 mov edX, dword ptr [EBP] + 10 |
420d4345 895df4 mov dword ptr [EBP]-0C, EBX
420d4348 e81014f4ff call near32 PTR 4201575d
420d434d 81c3835f0500 add EBX, 00055f83
420d4353 8d77ff Lea ESI, dword ptr [EDI]-01
420d4356 83fe02 cmp esi, 00000002
420d4359 8d75f0 Lea ESI, dword ptr [EBP]-10
420d435c 0f477514 cmova ESI, dword ptr [EBP] + 14
420d4360 53 push EBX
420d4361 89fb mov EBX, EDI
420d4363 b81a000000 mov eax, 0000001c // system call number value
420d4368 CD80 int 80 // call 0x80
----------------------------------------------------------------------
Of course, from the above code, we can only see that Linux calls a syscall assembly code process at a deeper level.
Said, the above Code may be nonsense :) OK, let's continue to read the following content.

--] FreeBSD's syscall
In the syscall under FreeBSD, I performed two follow-up operations to enter the internal directory, so the following two procedures are used to demonstrate
Code, but the following code shows that FreeBSD is much shorter :)
Trace into one step:
28080d98: 31c0 XOR eax, eax
28080d9a: 53 push EBX
28080d9b: e800000000 call near32 PTR 28080da0
-------------------------------------------------------------------
Trace into two step:
28080da0: 5B pop EBX
28080da1: 81c3ac980600 add EBX, 000698ac
28080da7: 8b934c0a0000 mov edX, dword ptr [EBX] + 00000a4c
28080dad: 8902 mov dword ptr [edX], eax
28080daf: 5B pop EBX
28080db0: 8d051a000000 Lea eax, dword ptr [0000001c] // system call number value
28080db6: CD80 int 80
28080db8: 7201 JC short PTR 28080dbb
28080dba: C3 retn
--------------------------------------------------------------------
From the code above, the syscall code of FreeBSD is much shorter than that of Linux, but it is not short enough.
Before this document, you are familiar with the cracking technology or overflow technology or Intel assembly language. I think you may feel like this: FreeBSD calls
Syscall is much safer than Linux. Why? Please go back and carefully check the above Linux/FreeBSD sink
Code compilation: Below we will also give a rough argument, but it's just a guess :)

--] Is FreeBSD safer than Linux?
Anyone who has learned the cracking technology knows that some jump commands can be used to crack the software.
Simple software is useful. I suddenly found that the above sentence is nonsense, and it has nothing to do with this article. It seems that I installed it in my head.
Things are not a good thing :(
Let's make a general analysis on why BSD is safer than Linux! See the following code:
Syscall in Linux:
420d4336 897dfc mov dword ptr [EBP]-04, EDI |
420d4339 8b4d0c mov ECx, dword ptr [EBP] + 0C |
420d433c 8b7d08 mov EDI, dword ptr [EBP] + 08 |-> syscall Parameter
420d433f 8975f8 mov dword ptr [EBP]-08, ESI |
420d4342 8b5510 mov edX, dword ptr [EBP] + 10 |
-----------------------------------------------------------------------------
420d435c 0f477514 cmova ESI, dword ptr [EBP] + 14 |
420d4360 53 push EBX |-> syscall Parameter
420d4361 89fb mov EBX, EDI |
420d4363 b81a000000 mov eax, 0000001c // system call number value
420d4368 CD80 int 80 // call 0x80
-----------------------------------------------------------------------------
From the code above, we can see this situation. Here we assume that the system function write is called to write the output :)
Write (filehandle, Buf, buf_length)
The function call of the assembly code is basically as follows:
Push buf_length
Push Buf
Push filehandle
Call write
After entering the write function, we will know a complete process of Linux syscall as follows:
Calls system functions in advanced languages |
-> Jump syscall (System ID for system functions) |
-> Assign the syscall parameter to the Register |
-> Mov eax, 0x ** (and the value of the preceding write function for syscall) |
-> Int 0x80 |
-> Return |
The basic process is shown above. What if we use spoof (spoofing) to pass the parameter registers? Assuming that spoof is successful,
It is easy to pass some bad variable values to the syscall system call, and then the system kernel may receive some
Improper handling of bad information leads to system exceptions or system overflow. Of course, these are just guesses.
I guess most of the content. As for the answer, there may never be any ...:)
//////////////////////////////////////// //////////////////////////////////////// //////
Syscall call of FreeBSD:
28080d98: 31c0 XOR eax, eax
28080d9a: 53 push EBX
28080d9b: e800000000 call near32 PTR 28080da0
28080da0: 5B pop EBX
28080da1: 81c3ac980600 add EBX, 000698ac
28080da7: 8b934c0a0000 mov edX, dword ptr [EBX] + 00000a4c
28080dad: 8902 mov dword ptr [edX], eax
28080daf: 5B pop EBX
28080db0: 8d051a000000 Lea eax, dword ptr [0000001c] // system call number value
28080db6: CD80 int 80
28080db8: 7201 JC short PTR 28080dbb
28080dba: C3 retn
From the above code, we can also see this situation. Here we assume that the system function write is called to write the output :)
Write (filehandle, Buf, buf_length)
The function call of the assembly code is basically as follows:
Push buf_length
Push Buf
Push filehandle
Call write
After entering the write function, we will know a complete process of Linux syscall as follows:
Calls system functions in advanced languages |
-> Jump syscall (System ID for system functions) |
-> Mov eax, 0x ** (and the value of the preceding write function for syscall) |
-> Int 0x80 |
-> Return |
According to my tracking analysis, we found that FreeBSD uses the parameter variables in the program. In this case, FreeBSD saves a register call.
The spoof register may be disabled in the Process of function parameters. From this point of view, FreeBSD is indeed much safer than Linux.
Bytes ------------------------------------------------------------------------------------------------
Although the syscall in Linux will call registers to save the parameter values, it may be advantageous (at least I feel that when I look at the code and analyze some kernels,
A lot more comfortable :), but if some high people can use the spoof register, it may cause some trouble. Of course, such trouble also needs to be specific.
Program hook, not to say spoof is successful for spoof :)
FreeBSD is a lot better, and I have to admire the advantages of FreeBSD. At the beginning, I was often overwhelmed by calling methods like FreeBSD.
But I got used to it. In the past, it was Linux for a while and BSD for a while; only recently
I found this interesting question only when I was missing it :)

--] Is FreeBSD programs faster than Linux programs?
This problem is hard to say. If we look at the above Code, there will be so much less assembly code. It is said that FreeBSD is slower than Linux and no one will believe it.
Of course, I have not conducted a more in-depth comparison and analysis on FreeBSD's system architecture and Linux system architecture, so I am not afraid to end with such an unclear conclusion.
Theory: If someone is interested, can I test the two operating systems on the same hardware platform?
Another problem is that FreeBSD has less assembly code than Linux, but the syscall parameter FreeBSD must also be obtained.
The obtained method is more direct than that in Linux :)

--] FreeBSD and Linux shellcode
Let's take a look at FreeBSD. If we talk about syscall, if we don't talk about the story of shellcode, it seems that something is missing... so.
I have written some simple shellcode with Linux shellcode. I have seen that many Chinese tutorials on shellcode on the Internet are continuously debugged by GDB.
Come on, I feel so troublesome: (I personally think that since I am familiar with GDB debugging technology, I must be familiar with compilation and syscall. I am not familiar with looking for the header file.
So I have been using assembly to write these cute shellcode. I just learned how to use it for a few days. What's wrong :)
Is FreeBSD's shellcode first, or Linux first? I took a coin and threw it down. As for why I threw a coin... sleepy... find something to stimulate myself.
Neural method :)). Well, the coin is finished. Let's talk about FreeBSD's.
Compile: NASM-F elf ***. ASM
LD-S-O ******. o
A: Shellcode (hello. ASM) under FreeBSD ):
Section. Text
Global _ start
_ Start:
XOR eax, eax
CDQ
Push 0x0a216472
Push 0x6f57206f
Push 0x6c6c6548
MoV EBX, ESP
Push byte 0xc
Push EBX
Push byte 0x1
Push eax
MoV Al, 0x4
Int 0x80
XOR eax, eax
Push eax
MoV Al, 0x1
Int 0x80
Bytes ------------------------------------------------------------------------------------------------
The assembly code above can be directly compiled to obtain the shellcode. Compile the code according to the preceding compilation method, and then:
Objdump-d hello> hello.txt
Copy the obtained machine code to the shellcode under FreeBSD.
B: Shellcode (hello. ASM) in Linux ):
Global _ start
_ Start:
XOR eax, eax
JMP short string
Code:
Pop ESI
Push byte 15
Push ESI
Push byte 1
Push eax
Int 0x80
XOR eax, eax
Push eax
Push eax
MoV Al, 1
Int 0x80
String:
Call Code
DB "Hello word! ", 0x0a
Bytes ------------------------------------------------------------------------------------------------
The assembly code above can be directly compiled to obtain the shellcode. Compile the code according to the preceding compilation method, and then:
Objdump-d hello> hello.txt
Copy the obtained machine code to a shellcode in Linux.
C: Why is FreeBSD different from shellcode in Linux?
I would like to leave this question for you to think about first, and then look at the following content. If you still don't know what I 've been reading, then it's possible.
You won't compile programming on UNIX at all... another case is that you are too stupid :(
C-1: Linux syscall system call is the following process:
Calls system functions in advanced languages |
-> Jump syscall (System ID for system functions) |
-> Assign the syscall parameter to the Register |
-> Mov eax, 0x ** (and the value of the preceding write function for syscall) |
-> Int 0x80 |
-> Return |
So, our shellcode is more casual when pushing the parameter, because the system-level syscall at the end has second parameters.
Assign values to each register before calling syscall.
C-2: FreeBSD's syscall system call is the following process:
Calls system functions in advanced languages |
-> Jump syscall (System ID for system functions) |
-> Mov eax, 0x ** (and the value of the preceding write function for syscall) |
-> Int 0x80 |
No, or remember the previous content? FreeBSD's syscall call is pushed before the system enters syscall, so our
Shellcode must push the parameter values first, instead of being as casual as Linux.

--] Summary
In fact, the last part of the difference about shellcode, if you really want to write it, it is estimated that there will be a whole article, but... people are iron rice, steel, and don't eat a meal.
Ele. me panic. as a result, I was prepared to escape the army. I had to fill my stomach first and then have a good night's sleep. by the way, in my dream, my "boss" started to bully me again...

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.