[ antoinealb.net ]

Automatically restarting an IKEA TRÅDFRI gateway

2019-08-10T00:00:00+00:00

So I got myself a set of connected light bulbs for my living room. Based on review, I decided to go with the IKEA models, as they are pretty inexpensive and provide good quality lighting. I also decided to have a gateway, which allows you to control your lamps from your LAN and provide additional functions like lamp groups. The gateway also offers an API so I figured it could be a fun thing to hack with.

In the beginning, everything seemed fine, and controlling the lamps from the smartphone was nice. However after a while, the lamps seemed to become less responsive, sometimes missing commands. The app would also have problems connecting to the gateway. Some research led me to a GitHub issue where somebody said that “the gateway needs restarting every 1-2 days”. And indeed, rebooting the gateway solved the issues I was facing.

The gateway API includes a remote reboot command which we should be able to use to avoid turning it off and on by hand. I did a quick experiment using the command found in the above GitHub issue to confirm the API worked as expected, and confident enough, decided to automate this.

My initial plan was to use my router to host the automation for rebooting the gateway, to avoid adding complexity. However, it turns out compiling custom software on pfSense is more complicated than expected. I was already spending more time than I wanted on this so I decided to pull my Raspberry Pi out of the drawer and hook it up. Maybe one day I will take some time to package the solution for pfSense, but we all know how temporary solutions end up…

I will assume you have an up to date version of Raspbian installed. Plenty of blogs on the Internet cover this up already.

The gateway communicates using a protocol called CoAP, which is a lightweight RPC protocol with semantics resembling HTTP. An open source implementation of this is libcoap, used by a Python API for the IKEA modules. We will install it from source using the following commands:

sudo apt-get install build-essential autoconf automake libtool
git clone --recursive https://github.com/obgm/libcoap.git && cd libcoap
./autogen.sh
./configure --disable-tests --disable-documentation --enable-examples --with-tinydtls --disable-shared --prefix=/usr/local
make && sudo make install

We can install Python and the API:

sudo apt install python3 python3-pip
pip3 install pytradfri

We will now write a simple script that takes the security key, authenticates with the gateway and asks it to reboot. Place the following in /usr/local/bin/reboot_tradfri.py and make it executable with chmod 755 /usr/local/bin/reboot_tradfri.py.

#!/usr/bin/env python3
"""
Reboots a IKEA Tradfri gatetway.

This can be used from a crontab to avoid a memory leak in the tradfri firmware.
"""

from pytradfri import Gateway
from pytradfri.api.libcoap_api import APIFactory, retry_timeout
from pytradfri.error import PytradfriError
from pytradfri.util import load_json, save_json

import uuid
import argparse
import json

TIMEOUT_SECONDS = 40


def parse_args():
    parser = argparse.ArgumentParser(description=__doc__)
    parser.add_argument('host',
                        metavar='IP',
                        type=str,
                        help='IP Address of your Tradfri gateway')
    parser.add_argument('--key',
                        '-k',
                        required=True,
                        help='Security code found on your Tradfri gateway')
    parser.add_argument('--config',
                        '-c',
                        required=True,
                        type=argparse.FileType('a+'),
                        help="Path to the configuration file. Will be created if it does not exist.")

    args = parser.parse_args()

    if len(args.key) != 16:
        parser.error("Security key must be 16 char long")

    return args


def load_identity(config_file):
    config = json.load(config_file)
    return config['identity'], config['psk']


def save_identity(config_file, identity, psk):
    conf = {'identity': identity, 'psk': psk}
    config_file.seek(0)
    config_file.truncate()
    json.dump(conf, config_file, indent=2)


def main():
    args = parse_args()

    args.config.seek(0)

    try:
        # Try to load a pre-existing shared key from the configuration file
        identity, psk = load_identity(args.config)
        api_factory = APIFactory(host=args.host, psk_id=identity, psk=psk, timeout=TIMEOUT_SECONDS)
    except (KeyError, json.JSONDecodeError) as e:
        # We could not load the preexisting key, generate a new one and
        # associate the gateway with it.
        print("Generating new identity & PSK")
        identity = uuid.uuid4().hex
        api_factory = APIFactory(host=args.host, psk_id=identity, timeout=TIMEOUT_SECONDS)
        psk = api_factory.generate_psk(args.key)

        save_identity(args.config, identity, psk)

    api = retry_timeout(api_factory.request, retries=10)

    gateway = Gateway()
    api(gateway.reboot())


if __name__ == '__main__':
    main()

You should now be able to reboot your Gateway by running the command below. Check that it worked by observing the status LEDs on the gateway itself. Make sure to replace $SECURITY_CODE with the string you can find on the back of your gateway, and $IP with its IP address.

reboot_tradfri.py $IP -k "$KEY" -c ~/tradfri_identity.json

Note: tradfri_identity.json does not exist at this point, but the script will create it and save the pre-shared key in it.

Finally, we will reboot the gateway each morning at 5 AM. At this point everybody should be asleep and not using the lights so it should not create any issues. We will use Cron which is a system used to schedule periodic jobs on UNIX systems. You configure it using a file called the Crontab, and you can read how this file works by doing man 5 crontab. Append the following to the crontab by running EDITOR=nano crontab -e, which will open an editor to modify your cron job definitions. Once you exit the editor, cron checks the syntax of the file and installs the new jobs if the config is valid.

0 5 * * * PATH=$PATH:/usr/local/bin && export PATH && reboot_tradfri.py -k KEY -c ~/tradfri_identity.json IP

Your gateway should now reboot everyday automatically, and keep working for a long time. It is a bit annoying to have to do that kind of workarounds for a commercial product. I would love either a fix from IKEA, or a way to deploy this on my pfSense box.

