-2

Batch script, a.k.a. bat or cmd, is good - easy to learn, easy to code, easy to use, easy to distrubute. However it lets coders down when they need to achieve something complex in batch script. The more important thing is that it encounters a security problem when it contains sensitive information such as user name for logging in, passwords, authentication codes, and even its source code.

I did a little research on compiling batch script and the result is as follows:

  1. Batch Compiler
    • Can it compile? Yes.
    • Can it execute? No, even with Windows 95 compatibility.
    • How to compile? Unkown due to the above issue.
    • Is it secure? Unkown due to the above issue.
  2. Quick Batch File Compiler
    • Can it compile? Yes.
    • Can it execute? Yes.
    • How to compile? Borland Delphi 6.0 - 7.0
    • Is it secure? No, it will write a temporary batch script in %temp% that can be accessed directly.
  3. Advanced BAT to EXE Converter
    • Can it compile? Yes.
    • Can it execute? No, even with Windows 95 compatibility.
    • How to compile? Unkown due to the above issue.
    • Is it secure? Unkown due to the above issue.
  4. Bat To Exe Converter
    • Can it compile? Yes.
    • Can it execute? Yes.
    • How to compile? Microsoft Visual C++ 6.0
    • Is it secure? No, it will write a temporary batch script in %temp% that can be accessed directly.

Conclusion:
The above four compilers seem to have problems with compatibility and methods of compilation. They are not reliable and secure to compile batch script.

Improvement to be made:
Better: To write the temporary batch script to RAM instead of %temp%.
Even better: Convert batch script to Low-Level Programming Language.
Ideal: Optimize LLPL for compatibility of different Windows.

Lastly, here is my question:
Is there a way to compile and secure batch script that is not using the method of the second and the forth software from above?

Thanks!

ll55
  • 103
  • 2
  • use option 4 and redirect where the `%temp% location is? – schroeder Dec 14 '16 at 20:42
  • powershell is also easy to use, easy to code, easy to distribute, etc. and compiles – schroeder Dec 14 '16 at 20:44
  • 2
    So how does a compiled batch script could be more secure than the batch script itself? It still contains all the originals secrets and the same program flow and thus the same errors made by novice programmers. It might be a bit harder to get to all these secrets but not too much. A compiler is not an obfuscator and also does not rewrite the program. – Steffen Ullrich Dec 14 '16 at 20:46
  • 1
    There are many, many different programs that will compile .bats for you. I think you are asking for a product recommendation. – schroeder Dec 14 '16 at 20:58
  • @SteffenUllrich, the compiled one is more secure than the original one obviously as reverse engining is needed, it gets more secure when the script gets longer, complex and encrypted. And if it is converted to LLPL completely, people cannot extract human-readable information. – ll55 Dec 14 '16 at 21:07
  • @schroeder, `%temp%` is the temporary folder under user' s account folder. I know powershell and used it once, but I wrote it in batch script so I think the problem goes back to batch script' s security issue. As I stated, 2nd and 4th software is not even compiling batch script, they are compressing batch script and extract it on execution like WinRAR' s SFX. And indeed I am looking some software that can compile batch script, run script from RAM, encrypt the compiled code and compress the compiled `exe` with something like `ace`. – ll55 Dec 14 '16 at 21:31
  • If you translate/compile code the basic structure is still there and can be often reversed with tools. Also, strings like passwords will be the same in the translated code and can be easily extracted with [strings](https://en.wikipedia.org/wiki/Strings_(Unix)) or similar. So it might get a bit harder to extract the data but with the help of tools like decompilers it should not be significantly harder. – Steffen Ullrich Dec 14 '16 at 21:36
  • If you can compile it and it runs, you can reverse it. Might take longer but you certainly can do it. Do not embed passwords into code. Use a software or (better) hardware secure store. Even that isn't perfect unless you also move the security processing into the secure store as well (e.g. HSM or smartcard). The other issue about embedding passwords is that they are then really hard to change which means they aren't and we get even more broken, insecure applications. – Julian Knight Dec 14 '16 at 21:39
  • I see why we must not store or embed sensitive infos in programs now. But is there some software can secure batch script using similar principle of credential storage? – ll55 Dec 14 '16 at 21:46
  • So, it has nothing to do with how easy batch is, it's about that you already wrote something in batch, and now you want to secure it after the fact. I'm not sure what the problem is with `%temp%`. Would creating a RAM disk and running all functions there help? That satisfies your 'better' option. – schroeder Dec 14 '16 at 22:09

1 Answers1

2

Compiling it will never resolve issues with plaintext passwords or leaking source code.

Everything can be decompiled, whatever it's C, .NET, Powershell. Plaintext passwords can be revealed without decompiling.

The issue would be rather different - secure storage of credentials.

One approach would be to store credentials in config file or in windows credential store - this way passwords and usernames are not in the batch script which runs on multiple systems, but it's using different configuration file on each system.

Aria
  • 2,706
  • 11
  • 19