Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
As it's a docx
file we can extract all the individual parts using binwalk
.
Then we navigate to /root/Desktop/_microsooft.docx.extracted/src/
, open up oof.txt
and Ctrl + F
for flag
.
flag{oof_is_right_why_gfxdata_though}
Alternatively, if you don't want to use the command line, change the extension to .zip
and unzip
Navigate into the correct folder and open oof.txt
. ctrl + F
to search for the flag.
So first we see that running the program slowly decrypts the string to yield a flag - but it's simply not fast enough. It never ends - we can check by putting a print()
statement at the end. So, we'll have to somehow make it go faster - and to do this we need to work out what the functions do.
The b()
function looks like this:
If we have a look at what it's doing, it seems to be reversing the input and comparing the two - so it returns True
if the inputted number is palidromic, and False
if it is not. We can't really make this more efficient, at least noticably.
The a()
function, however, looks like this:
What this seems to be doing is looping through every value from 2
to n-1
and checking if n
is divisible by it - a way of checking if it's prime. However, this is incredibly inefficient, and is probably the reason it takes so long. Let's make it more efficient and see if it does something.
We are going to use the sympy
function isprime
to change a()
:
Running this program spits out the full flag much faster now.
flag{pR1m3s_4re_co0ler_Wh3n_pal1nDr0miC}
Use n
, e
and c
in RsaCTFtool.
Just run
Running strings
on the file yields the flag.
The challenge hinted at the need to use the tool Volatility
.
First we run volatility -f memdump.raw imageinfo
on the dump to get the OS version. We then use the cmdscan
command to check the most recently run commands.
One of these is
JCTF{nice_volatility_tricks_bro}
We used this tool to guess the key, setting the keylength to 4 as this was said in the briefing.
We then used cyberchef to XOR the file with the key 5a 41 99 bb
It says it determines a .zip
file, but when unzipping you realise it's a .docx
file so change the extension to get:
flag{xor_is_not_for_security}
You can use dig
to check out the URL.
You can also head over here and input the URL there.
flag{next_year_i_wont_use_spf}
We can't use cat
to read the file, so we'll have to find another way.
The encrypted text we got given was
Some fiddling around with the capitalisation of the base64 characters got us the actually-printable string
which decoded to yield the flag.
flag{does_this_even_count_as_cryptooo}
Capture the Flag service to collect flags
Sorry, your flag is in another castle.
At this point he had to go and I took over.
Something that caught my eye was the descriptive note GitHub added:
This branch is 2 commits ahead of calebstewart:master.
If it was two commits ahead, then this account must have mades those two changes. I clicked the Compare
button next to this to check the changes, and they were very interesting.
One of these was an OpenSSH private key.
Another was in .bash_history
:
So this was fairly clear; this key was used to SSH into the website on port 50033. I copied the SSH key into a file called key
, ran chmod 700
to change the permissions so that it allowed me to use it to SSH, and connected.
Once in, all we had to do was cat flag.txt
.
flag{nahamcontron_is_on_the_grid}
So first rag went around to common social media sites, and eventually found a .
There was a pinned repository called . The directory was analysed, but nothing interesting was found except the description.
I decided to check his other repositories, one of which was a . Since the other repo was a dead end, I decided to check this one out.
A with CAndroid, I used 7z
to unzip the .apk
file.
Then I grepped all the files to see if there were any references to flag
. If there were, I checked them out.
This shows match in "classes.dex"
flag{3asY_4ndr0id_r3vers1ng}
Firstly I used 7z
to unzip the .apk
file.
Then I checked strings to see if there was a flag somewhere. Surprisingly, there was.
flag{4ndr0id_1s_3asy}
Rotten simply required you to use a caesar cipher to decode the text it sent you. Luckily, once decoded, all the text contained the word send
and this allowed us to filter out the correct shift.
This challenge wasn't really anything special, just automate the process of fighting bosses until you have enough money to get a new weapon, rinse and repeat until you get the "tank" which can defeat the gnomes, when you do that the flag is printed.
The title and description implies that K is replaced with J.
So, we install the tool jsteg
and simply run jsteg reveal luke.jpg
.
flag{yeast_bit_steganography_oops_another_typo}
Visiting the site, you can see that the location phphonebook.php
is referenced, however visiting the url as suggested (/index.php/?file=phphonebook.php
) it returns a blank page.
However, there is a trick to get around this - if you add a php filter on it so it encodes the content to base64 as demonstrated below: /index.php/?file=php://filter/convert.base64-encode/resource=phphonebook.php
This returns the source code which contains a very interesting piece of php.
This essentially means, if there is a variable in the POST request named emergency
, it will retrieve the contents of /flag.txt. We did this in two ways, with BurpSuite and with curl, but the curl request was much more simple, all was needed was: curl -X POST 'http://jh2i.com:50002/index.php/?file=phphonebook.php' -d 'emergency=999' | grep flag
Voila, the flag is returned. A relatively simple challenge, but it was definitely interesting to learn about the base64 filter.
Disassembling it with radare2
and gdb
doesn't really seem to spit out anything interesting (as the binary is stripped), but we can use string to see that flag.txt
is within the binary. This hints that there is actually something there.
So, to check it out, I disassembled the binary in GHidra. Sure enough, FUN_0040130e
had some basic C code to read the file and output the results.
All we had to do was overflow the buffer and execute the function.
Using ragg2
I found that the padding was 497 bytes.
flag{legend_of_zelda_overflow_of_time}
Going to /robots.txt
reveals the server source code, along with some authentication checks.
We didn't really do this the intended way.
Set the auth cookie to
which is the encoded form of
This makes the SHA512 comparison always true, allowing you to log in as the admin.
Take apart the javascript.
In there there is a reference to flag
with some base64 next to it.
Decoding the base64 gives us the flag.
Change your User-Agent to the Windows 95 profile and you see the flag.