But for now, I can move on to other stuff!

Test your external dependencies

2018-04-12T00:00:00+00:00

In the unit testing crowd your often hear the mantra that you should not test your external dependencies with unit tests and that they are only for integration testing. In a way this makes sense: the developper of the library probably took some time to test the library on their own, so why redo the work? However, I like to write a few unit tests when I am integrating a new library into a project. Most of the time I even commit them to the source repository and add them to the CI build.

For sure it takes much longer to integrate the library now. You have to write some tests, and you may have to code some mock objects as well. However, I find this investment in time well worth it, for two main reasons:

First, it gives you a better understanding of the API of your library. You can clearly see how the library works, which expectations it has. With mock objects you can also inject faults and see how the code reacts. In fact, I had the idea for this blog as I was integrating a library I used before in a new project. It took me so long to debug a weird issue, but when writing a test, it quickly became clear that I just forgot a step in the initialization of the library.

Second, it can be used as a future reference (or cheat sheet) by you and your team. This is why I add the tests to the repository: to make sure they will be available when I forget how to do a given operation.

Finally, once your test suite is in place, it becomes easy to prototype new interactions with the dependency. Just write tests for this new use case and see if it works. This is also useful if you ever have to fix a bug in the library: you can try and reproduce it in your familiar testing environment.

Happy testing!

Measuring program performance with perf(1)

2018-02-23T00:00:00+00:00

In my new internship I am working on optimizing some software. But before starting making changes to the source code, I need to make sure that I am optimizing important parts. Imagine for a moment that I spend days making one part of a program go 10x faster (!!), only to realize later that it is responsible for 1% of the total run time. How much would I have saved? The answer is not much: the new run time would be 99% + (1% / 10) = 99.1% of the original run time. In other words, only 1.01 times faster. Not so impressing now, is it?

This post will introduce one method to measure how the program is spending its time. This is known as profiling the code. I learnt a lot of techniques from my colleagues, but also a lot comes from Chandler Carruth’s talk at CppCon 2015. Go watch it if you want more information than what I expose here.

Sample program to profile

For those experiments we will need a small program to profile. I wrote a simple program (see below) that computes the Fibonacci sequence and displays it. I know that this is not optimal in any way, but we will see how.

#include <vector>
#include <iostream>

#include <benchmark/benchmark.h>

static void Benchmark_Fibonacci(benchmark::State& state) {
    const int N = 200;
    for (auto _ : state) {
        std::vector<int> v;

        v.push_back(1);
        v.push_back(2);

        for (int i = 1; i < N; i++) {
            v.push_back(v[i] + v[i - 1]);
        }

        benchmark::DoNotOptimize(&v);
        benchmark::ClobberMemory();
    }
}
BENCHMARK(Benchmark_Fibonacci);

BENCHMARK_MAIN();

We can now build this program using g++ benchmark.cpp -o fibo && ./benchmark. No output is produced, but the suite is computed, so it is time to measure what takes some time.

Now that this is done, we can run the program with the perf utility (found in linux-tools). We will run it with the -g option to record call graph information: We need to run it as root because the access to performance counter are disabled by default on Linux. Normal users can be given access to this, but this is out of the scope of this article.

$ sudo perf record -g ./benchmark
$ sudo perf report -g 'graph,0.5,caller'

You should now be presented with an interactive window in which you can see how much time your program spent in each function.

One nice trick in the code above is the use of the functions DoNotOptimize and ClobberMemory. Those twp functions basically tell the compiler to ignore the fact that the results of the computation are not used anywhere. Otherwise, most optimizers will delete the code of our benchmark, as it does not create side effect.

For those of you who are curious, you can implement it yourself using the following code:

void DoNotOptimize(void *p)
{
    volatile asm("" : : "g"(p) : "memory");
}

void ClobberMemory(void)
{
    volatile asm("" : : : "memory");
}

Basically those two lines of code are used to create fake zones where the results of the benchmark might be used. The compiler is also disallowed to optimize those parts by the use of the volatile keyword. For more detail on this, see the talk I linked above or GCC’s documentation on inline assembly.

There is a lot to be said on how to interpret perf’s output and optimize your code, but I just wanted to share what I learnt last week. The rest will be for another post!

How to read a datasheet ?

2018-01-11T00:00:00+00:00

So, since you started your journey into hardware making one word has been thrown around a lot: “datasheet”. You are not totally sure of what it is, but judging by how many times it is referenced by other engineers, you thought it must be very important. And you were right! Let me introduce you to this famous document.

The datasheet (sometimes called the spec sheet), is the document that lists every characteristic of a part or subassembly. It is provided by the manufacturer, who wants you to have every information you need to design a product using their part (and then buy lots of them).

Datasheets range from simple to very complicated. A small passive component such as a capacitor will have one or two pages of datasheets, up to about 1200 pages for the datasheet for a complex microcontroller! Obviously, you do not want to read so many pages, so you need to learn how to navigate effectively in this ocean of information.

Why do you want to read a datasheet?

Before you even download a datasheet, it is important to know why. Are you a programmer who wants to implement a software driver for a chip? An electrical designer picking the main parts of their next product? A reverse engineer trying to understand how an old board works? Parts of the datasheet that might be irrelevant for one of those situations might be crucial for another one.

Where do you even find those datasheets?

So now you need to find the document. I usually start by entering the name of the part I am interested in plus “datasheet” into Google. This is usually the quickest way to find what you are looking for. Make sure the part number in the PDF matches what you want, sometimes Google gives incorrect results!

