Commands using wc

I have found that base64 encoded webshells and the like contain lots of data but hardly any newlines due to the formatting of their payloads. Checking the "width" will not catch everything, but then again, this is a fuzzy problem that relies on broad generalizations and heuristics that are never going to be perfect.

What I have done is set an arbitrary threshold (200 for example) and compare the values that are produced by this script, only displaying those above the threshold. One webshell I tested this on scored 5000+ so I know it works for at least one piece of malware.

calculate how many different lines between two files

(Please see sample output for usage)

Use any script name (the read command gets it) and it will be encrypted with the extension .crypt, i.e.:

myscript --> myscript.crypt

You can execute myscript.crypt only if you know the password. If you die, your script dies with you.

If you modify the startup line, be careful with the offset calculation of the crypted block (the XX string).

Not difficult to make script editable (an offset-dd piped to a gpg -d piped to a vim - piped to a gpg -c directed to script.new ), but not enough space to do it on a one liner.

Sorry for the chmod on parentheses, I dont like "-" at the end.

Thanks flatcap for the subshell abbreviation to /dev/null

Output of a command as input to many

Kind of fun if you're that was inclined. I figured most of my commands start with s. sudo, screen, ssh etc. This script tells me what else they start with.

ls -1 shows one file per line (update: -1 was not really needed)

wc -l counts the lines received from the previous command

A lot of files in one dir is not so cool for filesystem.

Cleaned up and silent with &>/dev/null at the end.

Execute commands serially on a list of hosts. Each ssh connection is made in the background so that if, after five seconds, it hasn't closed, it will be killed and the script will go on to the next system.

Maybe there's an easier way to set a timeout in the ssh options...

Counts the files present in the different directories recursively. One only has to change maxdepth to have further insight in the directory hierarchy.

Found at unix.stackexchange.com:

http://unix.stackexchange.com/questions/4105/how-do-i-count-all-the-files-recursively-through-directories

Using the output of 'ps' to determine CPU usage is misleading, as the CPU column in 'ps' shows CPU usage per process over the entire lifetime of the process. In order to get *current* CPU usage (without scraping a top screen) you need to pull some numbers from /proc/stat. Here, we take two readings, once second apart, determine how much IDLE time was spent across all CPUs, divide by the number of CPUs, and then subtract from 100 to get non-idle time.

Searches for *.cpp and *.h in directory structure, counts the number of lines for each matching file and adds the counts together.

Count on a specific port (80) - FreeBSD friendly.

Echoes text horizontally centralized based on screen width

To get all directories, replace pattern*/ by just */

In this example, the command will recursively find files (-type f) under /some/path, where the path ends in .mp3, case insensitive (-iregex).

It will then output a single line of output (-print0), with results terminated by a the null character (octal 000). Suitable for piping to xargs -0. This type of output avoids issues with garbage in paths, like unclosed quotes.

The tr command then strips away everything but the null chars, finally piping to wc -c, to get a character count.

I have found this very useful, to verify one is getting the right number of before you actually process the results through xargs or similar. Yes, one can issue the find without the -print0 and use wc -l, however if you want to be 1000% sure your find command is giving you the expected number of results, this is a simple way to check.

The approach can be made in to a function and then included in .bashrc or similar. e.g.

In this form it provides a versatile character counter of text streams :)