By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
455,905 Members | 1,271 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 455,905 IT Pros & Developers. It's quick & easy.

Unpack Files to memory and then run them (like thinstall)

P: n/a
Hi,

Is it possible in anyway to load a file into memory and then run it
from there? I am working on a file compressor
(www.nemokprod.go.ro/nb.htm) that can compress and encrypt and save
multiple files as an exe file that can then run the compressed files
after unpacking them to a temp folder. The problem is that I have to
unpack the files to the hard-disk and then run them from there, making
them vulnerable to user that may try to get the original (unprotected)
files.

So the user shouldn't have access to the file operations in the
background. So I need to keep the original unpacked files hidden from
the user, until after they are opened by the unpacker and then deleted.
So users should have no kind of access to the files (should not see
them, open them, should not be able to modify or copy them) but the
unpacker should be able to run them. (that is why I think that the
memory is the best solution)

So is there any way to protect them, like unpacking them directly to
memory and then run them from there? Something like a virtual disk in
memory?

Thanks.

Oct 26 '05 #1
Share this Question
Share on Google+
13 Replies


P: n/a
Nemok wrote:
Is it possible in anyway to load a file into memory and then run it
from there?
Everything is possible. C++ is a general-purpose programming language
that can help you do just about anything.
I am working on a file compressor
(www.nemokprod.go.ro/nb.htm) that can compress and encrypt and save
multiple files as an exe file that can then run the compressed files
after unpacking them to a temp folder. The problem is that I have to
unpack the files to the hard-disk and then run them from there, making
them vulnerable to user that may try to get the original (unprotected)
files.
OK. An obvious problem.
So the user shouldn't have access to the file operations in the
background. So I need to keep the original unpacked files hidden from
the user, until after they are opened by the unpacker and then deleted.
So users should have no kind of access to the files (should not see
them, open them, should not be able to modify or copy them) but the
unpacker should be able to run them. (that is why I think that the
memory is the best solution)
A valid solution, I suppose.

How is all that relevant to C++ I am not sure yet. Do you have a C++
*language* question?
So is there any way to protect them, like unpacking them directly to
memory and then run them from there? Something like a virtual disk in
memory?


These questions cannot be answered within the scope of this newsgroup.
If I were to speculate, then I'd say, yes, probably, if the facility of
'virtual disk in memory' is available. Of course, it all has nothing
to do with C++ language and therefore off-topic. Find a better place to
ask those questions. I suggest starting in a newsgroup dedicated to the
OS on which you're going to be running your program.

V
Oct 26 '05 #2

P: n/a
Nemok wrote:
Hi,

Is it possible in anyway to load a file into memory and then run it
from there? I am working on a file compressor
(www.nemokprod.go.ro/nb.htm) that can compress and encrypt and save
multiple files as an exe file that can then run the compressed files
after unpacking them to a temp folder. The problem is that I have to
unpack the files to the hard-disk and then run them from there, making
them vulnerable to user that may try to get the original (unprotected)
files.

So the user shouldn't have access to the file operations in the
background. So I need to keep the original unpacked files hidden from
the user, until after they are opened by the unpacker and then deleted.
So users should have no kind of access to the files (should not see
them, open them, should not be able to modify or copy them) but the
unpacker should be able to run them. (that is why I think that the
memory is the best solution)

So is there any way to protect them, like unpacking them directly to
memory and then run them from there? Something like a virtual disk in
memory?

Thanks.


This post is off-topic in this forum since standard C++ doesn't know
about executing other programs. You'll want to post in a newsgroup
related to your OS since the answer to your questions will be dependent
on how processes are started, allocated system resources, etc. on your
system.

Rhetorical question: Is the purpose of all this to prevent the user
from getting the actual files? If so, a determined and knowledgeable
user could probably still get around your security measures (just like
they do with encrypted songs from iTunes, etc.).

Cheers! --M

Oct 26 '05 #3

P: n/a
Well the relation to C++ is the fact that I am building this in C++ for
WinXP.
Any ideas on how to create something similar to RAM disk?

Oct 26 '05 #4

P: n/a
> This post is off-topic in this forum since standard C++ doesn't know
about executing other programs.


AFAIK, not quite correct. C library is part of C++ standard and defines
functions for executing other programs. Not that it would help in this
case :)

Mirek
Oct 26 '05 #5

P: n/a
Nemok wrote:
Well the relation to C++ is the fact that I am building this in C++ for
WinXP.
Any ideas on how to create something similar to RAM disk?


A man in a flower shop: "Can you fix my flat tire?"
The flower lady: "No. This is a flower shop, what relation is
there to your tires?"
The man: "I was just driving _on_them_ before I walked in."

No, Nemok, no idea how to create something similar to RAM disk. C++ has no
mechanisms for that. Post to the newsgroup for your OS.
Oct 26 '05 #6

P: n/a
Mirek Fidler wrote:
This post is off-topic in this forum since standard C++ doesn't know
about executing other programs.


AFAIK, not quite correct. C library is part of C++ standard and defines
functions for executing other programs. Not that it would help in this
case :)

Mirek


True, there is std::system() which could work if the OP could get a RAM
disk. Unfortunately, that part of the question is still off-topic here.

Cheers! --M

Oct 26 '05 #7

P: n/a
Nemok wrote:
Well the relation to C++ is the fact that I am building this in C++ for
WinXP.
Any ideas on how to create something similar to RAM disk?


