proposal.txt

Bunny.py:

Bunny is intended to act as a layer 1/2 technology for near unsignaturable wireless mesh communication.
Bunny wraps all data in and out in a layer of obfoscation, it does this by passively listening to 
the local wireless and building a model of 'average' traffic. Then using this model it hides small 
snippets of data within various fields of the 802.11 protocol, that are either poorly defined or 
prone to contain data that mutates a lot.  These fields will include but are not limited to; vendor 
data, data packets of encrypted networks, duration fields.

Nodes will be able to find bunny specific packets with the preshared information of a modulus and 
remainder value that will be applied to the packet length of each read packet.  Bunny will 
have two layers of communication, one being a transport and routing protocol that will be able to be 
read with just a AES key, modulus and remainder value.  This layer will handle data routing and the 
backbone of a Bunny based network.  Then within that channel, many seperate communication channels 
can exist with a second round of block chipher encrypted data.  This provides for a 'russian doll'
model of commuincation channels, thus allowing for a properly layered privacy scheme.

So far the project depends on 3 external libraries:
	1. pylorcon (802.11 injection)
	   - and the underlying Lorcon library
	2. pcapy	(802.11 reading of packets)
	3. pycrypto	(cryptography)


The overall architecture will have classes for all major sectors of the programs:
	- encryption
	- send / recv
	- traffic modeling
	- templates
	- configuration
	
The structure of the application is as such:
	- The AEScrypt class is just a container for 2 functions, encrypt and decrypt.
	- The SendRec class is the backbone of the IO in the application.  When init'd,
	  both a lorcon object and pcapy instance are created and the interface is set into 
	  monitor mode. 
	  There is a function for updating the channel on the interface, testing packet 
	  capturing and grabing raw packets that include a RadioTap header. 
	
	- The TrafficModel class is the brains of the obfuscation functionality.
	  What is does is when created it captures a 3 second long packet capture using the 
	  SendRec class then analysis's the distribution of packet types and mac addresses.
	  Then it stick most of that data into two lists, type_ranges and mac_addresses.
	  type_ranges contains information about the types, their distruibution and an object
	  for each type from a subclass of the Template class.
	  These subclasses are then called dynamically when ever a packet needs to decoded or 
	  encoded with injected data. 
	  
	  ** A word about how injecting data into 802.11 packets works in Bunny**
		802.11 is a complex, partially implemented, leviathan of a standard and thus we 
		can easily abuse that complexity to hide data within 802.11 packet types without any
		easy way to detect it.  
		This is done by selecting key fields of different 802.11 packet types that are prone 
		to chunks of psuedo random input.  Then breaking up the original message and stuffing
		it into these fields,  the revease is done to get the data out of these packets.
		To detect a bunny specific packet, each outbound packet is resized to match pre determined 
		pack_len % mod = remainder  values.  Then when looking for packet bunny just tests each
		packets length against the modulus and remainder values. (idea from: Optyx, KIS root kit)
		
	  
	- The Templates class is a super class that contains many subclasses, one (hopefuly) 
	  for each major packet type.  Each subclass contains the fields and decoding mechanizums
	  A subclass is instaciated for each detected packet type in the TrafficModel, when a
	  object is created it decodes the raw packet and stores a 'template' version of a packet
	  captured off of the 3 second capture window.  Each subclass also can decode and resize 
	  packets.

	Bunny order of operations upon start up goes as follows:
		1. create trafficmodel
		2. search for bunny packets
		   if other bunny instances found:
			1. send and recv packets in the mesh using the packet templates and distributions found 
			   within the trafficmodel

	When a packet is send, the data (including routing info) with be encrypted with AES256 then
	chunks of the packet will be injected into the packet types contained with in templates, but at
	distributions of packet types that match the model (EX: beacon packet 60% of the time, data 40%)
	A single bunny packet can be broken up into many different 802.11 packets.  Because of this, the
	meshing/routing layer will need to act like TCP to ensure delivery.