Z80 Computer

Work has begun on a project that I have wanted to do for many years, and put off for one reason or another.  A few months ago, I decided that I wanted to (finally) build a Z80 machine from scratch, get it to run CP/M, and play a game of Zork.  I hadn't the foggiest idea what it would take, but I have picked up a touch of electronic and programming background over the years, so I decided to take a hack at it.

After a few months of research, design, and waiting for shipping, the first breadboards are starting to go together.  The machine will be a Z80A CPU running at 4MHz with 64k of RAM and 32k of ROM.  I intend to use a Zilog Z80-SIO with a MAX232 to communicate with an old NEC dumb terminal that I have laying around for control.

So far I have constructed the clock, the reset circuit, a single-instruction step circuit, and the beginnings of the bus buffering and signal/address decoding.  I intend to detail each circuit in an individual post including relevant schematics and measurements.

My first test will come shortly, once I finish wiring up the buffers.  I will be pulling the entire data bus low, and hooking LEDs to the buffered address bus output.  If all goes well, the CPU will read NOP off of the grounded data bus, and proceed to increment the address bus every time I run the single-instruction stepper.  The end effect -- A 16 bit binary counter.

From there, I can go into decoding, RAM/ROM, peripherals, some kind of storage, writing a ROM monitor, writing a custom CP/M BIOS, and on, and on, and on.  Oh well, I needed a project and more material for this blog anyway, and from the looks of it, I've got plenty to do now.

Patching Debian 5 for ShellShock

Debian 5 is, sadly, no longer supported by the friendly folks over at Debian.  Like the rest of the internet, it's default version of bash is quite vulnerable to the ShellShock vulnerability.

