Calculating Offset

This tutorial is more of a tip than a tutorial. It just explains how to calculate offsets for jumps and calls within the program you are patching.

Types of Jumps/Calls

Here I will just describe the different types of jumps and calls which you will come across:

Short Jumps
Short jumps be they conditional or unconditional jumps are 2 bytes long (or 1 nibble if your Californian ;-). These are relative jumps taken from the first byte after the two bytes of the jump. Using short jumps you can jump a maximum of 127 bytes forward and 128 bytes backwards.

Long Jumps
Long jumps if they are relative are 6 bytes long for conditional jumps and are 5 bytes long for unconditional jumps. For conditional jumps 2 bytes are used to identify that it is a long jump and what type of jump (je, jg, jns etc) it is. The other 4 bytes are used to show how far away the target location is relative to the first byte after the jump. In an unconditional jump only 1 byte is used to identify it as a long unconditional jump and the other 4 are used to show it's target's relative position, as with the conditional jumps.

Calls
There are two different types of calls which we will use. The normal type of call works the same as the long jumps in that it is relative to it's current position. The other type gives a reference to a memory location, register or stack position which holds the memory location it will call. The position held by the later is direct e.g. the memory location referenced may contain 401036h which would be the exact position that you would call, not relative to the position of the call. The size of these types of calls depends on any calculations involved in the call i.e. you could do: 'call dword ptr [eax * edx + 2]'. Long jumps can also be made using this method, but I didn't say that earlier as to avoid repetition.

Tables
Here is a brief list of all the different types of jumps/calls and their appropriate op-codes. Where different jumps have the same Op-Codes I have grouped them:

Jump Description Short Op-Code Long Op-Code
call procedure call E8xxxxxxxx N/A
jmp u nconditional jump EBxx E9xxxxxxxx
ja/jnbe jump if above 77xx 0F87xxxxxxxx
jae/jnb/jnc jump if above or equal 73xx 0F83xxxxxxxx
jb/jc/jnae jump if below 72xx 0F82xxxxxxxx
jbe/jna jump if below or equal 76xx 0F86xxxxxxxx
jcxz/jecxz jump if cx/ecx equals zero E3xx N/A
je/jz jump if equal/zero 74xx 0F84xxxxxxxx
jne/jnz jump if not equal/zero 75xx 0F85xxxxxxxx
jg/jnle jump if greater 7Fxx 0F8Fxxxxxxxx
jge/jnl jump if greater or equal 7Dxx 0F8Dxxxxxxxx
jl/jnge jump if less 7Cxx 0F8Cxxxxxxxx
jle/jng jump if less or equal 7Exx 0F8Exxxxxxxx
jno jump if not overflow 71xx 0F81xxxxxxxx
jnp/jpo jump if no parity/parity odd 7Bxx 0F8Bxxxxxxxx
jns jump if not signed 79xx 0F89xxxxxxxx
jo jump if overflow 70xx 0F80xxxxxxxx
jp/jpe jump if parity/parity even 7Axx 0F8Axxxxxxxx
js jump if sign 78xx 0F88xxxxxxxx



Calculating Offsets (finding in the xx's in table)

You will need to be able to calculate offsets when you add jumps and make calls within and to the code you have added. If you choose to do this by hand instead of using a tool then here are the basics:

For jumps and calls further on in memory from your current position you take the address where you want to jump/call and subtract from it the memory location of the next instruction after your call/jump i.e.:

(target mem address) - (mem location of next instruction after call/jump)

Example
If we wanted to jump to 4020d0 and the next instruction *after* the jump is at location 401093 then we would use the following calculation:

4020d0 - 401093 = 103d

We then write the jump instruction in hex as e93d100000 where e9 is the hex op-code for a long relative jump and 3d100000 is the result of our calculation expanded to dword size and reversed.

For jumps and calls to locations *before* the current location in memory you take the address you want to call/jump to and subtract it from the memory location of the next instruction after your call/jump, then subtract 1 and finally perform a logical NOT on the result i.e.

NOT(mem address of next instruction - target mem address - 1)

Example
If we wanted to call location 401184 and the address of the next instruction after the call is 402190 then we do the following calculation:

NOT(402190 - 401184 - 1 ) = ffffeff4

We can then write our call instruction in hex as e8f4efffff where e8 is the hex op-code for relative call and f4efffff is the result of the calculation in reverse order.

If you want to practice with different examples then the best way to do this is to use a disassembler like WDASM which shows you the op-codes and try and work out the results yourself. Also as an end note you don't have to perform these calculations if you have enough room to make your jump or call instruction into an absolute jump call by doing the following as represented in assembler:

mov eax, 4020d0
call eax (or jmp eax)

Final Notes

Make life easier and use a program to do this ;-)

