As hinted by the challenge title and description, this challenge is just some sort of base encoding. This is further confirmed by looking at the encoded data; 8990767883967987868C74768B8B90857A747A8678877981867C8B98 To determine the base, let us count the number of distinct symbols. 13! So this is likely to be base 13. There is of course a chance it was some other base where, by chance, the other symbols didn’t get used, but let us first try base 13....

We have been provided with the C code for this challenge; #include <stdio.h> #include <stdlib.h> int main(int argc, char *argv[]) { int id = 0; char name[16] = ""; printf("Input your name: "); gets(name); printf("Your name is %s with ID %d.\n", name, id); if (id == 1179402567) { printf("%s\n", argv[1]); } return 0; } As we can see, we are using the vulnerable gets function. We can use gets to overwrite the id variable which is just above the name variable on the stack....

In this challenge, we are given an oracle that will encrypt our input with a constant key. We are also given a redacted version of the encrypting script. Reading through the script, we can see that data is encrypted by splitting the data into blocks of two characters, encrypting each block individually (with a redacted function), and then concatenating the output. Furthermore, by connecting to the oracle, we can see that each block gets encrypted to a fixed size of 40 characters....

We are given a file with 10,000 lines, each of which is a new piece of data encrypted with a substitution cipher with a different key. One of these lines is the flag, and the rest are just random characters. To filter the rubbish out from the flag, we can use frequency analysis – as a substitution cipher will not change the frequency of characters. Ideally, we do not want to be comparing the character frequency distributions by hand....

This challenge provides us with the binary, so let us begin by printing the objects in the binary with objdump -t: SYMBOL TABLE: 0000000000000000 l df *ABS* 0000000000000000 crt1.c 0000000000000000 l df *ABS* 0000000000000000 crtstuff.c 0000000000403e60 l O .ctors 0000000000000000 __CTOR_LIST__ 0000000000403e70 l O .dtors 0000000000000000 __DTOR_LIST__ 0000000000402070 l O .eh_frame 0000000000000000 __EH_FRAME_BEGIN__ 0000000000401090 l F .text 0000000000000000 deregister_tm_clones 00000000004010c0 l F .text 0000000000000000 register_tm_clones 0000000000401100 l F .text 0000000000000000 __do_global_dtors_aux 0000000000404020 l O ....

This challenge only provides the following image of a book cover; As we can see, the ISBN is partially corrupted, and the goal is to recover the ISBN and thus recover the book title. After some quick googling, the structure of an ISBN10 code can be found. The following information is relevant; The first digits represent the country of publication, the next few digits represent the publisher, the remaining digits except the final digit specify the book’s title and edition, and the final digit is a checksum....

This challenge was created with the intention of showing partipicants how easy it is to decompile .NET code, presented in a fun game challenge. The challenge provides a Unity game. This is evident upon launching the game where you’re greeted with “Made with Unity”. Exploring the game there’s a jump that cannot be made. Rereading the descrption “Have a look around the map for anything that might be of help. It won’t be easy....

Based on the description, you may have determined that we are dealing with an autostereogram, better known as a magic eye puzzle. As such, you can theoretically just stare at the picture with great intensity until the flag reveals itself to you. If you did manage to solve this challenge with only your eyes then you are amazing. Discerning simple shapes is difficult, let alone a short sentence. If you are a mere mortal, an alternative way to solve this challenge is to use any of the online stereogram-solving tools that exist (this one’s pretty good)....

While running the image through stegsolve/stegonline or manipulating the pixels in your favourite image editor won’t work, a hex editor should show you that the data portion of the bitmap contains more than two distinct hex values. Checking the image properties should also indicate that ishihara.bmp is a 16-color bitmap image, and as such, each hex value denotes a different colour. Hence, we know that the image contains a wider range of colours than are being shown....