Hi,

One of my friend puzzled me to write a program which destructs itself.
i.e, by the time it stops execution, its executable file should be
deleted.

I tried a lot like
a) using " system() function to deleted the running program"
result: Access denied

b) googled for logic of other self destructing programs
result: not turned up

c) searched groups. They suggested using a .bat file, invoking the bat
file from currently executing one and through bat file deleting the
current executable after we have finished.
But in this case also, we are leaving residual (.bat file).
result: not a perfect one, only a remedy.

d) after system() function Access denial, i got a thought, as OS is
protecting the currently executing program, it is not possible to
perform anything explicitly on it. so what about taking a pointer in
the current program and filling the entire program space with garbage.

result: i don't known how to do it. i mean from where to start, what
is the start and end of the current memory space.etc.,

if any one of you find other ways please let me know. I think this is
for hackers, who can think out of box.

Bye..
KVT

kvt a écrit :
> Hi,
>
> One of my friend puzzled me to write a program which destructs itself.
> i.e, by the time it stops execution, its executable file should be
> deleted.
>
> I tried a lot like
> a) using " system() function to deleted the running program"
> result: Access denied
> d) after system() function Access denial, i got a thought, as OS is
> protecting the currently executing program, it is not possible to
> perform anything explicitly on it. so what about taking a pointer in
> the current program and filling the entire program space with garbage.
>
> result: i don't known how to do it. i mean from where to start, what
> is the start and end of the current memory space.etc.,
>
> if any one of you find other ways please let me know. I think this is
> for hackers, who can think out of box.

This has nothing to do with C++. You are OT here.

Now, for your problem, try using execve() or one of its frontend
instead; the man page should be informative enough.

Michael

On Dec 9, 12:48 pm, Michael DOUBEZ <michael.dou...@free.fr> wrote:
> kvt a écrit :
> > One of my friend puzzled me to write a program which destructs itself.
> > i.e, by the time it stops execution, its executable file should be
> > deleted.

> > I tried a lot like
> > a) using " system() function to deleted the running program"
> > result: Access denied
> > d) after system() function Access denial, i got a thought, as OS is
> > protecting the currently executing program, it is not possible to
> > perform anything explicitly on it. so what about taking a pointer in
> > the current program and filling the entire program space with garbage.

> > result: i don't known how to do it. i mean from where to start, what
> > is the start and end of the current memory space.etc.,

> > if any one of you find other ways please let me know. I think this is
> > for hackers, who can think out of box.

> This has nothing to do with C++. You are OT here.

> Now, for your problem, try using execve() or one of its frontend
> instead; the man page should be informative enough.

Not really. It's very, very system dependent. First, C++
doesn't offer any standard way of even finding the binary
executable which contains your code. Secondly, at least some
OS's will not allow deleting a file if it is open, and because
of virtual memory, a binary which is being executed is open.
Depending on the system, execve might or might not be of use (or
even might or might not be available). (It's a Posix function,
and there's absolutely know way of reliably finding the binary
you are executing under Posix.)

--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

Hi James,

can't we find the binary executable through the argv[0] argument while
having the arguments to main as
int main(int argc, char* argv[]);

and

coming to the destruction of the program. i have a thought
1) From parent fork a child process
2) make the child sleep until parent finishes
3) after parent finished, ask the child to remove the executable one
like...
system("mv " argv[0] "/dev/null"); //don't point out the mistakes in
this statement. i would like to just explain my logic. For successful
execution, i will take a string which is equivalent to the above
string

On 2007-12-10 08:04:55 -0500, kvt <balakrishna.jntu@gmail.com> said:

>
> can't we find the binary executable through the argv[0] argument while
> having the arguments to main as
> int main(int argc, char* argv[]);
>

No. Read the requirments for argv[0]. [basic.start.main]/2: 'argv[0]
shall be the pointer to
the initial character of a NT MB S that represents the name used to
invoke the program or ""'

--
Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of "The
Standard C++ Library Extensions: a Tutorial and Reference
(www.petebecker.com/tr1book)

