Capture the Flag

[BioHazard]

Just reviving this thread a little with this APZ - thrown together for the purpose of string encryption-decryption using a purely Lua-based technique. Is based on some source code I stumbled across at: https://forums.coronalabs.com/topic/...ion-decryption

Basically, it encrypts/decrypts any given string via a completely non-standard (custom) encryption routine that is entirely Lua-based. No external dependencies are required. Output can be manipulated via a table of Seed Keys with which to:

• randomize the encrypted output string
• manipulate length of output string

At the moment, the Seed Keys are set to randomly select values between 10 and 100 but these can be changed easily. For example, if the Seed Keys button was set to randomly select values from 100 to 1000, it will output much longer encrypted strings (and vice-versa).



The APZ here is probably still a little buggy - haven't had time to check function integrity thoroughly yet. Just thought I'd leave it here for open discussion and for folks to investigate. There's probably a ton of ways to make improvements. Foremost in my mind would be to compile the core function in Globals to DLL. Maybe IP could even envisage how to harden security for this technique by integrating it with MemoryEx and Assembly code? Feel free to post your thoughts/ideas.

Nb. I've thrown this up on Rex's Discord channel too - for anyone who wants to discuss it over there:

[kingzooly]

Sorry for the late reply I use a tool provided by someone that requested for me not to share it, and to this day I don't, I did do it the way the old tutorials did in the past but that was taking two long, I no longer have contact with the user so I can't ask him if we can release it plus it's buggy it does not always complie on some computers we never found out what created this bug.

[BioHazard]

... as long as Lua code, plain text or compiled, is loaded into memory at some point for the Lua VM to execute the code can easily be extracted. No matter how much obfuscation routines and encryption you apply, the answer is then in memory.

Definitely noted, IP. And yes, worth clarifying.

The best you can do is simple obfuscation that is small, fast and unobtrusive...

With this in mind, would you mind taking a quick look at something for me in private? Have sent you a PM.

[Imagine Programming]

BioHazard as long as Lua code, plain text or compiled, is loaded into memory at some point for the Lua VM to execute the code can easily be extracted. No matter how much obfuscation routines and encryption you apply, the answer is then in memory. This is still the case for virtualized applications, because in the end, those cannot virtualize the Lua bytecode - only machine instructions.

The best you can do is simple obfuscation that is small, fast and unobtrusive. I did find a point in using Lua that I accepted that all my Lua code is basically open source, haha!

[BioHazard]

...I am not dead in MS ... I use discord now

I was about to launch a search-N-rescue mission for you, Rex. This place can't afford to have yet another veteran go MIA.

Yeah look - I'm pretty much in agreement with your whole outlook in regards to project security. For the most part, the thread was started just for the benefit of any users (particularly the newbies) who wanted to look into some of the various protection techniques available to them. But even with a dedicated thread like this, I can't seem to generate any interest in the topic, beyond the input already provided from IP and Herrin.

Though, I do think this thread has the potential to spawn some interesting ideas - if only there were enough knowledgeable coders left here to participate. I had in mind the idea of developing some pure Lua encryption techniques that don't actually require any external libraries or plugins. It's a bit of specialist area but think it could open up discussion to some truly unique approaches that haven't been tried on this forum before.

...the max I do is complie the source code to a lua dll

Hey listen, I've been meaning to ask you about how you're compiling to DLL? I know there's a few old tutorials laying about for compiling from Pure Basic, Dev-C++ or from Visual Studio. But did you say you're actually compiling to DLL directly from Lua scripts? How? And with what tools? It'd be great if you could upload a basic 'hello world' example. I'd be keen to get a look at it. Any chance of that?

[kingzooly]

I am not dead in MS I just don't really add a layer of protection to any of my apps I make anymore wastes way too much of my times, plus I not used any kind of forum since last time I posted here, I use discord now, it's a much faster platform to chat on, easy means to share ideas images and files and also be friendly.

The thread is look and nice to see your all playing in the same ball park again but I dropped this topic a long time back I don't need to hide my work, the max I do is complie the source code to a lua dll just so it's easier to update source only when I don't need to update a UI part of the app.

I will keep looking at this post but I don't tihnk I going to take time in to it as it's not something I care about anymore, but AMS is not dead in my house lol even the wife keeps thinking what project could she do to start learning it.

[herrin]

I join the request of Bio

see you
regards

[BioHazard]

Seems to be a lack of general interest, IP. But for what it's worth ... I'm still interested.

[Imagine Programming]

I'll try to create a tutorial for my challenge this week, when life gives me some time ha!

[BioHazard]

Oh yeah - password is: [email protected]!!!

[BioHazard]

Hmm, still nobody else able to capture the password, eh?

Maybe this has given everyone a migraine? Or maybe just no-one else interested enough to try? Oh well, never mind. Regardless, think this has been up long enough now. And is time to post the APZ solution.

First, I should probably concede that although no-one else has captured the password, that fact is probably not an accurate reflection of the level of security this example provides. IP has already demonstrated that for any skilled coder, defeating the security is child's play. And Herrin also demonstrated that despite my best efforts, stripping the outer security can be done in a matter of seconds for any familiar enough to do so. And kudos to both of you for making light work of my hard work, haha!

Anyway, as promised, attached is the fully code-commented version of the APZ from which this example was compiled. Now, for anyone who did find this one big headache, try Irish-ing up yer coffee with a stiff belt of Jack Daniels first and then take another look using the attached APZ solution. If you follow the code-commenting, you'll see that it's actually quite logically organized and not all that difficult to follow. Made it a point to streamline the whole process so it's be understandable to everyone. So take a look and if you still have questions, don't be afraid to ask.

[BioHazard]

...I think I made this one a bit too difficult haha!

Mmm - yes, Or perhaps I'm just too dumb!

I think maybe that any challenges presented here should probably be limited to ideas and techniques that are Lua focused. Otherwise we're going to hit a bit of a 'brick wall' where nobody can understand what's going on. Stuff that requires analysis of assembly-code is likely to go over the heads of most - including me .

Although it'd be nice to develop this level of skill, many here are not going to have the inclination to invest the time required to reach this level of understanding.

Even though any really 'decent' level of security will actually require that people learn these more advanced programming skills, let's keep in mind that our primary purpose with this thread is to share ideas which others can actually understand enough to apply in their own projects. Which probably means working within the scope of the AMS & native Lua code libraries.

I know some will say that Lua can't ever provide any worthwhile level of security by itself and so there's little point in trying. And yes, I'd concur. But hardcore security isn't really our goal here. It's just to show how security can be improved a little bit beyond what the defaults of AMS provide. And to have some fun doing it!

That being said, I'll throw up one last opportunity for people to capture the password from the Daffy Duck challenge before posting the fully code-commented APZ solution.

So far, IP's the only one who's discovered the password. Herrin defeated the outer-security layers to capture the project's sourcecode but not its inner-security protecting the actual password. So before any/all interest is lost (and for any who still have the time or inclination to do so), here's a complete list of instructions for manually reversing the Daffy Duck example:

........................................

Nb. Example is coded to detect for local debuggers so these instructions are for manual reversal via the _proj.dat

Stage-1: Defeating the Outer Security:

For those who don't already know, the CDD file is a just a zipped file with a .cdd extension. And contains a file named _proj.dat which contains the project's source code. The CDD (pse.cdd) file which you can see in the AutoPlay folder (in this particular example) is a decoy/dummy file. The 'real' CDD has been renamed as pse.dat and is hidden/embedded inside the executable. To retrieve it, unpack the pse.exe.

The pse.exe has been double-packed, firstly with UPX and then with Enigma Virtual Box. After packing, the file's section-headers were scrambled, so it's resistant to a range of popular auto-unpackers. But by renaming the section-headers back to their Enigma defaults (.enigma1 & .enigma2) you'll be able to use auto-unpackers on it to extract the CDD (pse.dat).

Once it's been unpacked, you'll have access to the CDD file from which you can extract the proj.dat. (I won't go into methods for defeating the randomly generated CDD password as it's already been discussed many times in the past and there's already numerous threads on the subject).

Note:
You won't be able to run the unpacked file because it's coded to detect for instances of unpacking. The filenames of _proj.dat & _font.dat were swapped. So, it's actually the file named _font.dat which contains the sourcecode. That's the one you want.


Stage-2: Defeating the Inner Security:

The password is protected by 2 layers of encryption: Blowfish-Base64 and RC4 encryption.
Reversing the encryption requires the following steps:

• concatenation of the encrypted password subStrings (pw_subStringA, pw_subStringB)
• reversing the order listed in the table of obfuscated cryptoKeys (tCryptoKeys)
• using the custom cryptoKey Generator to de-obfuscate the table of cryptoKeys
• multiple (5-pass) Blowfish decryption (using the aforementioned table of cryptoKeys)
• single (1-pass) RC4 decryption (obfuscated cryptoKey is in password button's On Click event)

Note:
The RC4 crypto DLLs are stored in Globals as encrypted strings & must be restored to binary format before the RC4 decrypt function can be applied. The parameters for calling the RC4 crypto DLLs have been bytecoded (sIn.luac) and are executed via the dofile command.

There ya go folks - a custom migraine made to order!

[Imagine Programming]

I'll see what I can do, because the language you'll be analysing in Ghidra is not Lua. I think I made this one a bit too difficult haha!

[BioHazard]

... binary reversing can be a whole lot of fun!

LOL, would be if I knew WTF I was doing. Haha.
But not quite ready to give up on this one yet, IP. The 'fat lady' hasn't sung!

I have an idea ... tell me what you think:

How about you show me how to use Ghidra correctly, to capture the password of a plain vanilla, basic-as-you-can-get example? Something with just an input-field and a button. But with no obfuscation or encryption or anything else. Just a basic beginner's example where the password is stored as a plain text string.

Something dead simple like this:

password = "bi0hazard";
sReturn = Input.GetText("Input1");
if sReturn == "bi0hazard" then
    Dialog.Message("Notice", "Success");
else
    Dialog.Message("Notice", "Wrong Password");
end

I figure if you can show me how to use Ghidra correctly on something this simple, then I might be able to then apply the same principles to intuit and deduct how to use Ghidra on something more complex. Whaddya think?

Here's what I had in mind. Attached is an APZ with the basic code shown above. Perhaps if you just compile that and open it up in Ghidra. And then just selectively make about a half-dozen or so screenshots which illustrate the key steps involved (together with a short explanation for each step). So, it'd kind of be like a 5-6 step illustrated dummy's tutorial that I could follow. Maybe it'll help me (and the others) make the necessary logical connections for more complex stuff?

That's of course if you don't mind spending the time to do it. Personally, I'm predominantly a kinaesthetic learner, so this kind of thing might be just what I need to move forward. But if you do decide to whack something together - just pretend like I'm completely retarded, okay? Pretend like I'm Homer Simpson - on his dumbest day!

[Imagine Programming]

You can select Raw Binary and language: x86 default 32-bit gcc. Then you open it, let it analyse once, find the same point of recognition you might have found in IDA and right click on that address -> disassemble (or D). Then you can run the analysis from the menu again.

Then you could technically right click on the address you started disassembling at and define it as a function.by clicking Create Function. By doing this, you add the main code as a function and it automatically lists any other code or function it finds by following it in analysis.

I know it's a big learning curve, but that's precisely why I created this challenge; binary reversing can be a whole lot of fun!