This is my write-up for the level Sydney located at:

I looked in the main function to see what was going on:

There were two functions that interested me: get_password and check_password:



The get_password seems to be getting the password from what the user inputs. The check_password function, from my understanding, seems to be running multiple times, which would mean that there are multiple passwords in order to pass this exercise. I will set a break-point at the first line of the check_password function and see what is being compared. I tried this out and learned that maybe #0x303a might be a number, and that is being compared with the user input. I entered the hex value AND its decimal equivalent to the program, and it was rejected both times. I then took another look at the code. At this point, I was stumped. I did research online into the right side of the "equation" and found this: It just reaffirmed my position, that the value being compared to #0x303a is either one password or part of the password. After tinkering with the code, I realized that instead of entering a number, I should try entering a string, or taking the preset value and converting it into a string. 0x303a is 0: in ASCII. I entered that, and the password was incorrect. I then entered :0, because it could have been a little endian issue, and I got to the next step:

Now I have to convert the next 3 values in order to get the correct password. It seems that all of the compares are doing 2 characters at a time from an offset of 2 from r15. We know the first 2 characters are :0, now we just have to continue with the same way we got the first 2 characters.

Hex (little endian)ASCII

3a 30


38 70


64 26


3c 5f


The whole password ends up being: :08pd&<_ . Now we enter it in the program and have access:

Last updated