We are presented, at first, with an audio file that appears to have morse code but with *alot* of static interference. So much so that it is actually much louder than the actual morse code. I cannot show you how it *sounds* in this writeup without you listening ot it yourself, but this is what the audacity rendition of it appeared to be. Quite obviously; it's too smooth to be morse code. And thusly, it'd be very hard to make out the actual beeping manually, let alone with a software morse code decoder.
 

 

Now, there are multiple ways to go about removing the noise. There's the noise removal option that comes with Audacity, which works fine, however it doesn't quite remove *all* the interference and, sometimes, interacts with the actual beeping and makes them more...bass-intensive? No clue how to describe it, but it just did not sound as sharp as it should. This is where the [ultra-narrow](https://forum.audacityteam.org/t/trying-to-isolate-sound-in-a-certain-frequency/13376/11) plugin comes into play.

Using the ultra-narrow plugin, we are able to isolate the specific frequencies of the morse code and remove all extra unrelated ones, which helps turn our audio file into a much more intermittent and square, as opposed to smooth, appearance (AKA: the morse code tones are actually there.)
 

 

Now that looks much better. It looks still a bit hard to understand what tones are being played, but if we amplify it and make the sound lower in dB, we'll get a much better view of the dots and dashes (or shorter and longer tones).
 

 

Now the interesting thing is that, if we were to just plop this into a morse code decoder...we'd end up with nothing. Because this actually *isn't* morse code; but rather a fork of it. Notice anything peculiar about the amount of tones before it stays silent and moves onto the next group? That's right...there's 8 of them. The title of this challenge, when translated from morse to text, is "ASCII". As in...*the ascii table*. As in, 8 bits turn to a byte, with a byte being a printable character.

I'm sure you're familiar with what the ascii chart is and what I mean specifically. But, if not, here is an image that better showcases it:
 

 

So, really, what we have here is simple. The shorter tones (dots) correspond with one bit, and the longer tones (dashes) correspond with another. Perhaps we'll associate the shorter ones with a 1, and the longer ones with a 0. If we're wrong...we have a 50/50 chance and can just invert everything. Assuming we...didn't mess up along the way.

Which...yes, we're doing this manually. Given the relatively short length of the audio it shouldn't be too requiring of a lengthy python script (which, given I like to make a "solution" script...it's pretty telling that I didn't make one for this challenge. Lol.)

Anyway.
 

 

Here is an example of the thought process. We do this for each group of dots/dashes, and get a byte. This byte can then be converted into ASCII, which is (in theory) going to be part of the flag. Doing this from the start to end, and performing `"".join([chr(int(c, 2)^255) for c in f])` on *f* (which will just be a space-seperated string of binary bytes, like `"10001111 10000000 11111111"`), will give us the ASCII representation.

The reason why we are XORing by 255 for each character generated is because, unknown to me doing the challenge, the picture is actually the *opposite* of what the byte should be. XORing by 255 just gives us the inverted version of a value. For instance, 11111111 turns to 00000000 and vice versa.
 

So, if we split the entire data by the length of my screen (which I did so that I could go by it one-at-a-time), we will get the following ASCII results:
 


 
This turns to: `shctf{N0 1 c4n H34r u 8`

 


 
This turns to: `33P_800p(In) < /dev/nul`

 


 
This turns to: `lspace}`

 

`shctf{N0 1 c4n H34r u 833P_800p(In) < /dev/nullspace}`