toby-bro

CryptoBro en détresse

This challenge gives us the power consumption of a "something" that validates PIN codes. We will be going towards differential power analysis (DPA) to solve this problem.

Initially I tried calculating the mean for all the numbers at the same time, but nothing stood out particularly. So I imagined that the code that checked the PIN was probably checking the numbers one by one. So we are going to proceed the same way.

We calculated the average power consumption for all the codes that started with 0??? then all those like 1???... and compared their averages, the one that stood out the furthest from the lot gives us the right first digit.

We got this output

toby-bro

Grand classic hotel

Everyone knows of that hotel in which one can copy his badge or modify it and have access to all the rooms. Having a Mifare Classic card is already one step more protected let's see if it can hold us out.

We are provided with the trace that was generated by a proxmark eavesdropping on a key exchange between a key and a lock. Not knowing what proxmark was, I searched it up and found this page that seemed to be what we were looking for. It even talks about dumping ISO 14443-A traces to wireshark for further packet analysis, which I did... But I didn't know that Mifare ISO 14443 had nothing to do with standard ISO 14443 A, or at least the protocol differs sufficiently for the trace to be badly analysed when using the 14a option instead of what I found with after a quick RTFM where I realized the answer was in front of my eyes since the beginning...

[offline] pm3 --> trace list --help
[...]

toby-bro

Binary lullaby

Wow I was not expecting a Verilog challenge, this language is really fun. Anyways, this challenge consists of a Verilog file that does a lot of nonsense no one cares to read except for the line assign { y[15], y[7] } = { x[15], x[7] };, and the output of what this complicated circuit gave when it was fed the flag. The challenge is also lacking an implementation of the logic gates it uses but that is not a problem, we can write it.

As the inputs are wires, the input can take only two values 0 and 1. For once bruteforce seems the only option, and bruteforce seems feasible as there are only $2^{14} = 16384$ different values to test. We will thus write a gates.v file with the implementation of the basic gates in Verilog and a testbench.v that will bruteforce this code until finding the correct output. Once we have the correct input we will simply decode it back to ASCII with decode.py.

To solve the challenge the only thing left is to execute our programs. We are using Icarus to simulat

toby-bro

RSA WTF

Analysis

This challenge has the amusing property of providing us with $p, q, dp, dq$ in a RSA-related challenge.

In this challenge AES CBC is used to encrypt the flag with a key that is a random number that we understand we will have to derive from the $p, q, dp, dq$ aforementioned.

The flag is split into 8-byte blocks that are successively encrypted with this weird key generation method.

toby-bro

Problèmeuh

Ce challenge très intéressant est en gros surtout un problème d'arithmétique des nombres entiers. Ça m'a amusé de pouvoir en refaire. Allons-y pour la résolution.

Les contraintes sont que

$$(a,b,c,x,y) \in \mathbb Z ^5$$

et que

toby-bro

La quête de l'anneau

Ici le mécanisme pour chiffrer le message est une "multiplication modulaire" selon l'équation $c \equiv m \cdot iv \pmod s$ avec $c$ le message chiffré, $m$ le message à chiffrer, $iv$ un nombre aléatoire premier avec $s$ et $s$ le 'module' de chiffrement.

Le déchiffrement s'obtient donc avec l'équation $m \equiv c \cdot iv^{-1} \pmod s$ avec $iv^{-1}$ l'inverse de $iv$ dans l'anneau $\mathbb Z / s\mathbb Z$, en gros $iv^{-1} \cdot iv \equiv 1\pmod s $.

Démonstration:

$$ c \cdot iv^{-1} \equiv (m \cdot iv) \cdot iv^{-1} \pmod s \

toby-bro

CocoRiCo

In this challenge, we see that basically each time we connect to the server and input our name we are given a token, which enables us to login with this username. By looking at the code we see that toto seems to be an admin account. Thus we will try to generate his token.

We see that the token is generated by encrypting the usename and his privileges and their CRC32 checksum with AES in OFB mode. Furthermore the iv is provided to us. So as we can see on this wikipedia image, if we possess one valid token then we only need to XOR it to the new username and checksum to get a new valid token.

For simplicity we took bob as a username so as the json dump of his status had exaclty the same length as the one of toto (True has one letter less than False)

So this is what we did

toby-bro

Strike

To reverse engineer this program I used IDA on one side and gdb on the other side (with pwndbg) so i could see what each input would do.

First of all we see that the program expects one argument Then we realise that the length of the string we pass as argument must be a dividable by two.

From now on we will consider that I am using the program ./strike aabbccddee with aabbccddee a string passed as argument to the program (in gdb)

(gdb) set args aabbccddee

toby-bro

Very cute data

I had no idea what this data was. I thus found myself reading a writeup of the year before

Once i had understood how this I2C works i went to writing the program to parse the data and extract the flag : extract.py

import json
import sys
from pyDigitalWaveTools.vcd.parser import VcdParser

toby-bro

FFTea

The code in craft_signal.py applies the inverse Fourier Transform on the bytes it reads from the flag.txt. So we only need to apply the Fourier Transform on the fftea data. This code thus recovers the flag :

import numpy as np

# Load the data from the "fftea" file
data = np.fromfile("challenge", dtype = np.complex64)
data = np.fromfile("fftea", dtype = np.complex64)