Ok, while being bored reading at my desk and trying to configure Tripwire, I had an idea similar to what Tripwire does and that is to check the integrity of binary files. So here's a script that I made. Just pop in a new floppy.

So there it is. It's nothing special and it definitely doesn't replace something like tripwire or other well know integrity checkers, but oh well. It's more of a lazy way of doing things...heheh. But it works fairly well. Ok, now You're probably asking yourself, "ok I have the checksums of all the binary files on my system, now what??", well when you think your b0x or b0xen have been compromised, you would make a new checksum list and check it against the previous one that you made. You would check what changes have been made by using the diff command, type man diff or info diff for more info on how to use the command . You can also incorporate all this into a cronjob and have it run weekly or monthly. Whatever you'd like. Well that's it. Can you tell I'm paranoid???

(deleted by me) I almost made an idiot of myself. Damn I wish we could delete our own posts.

Well here is an example chksum:

ded15256d767929b02a3ed8eaba80c8d /bin/ping

I'm guessing that's what you meant by the size of the chksum and not the actual file that my script creates, right??
Oh and I am aware that 2 different files can have the same output. Althought I've never seen it myself. Even though I don't doubt you, would you mind explaining the proccess of how the chksums are created and why they might have the same output?? That is, if you have time. I've never looked into it that much, but now that you brought it up, it is intriguing.

EDIT: Are you sure 2 of the same files can have the same checksums ??

darnit, you DID read my post before I edited it out. ugh... well, my position was based on the checksums created in data packets sent across the internet. However, I noticed you used md5 checksum. That may very well be different. But I'll describe what you wanna hear anyway:

The checksum I'm talking about is created by adding up all the 1 bits in the data stream. So A (01000001) has a checksum of byte 0x02. AB (01000001 01000010) has a checksum of byte 0x04. Change one byte, and you've got AC (01000011 01000001) or byte 0x05). So it's pretty decent at detecting data corruption, which is the primary use of checksums. However, you can probably see how it can be wrong. A (01000001) and a B (01000010) both have the same checksum by themselves.

A md5 checksum may simply take a normal checksum and encrypt it.

Now, reguardless of the checksum method, let's look at things logically. Think about all the possible combonations in a 64 byte file. Can you fit the same number of combinations in 32 bytes? Of course not. So that means some combinations of the original 64 byte file will be duplicates when converted to 32 bytes. Think about how many duplicates you may find when you reduce a 100k+ file. Notice that even when compressing files - you can come out with a larger file than you started out with. That's because of the limits found when reducing a large data chunk to a smaller one.

So it's not perfect - but it can give ya a chance at detecting changes. So there's no reason why you shouldn't do it - just don't think of it as fail proof.

Heheh...thanks for explaining that even though ya didn't have to

Whats is this world coming 2? FUCKIN FLYING HAMSTERS, DOWN I SAY, DOWN! LOL, well done, just try to masturbate when bored.