
Steganographic Packets - NullUsr
https://vimist.github.io/2019/01/30/Steganographic-Packets.html
======
jwbensley
This is nothing new. This is a form of covert channel:
[https://en.m.wikipedia.org/wiki/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](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.

~~~
NullUsr
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](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.

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

[0] [https://www.torproject.org/docs/pluggable-
transports.html.en...](https://www.torproject.org/docs/pluggable-
transports.html.en#list-of-pts)

------
brad0
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.

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

------
LinuxBender
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.

~~~
NullUsr
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!

~~~
gpm
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](https://www.torproject.org/docs/pluggable-
transports.html.en)

~~~
egberts1
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.

------
egberts1
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.

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

------
detaro
Messing with packet sizes could also be an option?

~~~
egberts1
No need to.

~~~
detaro
No, but additional space to fit more bits.

