Past weekend was the 2022 version of the CQ World Wide RTTY DX Contest
and I participated. Not with any preparation: on Saturday after some other
tasks I sat behind radio and computer and looked up which set of macros would
work for this contest.
But propagation cooperated, especially on the 20 meter band. On Sunday evening
after dark I got a nice set of stations in the USA and Canada in the log. I
also saw a station from Brunei active but that station never managed to decode
my callsign while I tried for a quarter of an hour as this would have been a
new country in amateur radio for me.
I made 106 contacts in total: 70 on the 20 meter band and 36 on the 40 meter
band.
Officially the "Corinex CXWC-HD200-WNeH" cable modem is out of support for
years and deployments should have migrated to newer solutions. That is the
reason I got my hands on one: it was replaced by a docsis-based modem.
For as far as I can tell these modems are based on homepna or homeplug, over
coax networks (the tools on the router don't tell what kind of standards the
coax side uses).
I'd like to know if any of these are still used in the wild. If you find this
post because you got bored and looked at the underside of the wifi box in your
holiday park, get in touch!
My e-mail address is at the bottom of this page and I'm on twitter as
@khoos.
I have a DS2490 USB 1-wire interface on the home server conway which is
rerouted to one of the virtual machines so that that virtual machine can read
the sensors on the 1-wire network. This rerouting works when the machine is
started, the DS2490 USB 1-wire shows up in the virtual machine fine. From time
to time this DS2490 USB 1-wire interface gets confused when I am transmitting
on the radio so the solution is to detach it from the virtual machine, unplug
it from the server, plug it in again and attach it to the virtual machine
again. Today this had to be done and I got an unexpected error message:
root@conway:~# virsh attach-device --live gosper /etc/onewire-for-gosper.xml
error: Failed to attach device from /etc/onewire-for-gosper.xml
error: internal error: unable to execute QEMU command 'device_add': failed to find host usb device 2:8
In logfile /var/log/libvirt/libvirtd.log:
2022-09-24 21:16:38.655+0000: 10923: error : qemuMonitorJSONCheckError:395 : internal error: unable to execute QEMU command 'device_add': failed to find host usb device 2:8
To be complete about it: usb device 2:8 is exactly the right one!
root@conway:~# lsusb | grep 2490
Bus 002 Device 008: ID 04fa:2490 Dallas Semiconductor DS1490F 2-in-1 Fob, 1-Wire adapter
This seems to be new since I upgraded the homeserver to Devuan beowulf giving
me versions:
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture Descripti
+++-=====================================-===============-============-=========
ii libvirt-clients 5.0.0-4+deb10u1 amd64 Programs
ii libvirt-daemon 5.0.0-4+deb10u1 amd64 Virtualiz
un libvirt-daemon-driver-storage-gluster (no descr
un libvirt-daemon-driver-storage-rbd (no descr
un libvirt-daemon-driver-storage-zfs (no descr
ii libvirt-daemon-system 5.0.0-4+deb10u1 amd64 Libvirt d
ii libvirt-glib-1.0-0:amd64 1.0.0-1 amd64 libvirt G
ii libvirt0:amd64 5.0.0-4+deb10u1 amd64 library f
First idea: AppArmor
The first search result that came up was
Bug #1552241 “libvirt-bin apparmor settings for usb host device” : Bugs : libvirt package : Ubuntu.
So I tried changing the /etc/apparmor.d/abstractions/libvirt-qemu
file. After a few tries and reading the warnings in the rest of the file
I made sure the source was AppArmor by completely disabling it. The error
did not go away so I reverted the libvirt-qemu rules to the original settings,
restarted AppArmor and kept debugging.
Second idea: usb rights
Based on QEMU USB passthrough broken after Ubuntu 18.04 upgrade
I added udev rules to make sure group libvirt-qemu had read and write
rights on the usb device, with /lib/udev/rules.d/51-qemu-usb-passthrough.rules containing:
root@conway:~# udevadm test -a -p $(udevadm info -q path -n /dev/bus/usb/002/008)
calling: test
version 3.2.9
This program is for debugging only, it does not run any program
specified by a RUN key. It may show incorrect results, because
some values may be different, or not available at a simulation run.
[..]
GROUP 110 /lib/udev/rules.d/51-qemu-usb-passthrough.rules:1
MODE 0664 /lib/udev/rules.d/51-qemu-usb-passthrough.rules:1
handling device node '/dev/bus/usb/002/008', devnum=c189:135, mode=0664, uid=0, gid=110
[..]
Indeed the right groupid, but still the same error message when trying the
attach-device command.
Interesting find: it's specific to the virtual machine that had the device before
Small update: I can attach the USB device to a different host and detach it
from that host again. I just can't attach it to the 'original' host again.
I also posted this question on serverfault:
Can't live-attach a USB device to a kvm virtual host again after upgrades.
Update:
After a complete reboot of the homeserver the USB 1-wire interface worked
again (as I could imagine). But after another interference problem it's now in
the same state again. I did change the definition in both the virthost
configuration and the xml file from managed='no' to
managed='yes' before the reboot but that hasn't helped. Contents
of the /etc/onewire-for-gosper.xml file now:
Corinex CXWC-HD200-WNeH side with warrantylabel. The warranty was voided.
This week I was attending a course in hardware hacking: HackLab: Hardware Hacking
at the Deloitte office in Den Haag.
How to find the right pins to get a commandline on a router-like device was
part of this course, and the last day there was an option to Bring Your Own
Device, to hack it. So I brought this router as I thought it was an ideal
target to get access to it, since on the earlier try
I could not get into the webinterface of the Corinex CXWC-HD200-WNeH device.
Corinex CXWC-HD200-WNeH opened boards visible
So this time I took out the screwdriver, voided the warranty of the device by
breaking the little sticker on the side and opening it. It has a board with the
powersupply and cable interface parts. The powersupply is shielded with some
plastic.
There is a smaller board with the main chip which contains the processor,
ram, wifi module. The first task was to find the uart interface which should
give a serial console. That's a skill I learned in the hacklab: first find
out which pins have continuity to ground with the device switched off. With
a simple multimeter which has a beeping continuity meter this is simple.
The beep makes it possible to test the device without looking at the meter.
After that it's a matter of switching the multimeter to voltage and checking
other pins for voltage. Usually there are 4 pins on a uart port: ground
which is physically connected to the device ground, receive data and send
data and a reference voltage. On measuring the pins the reference voltage will
be at the steady maximum voltage, the data transmitting from the device will
be varying and the pin where the device expects data will be at 0 volt.
Uart ports can be 5 volt, 3.3 volt, 2.5 volt or 1.8 volt in recent devices.
5 and 3.3 volt are the most common. USB serial interfaces that support 5
and 3.3 volt are cheap (3 euro), USB serial interfaces that support all 4 are
somewhat more expensive (10 euro).
For the Corinex router the voltage is 3.3 Volt. There was a 3.3 Volt ftdi USB
to serial interface available, so I was able to access the uart port. I
connected to the uart port, used a terminal program and searched for the right
serial port settings and ended up at 57600 baud, 8 bits, no parity, 1 stopbit.
After looking at all the boot messages I was greeted with a root prompt. No
more hacking, just full access. The system boots using the U-Boot bootloader.
The system runs linux with a 2.6.21 kernel. I looked around on the filesystem
and started looking for the configuration for the webserver hoping to find the
username/password. I found this in /flash/config so I could get into
that interface as well.
I also found it was running a telnet server, but not on the standard port. The
port was 32560. Without commands like netstat or ss I had to
learn this from /proc/net/tcp. Browsing the iptables listing shows
that port 80 is supposed to be allowed and other ports aren't, but 32560 reacts
fine.
Chip found: Ralink RT3052F processor with embedded ram and flash and with
2.4 GHz wifi and a network switch for 1 gigabit port and 5 100 mbit ports.
Things I'd still like to do: copy the entire filesystem to another computer
so I can research it and check around the web interface for security issues.
I have a "Corinex Detachable Wireless-N Cable Access" Corinex CXWC-HD200-WNeH
to play with. This has been used for Internet access over TV coax cable in a
bungalow park where it has been replaced.
So it is some sort of cable modem. According to the source it's not managed
network over cable (docsis) but more like ethernet over cable, a relative
of ethernet over powerline. Searching a bit finds hempro | JPK consulting
which seems to be the next generation and isn't compatible.
I also found
Docsis, EOC of Moca toegepast in kleine kabeltelevisienetwerken which mentions that Corinex products are ethernet over cable according
to the HomePNA (abbreviated HPNA) 3.1 standard.
The only mention of these devices are for Dutch bungalow parks or campsites,
for example woon op een camping, open wifi. geen internet.
The site at corinex.nl just lists why you
should stop relying on these devices and replace them with newer technologies
that are supported.
It's not clear to me whether I can simply set up a network with a bit of
coax and another HomePNA coax interface or whether I need some sort of headend.
Time to play with the device and see how far I can get!
Ik kreeg vandaag een phishing mailtje gericht aan:
Cher(ère) client(e) Maes-Swerts/A.,
Votre abonnement Proxumis a été suspendu, car vous avez fait opposition
à un règlement de dette. Tant que le problème n'a pas été résolu, vous
ne pouvez utiluser aucune de vos services proxumis.
De resulterende pagina wil een credit-card betaling. Dus verzamelt gewoon
credit-card gegevens. Ik zou me bijna afvragen hoe snel er fraude komt als
ik daar echte gegevens invullen. Ik denk dat het in de orde van minuten is,
maar dat wil ik niet testen.
De spam voor 'Maes-Swerts/A.' is nu al meer dan 10 jaar bezig!
Eerder,
eerder,
eerder,
eerder,
eerder,
eerder,
eerder de originele ontdekking in 2012.
Our child plays minecraft regularly. The start was with the Microsoft minecraft
edition but recently the java edition became available too without paying
again.
I have set up the bedrock server for the Microsoft minecraft edition to make
it possible to play with other people outside the house. So the most recent
request was to do this for the java edition too.
I don't know much about minecraft but I can do enough with just some
websearching and finding a howto. So I started with
How to Set Up a Dedicated Minecraft Server on Linux
which seems to be a way to try to sell dedicated servers but I have enough
server hardware here at home so I just used the same virtual machine which
ran the minecraft bedrock server.
It turned out the default-jdk resulted in openjdk-11 getting
installed and this resulted in not being able to run the latest minecraft java
server. I switched to openjdk-17-jre-headless because I only need
the runtime and I never want to run the graphical stuff, so that saved a lot
in needed libraries and other overhead.
The server started fine, but the minecraft java edition couldn't connect to it
when trying to connect by name, but gave no usable error message. That's a
different rant. I checked on the server side and saw the listening socket in
dual-stack mode.
With tcpdump I soon found out the minecraft java edition starts with
the IPv4 address and gives up when that fails. The solution was to remove the
IPv4 address (A record) from the name, flush the dns cache and after that it
worked. This does mean that when friends want to connect that are behind
ISPs that only support legacy Internet addresses they will have a different
problem.
There are always attacks in the logs, but this one caught my eye because
someone mentioned it, I saw it in logs and searching for a simple explanation
for what I saw gave no answers.
Those are the interesting ones. So here is the logline split into multiple
parts in an attempt to make it more readable:
Searching for timepro.cgi finds a2004ns-mod/timepro.cgi at master · hklcf/a2004ns-mod · GitHub
which seems to be compiled code:
ELF 32-bit MSB executable, MIPS, MIPS-I version 1 (SYSV), dynamically linked, interpreter /lib/ld-uClibc.so.0, stripped.
Based on Honware: A virtual honeypot framework for capturing CPE and IoT zero days
my best guess is that requests to timepro.cgi attempt to reconfigure
a home router. And my next guess is that the attempt is to set the DNS resolvers
to 128.0.104.18 and 128.0.104.33. Further searching finds
another attempt from the same source IPv4 address which also looks a lot
like an attempt to reconfigure DNS settings:
The theory that this is an attempt to redirect DNS traffic is somewhat
confirmed by the fact that 128.0.104.18 indeed runs an open resolver
which will give me answers. For the few things I have tried those are valid
answers (no clear attempts to redirect traffic to other places). I get no
answers from 128.0.104.33 at the moment.
Update:
Searching for the string 128.0.104 finds more:
Past weekend was the 2022 version of the CQ World Wide RTTY DX Contest and I participated. Not with any preparation: on Saturday after some other tasks I sat behind radio and computer and looked up which set of macros would work for this contest. But propagation cooperated, especially on the 20 meter band. On Sunday evening after dark I got a nice set of stations in the USA and Canada in the log. I also saw a station from Brunei active but that station never managed to decode my callsign while I tried for a quarter of an hour as this would have been a new country in amateur radio for me. I made 106 contacts in total: 70 on the 20 meter band and 36 on the 40 meter band.
Past weekend was the 2022 version of the 
Ik kreeg vandaag een phishing mailtje gericht aan:
Cher(ère) client(e) Maes-Swerts/A., Votre abonnement Proxumis a été suspendu, car vous avez fait opposition à un règlement de dette. Tant que le problème n'a pas été résolu, vous ne pouvez utiluser aucune de vos services proxumis.De resulterende pagina wil een credit-card betaling. Dus verzamelt gewoon credit-card gegevens. Ik zou me bijna afvragen hoe snel er fraude komt als ik daar echte gegevens invullen. Ik denk dat het in de orde van minuten is, maar dat wil ik niet testen. De spam voor 'Maes-Swerts/A.' is nu al meer dan 10 jaar bezig! Eerder, eerder, eerder, eerder, eerder, eerder, eerder de originele ontdekking in 2012.
Ik kreeg vandaag een phishing mailtje gericht aan:
