BalalaikaCr3w - forensics

Infosec mini ctf writeup

the_storm — Mon, 23 Mar 2015 23:09:43 +0000

Category:

Event:

This is the InfoSec CTF writeup.
The ctf was very great. However, I felt it a bit simpler I think that was intended as a basic starting level. Some of the challneges were very interesting others were very straight forward. One thing that make me suffer a bit is the images in the challneges. I always had the feeling that they always contained something (steganography). I also was suffering with some guessing challenges like levle number 9. Yet, the good thing about the challneges is that each one will teach you something. The purpose of the CTF was to share knowledge. Below, you can find my write-up so please read, enjoy and take the best of it.
If you have any questions/comments, do NOT hesitate to contact me.

Thank you InfoSec Institute for the CTF

A pdf version of the solution can be found here.
https://www.dropbox.com/s/uuixb7zqcbyiq5x/solutions.zip?dl=0
If you would like to try the challenges before seeing the write-ups please check them on
http://ctf.infosecinstitute.com/

let's start :)

Level One

Challenge:

“May the source be with you! “

Solution:

Once I saw the word “source” then I expected that the flag will be in the HTML source code. I viewed the source code in my browser, and I managed to see the flag in the first line of the HTML code as illustrated below in the screenshot

flag: infosec_flagis_welcome

Level Two

Challenge:

“It seems like the image is broken..Can you check the file?“

Solution:

I checked the HTML source code and I got the image link which was “img/leveltwo.jpeg” Downloaded the image file and now it is time to analyse the file. The first step I wanted to to check the file type to see if it is actually an image. Executing the “file” command on linux that was the result.

looks like some ascii data inside not an image. Viewing the file content using the “cat” command that was the output “aW5mb3NlY19mbGFnaXNfd2VhcmVqdXN0c3RhcnRpbmc=“. The data is encoded in base64. I managed to know that because of the “=“ that was padded in the end of the text. using the base64 tool to decode that data that was the output “infosec_flagis_wearejuststarting”

Level Three

Challenge:

Nothing was stated regarding explicitly for the challenge. However there was that image that contains a QR code.

Solution:

sent the QR code to the following website http://zxing.org/w/decode?u=http%3A%2F%2Fctf.infosecinstitute.com%2Fimg%2Fqrcode. png
That was the result
.. -. ..-. --- ... . -.-. ..-. .-.. .- --. .. ... -- --- .-. ... .. -. —.
looks like some morse code. We need to find something to decode it. Using the following the website http://morsecode.scphillips.com/translator.html I managed to translate the morse code and that was the result.
“INFOSEC_FLAGIS_MORSING”

Level Four

Challenge:

“HTTP means Hypertext Transfer Protocol”

Solution:

HTTP is a Hyptertext Transfer Protocol. I thought that I might find the flag in any of the headers received from the server. I fired up my burp suite proxy to see what I will get in the HTTP response. These were the headers received from the server.

We can see that the server is setting a cookie in our browser. looks like it is encoding in some way however it has the same pattern as “infosec_flagis_xxxxxxx”
I didn’t know what was the encoding but it looks like some stream cipher. I expected it will be a caesar cipher. I coded this quick script to try all caesar with different steps. The script should stops once it finds the word “infosec”

def decode_ceaser(input_str, n):
    output = []
    for c in input_str:
        temp = 97+((ord(c)-97+n)%26)
        temp = chr(temp)
        output.append(temp)
    return output
for i in xrange(25):
        res = decode_ceaser(encoded_str, i)
        res = ''.join(res)
        if 'infosec' in res:
            print res
            break

and that was the result of running the script

infosec_flagis_welovecookies

Level Five:

Challenge:

No text was written only an image.

Solution:

I think this is steganography problem. It did take a lot of time for me to solve it since I am not that good with steganography. I checked the image with Stegsolve didn’t find anything. I checked it also with steghide but nothing. I checked some online websites and it was this website http://www.futureboy.us/stegano/decinput.html. I uploaded the image to the website and It resulted in some binary array as illustrated below

