Looping AIs (Siri, Alexa, Google Home)

There are plenty of videos showing how to trick Amazon Echo (Alexa) and Google Home into an infinite loop. Some folks used calendar entries, others rely on the good old Simon says trick. Since we share our realm with at least four AIs (that we know of), my wife and I decided to level up in the looping game.

It turns out, there are quite a few challenges to overcome when you want to integrate Siri or Cortana into the loop. Let’s start with a summary video. Skip to the end to see the outtakes 😅

Basic Idea

The basic idea is to make one AI say something that triggers the second AI to say something that triggers the next AI and so on… We used calendar events and notes. Mostly because you can easily manipulate them while the experiment is running. This also makes for a great game: Manipulate the AIs’ conversation without any human speaking. Just cloud data manipulation. It’s harder than one may think!

Training Siri

Siri has a cool feature: She doesn’t listen to everyone. To use Siri, one has to make her accustomed with ones own voice. This is done by speaking pre-defined phrases like “Hey Siri, how is the weather today?” Luckily, those phrases are not randomized but stay the same for every training session. I see an attack vector there. 😬

To make Google Home say the golden phrases we created an calendar event with the phrases as title. Unfortunately, Google Home speaks to fast (or computer-ish?) for Siri to catch up. We figured out that adding dots or commas slowed Google Home down a bit. At least enough for Siri to catch up.

Another caveat we found is, that Google Home loves to truncate long calendar event titles. We had to change the event title for every step of the training process. That was tedious and we tried several times until Siri was trained well. One time, we accidentally trained her to the phrase “HeySiri HeySiri”. 😂

This is how the calendar entry looked like:

Listening into the past

We discovered that Siri likes to listen into the past. When we made Google Home say something like “You have one appointment and the title is: Hey Siri…“, Siri would not start listen at the phrase “Hey Siri” or after the phrase “Hey Siri” but also grab a couple of phonemes from earlier to the activation phrase. Sounds scary, but what do we expect from an always-listening AI, right?

Trivia: Look at what time the screenshot was taken. Coincidence, I promise!

Training Cortana

We were not able to train Cortana, she would not listen to an artificial voice. It may be that the microphone wasn’t perfect on the laptop we used. Maybe Microsoft did very well on Cortana’s recognition algorithms and/or artificial neural networks. Since we were in a hurry, we threw Cortana out of the race. We leave this fruit hanging for someone else to grab it.

Note Yep, I am calling these things AI all the time. That is for convenience, I do know quite a bit about AI, natural language processing, machine learning and artificial neural networks. And I do know these gadgets are merely ANI (Artificial Narrow Intelligence) and far from AGI (Artificial General Intelligence) or what some may call strong AI. Still, I like to anthropomorphize and call them my AIs.

How to configure a WireGuard tunnel on OpenWrt using LuCi

[Update April 2017: I noticed people are still building configurations based on this outdated blog post. The way wireguard addresses interfaces in OpenWrt/LEDE has changed. Please consult a more recent blog post on the topic!]

A couple of months ago I worked on a concept for a sophisticated, IPv6-only overlay network spanning multiple sites and various devices. It is part of a a long-term project, which means assessing not only current, but also future protocols was suitable. The WireGuard cryptokey routing protocol was one of the candidates. The more I work with this still experimental protocol, the more I am convinced that this will become one of the major VPN protocols. It is lean and clean, easy to configure and exceptionally reliable. Furthermore, it seems to be very secure. But as a word of warning, I am less of a cryptography auditor and more of a programmer and network engineer.

I do believe in WireGuard and had the luck to participate in the project by contributing documentation and regularly testing the snapshots. It is a small, agile (BS Bingo!) and responsive group. The development speed is amazing and the head developer probably never sleeps 😮

Today I’d like to show you how to configure a WireGuard tunnel using OpenWrt/LEDE and luci-proto-wireguard. I developed luci-proto-wireguard during the past weeks as a side project. With the help from beta testers and experienced OpenWrt folks, the code matured and now awaits merging into the official repositories.

