all repos — site @ c2bde2b35d14f52e383ce68ef4618d72cdb2b60f

source for my site, found at icyphox.sh

A ton of changes

Signed-off-by: Anirudh <icyph0x@pm.me>
Anirudh icyph0x@pm.me
Fri, 22 Mar 2019 18:45:44 +0530
commit

c2bde2b35d14f52e383ce68ef4618d72cdb2b60f

parent

a89e8b4ae27ced1056f9dd5423fc3630e5b572e7

M build/about/index.htmlbuild/about/index.html

@@ -26,7 +26,7 @@ <div class="container-text">

<header class="header"> <a href="../">‹ back</a> </header> -<body class="noselect"> +<body> <div class="content"> <div align="left"> <h1>Hi, I’m Anirudh.</h1>
A build/blog/break-the-ice/index.html

@@ -0,0 +1,250 @@

+<!DOCTYPE html> +<html lang=en> +<link rel="stylesheet" href="/static/style.css" type="text/css"> +<link rel="shortcut icon" type="images/x-icon" href="/static/favicon.ico"> +<meta content="Memeing security since forever." name=description> +<meta name="viewport" content="initial-scale=1"> +<meta http-equiv="X-UA-Compatible" content="IE=edge,chrome=1"> +<meta content="#021012" name="theme-color"> +<meta name="HandheldFriendly" content="true"> +<meta name="twitter:card" content="summary_large_image"> +<meta name="twitter:site" content="@icyphox"> +<meta name="twitter:title" content="Anirudh"> +<meta name="twitter:description" content="Memeing security since forever."> +<meta name="twitter:image" content="/static/icyphox.png"> +<meta property="og:title" content="Anirudh"> +<meta property="og:type" content="website"> +<meta property="og:description" content="Memeing security since forever."> +<meta property="og:url" content="https://icyphox.sh"> +<meta property="og:image" content="/static/icyphox.png"> +<html> + <title> + Anirudh + </title> +<script src="//instant.page/1.1.0" type="module" integrity="sha384-EwBObn5QAxP8f09iemwAJljc+sU+eUXeL9vSBw1eNmVarwhKk2F9vBEpaN9rsrtp"></script> +<div class="container"> + <header class="header"> + <a href="/">icyphox.sh</a> (<a href="https://github.com/icyphox/site">src</a>) + </header> +<body class="noselect"> + <div class="introduction"> + <h1 align="center"> + <h1>Break the Ice — Hardware CTF</h1> + +<h2>SecureLayer7’s hardware CTF at Nullcon ’19, Goa</h2> + +<p>Earlier this month at Nullcon Goa, we had the chance to attempt a hardware CTF challenge designed by the folks at <a href="https://securelayer7.net">SecureLayer7</a>. We weren’t able to solve it during the period of 2 days that we had (we had talks and parties to be at), but the SL7 guys were kind enough to let us keep the hardware and solve it back at home. Which we did, otherwise this write-up wouldn’t have happened :)</p> + +<h3>The Hardware</h3> + +<p>So what’s this cryptic “hardware” I keep mentioning, you wonder? It’s an ESP8266 board — better known as a <strong>NodeMCU</strong>. Here’s a picture.</p> + +<p><img src="1*cWpvtbXan4LjdJBldelW-g.jpeg" alt="" /></p> + +<p>Oh, and it came with a pretty OLED display too. So the obvious task at hand was to connect the display to the board. A quick search, and we found an (ever helpful) <a href="https://www.instructables.com/id/Interface-LCD-Using-NodeMCU/">Instructables</a> link with the image down below.</p> + +<p><img src="1*1avLAYsHDTGU-JS3e6oVrA.jpeg" alt="Not the same display, but it works" /><em>Not the same display, but it works</em></p> + +<p>Mind you, we struggled quite a bit at this seemingly trivial step, but hey we’re CS students ;)</p> + +<p>On connecting the device via USB, the board spins up a wireless hotspot called “Device-6”.</p> + +<p><img src="1*wJ3ZY2EskoSSfvCjliP_jQ.png" alt="" /></p> + +<p>We tried to connect to this, but it was password protected. We’ll get back to it later.</p> + +<h3>Flash dump analysis</h3> + +<p>During one of the many web searches I made with regard to this board, an interesting tool showed up — <a href="https://github.com/espressif/esptool">esptool</a>. A Python utility to communicate with the ESP8266. Wonderful.</p> + +<p>This tool allows us to do a bunch of operations on the board, but what we’re actually interested in is reading the flash. After looking up the syntax for it, we arrived at:</p> + +<pre><code>› sudo ./esptool.py -p /dev/ttyUSB0 -b 460800 read_flash 0 0x400000 flash_contents.bin +Serial port /dev/ttyUSB0 +Connecting.... +Detecting chip type... ESP8266 +Chip is ESP8266EX +Features: WiFi +MAC: 84:f3:eb:05:83:1e +Uploading stub... +Running stub... +Stub running... +Changing baud rate to 460800 +Changed. +4194304 (100 %) +4194304 (100 %) +Read 4194304 bytes at 0x0 in 100.8 seconds (333.0 kbit/s)... +Hard resetting via RTS pin... +</code></pre> + +<p>The command is fairly easy to understand, the <code>-p</code> flag denotes the serial port of our device, <code>-b</code> specifies the Baud rate and <code>read_flash</code>, well, reads the flash starting at <code>0</code> till <code>0x400000</code> which is 4MB. +We faced a lot of trouble here, since we kept reading only upto 2MB. Why? Because that’s what the command on the Internet said.</p> + +<p>Anyway, we have our flash dumped into a file <code>flash_contents.bin</code>.</p> + +<p>We then decided to run <code>strings</code> on the flash binary and peruse through the thousands of lines it had. Brilliant right? It was, actually. We found a bunch of interesting strings, along with what we guessed to be the wireless hotspot’s password. Spoiler alert: it was.</p> + +<p><img src="1*5Hc-_XYFw-4_hw3iZpfqkQ.png" alt="The entire dump was 6000+ lines. Did we actually do this D:" /><em>The entire dump was 6000+ lines. Did we actually do this D:</em></p> + +<p>The go-to utility to (actually) analyze binaries is <code>binwalk</code>. The <code>-e</code> flag extracts the known file types it recognizes within the binary.</p> + +<pre><code>› binwalk -e flash_contents.bin + +DECIMAL HEXADECIMAL DESCRIPTION +-------------------------------------------------------------------------------- +283960 0x45538 Unix path: /root/.arduino15/packages/esp8266/hardware/esp8266/2.5.0/libraries/ESP8266WiFi/src/include/DataSource.h +289387 0x46A6B HTML document footer +291156 0x47154 HTML document header +291296 0x471E0 Unix path: /root/.arduino15/packages/esp8266/hardware/esp8266/2.5.0/cores/esp8266/abi.cpp +3145728 0x300000 Squashfs filesystem, little endian, version 4.0, compression:gzip, size: 139733 bytes, 10 inodes, blocksize: 131072 bytes, created: 2019-02-25 09:14:19 +</code></pre> + +<p>We see a squashfs filesystem here. <code>binwalk</code> creates a directory in your current path containing all the files and folders it managed to extract. <code>cd</code>ing into our squashfs folder, we see this:</p> + +<p><img src="1*VsEzd8PSYMIUwjBLNFFetA.png" alt=":O" /><em>:O</em></p> + +<p>Oooh yes. <code>cat</code>ting the file, we see:</p> + +<pre><code>› cat 1/Hidden.txt + +######################################### Hints :) ######################################## + +---telnet server on esp + +--Hunt the key to get MQTT creds + -- +--MQTT box + +--Publish the correct message to get ^FLAG^ + +&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt; PUBLISH..... DISPLAY.... SUBMIT.... :) &gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; +</code></pre> + +<p>Looking inside the directory named <code>2</code>, we see another dir <code>3</code> containing a JPEG image and a file telling us about steganography.</p> + +<p><img src="1*68k1Y6IoK0XTCPTQRn_0fw.png" alt="" /></p> + +<p>And the final directory <code>4</code> had nothing in it but a file with the string <code>flag</code>. Probably to show up as a false positive in the <code>strings</code> output of the flash dump.</p> + +<h3>Connecting to “Device-6”</h3> + +<p>The first file we came across, containing the hints, mentioned a <code>telnet</code> server running on the board. But how do we reach it? Yep, via the wireless hotspot it exposes — “Device-6”. We authenticated using the PSK we found earlier. +On doing so, we’re prompted with a captive portal:</p> + +<p><img src="1*XelmAgITUw-9aZc26meUDQ.png" alt="" /></p> + +<p>A few things can be done here, configure WiFi on the board, view some info about the board, and reset it. Let’s connect the ESP to our own SSID — like a mobile hotstpot.</p> + +<p><img src="1*oQcTNKOFGphPbX50K2pmlg.png" alt="" /></p> + +<p>Once that’s done, we should see the “Device-6” SSID disappear, indicating that the board is now connected to our own wireless hotstpot. Another thing we notice is the board lights up, and so does our display!</p> + +<p><img src="1*lzKOxEkzJqo8TNI4WckmOg.png" alt="That’s so sad. Alexa play Despacito." /><em>That’s so sad. Alexa play Despacito.</em></p> + +<h3>The telnet server</h3> + +<p>Once our host machine and the ESP are on the same network, we can <code>nmap</code> our subnet to find our ESP’s IP.</p> + +<p><img src="1*lPNqoIFmNfxfabdt4sqYSQ.png" alt="nmap scan report" /><em>nmap scan report</em></p> + +<p>We see an <code>http</code> server running, which was obviously the captive portal, and our <code>telnet</code> server on port 23.</p> + +<pre><code>› telnet 192.168.43.223 +Trying 192.168.43.223... +Connected to 192.168.43.223. +Escape character is '^]'. +Press Enter &amp; sumbit your key :) +somekey +Wrong Key!!! +</code></pre> + +<p>On connecting, we see a prompt asking for a key. And no, ‘sumbit’ was spelt that way ;)</p> + +<p>Where could this key possibly be? Well, the only unexplored part of this CTF so far is the image file we came across before. So… steganography.</p> + +<p>Although you won’t need it, I downloaded this Docker image for cracking stego — <a href="https://hub.docker.com/r/dominicbreuker/stego-toolkit/">stego-toolkit</a>. We then tossed the image under a bunch of steganography detection and breaking tools, but to no avail.</p> + +<p>After a good while <code>steghide</code> gave us something:</p> + +<pre><code>› steghide extract -sf 10071856.jpg +Enter passphrase: +</code></pre> + +<p>This took <em>really</em> long for us to figure but the password was the name of the image file itself. Urgh. On entering the password, we get a <code>keys.txt</code> file. Here’s what it looked like:</p> + +<pre><code>So you guessed the password i think... + +Nice!!! + +Key is somewhere hidden in this strings ... + +XH}&lt; +TJJ* +Y#pU +&lt;g?/N +gr[i}5 +&gt;+h1 +...snip... +jlW8B +yjbm +M4%' +tx;ZzL +3 k] +wPUf'rc +)Pz# +0AwN\ +Lgr:J2 +!H9u +4bSVy +(*-C +nOf2E\ + +Aaaaaand key is not guessable .... + +WARNING:Manual checking for correct key might take you 2 days to complete the challange!! +</code></pre> + +<p>Nearly 600 lines of gibberish. We guessed that one of these strings had to be they key for our <code>telnet</code> session. We tried to automate it, but the <code>telnet</code> session was very unstable. So being the madmen we were, we did it manually. We had all the time in the world. Off we went, copy/pasting the keys in batches of 5… and it worked.</p> + +<p><img src="1*vY84DrSpJU1H4c9pSvoB5Q.png" alt="yeet" /><em>yeet</em></p> + +<p>As the hint file mentioned, we had to connect to an MQTT instance somewhere and publish something for the flag. So this is what they were talking about.</p> + +<p>For those out-of-the-loop, <a href="https://en.wikipedia.org/wiki/MQTT">MQTT</a> is the protocol used in IoT basec client-server interactions, among other things. Go read about it if you want to understand the next bit.</p> + +<h3>Capturing the flag</h3> + +<p>To interact with the MQTT server, we’ll be using the <a href="https://mosquitto.org">Mosquitto</a> client. We then use the credentials and attempt to “publish” a message:</p> + +<pre><code>› mosquitto_pub -h 'm16.cloudmqtt.com' -p 17551 -t 'inTopic/web/test' -u 'hchzbuhr' -P 'Sz4plHnlVnHc' -m '(^.^)' +</code></pre> + +<p><img src="1*W_iVf3vDf4UaelycMbvPvw.png" alt="UwU" /><em>UwU</em></p> + +<p>After messing around with this for quite a bit (as is evident from the screen behind), we tried sending the string ‘flag’ as our message and… <em>dramatic pause</em> we got what you’d expect.</p> + +<p><img src="1*sO9vDtGgGjejxklF46gTlg.jpeg" alt="We were 10 days late, mind you" /><em>We were 10 days late, mind you</em></p> + +<h3>Conclusion</h3> + +<p>This was our first time playing a hardware CTF, and to be honest, there wasn’t <em>much *of “hacking” involved — at least by the word’s textbook definition. A lot of guesswork too, which made some parts of it excruciatingly painful to figure out. But all things considered, it was probably the most fun CTF I’ve played yet. Here’s a shoutout to the folks at SL7 for making this CTF *and</em> letting us keep the ESP :)</p> + +<p>That’s it. The end.</p> + + </h1> + </div> + + <div class="footer"> + <div class="left"> + &copy; 2019 — <a href="mailto:icyph0x@pm.me">icyph0x@pm.me</a> + </div> + + <div class="right"> + <a href="https://github.com/icyphox" target="_blank">GitHub</a> + <a href="https://twitter.com/icyphox" target="_blank">Twitter</a> + <a href="https://medium.com/@icyphox" target="_blank">Medium</a> + <a href="/about" target="_blank">About</a> + </div> + </body> + </div> +</html>
M build/blog/python-for-re-1/index.htmlbuild/blog/python-for-re-1/index.html

