Skip to content
Branch: master
Find file Copy path
Find file Copy path
Fetching contributors…
Cannot retrieve contributors at this time
80 lines (67 sloc) 4.56 KB
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
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.
You can’t perform that action at this time.