Howdy
Thought I’d kick things off by setting the tone for the rest of this blog. The front page description won’t do it justice as time passes and this nerdy diary of artless prose fills to the brim.
Getting closer to the point
This isn’t to say that the blog is purely tech-based or security-related. Indeed it will be a recurring theme, largely due to how much less effort it takes to type stuff (code) and then type some more (this blog) to discuss said stuff. But my other hobbies do plan on making an arrival here sooner rather than later. Patience, my fellow reader.
With that said, like comment subscribe hit the notification bell blah blah let’s get this show on the road!
The point
A long nine-month while back, during a CTF event in Dublin City run by Zero Days Security, I was stumped by one of the questions. The challenge Fast and Efficient came with a flag.enc
file and a diagram illustrating how everything was set up.
It shows two LFSRs (linear feedback shift registers) of different sizes being used as a keystream for encrypting a PNG file containing the flag. But I didn’t know how an LFSR worked and the internet wasn’t lending me a hand. So, what now? Good question!
Being the dumb-dumb that I was at the time, I tried looking around on GitHub to see what others have come up with to solve similar challenges, rather than actually trying to figure out what LFSRs are. To no avail. Luckily though, this problem remained unsolved for the entire duration of the competition, so my team managed to maintain our 2nd place position on the leaderboard.
Fast forward six months to October of 2019 when I revisited this question. I had spent a good portion of my summer break knee-deep in programming puzzles on Codewars and learning Rust as some sort of pursuit for knowledge and presumably eventual success, so you could say I was fresh out the oven to boldly take on a previously unsolved challenge like this one.
Understanding the problem
We have ourselves two registers, 12 and 19 bits long. What’s interesting is that we don’t know their starting state, and this unknown combination of ones and zeros is what makes the algorithm (supposedly) secure. Each register has two taps assigned. A tap is a bit that affects the next state of the register. For instance in this case the smaller register’s 2nd and 7th bits and the larger one’s 5th and 11th bits are taps.
Every round the register moves all of its bits to the right, the rightmost of which is not discarded, but rather appended to the output stream. Now the empty space on the left needs to be filled. That’s where the taps come in - they’re put through a linear function each round, storing the output bit in the leftmost empty space of the register. The function is usually a bitwise Exclusive OR (XOR) operation, as is in this scenario.
Each register cycles through eight rounds to output eight bits, also known as a byte. The two resulting bytes are added modulo 255. That’s right, not 256 oddly enough. This creates one final output byte, which is said to be part of a pseudo-random keystream. When XORed with the original flag.png
file, the encrypted flag.enc
is formed.
Our goal is to find out the seed value (starting position) of both registers, thus revealing the keystream and enabling the decryption of the flag file.
The “mod 255” part initially threw me off; it led me down a path of sleepless nights and fruitless attempts at correcting the challenge author’s “mistake” that was later revealed as an anti-plaigiarism technique. Worked wonders, didn’t it?
Finding the right approach
So anyway, before this turns into a tirade, I haphazardly put together a Python script to try and solve this dilemma, not realising how incredibly long it would take to loop over multiple highly abstracted operations for… hold on lemme do the maf 2^(12+19) = 2^31 = 2,147,483,648 …over 2 billion times! Sweet mother of… Python is certainly not the name of the game for this kinda job.
To the rescue comes my new friend Rust. I was ecstatic to finally put it to use, justifying all the procrastination and self-idulgence that I’d sacrificed to learn it over the summer. This was the moment to shine. Time to plot.
Plan of action
- Set up 2 registers that match the criteria in the challenge diagram.
- Loop over every possible seed value (starting point) of both registers.
- Let N1,N2,N3,N4 be the first 4 bytes of the encrypted flag file.
- Let K = (8 bits from register 1) + (8 bits from register 2) modulo 255.
- Test if K ^ N1 is equal to the 1st byte of a PNG header, which is 0x89.
- Do 8 further rounds to get a new K, and test if K ^ N2 equals 0x50.
- Repeat for N3, testing for 0x4E.
- Repeat for N4, testing for 0x47.
- Repeat for N3, testing for 0x4E.
- Do 8 further rounds to get a new K, and test if K ^ N2 equals 0x50.
- If any step fails, go back and try another seed value.
- Test if K ^ N1 is equal to the 1st byte of a PNG header, which is 0x89.
- If four bytes are successfully decrypted, try the whole
flag.enc
file.
Execution time baby!
Time flies when you’re programming, and in my case most of it was compilation time as I sipped on my coffee and tweaked tad bits of code while the infamously sluggish compiler was running, in an attempt to up the efficiency factor by a couple notches. What a mouthful!
Long story short, I’ve just about had it with these unannounced peculiarities. It turns out that the specific implementation for LFSRs employed by this challenge discarded the first output bit. Thinking back to the competition, how was anyone expected to figure out this random quirk within 7 hours? Never mind the craze-filled vibe that filled the already cramped space as people ran about looking to get a decent LTE signal, or queueing for their 2 free team pizzas, all while another 50+ challenges also needed attention. Fun times :P
Eventually it came down to guessing and trying out of the ordinary things. Sometimes you just gotta have time, patience and a decent CPU, along with a hearty meal and a YouTube playlist to distract you from the dreadful compiler errors. Rustc knows that I’m kidding of course!
After grieving over all the time I lost, and over the time I spent grieving, and then some… I eventually came to a soluciĆ³n muy eficiente and compiled it with Rust’s superb optimisations. This resulted in code that brute forced over 2.1 billion combinations of bits in less than 30 seconds on my machine. Consistently.
Pretty neat, huh? Here’s the outcome:
“Whaa whaa just give me the code already”
Alright ya godforsaken beggars, the solution in its full glory, also found on my GitHub page with the rest of the files:
|
|
Conclusion
It werks. Donut touch it. Also a special thanks to stackoverflow and my insomnia.