Recover a compromised KiwiSDR [fixed]

edited January 2022 in Problems Now Fixed

Hi All,

I have a Beaglebone Green from Seed with a KiWiSDR which purchased and implemented about 3 1/2 years ago and worked fine for about two years on a public IP address, until it was compromised and my ISP threatened to disconnect me unless I shut it down for allegedly sending spam.

Due to various issues (family, work, Covid) I have only just got around to trying to resurrect it. Of course the SD card was lost, so I went to:

and did my variant of it because I was running on another Devuan 4 box (Devuan 4 is like Debian 11 but without systemd)

  1. I got the flasher script
  2. I ran the flasher script to fetch the .img file
  3. I watched the checksums verify
  4. I ran unxz on the xz image file to obtain KiwiSDR_v1.390_BBB_Debian_8.5.img
  5. I ran dd if=KiwiSDR_v1.390_BBB_Debian_8.5.img bs=4096 of=/dev/sdb to copy to a 32Gb micro SD card
  6. I ran fdisk /dev/sdb and verified that there was an sdb1 partition type Linux (83) size 1.4Gb
  7. I connected the BB Green/KiwiSDR on my "inside" private LAN, inserted the SD card, booted and there was activity
  8. Blue LEDs flashing, Ethernet flashing and after a period the device shutdown (all lights off)
  9. Removed SD card
  10. Re-powered the system, activity, device obtains IP address ( via DHCP

Device now seems to be stuck in a loop making connections to Amazon cloud via HTTPS and flashing the blue lights lights. I left it overnight and its still doing the same thing this morning.

Watching it on TCP dump shows:

root@xg115:/var/lib/dhcp# tcpdump -vv -i eth1 host
tcpdump: listening on eth1, link-type EN10MB (Ethernet), snapshot length 262144 bytes
10:58:23.671748 IP (tos 0x0, ttl 64, id 51250, offset 0, flags [DF], proto TCP (6), length 85) > Flags [P.], cksum 0xaca7 (correct), seq 711252822:711252855, ack 3263345502, win 1456, options [nop,nop,TS val 146628309 ecr 2017735728], length 33
10:58:23.761705 IP (tos 0x0, ttl 236, id 62378, offset 0, flags [none], proto TCP (6), length 83) > Flags [P.], cksum 0x971d (correct), seq 1:32, ack 33, win 132, options [nop,nop,TS val 2017826711 ecr 146628309], length 31
10:58:23.762823 IP (tos 0x0, ttl 64, id 51251, offset 0, flags [DF], proto TCP (6), length 52) > Flags [.], cksum 0xc948 (correct), seq 33, ack 32, win 1456, options [nop,nop,TS val 146628332 ecr 2017826711], length 0
10:58:28.950303 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has tell, length 28
10:58:28.951959 ARP, Ethernet (len 6), IPv4 (len 4), Reply is-at 44:d5:cc:49:d5:f1 (oui Unknown), length 46
10:58:42.179436 IP (tos 0x0, ttl 220, id 37007, offset 0, flags [none], proto TCP (6), length 86) > Flags [P.], cksum 0xb863 (correct), seq 317337024:317337070, ack 554006657, win 748, length 46
10:58:42.180890 IP (tos 0x0, ttl 64, id 56180, offset 0, flags [DF], proto TCP (6), length 86) > Flags [P.], cksum 0x10da (correct), seq 1:47, ack 46, win 1643, length 46
10:58:42.202894 IP (tos 0x0, ttl 220, id 37008, offset 0, flags [none], proto TCP (6), length 40) > Flags [.], cksum 0x31f9 (correct), seq 46, ack 47, win 748, length 0

Here's a video of it going round in circles:

What do do next?

Mike G8TIC


  • More info ... if I scan it with nmap it has a couple of ports open but no SSH, no HTTP, no HTTPS and port 8073:

    root@xg115:/var/lib/dhcp# nmap -sS
    nmap -sS
    Starting Nmap 7.80 ( ) at 2022-01-08 11:36 GMT
    Nmap scan report for
    Host is up (0.013s latency).
    Not shown: 958 filtered ports, 40 closed ports
    1080/tcp open socks
    8888/tcp open sun-answerbook
    MAC Address: 44:D5:CC:49:D5:F1 (Unknown)
    Nmap done: 1 IP address (1 host up) scanned in 20.77 seconds
  • edited January 2022

    What happens if you reset or power cycle it? (Reset button is the outer one by the blue leds)

    (yeah I did just suggest turning it off and turn it back on again)

    Seriously though, does it get to the exact same condition?

    The ethernet LEDS suggest it is passing some data, what connections does it have open?

  • OK a quick guess having just port scanned mine (just 22 and 8073 open) the image write perhaps was not successful and it is still running the old install.

    I'd concentrate on the board, remove the Kiwi cape. Then get a base Debian install for the Beaglebone Green, see if it installs and runs OK then load KiwiSDR from github. I'll have a go here as I've not done it for a while and am not sure how recent a Debian will work.

  • I'd bet that 144.122 is not really the Kiwi's ip address. The video shows the standard Kiwi server LED pattern which does contain the ip. Can you decode it using the instructions here?

    Ports 1080 and 8888 should not be open which is even more suspicious.

  • jksjks
    edited January 2022

    If you enter that MAC address (44:D5:CC:49:D5:F1) into a site like it comes back "Amazon Technologies Inc." So this device is actually something like an Amazon Alexa 🙄

  • edited January 2022

    That makes much more sense.

    If you can read the Kiwi serial (2165 ?) could you see if shows it coming up (if enabled).

  • jksjks
    edited January 2022

    Good catch Stu. That Kiwi serial number has a local ip of updated Jan 8 11:35 UTC (I can tell this because I'm able to look on the server where the info is stored).

  • Gents,

    Thanks for the help ... its my fault!

    The KiWiSDR serial is 2165 and it does appear to have re-flashed and recovered as intended.

    I had written on one bit of paper, and on another bit of paper for something else to do with a problem with an Alexa device.

    It was late last night and I had a bit of a brain fart.

    Mike G8TIC

  • Mike, good to hear.

  • The SDR is now running on 2m with a 116MHz offset.

    This time its behind my firewall, but I've gone one further and implemented an Nginx reverse proxy so that it is accessible over HTTPS on the normal port 443.

    You can find it here:


Sign In or Register to comment.