Another way to find a datasheet is by going to the manufacturer website. This technique can be painful, as navigating the website is quite different for each manufacturer. You can usually find the documents from the page of the product you are interested in. This is unfortunately the only way to make sure you have every information about your part, as some manufacturer like to spread the information in various PDFs.

Finally, the last method is particularly useful when you are at the status of component selection. In this phase, you will be looking at a lot of different components, and searching the relevant datasheets takes a lot of time. Fortunately, large components retailer, like Digikey, usually offer datasheets for download from their product browser.

Like I mentioned some manufacturers keep all the information for one part in a single document, while others prefer to separate into several. Document intended for electrical engineers are usually what is called the datasheet. Software-related indications are typically in other documents, often named something like Reference Manual, Programmer’s manual, Programming model, etc. Sometimes the documents are shared across a device family. For example, the electrical information might be in the “STM32F407 datasheet”, while the programming documentation is in the “STM32F4 family reference manual”. Make sure you also download the errata; this document lists all the error and issues the manufacturer has discovered about their product and it helps to know about them.

Some manufacturers might not give you the datasheet right away; they might require you to give information about your company/product or sign a Non-Disclosure Agreement (NDA). I would try to stay away from such companies if possible, and only try to get their datasheets if you really cannot do otherwise. These behaviours are red flags: either the product is really new (the datasheet or the product itself still has issues) or the company wants to hide something (lack of performance?). Even if the company really just wants to protect their secrets it will come back to bite you later.

Anatomy of a datasheet

The first page(s) of a datasheet is called the Product Brief (see example below). It contains a list of all the features of a chip and the most important characteristics (power supply voltages, package, etc.). Start by reading those to make sure the chip suits your need. You can probably find typical applications of this chip here; see if your application is listed. If you don’t see the features you need on the brief, don’t waste your time on that part. In this section, you can also find the status of the chip (pre-release, active or obsolete) and the release date. Make sure you are not losing time with a very old part or something you won’t be able to buy in the next 18 months.

Example product brief for an STM32F407 micro controller

Some datasheets contain a section called Application Information or similar. In those sections, the manufacturer discusses the use of the product, usually with schematic and information regarding the choice of external components and the equations needed for your design. Sometimes the manufacturer will even suggest compatible parts to use for their design. If the datasheet does not contain such sections, look for documents called Application Notes (appnotes in short), which are separate document with the same purpose.

Example absolute maximum rating (STM32F407)

Next, find the section named “Absolute maximum ratings” (see example above). As the name implies, this contains the limits you must respect if you do not want to break the part. Study it carefully! The content of this section will vary a lot depending on the device you are studying, so it’s hard to give specific advice here.

When reading numerical values in a datasheet, you will see that it is quite common to have multiple values for one thing: usually a typical value and a range (min – max). Make sure your design is working over the whole range of possible values!

Random tips

When you do not know the exact name of what you are searching for, it is useful to look at the units: If you are searching for a time, simply skim the unit columns for something like nanoseconds.

There will be restrictions and conditions under which a given information is valid. Be careful, as they might be hidden in footnotes.

When looking at mechanical drawing, especially of chips, make sure you are looking at the correct orientation (from above or from below). Usually chip outlines are given from above, but you can sometimes be surprised.

When programming an unfamiliar device, I find it useful to print the relevant chapters from the datasheet. Then, take notes, draw schematics, write pseudo-code, highlight important sections etc. You cannot keep every important information in your head, and they will come back to bite you.

The datasheet is like a search engine. Use Ctrl-F a lot, and ask questions to the document. After a while you will know the kind of jargon used by your device’s manufacturer and you will be able to quickly find the detail you need.

33rd Chaos Communication Congress

2017-02-09T00:00:00+00:00

I spent the time between Christmas and New Year in Hamburg, Germany, at the Chaos Communication Congress, 33rd edition (33C3 in short). 33C3’s motto was “Works for Me”, a phrase that everyone working in IT/engineering will hear at some point during their career. It quickly became a meme in the congress, showing up every time a presenter had a laptop issue for example.

I used some of the time between talks to update a bit my personal infrastructure to include Owncloud in addition to the existing Gitlab instance. This is still a work in progress, and I may write about it in the future.

I also had a lot of project ideas that I will leave here, in case I need some ways to lose my time soon!

WhatsApp-b-gone, an idea that was created after @SyrianSpock and I realized that social gatherings were annoyingly filled with people glaring at their phone. The easiest way to implement this is probably to add some rules in the firewall to block WhatsApp traffic. The rules should be easy to turn on and off (webapp for example).
Learning how to use radare2. Radare2 is a reverse engineering framework like IDA pro, but libre and commandline. It seems powerful but the learning curve is rather steep, so I must stick to it.
Related to the previous one: reverse engineer the Xiaomi Band fitness device. This is a small connected device that is still complete enough to be interesting to reverse engineer. Gaining code execution on it would be nice, as it is a small wearable device with a lot of autonomy.
Modifying the CVRA’s USB to CAN adapter to use SocketCAN. It would allow us to plug it into Linux and use Wireshark to analyze traffic.
A “smart” time tracker, which works by detecting what is your current working directory and guessing on which project I am working.

Anyway: as last year , I took some notes about the talk I went to and also the talk I had to miss, so that I can watch them later. This year marks the introduction of French translation for streams, which are included in the recording if you want to. Kudos to the translation team!

The Global Assassination Grid

As they say in the Air Force, ‚No comms no bombs‘, – A technician’s insight into the invisible networks governing military drones and the quest for accountability

