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:
1 parent
316e83b905
commit
2159caec46
9 files changed
+34
-455
No files matched your search
@@ -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
|
||||
|
||||
Reference in new issue
Block a user