The new homeserver 2017 has arrived and I'm working on installing it. But first I had to do my first 'casemod' which was just rerouting a few cables. The case comes with a fan control, but I want all fan control to come from the mainboard and monitor the fans from the operating system. So I disconnected the fans from the case fan control and reconnected them to fan connectors on the mainboard that allow for voltage based fan control and monitoring.

The case is a bit overkill, but looks really good and offers lots of routes for airflow. New to me was that the case has cableguides which allow it to look really nice internally and have really good airflow. So I used those cableguides when I rerouted the fan cables and even tie-wrapped the cables to keep them looking nice.

I saw someone post somewhere about problems with sending mail, with the complete session log. E-mail addresses were obfuscated, but there was a part of the session not obfuscated, which had far more interesting secrets than just e-mail addresses. It looked a bit like this:

250-HELP
250-AUTH LOGIN PLAIN
250-SIZE 157286400
250-8BITMIME
250 OK
AUTH LOGIN
334 VXNlcm5hbWU6
dXNlcm5hbWU=
334 UGFzc3dvcmQ6
cGFzc3dvcmQ=
235 ... authentication succeeded
RSET
250 OK

Those "random" letters and digits look a lot like base64, so to decode them:

$ echo "VXNlcm5hbWU6" | base64 -d ; echo
Username:
$ echo "dXNlcm5hbWU=" | base64 -d ; echo
username
$ echo "UGFzc3dvcmQ6" | base64 -d ; echo
Password:
$ echo "cGFzc3dvcmQ=" | base64 -d ; echo
password

So the random letters and digits are actually username and password, very interesting information. Searching for VXNlcm5hbWU6 gives me examples of usernames and passwords.

And a third night. I used the timed recording option of audacity, which in the current linux version does not offer the option to set in advance how to save the project. This time I 'only' recorded for 7 hours, and was able to save the project afterwards without needing a recover. But on reloading the saved project audacity complained about some internal error in it, and it still had the problem of assuming 44.1 kHz sampling while showing the project sample rate as 48 kHz. Anyway, images decoded from the audio and I even recieved a few new ones.

On doing some research on randomness in Linux I found out about the rng-tools package which includes rngd which can get randomness from hardware random generators to linux /dev/random.

On the main homeserver greenblatt there was no hardware randomness source available, I already use randomsound to generate randomness from audio noise. I found out the Raspberry Pi has a hardware randomness source so I installed rng-tools and rngd was able to use it. The impact on the measured available entropy is quite visible.

On the night from Friday to Saturday I had the whole setup ready to receive more ISS SSTV images. And nothing was received since I had the antenna unplugged during Friday because of thunderstorms and forgot to plug it back in.

So when I found that out I put a note on my desk with 'Antenna unplugged?' which can be a reminder to unplug it when I'm done or plug it in when I want to receive something.

On the night from Saturday to Sunday I plugged the antenna in and let the whole setup run again like on the earlier run on Friday Received slow scan TV images from ISS while I was sleeping. To make sure I had the antenna plugged in I tuned to 145.750 MHz where I can hear a distant repeater faintly.

Again audacity hung after the recording, and this time on recovery it had some issues with the saved project. At first I could see and hear audio of SSTV passes but qsstv could not decode anything. In the waterfall display of qsstv it looked like the frequencies were too low. I had a thought that maybe something decided the samplerate was back to 44.1 kHz so I simply speeded the audio of an image pass up by 8.8435% and suddenly it decoded fine.

In the end I decoded 11 images from the ISS SSTV project. Numbers seen 8, 10, 9, 6, 7, 8, 6, 4, 5, 6.

And 2 images from nearby radio amateurs who weren't operating according to the bandplan... but at least did not interfere with the ISS SSTV transmissions.

I read about the current ARISS Celebrates it’s 20th Anniversary through SSTV Event and noticed the planned times weren't really compatible with my day/night cyclus. I know, as a hardcore radio amateur I should be up at the weirdest hours for rare events but I also like my sleep a lot and my wife really dislikes alarms at weird hours.

Automation to the rescue: I decided to record all of a night of ISS signals on the computer with audacity and decode images from it later. The computer adjusted the radio for doppler using gpredict. Since I don't have an automatic rotor for satellite antennas I used the VHF/UHF vertical. This may seem strange but the weakest signals from ISS are when it is right above the horizon (which is when the vertical has the best reception). And as noticed on earlier SSTV events that compared to other amateur satellites the ISS has a strong signal.

So I left it running for a night and checked the results afterwards. The result was a 9 hour recording and audacity decided to hang after stopping the recording. I made a backup copy of the audio data just to be safe and restarted audacity. Luckily it recovered the project fine after restarting.

With a recent version of qsstv I decoded the recorded audio and searched for ISS passes in the recording.

The result is 13 decodes in one night. It turns out it received audio from a number of low passes that I did not see in gpredict because I have gpredict set up to skip low passes (those that don't come above a 20 degree angle above the horizon). But the strong signals from ISS make those show up in my radio anyway.

Decoded and seen the numbers sofar: 11 (partially), 12, 9, 10, 9, 10, 9 (partially), 9, 7, 8.

E-mail with subject starting with "Please find attached our purchase order number" and a zip, with a zip in it with in that zip an .exe file.

Archive:  PO185 - 188207 X.zip
  Length      Date    Time    Name
---------  ---------- -----   ----
   341805  2017-07-19 04:55   PO362 - 867977 X.zip
---------                     -------
   341805                     1 file

Archive:  PO362 - 867977 X.zip
  Length      Date    Time    Name
---------  ---------- -----   ----
   431458  2017-07-19 15:32   PO362 - 867977 X.exe
---------                     -------
   431458                     1 file

I guess the .exe will cause some serious damage in Windows operating systems. The size is huge, where is the time virus writes tried to stay below 1024 bytes!