It was impressive to hear him talk about his experience as a drone pilot and why he switched to alert the public about the drone program. I don’t think it is technical but some military acronyms slipped in without being explained.

Shut Up and Take My Money!

FinTechs increasingly cut the ground from under long-established banks’ feet. With a “Mobile First” strategy, many set their sights on bringing all financial tasks—checking the account balance, making transactions, arranging investments, and ordering an overdraft—on your smartphone. In a business area that was once entirely committed to security, Fintechs make a hip design and outstanding user experience their one and only priority. Even though this strategy is rewarded by rapidly increasing customer numbers, it also reveals a flawed understanding of security. With the example of the pan-European banking startup N26 (formerly Number26), we succeeded independently from the used device to leak customer data, manipulate transactions, and to entirely take over accounts to ultimately issue arbitrary transactions—even without credit.

Good talk showing the issues in a banking startup. The exploits were not complicated but are a good example of what not to do when you are developing an application. Not very technical.

What’s It Doing Now?

Legend has it that most airline pilots will at one time have uttered the sentence “What’s it Doing now?”, whenever the autopilot or one of its related systems did something unexpected. I will be exploring some high-profile accidents in which wrong expectations of automation behavior contributed to the outcome.

This talk was trying to see how we could transpose the lessons learnt from plane autopilots to self-driving car, especially regarding to what to do when it fails. Not very technical.

Dieselgate – A year later

At 32C3 we gave an overview on the organizational and technical aspects of Dieselgate that had just broken public three months before. In the last year we have learned a lot and spoken to hundreds of people. Daniel gives an update on what is known and what is still to be revealed.

Awesome talk! Daniel was one of the two presenters on the 32C3 Dieselgate talk. This year they decided to split their talk in one about politics/law (this one) and one about hacking methods used (I could not watch it). I recommend it to anyone interested in the Dieselgate scandal. Not technical.

Nintendo Hacking 2016

This talk will give a unique insight of what happens when consoles have been hacked already, but not all secrets are busted yet. This time we will not only focus on the Nintendo 3DS but also on the Wii U, talking about our experiences wrapping up the end of an era. We will show how we managed to exploit them in novel ways and discuss why we think that Nintendo has lost the game.

I like talks about console hacking: Since console systems are exotic, they usually start with an overview of the platform, which allows you to understand the exploits part without too much specific knowledge (unlike say, talks about PC systems). A good talk, with three passionate hackers showing us how they owned the Wii U and the 3DS. However, the attacks presented are highly technical, and might be hard to understand if you are not familiar with ROP and Use-after-free.

How physicists analyze massive data: LHC + brain + ROOT = Higgs

Physicists are not computer scientists. But at CERN and worldwide, they need to analyze petabytes of data, efficiently. Since more than 20 years now, ROOT helps them with interactive development of analysis algorithms (in the context of the experiments’ multi-gigabyte software libraries), serialization of virtually any C++ object, fast statistical and general math tools, and high quality graphics for publications. I.e. ROOT helps physicists transform data into knowledge.

The presentation will introduce the life of data, the role of computing for physicists and how physicists analyze data with ROOT. It will sketch out how some of us foresee the development of data analysis given that the rest of the world all of a sudden also has big data tools: where they fit, where they don’t, and what’s missing.

Fun thing about this talk: the topics were chosen by the audience, based on the amount of cheering for a given topic. However, I did not learn much in this talk, especially on ROOT, which was supposed to be the theme of the talk. Somewhat technical.

No USB? No problem.

How to get USB running on an ARM microcontroller that has no built in USB hardware. We’ll cover electrical requirements, pin assignments, and microcontroller considerations, then move all the way up the stack to creating a bidirectional USB HID communications layer entirely in software.

xobs is the co-creator of the Novena open source laptop. I highly recommend reading his blog, if you are into hardware hacking or manufacturing. About the talk itself, I enjoyed it, as it was a nice introduction to USB and debugging, and I worked on those two topics before. However, if you are not planning to implement USB soon, or don’t like firmware hacking, this talk might not be your cup of tea.

Formal Verification of Verilog HDL with Yosys-SMTBMC

Yosys is a free and open source Verilog synthesis tool and more. It gained prominence last year because of its role as synthesis tool in the Project IceStorm FOSS Verilog-to-bitstream flow for iCE40 FPGAs. This presentation however dives into the Yosys-SMTBMC formal verification flow that can be used for verifying formal properties using bounded model checks and/or temporal induction.

Insanely technical talk about formal verification of FPGA programs, which can be used to find bugs not exercised by the simulation or by testing on hardware. I must admit I did not understand most of the talk, but I think I got an approximate understanding of the process.

Lockpicking in the IoT

“Smart” devices using BTLE, a mobile phone and the Internet are becoming more and more popular. We will be using mechanical and electronic hardware attacks, TLS MitM, BTLE sniffing and App decompilation to show why those devices and their manufacturers aren’t always that smart after all. And that even AES128 on top of the BTLE layer doesn’t have to mean “unbreakable”. Our main target will be electronic locks, but the methods shown apply to many other smart devices as well…

This talk focuses on some digital padlocks that use Bluetooth for unlocking. The researcher shows how incredibly bad the security of those things are, both mechanically and in software.

A world without blockchain

Instant money transfer, globally without borders and 24/7. That’s one of the promises of Bitcoin. But how does national and international money transfer work in the world of banks?

A talk showing what happens behind-the-scenes when you send money to your cousin in Brazil. Contains both the accounting principles and the technical explanations of what happens. I would have loved to go a bit more in-depth, but the talk was already short on time. Not technical.

Intercoms Hacking

Call the frontdoor to install your backdoors

