Adding a YubiKey to Lastpass

In the beginning of this year I got a YubiKey NEO from a colleague. As I
was already using LastPass to manage my passwords I wanted use my YubiKey as part of the two factor authentication process.

You can register your YubiKey by going to the premium “Multi-factor options” in your LastPass account settings and enabling the YubiKey option. For the two factor authentication to work you need to press the button on the YubiKey to generate a OTP (One Time Password) which will be stored with LastPass.

When I tried this for the first time I ran into a problem and got the following error: “At least one of the YubiKey tokens provided failed to validate.”. Copy and pasting this error in Google led me to a post on the LastPass support forum in which the solution was provided.

Thank you for contacting LastPass Support.

You need to set your YubiKey configuration to OTP authentication mode: … bikey-otp/

Once that is done, visit the following URL: and where it says ‘YubiKey with LastPass’, run the authenticator to make sure everything is working properly.

If no issues found, try to setup the YubiKey once again: … ntication/

Let me know how it goes.


After enabling OTP I could register my key and start using it with LastPass.

Updating the operating system on my Atari 1040STF

After finishing the drive swap mod on Atari 1040 STF I continued browsing the Atari forum’s hardware section and found a post/guide on how to update the operating software. In general, updating the OS is advisable as newer versions may contain bug fixes, security updates and increased I/O compatibility. The same goes for my Atari. The last available version for my machine, 1.04 a.k.a. Rainbow TOS, contains all of the above and is found to be faster overall.

On the Atari, the OS is stored on two or in my case six ROM (Read Only Memory) chips. As the name indicates, writing to ROM chips is not possible so they have to be replaced with chips containing the newer OS. While it is possible to buy a “ready to go” upgrade package it is also possible to go the DIY route and prepare the chips yourself. I opted for the latter as it is much more fun, educational and gives a real sense of achievement when finished.

The next step was to make a list of requirements, according to the guide I needed:

  • Six EPROM chips (Erasable Programmable Read Only Memory)
  • A EPROM chip programmer
  • The new version of the Atari OS
  • ROMSPLIT (a program used to split the OS image in to small parts for writing to chip)

After two weeks I had everything I needed and was able to continue the project.

Before writing the OS image it had to be split in to six parts using ROMSPLIT. A physical machine or emulator is needed to run ROMSPLIT as it is build specifically for the Atari. I used the STEEM emulator which can be found here: After splitting the image I was left with the following files:

  • TOS104US.H00
  • TOS104US.H01
  • TOS104US.H02
  • TOS104US.L00
  • TOS104US.L01
  • TOS104US.L02

Now it was time to write the different parts to the EPROM’s. This process is fairly straight forward as it is nothing more than connecting the programmer, plugging in the EPROM, launching the programmer software and selecting the correct IC, opening the file to write and pressing write. After each chip I took a piece of electrical tape and stuck it over the glass window to prevent the chip from being erased. I also wrote the corresponding part name on the chip.

After preparing the EPROM’s came replacing the old ROM’s. At first I thought this would super easy but I could not figure out where to put which chip. According to the Atari forum the correct places were indicated on the motherboard but for some reason my Atari only mentioned U2 to U7.

Luckily I was not the only one having this problem and I soon found the correct place for each chip. For future reference here is what worked for me (and others):

  • TOS104US.H00 –> U4
  • TOS104US.H01 –> U3
  • TOS104US.H02 –> U2
  • TOS104US.L00 –> U7
  • TOS104US.L01 –> U6
  • TOS104US.L02 –> U5

All what was left was to re-assemble and power on the system. After a few seconds I was greeted with the familiar green desktop and after looking at the system info I verified it was version 1.04  indicating that the update was a success :).

See ya on the next one.

Fix wifi Acer Aspire 5040

I recently upgraded a Acer Aspire 5040 to Windows 7. After the upgrade I installed all the drivers and found the wifi was not working correctly.  Everything looked fine but I could not see any access points to connect to. To fix this issue I had to go Acer’s support website and download and install the Launch Manager. Before installing I had to enable compatibility mode for Windows XP and select run as administrator on the setup.exe. After rebooting the lights on the front of the laptop turned on and  I could now detect access points.

Sites used:


Flashing a bios chip with an Arduino

I will use this post to describe the process I went trough to (re)flash the BIOS on a bricked ASUS P5B using a Arduino and some freely available software.

Some background info: My cousin gave me this motherboard and asked me to have a look at it after a failed BIOS update left him with a nice big paperweight. I’ve actually attempted to fix this board before using the method described here but I eventually gave up after I realised I lacked the necessary skills and shelved the project. Fast forward a year or so I come across a post on hackaday about a Arduino based BIOS flasher and decided the time had come to give it another try.

