Capture the Flag

[BioHazard]

Okay, the NSA's demon spawn it is then! Taking another look at Ghidra now. LOL, how fitting that we're using a tool released by the NSA to discover secrets. If they're giving something this powerful over to the public, imagine how evil they're super-secret stuff is ...


Far out, could installation of the Open Java Development Kit been made any more difficult? LOL, just love having to google how to install a basic dependency.

Alriiighty then - the evil serpent is now up and running! Hello, Ghidra. Haha, you know that icon of the snake eating its own tail is a popular secret-society symbol, right? Goes all the way back to ancient Egypt and later used by the Gnostics. The Ouroboros! Wonder what our evil masters are trying to tell us? That we're infinitely banging our heads against a wall in a futile attempt to resist?

Hang on, Ghidra is even more complex than IDA! What am I supposed to do here. Import the LH file as 'raw binary'? And then what??? LOL, throw me in at the deep end why don't ya?

Look, I can recognize a limited variety of assembly language statements. And can use that recognition to formulate some basic logical deductions. But I can't read and interpret the language as a whole like I can with Lua. So (short of months of study) I'm not seeing a way to progress with this. Won't de-obfuscation require someone with a firm grasp of assembly code? Or am I missing something with your clues?

In the meantime, I'm also having a look at RetDec (Retargetable Decompiler) and its IDA plugin which supposed to be able to decompile files opened in the IDA disassembler. Maybe it's easier to understand?

[Imagine Programming]

Haha! Well, the assembly is hard to understand if you never used it; therefore I mentioned Ghidra, it's free, Java (and open source) so you can see what is inside Ghidra and Ghidra will decompile the assembly code to a readable C-like language. The LH exports a single assembly named Obfuscation0 - this contains some code and two subroutines. Disassemblers like Ghidra and IDA64 often identify those subroutines as functions (because they are, cdecl convention).

Also, attaching a debugger to autorun.exe is not pointless - but cumbersome, you'd have to break at several points in the MemoryEx.lmd module right before the assembly code is executed so that you can discover where the assembly is loaded in memory. Once you figure that out, you can set a breakpoint in the assembly. This is just too much work.

The 'HAHAWTFKEY!!' string is a defined data label in the assembly that is used in some routine in there

[BioHazard]

I can see the obfuscation routine in the disassembled code - but how I am supposed to understand what I'm looking at? You're going to have to walk me through this, IP. Just pretend like I'm completely retarded - which I kinda am as far as this one goes

PS.
Am I correct in assuming that going in through the autorun.exe, by firing up the debugger in IDA, is kind of pointless? Because the text-strings are obfuscated and can therefore see no way to find where to set breakpoints? And should I therefore just stick with trying to analyse the disassembled LH file?

PPS.
What's the significance of the 'HAHAWTFKEY!!' text-string???

[Imagine Programming]

orlh is a variable you have shown in a screenshot before, "<3" is a function in that loaded LH file (in the Lua part of it). Try to find it!

Any version of IDA will work, but IDA shows disassembled code which might be hard to read and analyze if assembly is new to you. Ghidra is, even though it's by the NSA, much more powerful in my opinion.

[BioHazard]

herrin indeed, the On Key of that input invokes some code! Follow the code!

Okay, so here's the code from that On Key event:

if (e_Key == 13) then 
    orlh["<3"](orlh, Input.GetText(this))
end

... which just reveals that user input is to be grabbed from the Imput field if the Enter key is pressed. But I'm not familiar with the part of the code which is referencing the LH file ...

orlh["<3"](orlh

Do you understand the significance of that part, herrin? I'm looking through the documentation of the MemoryEx plugin but can't see anything useful that will help us. Will have to go back in with the disassembler, I think?

Nb.
IP, I'm using the feeware version of IDA v7.0.
I do have the right tool, don't I?

[Imagine Programming]

Okay, here's what I've found so far, IP:

The source code from the CDD's proj.dat reveals precisely nothing. LOL, because there's basically nothing in there except for this 'decoy message':




... and also this line which just reveals your MemoryEx plugin loading the Lua Header file from the Docs folder:

Hehe, do you like that decoy message? Anyhow, you're on the right track when it comes to reversing it - quite accurately too! Just a few more steps to take!

So we know that any and all information regarding the password is stored in that LH file. And that the LH file is a compiled binary. So it's also known that we need a debugger/disassembler to analyse it.

But there are two basic obstacles thwarting me

i) Local debuggers familiar to me (ie OllyDbg, x32dbg, Zeta Debugger, etc) are entirely useless for this particular task - because they can't disassemble LH files. And using them to hook into the target's running process via the autorun.exe doesn't reveal anything useful. (Unless I'm having a 'homer moment' and missing the obvious. Haha, wouldn't be the first time). In fact Zeta Debugger just reports debug info as being 'stripped'. And Ollydbg just seems to lock up. And when using OllyDbg's Step'N'Search plugin to find entry-points on password input, it then just seems to keep running in an endless loop and punishing my CPU in the most unholy of ways. Leaves me scratching my head in bewilderment?