decoding the binary array I got using the following website http://string-functions.com/binary-string.aspx
and the result was
infosec_flagis_stegaliens

Level Six

Challenge:

“Do you want to download sharkfin.pcap file?”

Solution:

It is is a pcap file which we need to analyse. After downloading the pcap and opening with Wireshark. The first thing I do is to look at the protocol hierarchy and that was the result.

We can see a lot of HTTPS data which probably will not be interested in since we can’t decrypt it. I filtered out all tcp
data using the following filter “!(tcp)” and there was a single udp packet. I followed the UDP stream and that was the stream content. “696e666f7365635f666c616769735f736e6966666564”

Decoding the hex steam content that was the result

“infosec_flagis_sniffed”

Level Seven

Challenge:

Nothing appeared actually in the homepage.

Solution:

I opened the burp suite proxy to try to see the response coming from the server.

looks like we have some base64 data in the HTTP response reason field. Decoding the data we got this:
“infosec_flagis_youfoundit”

Level Eight

Challenge:

“Do you want to download app.exe file?”

Solution:

I downloaded the app.exe file. I thought first of reversing the app and see how it works. I was getting ready to run my windows VM and start the executable. However, I though of running the linux command “strings” quickly and see if I got any thing there. Indeed, I executed the command and that was the result.

The flag: infosec_flagis_0x1a

Level Nine

Challenge:

Solution:

I first expected that this will be a sql injection and I should bypass the login. I tried different SQL injection vectors to login but didn’t receive any output. I then said it might be something easier than that. I tried some dictionary attack on the login page and the following credentials logged in successfully.

username: root
password: attack
Once I logged in the output was
“ssaptluafed_sigalf_cesofni”
we can see that this is the flag but reversed. Reversing it again we have “infosec_flagis_defaultpass”

The flags looks a bit weird for me. I searched the web for the cisco IDS default login credentials but couldn’t find anything. Actually my script took a lot of time running to find the username and password.

Level Ten

Challenge:

What kind of sound is this? Sorcery perhaps??

Solution:

I downloaded the audio file. I expected that the wave audio file might contain something hidden in one of its channels. I examined how many channels the wave file contains. It was only one channel which means probably nothing is hidden in the wave channels. I executed binwalk to see if there is any thing appended or inside the audio file. However, I didn’t manage to get anything. I checked the image on the challenge page it was stating “not listening”. I though then I should find away to listen to what is being played. I changed the playback speed to some values and was listening to the output. Indeed, when I changed the playback speed to 0.22X I managed to listen to

“infosec_flagis_sound”

The URL of the edited file is: http://st0rm.altervista.org/solved.wav

Page 12 of 18

Level Eleven

Challenge:

No it must not be a sound? But wait whaT? [PHP logo]

Solution:

I downloaded the php logo. and it was named “php-logo-virus.jpg” the name is very catchy so I believe it contains our flag. One of the main things to analyse when dealing with images is the exif data. http://regex.info/exif.cgi is one of the best websites to analyse the exif data of images. Using the regex.info website, we managed to extract the following “infosec_flagis_aHR0cDovL3d3dy5yb2xsZXJza2kuY28udWsvaW1hZ2VzYi9wb3dlcnNsa WRlX2xvZ29fbGFyZ2UuZ2lm%a0%86%01” from the “Document Name” in the exif data structure. We see part of the flag and the other part is encoded in base64. Decoding the base64 resulted in: “http://www.rollerski.co.uk/imagesb/powerslide_logo_large.gif” I visited the url and the image contain the word “powerslide”. Hence, our flag should be

Flag: infosec_flagis_powersilde

Level Twelve

Question:

Dig deeper

Solution:

I saw the same image in the first level. I then decided it will be a steganography challenge. I kept digging into the image with all possible ways but I couldn’t find anything. I actually wasted a couple of days in that. Then I decided to move away from the image and check the source code of the page. I checked the source code again to see if it was related to level 1 by any means. I couldn’t find anything obvious. I then decided to compare the html of the two pages to see if there any differences. I used the comparer tool in burp suite to see the difference and that was the result.

