Any CreateProcess API alternative?

[Guest]

I want to fork a new process and my executable binary is stored inside
somewhere. Is there any possible way to fork a process using CreateProcess
API without writing to the disk first? Like let's say I want to create a
process from an array of bytes or memory stream containing the executable
data cause I want to prevent my program executable module from being stolen..

 

[Guest]

I want to fork a new process and my executable binary is stored inside

somewhere. Is there any possible way to fork a process using CreateProcess
API without writing to the disk first? Like let's say I want to create a
process from an array of bytes or memory stream containing the executable
data cause I want to prevent my program executable module from being stolen..

Not that I know of.
But what you want to do is not secure anyway.
You have 1 exe that starts another exe.
What you can do is to use protected storage to create a file that only your
process can access. then that process can launch that file.

But as I said, that is still not secure. the first exe still has to be on
disk somewhere, so if someone wants to steal it or disassemble it, they can
still do so.
How is that any different?

 

[Guest]

Well, actually my purpose is to protect a .NET executable module from being
viewed in 3rd party tool like .NET Reflector, etc. In fact, I plan to perform
RSA encryption on the target .NET executable then perform decryption on fly
to load the program.

I tried to fork a native executable module using CreateProcess API with in
SUSPEND THREAD mode then using WriteProcessMemory to write another native
executable data into my forked process and resume the thread it works.
However, the .NET executable process doesn't work which seems the CLR done
something different in CreateProcess API compared to native code. Any other
ideas to help protecting .NET binary?

 

[Guest]

I want to fork a new process and my executable binary is stored inside
somewhere. Is there any possible way to fork a process using CreateProcess
API without writing to the disk first? Like let's say I want to create a
process from an array of bytes or memory stream containing the executable
data cause I want to prevent my program executable module from being stolen..

First of all, you're going to run into problems on newer systems with
Execute Disable Bit (on the CPU) and/or Data Execution Prevention options (in
Windows). Both of these options are specifically designed to try to stop you
from running data as code.

Second, some antivirus applications consider running data as code a
suspicious activity and may try to block such data/code from executing.

Third, anyone with Administrator and/or debugging privileges can attach a
debugger to your process, force it to dump its address space to disk, and
therefore have a copy of your "embedded" executable.

The .NET Framework has a way of doing something similar in the managed
world. Dynamic assemblies can run directly from memory. However, this would
not help with your IP concerns...MSIL is normally very easy to disassemble.
(MS even provides a disassembler, Ildasm.exe.)

Sean

 

[Guest]

Then it seems to be a trouble protecting IP when using .NET for software
implementation. Does Microsoft provide any security framework, API or library
for securing .NET binary currently or in the future?

Like any new or extensions for API such as CreateProcess with ability to
load RSA encrypted file allowing to pass RSA keys to let the kernel perform
decryption and process creation internally?

I have seen some other implementation uses kernel-mode API hooking which is
a rootkit characteristic and might be flagged as malware by some AV software.
Besides that, if I hook API within ntdll.dll will Vista API changes break my
app or Microsoft preserve all kernel-mode API backward compatibility?

 

[adebaene]

Then it seems to be a trouble protecting IP when using .NET for software
implementation.

Yes, there is.

Does Microsoft provide any security framework, API or library
for securing .NET binary currently or in the future?

Not Microsoft directly, but a lot of 3rd party "obfuscators" solutions
exist for that purpose.

Like any new or extensions for API such as CreateProcess with ability to
load RSA encrypted file allowing to pass RSA keys to let the kernel perform
decryption and process creation internally?

Think about it... encryption is *not* a good solution in this case,
since you need to provide the decryption key along with the executable
(it is security through obscurity , which is better than nothing)

I have seen some other implementation uses kernel-mode API hooking which is
a rootkit characteristic and might be flagged as malware by some AV software.
Besides that, if I hook API within ntdll.dll will Vista API changes break my
app or Microsoft preserve all kernel-mode API backward compatibility?

Microsoft preserves backward compatibility for APIs that are documented
in MSDN or the DDK documenation, period.

Anyway, I believe that in many cases, the good answer to Intellectual
Property protection concerns is not technical, but rather juridic (ie,
licence agreement, etc...). You should think about that first....

Arnaud
MVP - VC

 

[William DePalo [MVP VC++]]

Well, actually my purpose is to protect a .NET executable module from
being
viewed in 3rd party tool like .NET Reflector, etc. In fact, I plan to
perform
RSA encryption on the target .NET executable then perform decryption on
fly
to load the program.

It wouldn't be easy to do, but after you build your application you could
remove code and / or data which gets replaced by NOPs and null bytes to
render it inert.

That which you remove could be encrypted and stored to an external file. At
runtime, you could decrypt the file, and write the code and data sections
back to the proper locations in memory, and use VirtualProtect() and
FlushInstructionCache() to make sure that what you added back is executable.

Note that with every release of the operating system it gets harder to do
things like this because with every release there is an attempt to close one
or more of the doors that malware authors use to sneak their code by the
operating system and the anti-virus utilities. It's possible that anything
that you do now could break in the future.

Just by the way, there are third party tools like these which do encrypt
code and data to prevent reverse engineering and piracy with software and
/or hardware:

http://www.aladdin.com/HASP/HaspHL.asp

http://www.strongbit.com/execryptor_screenshots.asp

Regards,
Will