Good Morning,

I face a dillema here at my workplace of being asked to do something i have no idea how to do. Therefore i come seeking advice.

I have an application with two executables, one that calls the other and a set of dlls that are called by both. Also there are a number of reference text files which the application refers to.

I do not have source to these files, only the precompliled artifacts.

I need this application to run as a single executable, without extracting files anywhere. The files contain confidential information and need to only be accessable to the program itself, not the user.

If they are only extracted to memory during runtime, that might be acceptable since the average user wont have the skill to look there.

I understand that everything is extractable, but i just want it to be secure enough that its not directly in the open.

Thanks in advance, im open to any ideas

Perrin

Hi

It sounds like a job for PEBundle, or similar application.

"PEBundle is a revolutionary tool that allows for DLLs or other files to be ‘bundled’ with an executable, therefore removing the requirement to distribute the bundled files separately from the application."

http://www.bitsum.com/pebundle.asp


If your workplace has some programming capabilities you could probably write your own application to do the job, but for the price it's well worth the support. The author of PEBundle (Jeremy Collake) is well known here as a writer of quality software, so I don't think you'd have any regrets in purchasing it if it fully meets your needs.

Regards,
Kayaker

Sounds interesting, although it appears it can only do dlls and exes, not the reference text files which is what im really looking to protect

edit: hmmm, or maybe it can

What exactly should be done with the text-files during execution? Should any third-party-program (i.e. one that you don't have the source code for) that usually only reads data from files on the disk open them, or what?

The only thing that needs to access the text files is the program im trying to encapsulate (we'll call it AST.exe for sake of convenience). The text files are a sort of template that AST.exe uses to read data from a hardware device. The program contains those templates, AST.EXE and 4 or 5 dlls that handle certain dialogs within AST.exe

What i would like to do would be to encapsulate all that, into a single EXE. Ive done some more research, and it appears there is a program called Thinstall that can do this, I tried PEbuild, but cant find a way to integrate the txt files.

Hmmm, tried a couple apps and am having some issues

The program im attempting to encapsulate contains a wibu-key emulator (dll) and its not liking to encapsulate that.

Ive tried Thinstaller and PEbuild both and when the program is run it errors out saying that astra32.dll (wibukey emu) cannot be found even thought it is encapsulated. Any ideas?

Extract to temp dir and run from there? Is that "hidden" enough?

Unfortunately not LLXX, any newb with filemon could figure that out, temp into ram is the bare minimum

How about makeing an asm prog and call with absolute address?

I made a prog calling an absolute address function with none pack that I didn't made DLL it really works.

I dont think this method agree with yours but a possibility

Embed the files as resources, then use FindResource(...), LoadResource(...), and LockResource(...):

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/winui/windowsuserinterface/resources/introductiontoresources/resourcereference/resourcefunctions/findresource.asp ("http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/winui/windowsuserinterface/resources/introductiontoresources/resourcereference/resourcefunctions/findresource.asp")

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/winui/windowsuserinterface/resources/introductiontoresources/resourcereference/resourcefunctions/loadresource.asp ("http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/winui/windowsuserinterface/resources/introductiontoresources/resourcereference/resourcefunctions/loadresource.asp")

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/winui/windowsuserinterface/resources/introductiontoresources/resourcereference/resourcefunctions/lockresource.asp ("http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/winui/windowsuserinterface/resources/introductiontoresources/resourcereference/resourcefunctions/lockresource.asp")

Two words disavowed: no source

sorry, all i have is precompiled unless im missing something

Ahh... I misread your original post. If you're not willing to modify the binaries, you probably won't be able to get this to work, particularly because you'll need one exe to call the other exe, and this is REALLY hard to do without the second exe being on disk (unless you want to write your own loader).

No source? Then make some, in the usual fashion of RCE

The second EXE is actually a relatively minor part of the program, worst comes to worst i could live without it. What is posing the greatest problem at the moment is that when encapsulated with asta32.dll (wibu emu) AST.exe cant seem to see it.

Edit, actually, the second EXE is the one thing in the entire program that i would be comfortable being on disk, its very generic and would be relatively safe

Ok Update

Tried a number of apps:

PEbundle: Works nicely, however it just extracts to disk which defeats the purpose. Also, it isnt able to specify a directory structure, puts everything in root

Thinstall: works when the dll that calls astra32.dll isnt included, but then i cant access half the functions in the program because its locked. When wibucheck.dll is included, it errors out saying that astra32.dll cannot be found.

Molebox: Still playing with this, looks a more promising app than pebundle, and possibly on par with Thinstall.


Anyone know any other apps that do the same sort of thing? (must not extract to disk to run however), extracting to memory is acceptable.

Would it be an option to allow them to be written to disk if you immediately follow by locking them for read and write access so no other applications can get into them, and also use the FILE_FLAG_DELETE_ON_CLOSE flag so that the files are deleted when the program closes, even if it crashes?

I believe the only way the user could get into the files then, without using advanced-level kernel-mode drivers (which you said is not your main concern), is by forcing the system to the blue screen of death, which would be the only way for the system to fail to delete the file.

Obviously a person willing to do this is definitely trying to get into those files, and storing them in RAM wouldn’t be a limiting factor for such a person either.


L. Spiro

L. Spiro, i like that idea. They would be locked similiar to the SYSTEM and SAM files in windows correct. I can already set it up so they write to disk, then are deleted upon program exit. However, i dont know how to implement the FILE_DELETE_ON_CLOSE flag with precompiled files so they would delete even if it crashed. Any more information on that?

hFile = CreateFile( szFileName, GENERIC_READ, 0/*No sharing at all.*/,
0, OPEN_EXISTING, FILE_FLAG_DELETE_ON_CLOSE, 0 );


That’s it.


L. Spiro

One could still use DuplicateHandle(...) to access it, or just inject code into your process.

true ^^ However, anythings hackable but as i said, im just trying to protect it from the moderate user

"moderate user"? How would you define "moderate"?

Someone who can use premade apps, filemon, maybe winhex to check memory but who isnt going to be able to unpack anything. Also they would be able to use undelete type apps so just deleting on exit isnt acceptable now that i think about it

Crashing the system, using DuplicateHandle(), injecting code, and using kernel file-recovery software all indicate a user who is already capable of using hex-editing software, including RAM-based ones.
They also indicate a user with a motive, and quite frankly, once you have that, you aren’t stopping him or her anyway.

All of these security loopholes are important to mention, but only so that you can correctly make your decision on which way to go.


L. Spiro

Aren't you forgetting the computer reset button now? No need for blue screens, just use filemon + the reset button to defeat this method, so this should probably still count as "moderate" level.

With that loophole mentioned I would then agree it may not be safe.


L. Spiro