Secure Computer: Copy XBOX Games

Copy XBOX Games

Copy XBOX Games

 BURNING X-BOX & GAMECUBE GAMES USEING CDRWIN

 

1) Insert your original in your CD-ROM.
2) Open CDRWin (or any other image extractor) to make an iso image of the game
on your hard disc. Click on 'Extract Disc/Tracks/Sectors'
3) Here are the settings which work for me (!):
Disc Image/Cue sheet
File-Format: Automatic
Reading-Options:
RAW, CD+G, CD-TEXT and MCN/USRC all Unchecked
Error Recovery: Ignore
Jitter Correction: Auto
Subcode Analyses: Fixed
Data-Speed: MAX
Read Retry Count: 10
Audio Speed: MAX
Subcode Threshold: 900
There are a lot of reports, that Raw reading also works, but I had problems with it enabled.
4) Click on 'Start'

RECORDING TO A DISC

1) Install Fireburner

 

2) Double click on the Cue File For The Game
3) Right Click And select burn To CD
That?s all there is record DAO, and you can try to burn it fast at 2X
Using PNY Black Diamond CDR'

Secure Computer: Shellcoding Techniques

Secure Computer: Shellcoding Techniques

Shellcoding Techniques

  Introduction

This paper assumes a working knowledge of basic shellcoding techniques, and x86 assembly, I will not rehash these in this paper.  I hope to teach you some of the lesser known shellcoding techniques that I have picked up, which will allow you to write smaller and better shellcodes.  I do not claim to have invented any of these techniques, except for the one that uses the div instruction.



The multiplicity of mul

This technique was originally developed by Sorbo of darkircop.net.  The mul instruction may, on the surface, seem mundane, and it's purpose obvious.  However, when faced with the difficult challenge of shrinking your shellcode, it proves to be quite useful.  First some background information on the mul instruction itself.

mul performs an unsigned multiply of two integers.  It takes only one operand, the other is implicitly specified by the %eax register.  So, a  common mul instruction might look something like this:

movl $0x0a,%eax
mul $0x0a

This would multiply the value stored in %eax by the operand of mul, which in this case would be 10*10.  The result is then implicitly stored in EDX:EAX.  The result is stored over a span of two registers because it has the potential to be considerably larger than the previous value, possibly exceeding the capacity of a single register(this is also how floating points are stored in some cases, as an interesting sidenote).

So, now comes the ever-important question.  How can we use these attributes to our advantage when writing shellcode?  Well, let's think for a second, the instruction takes only one operand, therefore, since it is a very common instruction, it will generate only two bytes in our final shellcode.  It multiplies whatever is passed to it by the value stored in %eax, and stores the value in both %edx and %eax, completely overwriting the contents of both registers, regardless of whether it is necessary to do so, in order to store the result of the multiplication.  Let's put on our mathematician hats for a second, and consider this, what is the only possible result of a multiplication by 0?  The answer, as you may have guessed, is 0.  I think it's about time for some example code, so here it is:

xorl %ecx,%ecx
mul %ecx

