The testing environment was redhat linux 7. 2 running on a pentium 100 with 64 megs of ram.

Started off with strings of the-binary.
Tried to search on the internet for *nazgul*, couldn't find anything.

Searching for "The Linux C library 5.3.12" + "yplib.c,v 2.6 1994/05/27 14:34:43 swen Exp" on google gave 1 result. The binary for a program called safeload.
The strings from safeload are here . The source is here , Try http://www-miaif.lip6.fr/willy/pub/safeload/v0.2/untared/


The strings from "inetd" in the lrk4 rootkit also showed up in a google search search on "yplib.c,v 2.6 1994/05/27 14:34:43 swen Exp"
The with the strings output was from a honeynet report, http://project.honeynet.org/challenge/results/submissions/addam/strings/inetd.strings

Used the "REC portable decompiler engine and the MIPS R3000 disassembler" to try and generate source code .
See http://www.backerstreet.com/rec/rec.htm for the tool.

Generated assembly with objectdump -D, didn't help much .

Executing the program resulted in the "[mingetty]" process listening for a raw nvp socket on port 11.
A remote nessus scan on the machine didn't provide any new information.

Used the HT editor to place nop's over the close system calls in the second fork. Still no output.

I used fenris and modified the socket to be bound as udp to port 5555. After struggling to do this I was unable to figure out what bytes to send to it.
I created a udp client and was able to send data blocks to the-binary. I tried an array of 0-499 but not much further, my assembly needs work. Saw some conditionls to check the received data. Used fenris and aiger to step through but was not able to get much past the data being received. After the snort test data was released I tried sending the same packets to my fenris-port-5555-bound-binary from a remote machine. Still ended up in endless conditional loop.

I restored the symbol tables using dress and saved it as "new-binary." I still was not able to deduce much of anything from the assembly or the recovred REC code.

Release of the snort test data helped. I constructed a packet and sent it via raw nvp on port 11 to the new-binary. I modified my previous udp client to send raw data over nvp. I used the string from the forth packet of the snort.log (one just before the hacked machine sent off outgoing connections). Viola, Ptrace followed [mingetty] as it forked, opened files and spawned new sockets.  The information here is difficult to interpret. Probably should have saved each fork in a separate file.

I also used the Linux Trace Toolkit, http://www.opersys.com/LTT. This gives a complete picture of the machine while the code was running. The output was more clearly organized for me. The kerel trace daemon output for each of the processes below was captured.
985 the-binary
-986
-987
-988
-989
-990
-991
-992

Some brief notes about what each process was doing, click on each of the above for the actual trace output. Also the newtork calls from the kernel here .  Socket call summary here . Filesystem calls here.

985 - execs new-binary,
986 - setsid, sigaction, fork and exit
987 - chdir, close fd's 0,1,2, open the SOCKET, recv on socket, after receive fork, repeat.
988 - fork
989 - read from .hj237349, sends 473 bytes over SOCKET, read from .hj237349 again, send message 498 bytes over SOCKET.
990  execve bash, opens and reads or maps the following (then forks):
ld.so.cache
libtermcap.so.2.0.8
libdl-2.2.4.so
libc-2.2.4.so
locale.alias
LC_IDENTIFICATION
LC_MEASUREMENT
LC_TELEPHONE
LC_ADDRESS
LC_NAME
LC_PAPER
LC_MESSAGES
SYS_LC_MESSAGES
LC_MONETARY
LC_COLLATE
LC_TIME
LC_NUMERIC
LC_CTYPE
mtab
meminfo

991 reads from .hj237349, execcve tcsh, opens files similar to above
lots of closes, then new socket, opens nsswitch.conf
ld.so.cache
libnss_files-2.2.4.so
group
socket call 7 fpm fd:16
utmp
ioctl
fork

992
ioctl
execve 8x
write
exit

Used tracker to detect changes to the filesystem. Hopefully computes md5 sums for all files and compares. http://hexadecimal.uoregon.edu/tracker/
Results here. Fresh install, took a snapshot, logged in to a second terminal and ran a debug session. The altered devices, crontab and log files could be expected. Where is the file that was written by the last process.

Used snort to record network traffic but never saw any packets come out of the test box. LTT showed out and in packets during the test. Perhaps they were sent to 0.0.0.0.

Thanks for donating your time to read this. Spent a ton of time reading and flailing all month. Ran out of time, learned a ton.


Some feferences
http://www.incidents.org/papers/ssh_exploit.pdf
http://jeff.wwti.com/papers/Mixter/trojans.txt
http://www.acm.uiuc.edu/sigmil/RevEng/t1.htm
http://www.phrack.com/phrack/58/p58-0x05
http://khdp.org/docs/project/b4b0/3/b4b0-3-7.txt