unforum

[drizjr]

SPOILER: binary not morse

[strife777]

Great job...found where it pertains to...a log located at..

[SpaceBass]

Great job driz! God, I LOVE that misdirection!

[jamesi]

/dev/null/ is a unix/linux thing, as far as i know

can there be a way to access failsafe.html?

--j

[vpisteve]

Doh! Binary disguised as Morse Code??!!

Where have I seen this before????

Hmmmm......





Moot didn't die! He went back in time!!!!

(Disclaimer: totally out of context Lockjaw reference. Sorry!)

[CognosZereo]

Hi everyone
I posted this on CD and having been to this forum in the last few days since starting to play L3, wanted to return the favour to you guys for sharing.

[CognosZereo]

Sorry

[Caterpillar]

/dev/null is UNIX-speak for "nowhere"

....not that it means squat to me, this one's way beyond me, I'll leave it to the experts

[Splinter]

NRU.US

[Gupfee]

Well, my limited knowledge of unix tells me this about the log (forgive me for stating the obvious but I want everything in one place):

1. This is a log of a "purge" program used to clean up files of a dubious nature, like packet sniffers, DOS attackers, etc. Files that don't belong on a network and may be malicious.

2. The purge program "found" failsafe.html and moved it to /purge and then tried to delete it. It was unable to because there was a file lock on it. The file lock was identified as "pid9375 /dev/null jake.d" A pid is a process ID which means something was running a process and it was being directed at /dev/null, an empty file. This just means it was directed at a "black hole" to make it disappear. jake.d sounds like a file name, not a user name although I don't know what the .d extension means off the top of my head.

So, it sounds like the file is still there because the purge didn't delete it. But it's not in /purge, so the trick is to figure out where it is. Maybe it was returned to its original location by the jake.d process.

I'm not sure what the -d modifier is but I know someone I can ask.

This line is very suspicious:

purge.x: Flagging /tmp/* -g !root

Again I'm not sure what's going on there but whenever root is involved in unix, it means something interesting is happening

Unless another Unix expert steps up in the meantime, I'll have more info tomorrow when I can ask someone who really knows this stuff what he makes of it.

[ZeusLegion]

The .d could be for daemon.

I cannot find failsafe.html in:

/bin/
/tmp/
/usr/
/purge/

So it remains to be seen what jake.d did with it.

Z

[SpaceBass]

Filling in a few blanks: the purge process found a "rootkit," in the "/bin" directory (generally reserved for program executables) which it proceeded to attempt to clean. A rootkit is a packaged exploit for one or many security vulnerabilities on a system that, when executed, grants the attacker privileges above what they should have (generally "root" privileges, i.e. admin superuser). Sidenote: rootkits are generally used by less sophisticated attackers ("script kiddies") who do not have the knowhow or patience to perform the exploit manually.

The purge process then scanned the "/usr" directory (where user data and user-owned executables are generally stored) and found failsafe.html and transfer.log.

Here, it appears that the purge process relocated all of the malicious files it had found to the "/purge" directory, then began to delete them. It successfully deleted all of the components of the rootkit but died at the failsafe.html because the file was in use by another process "jake.d." Generally, something ending in ".d" is a daemon, which is a Unix term for a system service. This suggests that the jake daemon was writing to or otherwise accessing the failsafe.html file in a way that made it impossible for the system to delete it. The description of the failure also suggests that the jake daemon has higher system privileges than the system itself, which is odd.

Another odd thing is that the jake daemon is itself apparently located in "/dev/null" which can't be true. Unix identifies hardware devices in virtual subdirectories of "/dev" such as "/dev/hdd0" for the primary harddrive. "Nowhere" is a fair description of "/dev/null" as it is a virtual device equivalent of a black hole, and where you send files to delete them.

[Sin Vraal]

Hey, I finally heard back from L3 on my failsafe post:

==========================================

Mr. Vraal,

According to the notes from the client we can confirm that failsafe.html is in the charcoal underneath the paint.

As for any further information in regards to the painting we do not have any.

Stephen Lake
Attorney at Law

[ramiles]

morse code

[Caterpillar]

Which pic? The lost art? I don't see any M.C.