The author attack modern intercoms by forcing them to connect to a rogue 3G cell. They are then able to open the door and spy on door conversation. It was interesting to see how to create a fake GSM antenna using a BladeRF/HackRF with YateBTS on the software side. Technical: you might have to search a bit if you don’t know anything about GSM & SDR.

radare demystified

radare is a libre framework and a set of tools to ease several tasks related to reverse engineering, exploiting, forensics, binary patching. This year, the project gets 10 year old.

This talk will show the evolution and structure of the project, its roots, some of the most notorious capabilities, showing several usage examples to let the attendees the power in functionalities and extensibility the tool provides.

I wanted to learn radare2 even before coming to CCC, so this talk was a “must attend”. What I got back from this talk was some starting points on how to use radare2. If you are not interested by reverse engineering, I don’t think you are in the audience for this talk.

Here are my raw notes:

They apparently have an IRC channel.

Should take between 2 days and one week to get used to it (à la vim).

Commands are mnemonic, based on modifiers (à la vim again)

5 commands to remember:

* s seek
* pd print disassembly
* s? prints help for s
* w is for write
* q quit
* ~ means grep ("p 10 ~ Mov")
* /m looks for known file format using magic

It appears to be able to read data in structs.

See the blog post "Analysis by default"

On Smart Cities, Smart Energy, And Dumb Security

Smart City is an abstract concept everyone talks about but no one knows what it actually means. No one, except Energy utilities. In this talk we will explore the vast world of Smart Energy, and see how energy providers used the “Smart City” concept to get better control over our energy consumption, all while almost completely ignoring security aspects along the way. Join me and see how Smart Energy is making our lives a little bit better, but also dangerously insecure.

I was disappointed by this talk. It contained a lot of non-fact based affirmations such as “you can make electricity meters exploded by hacking them” and little technical content. Same goes for Zigbee: no exploits / concepts, only talk. I was under the impression that the guy wanted to sell us the product his new startup is developping (he said he was working on this topic at the beginning of the talk though). I don’t recommend watching it.

Dissecting modern (3G/4G) cellular modems

Let’s have a detailed look at some modern 3G/4G cellular modems and see what we can find out about their internals using undocumented debug interfaces and software or hardware based hacking techniques.

The speakers are coming from the osmocom project so they know quite a lot about reverse engineering. This is also not their first talk so they know how to present well. A good talk about reverse engineering obscure hardware, GPL enforcement and weird programming practices. Technical.

They also introduced a multi voltage UART adapter called the Osmocom MV-UART.

Dissecting HDMI

Ever wondered what is actually happening when a speaker can’t get their laptop to project? While developing the FPGA-based HDMI2USB.tv open hardware for recording conferences, we discovered just how convoluted the HDMI protocol can be. Come hear all the horrible details!

The speaker comes from the Timsvideos project. The aim of the project is to be able to record conferences, like the CCC, but with less resources. To do that they wanted to create an HDMI screen capture board, which they implemented on an FPGA.

He recommended to watch another talk from 28C3 called “Implementation of mitm attack on hdcp-secured links”. Also a website filled with FPGA resources: hamsterworks He also mentions a talk at PyCon AU about designing hardware with FPGAs.

The Moon and European Space Exploration

Since the early successes of moon missions in the Sixtie, mankind has moved on to the earth orbit and other deep space missions. But interest in the moon as a target has intensified recently as the strategies for future missions are evolving.

Jan Wörner is the director of the European Space Program. In this talk he tries to answer the question “Why are we studying space?” I recommend it to everybody; the talk is fun and not technical.

Interplanetary Colonization

The long term survival of the human species requires that we become an interplanetary species. But we must answer two big questions: where are we going, and how do we get there? We explore what scientists know (and don’t know) about humanity’s potential future homes both inside and outside the solar system, and then we’ll dive into the technological challenges of (and potential solutions for) getting humans to and colonizing a new planet.

Quick intro to how can we move from planets to planets to colonize them. Not very technical, but I did not enjoy it as much as the previous one.

The Zcash anonymous cryptocurrency

Zcash is the third iteration of an extension to the Bitcoin protocol that provides true untraceability, i.e. fully anonymous transactions. It is arguably the first serious attempt to establish this extension, in the form of its own blockchain, beyond the form of an academic proposal. The talk provides an introduction to the magic that makes it work.

I need to rewatch that one to fully understand the math behind Zcash. It looked interesting, but I am into crypto; skip if you are not.

Community

Mitch Altman (born December 22, 1956) is a San Francisco-based hacker and inventor, best known for inventing TV-B-Gone, as featured speaker at hacker conferences, as international expert on the hackerspace movement, and for teaching introductory electronics workshops. He is also Chief Scientist and CEO of Cornfield Electronics.

In this talk, Mitch Altman tells us the story of how he entered the hacker scene. The guy is influential and his message definitely resonated with me. However, it also revealed that he has some strong bias, against the government for example, which I don’t agree with.

Retail Surveillance / Retail Countersurveillance

From geo-magnetic tracking for smartphones to facial recognition for email marketing, from physical shopping cart fingerprinting to computer vision algorithms that use your clothing as metadata, this talk will explore the emerging landscape of hyper-competitive retail surveillance. Instead of dramatizing these technologies which can lead to calcification and normalization, the aim of this talk is to energize discourse around building creative solutions to counter, adapt to, or rethink emerging surveillance technologies.

Those projects are about defeating common surveillance techniques through fashion and makeup. I liked the concepts, they are very cyberpunk-ish.

The Ultimate Gameboy talk