For this howto I assume you run the latest snapshot of, let’s say OpenWrt. I will also assume that you have a basic understanding of WireGuard.

First step is to create the WireGuard interface. Go to the Interfaces page and create a new interface. Select WireGuard VPN in the dropdown menu. If this option does not show up, then you are missing luci-proto-wireguard 💩. Head over to Software and install it.

Think of good name for the interface, in this article we will proceed using foo 😬 Next thing you will see is the interface configuration page. I tried to make it as self-explanatory as possible by including helpful hints below the options. Most important configuration data are the Private Key of the interface and the Public Key of at least one peer. Also, don’t forget to add the network or address of the other end of the tunnel to Allowed IPs. Otherwise the tunnel won’t work as expected.

If you like to add some post-quantum resistance, you can do so in the advanced tab.

In the firewall tab, you can create a new zone or assign the interface to an existing zone. I recommend doing this after the device is set up and working.

Click Save and Apply once you are satisfied.

Now you should have a WireGuard tunnel interface, but it has not been assigned an IP address yet. I wanted to allow a wide range of setups and enable everyone to do even the weirdest things with their routers. So I removed the direct addressing feature that I was implemented in an earlier version. Luckily, you can create a static configuration on top of foo by creating a new device and selecting Static address as protocol.

It is important to select foo as the underlying interface, either by finding it in the interface list, or, if it does not (yet) show up there, by typing @foo into the custom interface field.

Voilà! We now have the standard static addressing page. Configure according to your VPN concept and hit Save and Apply to proceed.

You should now see both interfaces in your interface list. I recommend putting them into the same firewall zone for easier administration. You can tell that I moved them into the same zone from the color of the interfaces. Interfaces foo and bar share the same firewall zone color.

I’d like to add some monitoring, but that isn’t ready yet. In the meantime, you can check on your WireGuard interface(s) using wg on the command line.

If you find any bugs, please report them. Thanks for reading and happy cryptokey routing everyone!

Hint On some devices it may be necessary to restart the device after after installing luci-proto-wireguard, so that the netifd daemon correctly loads the helper script that comes with wireguard-tools. Thanks Stefan for pointing this out!

Update (July 2018)

I receive quite a few emails on the topics of OpenWrt and WireGuard every week. Unfortunately, I do not have the time to answer all of them individually. So I kindly ask you to direct questions regarding WireGuard and OpenWrt/LEDE to the OpenWrt Forums or to the WireGuard Mailing List. There the questions will be exposed to a wider audience and may additionally help other people facing the same challenges. Thank you!

Additional antennas for Turris Omnia

In an earlier post I mentioned the rather disappointing wifi signal strength of my Turris Omnia. Other users reported similar issues, so it looks like I am not the only one suffering. To put things into perspective: My router’s signal strength is about 75% compared to the previous COTS device (100%). Clearly, we are talking about #FirstWorldProblems here. 😢

It is still unclear why some devices remain under expectations.

  • Is it a hardware issue? Or software?
  • Is it the driver blob?
  • Is there a problem with the connectors?
  • Are the antennas broken?
  • Could it be an issue with the two pre-antenna filters?
  • Why are both bands affected?

I wanted to rule out antenna and connector issues to help the community find the problem. The idea is to replace the filters, stock antennas and stock HF cables. So I went on a shopping spree and bought five dual-band antennas with 5dBi gain and corresponding HF pigtails.

Two filters are connected upstream of the antennas on the left and right (red circles). The third antenna in the middle is directly connected to the 2.4GHz wifi card.

I replaced the filters and the gray stock HF cables. Each antenna is now directly connected to one of the wifi cards via pigtail. I also replaced the stock antennas, to refute the broken antennas theory.

No special tools were needed, there were already five SMA holes in the case.

And now the most important piece of information: Did it work? Unfortunately, no, I have not seen a significant improvement of signal strength, regardless which band I looked at.

At least we now know that a hardware issue including the antennas or filters is less likely. The quest continues… 📶❓