Hmmm. We see there is a new css was added to leveltweleve.php file. I decided to check that css file. Now, I started to see the relation between the two levels (Dig deeper indeed). The content of the CSS file was
.thisloveis{

color: #696e666f7365635f666c616769735f686579696d6e6f7461636f6c6f72; }

Looks very interesting. There is no colour with the following value and this looks like a hex value. Decoding the hex value we got:

infosec_flagis_heyimnotacolor

Level Thirteen

Challenge:

What the heck happened here? It seems that the challenge here is gone? Can you find it? Can you check if you can find the backup file for this one? I'm sorry for messing up :(

Solution:

This challenge requires a bit of guessing to get the old file. Out of convention, developers usually name the old files as .old or .bak. or .backup. I tried to access http://ctf.infosecinstitute.com/levelthirteen.php.old and indeed I managed to access the old php file (backup). Opening the file in a text editor

We can see some interesting code commented out here. Our next step is to download the imadecoy file. I downloaded the file and directly executed the “file” command to know what file it is.

As we can see, it is a pcap file. I opened the file with Wireshak and directly checked the protocol hierarchy.

As we can see most of the packets are DNS. I am not sure if that was noise packets or it contains our flag. I checked some DNS packets randomly but nothing catchy was there. Most of the queries were DNS queries to google.com.ph. I decided to exclude all DNS queries because I think they are only noise. After excluding them I saw some HTTP requests. I sorted the packets with size and the 4th packet was JPG image named HoneyPY.PNG. Looks very interesting. Dumping the image, I saw that

Flag: infosec_flagis_morepackets

Level Fourteen

Challenge:

Do you want to download level14 file?

Solution:

The challenge file was dump of database. Browsing the database dump, there were a lot of tables and records. I searched for the word “flag”. I found a table but it didn’t contain anything interesting. However, after that table directly, there was a table named “friends” the fourth record of the table was some Unicode data, which looked very catchy.

(104, '\\u0069\\u006e\\u0066\\u006f\\u0073\\u0065\\u0063\\u005f\\u0066\\u006c\\u0061\\u0067\ \u0069\\u0073\\u005f\\u0077\\u0068\\u0061\\u0074\\u0073\\u006f\\u0072\\u0063\\u0065\\ u0072\\u0079\\u0069\\u0073\\u0074\\u0068\\u0069\\u0073', 'annoying', ‘0x0a');
I decoded the unicode data and it was

infosec_flagis_whatsorceryisthis

Level Fifteen

Challenge

“DNS Lookup”

Solution

I entered google.com to see the output and it was the output of the dig command. I expected that we have Remote Code Execution vulnerability here. I expected that the developer coded this in away similar to

system(“dig”.$_GET[‘dig’]);
I tried to give the following input “s;ls -la” and that was the result

Indeed, it executed our command. We can see the hidden file “.hey”. I “catted” the content of the .hey file and it was “Miux+mT6Kkcx+IhyMjTFnxT6KjAa+i6ZLibC”
The string looks encrypted/encoded in some way. I tried to decode the string with many things like Base16, Base32, Base64, Base91, Base58, Base85 and Caesar but it didn’t work. I noticed the ZlibC that appended to the end of the file. I though that this is a kind of a hint. I kept googling about the Zlibc and trying to find any relation between it and the given text. After a couple of days googling, I tried an encoding technique called ATOM-128 on that website http://crypo.in.ua/tools/eng_base64c.php and indeed it decoded the text which was

infosec_flagis_rceatomized

We searched for what atom-128 means and according to the following question on stackoverflow.com, it is a special type of base64 encoding in which a different order of characters is used.

Best Nike Sneakers | NIKE HOMME

cloudfs forensics(200)

the_storm — Wed, 21 Jan 2015 13:24:56 +0000

Category:

forensics

Event:

Ghost in the Shellcode CTF Quals 2015

We have just finished Ghost in the Shell code CTF in 12th place. Though GITS CTF is usually one of the best CTFs, but this year they weren't that good. The web task had a good idea but wan't correctly implemented, some people got the flag right away from others' exploitations. Forensics tasks wasn't really PURE forensic. Yet, I personally enjoyed the CTF and enjoyed cloudfs challenge.

Cloudfs challenge was a forensic challenge with 200 points. The task description was "find the key". After downloading the task file, we checked the file and it was compressed with xz. After decompressing the file, we got a pcap file. Opening the PCAP file with wireshark, we found around 3K packets. Checking the Protocol Hierarchy of the packets we got the following result: 98.81% of the packets are ICMP packets.

It simply means that the flag must be some ICMP packets. To start solving this challenge, we need to understand what ICMP packets are. The Internet Control Message Protocol is part of the Internet Protocol Suite, as defined in RFC 792. ICMP messages are typically used for diagnostic or control purposes or generated in response to errors in IP operations (as specified in RFC 1122). ICMP protocol has many functionalities like sending error messages, such as Destination unreachable, Time limit Exceeded, etc... One of the ICMP protocol functionalities is ICMP echo request/reply. In the normal ICMP echo packet, the sender usually sends 48 bytes of data to the recipient who should echo back this data. Usually this type of ICMP packets are used to as an indication that the recipient is up and running. In the normal ICMP echo request/reply, the data section should include some of these bytes "11:12:13:14:15:16:17:18:19:1a:1b:1c:1d:1e:1f:20:21:22:23:24:25:26:27:28:29:2a:2b:2c:2d:2e:2f:30:31:32:33:34:35:36:37" and usually the default size of the ICMP echo request is 48 bytes.

By looking at the ICMP packets in the given pcap file. we realized that the size of each packet is NOT 48 bytes. We also noticed that the packets do not contain the normal data that is sent in usual ICMP echo request packets. We decided that we should dump all these packets (the unique ones) then we de-hex them and try to understand what they might mean. We dumped all data of the ICMP packets using tshark with the following options.

$ tshark -r cloudfs -Y "icmp" -T fields -e data > raw_data

Now we have the raw_data of the ICMP echo packets. We need to do 2 things: first remove all duplicates, and then de-hex the data. This can be done with a very simple python script. The following script does what I have explained above.

f = open('raw_data', 'r')
lines = f.read().splitlines()
output = []
output2=[]
for l in lines:
    try:
        val = l.decode('hex')
        if val not in output:
            output.append(val)
    except:
        print "In Exception" + l

w = open('output_raw_decoded', 'wb')
for i in output:
	w.write(i)
w.close()

Now we have the unique data dumped into a file and decoded. The next stage we should think of is to try to understand this data. What is this file. I checked the output_raw_decoded with the file command but it just show its type as "data". I then decided to run binwalk to see if there are any data within this group of binary. Indeed, binwalk show us the following result.

We can see s bzip2 compressed file here. We dumped the compressed file using dd with the following options

$ dd if=output_raw_decoded of=compressed_output skip=1480 bs=1

Now we have another file which we should check its type and see what is inside. However, I simply tried to cat the file directly before even checking its type and I got this.

We can see the key now ...

key{WhyWouldYouEverUseThis}

I hope you enjoyed the write-up

Regards

Asics shoes | Buy Yeezy Slides 'Core' - Kanye West x Adidas — Ietp

vodka (forensics 400)

the_storm — Sat, 01 Nov 2014 19:13:51 +0000

Category:

forensics

Event:

No cON Name CTF Finals 2014

Description: We were given a pcap file called vodka were asked to get out the flag.

Solution:

We opened the pcap file with wireshark and take a look the statistics of the pcap file, we saw that 100% of the packets in the file was mainly tftp protocol packets.

Looking at the first packet in the pcap, we see a write request with a file named "openwrt-wrtsl54gs-squashfs.bin" and then we see the blocks are send with size 558 bytes and after each block we see an acknowledgment of receiving the block.

What we simply need now is to dump that binary file from the pcap. Using this command on tshark:

tshark -r vodka.pcap -Y "tftp and tftp.opcode==3" -Tfields -edata > openwrt-wrtsl54gs-squashfs.hex

The file now is dumped. However, it is in hex not in binary because the output of tshark is in hex. We wrote a simple python code to change the file from hex to binary.

f = open('openwrt-wrtsl54gs-squashfs.hex', 'r')
w = open('openwrt-wrtsl54gs-squashfs.bin', 'wb')
lines = f.readlines()
for l in lines:
	w.write(l.strip('\n').decode('hex'))
w.close()

Now we have the binary file. The first thing we did is we ran the "file" command trying to now the type of the file, but the output of file was nothing except "data". Then we use "binwalk" and that was the result of binwalk.

DECIMAL       HEX           DESCRIPTION
-------------------------------------------------------------------------------------------------------
32            0x20          TRX firmware header, little endian, header size: 28 bytes,  image size: 1323008 bytes, CRC32: 0x6CAC483 flags/version: 0x10000
60            0x3C          gzip compressed data, from Unix, NULL date: Thu Jan  1 02:00:00 1970, max compression
517152        0x7E420       Squashfs filesystem, little endian, version 2.1, size: 805671 bytes,  269 inodes, blocksize: 65536 bytes, created: Wed Oct 29 20:53:25 2014

So, there is a squash file system and there is a firmware. We thought that we will get the squashfs using dd, mount it and then get the flag. We "dded" the binary file and tried to mount the squash file system, but the mount has failed. Probably, to mount the squashfs correctly we need to read the firmware to extract some options and then we should be able to mount the squash fs correctly. We googled a bit about the squash fs and TRX firmware and we found this tool.

We downloaded the tool and compile it. Using "extract-firmware.sh" in the tool with the openwrt-wrtsl54gs-squashfs.bin as input, we managed to mount the squash file system correctly. Browsing the squashfs folder, we found three folders: "image parts", "logs" and "rootfs".

That was the content of the rootfs:

I entered the rootfs and found a minimal linux system. Not sure were to go in this system, I assumed that there will be something inside the "www" folder. I checked it, but it was empty. I decided to grep the entire system for the word "flag". I found a huge output. That was one of the lines in the output of the grep command.

Looks like the nc file is interesting. I checked the file, it was basically a bash file. Checking the source code of the nc file, I found in the comments this section.

######################
### Draw rainbow flag
######################

I decided to run the nc file after making sure it doesn't have something malicious, and that was the result of running it.

Looking at the bottm right corner of the output we see "NCNdeadface" which was simply the flag.

flag: NCNdeadface

PS: I managed to solve this after the end of the competition with like 15 mins. The reason why, is that the grep on flag returned a huge amount of data.

Running sports | jordan Release Dates

Secret host (forensics 100)

azrael — Mon, 17 Mar 2014 13:32:59 +0000

Category:

forensics

Event:

RuCTF Quals 2014

Here we need to find something hidden on host http://10.100.0.1/ using given openvpn configs and dump.

We connected to VPN with given configs but system is required to authenticate. After using strings on dump we got login and password SuperPuperRoot / VeryStrongSecret. So we have authenticated in VPN and went on http://10.100.0.1/. There is we got a page with this source code:

<html>
<body>
	<h1>It works!</h1>
	<p>This is the default web page for this server.</p>
	<p>The web server software is running but no content has been added, yet.</p>
	<p style="color: white">Your secret information is RUCTF_29793ced32a8c89481c83827cf24647a</p>
</body>
</html>

Flag is RUCTF_29793ced32a8c89481c83827cf24647a.

latest Nike Sneakers | Zapatillas de running Nike - Mujer

Attachments:

openvpn.5df2789228a89cdcd1ff58e3e650df0f.7z

NEOQUEST 2014 Quals - Отмороженный компьютер

Dor1s — Tue, 04 Mar 2014 09:37:19 +0000

Category:

forensics

Event:

NeoQuest Quals 2014

Дан .vmem дамп памяти, по легенде, полученный с помощью Cold Boot Attack .

Из дампа среди всего прочего можно вытащить .html страницу (руками или через foremost) для ввода кодов деактивации ракет:

По легенде как раз нужно найти "коды отмена пуска ракеты или хотя бы что-то?".

Посмотрим список процессов (например, через фрэймворк volatility):

 doris$ ./vol.py -f ../../neoquest2014/vmem/win2.vmem --profile Win7SP1x86 pstree
Volatility Foundation Volatility Framework 2.3.1
Name                                                  Pid   PPid   Thds   Hnds Time
-------------------------------------------------- ------ ------ ------ ------ ----
 0x8459f190:wininit.exe                               392    320      3     75 2014-01-27 09:58:15 UTC+0000
. 0x8623a530:lsass.exe                                484    392      6    526 2014-01-27 09:58:15 UTC+0000
. 0x86212530:services.exe                             476    392      9    196 2014-01-27 09:58:15 UTC+0000
.. 0x86355378:svchost.exe                             768    476     18    459 2014-01-27 09:58:16 UTC+0000
... 0x8638fa50:audiodg.exe                            980    768      6    149 2014-01-27 09:58:17 UTC+0000
.. 0x846a8a88:wmpnetwk.exe                            780    476     10    254 2014-01-27 09:59:33 UTC+0000
.. 0x8471a538:svchost.exe                            2328    476     21    427 2014-01-27 10:00:24 UTC+0000
.. 0x85c7ad40:spoolsv.exe                            1300    476     12    267 2014-01-27 09:58:19 UTC+0000
.. 0x86396758:svchost.exe                             920    476     34   1107 2014-01-27 09:58:17 UTC+0000
.. 0x8623da60:svchost.exe                            1436    476     15    233 2014-01-27 09:58:20 UTC+0000
.. 0x85c525a0:svchost.exe                            1188    476     15    363 2014-01-27 09:58:19 UTC+0000
.. 0x863282c8:svchost.exe                             680    476      7    256 2014-01-27 09:58:16 UTC+0000
.. 0x86221030:svchost.exe                            1328    476     17    301 2014-01-27 09:58:19 UTC+0000
.. 0x86316030:SearchIndexer.                         1544    476     11    646 2014-01-27 09:59:32 UTC+0000
.. 0x86364538:svchost.exe                             828    476     17    425 2014-01-27 09:58:16 UTC+0000
... 0x84637398:dwm.exe                               2020    828      3     71 2014-01-27 09:59:24 UTC+0000
.. 0x863bb030:TrustedInstall                         1088    476      4    158 2014-01-27 09:58:17 UTC+0000
.. 0x866dd770:taskhost.exe                           2016    476     12    235 2014-01-27 09:59:23 UTC+0000
.. 0x86307d40:svchost.exe                             608    476     10    360 2014-01-27 09:58:16 UTC+0000
... 0x84724d40:VBoxSVC.exe                           2796    608     12    537 2014-01-27 10:00:52 UTC+0000
.... 0x8467dd40:VirtualBox.exe                       2076   2796     34    728 2014-01-27 10:03:47 UTC+0000
.... 0x8477b840:VirtualBox.exe                       3116   2796      0 ------ 2014-01-27 10:01:04 UTC+0000
.... 0x846cc030:VirtualBox.exe                        756   2796      0 ------ 2014-01-27 10:02:35 UTC+0000
... 0x846502e0:WmiPrvSE.exe                          3952    608      7    109 2014-01-27 10:02:25 UTC+0000
.. 0x845d1d40:mscorsvw.exe                           2288    476      7     73 2014-01-27 10:00:21 UTC+0000
.. 0x8477e030:wermgr.exe                             2644    476      1      0 2014-01-27 10:12:24 UTC+0000
.. 0x863801b0:svchost.exe                             888    476     12    280 2014-01-27 09:58:17 UTC+0000
. 0x8623d438:lsm.exe                                  492    392     10    136 2014-01-27 09:58:15 UTC+0000
 0x861a6030:csrss.exe                                 356    320      8    362 2014-01-27 09:58:15 UTC+0000
 0x845336c0:System                                      4      0     84    658 2014-01-27 09:57:50 UTC+0000
. 0x8585d4d0:smss.exe                                 260      4      2     29 2014-01-27 09:57:50 UTC+0000
 0x8594ed40:csrss.exe                                 400    384      7    203 2014-01-27 09:58:15 UTC+0000
 0x85819810:winlogon.exe                              440    384      3    114 2014-01-27 09:58:15 UTC+0000
 0x84656780:explorer.exe                             2004   2000     21    761 2014-01-27 09:59:24 UTC+0000
. 0x8471ed40:VirtualBox.exe                          2764   2004      7    400 2014-01-27 10:00:51 UTC+0000
. 0x85a5fa60:notepad.exe                              864   2004      1     60 2014-01-27 10:06:23 UTC+0000

Особый интерес вызывают VirtualBox.exe (pid=2076) и notepad.exe (pid=864).

Сдампив память данных процессов (опять же через volatility):

doris$ ./vol.py -f ../../neoquest2014/vmem/win2.vmem --profile Win7SP1x86 memdump -p 2076 -D ../../neoquest2014/vmem/virtualbox/
doris$ ./vol.py -f ../../neoquest2014/vmem/win2.vmem --profile Win7SP1x86 memdump -p 864 -D ../../neoquest2014/vmem/notepad/

обнаруживаем следующее:

Страничка в браузере была открыта на виртуальной машине;
В форму на странице были введены символы (cb0c27fda09a86a4bdea244d - 24 символа, а ключ должен быть 32). Их можно обнаружить, например, при поиске по дампу по ссылке на локальный ресурс http://10.0.31.148 (строка в юникоде);
В том месте дампа, где должны быть отображены все 32 введенных символа, все байты перезаписаны значением 0x20 (код пробела). Позже становится понятно, что это было сделано специально для усложнения задания.

Напрашивается вывод, что нужно искать изображение, которое было на экране.

В дампе памяти процесса notepad.exe (pid=864), можно обнаружить следующую полезную информацию:

Был открыт файл C:\Windows\system32\NOTEPAD.EXEC:\Users\komsomol\VirtualBoxVMs\KP-2\Logs\VBox.log, который содержит в себе следующие данные:

<...>
00:00:02.075516 Display::handleDisplayResize(): uScreenId = 0, pvVRAM=065c0000 w=640 h=480 bpp=32 cbLine=0xA00, flags=0x1
00:00:04.545335 Display::handleDisplayResize(): uScreenId = 0, pvVRAM=065c0000 w=640 h=480 bpp=0 cbLine=0x280, flags=0x1
00:00:04.598215 Display::handleDisplayResize(): uScreenId = 0, pvVRAM=00000000 w=720 h=400 bpp=0 cbLine=0x0, flags=0x1
00:00:04.650237 PIT: mode=2 count=0x10000 (65536) - 18.20 Hz (ch=0)
00:00:04.655742 Guest Log: BIOS: Boot : bseqnr=1, bootseq=0213
00:00:04.664736 Guest Log: BIOS: Booting from CD-ROM...
00:00:11.337163 Display::handleDisplayResize(): uScreenId = 0, pvVRAM=065c0000 w=1024 h=768 bpp=24 cbLine=0xC00, flags=0x1
<...>

0x065c0000 - адрес видеопамяти виртуальной машины!!!

Обратившись в memmap процесса VirtualBox(pid=2076):

VirtualBox.exe pid:   2076
Virtual    Physical         Size DumpFileOffset
---------- ---------- ---------- --------------
<...>
0x065c0000 0x194d8000     0x1000      0x2384000
<...>

получаем смещение видеопамяти в дампе - 0x2384000.

Далее считываем данные из дампа (полученного с помощью memdump -p 2076) по адресу 0x2384000, пишем в файл и читаем ключ на картинке (скрипт sharedVideoMemory.py):

Добиться нормальных цветов можно переставив байты, соответствующие цветовым компонентам, в правильном порядке. Впрочем, это совсем не обязательно.

Ключ: cb0c27fda09a86a4bdea244d8a494820

jordan Sneakers | 『アディダス』に分類された記事一覧