5

Is it possible using Windows to read a file into memory (keep data in byte array), delete original file from filesystem and execute it from memory?

EDIT

My goals is to protect my java code from reverse enginering.

I wrote a launcher in C++ that take my encrypted jar file, decrypt it and launch it. The little problem is that i have to write my decrypted jar file somewhere in the filesystem, so it can be easily captured and decompiled... there is no way to prevent this?

Mateen Ulhaq
  • 24,552
  • 19
  • 101
  • 135
blow
  • 12,811
  • 24
  • 75
  • 112
  • 4
    You might want to do more research on NX bit and DEP (Data Execution Prevention) on the web. – Hossein Nov 06 '11 at 18:00
  • 1
    What would be the point of such a capability? – David Heffernan Nov 06 '11 at 18:09
  • 6
    Before wasting time on "protecting" your code you should know that there is no way to really protect your code. You just can make it harder for an attacker to get it but you can't make it impossible. – Sylence Nov 06 '11 at 18:11
  • @Blow - I updated my answer to address the Java part (in a generic way). It still doesn't make your secret source invisible though. – Flexo Nov 06 '11 at 18:13
  • @Sylence: i know that, but you can read all java code using a simple decompiler in less than 2 minutes, instead you can't decompile an exe file and decrypt jar file without waste more time. – blow Nov 06 '11 at 18:15
  • If the computer is going to use the code, there is no way to prevent it from occupying memory without running. (Whatever that means.) – Mateen Ulhaq Nov 06 '11 at 18:31
  • Aren't there Java obfuscators available? I know there are some for C++. – Mateen Ulhaq Nov 06 '11 at 18:32
  • Why is this tagged [tag:c]...? Was it to make Linus Torvalds (famous/infamous hater of Java and C++) happy? – Mateen Ulhaq Nov 06 '11 at 18:32
  • 1
    @blow Actually, you can read all instructions from an exe file with less than 2 minutes of disassembly, and locating a jar file within it (then copying out and decompiling) will take even less time. – ssube Nov 06 '11 at 18:34

3 Answers3

8

No, it's not possible to do like that. There's no system call that says "take this chunk of my memory and use just that part of it as the image of a new process".

You can load code into memory and jump to it within the current process, but that's an ugly thing to do because you have to handle all of the relocations.

With regards to the Java specific part:

You can embed a Java interpreter within your C++ executable. You can write your own class loader for Java (through the C++ interface to the JVM) that will load classes from your encrypted Jar file. That way you could avoid ever writing the unencrypted Jar file to disk. It will of course be visible in memory to anyone with a debugger...

Community
  • 1
  • 1
Flexo
  • 87,323
  • 22
  • 191
  • 272
  • thank you, i have already tried to use a custom class loader, but there are problems with spring and IoC. – blow Nov 06 '11 at 18:19
  • With an embedded JVM and a native class loader this could work without the need to write the unencrypted Jar out. I suspect you could load spring and IoC with the "usual" class loader still if that's easier than making them load with your custom native one. – Flexo Nov 06 '11 at 18:22
1

IInspectable, jmax has stated this answer could be used as part of solution to secure a file, they can't provide the full solution in the comments section. If you trying to implement such a solution then please can you raise a new question with what you have tried and where you are stuck. The comments section shouldn't be used to explore further topics or request details on implementing something new.

