Cloning MiFare classic with the proxmark

A while back I wanted to try cloning a MiFare card using the proxmark 3. The target was a card used for opening garbage containers in the city where I live. Reasons being that I wanted a spare in case I lost the original (replacements cost about 10 euro) and I wanted to put it on my key chain to have it always with me.

The cloning process is fairly easy and roughly consists of the following steps:

  1. Identify the type of card
  2. Get keys
  3. Dump content
  4. Analyze content of card
  5. Write dump to empty card*
  6. ……
  7. Profit!!!!!

Identifying the type of card

The proxmark client has an easy way to search and identify cards by using the “lf search” and “hf search” commands. The command output shows that the card is indeed a MiFare classic card.

 [usb] pm3 --> hf search
 [=] Checking for known tags…
 UID : B4 EE 82 34           
 ATQA : 00 04          
  SAK : 08 [2]          
 TYPE : NXP MIFARE CLASSIC 1k | Plus 2k SL1 | 1k Ev1          
 [=] proprietary non iso14443-4 card found, RATS not supported          
 [=] Answers to magic commands: NO           
 [+] Prng detection: WEAK           
 [+] Valid ISO14443-A tag  found 

Dumping 1,2,3

Dumping the content of the cards is as easy as running “hf mf dump“. Sadly I was too eager (and inexperienced) and forgot that in order to dump the card you first need to get the keys.

 [usb] pm3 --> hf mf dump
 [!] Could not find file hf-mf-B4EE8234-key.bin   

Getting the keys and dumping the card

There are several ways to cracking MiFare cards but the easiest way is just test and see if the default MiFare keys work. Luckily for me the default key “FFFFFFFFFFFF” did and I was able to dump the card.

Trying out the MiFare default keys

Dumping the card:

 
 [usb] pm3 --> hf mf dump
 [=] Reading sector access bits…          
 …………….
 [+] Finished reading sector access bits          
 [=] Dumping all blocks from card…          
 [+] successfully read block  0 of sector  0.          
 [+] successfully read block  1 of sector  0.          
 [+] successfully read block  2 of sector  0.          
 [+] successfully read block  3 of sector  0.          
 [+] successfully read block  0 of sector  1.

[snip]

