Ok, so the fourth challenge is again a zip file (hash: 1A2570D5CC6E2C3A185E939DC49CB4B908B867E02AC84BF7ABB532B3395FB01A) and it contains a file fun.docm (hash: 4AE794A701D2F28BA7E6292F0463444F6A567CB7C26188A518270544252877FB). Now the first thing you need to know about the newer office file formats is that they are all zip files. So yes a DOCM and a XLSX and a PPTX, etc are all ZIP files with various contents pieces inside (see here for other zip based documents)
SIDENOTE: this is one of the very reasons that I wrote my FileId tool to begin with. Most file identification apps don’t go very much beyond magic headers. If we understand that the magic header gives us a container format (i.e. Ole Structured Storage [OLESS], ZIP, and many others), then we can parse that container and gain much more information. This is exactly what FileId does it understands OLESS files and ZIP files and has some ideas what to look for inside to figure out its true file type.
SIDE-SIDENOTE: Of course since its a container then we can do nasty things that were never intended to be done…like having a DOC, XLS, PPT all in a single file and all open completely different content depending on which app is opening it.
ok, back to the challenge at hand and DOCM file! we can verify its a DOCM by running it through FileId or we can simply run 7zip and extract the contents…which is what I did. Since its truly a DOCM we will find a file inside the WORD subfolder named vbaProject.bin (it actually doesn’t have to be named this, but I digress). I also happen to know that this is also an OLESS file, so again we can run it through FileId, but there is a known bug in FileId here…
So here we have a couple of choices as what to do next, but the underlying principle is to get to the VBA…here are several options (I did them all):
so there’s a bunch of stuff…now what. Well I spent waaayyy to much time deobfuscating & renaming every function to something more meaningful and useful. So I have a DOCM that is cleanedup and safe to open (i.e. no Document_Open subroutine, no passwords or anything). Get it here: 19E8BE71029D5900C54EB2213E097BC442003C1F4F5E7940B71F9902A00270FB.
like I said I spent too much time going over each function, figuring out what it does and renaming it (yes I wrote some tools for this, but they’re not ready to share).
If you look at the code in the clean-up document take a look at the last few functions in the `mod1’ module:
The test subroutine is something that I put in to get the key out, but I figured all the parts and peices by going through each function and figuring out what they do, where it was pulling values from and what the values were in some cases. The only suggestion I have is get good at debugging!
After that I noticed an oddity in this fnCheck function (orginally it was named XWn5TNdoykQb0QoitVEG7sLOxIRSi97XmqmM) - it would do a check and then show a message box. Hmm, I wonder what the value would have to be in order to have the message box show? Well since I had just done a brute force exercise a few minutes eairler (see DOC 02) I started using the brute force routine to get out the expected value….but after a few minutes it hit me…wait I have the exact value its looking for… the value of ‘frm2.Tag’