Bad Apple!! but it's traceroute — jssfr.de
Bad Apple!! but it's traceroute
As a follow-up to<br>my post about how to make traceroute tools show arbitrary content<br>and inspired by<br>the release of another Bad Apple cover the other day<br>I simply had to.
Of course, I'm<br>not the first one to do this.<br>That couldn't stop me though.
How it works
In the post I linked above, I had demonstrated how to inject fake hops into<br>traceroute output.
Using the numgen feature of nftables,<br>we can make the hops vary every time an ICMPv6 packet is generated.<br>numgen gets us either random numbers or a monotonic counter. With a counter,<br>we can easily make each hop return a different IPv6 address each time a<br>response packet is generated. Using<br>the playground from the other post:
ip netns exec tracemess nft -f -<br>Two other things were needed to make this happen. First of all, we need to<br>disable the kernel's rate limit (by default, 1/s) for ICMPv6 egress<br>using sysctl net.ipv6.icmp.ratelimit=0, otherwise the party will be over<br>really quick.
The second problem is that mtr will normally show multiple addresses for each<br>hop, because that indicates that multiple different paths are in use for a<br>packet and that is normally useful information. In this case, however, that's<br>rather annoying:
In order to fix that, we have to apply a one-line patch1 to<br>mtr2:
diff --git a/ui/net.c b/ui/net.c<br>index c0cbf28..7c52710 100644<br>--- a/ui/net.c<br>+++ b/ui/net.c<br>@@ -266,6 +266,7 @@ static void net_process_ping(<br>break; /* Found first vacant position */<br>+ i = 0;
if (found == 0 && i addrs[i], &addrcopy, sockaddr_addr_size(sourcesockaddr));
With all this in place, I used ffmpeg to resample the video to<br>8 frames-per-second (which equates an interval of 125 ms between frames) and<br>export scaled-down (to 30x11 pixels) individual frames to PNG files. I<br>then wrote a python script to read the image files and convert them into an<br>nftables ruleset to generate the corresponding ICMPv6 responses.
That results in a bit over a megabyte of nftables rules, but it's definitely<br>worth it.
Why?
The<br>shadow art Bad Apple music video<br>has become the benchmark for hacked displays, for<br>a very loose definition of "display",<br>similar to how running Doom (the 1993 video game)<br>has become the benchmark of gaining code execution on a new hardware platform.<br>I suspect the reason for that is that, due to its shadow art style, the video<br>can be rendered even on "displays" which only have one bit per pixel (on/off).
There is<br>a subreddit dedicated to<br>showing off the kinds of devices people have gotten Bad Apple to display on.<br>My favourite would at this point be<br>this hack abusing a HD47780-compatible character LCD,<br>simply because I enjoy hacking these devices, too3. There's also<br>more than<br>one compilation video showing multiple versions.
Considering that … I simply had no choice, did I?
Comments are welcome in the Fediverse thread for this post.
Instead of patching mtr, one could also use a shell loop<br>wrapped around traceroute. That doesn't need patching, but is barely<br>less cheating than the one-line patch to mtr. ↩
mtr does allow to limit the number of addresses shown<br>per-hop (the -E flag), but it then always displays the first address.<br>That means we get a freeze-frame of the first frame of the video ☹️. ↩
Though I cannot decide whether<br>this thing where people redrew the video on a shared online canvas<br>or this thing with an autostereogram<br>should be second place in my personal ranking. ↩
jssfr.de homepage<br>legal / contact
English<br>Deutsch
UberBlogr Webring>