Temporary folders [.exe]

[wawazx]

I built a .exe file with Autoplay Media Studio and I noticed that when i launched the .exe file
I could see an "autorun.exe" file in Task manager.
I followed the path --> C:\Users\%username%\AppData\Local\Temp\ir_ext_temp _1
And I found that EVERY folders inside the CD_ROOT folder were copied there.

Is there a way of "telling" AMS not to make temp folders ?
I don't want the images etc to be copied there.

- Thanks for your help.

[Imagine Programming]

I built a .exe file with Autoplay Media Studio and I noticed that when i launched the .exe file
I could see an "autorun.exe" file in Task manager.
I followed the path --> C:\Users\%username%\AppData\Local\Temp\ir_ext_temp _1
And I found that EVERY folders inside the CD_ROOT folder were copied there.

Is there a way of "telling" AMS not to make temp folders ?
I don't want the images etc to be copied there.

- Thanks for your help.

Well, if you use the Web Executable option when you build your project, AMS will in fact have to copy those files to disk somewhere. You create a self extracting executable with that option. I also don't see another solution for your problem without sandboxing or virtualisation

[herrin]

I agree with Imagine avoid reading ram codes and copying files to disk

[colc]

Hi,
Found this in my archives,not a complete solution but may help in your images from being copied at a base level temp folder
Secure_Source_Files.apz
Cheers

[BioHazard]

colc

Thanks for the example, Col. Yes, a password-protected zipfile can certainly help with low-level security. But of course, at some point in the event timeline, the password has to be stored/retrieved or inputted. Which of course is where the security apparatus breaks down. Much better to use a method which can bypass this limitation.

Here's one such method (simplistic in nature for demonstration purposes - but whose principle can be easily built upon with additional security layers if so desired):

Store your images as Base64 encrypted strings (either within encrypted files or within project variables themselves). Have AMS decode the strings and then load the result on-the-fly. The decoding process, will still involve momentarily writing the results to the TempFolder, however ...

... interception of results can be made very difficult via:

• applying a 'hidden' attribute to the decrypted results immediately after decoding
• restricting access to the decrypted results during runtime via a File.SetPermissions() action.
• initializing a File.Delete() command immediately after decryption

Have a look thru this attached example. And watch the TempFolder very closely at runtime. You'll find that the entire process (from point-of-decryption until point-of-deletion) is so fast that you can't even see the unencrypted.dat file appear, let alone intercept it. In fact, I'll boldly go so far as to challenge anyone here to see if they can successfully intercept and retrieve the unencrypted.dat file. (And as mentioned, additional layers of security can be added quite easily).

Of course, no security method is unbreakable. But we can obfuscate to the point where the effort required to break the security, overshadows the benefits of trying. And this is a pretty decent method for casual protection. But for security of application resources to a level beyond these kinds of basic methods of obfuscation, a commercial solution is required.

VMProtect Ultimate is arguably one of the very best commercial solutions available. And to my knowledge, its security protocols are as close to unbreakable as you're going to get. Most reversing groups won't even bother with applications hardened with VMProtect security - they're widely considered as just too difficult to defeat. The URL is here (if interested): http://vmpsoft.com/support/user-manu...t-is-vmprotect

[Imagine Programming]

I feel I have to add a few facts about BioHazard's reply;