To clean up the mess we have going here, start off by ensuring that the system is up to date (Debian 5.0.10 is the latest in the repositories.  If you haven't already switched over to the archive sites for the upstream repositories in order to get package updates, update your /etc/apt/sources.list to point at the Debian archives (see the FAQ section at https://wiki.debian.org/DebianLenny).  Then run an 'sudo apt-get update && sudo apt-get upgrade'.

Post-upgrade, /etc/debian_version should show the system at 5.0.10.  In order to update bash, grab the bash-3.2 sources here:  https://ftp.gnu.org/pub/gnu/bash/bash-3.2.tar.gz

Unpack them, and run a bit of bash to patch the sources up to 3.2.55:

#!/bin/bash

wget https://ftp.gnu.org/pub/gnu/bash/bash-3.2.tar.gz
tar -zxvf bash-3.2.tar.gz
cd bash-3.2

for x in `seq 1 55`
do
    curl https://ftp.gnu.org/pub/gnu/bash/bash-3.2-patches/bash32-`printf "%03d" $x` | patch -p0;
done

./configure
make
make tests

Then do the standard GNU install with "sudo make install".

Observium On OpenBSD

Note:  The following is a blow by blow of the installation, told in story form.  If you intend to follow this as a guide to the installation of Observium in OpenBSD, please read through to the end before starting the installation.  I will be show config snippets at varying stages of broken-ness.

Always being one to enjoy a technological challenge, I was presented with the task of building out a new management network.  I firmly believe that management of all devices on a network needs to be out of band from the rest of the network operation, so I was quite happy to take on this task.  After installing the new switches, and getting all of the monitor ports cabled up, I stopped to contemplate how I would set up my network monitoring suite, and how I would access this OOB network remotely.

Being a project that requires security (someone finding their way onto this network could be catastrophic), I decided that the best course of action was to set up a machine with a NIC in both my internal and my management networks, and run OpenBSD 5.3 on it.  A few months ago, the friendly folks over at #juniper on freenode recommended Observium as a network monitoring suite, and I have found it to be a fantastic project so far.  The Observium installation documentation is very clear that it supports Ubuntu/Debian only.  There is a second set of installation instructions for RHEL/CentOS.

So off I went with my OpenBSD installation, knowing full well that the Observium installation was probably going to be a painful one, but the machine that spans the gap between the two networks is a prime location for my monitoring utilities, so I decided to do it anyway.  Starting off with the OS installation, I accepted the defaults for the most part, configured my NICs for my network, and allowed OBSD to work its own disklabel magic (use the whole disk, autopartition).  When it came time to choose installation sets, I simply issued a -x* -games*, and went along my merry way (not fully appreciating the implications of my actions at the time).  Once the install was done, and I was presented with a prompt, the first order of business was to get the package mirror set up so I could begin installing the prerequisite software for Observium.  I chose to use the mirror in Denver, CO, USA.  This involved adding one line, and changing one line in .profile (changes in bold):


PATH=/sbin:/usr/sbin:/bin:/usr/bin:/usr/X11R6/bin:/usr/local/sbin:/usr/local/bin
PKG_PATH=ftp://ftp3.usa.openbsd.org/pub/OpenBSD/5.3/packages/amd64/
export PATH PKG_PATH

Next, we need to get a proper editor, and a few tools:

# pkg_add -vi vim nmap svn

After everything is done installing, I picked up the prereqs for Observium from their install documentation:

# pkg_add -vi fping mysql-server net-snmp rrdtool graphviz php

This will chug along for a while, and occasionally ask a question.  When prompted for a php version, I chose the latest 5.3 release (per the prereqs), in the non ap2 build (this is for Apache 2, but Apache 1.3 ships with OBSD out of the box).  But...  the damn thing breaks on rrdtool...  After a bit of Googling, I discovered that the required libraries are part of xcore53...  one of the packages that I opted to not install earlier.  SOOOOO, off to the closest mirror to grab xcore53.tgz, and run a cd / && tar -zxvpf ~/xcore53.tgz, start the pkg_add over, and we're done.

I brought up the mysql database with /usr/local/bin/mysql_install_db, then set the root password, and created a database for Observium according to the installation instructions.  I set the database credentials in /var/www/observium/config.php.

Next, I decided to install observium into /usr/local/observium, as I didn't like the idea of using /opt.  I pulled the code down via SVN per the instructions on the site, and dropped the config snippet from the RHEL instructions into /var/www/conf/httpd.conf, with some minor modifications:



       ServerAdmin webmaster@localhost
       DocumentRoot /usr/local/observium/html
       
               Options FollowSymLinks
               AllowOverride None
       
       
               Options Indexes FollowSymLinks MultiViews
               AllowOverride All
               Order allow,deny
               allow from all
       
       ErrorLog  /usr/local/observium/logs/error.log
       LogLevel warn
       CustomLog  /usr/local/observium/logs/access.log combined


I wound up chasing my tail for an hour or two messing with the httpd configs, before I realized that httpd had chrooted itself into /var/www (hence the funny config location).  I quickly moved the Observium install over to /var/www/observium, and changed the httpd config again:



       ServerAdmin webmaster@localhost
       DocumentRoot /var/www/observium/html
       
               Options FollowSymLinks
               AllowOverride None
       
       
               Options Indexes FollowSymLinks MultiViews
               AllowOverride All
               Order allow,deny
               allow from all
       
       ErrorLog  /var/www/observium/logs/error.log
       LogLevel warn
       CustomLog  /var/www/observium/logs/access.log combined


Much better!  Now we get an error about the database.  pkg_add -vi php-mysql 

Now getting an error about not being able to bind to the MySQL socket.  Wow, wonderful.  More Googling revealed that, yet again, the chroot was biting me:

# mkdir -p /var/www/var/run/mysql
# ln /var/run/mysql/mysql.sock /var/www/var/run/mysql/mysql.sock

Now that we're past that, OH LOOK, It's a 500 error!  After a few hours of sticking die()'s into the code, I figured out that since I was in a chroot, the install_dir variable would be relative to /var/www.  Once this variable was set from /var/www/observium to /observium, the web UI loaded right up.  When I attempted to add a user, I found that adduser.php was now throwing errors about not being able to find functions that should have been included with common.php.  Turns out that even though Apache is chrooted, the php cli, is not.  DOH!  ln -s /var/www/observium /observium  It's a hack, but hey, it works now... Kind of...  In reality, it just fails differently.  Turns out I missed a step in the install documentation, and didn't initialize the database...

After I got the DB initialized, and a user created, I realized that addhost.php wasn't working.  After more tinkering, I realized that all of the default paths for the utilities were wrong, because the software was designed to run in Linux.  I grabbed the whole block of utility path define()'s out of the defaults file, and gave them the correct paths, and lo and behold!  OBSERVIUM IN OBSD.

I will most likely be revisiting this topic in the not-too-distant future, as I find more things that I need to hack around, but for the time being, It looks like I have monitoring running on the machine I wanted it on.  Now it's time for pf!

Book Review: The Absolute Beginner's Guide to Binary

At one of the Defcon 101 talks given by 1o57, a complaint was made.  1o57's talk was called Hacking the Hacker, and was a rundown of skills that anyone who considers themselves to be a hacker should have, or be striving towards.  1o57 was concerned at the state of the hacker scene, in that many people he talked to couldn't even do a 4-bin binary count-up.

The talk was great, but left me concerned.  I picked up a copy of The Absolute Beginner's Guide to Binary by Greg Perry, as a refresher, and found it to be quite an enjoyable read.  Greg explains Binary, Bits, Bytes, and Hex in enough detail as to not leave anything out, yet at a level of readability that I would recommend it even to complete novices of base-2 math, and computers in general as a great text to fully explain the topic to them.

Mr. Perry also gives several topics throughout the book that he leaves to the reader as areas for farther research, which is something that I, personally, find to be very attractive.   It lets the reader branch out and expand their horizons in an organic way.  This is a fantastic learning style for hackers.  Thus, I would definitely recommend this book to anyone who is interested in computers, electronics, or digital communications, but needs a bit of work at the bits and bytes level.

Finding Unused IPs

I recently had a need to fit a new host onto a crowded network, without well documented address assignments.  This led me to several obvious answers, all of which required reading long lists of IP addresses while looking for gaps here and there.  Since reading through DNS zone files, or filtering Nmap ping sweep output didn't sound like much fun, I threw this little guy together.

#!/usr/bin/perl
#############################
## ipchecker.pl            ##
## (c)2012 Peter H. Ezetta ##
#############################


use strict;
use warnings;
use 5.010;

my @results;

foreach (`nmap -sP -v 192.168.0.*`) {
    chomp;
    push( @results, $_ ) if (/^Host/);
}

foreach (@results) {
    say if (/down/);
}

Change the address in the foreach loop to match the network you're scanning, and Nmap will run a ping scan like normal, with a nice little Perl wrapper to only give you the hosts that are down, instead of  up.

"Borrowing" A Screen Session

GNU Screen is a tool that most everyone reading this will be aware of.  In a nutshell, it's a terminal multiplexer, that is, it allows multiple virtual terminals to be brought up in one screen session.  Very useful when you're on the terminal.

Another purpose that is used quite often is to allow long running scripts to run on a remote server, without having to worry about your SSH session getting disconnected.  One would simply start a screen session, run their script, and detach from the screen session, leaving the script to do it's work.

This can occasionally be a problem when one system administrator has started a long running process, and for whatever reason, another system administrator needs to get into the screen session, when it's owner isn't present.  Attempting to su user, then attach to the screen session will lead to the following error:


[14:43:06] [peter@server ~]$ sudo su user
[sudo] password for peter: 
[14:43:45] [user@server /home/peter]$ screen -l
Cannot open your terminal '/dev/pts/2' - please check.
[14:43:53] [user@server /home/peter]$

A quick check of the permissions of /dev/pts/2 reveals the problem:


[14:43:53] [user@server /home/peter]$ cd /dev/pts/
[14:51:42] [user@server /dev/pts]$ ls -lsa 2
0 crw--w---- 1 peter tty 136, 2 2012-11-04 14:51 2

As we can see, the terminal I'm connected to is owned by my user, not effective user that we assumed with su user.  One solution would be to chmod +w /dev/pts/2, but allowing other users to connect to our pts device poses a security risk.  Enter script.

Script is used to create a typescript recording of everything that happens in a terminal, as long as script is running.  It will connect to a new tty device when it is called:

[15:00:20] [user@server ~]$ script test

Script started, file is test

[15:00:25] [user@server ~]$ tty

/dev/pts/3

[15:00:32] [user@server ~]$ ls -lsa /dev/pts/3

0 crw--w---- 1 user tty 136, 3 2012-11-04 15:00 /dev/pts/3

As you can see, by calling script, we have obtained a new pts device, and it's owned by user, not by peter.  This means that we can now screen -d -r to attach to user's screens, even in his absence.

One last note:  If you don't have a purpose for the typescript file that is generated by script, just give it /dev/null as an output file:  script /dev/null, which will throw away the typescript.

Lines of Code

This is going to be a short one.  The other day, one of my friends asked me for a quick way to tell how many lines of code were in a project directory.  Here was my solution (thank you, Perl!)

$ find . -name '*.pl' | xargs perl -e \
'my $x = 0; foreach (<>) { $x++ }; print "$x\n"'

Of course the *.pl can be changed to whatever extension you would like, and TIMTOWTDI, but I happen to be fond of foreach loops and the <> operator, so...