Stanton
  • 31
  • 4
  • This does not provide an answer to the question. Once you have sufficient [reputation](https://stackoverflow.com/help/whats-reputation) you will be able to [comment on any post](https://stackoverflow.com/help/privileges/comment); instead, [provide answers that don't require clarification from the asker](https://meta.stackexchange.com/questions/214173/why-do-i-need-50-reputation-to-comment-what-can-i-do-instead). - [From Review](/review/late-answers/33191666) – Luke B Nov 19 '22 at 20:40
0

While this is an old question, there is a way to read a file into memory and execute it, its called a RAM disk. This can be used for any programming language.

  1. Create a RAM disk. e.g. by running ImDisk toolkit using java's ProcessBuilder
  2. Copy/create the exe file to the RAM disk
  3. Execute the file on the RAM disk
  4. Delete the RAM disk

This would be slow to set up for a single file execution but would do the job.

JMax
  • 647
  • 6
  • 8
  • That's just a convoluted way of doing what the OS is doing already when launching and executing a regular process. – IInspectable Jan 27 '22 at 08:47
  • @IInspectable, please read the original posters question. The OP wanted to 'delete the original file' and execute it from memory. The OS won't allow you to delete a running exe, but you can with the above method. So you're right that it is similar to what the OS is already doing, but the RAM disk way doesn't leave it on the physical disk. – JMax Jan 30 '22 at 11:25
  • *"the RAM disk way doesn't leave it on the physical disk"* - That's a creative way of interpreting the requirements. What the OP *really* asked for is: *"delete original file from filesystem"*. Your proposed solution doesn't satisfy that requirement. What it does is transfer the file to a different filesystem. An attacker would now have to exchange their hard-coded `C:` to `D:`, `Z:`, or whatever [MS-DOS device name](https://learn.microsoft.com/en-us/windows-hardware/drivers/kernel/introduction-to-ms-dos-device-names) any given RAM disk implementation decided to assign (if any). – IInspectable Jan 30 '22 at 11:40
  • In other words: `CreateProcess` requires a filesystem path to the executable image, and that image cannot be removed from the filesystem for as long as the process has it mapped into memory. If `CreateProcess` can find the executable image, then so can anyone else. This doesn't accomplish anything. – IInspectable Jan 31 '22 at 17:42
  • You can protect the RAM disk from access outside of your application. So its more secure than having it on disk. Although ultimately nothing is going to provide a fully secure way of doing what the original OP wanted. – JMax Feb 01 '22 at 13:36
  • You can also protect objects in the file system by applying an appropriate ACL. Using a RAM disk doesn't provide any benefit. It doesn't do anything useful, at best, and is likely a pessimization in reality. – IInspectable Feb 01 '22 at 16:24
  • The files will still be on disk which will leave them vulnerable. You can also get around an ACL as it's not that secure. Using a RAM disk will not leave any files on disk, as soon as they're gone from memory they can't be recovered. – JMax Mar 16 '22 at 10:04
  • *"The files will still be on disk which will leave them vulnerable."* - No, the ACL is enforced by the kernel. Thus the file is protected as much as you want it to be protected. *" You can also get around an ACL as it's not that secure."* - A blunt statement that stands without foundation. Citation needed. *"Using a RAM disk will not leave any files on disk, as soon as they're gone from memory they can't be recovered."* - Right. So for the entirety of its lifetime, the code is vulnerable. Unless you protect the process with an ACL. At which point you may just as well protect the filesystem. – IInspectable Mar 16 '22 at 11:29
  • Its harder to protect the files once they're on disk as you can just login at ANY point (not just the lifetime of the process), take ownership, and copy them. Google "How to set or reset NTFS permissions of a file or folder with icacls command" for a citation. – JMax Mar 17 '22 at 13:00
  • With a RAM disk you can only take them when the user is logged in with the files on the RAM disk. You can use an ACL to protect the contents of a RAM disk too, this will provide an extra layer of protection. There's also additional ways of securing a RAM disk from access (please do reasearch this if you're interested). Although as I've said earlier, nothing's going to fully protect the files exactly as the OP wants. Thank you for your interest in this subject. – JMax Mar 17 '22 at 13:00
  • You do realize that to execute *icacls* to take ownership of a file with a restricted ACL you have to run the command elevated. You cannot reset NTFS permissions, unless you hold the respective privileges. That's not a scenario that Windows' access control guards against. All of this is besides the point: A RAM disk doesn't buy you **anything**. Not even a little. Nothing. If you assume the privileges to change random ACL's it's reasonable to assume that you can run arbitrary code under a debugger. At which point your entire RAM disk campaign is moot. Can't you just let it go? – IInspectable Mar 17 '22 at 13:13
  • If the file is on disk then you lose control and can elevate your permissions at any point to obtain it. If the file is on a RAM disk it doesn't exist outside of the instance it's running in, so its possible to control the environment. "If you assume the privileges to change random ACL's" I don't assume this when running in an environment the application controls, i'm saying this can be used as part of wider solution to control where the file is, when it exists and who has access. This isn't possible using ACL on a file system. – JMax Mar 18 '22 at 15:08
  • I understand you're looking at this as just a file system-based approach, and comparing running a standard RAM disk vs a file system. In that instance you're correct, there is very little difference like for like. Hopefully you understand I'm suggesting using this as part of a wider solution. – JMax Mar 18 '22 at 15:09
  • Yes, that's understood. And you have consistently failed to make a convincing point. If a user can attach a debugger, then they have prolonged the to-be-protected resource's lifetime **indefinitely**. Can we now please put an end to this *"RAM disks are more secure than securable objects"* campaign? Thank you. – IInspectable Mar 18 '22 at 15:27
  • Why do you think you can attach a debugger in a controlled environment? You have failed to understand some basic points. You have even contradicted yourself by saying a RAM disk doesn't provide ANYTHING, but also agreeing the files only exist for the lifetime of the process. Put simply, a file that is stored on disk can be recovered, a file in memory can't be recovered once it's gone. Can we put an end to this "file systems are the same as volatile memory" campaign? – JMax Mar 20 '22 at 00:35
  • *"Why do you think you can attach a debugger in a controlled environment?"* - Because we aren't talking about a controlled environment. If we were, then what's the specific problem you are trying to solve? So no, using a RAM disk buys you **exactly** nothing. At all. – IInspectable Mar 20 '22 at 08:03
  • From the post above...This answer could be used as part of a solution to secure a file, which can't be provided here in the comments section. If you trying to implement such a solution then please can you raise a new question with what you have tried and where you are stuck. The comments section shouldn't be used to explore further topics or request details on implementing something new. – JMax Nov 15 '22 at 21:01