• Base64 is not encryption, it is an encoding. This means it merely is a translation. Any standardised tool can decode the encrypted.dat file
• Reverse engineers / InfoSec people often have directory watches that immediately open a file when it is created and read its contents. Even though a person cannot see the file being created, software can and will be on time. (https://docs.microsoft.com/en-gb/win...-notifications)
• These same engineers will have their environment set to always show hidden files (heck, as do I), meaning the 'hidden' or even 'system' attribute on files will have no effect. They will even pop out, because they are displayed at a slightly lower opacity than other files in Windows Explorer.
• Denying access to the file is pretty handy, however accounts in the Administrators group can still read the file. This might also cause the file not being deleted in rare occasions, because the program is denying its running user access to the file.

Even though BioHazard's solution provides a bit of obscurity, security by obscurity is never truly secure. This will filter a group of people from accessing those files, however a large group of people will still know what to do. That's why he said 'Of course, no security method is unbreakable'.

I don't mean to say that this is not a good solution for your problem, however I felt it was required to add these technical notes. Virtualisation is still the best option if you want to truly sandbox a program and prevent unauthorised access, however this is often a very complex process for small matters in my honest opinion. Often you see the big companies not even trying to protect their software to that extent anymore, because the effort is not worth it.

[BioHazard]

Concur 100%+ with every point raised there, IP. This is casual low-level security via obfuscation only. And should not be interpreted otherwise. It is however about the best one can hope to achieve using just the tools native to AMS (short of applying additional layers of security - as was made clear). This example was kept basic and simple - for purposes of demonstration (also made clear).

And yes too, in regards your observation about employing 3rd party virtualization for more serious solutions. Hence the link to VMProtect which uses various combinations of virtualization and obfuscation via code mutation.

But the intended target audience of my post here (and the attached demo for that matter) is regular forum members - seeking to deter casual end users. Not developers seeking to thwart off reversing-engineers. So I think it's important that users don't go and throw out the baby with the bath water. Right?

That being said, I'm now provoked (tongue-in-cheek) into re-issuing my forum-wide challenge, to you directly, sensei. LOL.

PS.
Folks, I don't really doubt that IP can't intercept and capture the decoded .dat file from the TempFolder (in about 10 seconds flat - knowing my sensei). But I do want to see if anyone else here can do it. (And if so, provide evidence of success via a short screen recording).

So my initial challenge stands. Intercept and capture the decoded .dat file (ie. the image file displayed in the apz demo at runtime) from the TempFolder. There are only 2 rules:

• No cheating - you can't alter the .apz code (in any way) in order to do it.
• And Ulrich's restricted from participating ('cause he's way too smart and will upset the bell curve! )

On yer marks ... get set ... go!

[Imagine Programming]

Was I restricted from participating as well? Haha I'm sorry, but I wanted to actually see if PureBasic could snatch it fast enough:
- https://www.youtube.com/watch?v=Ms2g...=BasGroothedde

[BioHazard]

No fair, IP! Those with 150+ IQs are barred from participating.
I knew I was no match for your kungfu so was ready for the ass-kicking.

But hey, that took a whole 47 seconds.
You're not losing your touch there are you, sensei?

[BioHazard]

Not to wander off topic - but you have some very curious videos up on your channel there, IP. The shooting range, eh? Looks like a blast (pun intended). Fun with firearms - yes!

Y'know, my brother is ex Australian military. And so I asked him one day, if he'd ever trained with the EF88 Austeyr or M4A1 Carbine assault rifles. He just laughed and said, "Sure. Those and the F89A1 Minimi, too. Plus a few light torpedos. And a variety of surface-to-air and anti-ship cruise missiles, too". LOL, my brother the gun nut. Imagine shooting some clay pigeons with these:

EF88 Austeyr Assault Rifle:


F89A1 Minimi Light Machine Gun:


AGM-84 Antiship Cruise Missile:


RIM-162 Sea Sparrow Surface-to-Air Missile:

[Imagine Programming]

Oof! I bet those clay pigeons will come to live and start screaming when they see that! Haha!

The shooting I was doing over there was for a team day in a software company I worked at back then. That's the first time I shot anything and it so happened to be a Winchester, pretty crazy!

[herrin]

BH have a PM


scene:
user A distributes this executable online and protects the png file inside with this code and the only security of AMS
user B downloads it and for some reason wants to get hold of the code or a file inside


the video shows how both can be obtained in a couple of minutes and without much effort

it does not want to be an answer to you but only the demonstration that security in AMS is extremely low

[BioHazard]

herrin
Yeah, look - it's not really my wish here to initiate a discussion on AMS security (or more accurately, its lack thereof) as this topic has already been discussed to death in dozens of threads (most of which can be found in the AMS v7.5 subforum below).

The OP's original thread topic inquired specifically about protecting a project's image files (not project security in general). And so this is the issue I was addressing here. A discussion on the wider issues of project-security in general would be better suited to a separate thread on the matter. But I'd advise first looking through the copious volume of threads already dedicated to the matter. In all honesty, the issue really has (over the years) been exhausted to the point of becoming a tome unto itself. And is very likely it'd just end up a rehashing of old material.

The Crypto.Base64Decode() approach I suggested was brought up again, only because it's the one method most commonly agreed upon to be simplistic to implement when wishing to limit project-scope specifically to the use of native AMS tools. The AMS Unpacker in your video has been floating around the web for quite some time now, and for many more years still, in its earlier incarnations. I do appreciate the input, though. And will add too, that Base64 can be marginally more effective if the decoding takes place in memory rather than via hard disk (though this is somewhat a mute issue perhaps, as there are ways to snatch code from memory easily enough, too).

More to the point though - for all those newer members who wish to look into the wider issue of AMS security in general (particularly via third-party tools) but who're unfamiliar with the tomes of threads already archived here - the one starting place I would recommend, is this tutorial:

Advanced Exe Multi Protection Against Reverse Engineering:
https://www.cybrary.it/0p3n/advanced-exe-multi-protection-reverse-engineering-free-tools

Then do a forum search to retrieve some of those dozens of aforementioned threads. But do your search via Google using simple search-terms.(ie: "indigorose security", indigorose encryption", etc) as the inbuilt forum-search function tends to retrieve only recent threads. Most of the in-depth discussions, tutorials and examples related to 'security' are archived in the v7.5 subforum. And google is the quickest way to find them.

And one last suggestion for any who're really serious about understanding the architecture of AMS project security: Head on over to *************.com and take a look at their stuff. Although the site is largely dedicated to 'intellectual property theft' and to 'breaking into' AMS applications rather than 'creating' them, it is a very useful place to learn about the intricacies of reversing (and other aspects of software security).

I believe the site's run by former member LucasTheDuck (aka. Pabloko) who's a very talented coder and reverser. And regardless of the color of one's own philosophical outlook regarding the issue of reversing, he's probably one of the very few individuals who can truly pass on an in-depth knowledge about the application of sophisticated security techniques with AMS. (Nb. You'll need an online-translator over there if you don't speak Spanish. Or there's a small English section at the bottom of the forum's homepage).

[BioHazard]

Edit,

wawazx
Was just re-reading your original post and realized that I kind of misinterpreted your request. When you said:

I don't want the images etc to be copied there

... I didn't realize at the time that you were just using 'images' as an example of the kinds of exposed resources you didn't want copied. And that you were in fact concerned about all of the project's resources. Sorry about that - should've read your post more carefully - my bad!

In light of which, have you considered employing a free 3rd-party solution such as Enigma Virtual Box? It won't give you professional level protection by any means - but given that you're electing to compile your project via the web-executable option, Enigma Virtual Box might be ideal for you.

It'll pack all project resources into a single executable (much like the AMS web.exe option does) but without the need to unpack to a temp folder at runtime. And so will give your project a measure of low-level protection. It's not Fort Knox by a long stretch but it's better than nothing - and it's free! (The same can't really be said for other virtualization solutions like Molebox and VMProtect).

Attached is a zipped copy of an example project compiled by Enigma - which you can see here is just a typical AMS application published via the build to Hard Drive folder option:



Enigma then packed the AMS project files into a single executable (same as AMS web.exe option does). This 2kb file is the sum total of what gets written to the temp folder at runtime:




... And this is the contents of that same 2kb file (which is the only thing that gets exposed):




So - if you're interested in taking a look, here's the website and download link:

Website: https://enigmaprotector.com/en/home.html
Download: https://enigmaprotector.com/assets/files/enigmavb.exe

Note: To compile with Enigma Virtual Box, you must compile your AMS.apz via the build to Hard Drive folder option first (don't use the web.exe option - it won't work). When Enigma outputs its lone executable, it will append the term, "_boxed" to the end of the filename. Like this:



You must rename the Enigma-protected executable back to whatever filename you originally assigned to your AMS executable. (The default name would be: autorun.exe). The reason for this need is because Enigma packs all the AMS project files (including the CDD file) into a single protected-executable. And as you may be aware, all AMS executables must bear the same name as the CDD file they're referencing - else they won't run. (You delete the original AMS files afterwards, so that you're left with just the Enigma-protected file).

[kingzooly]

The problem with this is since it's compressing all of that and depending how it's accessing it after you might not be able to create a large app with this what will run well, but that's something you have to test out.