Minesweeper is written in C++ for WinXP. Should I ask Minesweeper
questions here?
Oct 26 '05 #8

P: n/a
Neo
OK ther topic isn't C++ ... but i've heard of something called UPX...
upx.sourceforge.net

it compresses ur files...on ur HD
Then decompresses it in memory when it is run and executes it.. no HD
involved :)

And i think the source is available under GNU.

There u go.
Neo

Oct 27 '05 #9

P: n/a
Thanks Neo. I see you are the only one here that is not too busy to say
I am off topic to actually read my question and give me an answer if
possible.

Oct 27 '05 #10

P: n/a
Nemok wrote:
Thanks Neo. I see you are the only one here that is not too busy to say
I am off topic to actually read my question and give me an answer if
possible.


<sigh> I see you are not the only one here not realizing that perpetuating
off-topic is simply not good for _everybody_. comp.lang.c++ is *not*
a chat room for every issue remotely related to C++.
Oct 27 '05 #11

P: n/a
Victor Bazarov wrote:
Nemok wrote:
Thanks Neo. I see you are the only one here that is not too busy to say
I am off topic to actually read my question and give me an answer if
possible.


<sigh> I see you are not the only one here not realizing that perpetuating
off-topic is simply not good for _everybody_. comp.lang.c++ is *not*
a chat room for every issue remotely related to C++.


To quote Judge Easterbrook: "If the rules are good, enforce them; if
the rules are bad, change them; there's little point in having good
rules but winking at noncompliance."
(http://www.legalaffairs.org/howappea...g_archive.html)

Cheers! --M

Oct 28 '05 #12

P: n/a
mlimber wrote:
Victor Bazarov wrote:
Nemok wrote:
Thanks Neo. I see you are the only one here that is not too busy to say
I am off topic to actually read my question and give me an answer if
possible.


<sigh> I see you are not the only one here not realizing that perpetuating
off-topic is simply not good for _everybody_. comp.lang.c++ is *not*
a chat room for every issue remotely related to C++.

To quote Judge Easterbrook: "If the rules are good, enforce them; if
the rules are bad, change them; there's little point in having good
rules but winking at noncompliance."
(http://www.legalaffairs.org/howappea...g_archive.html)


I am not sure what you're trying to say with this quote. Honestly.

To the OP and others:

If we could _enforce_ the rules, we'd not be having this conversation.
Neither I nor other regulars here are going to change the topicality of
this newsgroup (IOW, the "rules" are just fine). But the rules are just
that, rules. Guidelines. No mechanism here exists to enforce them,
comp.lang.c++ is "unmoderated". That's why we "police" this newsgroup
and not *filter* it (like most moderated NGs).

Now, following the rules (guidelines) is the responsibility of every
poster, not a chosen few who pick which posts make it and which are left
to decay in bit- (or byte-) buckets as in moderated newsgroups. I do
actually think that this is a much better situation. Nobody has their
brains shot out by a pepper pellet here, nobody's arms or noses are
broken by a hard-rubber baton.

I will not tire to repeat this spiel: if we don't do our "policing" (in
whatever form it happens to exist), this newsgroup will cease to function
as intended. As part of "policing", the rule is not to answer off-topic
questions _at_all_. Not by marking it [OT], not in any other way. If
an off-topic question is answered, the off-topic question poster usually
simply leaves (he got what he wanted) never to come back again. He wasn't
interested in C++ to begin with, anyway. And some other bloke might see
that OT is perpetuated and deduce that it is perfectly OK to ask it again.
Another sod answers that one, and so on.

If the poster who doesn't know where to post is simply nudged in the right
direction, it is by far better than supplying the answer alongside some
vague mention of off-topicality. If he leaves hungry, he's more likely to
find the _proper_ place to eat. He'll just have to. Basically this is
the same as "give the man a fish" vs "teach the man to fish" thing.

V

P.S. If that's what Judge Easterbrook meant, good. If it's not, I am not
going to cry, anyway.
Oct 28 '05 #13

P: n/a

"Victor Bazarov" <v.********@comAcast.net> wrote in message
news:8r******************@newsread1.mlpsca01.us.to .verio.net...
mlimber wrote:
Victor Bazarov wrote:
Nemok wrote:

Thanks Neo. I see you are the only one here that is not too busy to say
I am off topic to actually read my question and give me an answer if
possible.

<sigh> I see you are not the only one here not realizing that
perpetuating
off-topic is simply not good for _everybody_. comp.lang.c++ is *not*
a chat room for every issue remotely related to C++.

To quote Judge Easterbrook: "If the rules are good, enforce them; if
the rules are bad, change them; there's little point in having good
rules but winking at noncompliance."
(http://www.legalaffairs.org/howappea...g_archive.html)


I am not sure what you're trying to say with this quote. Honestly.

...
P.S. If that's what Judge Easterbrook meant, good. If it's not, I am not
going to cry, anyway.


Basically what Judge Easterbrook was saying was that if you have rules don't
let people break them. If you let people break them, and you have a reason
to, then the rule is no good so change it.

What I think he (the quoter) meant by that quote was, we stick to c++
questions here. If your problem is not c++ specific, it's OT and shouldnt'
be answered, because that's our rule.
Oct 31 '05 #14

This discussion thread is closed

Replies have been disabled for this discussion.