mothran

Very good points. I did some benchmarks a while ago and found the the decode routines (un-optimized) were some of the slower pieces of code in round trip life of a packet. But with some work it could be done.

> But as it stands (MODULUS = N.NN, REMAINDER = 0.NN) only has 5 decimal digits = 16 bits of entropy. Bunny traffic could be identified after observing just a handful of packets (not even knowing the actual values for M and R).

Very true, I will add this to my TODO list, thanks.

No problem man, if you get it working on your hardware that is not listed in the README, please tell me. I would love to keep a easy to find list of supported chips.

Hmmm I like this trick, but that means I would have to process and decode each 802.11 as is comes in. It would create quite a bit of overhead for each packet.

Maybe I am mis-understanding you. Where would you put the MAC data in a packet? would in be broken up or just stuffed in to a single location for each packet?

Ok so the code is a bit weird in that section because of issues with different wifi chipsets (thus the -4). Sorry about the messy code, I would barely call Bunny alpha.

The mod/remainder values are agreed upon by the network operators, that is why they are in config.

The length % mod == remainder trick for detecting packets was inspired by the KIS rootkit in the later 90's. http://packetstormsecurity.com/files/25029/kis-0.9.tar.gz.ht...

Spot on.

Yes, that is high on my list to fix.

The crypto is super simple currently. I have spent a long time trying to figure out a better solution but currently there is a single round of AES-256 in CBC mode, each message gets a random IV.

To answer the first questions from this, 1) yes I know there is no MAC I am working on that and could use some ideas 2) forward security is not built in, but if you can find a quicker way to renegotiable mpOTR we might be in business.

Any feedback would be great, I would really like to improve Bunny to be more solid in its use of crypto.

Bunny basically sends raw packets are that build around a model of 802.11 packets that it has seen. It spoofs all the fields and then injects little bits of data into certain 802.11 fields that are rarely used or have someone random data when they are. So this means that bunny is essentially a ad-hoc style network that hides is traffic to look like whatever wifi networks are around.

It could be modified to detect both ends of the mirror devices. I would warn against trusting that model of the GFW because devices are not all placed at the inbound international connections. I have found that most devices are deployed farther down the network chain into the regional level last 10-100 miles ish. For example I have detected a GFW mirror or device in Tibet.