Gift Abuser

Platform: hackerlab | Category: Forensics | Type: Challenge | Difficulty: Medium | OS: Windows | Author: XESXOR | Date: 2026-04-05 | Status: Solved Techniques: memory_dump_triage, pe_correlation, process_hollowing_detection, xor_blob_decoding

Summary

Task: a ZIP archive contains a 2 GiB VMware Windows memory dump with suspicious desktop executables and injected process artifacts. Solution: trace a hollowed svchost.exe back to the dropped GUI payload, extract its transformed data blob, and XOR it with 0x41 to recover the flag.

Gift Abuser — HackerLab

Description

Organizer description was not preserved with the solved files. The provided archive contained gift_abuser.zip with a single artifact, task_podark.vmem.

English summary: this is a Windows memory-forensics challenge built around malware execution. The goal is not to carve the flag directly from the full dump, but to identify the injected process, reverse the hollowing payload chain, and decode the hidden flag bytes.

Analysis

1. Initial triage

The challenge file was downloaded from the provided HackerLab URL with multi-connection aria2c, then unpacked: ‍​‌‌​​‌​​​‌‌​​‌​​​​‌‌​‌​​​​‌‌‌​​‌​​‌‌​​​‌​​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​​​‍

 bash read-only • copy allowed Copy
aria2c -x 16 -s 16 "https://hackerlab.pro/game_api/files/download?folder=parts_4986cad0-d919-4a64-a03a-a2382e8997c3_data&name=gift_abuser&type=zip"
unzip -l gift_abuser.zip

The archive contained one large file:

• task_podark.vmem — about 2 GiB

Basic triage with file, exiftool, binwalk, and strings showed that this was a raw VMware memory dump from a Windows machine. Volatility identified the system as Windows 10 19044 x64.

2. Volatility process and file correlation

The first meaningful pivot came from process listing. Alongside normal browser processes, one entry stood out: ‍​‌‌​​‌​​​‌‌​​‌​​​​‌‌​‌​​​​‌‌‌​​‌​​‌‌​​​‌​​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​​​‍

• svchost.exe (PID 6804) — 32-bit, running in session 1

That is suspicious because svchost.exe is usually a system service host, and seeing a 32-bit instance in a user session is unusual enough to investigate further.

filescan provided the next clue by revealing suspicious Desktop executables:

• C:\Users\vanya_hacker_2011\Desktop\explorer.exe
• C:\Users\vanya_hacker_2011\Desktop\oh_no.exe

It also exposed VMware shared-folder development artifacts:

• \\vmware-host\Shared Folders\Share\111\ProcessHollowing.exe
• \\vmware-host\Shared Folders\Share\111\HelloWorld.exe
• \\vmware-host\Shared Folders\Share\111\HelloWorld — копия.exe
• \\vmware-host\Shared Folders\Share\111\2\explorer.exe
• \\vmware-host\Shared Folders\Share\111\2\oh_no.exe ‍​‌‌​​‌​​​‌‌​​‌​​​​‌‌​‌​​​​‌‌‌​​‌​​‌‌​​​‌​​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​​​‍

This strongly suggested that the memory image captured a malware-development or testing environment where a demo process-hollowing sample had later been retargeted.

3. Reverse the malware chain instead of chasing browser noise

During solving, local writeups such as Legendary OS, Infection, and Some Kind, plus the memory-analysis HackTricks cheat sheet, were useful for narrowing the methodology: identify the suspicious process, dump related binaries, and correlate PE artifacts with injected memory rather than relying on a blind full-dump flag search. ‍​‌‌​​‌​​​‌‌​​‌​​​​‌‌​‌​​​​‌‌‌​​‌​​‌‌​​​‌​​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​​​‍

That mattered because two early avenues were misleading:

• direct ASCII and UTF-16LE searches for CODEBY{ across the full VMEM returned nothing;
• browser artifacts contained many Yandex searches and Boris-related pages (кот борис, кот борис хакер, Yandex pets pages, meme pages), which looked intentional but turned out to be pure red herrings.

There was even a Boris was here string inside one hollowing binary, which reinforced the false trail without helping recover the flag.

The real path was malware analysis. ‍​‌‌​​‌​​​‌‌​​‌​​​​‌‌​‌​​​​‌‌‌​​‌​​‌‌​​​‌​​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​​​‍

4. What the binaries actually do

Static analysis of the shared-folder PE files showed a very recognizable training/demo setup:

• ProcessHollowing.exe hollowed svchost.exe and replaced it with HelloWorld.exe
• HelloWorld.exe was only a GUI payload that displayed Hello World

The later Desktop/shared-folder pair had the same structure but different payload names:

• explorer.exe was the retargeted hollowing launcher
• oh_no.exe was the payload injected into svchost.exe

oh_no.exe was another simple GUI sample. Its window strings included: ‍​‌‌​​‌​​​‌‌​​‌​​​​‌‌​‌​​​​‌‌‌​​‌​​‌‌​​​‌​​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​​​‍

• Oh no...
• Oh no, your computer is mine now...
• He-he

That fit perfectly with the memory view: hollowprocesses and malfind both confirmed that PID 6804 had executable, non-file-backed injected memory rather than a clean image-backed process layout. GUI window enumeration also showed the same message-box text tied to PID 6804.

So the suspicious svchost.exe was not the original source of the flag by itself; it was the hollowed container for oh_no.exe.

Solution

1. Confirm that direct flag carving is a dead end

‍​‌‌​​‌​​​‌‌​​‌​​​​‌‌​‌​​​​‌‌‌​​‌​​‌‌​​​‌​​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​​​‍

The obvious searches failed:

• ASCII search for CODEBY{
• UTF-16LE search for CODEBY{

That meant the flag was probably transformed in memory or stored inside the payload in an encoded form.

2. Search for transformed versions of the flag prefix

Instead of searching for the literal flag, a custom search was done for single-byte transformed variants of the CODEBY{ prefix across the full memory dump. This located a promising blob at:

• VMEM offset 0x4dfb48f0

The bytes at that location were not plaintext, but they looked like a short encoded string rather than random noise. ‍​‌‌​​‌​​​‌‌​​‌​​​​‌‌​‌​​​​‌‌‌​​‌​​‌‌​​​‌​​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​​​‍

3. Locate the same blob inside dumped payload files

The same transformed bytes were found much more cleanly in dumped oh_no.exe artifacts, especially:

• dumpfiles/file.0xda0602a669d0.0xda06035700a0.DataSectionObject.oh_no.exe.dat
• blob offset inside that file: 0x198f0

Relevant encrypted bytes:

 text read-only • copy allowed Copy
02 0e 05 04 03 18 3a 12 22 01 33 38 1e 11 33 2e 22 24 32 12 1e 29 71 2d 2d 2e 16 28 2f 26 3c 00

This is the key insight of the challenge: the meaningful artifact is easier to recover from the hollowed payload's data section than from the entire 2 GiB memory image. ‍​‌‌​​‌​​​‌‌​​‌​​​​‌‌​‌​​​​‌‌‌​​‌​​‌‌​​​‌​​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​​​‍

4. Decode with XOR 0x41

The blob decodes cleanly by XORing each byte with 0x41:

 python read-only • copy allowed Copy
#!/usr/bin/env python3
blob = bytes.fromhex(
    "02 0e 05 04 03 18 3a 12 22 01 33 38 1e 11 33 2e "
    "22 24 32 12 1e 29 71 2d 2d 2e 16 28 2f 26 3c 00"
)

key = 0x41
decoded = bytes(b ^ key for b in blob)
print(decoded.decode("ascii", errors="replace"))
print(decoded.rstrip(b"A\x00").decode())

Output:

 text read-only • copy allowed Copy
CODEBY{REDACTED}A
CODEBY{REDACTED}

The trailing null byte in the stored blob becomes A after XOR, so the real flag is the string only up to the closing brace. ‍​‌‌​​‌​​​‌‌​​‌​​​​‌‌​‌​​​​‌‌‌​​‌​​‌‌​​​‌​​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​​​‍

5. Final recovery path

1. Identify task_podark.vmem as a VMware Windows memory dump.
2. Use Volatility to fingerprint the host as Windows 10 19044 x64.
3. Spot the suspicious 32-bit svchost.exe in session 1.
4. Correlate it with filescan results showing explorer.exe, oh_no.exe, and VMware shared-folder development binaries.
5. Reverse the process-hollowing demo and confirm that the retargeted version injects oh_no.exe into svchost.exe.
6. Use malfind, hollowprocesses, and GUI window enumeration to confirm PID 6804 is the hollowed process showing the Oh no... message.
7. Ignore the Boris/browser rabbit hole and search for transformed flag-prefix bytes instead of literal CODEBY{.
8. Recover the encoded blob from the dumped oh_no.exe data section.
9. XOR the blob with 0x41 to obtain the flag. ‍​‌‌​​‌​​​‌‌​​‌​​​​‌‌​‌​​​​‌‌‌​​‌​​‌‌​​​‌​​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​​​‍