The requirements (can also be found here):


  • A chip compatible with or supported by Flashrom, in my case a mx25L8005 (a list of all supported chips can be found here)
  • Any of the supported Arduinos:
    • any based on the ATmega328 (/168/88 will work with small changes too), like the Arduino Uno R3.
    • Arduino Mega or Mega2560, but notice that the software has a different branch for them.
  • a way to convert the 5V logic levels to 3.3V (except if 3.3V arduino, these are rarer)


  • Flashrom
  • frser-duino (formerly known as serprog-duino)
  • AVR toolchain

Before you can actually flash the chip you must first connect the flasher to the chip. Some motherboards have a SPI header which makes connecting the Arduino a breeze. Other motherboards may have a removable chip which you transport to a breadboard. If your motherboard doesn’t have either one you will still be able to use this method but you might need some wires/clips specially designed for working with chips and or microprocessors.

The ASUS P5B motherboard has a SPI header located near the BIOS chip. The pinout can be seen in the picture below. Please note that pin names can differ between chips ( i.e. the SO pin can also be named MISO or DO depending on the chip).

[Header Pins] <--> [Arduino Pins]
[1] VCC (3.3V in my case)<-->[3.3V]
[3] SO(MISO,DO)<-->[12]
[4] SI(MOSI,DIO)<-->[11]
[5] CS#(SS)<-->[10]
[6] SCLK(CLK,SCK)<-->[13]
[7] GND<-->[GND]

If your motherboard does not have a SPI header you can use the following information

Left pins of the BIOS chip:
[pin1 of the bios chip] /CS<->10k resistor<->VCC 
[pin1 of the bios chip] /CS<->Arduino pin10(SS, PORTB2)
[pin2 of the bios chip] DO<->Arduino pin12(MISO, PORTB4)
[pin3 of the bios chip] /WP<->VCC
[pin4 of the bios chip] GND<->GND on the power pins

Right pins of the BIOS chip:
[pin8 of the bios chip] VCC<->+3.3V on the power pins of the Arduino
[pin7 of the bios chip] /HOLD<->VCC
[pin6 of the bios chip] CLK<->Arduino pin13(SCK, PORTB5)
[pin5 of the bios chip] DIO<->Arduino pin11(MOSI, PORTB3)

First you’ll need flashrom, the AVR toolchain and Git which can be installed with some simple “apt-get’s” (I’ve used a Ubuntu live CD for this part).

sudo apt-get install flashrom gcc-avr binutils-avr gdb-avr avr-libc avrdude git

Next we’ll download and build frser-duino.

$ git clone --recursive git://
$ cd frser-duino

If you have a Arduino with an FTDI chip (which my Duemilanove has) you can use the command below. If not skip to the part about the 8u2 or 16u2 boards.

$ make ftdi && make flash-ftdi

Edit: If you execute the command above and receive an error stating that LTO has not been enabled you will either have to build avr-gcc with LTO enabled or remove -flto and -fwhole-program from the makefile. I’ve opted for the latter which did the trick.

For a board with an Atmega 8u2 (Arduino Uno) or a 16u2(Due) you can use:

$ make u2 && make flash-u2

Hooray 😀 !You’ve reached the best part! In this step we’ll use flashrom to flash our chip.

To flash the chip you can use this command:

flashrom -p serprog:dev=/dev/ttyUSB0:2000000 -w P5B.rom

If all goes well flashrom will write the specified file to the chip(in my case the P5B bios rom).

To check if everything went according to plan you can dump the chip’s content by using this command. Or use the -v option while running flashrom to verify that the flashing was successful.

flashrom -p serprog:dev=/dev/ttyUSB0:2000000 -r good.rom

After completing the dump you can use a hex editor to compare the files. If they match it means you’ve successfully flashed your chip 🙂 .

Links used:

Sansa Clip+ Repair

My girlfriend was almost in tears when she told me her beloved Sansa Clip+ would not power on anymore. She handed me the little music player and told me that earlier that day, she pressed the power button a bit too hard after which she heard something break.

When inspecting the power button I noticed it was a bit loose where it usually has some tension from the switch underneath. I decided to have a closer look and used a tutorial to help me disassemble the Sansa.
Looking at the board the problem quickly revealed itself. The “extreme” use of force had broken the solder connections between the power switch and the board and as a result the switch fell off. Time to get out the soldering iron!

After reseating the switch and repairing the broken solder connections the Sansa powered up again meaning my girlfriend could listen to here favourite music again and dry her tears.

Edit: After a week my girlfriend returned to me with her Sansa. This time she was only hearing sound from one of her earbuds instead of both. Because I taught her well she had already tried multiple headphones to verify the problem was not the headphones but rather the Sansa itself. I did some research and found that this problem can be fixed by reheating the solder connections between the headphone jack and the board. It appears that the “stress” resulting from removing and plugging in the headphones weakens the connections.