[/snip>          
        
 [+] time: 17 seconds
 [+] Succeded in dumping all blocks
 [+] saved 1024 bytes to binary file hf-mf-B4EE8234-data.bin           
 [+] saved 64 blocks to text file hf-mf-B4EE8234-data.eml           
 [+] saved to json file hf-mf-B4EE8234-data.json 

Analyzing the content of the card

After completing the dump I decided to look at the data on the card using hexdump. I found that the only data was at the start of the file and seemed to correspond with the UID, ATAQ and SAK. My guess was that the container/reader only checked for the UID of the card before opening.

hexdump of the card data

Writing the dump to a new card*

At this point I thought I hit the jackpot and could just write the dump to any blank MiFare card without issues but no. As I learned then the first block of any MiFare card is called the “Manufacturers block” and it is not writable by default. Therefore there is no way to change the UID on normal MiFare card. However there are some Chinese sellers that sell so called “Magic” or “UID block 0” modifiable cards where block 0 is (re)writable. The proxmark client will tell you if the card will answer to magic commands as highlighted in the command output:

 [usb] pm3 --> hf search
 [=] Checking for known tags…
 UID : AA B5 11 02           
 ATQA : 00 04          
  SAK : 08 [2]          
 TYPE : NXP MIFARE CLASSIC 1k | Plus 2k SL1 | 1k Ev1          
 [=] proprietary non iso14443-4 card found, RATS not supported          
 [+] Answers to magic commands (GEN 1a): YES           
 [+] Prng detection: WEAK           
 [+] Valid ISO14443-A tag  found

At this point we can write the dump to the Chinese card:

 [usb] pm3 --> hf mf cload hf-mf-B4EE8234-data.eml 
 [+] loaded 1024 bytes from text file hf-mf-B4EE8234-data.eml           
 [=] Copying to magic card          
 ……………………………………………………….
 [+] Card loaded 64 blocks from file      

Running hf search again to check to see if the process was successful. As can be seen the UID has been changed to that of the target card:

 [usb] pm3 --> hf search
 [=] Checking for known tags…
 UID : B4 EE 82 34           
 ATQA : 00 04          
  SAK : 88 [2]          
 TYPE : Infineon MIFARE CLASSIC 1K          
 [=] proprietary non iso14443-4 card found, RATS not supported          
 [+] Answers to magic commands (GEN 1a): YES           
 [+] Prng detection: WEAK           
 [+] Valid ISO14443-A tag  found  

If you found this interesting or have feedback/questions please leave a comment!

P.S. Almost all of the above can be done using the “autopwn” command present in the proxmark repo from RfidResearchGroup.

References:

Prolific 2023 driver on Windows 10

  1. Go to device manager
  2. Right click on the prolific usb to serial adapter and select update driver.
  3. Select browse my computer
  4. Select from a list of devices
  5. Uncheck the checkbox next to supported devices
  6. Scroll down the list and select prolific
  7. Select the driver from 2007
  8. Select next
  9. Done

References:

  1. Todo (link to the forum post who referenced this method)

Emulating Amiibo’s with a Proxmark 3

In this post I will share the process I went through to emulate Amiibo’s with a Proxmark 3. For this the following things are required: 

Create a new folder and put Samy K’s script and the amiibo bin file in there. To be able to run the script you’ll need to make it executable. This can be done by using the following command: chmod +x mfu2bineml. After making the script executable you can use it to create an eml file that can be used by the Proxmark. To do this use the following command: ./mfu2bineml <put_amiibo_name_here>.bin > amiibo.eml. I found that the Proxmark client dislikes spaces in filenames so it is recommended to not use them in the filenames. 

An example of the script output can be found below: 

user@ubuntu-vm:~/Desktop/amiibo$ ./mfubin2eml Champion\ Mipha.bin > amiibo.eml

Character / info: 01 07 00 00 03 5a 09 02
Game : 010 The Legend of Zelda
Character: 7 --
Variation: 00 --
Type : 00 Figure
Amiibo : 035a The Legend of Zelda
Series : 09 The Legend Of Zelda
Last : 02 (should be 02)


Looks like encrypted file but setting preventing us from decrypting
Does not contain header, adding
UID: 04c25292aa5280
PWD: 00000000

hf mf eload u Champion Mipha.bin
hf 14a sim t 7 u 04C25292AA5280

The last part of the script will tell you what commands to use in the Proxmark client to load the eml file and emulate/simulate the Amiibo. Because I love tool output here is the output from the Proxmark client: 

pm3 --> hf mf eload u /home/user/Desktop/amiibo/amiibo
…………………………………………………………………………………………………………………………………………………………………………………………………………………………………
[+] Loaded 255 blocks from file: /home/user/Desktop/amiibo/amiibo.eml
pm3 --> hf 14a sim t 7 u 04C25292AA5280
[+] Emulating ISO/IEC 14443 type A tag with 7 byte UID (04 C2 52 92 AA 52 80 )
[+] press pm3-button to abort simulation

And here is a video demonstration of the Amiibo emulation. 

My first quadcopter build

In this post I will share my experiences with building a budget quadcopter I bought from AliExpress. This is by no means a tutorial and I advise you to look in the links section of this post if you are looking for a one.

So let’s begin.

It came without instructions, I messaged the seller and he/she replied that there are enough build instructions available

https://nl.aliexpress.com/item/Carbon-Fiber-Mini-QAV250-H250-C250-Quadcopter-1806-Brushless-Motor-12A-ESC-CC3D-Control-Board-5030/32285772418.html.

One problem though it came without instructions. I messaged the seller and got a reply similar to use google and RTFM. Not knowing where to go from there I shelved the project. Two weeks ago I decided to get over my self doubt and continue the project. After all how hard could it be right?

I started looking for tutorials online and found one which suited my needs.

http://www.dronetrest.com/t/qav-zmr-250-assembly-build-guide/1244

Although the overall proces seems simple the tutorial managed to confuse me quite a bit. The topics I got confused about:

  • Which length srew to use for the motors
  • How to connect the wires for the motors
  • How to orientate the cc3d board computer
  • How to connect the receiver to the cc3d

Motor screw length

This will probably vary on the types of motors but I ended up using 6 mm screws which I thought would be to long and might damage the motors. I tested it with one motor which continued to work. I decided what worked for one will work for all and fitted the 6mm screws on all motors. Please note that this does not mean 6 mm is the right fit for your motors.

How to connect the motor wires

According to the tutorial the wires for motors that turn clockwise have to be switched and the wires for the CCW motors do not need switching. Further along the tutorial it says the wire for the CCW motor needs to be switched. To be clear only the first statement is true (although this issue could probably be fixed in the firmware).

IMG_0979
Build almost completed.

Orientation of the cc3d board.

The tutorial tells you to place the cc3d board with the arrow to the side (left) but instead this needs to point at the front of the copter. Putting the cc3d arrow to the left will make the computer think the side is the front of the copter which causes the copter to flip immediatly on takeoff.

After fixing these issues I was able to get my quad of the ground.

I’ve included the maiden flight below:

Note2Self #1:

buy a small drone and learn how to fly it.

Tried to fly the drone outside and crashed it :(.

Also one of the motor wires came loose and when testing for damage the ESC fried.

Fried ESC

Note2self #2: 

Do not remove shrink wrap from ESC’s or re apply if removed. Plus isolate the power pads on the power distribution board. The frame of the QAV250 is conductive and will create shorting causing all tons of fun like mini fires :D.

ToDo:

  1. Get 4 new ESC + motor
  2. Get a new smaller drone to fly indoors
  3. Get a strap to fasten the battery

Saturday the 14th of october:

Got my replacement motors plus ESC’s in the mail. Also got my mini drone the day before. Those things are awesome and a good tool to learn how to fly a quad.

28th of January

So I rebuilt my quad just to find out one of my motors stutters. When searching for a solution I found several other people had this problem in combination with the cc3d and librepilot. One suggestion was to update the firmware on my simonk Esc (which of course are cheap ripoffs of the real thing). I looked at the pcb to find a fis 330 chip was there waiting for me. Supposedly these can be flashed with an arduino nano and blheli suite. So that’s where we are going next.

Flashing a BIOS chip with a Raspberry Pi

I made this post as a addition or supplement to my “Flashing a BIOS chip with an Arduino” post.

While doing some research online I found several articles/posts from people using a Raspberry Pi to flash SPI flash chips. Apparently the Raspberry Pi  is very suitable for this kind of thing as it has a SPI interface and is able to run linux. I was eager to try this out for myself so I got out my Pi 3 model B and got to work. For this project I used a Winbond 25X80 salvaged from a motherboard I had lying around.

Preparing the RaspberryPi

As others have pointed out, the latest version of Raspbian (Stretch) will also work by adding the spispeed param to the Flashrom command.

Enable the SPI interfaces by typing sudo raspi-config and selecting P4 SPI under the Interfacing options.

Select option 5: Interfacing options

Select SPI to enable the SPI interfaces

The SPI interfaces will become available under /dev/spidev0.0 and /dev/spidev0.1.

Next we install the packages are needed by Flashrom by using the following command.

sudo apt install git libpci-dev libusb-1.0 libusb-dev

Make and install Flashrom.

git clone https://github.com/flashrom/flashrom.git
cd flashrom
make && sudo make install

 

Connecting the Raspberry to the SPI flash chip

The table below show the connections between the RaspberryPi and the chip.

RPi pin SPI flash
25 GND
24 CS
23 SCK
21 DO
19 DI
17 VCC 3.3V and /HOLD and /WP

Flashing the chip

In order to verify Flashrom correctly identifies the chip we run Flashrom without any operations.

pi@raspberrypi:~ $ flashrom -p linux_spi:dev=/dev/spidev0.0,spispeed=512
flashrom p1.0-76-g291764a on Linux 4.14.34-v7+ (armv7l)
flashrom is free software, get the source code at https://flashrom.org

Using clock_gettime for delay loops (clk_id: 1, resolution: 1ns).
Found Winbond flash chip "W25X80" (1024 kB, SPI) on linux_spi.
No operations were specified.

Now that Flashrom correctly identifies the Winbond W25X80 we can continue to backup the current BIOS.

pi@raspberrypi:~ $ flashrom -p linux_spi:dev=/dev/spidev0.0,spispeed=512 -r flash.dat
flashrom p1.0-76-g291764a on Linux 4.14.34-v7+ (armv7l)
flashrom is free software, get the source code at https://flashrom.org

Using clock_gettime for delay loops (clk_id: 1, resolution: 1ns).
Found Winbond flash chip "W25X80" (1024 kB, SPI) on linux_spi.
Reading flash... done.

After backing up the old BIOS we can safely write the new BIOS back to the chip.

pi@raspberrypi:~ $ flashrom -p linux_spi:dev=/dev/spidev0.0,spispeed=512 -w flash.dat 
flashrom p1.0-76-g291764a on Linux 4.14.34-v7+ (armv7l)
flashrom is free software, get the source code at https://flashrom.org

Using clock_gettime for delay loops (clk_id: 1, resolution: 1ns).
Found Winbond flash chip "W25X80" (1024 kB, SPI) on linux_spi.
Reading old flash chip contents... done.
Erasing and writing flash chip... 
Warning: Chip content is identical to the requested image.
Erase/write done.

References:

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:

http://www.yubico.com/products/services … bikey-otp/

Once that is done, visit the following URL: https://lastpass.com/debug.php 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:

https://helpdesk.lastpass.com/security- … ntication/

Let me know how it goes.

Best,
Jed

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.

Continue reading Updating the operating system on my Atari 1040STF

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:

  1. http://www.acer.com/ac/en/GB/content/drivers
  2. http://www.sevenforums.com/network-sharing/57483-wireless-acer-aspire-5020-a.html

Flashing a SPI (BIOS) chip with an Arduino

In this post I will share how you can use an Arduino to flash/program chips through the Serial Peripheral Interface (SPI). I used this method myself to repair a ASUS-P5B motherboard that had it’s BIOS erased after a failed update.

Requirements

Hardware

  • Arduino Uno/Duemilanove or Mega (more info here)
  • A chip that is supported by flashrom (full list available here)

Software

  • VM Player/Workstation (I tried using Virtualbox but for some reason it does not play nice, flashrom will see the chip but will not actually read or write)
  • An Ubuntu 16 or 18 Virtual Machine
  • flashrom
  • fser-duino

The process

Installing git, flashrom and dependencies for frser-duino

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

Getting frser-duino and preparing the Arduino

git clone --recursive git://github.com/urjaman/frser-duino
cd frser-duino
make ftdi
sudo make flash-ftdi

Connecting the Arduino to the SPI chip

The following image is an example schematic taken from the flashrom GitHub and shows the pins on the Arduino and the pins on the chip they should connect to (please note that PB0 does not have to be connected):

The image below shows the pinout for the MX25L8005:

Please note that different manufacturers might use different pinouts for their chips and you should therefore always check the datasheet for the correct one.

Flashing the SPI chip

To verify that everything is working correctly we first run flashrom without any operations:

sudo flashrom -p serprog:dev=/dev/ttyUSB0:2000000

The output should look like this:

flashrom v0.9.9-91-g0bfa819 on Linux 4.10.0-28-generic (x86_64)
flashrom is free software, get the source code at https://flashrom.org

Using clock_gettime for delay loops (clk_id: 1, resolution: 1ns).
serprog: Programmer name is "frser-duino"
Found Macronix flash chip "MX25L8005" (1024 kB, SPI) on serprog.
No operations were specified.

If the previous command worked as expected we are now ready for our final step. To write the new BIOS to the chip we use the following command:

sudo flashrom -p serprog:dev=/dev/ttyUSB0:2000000 -w [NEWBIOS]

The output should look like this:

flashrom v0.9.9-91-g0bfa819 on Linux 4.10.0-28-generic (x86_64) flashrom is free software, get the source code at https://flashrom.org Using clock_gettime for delay loops (clk_id: 1, resolution: 1ns). serprog: Programmer name is "frser-duino" Found Macronix flash chip "MX25L8005" (1024 kB, SPI) on serprog. Reading old flash chip contents... done. Erasing and writing flash chip... Erase/write done. Verifying flash... VERIFIED. 

And that is it. We have successfully flashed a chip using the SPI interface. If you have any questions or feedback about this post please leave a comment below!

References

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.