What is this shellcode doing?  Well, it 0's out the %ecx register using the xor instruction, so we now know that %ecx is 0.  Then it does a mul %ecx, which as we just learned, multiplies it's operand by the value in %eax, and then proceeds to store the result of this multiplication in EDX:EAX.  So, regardless of %eax's previous contents, %eax must now be 0.  However that's not all, %edx is 0'd now too, because, even though no overflow occurs, it still overwrites the %edx register with the sign bit(left-most bit) of %eax.  Using this technique we can zero out three registers in only three bytes, whereas by any other method(that I know of) it would have taken at least six.


The div instruction

Div is very similar to mul, in that it takes only one operand and implicitly divides the operand by the value in %eax.  Also like, mul it stores the result of the divide in %eax.  Again, we will require the mathematical side of our brains to figure out how we can take advantage of this instruction.  But first, let's think about what is normally stored in the %eax register.  The %eax register holds the return value of functions and/or syscalls.  Most syscalls that are used in shellcoding will return -1(on failure) or a positive value of some kind, only rarely will they return 0(though it does occur).  So, if we know that after a syscall is performed, %eax will have a non-zero value, and that  the instruction divl %eax will divide %eax by itself, and then store the result in %eax, we can say that executing the divl %eax instruction after a syscall will put the value 1 into %eax.  So...how is this applicable to shellcoding? Well, their is another important thing that %eax is used for, and that is to pass the specific syscall that you would like to call to int $0x80.  It just so happens that the syscall that corresponds to the value 1 is exit().  Now for an example:

      
xorl %ebx,%ebx
mul %ebx
push %edx
pushl   $0x3268732f
pushl   $0x6e69622f
mov %esp, %ebx
push %edx
push %ebx
mov %esp,%ecx
movb $0xb, %al  #execve() syscall, doesn't return at all unless it fails, in which case it returns -1
int $0x80

divl %eax  # -1 / -1 = 1
int $0x80

Now, we have a 3 byte exit function, where as before it was 5 bytes.  However, there is a catch, what if a syscall does return 0?  Well in the odd situation in which that could happen, you could do many different things, like inc %eax, dec %eax, not %eax anything that will make %eax non-zero.  Some people say that exit's are not important in shellcode, because your code gets executed regardless of whether or not it exits cleanly.  They are right too, if you really need to save 3 bytes to fit your shellcode in somewhere, the exit() isn't worth keeping.  However, when your code does finish, it will try to execute whatever was after your last instruction, which will most likely produce a SIG ILL(illegal instruction) which is a rather odd error, and will be logged by the system.  So, an exit() simply adds an extra layer of stealth to your exploit, so that even if it fails or you can't wipe all the logs, at least this part of your presence will be clear.



Unlocking the power of leal

The leal instruction is an often neglected instruction in shellcode, even though it is quite useful.  Consider this short piece of shellcode.

xorl %ecx,%ecx
leal 0x10(%ecx),%eax

This will load the value 17 into eax, and clear all of the extraneous bits of eax.  This occurs because the leal instruction loads a variable of the type long into it's desitination operand.  In it's normal usage, this would load the address of a variable into a register, thus creating a pointer of sorts.  However, since ecx is 0'd and 0+17=17, we load the value 17 into eax instead of any kind of actual address.  In a normal shellcode we would do something like this, to accomplish the same thing:

xorl %eax,%eax
movb $0x10,%eax

I can hear you saying, but that shellcode is a byte shorter than the leal one, and you're quite right.  However, in a real shellcode you may already have to 0 out a register like ecx(or any other register), so the xorl instruction in the leal shellcode isn't counted.  Here's an example:

xorl    %eax,%eax
xorl    %ebx,%ebx
movb    $0x17,%al
int    $0x80
      
xorl %ebx,%ebx
leal 0x17(%ebx),%al
int $0x80

 


Both of these shellcodes call setuid(0), but one does it in 7 bytes while the other does it in 8.  Again, I hear you saying but that's only one byte it doesn't make that much of a difference, and you're right, here it doesn't make much of a difference(except for in shellcode-size pissing contests =p), but when applied to much larger shellcodes, which have many function calls and need to do things like this frequently, it can save quite a bit of space.