UNIX Socket FAQ

A forum for questions and answers about network programming on Linux and all other Unix-like systems

You are not logged in.

  • Index
  • » C
  • » understanding exploits

#1 2004-06-01 04:28 PM

felix
Member
Registered: 2003-12-04
Posts: 171

Re: understanding exploits

Aloha!

I'm reading and trying understand how exploits work, in a paper they used a technique called "ALIGN" that i don't know what it try align! :(

The code is that:

for (i=0;i<howling;i+=4)

       {
                buffer[i+ALIGN]=(retaddr&0x000000ff);
                buffer[i+ALIGN+1]=(retaddr&0x0000ff00)>>8;
                buffer[i+ALIGN+2]=(retaddr&0x00ff0000)>>16;
                buffer[i+ALIGN+3]=(retaddr&0xff000000)>>24;
        }

Where:

i = integer var to be used in loop
howlong =  is the size of buffer to be overflowed
ALIGN = is a integer initilized with ZERO.
retaddr = is the stack pointer less offset (in this case ZERO).

I understood that it is a rigth bit deslocation, but why ?? for what ? What are this 0xyyyyyyy ? Someone can help me ?

Thkz

Offline

#2 2004-06-01 07:39 PM

RobSeace
Administrator
From: Boston, MA
Registered: 2002-06-12
Posts: 3,847
Website

Re: understanding exploits

Well, on some systems, code and data must be properly aligned
on the stack, usually so that it starts on a native word address
boundry...  So, presumably, that "ALIGN" value would be set to
the offset needed to reach the proper alignment... *shrug*

As for the bit-twiddling and hex numbers, all that's doing is splitting
the retaddr into its component bytes, and stuffing each one
individually into the appropriate spot in the buffer...  Though,
really, those 4 assignments could be replace by a simple:

memcpy (buffer + i + ALIGN, &retaddr, 4);

But, some people like to do things the hard way... ;-)

Offline

#3 2004-06-02 03:31 AM

Nope
Administrator
From: Germany
Registered: 2004-01-24
Posts: 385
Website

Re: understanding exploits

No Rob, a simple memcpy isn't the same. To copy what the original code
does you'd have to perform a htonl prior to the memcpy. I do the same
somewhere in my code to "normalise" some ints as I once had problems
to get htonl to work properly with int instead of unsigned long.

I am not sure why they bother to add the Align thing. The compiler is
supposed to take care of those problems after all.

Well Felix. The 0xyyyyyyyy is the hex way to represent a 32 bit integer.
The FF you see in there represents the case that 8 bits are set to 1. The
'&' performs a bitwise "and" operation, making in this case sure that all
other bits beside those under the FF are set to zero. The buffer is a char
array and a char is supposed to be a 8 bit variable. By mascing the other
bits out they make sure that the type conversion from int to char goes right.
By shifting the value by 0,8,16,24 bits they put the value they want to
store in the lowest 8bits of the int so that it can be taken over by the char.

"192.168.0.15" is C0A8000F in hex.

C0A8000F & 000000FF is 000000 0F
C0A8000F & 0000FF00 is 00000000 right shift by 8 is 000000 00
C0A8000F & 00FF0000 is 00A80000 right shift by 16 is 000000 A8
C0A8000F & FF000000 is C0000000 right shift by 24 is 000000 C0

Now integers are stored differently on different systems. So the memcpy
that Rob proposes would reverse the byte order on a i386 based system.
On other systems, like the ones with a G5  processor the byte order would
be correct. In this case would be a union(int and 4byte char array) faster
than a memcpy. That's why we have to normalise values in the net to ensure
that all computers get the same numbers to work with. It gets woerse on
some older 16 bit systems that represent a 32bit value as a pair of 2 16bit
values.

