Upon extracting the archive, we come across such_evil, identified as a 32-bit Windows executable (PE32). Despite lacking a .exe extension, it functions as a typical Windows binary. This underscores the importance of looking beyond file extensions and examining the file’s magic bytes to accurately identify its format and architecture.
file such_evil
such_evil: PE32 executable (console) Intel 80386 (stripped to external PDB), for MS Windows
Running strings reveals standard library calls (msvcrt.dll) and typical Windows executable declarations but there is nothing interesting.
!This program cannot be run in DOS mode.
.text
`.data
%(0@
%,0@
%00@
%40@
%80@
%<0@
%@0@
msvcrt.dll
_controlfp
__set_app_type
__getmainargs
exit
_XcptFilter
_exit
_except_handler3
Using binwalk, the entropy analysis shows normal distribution, suggesting no potential for encryption or compression.
binwalk -E such_evil
Lets jump over to IDA. Recall that because this is a Windows binary, PE, to be able to run this program we will need to be on a Windows machine.
Examining the start function of the program, we see the typical setup of a main function and then a call to sub_401000
The function sub_401000 has many mov instructions and eventually does a load, lea into eax and then calls it. This is typical of shellcode that is written into the program that is unraveled layer after layer then loaded into memory to be executed. Lets set a breakpoint on call eax and step into the shellcode.
Inside the call, we see the first part of the shellcode.
Continuing to step through the execution, we can see that an area of memory is being XOR’d with 66 hex. This is decrypting a string and possible further shellcode. We can set a breakpoint on the jmp loc_19FD60 and run to it.
We can see the string that was being decoded, "and so it begins". Continuing to step through we get to the next part of the shellcode.
Once again, lets run to the jmp loc_19FDD4 and let the program do its decoding. The next strings we see that are decoded is "get ready to get nop'd so damn hard in the paint". If we keep running through we eventually get a decoded string that is the flag.
If you end up going to far and just let the program run, you will get a BrokenByte error.
Flag: such.5h311010101@flare-on.com
In this write-up for the picoCTF challenge "Investigating Reversing 0," we tackle the transformation of flag data in mystery.png. By analyzing how the program modifies the data and applying the reverse logic, we’ll decode the hidden flag.
In this write-up for the picoCTF challenge "WebNet1", we decrypt TLS traffic using a provided private key. Follow along as we use Wireshark to extract decrypted HTTP files and uncover the flag through analysis.
In this blog post, I explore the 5get_it challenge from the FireEye Flare-On series, where I used Ghidra to dissect a 32-bit Windows DLL.
