Tag Archives: Technology

The P Versus NP Problem Is One of Computer Science’s Biggest Unsolved Problems

 

In the world of theoretical computer science, P vs. NP is something of a mythical unicorn. It’s become notorious, since it remains an unsolved problem. It basically asks this: If it is easy to check that a solution to a problem is correct, is it also easy to solve that problem? Get back to us when you have an answer. (http://www.claymath.org/millennium-problems)

Why Is This So Hard?

In the P vs. NP problem (http://news.mit.edu/2009/explainer-pnp), the P stands for polynomial and the NP stands for nondeterministic polynomial time. Did we lose you? Let’s back up. In simpler terms, P stands for problems that are easy for computers to solve, and NP stands for problems that are not easy for computers to solve, but are easy for them to check. Here’s when an example might be helpful: “A farmer wants to take 100 watermelons of different masses to the market. She needs to pack the watermelons into boxes. Each box can only hold 20 kilograms without breaking. The farmer needs to know if 10 boxes will be enough for her to carry all 100 watermelons to market.” (https://simple.wikipedia.org/wiki/P_versus_NP)


Behnam Esfahbod / WIkipedia ()

This sample problem is not easy to solve; it requires you to go through every dang possible combination. Checking the final answer, however, is pretty easy. All P problems are also NP problems (if a computer can easily solve it, the computer can also easily check it). The question remains open: Are P problems and NP problems the same type of problem? Or, are there are some problems that are easily verified but not easily solved?

Who Wants To Be A Millionaire—From Math?

You may be wondering who really cares about this sort of thing. Well, if someone could show that P is equal to NP, it would make difficult real-world problems a piece of cake for computers to solve. Oh, and the person who solves this problem would also get $1 million from the Clay Mathematics Institute. The P vs. NP Problem is one of six unsolved Millennium Problems that hold a million-dollar prize for whoever cracks it.

Want to dive even further into the world's toughest math problems? Check out "The Millennium Problems: The Seven Greatest Unsolved Mathematical Puzzles Of Our Time" by Keith J. Devlin. We handpick reading recommendations we think you may like. If you choose to make a purchase, Curiosity will get a share of the sale.

Watch And Learn:
Why is P vs NP Important?

In this video,He explain perhaps the most famous problem in all of Computer Science. Does P = NP? He define the terms and give examples of each. We also programmatically go through the traveling salesman problem. He experiment with a little bit of mixed reality in this video as well.


Sources and References:https://curiosity.com/topics/the-p-versus-np-problem-is-one-of-computer-sciences-biggest-unsolved-problems-curiosity/
https://madatgravity96.wordpress.com/
http://www.claymath.org/millennium-problems

Blog:
https://thegeekiestone.com/

Advertisements

Solving the Assessment Puzzle — Open Matters

By Sarah Hansen, OCW Educator Project Manager Assessing students’ learning is one of the most important things we do as educators. It’s also one of the most complicated. There’s a lot to consider: When will assessment happen? (Along the way? At the end of the course?) How will we collect useful information about student learning? […]

via Solving the Assessment Puzzle — Open Matters

The Structure of the Earth

Physical Properties of the Earth

The Earth is an oblate spheroid, being slightly flattened at the
poles:

Equatorial radius = 6378 km Polar radius = 6357 km

These measurements are calculated on the assumption that the Earth’s surface is smooth, but this is only an approximation since it disregards mountains and ocean depths. However, the difference between the height of Mount Everest and the depth of the Marianas trench is only about 20 km. Most land is concentrated in seven continents each fringed by shallow seas (flooded continent). Separating these are a number of major oceans including the Pacific, Atlantic and the Indian oceans.

It was Cavendish in 1798 who first calculated the mass of the Earth as 5.977 x 1024kg, and since its volume is known (from 4/3 ∏ r^3 where r is the radius of the Earth), then it can be calculated that the average density is 5.516 g/cm3. However, most rocks exposed at the surface have densities of less than 3g/cc, for example:

sandstone: 1.9 - 2.4 g/cm3
limestone: 1.9 - 2.7 g/cm3
granite: 2.6 - 2.7 g/cm3
basalt: 2.8 - 3.0 g/cm3 

Therefore, a material of greater density must exist at deeper levels within the Earth. The Earth has a series of layers or “shells”, but only the outer few km of the Earth can be directly observed; the upper crust, and the deepest boreholes which reach to only about 12.5 kms. Earthquakes provide the key to the structure at depth.

Earthquakes

Stresses which develop in the Earth may become great enough to break the rocks, and cause slip along the resulting in fractures (faults). Although the slip distance in a given earthquake may be small (cm to metres), the rock masses involved are large and so the energy released is great. The resulting shock waves, or earthquakes, may cause great damage; greatest near the centre or focus, and less further away. The epicentre is the point on the surface of the Earth vertically above the focus.

Detection of seismic waves.
Earthquake energy is transmitted by several types of waves. Two types will be described:

P waves (primary or compressional) are transmitted by vibrations oscillating in the direction of propagation (push/pull).

S waves (secondary or shear), which vibrate at right angles to the direction of propagation. S waves cannot be transmitted through liquids because liquids have no elastic strength.

Recording Earthquakes

The arrival of earthquake waves is recorded by a seismograph. A mass is loosely coupled to the Earth by a spring. A chart is firmly coupled to the Earth. A pen linking them traces the difference in motion between the mass and the Earth’s surface. The arrival of waves from a distant earthquake is recorded as a seismogram on the rotating drum.

Consider what happens to P and S waves as they travel through the Earth.

The most important property of seismic waves is their speed of propagation. The velocity is governed by the physical properties (density, compressibility, rigidity) of the medium through which the wave is travelling.

Earlier in this lecture, it was deduced that the density of the Earth increases with depth. The wave propagation velocity must, therefore, change with depth, and this causes the wave to refract.

Refraction

If a wave travelling through a medium with a fixed density encounters a new medium with a different density, the wave will change its direction. This “bending” of the wave is called refraction.

Data from seismometers located around the world can record waves from any given earthquake. The differences between recordings at different seismometers reveal properties of the sub-surface and hence the internal structure of the Earth.

For example, it has been discovered that the mantle is solid rock, but the outer core is a liquid. This was discovered, because for any given earthquake:-

  1. Both P and S waves are recorded by seismometers at distances of up to 103o from the epicentre.
  2. At distances greater than 103o, no S waves are recorded. This means that S waves that would have reappeared at > 103o have not propagated. The material at depths travelled by such waves must be liquid and be unable to transmit S waves.

Also, it has been discovered that the outer core must have a lower P wave velocity than the mantle. This is because at distances of 103o to 142o, no strong P waves are recorded. The liquid outer core has a lower P wave velocity, causing the P waves to be refracted to a steeper angle, so they cannot re-emerge between 103o to 142o. They actually re-emerge at angles > 186o. There is one small caveat to this observation. The inner core appears to be solid because some weak P wave arrivals occur between 103o to 142o. This is thought to be due to a slight increase in P wave velocity as waves enter the inner core, causing them to be refracted to a shallower angle, to re-emerge between 103o to 142o. If the inner core is solid, S waves could propa- gate there. The graph shows some calculations of what expected S wave velocities would be, but the inner core structure is still a source of controversy.

The MOHO

In the early 20th century a Yugoslavian seismologist by the name of Mohorovicic was studying seismograms from shallow focus earthquakes (< 40 km) that were nearby <800km. He noticed that there were 2 distinct sets of P waves and S waves involved. He interpreted these waves as a direct set and a refracted set. In the refracted set, waves travel down and are refracted at a boundary by a medium of higher velocity.

This boundary separates the crust with VP of 6-7km/sec from the upper mantle where VP starts at 8km/sec. It is called the Mohorovicic discontinuity but is commonly known as the MOHO.

Today, seismologists use artificial explosions to determine the structure beneath the surface and it is from these data that the depth of the MOHO can be calculated and thus the thickness of the crust. The MOHO is at 5-15 km under ocean crust and 35 km beneath normal thickness continental crust. The MOHO can be as much as 70 km deep beneath mountain belts where converging plates have caused an orogeny or mountain building event.

The Structure of the Earth

Recent advances in seismology now allow tomographic images of the interior of the Earth to be produced from P and S wave velocity data. Just as tomographic images of the interior of human bodies are produced by density contrasts in human tissue and bone subject to wave propagation, density contrasts in the Earth can be mapped by combining wave velocity data from large numbers of earthquakes.

The basic idea is that where the solid mantle is relatively hot, the P and S wave velocities should be anomalously low because the heat will result in a density decrease. One should be able to image hot, ascending plumes of mantle asthenosphere by looking for areas of anomalously low seismic velocity. Conversely, where the solid mantle is relatively cool, the P and S wave velocities should be anomalously fast because the lack of heat will result in a relatively high density.

One should be able to image cool, descending slabs of mantle lithosphere by looking for areas of anomalously high seismic velocity. Such images allow us to study subduction zones and constrain how deep the slabs penetrate. It appears that some slabs do not penetrate beneath 670 km whereas others continue down to the core-mantle boundary. This is an area of controversy in geology.

League of Legends Live: A Concert Experience at 2017 Worlds Countdown

League of Legends Live: A Concert Experience at 2017 Worlds Countdown

https://clips.twitch.tv/embed?clip=AverageStormyOilBlargNaut&autoplay=false&tt_medium=clips_embed

 

Astronomy Picture of the Day – Eclipsosaurus Rex

See Explanation.  Clicking on the picture will download
 the highest resolution version available.

Eclipsosaurus Rex 
Image Credit & CopyrightFred Espenak (MrEclipse.com)Explanation: We live in an era where total solar eclipses are possible because at times the apparent size of the Moon can just cover the disk of the Sun. But the Moon is slowly moving away from planet Earth. Its distance is measured to increase about 1.5 inches (3.8 centimeters) per year due to tidal friction. So there will come a time, about 600 million years from now, when the Moon is far enough away that the lunar disk will be too small to ever completely cover the Sun. Then, at best only annular eclipses, a ring of fire surrounding the silhouetted disk of the too small Moon, will be seen from the surface of our fair planet. Of course the Moon was slightly closer and loomed a little larger 100 million years ago. So during the age of the dinosaurs there were more frequent total eclipses of the Sun. In front of the Tate Geological Museum at Casper College in Wyoming, this dinosaur statue posed with a modern total eclipse, though. An automated camera was placed under him to shoot his portrait during the Great American Eclipse of August 21.

 

From: https://apod.nasa.gov/apod/ap171007.html

Astronomy Picture of the Day – Global Aurora at Mars

See Explanation.  Clicking on the picture will download
 the highest resolution version available.Global Aurora at Mars 
Image Credit: MAVENLASP, University of ColoradoNASAExplanation: A strong solar event last month triggered intense global aurora at Mars. Before (left) and during (right) the solar storm, these projections show the sudden increase in ultraviolet emission from martian aurora, more than 25 times brighter than auroral emission previously detected by the orbiting MAVEN spacecraft. With a sunlit crescent toward the right, data from MAVEN’s ultraviolet imaging spectrograph is projected in purple hues on the right side of Mars globes simulated to match the observation dates and times. On Mars, solar storms can result in planet-wide aurora because, unlike Earth, the Red Planet isn’t protected by a strong global magnetic field that can funnel energetic charged particles toward the poles. For all those on the planet’s surface during the solar storm, dangerous radiation levels were double any previously measured by the Curiosity rover. MAVEN is studying whether Mars lost its atmosphere due to its lack of a global magnetic field.

 

Source: https://apod.nasa.gov/apod/ap171006.html

WannaCry a Birthday Gift??

I woke up on the 12th of May, it was my birthday, and I looked on the news feed and saw a burst of articles regarding the WannaCry Ransomware that has swept across the globe.

number20of20symantec20detections20for20wannacry20may201120to2015
In the last few days, a new type of malware called Wannacrypt has done worldwide damage.  It combines the characteristics of ransomware and a worm and has hit a lot of machines around the world from different enterprises or government organizations:

https://www.theregister.co.uk/2017/05/13/wannacrypt_ransomware_worm/

While everyone’s attention related to this attack has been on the vulnerabilities in Microsoft Windows XP, please pay attention to the following:

  • The attack works on all versions of Windows if they haven’t been patched since the March patch release!
  • The malware can only exploit those vulnerabilities it first has to get on the network.  There are reports it is being spread via email phishing or malicious web sites, but these reports remain uncertain.

 

Please take the following actions immediately:

  • Make sure all systems on your network are fully patched, particularly servers.
  • As a precaution, please ask all colleagues at your location to be very careful about opening email attachments and minimise browsing the web while this attack is on-going.

 

The vulnerabilities are fixed by the below security patches from Microsoft which was released in Mar of 2017, please ensure you have patched your systems:

https://technet.microsoft.com/en-us/library/security/ms17-010.aspx

Details of the malware can be found below.  The worm scans port TCP/445 which is the windows SMB services for file sharing:

https://securelist.com/blog/incidents/78351/wannacry-ransomware-used-in-widespread-attacks-all-over-the-world/

Preliminary study shows that our environment is not infected based on all hashes and domain found:

 

URL:

www.iuqerfsodp9ifjaposdfjhgosurijfaewrwergwea.com

MD5 hash:

4fef5e34143e646dbf9907c4374276f5
5bef35496fcbdbe841c82f4d1ab8b7c2
775a0631fb8229b2aa3d7621427085ad
7bf2b57f2a205768755c07f238fb32cc
7f7ccaa16fb15eb1c7399d422f8363e8
8495400f199ac77853c53b5a3f278f3e
84c82835a5d21bbcf75a61706d8ab549
86721e64ffbd69aa6944b9672bcabb6d
8dd63adb68ef053e044a5a2f46e0d2cd
b0ad5902366f860f85b892867e5b1e87
d6114ba5f10ad67a4131ab72531f02da
db349b97c37d22f5ea1d1841e3c89eb4
e372d07207b4da75b3434584cd9f3450
f529f4556a5126bba499c26d67892240

 

Per Symantec, here is a full list of the filetypes that are targeted and encrypted by WannaCry:

  • .123
  • .3dm
  • .3ds
  • .3g2
  • .3gp
  • .602
  • .7z
  • .ARC
  • .PAQ
  • .accdb
  • .aes
  • .ai
  • .asc
  • .asf
  • .asm
  • .asp
  • .avi
  • .backup
  • .bak
  • .bat
  • .bmp
  • .brd
  • .bz2
  • .cgm
  • .class
  • .cmd
  • .cpp
  • .crt
  • .cs
  • .csr
  • .csv
  • .db
  • .dbf
  • .dch
  • .der
  • .dif
  • .dip
  • .djvu
  • .doc
  • .docb
  • .docm
  • .docx
  • .dot
  • .dotm
  • .dotx
  • .dwg
  • .edb
  • .eml
  • .fla
  • .flv
  • .frm
  • .gif
  • .gpg
  • .gz
  • .hwp
  • .ibd
  • .iso
  • .jar
  • .java
  • .jpeg
  • .jpg
  • .js
  • .jsp
  • .key
  • .lay
  • .lay6
  • .ldf
  • .m3u
  • .m4u
  • .max
  • .mdb
  • .mdf
  • .mid
  • .mkv
  • .mml
  • .mov
  • .mp3
  • .mp4
  • .mpeg
  • .mpg
  • .msg
  • .myd
  • .myi
  • .nef
  • .odb
  • .odg
  • .odp
  • .ods
  • .odt
  • .onetoc2
  • .ost
  • .otg
  • .otp
  • .ots
  • .ott
  • .p12
  • .pas
  • .pdf
  • .pem
  • .pfx
  • .php
  • .pl
  • .png
  • .pot
  • .potm
  • .potx
  • .ppam
  • .pps
  • .ppsm
  • .ppsx
  • .ppt
  • .pptm
  • .pptx
  • .ps1
  • .psd
  • .pst
  • .rar
  • .raw
  • .rb
  • .rtf
  • .sch
  • .sh
  • .sldm
  • .sldx
  • .slk
  • .sln
  • .snt
  • .sql
  • .sqlite3
  • .sqlitedb
  • .stc
  • .std
  • .sti
  • .stw
  • .suo
  • .svg
  • .swf
  • .sxc
  • .sxd
  • .sxi
  • .sxm
  • .sxw
  • .tar
  • .tbk
  • .tgz
  • .tif
  • .tiff
  • .txt
  • .uop
  • .uot
  • .vb
  • .vbs
  • .vcd
  • .vdi
  • .vmdk
  • .vmx
  • .vob
  • .vsd
  • .vsdx
  • .wav
  • .wb2
  • .wk1
  • .wks
  • .wma
  • .wmv
  • .xlc
  • .xlm
  • .xls
  • .xlsb
  • .xlsm
  • .xlsx
  • .xlt
  • .xltm
  • .xltx
  • .xlw
  • .zip

As you can see, the ransomware covers nearly any important file type a user might have on his or her computer. It also installs a text file on the user’s desktop with the following ransom note:

2cry

How to prepare for PWK/OSCP, a noob-friendly guide

Few months ago, I didn’t know what Bash was, only heard of SSH tunneling, no practical knowledge. I also didn’t like paying for the PWK lab time without using it, so I went through a number of resources till I felt ready for starting the course.

Warning: Don’t expect to be spoon-fed if you’re doing OSCP, you’ll need to spend a lot of time researching, neither the admins or the other students will give you answers easily.

1. PWK Syllabus
1.1 *nix and Bash
1.2 Basic tools
1.3 Passive Recon
1.4 Active Recon
1.5 Buffer Overflow
1.6 Using public exploits
1.7 File Transfer
1.8 Privilege Escalation
1.9 Client-Side Attacks
1.10 Web Application Attacks
1.11 Password Attacks
1.12 Port Redirection/Tunneling
1.13 Metasploit Framework
1.14 Antivirus Bypassing
2. Wargames
2.1 Over The Wire: Bandit
2.2 Over The Wire: Natas
2.3 Root-me.org
3. Vulnerable VMs

1. PWK Syllabus:

Simply the most important reference in the list, it shows the course modules in a detailed way. Entire preparation I did was based on it. Can be found here.

1.1 *nix and Bash:

You don’t need to use Kali Linux right away, a good alternative is Ubuntu till you get comfortable with Linux.

1. Bash for Beginners: Best Bash reference IMO.
2. Bandit on Over The Wire: Great start for people who aren’t used to using a terminal, aren’t familiar with Bash or other *nix in general. Each challenge gives you hints on which commands you can use, you need to research them.
3.  Explainshell: Does NOT replace man pages, but breaks down commands easily for new comers.

1.2 Basic tools:

You will use these tools a lot. Make sure you understand what they do and how you can utilize them.

Netcat: Most important tool in the entire course. Understand what it does, what options you have, difference between a reverse shell and a bind shell. Experiment a lot with it.
Ncat: Netcat’s mature brother, supports SSL. Part of Nmap.
Wireshark: Network analysis tool, play with it while browsing the internet, connecting to FTP, read/write PCAP files.
TCPdump: Not all machines have that cute GUI, you could be stuck with a terminal.

1.3 Passive Recon:

Read about the following tools/techniques, experiment as much as possible.

1. Google dorks
2. Whois
3. Netcraft
4. Recon-ng: Make sure you check the Usage guide to know how it works.

1.4 Active Recon:

  • Understand what DNS is, how it works, how to perform forward and reverse lookup, what zone transfers are and how to perform them. Great resource here.
  • Nmap: One of the most used tools during the course (if not the most). I’d recommend to start by reading the man pages, understand different scanning techniques and other capabilities it has (scripts, OS detection, Service detection, …)
  • Services enumeration: SMTP, SNMP, SMB, and a lot others. Don’t just enumerate them, understand what they’re used for and how they work.
  • Great list for enumeration and tools.

1.5 Buffer Overflow:

Most fun part in my opinion. There are countless resources on how to get started, I’d recommend Corelan’s series. You probably need the first part only for PWK.

1.6 Using public exploits:

Occasionally, you’ll need to use a public exploit, maybe even modify the shellcode or other parts. Just go to Exploit-db and pick one of the older more reliable exploits (FTP ones for example). The vulnerable version is usually present with the exploit code.

1.7 File Transfer:

Not every machine has netcat installed, you’ll need to find a way around it to upload exploits or other tools you need. Great post on this is here.

1.8 Privilege Escalation:

A never ending topic, there are a lot of techniques, ranging from having an admin password to kernel exploits. Great way to practice this is by using Vulnhub VMs for practice. Check my OSCP-like VMs list here.

Windows:Elevating privileges by exploiting weak folder permissions
Windows: Privilege Escalation Fundamentals
Windows: Windows-Exploit-Suggester
Windows: Privilege Escalation Commands
Linux: Basic Linux Privilege Escalation
Linux: linuxprivchecker.py
Linux: LinEnum
Practical Windows Privilege Escalation
MySQL Root to System Root with UDF

1.9 Client Side Attacks:

Try out the techniques provided in Metasploit Unleashed or an IE client side exploit.

1.10 Web Application Attacks

Another lengthy subject, understand what XSS is, SQL injection, LFI, RFI, directory traversal, how to use a proxy like Burp Suite. Solve as much as you can from Natas on Over The Wire. It has great examples on Code Injection, Session hijacking and other web vulnerabilities.

Key is research till you feel comfortable.

1.11 Password Attacks:

Understand the basics of password attacks, difference between online and offline attacks. How to use Hydra, JTR, Medusa, what rainbow tables are, the list goes on. Excellent post on this topic here.

1.12 Port redirection/tunneling:

Not all machines are directly accessible, some are dual homed, connected to an internal network. You’ll use such techniques a lot in non-public networks. This post did a great job explaining it.

1.13 Metasploit Framework:

Decided to skip this part, but if you still want to study it, check out Metasploit Unleashed course.

 

1.14 Antivirus Bypassing:

Skipped this part too.

2. Wargames

Use them as a prep for vulnerable machines.

2.1 Over The Wire: Bandit

Great start for people who aren’t familiar with Linux or Bash.

2.2 Over The Wire: Natas

Focused on web application, many challenges aren’t required for OSCP, but it helps for sure.

2.3 Root-me.org

Has great challenges on privilege escalation, SQL injection, Javascript obfuscation, password cracking and analyzing PCAP files

3. Vulnerable Machines

Boot-to-root VMs are excellent for pentesting, you import a VM, run it and start enumerating from your attacking machine. Most of them result in getting root access. Check the post on which machines are the closest to OSCP, there is also the https://lab.pentestit.ru/ .

Blog posts regarding my journey through Pentestit.ru.:

Pentestit Lab v10 – Introduction & Setup
Pentestit Lab v10 – The Mail Token
Pentestit Lab v10 – The Site Token

How to Sniff a Network: Decoding the IP Layer

 

Following from previous post, which can be found at: How to Sniff a Network : Packet Sniffing on Windows and Linux and How to Sniff a Network : Raw Sockets and Sniffing.

Sniffing one packet is not overly useful, so let’s add some functionality to process more packets and decode their contents.

In its current form, our sniffer receives all of the IP headers along with any higher protocols such as TCP, UDP, or ICMP. The information is packed into binary form, and as shown above, is quite difficult to understand. We are now going to work on decoding the IP portion of a packet so that we can pull useful information out such as the protocol type (TCP, UDP, ICMP), and the source and destination IP addresses. This will be the foundation for you to start creating further protocol parsing later on. If we examine what an actual packet looks like on the network, you will have an understanding of how we need to decode the incoming packets. Refer to Figure 3-1 for the makeup of an IP header.

Figure 3-1 Typical IPv4 header structure
Figure 3-1: Typical IPv4 header structure

We will decode the entire IP header (except the Options field) and extract the protocol type, source, and destination IP address. Using the Python ctypes module to create a C-like structure will allow us to have a friendly format for handling the IP header and its member fields. First, let’s take a look at the C definition of what an IP header looks like.

struct ip {
u_char ip_hl:4;
u_char ip_v:4;
u_char ip_tos;
u_short ip_len;
u_short ip_id;
u_short ip_off;
u_char ip_ttl;
u_char ip_p;
u_short ip_sum;
u_long ip_src;
u_long ip_dst;
}

You now have an idea of how to map the C data types to the IP header values. Using C code as a reference when translating to Python objects can be useful because it makes it seamless to convert them to pure Python. Of note, the ip_hl and ip_v fields have a bit notation added to them (the :4 part). This indicates that these are bit fields, and they are 4 bits wide. We will use a pure Python solution to make sure these fields map correctly so we can avoid having to do any bit manipulation. Let’s implement our IP decoding routine into sniffer_ip_header_decode.py as shown below.

import socket


import os
import struct
from ctypes import *

# host to listen on
host = "192.168.0.187"


# our IP header
u class IP(Structure):
_fields_ = [
("ihl", c_ubyte, 4),
("version", c_ubyte, 4),
("tos", c_ubyte),
("len", c_ushort),
("id", c_ushort),
("offset", c_ushort),
("ttl", c_ubyte),
("protocol_num", c_ubyte),
("sum", c_ushort),
("src", c_ulong),
("dst", c_ulong)
]


def __new__(self, socket_buffer=None):
return self.from_buffer_copy(socket_buffer)


def __init__(self, socket_buffer=None):


# map protocol constants to their names


self.protocol_map = {1:"ICMP", 6:"TCP", 17:"UDP"}


v # human readable IP addresses


self.src_address = socket.inet_ntoa(struct.pack("<L",self.src))
self.dst_address = socket.inet_ntoa(struct.pack("<L",self.dst))


# human readable protocol
try:
self.protocol = self.protocol_map[self.protocol_num]
except:
self.protocol = str(self.protocol_num)


# this should look familiar from the previous example
if os.name == "nt":
socket_protocol = socket.IPPROTO_IP
else:
socket_protocol = socket.IPPROTO_ICMP


sniffer = socket.socket(socket.AF_INET, socket.SOCK_RAW, socket_protocol)


sniffer.bind((host, 0))
sniffer.setsockopt(socket.IPPROTO_IP, socket.IP_HDRINCL, 1)


if os.name == "nt":


sniffer.ioctl(socket.SIO_RCVALL, socket.RCVALL_ON)

try:


while True:


# read in a packet
w raw_buffer = sniffer.recvfrom(65565)[0]


# create an IP header from the first 20 bytes of the buffer
x ip_header = IP(raw_buffer[0:20])


# print out the protocol that was detected and the hosts
y print "Protocol: %s %s -> %s" % (ip_header.protocol, ip_header.src_¬
address, ip_header.dst_address)


# handle CTRL-C
except KeyboardInterrupt:

# if we're using Windows, turn off promiscuous mode
if os.name == "nt":
sniffer.ioctl(socket.SIO_RCVALL, socket.RCVALL_OFF)

The first step is defining a Python ctypes structure u that will map the first 20 bytes of the received buffer into a friendly IP header. As you can see, all of the fields that we identified and the preceding C structure match up nicely. The __new__ method of the IP class simply takes in a raw buffer (in this case, what we receive on the network) and forms the structure from it. When the __init__ method is called, __new__ is already finished processing the buffer. Inside __init__, we are simply doing some housekeeping to give some human readable output for the protocol in use and the IP addresses v.
With our freshly minted IP structure, we now put in the logic to continually read in packets and parse their information. The first step is to read in the packet w and then pass the first 20 bytes x to initialize our IP structure. Next, we simply print out the information that we have captured y.
Let’s try it out.

Kicking the Tires

Let’s test out our previous code to see what kind of information we are extracting from the raw packets being sent. I definitely recommend that you do this test from your Windows machine, as you will be able to see TCP, UDP, and ICMP, which allows you to do some pretty neat testing (open up a browser, for example). If you are confined to Linux, then perform the previous ping test to see it in action.

Open a terminal and type:

python sniffer_ip_header_decode.py

Now, because Windows is pretty chatty, you’re likely to see output immediately.
I tested this script by opening Internet Explorer and going to www
.google.com, and here is the output from our script:

Protocol: UDP 192.168.0.190 -> 192.168.0.1
Protocol: UDP 192.168.0.1 -> 192.168.0.190
Protocol: UDP 192.168.0.190 -> 192.168.0.187
Protocol: TCP 192.168.0.187 -> 74.125.225.183
Protocol: TCP 192.168.0.187 -> 74.125.225.183
Protocol: TCP 74.125.225.183 -> 192.168.0.187
Protocol: TCP 192.168.0.187 -> 74.125.225.183

Because we aren’t doing any deep inspection on these packets, we can only guess what this stream is indicating. My guess is that the first couple of UDP packets are the DNS queries to determine where google.com lives, and the subsequent TCP sessions are my machine actually connecting and downloading content from their web server. To perform the same test on Linux, we can ping google.com, and the results will look something like this:

Protocol: ICMP 74.125.226.78 -> 192.168.0.190
Protocol: ICMP 74.125.226.78 -> 192.168.0.190
Protocol: ICMP 74.125.226.78 -> 192.168.0.190

You can already see the limitation: we are only seeing the response and only for the ICMP protocol. But because we are purposefully building a host discovery scanner, this is completely acceptable. We will now apply the same techniques we used to decode the IP header to decode the ICMP messages. Stay tuned for the next post.

How to Sniff a Network: Packet Sniffing on Windows and Linux

Network sniffers allow you to see packets entering and exiting a target machine. As a result, they have many practical uses before and after exploitation. In some cases, you’ll be able to use Wireshark (https://wireshark.org/) to monitor traffic or use a Pythonic solution like Scapy (which we’ll explore in the later posts). Nevertheless, you can read more: How to Sniff a Network : Raw Sockets and Sniffing.

 

Accessing raw sockets in Windows is slightly different than on its Linux brethren, but we want to have the flexibility to deploy the same sniffer to multiple platforms. We will create our socket object and then determine which platform we are running on. Windows requires us to set some additional flags through a socket input/output control (IOCTL),1 which enables promiscuous mode on the network interface. In our first example, we simply set up our raw socket sniffer, read in a single packet, and then quit.

import socket
import os
# host to listen on
host = "192.168.0.196"

# create a raw socket and bind it to the public interface
if os.name == "nt":
u socket_protocol = socket.IPPROTO_IP
else:
socket_protocol = socket.IPPROTO_ICMP
sniffer = socket.socket(socket.AF_INET, socket.SOCK_RAW, socket_protocol)
sniffer.bind((host, 0))

# we want the IP headers included in the capture
v sniffer.setsockopt(socket.IPPROTO_IP, socket.IP_HDRINCL, 1)

# if we're using Windows, we need to send an IOCTL
# to set up promiscuous mode
w if os.name == "nt":
sniffer.ioctl(socket.SIO_RCVALL, socket.RCVALL_ON)

# read in a single packet
x print sniffer.recvfrom(65565)

# if we're using Windows, turn off promiscuous mode
y if os.name == "nt":
sniffer.ioctl(socket.SIO_RCVALL, socket.RCVALL_OFF)

We start by constructing our socket object with the parameters necessary for sniffing packets on our network interface u. The difference between Windows and Linux is that Windows will allow us to sniff all incoming packets regardless of protocol, whereas Linux forces us to specify that we are sniffing ICMP. Note that we are using promiscuous mode, which requires administrative privileges on Windows or root on Linux. Promiscuous mode allows us to sniff all packets that the network card sees, even those not destined for your specific host. Next we set a socket option that includes the IP headers in our captured packets. The next step w is to determine if we are using Windows, and if so, we perform the additional step of sending an IOCTL to the network card driver to enable promiscuous mode. If you’re running Windows in a virtual machine, you will likely get a notification that the guest operating system is enabling promiscuous mode; you, of course, will allow it. Now we are ready to actually perform some sniffing, and in this case we are simply printing out the entire raw packet x with no packet decoding. This is just to test to make sure we have the core of our sniffing code working. After a single packet is sniffed, we again test for Windows, and disable promiscuous mode y before exiting the script.

Kicking the Tires

Open up a fresh terminal or cmd.exe shell under Windows and run the
following:

python sniffer.py

In another terminal or shell window, you can simply pick a host to ping.
Here, we’ll ping nostarch.com:

ping nostarch.com

In your first window where you executed your sniffer, you should see
some garbled output that closely resembles the following:

('E\x00\x00:\x0f\x98\x00\x00\x80\x11\xa9\x0e\xc0\xa8\x00\xbb\xc0\xa8\x0
0\x01\x04\x01\x005\x00&\xd6d\n\xde\x01\x00\x00\x01\x00\x00\x00\x00\x00\
x00\x08nostarch\x03com\x00\x00\x01\x00\x01', ('192.168.0.187', 0))

You can see that we have captured the initial ICMP ping request destined for nostarch.com (based on the appearance of the string nostarch.com).
If you are running this example on Linux, then you would receive the response from nostarch.com. Sniffing one packet is not overly useful, so let’s add some functionality to process more packets and decode their contents in the following post.