on a G5: C0A8000F
on i386: 0F00A8C0
old 16bit: 000F C0A8 or 0F00 A8C0 (I've seen both)

Offline

#4 2004-06-02 03:36 AM

Nope
Administrator
From: Germany
Registered: 2004-01-24
Posts: 385
Website

Re: understanding exploits

no edit in here...

of course the retaddr thingy is supposed to be already in net byte order in
the first place, so Rob is right of course.  :oops:

Offline

#5 2004-06-02 01:35 PM

RobSeace
Administrator
From: Boston, MA
Registered: 2002-06-12
Posts: 3,847
Website

Re: understanding exploits

Heh.  I was just about to write code to verify that I was correct,
and then bitch at you, too... ;-)

But, it has nothing to do with it being in network byte order; rather,
it's already in host byte order, and you want to KEEP it in host
byte order, since it needs to be interpreted by the host as a valid
address to jump to...  So, regardless of your native byte ordering,
you can ALWAYS safely do a simple memcpy() into the buffer...
In fact, that's always SAFER to do than trying to do the manual
byte-splitting, since to do that, you need to make some implicit
assumptions about the native byte ordering, to determine which
byte goes where in the buffer...  Just doing a raw memcpy() hides
those details from you, and everything works magically... ;-)

Offline

#6 2004-06-02 04:58 PM

felix
Member
Registered: 2003-12-04
Posts: 171

Re: understanding exploits

Hi RobSeace and Nope! :)

Thkz once again for help with my dummy questions..  :oops:

The explanation of Nope was really intersting i doesn't know about that facts between processors like i386, G5, 16bits processors, etc. Very cool it! And appear that play with ASM in G5 is more easy since i belive that wi can push data at stack in normal order (not like i386, in reverse order).

I already know what is a shift rigth and AND logical operation, my doubt is for what use it and why that hex number.

But based at your example i had a doubt. You post:

C0A8000F & 00FF0000 is 00A80000

And if we have C0A8000F & 00A80000 what should be the result ? 00A80000,  00000000 or 00110000 ??

I yet have some doubts.

1 - Where can i found documentation about this "need" of "align" data at stack ? I doen't understand it very well yet.. the why/because..  :cry:

2 - Why he does that AND operation between retaddr (stack pointer address of his program) and this pre-defined hex numbers that are one byte changing the FF (255) in each to 2 bits and making a 8 bits increment in shift rigth ? Why ?? To put it each 2bits of the byte (retaddr) in binary form in each byte of "buffer" ??

3 - The memcpy() really is much more easy and better, but yet, with memcpy (buffer + i + ALIGN, &retaddr, 4); why use size 4 as last paramter ? Because it will convert each 2byte (2hex numbers from retaddr) into a binary and save at buffer ?

4 - Why do it in all buffer ?? Why we need to save the retaddr in this form in all buffer and not only in the original retaddr ?

ps.: When i be a big man, i will want be like RobSeace and Nope!  :wink:

Regards

Offline

#7 2004-06-02 08:21 PM

RobSeace
Administrator
From: Boston, MA
Registered: 2002-06-12
Posts: 3,847
Website

Re: understanding exploits

Offline

#8 2004-06-03 01:01 AM

Nope
Administrator
From: Germany
Registered: 2004-01-24
Posts: 385
Website

Re: understanding exploits

Offline

#9 2004-06-03 09:13 AM

mlampkin
Administrator
From: Sol 3
Registered: 2002-06-12
Posts: 911
Website

Re: understanding exploits

For a buffer overflow exploit... especially if you are passing raw ( machine ) code and data at the system...

The exploit software has to make perform all required data alignment ( as described in the preceding messages) by "hand"... otherwise the exploit commands would fault out instead of executing... 

That would be the rational behind the alignment var...

The byte by byte copy is also because of the above... i.e. the alignment between the host and target exploit string / commands may be different ( for any number of reasons )...  so a straight assignment isn't possible...

The 0x000000FF etc. lines seem sloppy btw...  the compiler should be giving warnings about potential precision loss / type mismatching if it sees that code ( and warnings are on )... since there is no explicit casting to the appropriate primitive type... 