The 8-bit Game Boy was sold between 1989 and 2003, but its architecture more closely resembles machines from the early 1980s, like the Commodore 64 or the NES. This talk attempts to communicate “everything about the Game Boy” to the listener, including its internals and quirks, as well as the tricks that have been used by games and modern demos, reviving once more the spirit of times when programmers counted clock cycles and hardware limitations were seen as a challenge.

Last talk I saw at the congress, with a packed audience. Very well prepared, and communicates the effects used in Gameboy programming well.

Shining some light on the Amazon Dash button

This talk will explore the hard- and software of the Amazon Dash button.

PS4: PC Master Race

Last year, we demonstrated Linux running on the PS4 in a lightning talk - presented on the PS4 itself. But how did we do it? In a departure from previous Console Hacking talks focusing on security, this year we’re going to focus on the PS4 hardware, what makes it different from a PC, and how we reverse engineered it enough to get a full-blown Linux distro running on it, complete with 3D acceleration.

Yay, more console hacking! Very impressive technical level, learnt a lot about hardware and Linux kernel while watching this!

Talks I plan to watch later

Since I did not have time to watch everything I wanted, I made a short list of the videos I am going to watch in the coming weeks:

Global Game Jam

2017-01-24T00:00:00+00:00

As last year, I took part in the local Global Game Jam chapter. As last year, we had about 48 hours to create a video game about a specific theme, revealed at the beginning of the jam. I took part with almost the same team as last year (kudos to them):

Eric and I would do the coding,
Chloé and Lionel would do the drawing,
Anthony would do the playing (both playing the game and sounds).

This time we were more prepared than last time: we met one week before the event to decide which kind of game we wanted to do. We wanted something with more motion and more immediate fun than our first game, Duel of Wizard. We wanted something where implementing a few rules and behavior would lead to something playable early, in order to be able to iterate.

We decided to do a shoot them up type of game, which are fun to play and dynamic. It would also be a good exercise in level / game design; designing the enemies, their patterns and the level around them would provide a nice break from just churning out code or assets. On the technical side we would be using Phaser again.

The result is Apocalypse Miaou, a game in where you play a lion and a tiger who fight against enemies ruining their forest. It is a bit too hard to finish, but it even features a boss! You can watch the end result below or you can playtest it online.

We learnt a lot about while creating Apocalypse Miaou, about game programming (behaviors and entities), game design (some enemy patterns are really hard to avoid), and music (the game music is the first time Anthony composed something). I would like to thank the Swiss Castle Jam Organizers, for this incredible event, and Anthony, Chloé and Lionel for hosting me.

See you next year!

A value chain approach to understanding Open Source software

2016-12-14T00:00:00+00:00

Open Source is a way of developing products – usually software ones, although this is changing – in an open and public way. To qualify as “proper” Open Source, a product must grant several key freedoms to its customers: The user must be free to use the product, they must be free to copy the product, they must be free to study and modify the product. This approach to software distribution started in the 1970s. At first it only applied to research projects produced in universities, but in the 1990s it became used commercially, especially as backend (i.e. not user-facing) systems. In recent years, Open Source software left the backend and is now very present even in customer facing products.

A recent example is the one of Sun Microsystems: they used to develop proprietary systems but decided to open source the Java programming environment. Java was then reused by several other companies, including Google, who use it for their Android phone operating system (an open source project in itself). Sun was then bought by Oracle in 2009, due to financial problems. This begs the question: why was this Sun’s strategy? Surely, they could have earned a lot more by selling a license for Java, if their product was good. In this essay, I try to take a look at the Open Source movement from a value chain perspective in order to explain this kind of behavior. Value chain analysis is concerned with three aspects: value creation, value capture and the global network surrounding those processes.

We must first ask how are open source products creating value when compared to proprietary one. First, the open source solution can be cheaper than the proprietary one through a process of commodification: some parts of modern IT systems are not a key strategic advantage anymore, for example web servers or operating systems. Therefore, it makes sense economically to split the development costs with other actors.

From the customer’s perspective, open source software has an increased value because it reduces risks associated to vendor lock-in. Proprietary solutions can become a liability when the development is stopped by its vendor. Open source, on the other hand, allows the user to continue fixing bugs and go on with their operations.

We now need to understand how a company can capture value by releasing their intellectual property as open source. Obviously standard methods of selling licenses cannot be used: since the freedom to copy the product is guaranteed without conditions, it is not possible to sell it “as is”.

One business model which circumvents that limitation is the use of so called “dual licenses”: the idea is to offer the product as open source but with limitations which might not be acceptable by commercial users. A commercial license is then offered which removes the limitations. The most common limitation is to force one company to release their complete product as open source if it includes open source component.

The second commonly used business model around open source products is the sales of complementors, e.g support contracts or additional features. This is the approach chosen by Google for their Android system. By providing phone manufacturers with a high quality open-source model, they attracted users to their platform. They could then try to sell those users their more lucrative products such as personalized advertisements.

From a network perspective, open source has a lot for it. Obviously it eases existing forms of collaboration between actors in a value network, through the process of commodification explained before.

However it also creates new interesting connections: users of an open source product can now contribute back to the product they use. They leave the role of being a pure customer to being directly involved in the creation. They don’t contribute their solution to the project for the “greater good”, but for economical reasons. It is usually cheaper to integrate a change into the original project than to maintain a list of changes internal to the company (a practice called “forking”)

Sharing technology through open source also allows company to find engineers already well-knowledgeable on a given technology. This reduces their time to market and allow them to scale their staff easily, by only having to train them on in-house, key technologies. On the other hand engineers also benefit from this, by being able to take their experience with them to a new employer without violating an eventual non disclosure agreement.

