Steganographic Packets | Hacker News Reader

Steganographic Packets

vimist.github.io

46 pointsNullUsr15 comments

This is nothing new. This is a form of covert channel: https://en.m.wikipedia.org/wiki/Covert_channel

Specifically from the Wiki artical see the Timing Channel section.

Another interesting concept is to hide the bits in the unused options in protocol header fields (see the "Data hiding in TCP/IP Protocol suite by covert channels" section on the same Wiki artical).

I was looking for example code snippets online and found some examples of hiding bits in packet headers but, not in inter-packet timings. I ended up writing a transmit and receive script one afternoon at my desk out of boredom (although, just as a proof of concept to myself, I didn't take the time to refine to the superior levels of the OP, such as bit rate or reliability, as I never intended to use it): https://null.53bits.co.uk/index.php?page=icmp-messages

It would be nice to combine the technique used in some header-bit-packing scripts with the OPs timing based script; whereby one specifies the destination IP we want to communicate to secretly and alter the buffering of packets only to that IP. I never bothered to refine my scripts beyond "Hello World" because the timing based approach requires one to generate traffic that possibly otherwise wouldn't exist between the source and destination IP. Encoding bits in the inter-packet delay of existing "legitimate" flows to the destination would require it to be relatively close in terms of latency.

Not sure if you spotted the links in the post itself, but there's a working (basic) proof of concept here: https://github.com/vimist/packet_differential_encoding

Boyan commented on the post itself suggesting applying coding & modulation theory, which I thought was an interesting point.

For more like this, see pluggable transports [0] from tor.

[0] https://www.torproject.org/docs/pluggable-transports.html.en...

Would this work over a long connection? Say to the other side of the world?

Network delays would mess this up afaik.

I suppose you could introduce a error correcting code in it but that would kill your throughput even more.

Delays in pulse width modulation are easily overcome with lower bandwidth and/or error correction coding: a function of Shannon’s limit.

This is very clever. I hope the author continues to work on this. This could be very useful where speech is censored and encrypted streams are blocked.

Thanks. I hadn't really given much thought for any widespread practical use. I think the throughput would be the limiting factor, on average (using my encoding scheme, which could definitely be optimised) you average about 5.882 Bps. Would definitely be interested in hearing what uses people see for it though!

The first thought that comes to mind is Tor's pluggable transports used to bypass censorship.

Admittedly 6Bps isn't good enough for that (I think), but it might be possible to combine it with other mechanisms or increase that number?

https://www.torproject.org/docs/pluggable-transports.html.en

While TOR represent the worst kind of the variances of inter-packet delay of all network topology, the devil in the details is compensating for the largest “single-hop”-like variance.

Ummm, think of those dedicated phones between two ATM switches in the old days.

The real art is being able to decipher these pulse-width modulated packets across multiple hops (and switches) while factoring in the variances Of traffic flow that surges through each hops.

That’s why we have waterfall defense against these kind of offense, oh wait. No, really, it is a 25yo solved problem, non-academically.

Messing with packet sizes could also be an option?

No need to.

No, but additional space to fit more bits.

Reply on news.ycombinator.com