ii) Which all leads me back to your most recent clue: to disassemble the LH file with either IDA Pro or the NSA's demon spawn, Ghidra. LOL, it just *****s me up that they chose to name their software after an armless, bipedal, bat-winged dragon with three heads and two tails. Must have been a day of self-reflection for the NSA when they came up with that one.

So I went with your clue and tried those programs. Even had a whack at it with Binary Ninja. However when looking at the disassembled code in these programs, I really have no idea how to proceed. Normally, I'd expect to see a way to get the target-program's process up & running so a search could be made for entry-points on the password field. But I can't intuit how to work with these program's (at least not without wading through all their documentation). So short of doing just that, it's safe to say - I'm STUCK!

Maybe Rex has some ideas about how to do this? Or I think we might need more clues. Keep in mind, there aren't actually that many here who'd even be familiar with what IMXLH is. Let alone how to reverse it.

Debuggers do in fact help you out when autorun.exe is running, but you need to know where to set the breakpoint. What is behind a function call routine (i.e. loadedLH.AssemblyName) - that would take a lot of work to reverse, considering you have to jam your debugger through all the code executed by AMS and Lua before the instruction pointer is set to the start of the assembled code. So using a debugger on autorun.exe would work, but would cost you a lot of effort.

When you look at the disassembled LH module and view all the contents in IE IDA64, there should come a point in which you might recognise something. Press C after points of recognition, and with a certain attempt IDA will know what to do. I'll stop now before I give too much away haha!

herrin indeed, the On Key of that input invokes some code! Follow the code!

[herrin]

something here too

[BioHazard]

Okay, here's what I've found so far, IP:

The source code from the CDD's proj.dat reveals precisely nothing. LOL, because there's basically nothing in there except for this 'decoy message':




... and also this line which just reveals your MemoryEx plugin loading the Lua Header file from the Docs folder:



So we know that any and all information regarding the password is stored in that LH file. And that the LH file is a compiled binary. So it's also known that we need a debugger/disassembler to analyse it.

But there are two basic obstacles thwarting me

i) Local debuggers familiar to me (ie OllyDbg, x32dbg, Zeta Debugger, etc) are entirely useless for this particular task - because they can't disassemble LH files. And using them to hook into the target's running process via the autorun.exe doesn't reveal anything useful. (Unless I'm having a 'homer moment' and missing the obvious. Haha, wouldn't be the first time). In fact Zeta Debugger just reports debug info as being 'stripped'. And Ollydbg just seems to lock up. And when using OllyDbg's Step'N'Search plugin to find entry-points on password input, it then just seems to keep running in an endless loop and punishing my CPU in the most unholy of ways. Leaves me scratching my head in bewilderment?

ii) Which all leads me back to your most recent clue: to disassemble the LH file with either IDA Pro or the NSA's demon spawn, Ghidra. LOL, it just *****s me up that they chose to name their software after an armless, bipedal, bat-winged dragon with three heads and two tails. Must have been a day of self-reflection for the NSA when they came up with that one.

So I went with your clue and tried those programs. Even had a whack at it with Binary Ninja. However when looking at the disassembled code in these programs, I really have no idea how to proceed. Normally, I'd expect to see a way to get the target-program's process up & running so a search could be made for entry-points on the password field. But I can't intuit how to work with these program's (at least not without wading through all their documentation). So short of doing just that, it's safe to say - I'm STUCK!

Maybe Rex has some ideas about how to do this? Or I think we might need more clues. Keep in mind, there aren't actually that many here who'd even be familiar with what IMXLH is. Let alone how to reverse it.

[Imagine Programming]

Hint: Use Ghidra, BinaryNinja or IDA64 on the LH module

[BioHazard]