Looking at the open source economy from a network point of view also reveals that software companies have their own form of the “smiley curve”. The smiley curve was proposed by Stan Shih, founder of Acer, in the early 90s. He theorized that both ends of the value chain (design and distribution) were much more profitable activities than in the center (manufacturing). Software companies tend to follow a similar pattern: selling application and user-facing services has a lot more value than selling operating systems. A good example of this is Microsoft of which most value comes from their Office suite and not from the Windows operating system. Therefore, it makes sense to try to be at the end of the value chain while avoiding the middle of the technological stack, sharing the cost with other companies.

In conclusion, we see that the tendency for companies to release some of their software as open source can be explained by a value chain approach. We also see that open source can increase the value captured by a company, especially in higher value activities. Similar effects are already emerging in the field of open hardware, and time will tell if this trend continues its rise.

This essay was originally written for a class at EPFL. Thanks to Guido Albertelli for his feedback before putting it online.

Using Dnsmasq for VM testing

2016-07-04T00:00:00+00:00

Today I was trying a new configuration option for Gitlab and I wanted to make sure I did not make any mistakes before trying the site live. Therefore I decided to deploy the configuration in a virtual machine and then copy it on the live server.

To access the page served by the VM two conditions needed to be met:

The HTTP port should be forwarded to be available on the host. Vagrant makes it extremely easy, take a look at this tool if you don’t know it already.
The virtual machine should be accessible under the domain given to Gitlab’s web server. Simply typing the IP address might not work because a single web server might be configured to serve different sites depending on the domain. This part is usually done by hacking /etc/hosts to resolve the chosen name to 127.0.0.1 but I decided to try using Dnsmasq for this after reading a blog post about it.

What is Dnsmasq ?

Among other things, Dnsmasq can act as a DNS caching server. This can be used to increase resolution speed, or, in our case, to inject fake DNS records into our network. Specifically, I will use to resolve all .dev domains to my own machine.

Installing Dnsmasq on OSX

Using Homebrew installing Dnsmasq is relatively easy: brew install dnsmasq. I decided to track the configuration in my dotfiles repository and to symlink the actual file to the versioned one:

cp /usr/local/opt/dnsmasq/dnsmasq.conf.example ~/dotfiles/dnsmasq.conf
sudo ln -s ~/dotfiles/dnsmasq.conf /usr/local/etc/dnsmasq.conf

Configuring the DNS server

Note: you can find the latest version of the file on Github.

The first step is to be a good netizen by disabling the forwarding of ill-formed domain names. I don’t know if this is strictly required but the Dnsmasq example guide suggests enabling it. We will also only allow requests coming from localhost for security reasons.

# Never forward plain names (without a dot or domain part)
domain-needed
# Never forward addresses in the non-routed address spaces.
bogus-priv

# Only allow localhost requests
listen-address=127.0.0.1

Then we will add the redirection rules. We only have one, i.e. sending all .dev to 127.0.0.1.

# Add domains which you want to force to an IP address here.
# Sends all domain ending in .dev to localhost
address=/dev/127.0.0.1

After restarting Dnsmasq (sudo brew services restart dnsmasq), you should be able to test your config by running dig foo.dev @localhost. If you get an answer mapping to 127.0.0.1, everything is working!

Sending DNS requests to Dnsmasq

This step if pretty straightforward: Open System Preferences, go to “Network”, then click “Advanced…” and add 127.0.0.1 to your servers under the “DNS” tab. Don’t forget to click apply once you left the advanced settings! Now you should be able to ping foo.dev, however normal websites won’t be recognized anymore.

Adding upstream servers

The original guide chooses to send only the .dev queries to Dnsmasq, but I preferred to add upstream servers to my config. Upstream DNS servers are queried when Dnsmasq doesn’t know how to resolve a given query. Enabling them means that DNS queries will be cached, making them slightly faster. It also means that you don’t have to fumble with OSX files such as /etc/resolver/, which is forbidden by El Capitan (I haven’t updated my laptop to El Capitan though).

To enable upstream servers add the following to your dnsmasq.conf. I chose to use two different DNS providers for reliability reasons (Google DNS and OpenDNS).

# Upstream DNS servers
server=8.8.8.8
server=8.8.4.4
server=208.67.222.222
server=208.67.220.220

Restart Dnsmasq and voilà! You are now able to ping google.com and foo.dev should resolve to localhost. You can now configure your virtual server as foo.dev and it should correctly answer, but that is left as an exercise to the reader ;)

Using GCC’s Stack Smashing Protector on microcontrollers

2016-06-01T00:00:00+00:00

Writing your code in C means manual memory management means a lot of bug types: Double free, use after free, stack overflow, etc. Those bugs can be especially hard to debug because they will cause erratic behavior but might not trigger an error condition immediately.

I recently added a memory protection unit (MPU) driver that I used to detect NULL pointer dereference. This (combined with other patches) significantly increased the stability of our platform, but we still had occasional issues.

In order to debug those, I wanted to add more memory hardening to the system. I started with the stack smashing detection, since it was the easiest.

What is stack smashing ?

To quote Wikipedia:

In computer security and programming, a buffer overflow, or buffer overrun, is an anomaly where a program, while writing data to a buffer, overruns the buffer’s boundary and overwrites adjacent memory locations. This is a special case of the violation of memory safety.

Stack smashing is a class of buffer overflow which occurs on stack-allocated buffers. It can be used by an attacker to gain code execution by modifying a function return address. That is not a concern on our robot, but it can be an issue if you are developing an Internet-connected product.

Consider the following code:

void my_buggy_function(const char *user_provided_message)
{
    char buffer[10];
    strcpy(buffer, user_provided_message);
}