Also note that if the code were explicitly casting to the correct type... the only thing required are the shift operators ( i.e. = ( char ) addr >> 16; )...  since the cast will automatically chop off the MSBs and you don't have to worry about accidental copy of the carry flag to somewhere inappropriate since all the shifts are on 8 bit boundaries...

Btw, I am guessing that is a fragment of the old UCD exploit code...


Michael


"The only difference between me and a madman is that I'm not mad."

Salvador Dali (1904-1989)

Offline

#10 2004-06-03 12:50 PM

RobSeace
Administrator
From: Boston, MA
Registered: 2002-06-12
Posts: 3,847
Website

Re: understanding exploits

Offline

#11 2004-06-04 03:36 AM

Nope
Administrator
From: Germany
Registered: 2004-01-24
Posts: 385
Website

Re: understanding exploits

It is right that intel processors can access unaligned data...most of the
time. Storing data unaligned will let you loose at least one clock cycle per
read or write operation. That doesn't sound much, but can easily slow
down the bottleneck ram by 30+%. Considering that the alignment is type
specific and that a normal compiler therefore only makes sure that the
first variable of a type is aligned properly you loose only very little
memory to the alignment overhead. So in the spirit of best resource use
on a PC type machine I see it as a must. As I said, you have to decide
between speed and memory usage. The SSE extensions for example get
so slowed down if the data isn't in a 16byte alignment that the use is
bogus. Well, if non-aligned data reduceses the efficiency, then alignment is
required in some way. The intel ones read 2 times the actual data and
then move it together into an aligned memory cell prior to start working
with it. By doing that you loose cache memory to gain a few bytes more regular ram. That this happens on hardware level doesn't change the
fact that the cpu core needs data alignment. The "late alignment" was just
built in to keep compatibility to older code. Other processors whose cores
have the same limitations and miss this additional compatibility mode
really need alignment.

Offline

#12 2004-06-04 02:09 PM

RobSeace
Administrator
From: Boston, MA
Registered: 2002-06-12
Posts: 3,847
Website

Re: understanding exploits

Offline

#13 2004-06-06 05:55 PM

Nope
Administrator
From: Germany
Registered: 2004-01-24
Posts: 385
Website

Re: understanding exploits

Offline

#14 2004-06-06 06:37 PM

RobSeace
Administrator
From: Boston, MA
Registered: 2002-06-12
Posts: 3,847
Website

Re: understanding exploits

Sure, but who interacts with the core?? ;-)  What the programmer
sees of Intel x86 looks nothing like its actual core, anymore...
These days, it's basically a RISC core, with a CISC interpreter on
top...  But, really, who cares?? ;-)  Ok, I'm sure someone cares;
like those writing optimizing compilers...  But, *I* don't care... ;-)
It's still just a bloated CISC chip to me, and one that'll work just fine
if I throw unaligned data/code at it...  How it accomplishes this
underneath doesn't really concern me too much...  (Unless I'm
trying to eke out every last bit of efficiency I possibly can, for some
bit of code, anyway...  But, more often than not, lots of other things
tend to take precedence over pure maximum efficiency...)

But, yes, I was being a smart-ass, and you may be TECHNICALLY
correct about there being SOME hidden requirement (I actually am
not sure, since I haven't kept up on the modern x86 core design)
somewhere... ;-)  But, the requirement is not one visible from the
outside, which is really all that matters, IMHO...

Oh, and vi is the only true editor, of course... ;-)  Emacs is the
work of the devil...  I mean, what sick, twisted weirdo would put a
damned LISP interpreter into his editor?!? ;-)

Offline

#15 2004-06-07 07:46 PM

felix
Member
Registered: 2003-12-04
Posts: 171

Re: understanding exploits

Hi,

Thkz a lot again, i really can understand it now. ;-)

Only a curious, i saw some of you writing "little endian & big endian" and i search about it (to learn what it is), and i saw that the PowePC can work like little and big endian... really cool! :)

Regards.

felix

Offline

  • Index
  • » C
  • » understanding exploits

Board footer

Powered by FluxBB