@@ -26,18 +26,18 @@ <div class="container-text">

<header class="header"> <a href="../">‹ back</a> </header> -<body class="noselect"> +<body> <div class="content"> <div align="left"> - <h2>Python for Reverse Engineering 1: ELF Binaries</h2> + <h1>Python for Reverse Engineering 1: ELF Binaries</h1> -<h3>Building your own disassembly tooling for — that’s right — fun and profit</h3> +<h2>Building your own disassembly tooling for — that’s right — fun and profit</h2> <p>While solving complex reversing challenges, we often use established tools like radare2 or IDA for disassembling and debugging. But there are times when you need to dig in a little deeper and understand how things work under the hood.</p> <p>Rolling your own disassembly scripts can be immensely helpful when it comes to automating certain processes, and eventually build your own homebrew reversing toolchain of sorts. At least, that’s what I’m attempting anyway.</p> -<h2>Setup</h2> +<h3>Setup</h3> <p>As the title suggests, you’re going to need a Python 3 interpreter before anything else. Once you’ve confirmed beyond reasonable doubt that you do,

@@ -81,7 +81,7 @@

<div class="codehilite"><pre><span></span><code><span class="gp">$</span> gcc chall.c -o chall.elf </code></pre></div> -<h2>Scripting</h2> +<h3>Scripting</h3> <p>For starters, let’s look at the different sections present in the binary.</p>