Edit,
You can get full resolution of the screenshot (in Clue#1) by opening it in a separate browser window: https://i.imgur.com/Mlx40or.png
Sorry about that.

[BioHazard]

Here are the screenshots that should prove I solved the challenge. I at first didn't use a debugger to solve it, so I couldn't find the easter egg. I asked Bio about this and he instructed me to use one, so the beautiful easter egg shows up. Nice touch, I really love how you even took that into consideration!

Ah-hah, yes. Never doubted you for a second, sensei! Nicely done. And happy that you liked my little 'easter egg' (LOL, shame it's not quite Easter yet). I actually wanted to consult you with that one. Originally, my intention was to code for detection of both 'local' and 'kernel mode' debuggers. Detecting for local debuggers was simple enough but couldn't quite get the call parameters correct for 'remote' (kernel mode) debuggers. Will PM you about that - am guessing that you'll probably know the missing puzzle piece?

...I also increased the points for obfuscation-routine0 ... I might have made it a bit more difficult than I anticipated. If anyone doing that challenge has the feeling they're not making progress, ask for another hint

Right then, I'll be taking a closer look. I have the day off from work tomorrow (Wednesday) so will have some free time to investigate properly. Haven't used IMXLH before (just some basic reading) so even though I have the project's sourcecode and can see the LH file in there, am not really sure exactly what I'm looking at. Need some time to analyze, think and reflect. It ain't over till the fat lady sings!

How about you, herrin? Any ideas about how to proceed with IP's challenge? LOL, maybe we can team up to collude and conspire? Doubt I can 'whip' IP all by myself - his kungfu is always lethal!
.....................................


Nb.
My Daffy Duck challenge is now up alongside IP's example, on his new CTF website at: https://amsctf.0xb.nl. So for anyone else who's managed to capture its flag, you can submit your answer over there. (Or you can just PM me the password - if you haven't yet registered a new account with IP). And here's some clues for anyone still trying to capture Daffy Duck's password:

Clue #1:
Herrin's already revealed an important clue with the screenshot he posted (in post #5). It displays the code I used to create a custom cryptoKey generator. Here's a screenshot of that same code snippet - but taken from the code-commented version of my project.apz:




Clue #2:
And here's a screenshot of another important piece of the project's code:




Clue #3:
Both of these code-blocks are required to reverse the encryption process that protects the application's password (which is stored locally as encrypted substrings). Decryption requires concatenating the password substrings, followed by:

• 5-pass Blowfish decryption
• Single-pass RC4 decryption

Clue #4:
The crypto-keys required for the decryption process are obfuscated. That's what the cryptoKey Generator is for.

There ya' go - practically giving it away! Who else is up for the challenge then? How about you, Ulrich? Can we pique your curiosity enough to get involved in this thread? And Rexxy - where are you, mate? Dare say it won't take you very long to figure this one out. And lastly (but never leastly) how about some of the newbies? You're all welcome here and among friends. So don't be too shy about putting in your two cents worth!

Come one, come all.

[Imagine Programming]

Here are the screenshots that should prove I solved the challenge. I at first didn't use a debugger to solve it, so I couldn't find the easter egg. I asked Bio about this and he instructed me to use one, so the beautiful easter egg shows up. Nice touch, I really love how you even took that into consideration! BioHazard

(EDIT) - I also increased the points for obfuscation-routine0, as it didn't seem fair that it was worth less than Bio's challenge. I might have made it a bit more difficult than I anticipated. If anyone doing that challenge has the feeling they're not making progress, ask for another hint

[Imagine Programming]

I can't give too many tips, however I didn't prevent debuggers. I also don't prevent you hooking into functions, so you could technically separate the Lua part from the rest of the LH file. Also, remember what you can add to an LH file; it's not just Lua, it allows for another language...

[BioHazard]

really a great job
compliments bio
to study in depth

Hey now, that didn't take you long to break my initial security to get at the proj.dat, Herrin. Well done! Remind me to double-padlock all of cupboards if you ever come around to visit, haha!

I see you found my custom cryptoKey Generator! But LOL, you'll still have to reverse the encryption process to get at the password - a task which has been known to induce a migraine or two. Good luck, you're halfway there!

Here's another one. The challenge in this one is to find the correct password and post it to amsctf.0xb.nl after you've applied for an account. This one should not be too difficult, but it might throw people off as well. Think out of the virtual box, because there is none! ...

Well, I have your sourcecode. And can see your evil MemoryEx plugin has been used. I also have your obfuscation-routine0.LH file but am not sure where to go from here. Wouldn't this require knowledge of how to decompile Lua Header files? Am going to need some tips or clues to move forward with this one, sensei?

[Imagine Programming]

Here's another one. The challenge in this one is to find the correct password and post it to amsctf.0xb.nl after you've applied for an account. This one should not be too difficult, but it might throw people off as well. Think out of the virtual box, because there is none! Don't share screenshots of the correct password, however show a screenshot of the amsctf website displaying that you have succeeded.

obfuscation-routine0.zip