On Dec 10, 6:04 pm, kvt <balakrishna.j...@gmail.com> wrote:
> Hi James,
>
> can't we find the binary executable through the argv[0] argument while
> having the arguments to main as
> int main(int argc, char* argv[]);
>
> and
>
> coming to the destruction of the program. i have a thought
> 1) From parent fork a child process
> 2) make the child sleep until parent finishes
> 3) after parent finished, ask the child to remove the executable one
> like...
> system("mv " argv[0] "/dev/null"); //don't point out the mistakes in
> this statement. i would like to just explain my logic. For successful
> execution, i will take a string which is equivalent to the above
> string

Even with fork, the code being executed is part of the binary that the
parent executes (even when processes are different). So, you are not
really changing anything as compared to issuing that system call from
the parent process.

kvt wrote:

> coming to the destruction of the program. i have a thought
> 1) From parent fork a child process
> 2) make the child sleep until parent finishes
> 3) after parent finished, ask the child to remove the executable one
> like...
> system("mv " argv[0] "/dev/null"); //don't point out the mistakes in
> this statement. i would like to just explain my logic. For successful
> execution, i will take a string which is equivalent to the above
> string

If you're using some Unixoid system as you apparently do, you can
usually remove the "file" even if it's still open (because you don't
directly erase a file on these systems but only remove a directory
entry). You don't need any trickery. However, there may be several names
(links) for one file, which you cannot find trivially, some temporary
directory entry might still be created upon removal (on NFS, for
example), and this of course has nothing to do with C++. Ask this on
comp.unix.programmer (f'up to).

Abhishek Padmanabh a écrit :
> On Dec 10, 6:04 pm, kvt <balakrishna.j...@gmail.com> wrote:
>> Hi James,
>>
>> can't we find the binary executable through the argv[0] argument while
>> having the arguments to main as
>> int main(int argc, char* argv[]);
>>
>> and
>>
>> coming to the destruction of the program. i have a thought
>> 1) From parent fork a child process
>> 2) make the child sleep until parent finishes
>> 3) after parent finished, ask the child to remove the executable one
>> like...
>> system("mv " argv[0] "/dev/null"); //don't point out the mistakes in
>> this statement. i would like to just explain my logic. For successful
>> execution, i will take a string which is equivalent to the above
>> string
>
> Even with fork, the code being executed is part of the binary that the
> parent executes (even when processes are different). So, you are not
> really changing anything as compared to issuing that system call from
> the parent process.

With execve, I was expecting the execution to close the file from which
it is executed initialy since it completely takes other the execution
space. It doen't seem to be the case. There must be some issue with the
execution tree of windows.

Better ask on a win32 group.

Michael

On Dec 10, 2:04 pm, kvt <balakrishna.j...@gmail.com> wrote:

> can't we find the binary executable through the argv[0] argument while
> having the arguments to main as
> int main(int argc, char* argv[]);

No. First, according to the standard, all you get in argv[0] is
the name of the program as invoked (if that---an implementation
is allowed to just put an empty string there). There is no
defined mapping from the "name of the program as invoked" and
the pathname of the executable file---under Unix or Windows, for
example, you'd have to exploit the PATH environment variable,
using various system specific functions to determine whether
there was an executable file with the given name in each element
in the list.

And second, Unix (and I think Windows as well) isn't conform in
this respect anyway---Posix doesn't allow it, to begin with.
What you actually get in argv[0] is whatever the invoking
program (the program which called exec) gives you, and there is
no requirement that this bear any relationship to the command
name. The shells I normally use (bash, ksh or the Bourne shell)
are pretty correct about putting the right thing there, but
other programs aren't; xterm or the login server, for example,
may prefix a '-' to the name, and I've seen various magic
inserted there as well. (For that matter, all you have to do
under Unix is add a link, and invoke the program through that.)

> and

> coming to the destruction of the program. i have a thought
> 1) From parent fork a child process
> 2) make the child sleep until parent finishes
> 3) after parent finished, ask the child to remove the executable one
> like...
> system("mv " argv[0] "/dev/null"); //don't point out the mistakes in
> this statement. i would like to just explain my logic. For successful
> execution, i will take a string which is equivalent to the above
> string

That has more chances of working, but you still need the system
dependent stuff in the "system", and you still have the problem
that the mapping between the filename (needed by "rm", "erase"
or whatever) and the name you give as a command is very
implementation defined.

--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34