@@ -305,7 +305,7 @@ </code></pre>

<p>I’m not sure why it uses <code>puts</code> here? I might be missing something; perhaps <code>printf</code> calls <code>puts</code>. I could be wrong. I also confirmed with radare2 that those locations are actually the strings “haha yes!” and “nah dude”.</p> -<h2>Conclusion</h2> +<h3>Conclusion</h3> <p>Wew, that took quite some time. But we’re done. If you’re a beginner, you might find this extremely confusing, or probably didn’t even understand what was going on. And that’s okay. Building an intuition for reading and grokking disassembly comes with practice. I’m no good at it either.</p>
M build/static/style.cssbuild/static/style.css

@@ -1,7 +1,6 @@

@font-face { font-family: Inter; src: url('fonts/Inter-Regular.woff2'); - font-size: 13px; } html,

@@ -27,7 +26,7 @@ animation: fadein 3s;

} .container-text { - position: absolute; + position: absolute; overflow-y: auto; overflow-x: hidden; top: 0;

@@ -36,11 +35,11 @@ left: 0;

right: 0; color: white; - -webkit-animation: fadein 3s; - -moz-animation: fadein 3s; - -ms-animation: fadein 3s; - -o-animation: fadein 3s; - animation: fadein 3s; + -webkit-animation: fadein 1.5s; + -moz-animation: fadein 1.5s; + -ms-animation: fadein 1.5s; + -o-animation: fadein 1.5s; + animation: fadein 1.5s; } @keyframes fadein {

@@ -67,12 +66,17 @@ }

