Actually fix 2001/anonymous to run target program

I can now report happily that the program works as it was thought to -
both modify the binary and run it. A problem was that it used to call
main() infinitely (seemingly) call main() recursively but this was
causing a problem. It had to be (as I did some while back) moved to a
new function which is not recursive. My guess is that in the past it was
okay due to exit() but I don't know if this is true or not. So what
could be done?

We have to make sure we have BOTH the file descriptor AND the mmap()d
memory close()d and munmap()d as otherwise we would get a text file busy
error. Then we simply call execv() again. I didn't change it so that the
earlier call to execv() is no longer called because I didn't want to
break anything even though at that point M is actually empty.

The astute programmer would observe that the execv() call is slightly
different: don't use M as the path but rather k[1]. Why? Because
initially M is empty but after the function is called it ends up being
something like '.anonymous.ten134517173' but this file never exists. If
you observe even no file is created (or so it seems) as only cpp is
used, not cc (I'm not actually clear what the purpose of that is). The
mmap() call is important of course as is the open() call as one of the
parameters of mmap().

Is this a workaround? Perhaps in a way but it's the only way it'll work
that I can think of as munmap() and close() must be called lest we get a
text file busy error and only then can we call execv().

Removed cpp.c and cpp make rule.
This commit is contained in:
Cody Boone Ferguson committed 2023-05-19 07:07:44 -07:00
1 parent 316e83b905
commit 2159caec46
9 files changed
+34 -455

No files matched your search

+6 -31
View File
@@ -1103,36 +1103,10 @@ fire](https://en.wikipedia.org/wiki/Halt_and_Catch_Fire_(computing))! :-) ).
# 2001
## [2001/anonymous](2001/anonymous/anonymous.c) ([README.md](2001/anonymous/README.md))
## STATUS: might not be completely functional - can you confirm?
[Cody Boone Ferguson](/winners.html#Cody_Boone_Ferguson) fixed a segfault in
both the entry and the supplementary program (both segfaulted) and it appears to
work in that it does do what the author suggests. However there is an
inconsistency in remarks about whether it should _execute_ the program it's run
on after modification or if it should _only modify_ it. With Cody's fix it
modifies the program, only works on 32-bit ELF binaries (by design) and the
binary still works but we do not know if it's supposed _additionally_ run it.
Can you confirm? Please let us know!
## STATUS: INABIAF - please **DO NOT** fix
[Cody Boone Ferguson](/winners.html#Cody_Boone_Ferguson) fixed this so that it
doesn't segfault and so that it at least _does_ modify the target executable (but see
below) but he's not sure if it's _also_ supposed to run the program; upon a second
look at the README.md file it _appears_ that it's supposed to but the binary at least
is modified (hopefully in the correct way that the entry is supposed to do but
this cannot be confirmed), at least if 32-bit ELF (that's the only file type
it's supposed to modify).
The [anonymous.sh](2001/anonymous.sh) script, run by
[2001/anonymous/try.me.sh](2001/anonymous/try.me.sh), is for now a workaround
(until it can be ascertained - and addressed if necessary and possible - if the
program is supposed to run the target executable or not); the script runs the
program on the target executable and then runs the target executable after
modification which in effect emulates the original program (if indeed it did run
the executable as seems likely).
So again this might be only partially resolved but for now this is unknown.
doesn't segfault and then also fixed the functionality of it (but see below).
Cody also fixed the [anonymous.ten.c](2001/anonymous/anonymous.ten.c) program
(it also segfaulted) but notes that it **MUST** be compiled as a **32-bit ELF
@@ -1143,16 +1117,17 @@ you run it on the compiled [anonymous.ten.c](2001/anonymous/anonymous.ten.c) but
if nothing else it will not modify the target executable (this part of the fix
at least should be correct).
In fact if you run the program on a 32-bit ELF binary (say compiled from another
system) under macOS it won't even touch it (it shouldn't crash however).
The file `2001/anonymous/anonymous.ten.32` is a pre-compiled
[2001/anonymous.ten.c](2001/anonymous.ten.c) as a 32-bit ELF binary in case you
can run ELF binaries but cannot compile 32-bit binaries.
Other BSD Unices were not tested.
BTW: if something is _partially_ resolved is it impartial ? :-)
## STATUS: INABIAF - please **DO NOT** fix
Note also that if you don't specify a file or you specify a non-32-bit ELF file
this program will very likely crash or do something strange like slaughter the
elves of Imladris :-(
## [2001/bellard](2001/bellard/bellard.c) ([README.md](2001/bellard/README.md))
## STATUS: doesn't work with some platforms - please help us fix