In this overly simplificated example, if the user provided message is longer than nine characters (plus terminating zero), then the copy will overflow from the buffer into following variables. An attacker could use this to override the function return address, gaining code execution.

How does Stack Smashing Protection work ?

Stack Smashing Protection (SSP) tries to prevent most of those bugs by adding an extra variable (called a canary) in every function. On function entry this canary is set to a value and on function exit the canary’s value is checked. If it has changed during function execution it means the stack has been smashed and a callback is fired.

Of course SSP cannot detect every buffer overflow but it is still better than nothing for debugging. It also effectively closes a whole class of security flaws if correctly implemented. However, it has a (small) runtime cost, which might be a problem depending on your requirements.

Enabling SSP

Turning on SSP with GCC is quite easy: Just add -fstack-protector-all to your CFLAGS. You might also be interested in -fstack-protector and -fstack-protector-strong which use some heuristics to exclude some functions from being checked.

So let’s build and see how it goes:

arm-none-eabi/bin/ld: cannot find -lssp_nonshared
arm-none-eabi/bin/ld: cannot find -lssp

Apparently some libraries are missing.

Adding missing libraries

A bit of Googling teaches me that I should be able to circumvent that problem by linking against empty static libraries instead. First, ask GCC to look for libraries in the current folder by adding -L . to your LDFLAGS. Then, create empty libssp.a and libssp_nonshared.a using the following commands:

arm-none-eabi-ar rcs libssp.a
arm-none-eabi-ar rcs libssp_nonshared.a

Now, rebuild the project and GCC should complain about missing references to __stack_chk_guard and __stack_chk_fail.

Writing the Stack Smashing protector callback

To work correctly SSP requires two symbols to be defined:

__stack_chk_guard which contains the initial value of the stack protector, and,
__stack_chk_fail which is called when a stack smashing is detected. This function should never return.

Here is a minimal implementation for ChibiOS but adapting it to your platform should be trivial. Just be careful to adapt STACK_CHK_GUARD to the word width of your architecture (the example is for 32 bits).

uintptr_t __stack_chk_guard = 0xdeadbeef;

void __stack_chk_fail(void)
{
    chSysHalt("Stack smashing detected");
}

If you want to make your system harder to exploit I recommend setting __stack_chk_guard to a random value on every boot using the hardware random number generator found in recent microcontrollers. Otherwise an attacker might be able to find the value of your stack canary and exploit this knowledge to circumvent this protection.

Testing the protection

We are now able to check if the stack smashing protection works correctly by running the following function:

void foo(void)
{
    char buffer[2];
    strcpy(buffer, "hello, I am smashing your stack!");
}

If everything goes well your panic handler should be called on function exit (check that with a debugger). If it doesn’t, try to reduce optimization level or check your console output for any warning/error messages.

Conclusion & Future work

SSP is one of the numerous tool you can use to make your code more secure. It has the advantage of being easy to apply to your whole codebase at once since it does not require any change to your source code.

I plan to add other other debugging features in the following weeks. I have an idea on how to use the MPU to prevent thread stack overflows (different from the buffer stack overflow we explored today). I also would like to implement heap corruption detection but I don’t know how I will do this yet. If anybody has done this before I would be glad to hear about it.

Edit 21st june 2016

I realized that .a files cannot be shared accross machines. I modified my build process to generate the required files automatically by adding the following lines to my Makefile:

libssp.a:
	arm-none-eabi-ar rcs $@
libssp_nonshared.a:
	arm-none-eabi-ar rcs $@

myproject.elf: libssp.a libssp_nonshared.a

10/10, will do again

2016-02-01T00:00:00+00:00

Last weekend I took part in the global game jam chapter organized in my home town. For those who don’t know the concepts of a game jam, it is a type of events where team gathers to make a game in 48h. The global in the name means that it simultaneously takes place all over the world, both remotely and with physical gatherings.

Screenshot of our game, “Duel of Wizards”

I took part in the jam with 5 friends I knew from before. Our main goal was to be able to ship “something”, given that none of us made a game before. We decided to develop a card game based on the “draft” mechanism: each player picks a card from a set, then gives the set to the opponent who picks a card and passes it back until the set is empty. If you want to try it, you can play it in your browser.

The team was quickly divided into three parts:

@ericdupertuis and myself were going to be the game programmers.
Two friends (Anthony and Maëlick) would be our game designers. This was a hard task since none of us had experience and it has a lot of impact on the finished game. They also ended up choosing the music for the game and writing the booklet for the physical version of the game.
The last two team members (Lionel and Chloé) would be our graphics team, making the awesome assets (<3) of our game.

The experience was a blast, and everybody in the team loved it as well! Sadly our game concept wasn’t as catchy as we hoped and the games were too long to stay interesting. This is largely due to our lack of experience making games, and I am sure we will become better with time.

Related to the point above, I think we should have done more iterative design. The coolest part of the jam was when we were integrating the assets, redoing the layout or improving the game and it felt like every 30 min someone had something cool to show to the others. Doing iterations sooner may have also allowed us to iterate on the gameplay.

Lessons learnt for the next jam:

Try to have a playable version early on to catch gameplay problems.
Our game engine was a little bit too basic, or maybe inappropriate for what we wanted to do. We were only able to have a working GUI and start playing rounds of our game after a day. This is way too long to see if a concept is fun or not.
Related to previous point: Choose the type of game we want to make before the jam and choose appropriate technologies before.
Study your tools: I realized after the jam that we reimplemented stuff that was already in the engine, such as game states.

UPDATE: @EricDupertuis posted his own writeup of the jam.