rootninja

I just thought I found a really bad flaw in an O’Reilly book that I starting thumbing through entitled “BSD Hacks - 100 Industrial Strength Tips & Tools” written by Dru Lavigne. In one of the very hacks the author enlists the reader to create his or her very first script. “If you’ve never written a script before, this is an excellent exercise in how easy and useful scripting can be.” I laughed after reading this because it’s also an exercise in how much damage such a small bug unintended feature can do.

The hack is called “Create a Trash Directory” and it works just fine if you’re deleting just one item, or multiple items using just one argument. You delete something, and a short little script that you have aliased in place of “rm” actually just moves whatever you intended to delete into a directory somewhere under your home directory, most likely named “.trash”. But the simple three line script only took into account a single command line argument, dollar one. If you had a directory with files “junk.sh”, “trash.txt”, “dontdelete.me”, and “important.doc”. And you typed:

then ok, fine. You just moved everything in `pwd` into your trash directory and you can recover it later. But, if you typed:

to delete just a subset of files, then you’re up a creek without a paddle when you decide you really want those last two files back. The script implemented in the book only the first argument “junk.sh” into account. trash.txt and important.doc were $2 and $3, but your script didn’t handle those arguments. Only the regex covered by the dollar one argument is now recoverable. Ooops!

What you really wanted to do with the trash script is delete all the parameters using $@. The hack never really explains this for the command line handicapped! The hack does cover this situation in the end, asking if you spotted the flaw, but what if you were testing your script as you wrote it instead of reading the whole thing? So like I said, I thought I found a flaw, but I didn’t! It would have been nice for the command line noob if they explained what why and how!!!

BSD bsd hacks, bugs, oops, orielly, shell scripts, trash

shc is the only tool i’ve found that will compile scripts so idle hands won’t tamper with your bash shell scripts. Yes, I know I could just use permissions to keep people from reading them and it’s easy to reverse engineer the binary code, but I look at it like locking your car door; it’s a deterrent. It’s not hard to break into a car, you don’t even need to use the door. Thieves can just spider your window glass to get in, but door locks will keep the average joe out! Someone just tampering for a minute or two trying to tweak something probably won’t want to spend the time to effort breaking in.

to compile a shell script into a binary executable:

Now you can run it like any normal executable…  If this doesn’t work for you, try an obfuscator.  Obfuscating your code might just be all you need, and it will still be the same script, just the spacing and comments will be different, to the human eye at least.

Try obfsh shell script obfuscator - inject deceiving comments and mess with blank lines, spacing and tabs.  Or just roll your own.  Rename all your variables to rediculous things or words that look like code, or reversed meanings.  Change the formatting, etc.  Get creative…

http://www.comp.eonworks.com/index.html

Linux, programming bash, binary, compile, executable, install, make, obfuscator, shc, shell scripts

In a shell script you’re probably testing a variable against some constant or another variable, but why not run a command in a subshell and compare the output?  You could even compare the output of two subshell commands!  I guess most of the time i’m doing something like this i’m using perl or python.  But I needed a way to double check which disk had a powerpc boot partition on it before copying it over to a blank disk and I didn’t have much to work with on those old boards, so I whipped this up right quick:

#!/bin/sh

#check to see if sda has a PPC boot partition

if [ "`/sbin/fdisk -l /dev/sda | grep PPC`" == "" ]; then

if [ "`/sbin/fdisk -l /dev/sdb | grep PPC`" == "" ]; then

echo “both disks have PPC boot partitions”

exit 1;

else

echo “run this: dd if=/dev/sdb of=/dev/sda”

fi

else

if [ "`/sbin/fdisk -l /dev/sdb | grep PPC`" == "" ]; then

echo “run this: dd if=/dev/sda of=/dev/sdb”

else

echo “both disks have PPC boot partitions”

exit 1;

fi

fi

Shell scripting if-then-else tests with commands embedded in backticks.  Why?  Because i’m messing with some old power pc blades running 2.4 kernels with no modern day apps like ssh, rsync, or python.  I don’t know why I didn’t think of this before now?

http://blog.rootninja.com/wp-content/uploads/2008/09/rootninja_80×151.jpg” alt=”root|ninja” width=”80″ height=”15″ />

Linux 2.4, if-then-else, kernel, Linux, ppc, shell scripts