legal contact rss


How to use this swiss knife for our security work ...

Check this link for sample captures

OSI Layer

In respect to know where you have to look for your data, we need to have some theory first:

Remember: Please Do Not Through Sausage Pizza Away

ARP resolution

Right before a device can talk to devices on other network segments, it needs to (at least) know the layer2 address of the router.

Download the appropriate ARP-data packet and Analyse what you see

What is an gratious ARP

ARP spoofing (poisoning)

Let me demo the "Cracker"

arp -a

echo 1 > /proc/sys/net/ipv4/ip_forward

arpspoof -t & >/dev/null
arpspoof -t & >/dev/null


ettercap -T -q -M ARP / //

arp -a

TCP 3 way handshake

Calculate the ACK

Packet 1. Station A sends a SYN to Station B with a sequence number of 0. The Ack number is also zero.

Packet 2. Station B starts its sequence number at zero and acknowledges Station A’s sequence number by adding a 1.

Packet 3. Station A sends an ACK to Station B to acknowledge it’s starting sequence number. It also adds a 1 to the ISN.

Packet 4. Station A sends a GET request to Station B. This request is 100 Bytes long. The sequence number for station A starts at 1, but this packet has 100 Bytes of data in it. We add the amount of data sent to the current sequence number, then we get the next expected sequence number, 101.

Packet 5. Station B responds to the request from Station A. Since B has not sent data yet, its sequence number is still at 1. However in order to acknowledge receipt of the 100 bytes from Station A, it sends an acknowledgement number of 101. This packet contains 200 bytes of data, not including the IP and TCP headers. The next expected sequence number for station B will be 201.

Packet 6. Station A sends another request containing 50 bytes. It is now at sequence number 101 to start. The next expected sequence number should be 151 (101 + 50 = 151). It acknowledges the 200 bytes sent by station B by sending an ack number of 201.

Packet 7. Station B responds to the request with a 1000 byte packet. The starting sequence number is 201, so the next expected sequence number is 1201. It successfully received the 50 bytes from station A, so it acks with 151.

And so on…

The two machines will use these sequence numbers to track what has been sent and received. Remember that each side maintains its own sequence numbers. There is no running total for both sides of the conversation in a single sequence number.

Using these sequence numbers, we can see gaps in data where traffic was lost. For example, we may see traffic for sequence numbers 0-1000, then miss a few packets, and see another packet with a sequence number of 1500. Where are the missing 500 bytes? Wireshark does a great job of flagging these packets as out-of-order or “previous packet lost”.

Wireshark also has a very useful chart for graphing out sequence numbers called the “Stevens Graph”, available under Statistics | TCP Stream graph. This graph makes gaps in data and retransmissions very clear. In the chart below, we graphed the sequence numbers from a backup server during the backup and we could clearly see the gaps in transmission. This should be a solid line!

Time Sequence Graph Stevens sequence numbers

After having heard now how TCP works, can you answer below question?

What challenge has the NSA while doing the "Quantum Insert"?


Download the sample capture and explain your findings.