.content { position: absolute; - font-size: 17px; + font-size: 18px; top: 10%; left: 20%; right: 20%; width: 60%; - line-height: 170%; + line-height: 1.8; +} + +pre, code { + background: #041b1e; + padding: 2px; } .logo {

@@ -90,7 +94,7 @@ }

.header { color: cyan; - top: 20px; + top: 10px; position: absolute; width: 100%; text-align: left;

@@ -125,7 +129,7 @@ display: inline-block;

margin-right: 30px; } -.noselect{ +.noselect { -webkit-touch-callout:none; -webkit-user-select:none; -khtml-user-select:none;

@@ -141,7 +145,24 @@

max-width: 720px; } -@media only screen and (max-width: 100em) { +h1, h2, h3 { + font-weight: normal; +} + +h2 { + color: gray; +} + +h3 { + color: cyan; +} + +p { + bottom: 2em; +} + + +@media only screen and (max-width: 70em) { .left { display: block; margin-right: 0;

@@ -158,14 +179,15 @@ overflow-y: auto;

} .content { - top: 10%; left: 10%; right: 10%; bottom: 10%; - font-size: 16px; - line-height: 150%; - width: 85%; + width: 80%; } + + .content h1, h2, h3 { + line-height: 1.5; + } pre { overflow-x: auto;
A pages/blog/break-the-ice.md

@@ -0,0 +1,215 @@

+# Break the Ice — Hardware CTF + +## SecureLayer7’s hardware CTF at Nullcon ’19, Goa + +Earlier this month at Nullcon Goa, we had the chance to attempt a hardware CTF challenge designed by the folks at [SecureLayer7](https://securelayer7.net). We weren’t able to solve it during the period of 2 days that we had (we had talks and parties to be at), but the SL7 guys were kind enough to let us keep the hardware and solve it back at home. Which we did, otherwise this write-up wouldn’t have happened :) + +### The Hardware + +So what’s this cryptic “hardware” I keep mentioning, you wonder? It’s an ESP8266 board — better known as a **NodeMCU**. Here’s a picture. + +![](1*cWpvtbXan4LjdJBldelW-g.jpeg) + +Oh, and it came with a pretty OLED display too. So the obvious task at hand was to connect the display to the board. A quick search, and we found an (ever helpful) [Instructables](https://www.instructables.com/id/Interface-LCD-Using-NodeMCU/) link with the image down below. + +![Not the same display, but it works](1*1avLAYsHDTGU-JS3e6oVrA.jpeg)*Not the same display, but it works* + +Mind you, we struggled quite a bit at this seemingly trivial step, but hey we’re CS students ;) + +On connecting the device via USB, the board spins up a wireless hotspot called “Device-6”. + +![](1*wJ3ZY2EskoSSfvCjliP_jQ.png) + +We tried to connect to this, but it was password protected. We’ll get back to it later. + +### Flash dump analysis + +During one of the many web searches I made with regard to this board, an interesting tool showed up — [esptool](https://github.com/espressif/esptool). A Python utility to communicate with the ESP8266. Wonderful. + +This tool allows us to do a bunch of operations on the board, but what we’re actually interested in is reading the flash. After looking up the syntax for it, we arrived at: + +``` +› sudo ./esptool.py -p /dev/ttyUSB0 -b 460800 read_flash 0 0x400000 flash_contents.bin +Serial port /dev/ttyUSB0 +Connecting.... +Detecting chip type... ESP8266 +Chip is ESP8266EX +Features: WiFi +MAC: 84:f3:eb:05:83:1e +Uploading stub... +Running stub... +Stub running... +Changing baud rate to 460800 +Changed. +4194304 (100 %) +4194304 (100 %) +Read 4194304 bytes at 0x0 in 100.8 seconds (333.0 kbit/s)... +Hard resetting via RTS pin... +``` + + +The command is fairly easy to understand, the `-p` flag denotes the serial port of our device, `-b` specifies the Baud rate and `read_flash`, well, reads the flash starting at `0` till `0x400000` which is 4MB. +We faced a lot of trouble here, since we kept reading only upto 2MB. Why? Because that’s what the command on the Internet said. + +Anyway, we have our flash dumped into a file `flash_contents.bin`. + +We then decided to run `strings` on the flash binary and peruse through the thousands of lines it had. Brilliant right? It was, actually. We found a bunch of interesting strings, along with what we guessed to be the wireless hotspot’s password. Spoiler alert: it was. + +![The entire dump was 6000+ lines. Did we actually do this D:](1*5Hc-_XYFw-4_hw3iZpfqkQ.png)*The entire dump was 6000+ lines. Did we actually do this D:* + +The go-to utility to (actually) analyze binaries is `binwalk`. The `-e` flag extracts the known file types it recognizes within the binary. + +``` +› binwalk -e flash_contents.bin + +DECIMAL HEXADECIMAL DESCRIPTION +-------------------------------------------------------------------------------- +283960 0x45538 Unix path: /root/.arduino15/packages/esp8266/hardware/esp8266/2.5.0/libraries/ESP8266WiFi/src/include/DataSource.h +289387 0x46A6B HTML document footer +291156 0x47154 HTML document header +291296 0x471E0 Unix path: /root/.arduino15/packages/esp8266/hardware/esp8266/2.5.0/cores/esp8266/abi.cpp +3145728 0x300000 Squashfs filesystem, little endian, version 4.0, compression:gzip, size: 139733 bytes, 10 inodes, blocksize: 131072 bytes, created: 2019-02-25 09:14:19 +``` + + +We see a squashfs filesystem here. `binwalk` creates a directory in your current path containing all the files and folders it managed to extract. `cd`ing into our squashfs folder, we see this: + +![:O](1*VsEzd8PSYMIUwjBLNFFetA.png)*:O* + +Oooh yes. `cat`ting the file, we see: + +``` +› cat 1/Hidden.txt + +######################################### Hints :) ######################################## + +---telnet server on esp + +--Hunt the key to get MQTT creds + -- +--MQTT box + +--Publish the correct message to get ^FLAG^ + +<<<<<<<<<<<<<<<< PUBLISH..... DISPLAY.... SUBMIT.... :) >>>>>>>>>>>>>>>>>>>>>> +``` + + +Looking inside the directory named `2`, we see another dir `3` containing a JPEG image and a file telling us about steganography. + +![](1*68k1Y6IoK0XTCPTQRn_0fw.png) + +And the final directory `4` had nothing in it but a file with the string `flag`. Probably to show up as a false positive in the `strings` output of the flash dump. + +### Connecting to “Device-6” + +The first file we came across, containing the hints, mentioned a `telnet` server running on the board. But how do we reach it? Yep, via the wireless hotspot it exposes — “Device-6”. We authenticated using the PSK we found earlier. +On doing so, we’re prompted with a captive portal: + +![](1*XelmAgITUw-9aZc26meUDQ.png) + +A few things can be done here, configure WiFi on the board, view some info about the board, and reset it. Let’s connect the ESP to our own SSID — like a mobile hotstpot. + +![](1*oQcTNKOFGphPbX50K2pmlg.png) + +Once that’s done, we should see the “Device-6” SSID disappear, indicating that the board is now connected to our own wireless hotstpot. Another thing we notice is the board lights up, and so does our display! + +![That’s so sad. Alexa play Despacito.](1*lzKOxEkzJqo8TNI4WckmOg.png)*That’s so sad. Alexa play Despacito.* + +### The telnet server + +Once our host machine and the ESP are on the same network, we can `nmap` our subnet to find our ESP’s IP. + +![nmap scan report](1*lPNqoIFmNfxfabdt4sqYSQ.png)*nmap scan report* + +We see an `http` server running, which was obviously the captive portal, and our `telnet` server on port 23. + +``` +› telnet 192.168.43.223 +Trying 192.168.43.223... +Connected to 192.168.43.223. +Escape character is '^]'. +Press Enter & sumbit your key :) +somekey +Wrong Key!!! +``` + + +On connecting, we see a prompt asking for a key. And no, ‘sumbit’ was spelt that way ;) + +Where could this key possibly be? Well, the only unexplored part of this CTF so far is the image file we came across before. So… steganography. + +Although you won’t need it, I downloaded this Docker image for cracking stego — [stego-toolkit](https://hub.docker.com/r/dominicbreuker/stego-toolkit/). We then tossed the image under a bunch of steganography detection and breaking tools, but to no avail. + +After a good while `steghide` gave us something: + +``` +› steghide extract -sf 10071856.jpg +Enter passphrase: +``` + + +This took *really* long for us to figure but the password was the name of the image file itself. Urgh. On entering the password, we get a `keys.txt` file. Here’s what it looked like: + +``` +So you guessed the password i think... + +Nice!!! + +Key is somewhere hidden in this strings ... + +XH}< +TJJ* +Y#pU +<g?/N +gr[i}5 +>+h1 +...snip... +jlW8B +yjbm +M4%' +tx;ZzL +3 k] +wPUf'rc +)Pz# +0AwN\ +Lgr:J2 +!H9u +4bSVy +(*-C +nOf2E\ + +Aaaaaand key is not guessable .... + +WARNING:Manual checking for correct key might take you 2 days to complete the challange!! +``` + + +Nearly 600 lines of gibberish. We guessed that one of these strings had to be they key for our `telnet` session. We tried to automate it, but the `telnet` session was very unstable. So being the madmen we were, we did it manually. We had all the time in the world. Off we went, copy/pasting the keys in batches of 5… and it worked. + +![yeet](1*vY84DrSpJU1H4c9pSvoB5Q.png)*yeet* + +As the hint file mentioned, we had to connect to an MQTT instance somewhere and publish something for the flag. So this is what they were talking about. + +For those out-of-the-loop, [MQTT](https://en.wikipedia.org/wiki/MQTT) is the protocol used in IoT basec client-server interactions, among other things. Go read about it if you want to understand the next bit. + +### Capturing the flag + +To interact with the MQTT server, we’ll be using the [Mosquitto](https://mosquitto.org) client. We then use the credentials and attempt to “publish” a message: + +``` +› mosquitto_pub -h 'm16.cloudmqtt.com' -p 17551 -t 'inTopic/web/test' -u 'hchzbuhr' -P 'Sz4plHnlVnHc' -m '(^.^)' +``` + + +![UwU](1*W_iVf3vDf4UaelycMbvPvw.png)*UwU* + +After messing around with this for quite a bit (as is evident from the screen behind), we tried sending the string ‘flag’ as our message and… *dramatic pause* we got what you’d expect. + +![We were 10 days late, mind you](1*sO9vDtGgGjejxklF46gTlg.jpeg)*We were 10 days late, mind you* + +### Conclusion + +This was our first time playing a hardware CTF, and to be honest, there wasn’t *much *of “hacking” involved — at least by the word’s textbook definition. A lot of guesswork too, which made some parts of it excruciatingly painful to figure out. But all things considered, it was probably the most fun CTF I’ve played yet. Here’s a shoutout to the folks at SL7 for making this CTF *and* letting us keep the ESP :) + +That’s it. The end.
M pages/blog/python-for-re-1.mdpages/blog/python-for-re-1.md

@@ -2,15 +2,15 @@ ---

template: text.html --- -## Python for Reverse Engineering 1: ELF Binaries +# Python for Reverse Engineering 1: ELF Binaries -### Building your own disassembly tooling for — that’s right — fun and profit +## Building your own disassembly tooling for — that’s right — fun and profit While solving complex reversing challenges, we often use established tools like radare2 or IDA for disassembling and debugging. But there are times when you need to dig in a little deeper and understand how things work under the hood. Rolling your own disassembly scripts can be immensely helpful when it comes to automating certain processes, and eventually build your own homebrew reversing toolchain of sorts. At least, that’s what I’m attempting anyway. -## Setup +### Setup As the title suggests, you’re going to need a Python 3 interpreter before anything else. Once you’ve confirmed beyond reasonable doubt that you do,

@@ -59,7 +59,7 @@ $ gcc chall.c -o chall.elf

``` -## Scripting +### Scripting For starters, let’s look at the different sections present in the binary.

@@ -301,7 +301,7 @@

I’m not sure why it uses `puts` here? I might be missing something; perhaps `printf` calls `puts`. I could be wrong. I also confirmed with radare2 that those locations are actually the strings “haha yes!” and “nah dude”. -## Conclusion +### Conclusion Wew, that took quite some time. But we’re done. If you’re a beginner, you might find this extremely confusing, or probably didn’t even understand what was going on. And that’s okay. Building an intuition for reading and grokking disassembly comes with practice. I’m no good at it either.
M static/style.cssstatic/style.css

@@ -1,7 +1,6 @@

@font-face { font-family: Inter; src: url('fonts/Inter-Regular.woff2'); - font-size: 13px; } html,

@@ -27,7 +26,7 @@ animation: fadein 3s;

} .container-text { - position: absolute; + position: absolute; overflow-y: auto; overflow-x: hidden; top: 0;

@@ -36,11 +35,11 @@ left: 0;

right: 0; color: white; - -webkit-animation: fadein 3s; - -moz-animation: fadein 3s; - -ms-animation: fadein 3s; - -o-animation: fadein 3s; - animation: fadein 3s; + -webkit-animation: fadein 1.5s; + -moz-animation: fadein 1.5s; + -ms-animation: fadein 1.5s; + -o-animation: fadein 1.5s; + animation: fadein 1.5s; } @keyframes fadein {

@@ -67,12 +66,17 @@ }

.content { position: absolute; - font-size: 17px; + font-size: 18px; top: 10%; left: 20%; right: 20%; width: 60%; - line-height: 170%; + line-height: 1.8; +} + +pre, code { + background: #041b1e; + padding: 2px; } .logo {

@@ -90,7 +94,7 @@ }

.header { color: cyan; - top: 20px; + top: 10px; position: absolute; width: 100%; text-align: left;

@@ -125,7 +129,7 @@ display: inline-block;

margin-right: 30px; } -.noselect{ +.noselect { -webkit-touch-callout:none; -webkit-user-select:none; -khtml-user-select:none;

@@ -141,7 +145,24 @@

max-width: 720px; } -@media only screen and (max-width: 100em) { +h1, h2, h3 { + font-weight: normal; +} + +h2 { + color: gray; +} + +h3 { + color: cyan; +} + +p { + bottom: 2em; +} + + +@media only screen and (max-width: 70em) { .left { display: block; margin-right: 0;

@@ -158,14 +179,15 @@ overflow-y: auto;

} .content { - top: 10%; left: 10%; right: 10%; bottom: 10%; - font-size: 16px; - line-height: 150%; - width: 85%; + width: 80%; } + + .content h1, h2, h3 { + line-height: 1.5; + } pre { overflow-x: auto;
M templates/text.htmltemplates/text.html

@@ -26,7 +26,7 @@ <div class="container-text">

<header class="header"> <a href="../">‹ back</a> </header> -<body class="noselect"> +<body> <div class="content"> <div align="left"> {{ body }}