Ax0n's Insight

I can't vouch for all hackers. I can't even vouch for my fellow HiR contributors. All I can do is tell you where I came from and what shaped me into who I am today. I must tell you that the mainstream image of "hackers" has obviously strayed a great deal from reality. Think of Matthew Broderick in WarGames. He wasn't malevolent. He was a bit mischievous, perhaps, but not a cyber-terrorist. He was curious and brilliant and he got in over his head.

I define "hacker" somewhere between any person who, by virtue of curiosity, must know everything about something and any person who refuses to blindly accept posted limitations. I also think that "hacker" is a strong word that usually shouldn't be used introspectively. I call myself a tinkerer.

My personal motto is this:

If something is broken, I can usually fix it.
If something is not broken, I can usually make it faster, better or easier to use...
or I can break it.

My parents were kind of technical. My mother comes from a long line of tinkerers and engineers. My father comes from a strong mechanical discipline, and knew the advantages that computers would offer in the future.

One of the very first truly affordable and personal computers was the Timex Sinclair 1000. It was released in Europe in 1981 as the Sinclair ZX-81, and found its way to our side of the pond a year later through a partnership with Timex. It was powered by a Zilog Z80 CPU, was about 6 inches square, about 3/4 inch thick. It had a tiny touch-membrane keyboard mounted on the computer case itself, and had composite video output (Black and White) for a Television as a monitor, and used a cassette tape for data storage. Out of the box it came with a scant two kilobytes of RAM. To put things into perspective, this paragraph would fill more than half the RAM of my old Timex. My dad purchased the $100 kit from a local department store and had to solder all the parts together himself. For an extra $25, if I recall correctly, he could have purchased one that was as ready-to-run as they come (which wasn't all that ready-to-run, it just didn't require assembly)

This isn't about my dad's old Timex, though. I was about four years old when he bought it. Most of the programs for it were found in magazines and required the user to type them in by hand. As you can imagine, this wasn't a difficult task with only 2kB of RAM. Before I was 5, I was already messing with the Timex. I had learned how to turn it on and load programs that my dad had recorded to tape. The programs sounded faintly like a modem handshake, and I liked that sound, despite its cold, harsh tone. The whole experience was mysterious and magical to me.

By the age of five, I was modifying programs and saving them to tape. I started by putting my name on the side of a bomber plane (which was drawn with block characters on the screen) in one of the games. Later on, I made my own text programs. I was also rabidly taking apart anything I could find screws on. This included mechanical spring-wound alarm clocks, radios, TV remotes, my toys, and anything else I felt like opening up. Curiosity had gotten the best of me. A firm grasp of mechanical synergy had not quite bestowed its wisdom upon me, yet. My parents often ended up having to re-assemble or simply throw away things that I'd broken with hand tools.

I have to give a lot of credit to my father and to my grandfather on my mother's side, as they were my earliest inspirations for mechanical hacking. As any Father should, my dad used me as early as possible for my extra set of hands. Sometimes it was to fetch a beer, but more often it was to hold a screwdriver or wrench while he worked on his truck. I observed while he replaced a timing chain, serviced his transmission, did oil changes, and even patch a hole in the gas tank.

My grandfather was the bona-fide definition of an Optics Hacker, even back in the 1940s. His team took and refined the crude fresnel lens to come up with the paper-thin magnifying surfaces found today in projectors, on cheap bookmarks, etc. On top of microscopes, telescopes and photography equipment, he also had a full machine shop in his basement where he spent hours and hours crafting devices made of wood, PVC, glass, metal, and plexiglass. Furthermore he was an electronics tinkerer. His basement was a mad scientists laboratory of anything and everything you could think of (even a kitchen sink!) It's easy to see where I got the itch to tinker beyond what's normal for a kid.

I was born a little late to really savor the experience of the technology of the early 1980s, but that didn't stop me from finding dial-up BBS systems, mainframes and UNIX servers in the mid-to-late 1980's. My first foray into dial-up servers (as opposed to BBSs) was the local library. Using some trickery at the library itself, I found the unprivileged account information to allow me to log in to the library with my modem. This resulted in me being able to reserve books, browse the card catalog, view full magazine articles, and even request inter-library transfers all from the comfort of my home as if I were in the library. I eventually found the IP Address for the server by using one of the more privileged "research terminals" to telnet out to somewhere that would show my the IP Address I was coming from. Via the Internet, the library's server had even more interesting things to show me. I spent a great deal of time not just using, but tinkering with the library's software. I used their services "under the radar" for many years before they replaced the entire system with a more modern Web-Based solution.

While still in high school, I was accepted to take certain classes for high-school and college credit at the local community college. I always made sure to enroll myself in a few classes that would require UNIX shell access. This was great, and really helped me sharpen my shell scripting and UNIX userland skills. My dad and I had tried Linux in 1994, but with only one Linux-capable computer in the house and not enough space to really dedicate to a Linux partition, we abandoned the project early on. Legitimate shell accounts were the only way I really could play with anything other than DOS.

In parallel to this, I was learning how to solder, and how to build circuits using schematics I'd find printed in books. My mechanical interests were becoming more refined as well, leading me away from Lego creations and repairing broken power tools, and into working on two-cycle engines and picking locks. In college, I took classes that would allow me to practice what I liked doing while earning high marks. This included small engine repair (four cycle), photography, networking (IT) and even a few programming classes. Oddly enough, I met Asmodian X, one of HiR's contributors, through one of the IT classes.

It's important to note that I didn't learn a lot from my coursework in these classes. My instructors were often my mentors, and I would often use the class time as an opportunity to mess with similar things of a more advanced nature. Some of my professors thought of this as goofing off, but I usually scored well on tests, so they let me be.

I'm at a phase in my life now where I'm still striving to know more about everything I'm interested in, and I'm constantly looking for more things to be interested in. I've chronicled a few stories from my life which brought me here. Just remember, it's not about how many web pages you can deface. It's not about how many uber-secure servers you can weasel your way into or how good your social engineering skills are. It's about a lifestyle of curiosity and constant learning.


Encrypted filesystem images

Hola boys and girls, in this article I will speak a bit about encrypted file system images. There are many different utilities out there and each modern operating system has some kind of encryption scheme for either all or parts of their file system.
This is a short list of utilities that are available to the general public. Ill cover the basics of what an encrypted file system image is and list a few publicly available implementations for your information.

This article is intended for advanced users with a well-rounded understanding of how a computer and operating systems work.

-=- ToC -=-
x.......... Introduction
1.......... What is an encrypted file system
2.......... Uses of encrypted storage
3.......... Implementations of note with feature breakdown
4.......... Summary
5.......... Works cited

1.......... What is an encrypted file system
An encrypted file system consists of two parts, the file system (an organized system of storing binary data in an organized fashion). The other part being encryption, which is scrambling data in an organized fashion so that only designated parties may view it. In this article I am speaking about a file with in a file complete with its own file system and not dependant on the file system which the physical media that the file resides on.

2.......... Uses of encrypted storage
Secret codes as a concept are well known, it allows you to speak in a public area with out the information being revealed to un-intended recipients. The Internets data privacy is only safe because no one cares to dig through the deluge of information to figure out what your doing. In the novel "Takedown" regarding the capture of Kevin Mitnick, the authorities and two over zealous private citizens proceeded to track a persons activities via packet sniffing an entire ISP. This was done transparently so no one knew his or her privacy has been violated all to hell.

Encryption has become necessary as the medium of the Internet and computers in general have been under attack by governments, multinational corporations and criminal institutions.

Encryption is not the ENTIRE answer to these threats though. Being proactive about your computer usage routines so that you minimize communicating in an un-secure fashion is very important. Protecting your computer from rogue programs and un-trusted software is also important. All this while asking yourself, "what is this information worth." If the answer is ever your life, then you have best be prepared to dedicate a sizable portion of your life to servicing the protection of that information. Security is about setting the bar for your would be intruder. Basic security keeps the honest people honest, medium security keeps the burglar at bay, and comprehensive security keeps the bogyman out. Encryption can be very effective as an effort multiplier when used correctly.

3.......... Implementations of note with feature breakdown
- 3.1 Integrated encrypted file systems (OSS/Un*x):
Native utilities within most of the free Un*x like os's have included crypto.
Most of which have the capacity to create "memory disks" or "looped file systems". The utilities typically have the option for encrypting the data.
In Linux in the 2.4 series and greater a person can do the following command:
$ dd if=/dev/zero of=enc_vol.img bs=1k count=4096
$ losetup -e 3des /dev/loop0 enc_vol.img
$ mkdosfs /dev/loop0
$ mount /dev/loop0 /mnt/

This system can use XOR and DES encryption by itself, if additional encryption algorithms are compiled into the kernel then you can make use of those too. The files created in this format are compatible with FreeOTFE, which is also available on windows and some mobile devices.

*** A side note -there was a paper which was written by Jerome Etienne titled "Vulnerability in encrypted loop device for Linux". In short, this is not a problem getting access to encrypted data, but making educated guesses and moving encrypted data around in the encrypted file. Since the file system doesn’t care about what data is where so long it’s in accordance with the file system structure the changes would not be detectable to the system. This attack is classified as a Denial of service attack but could be also classified as a kind of instant replay attack. The suggestion by the author is to authenticate to each data block or authenticate the integrity of the entire file system at boot time. The truly paranoid may want to perform a hash on the encrypted file system image via a mounting and unmounting script. This is a minor issue because the integrity of the information is controlled more by safe computing practices and physical security than encryption (Etinne, 2001).

In light of the looped file system and its shortcomings dm-crypt and LUKS have been developed as an alternative.

Prerequisites: A Linux 2.6 kernel with device mapper and dm-crypt support is needed. Also install cryptsetup-luks the package and util-linux package (g-loaded, 2005).

# cryptsetup --verbose --cipher "aes-cbc-essiv:sha256" --key-size 256 \
> --verify-passphrase luksFormat /dev/mydev/zipdisk
# cryptsetup luksOpen /dev/mydev/zipdisk encr-zipdisk
# mkdosfs -v -F 16 -n "ENCR1" /dev/mapper/encr-zipdisk
# mount -t vfat -o rw /dev/mapper/encr-zipdisk /mnt/tmp/

OpenBSD supports memory disks or Virtual Nodes and this is done by:
$ vnconfig -k svnd0 /tmp/cryptimg
Encryption key:
$ mount /dev/svnd0c /mnt
This uses the blowfish algorithm for encryption (OpenBSD, 2007).

- 3.2 Encrypted Volume Utilities for commercially desktop systems:
---Ms Windows---
NTFS file encryption is available on Microsoft Windows XP Professional and supposedly Vista Business, Premium and Ultimate on a per file basis. Ultimate supposedly has full disk encryption utilizing their trusted computing hardware (Microsoft 2007).

Typically with the standard NTFS crypto you need to be using their latest version of the NTFS file system.
-Right click on the files you intend to encrypt.
-Select advanced
-Click on the encrypt check box.

Alternatively you can use the cipher command.
c:\echo "HiR" > example.txt
c:\cipher -e c:\example.txt

Encryption in windows this way is transparent to the user, it looks to them like any other file, however its encrypted on the disk so recovery by a third party person who has direct access to the file system is unlikely.

The file system will then enable the "encrypt" attribute which keys off of your account login info. So in order to access the content you will need the person's login info.

---Apple Mac OS 10---
Mac OS 10 has encrypted volume file creation available with AES encryption (Apple, 2007).

Select Macintosh HD -> Applications -> Utilities -> Disk Utility -> File -> New -> Blank Disk image
... Then put in the file name (ex. file)
-> select encryption -> AES-128 -> put in the password -> DONE!

Whenever you click on the image it will mount and ask for your password (assuming you don't put it in your keychain).

Of course this can be done in the command shell too.
$ hdiutil create -size 10m -encryption AES-128 -stdinpass test
Enter disk image passphrase:
created: /Users/jkershner/Desktop/test.dmg
$ hdiutil attach test

- 3.3 Third Party disk encryption systems:
Can create layered encrypted file systems images with a form of segnagraphy which a user can use a panic password to display the outer non-sensitive disk image, and a normal password for normal access to the disk image. It also can use file keys, which are existing files located anywhere on the computer, which the program uses as part of the authentication process. It can either use files on the hard drive or it can directly access devices such as hard drive partitions, entire disks or jump drives. In addition to secure file access by reading encrypted data in packets and keeping it in memory so that it does not hit the disk in unencrypted form. This is a free utility available on Windows and Linux platforms (TrueCrypt Foundation, 2007).

Operates under both PC (MS Windows 2000/XP) and PDA (Windows Mobile 2003/2005) platforms Linux compatibility (Crypto loop "losetup", dm-crypt and LUKS supported) "Hidden" volumes may be concealed within other FreeOTFE volumes, providing "plausible deniability" FreeOTFE volumes have no "signature" to allow them to be identified as such Encrypted volumes can be either file or partition based (Dean, 2007).

- 3.4 Steganographic features
The most compelling features are the features offered in some of the 3rd party utilities which use a false nested file system image which is accessible with a panic password incase you are cohersed into giving the password so that at this first glance there would be plausible deniability (Dean, 2007)(TrueCrypt Foundation, 2007).

Simply renaming the encrypted volume file to appear as something else (such as an MP3 or a JPEG) requires the use of a 3rd party stegnagraphy utility such as Jsteg(Guillermito, 2004). Unfortunately there are ways of detecting this kind of embedding in images and possibly in other kinds of stegnagraphic containers formats (Raggo, 2007)(Fridrich, Goljan and Hogea 2006).
4.......... Summary

We have glossed over several methods of securely storing sensitive information. Combining these methods with other methods of securing information physically, electronically (through ciphering) and through safe computing practices you should have a fighting chance at keeping your data from prying eyes. Granted the data we are protecting is usually not as valuable as we think nor so worthless as to not disserve our attention to keeping it safe. A little paranoia can be healthy.

5.......... Works cited

Jessica Fridrich, Miroslav Goljan, Dorin Hogea. "Steganalysis of JPEG Images: Breaking the F5
Algorithm." (April 2006)

Guillermito. "Extracting data embedded with JSteg." (February 2004)

Raggo, Michael. (Accessed February 2007)

Etienne, Jerome ".Vulnerability in encrypted loop device for Linux" (December 2001)

Shimomura, Tsutomu and Markoff, John. "Takedown: The Pursuit and Capture of Kevin Mitnick, America's Most Wanted Computer Outlaw-By the Man Who Did It." Warner Books Inc (December 1996). ISBN-13: 978-0786889136

-3rd Party Security Products
Dean, Sarah "Free OTFE." (Accessed February 2007)

TrueCrypt Foundation websirte. (Accessed February 2007)

-Opperating systems, security feature implementation and howto's

Microsoft Inc. "Encrypting File System overview." (Accessed February 2007)

Apple Corp. "Mac OS X: How to create a password-protected (encrypted) disk image." (Accessed February 2007)

g-loaded.eu, "Encrypt devices using dm-crypt and LUKS." (November 2005)

OpenBSD foundation. (Accessed 2007)



Build your own network appliance

You're probably used to seeing "appliances" - that is, certain kinds of embedded computing devices -- on a daily basis. Embedded computing is a pretty broad term. It can include obvious things like ATM machines and display kiosks, or less obvious computer-controlled devices like mobile phones and wireless network routers.

Appliances usually describe a smallish computer with a dedicated purpose. These are usually slow computers with no hard drive, very little RAM, and often lacking a monitor, keyboard, or graphical display.

The wireless network router is a perfect example. It has no screen, no input method except for a reset button, very limited RAM, and little bit of flash memory for saving user-defined settings. The user interaction takes place via the network, mostly through a small web application. Most of the time, it just sits there doing its job without the owner giving it a second thought. It may go months or even years without being rebooted or any other user interaction.

There are four main things you need to carefully consider before starting out:

Hardware: Since it will potentially be running 24 hours a day for years on end, the appliance should be built on a reliable and/or easily replaced hardware platform.

Operating system: Ideally, the operating system on a network appliance will take up as little space as needed, and have only the most basic set of tools to get the job done.

Configuration & resilience: An appliance should be resistant to damage that can be caused by a sudden power-off or reboot, but changes made in the user interface should be stored to non-volatile memory as soon as the user chooses to save the configuration.

Daemons & Services: A little network-attached computer that doesn't do anything for the network is just plain useless. Be creative.


With modern technology, it's not difficult to meet the hardware requirements that an appliance demands. A motherboard and processor can last longer than a decade. Most computer hardware failures are due to moving parts such as cooling fans and hard drives. If you take the moving parts out of the equation, it's possible to build a computer that will be reliable for years to come.

Building an appliance out of a normal, everyday PC is possible. Get a motherboard that supports booting from USB, or purchase a solid-state hard drive (including those IDE-to-Compact-Flash adapters), under-clock the CPU and pick up a really good heat sink. There will be no need for a CPU fan, and if the fan in the power supply fails, it still should function properly.

A more practical route is to built a mini-ITX system. These are small motherboards, usually with slow but cool-running processors. They usually require no ventilation and are powered by an external power brick, without a real power supply in the case.

Another option is the use of a specialized ultra-compact, low-power computer that's purpose-built for this sort of thing. On the forefront of this market is Soekris Engineering. Soekris manufactures and sells purpose-built appliances that are for the most part x86 compatible. You can order just the components you want, or you can purchase it assembled into a high-quality metal case that's no bigger than an average-sized small-office ethernet hub. The logic boards come with at least one serial port for console interaction, and can be specified with several ethernet ports, cardbus, compact flash, and miniPCI connectors. They are affordable in small quantities for tinkering and prototyping, with heavy discounts on bulk orders.

Operating System

The operating system, as the base of your appliance, should be rock-solid and of course should have hardware and software support for everything you plan on doing with your appliance. The last thing you want is a setup that requires you (or your users!) to constantly reboot the appliance because of an unstable kernel, un-tested third-party patches for unsupported hardware devices, and the like.

Several appliance developers have chosen to go with OpenBSD, with many of them choosing Soekris hardware as their platform. Installation of the operating system in an "appliance" style really doesn't vary too much from platform to platform as much as it varies depending on the type of media that you plan on installing onto. Since we want to keep moving parts to a minimum, the best media to use is some sort of flash memory such as a compact flash card or a USB flash drive. Generally speaking, compact flash cards have the highest performance potential assuming you don't bottle-neck their performance by hooking them up via a USB card-reader. Many of the Soekris appliances and mini-ITX motherboards come with a built-in CF slot and support booting off of compact flash. On other mini-itx systems and most full-sized computers, you will probably end up having to boot off of a USB flash drive, but if you never need to change configurations, you could just as easily burn your installation to a CD and boot your appliance that way.

Flashdist is one project that aims to make it really easy to install OpenBSD onto an appliance. The author's target is Soekris, but in reality flashdist will work to install a compact version of OpenBSD onto a small flash drive, and the resulting flash drive should boot OpenBSD on any system that supports booting from USB, although I'd strongly recommend re-compiling the OpenBSD kernel with only the hardware support and options that are needed for your project.

Getting the base operating system installed is somewhat beyond the scope of this article. There are several other projects that you can find for getting various other operating systems to run on a very compact environment. Some are made with Soekris in mind, while others, such as m0n0wall are made to boot a full-sized desktop or server PC from CD and write configuration information to magnetic media, such as a floppy diskette.

Configuration & Resilience

This is a big one. Resilience is usually achieved by leaving the boot media mounted read-only so that files can't be easily corrupted if power is suddenly lost. Configuration changes can be saved by re-mounting the drive in a read/write state just long enough to modify the necessary files.

An operating system still needs a place to store its temporary files, and it's quite possible that other services you install on your homebrew appliance will also want to store logs, or otherwise require some writable drive space. This is achieved through the use of ramdisks. Usually, an appliance only keeps temporary logs that vanish once it's rebooted. Ramdisks for /tmp and /var are most common. This allows the system to use the binaries and libraries directly from the boot media, while giving the operating system and daemons somewhere to store logs and temporary files.

You will likely have to tinker with the configuration of the OS and daemons you choose to run. Ramdisks are meant to be small, so you will want to make automated provisions to keep them from becoming full of clutter, carefully monitoring them while you're in the development process.

Daemons & Services

This is where creativity comes into play, but this can also heavily steer the hardware requirements for your project, as well. If you want to make a network attached storage (NAS) file server, you will probably need to have a real hard drive. Some Mini-ITX systems have provisions for a 2.5" laptop hard drive, but I haven't seen a Soekris board that has this feature. You could make an 802.11 bridge to join two wireless networks together, a network sniffing and intrusion detection appliance, a web server load-balancer, or even a simple firewall for your home network. The opportunities are almost limitless!

PCEngines: Adapters to attach a CF card to a normal IDE controller
Soekris Engineering: Manufacturers of high-quality x86 appliance hardware
Flashdist, a package for creating embedded OpenBSD installations
M0n0wall, a ready-to-run network appliance CD-ROM


Solaris Zero-Day... Good grief!

Today, the SANS ISC sent out an alert regarding a telnet exploit against Solaris 10

They posted a snort rule to detect it. They originally posted a snort rule which could be used to detect the exploit being attempted. In part, it included the hex string:

55 53 45 52 01 2d 66

The above is part of the TELNET protocol where user authentication credentials are passed, with the last two octets being ASCII for "-f". The string is no longer part of the ISC post.

The login(1) man page on Mac OS X says this about the -f flag:

-f The -f option is used when a user name is specified to indicate
that proper authentication has already been done and that no
password need be requested. This option may only be used by the
super-user or when an already logged in user is logging in as

Basically, if you pass "-f" before your username to the telnet daemon, it says "just trust me, I'm authenticated, I promise!" to the login(1) process.

Fortunately, most people shut down telnet in favor of the more secure ssh protocol. I still can't believe that this has been a problem for this long without being caught. Also, I believe Solaris restricts root from logging in anywhere other than the console.

I tried this against my Sun Ultra 5 running Solaris 10. Trying to login with "-faxon" did not work. However, passing -l "-faxon" on the telnet command line DID work. Root did not work because root can only log in on the console. Here's some screen caps. This is just embarrassing.


newLISP OTP implementation

I had some free time, so I came up with something fun to play with.

I can't stress enough the importance of protocol when dealing with cryptography. Leaving no trace of the used portion of the pad nor the cleartext file is essential to maintaining the secrecy of your messages.

Some operating systems let you set flags or attributes on files so that they're automatically secure-erased when deleted. Other operating systems require a tool such as "wipe" or "shred" to completely destroy the files. The "leftover" pad can be re-used for future communications. You can make the pad as large or as small as you wish, but it must be larger than the file you wish to encrypt, and it's up to all parties to keep their pads "in sync" with the others. I didn't say OTP was practical, it's just really good when implemented correctly.

I advocate keeping ALL sensitive files (the pad and cleartext) on a USB flash drive along with a secure-erase tool. If the risk of compromise exists, 5-10 seconds in a microwave will render it and all contents completely useless. Although USB flash drives are solid state, given the nature of their construction, it's been proven that some information may be retrievable from them even after a secure erase. Always use your head.

Now that the formalities are out of the way, let's get started!

First, I created a 5kB file of pseudo-random data to use for my pad, and made a copy of the pad for the recipient.

Chimera:~/test ax0n$ dd if=/dev/urandom of=pad bs=1k count=5
5+0 records in
5+0 records out
5120 bytes transferred in 0.001332 secs (3843715 bytes/sec)

Chimera:~/test ax0n$ cp pad receiver-pad
Next, I launched my script. It requires 4 pieces of information. The pad file, the file to encrypt or decrypt, the output file, and the file to write the leftover portion of the pad to. After running it, you can see the script, the leftover pad, the original pad (which should be secure-erased immediately after use), the encrypted target file (in this case, my /etc/passwd file) and the pristine copy of the original pad which should have been handed (never transmitted!) to my recipient.
Chimera:~/test ax0n$ ./crypt.lsp pad /etc/passwd passwd.crypt leftover-pad

Chimera:~/test ax0n$ ls -la
total 56
drwxr-xr-x 7 ax0n ax0n 238 Feb 7 22:36 .
drwx------ 55 ax0n ax0n 1870 Feb 7 22:33 ..
-rwxr-xr-x 1 ax0n ax0n 675 Feb 7 22:33 crypt.lsp
-rw-r--r-- 1 ax0n ax0n 3188 Feb 7 22:36 leftover-pad
-rw-r--r-- 1 ax0n ax0n 5120 Feb 7 22:36 pad
-rw-r--r-- 1 ax0n ax0n 1932 Feb 7 22:36 passwd.crypt
-rw-r--r-- 1 ax0n ax0n 5120 Feb 7 22:36 receiver-pad
Here's part of the hexdump from the encrypted password file. It's very, very random.
Chimera:~/test ax0n$ hexdump -C passwd.crypt
00000000 d3 17 89 23 2f 51 bc 9c c2 3d d3 b3 fb e0 5c 4b |...#/Q...=....\K|
00000010 43 8e 4f e7 71 53 c7 fd 2b b2 ff 37 32 64 3a 2d |C.O.qS..+..72d:-|
00000020 df 8e 19 fa 64 07 c9 8d f2 36 f0 41 e6 ca 65 67 |....d....6.A..eg|
00000030 a3 a4 e6 b0 dc 48 14 08 12 0d c4 72 1a 18 c6 bc |.....H.....r....|
00000040 0a cd 79 69 2b f2 62 15 63 48 da f5 3d 36 41 e8 |..yi+.b.cH..=6A.|


00000730 4c 71 17 04 13 50 d2 e0 ab 3a 2d 44 16 0d 72 cf |Lq...P...:-D..r.|
00000740 60 47 16 43 8a 1f 73 03 e8 e9 b8 71 d6 ee fd 68 |`G.C..s....q...h|
00000750 09 dd 81 60 35 65 0b 8f 66 03 97 f4 96 39 78 44 |...`5e..f....9xD|
00000760 f8 24 99 bc 68 6e 28 14 f3 2f fc 0a a3 68 47 70 |.$..hn(../...hGp|
00000770 fd 41 fc 51 e2 c2 0c de 07 be 40 ce 6c a8 bb 5b |.A.Q......@.l..[|
00000780 88 4b 52 50 a4 95 b5 37 71 12 12 76 |.KRP...7q..v|
On the receiving end, we use the receiver-pad file against the encrypted password file, then we can see the new files with ls.
Chimera:~/test ax0n$ ./crypt.lsp receiver-pad  passwd.crypt passwd.clear reciever-leftover-pad

Chimera:~/test ax0n$ ls -la
total 72
drwxr-xr-x 9 ax0n ax0n 306 Feb 7 22:38 .
drwx------ 55 ax0n ax0n 1870 Feb 7 22:33 ..
-rwxr-xr-x 1 ax0n ax0n 675 Feb 7 22:33 crypt.lsp
-rw-r--r-- 1 ax0n ax0n 3188 Feb 7 22:36 leftover-pad
-rw-r--r-- 1 ax0n ax0n 5120 Feb 7 22:36 pad
-rw-r--r-- 1 ax0n ax0n 1932 Feb 7 22:38 passwd.clear
-rw-r--r-- 1 ax0n ax0n 1932 Feb 7 22:36 passwd.crypt
-rw-r--r-- 1 ax0n ax0n 3188 Feb 7 22:38 receiver-leftover-pad
-rw-r--r-- 1 ax0n ax0n 5120 Feb 7 22:36 receiver-pad

Let's see if the decrypted file is legible...

Chimera:~/test ax0n$ cat passwd.clear
# User Database
# Note that this file is consulted when the system is running in single-user
# mode. At other times this information is handled by one or more of:
# lookupd DirectoryServices
# By default, lookupd gets information from NetInfo, so this file will
# not be consulted unless you have changed lookupd's configuration.
# This file is used while in single user mode.
# To use this file for normal authentication, you may enable it with
# /Applications/Utilities/Directory Access.
nobody:*:-2:-2:Unprivileged User:/:/usr/bin/false
root:*:0:0:System Administrator:/var/root:/bin/sh
daemon:*:1:1:System Services:/var/root:/usr/bin/false


tokend:*:91:91:Token Daemon:/var/empty:/usr/bin/false
unknown:*:99:99:Unknown User:/var/empty:/usr/bin/false

Yep, it worked!

Let's look at the newLISP code for this project. On the newLISP discussion boards, cormullion and Lutz (the founder of newLISP) reminded me of the beauty of the "cond" command, which works a little bit like "case" except it evaluates whole expressions, not just one variable. I added a bit of whitespace into the code to show how "cond" works. They also helped me re-factor my argument assignment statements down to one line with "map".

(< (length (main-args)) 5)
(println "USAGE: crypt.lsp [pad] [file] [output] [pad-remainder]")
(map set '(pad target output remainder) (rest (rest (main-args))))
(write-file output (encrypt (read-file target) (read-file pad)))
(write-file remainder (slice (read-file pad) (length (read-file target))))

Instead of taking the painstaking route of stepping through all the logic to show how XOR encryption works like I did in my cryptography example a few days ago, I am using as many newLISP shortcuts as I know how to while maintaining the feature set I want. For instance, newLISP has the "encrypt" function which is exactly what I was using in my original example. It runs a bitwise XOR of the contents of two variables, even if those variables contain the entire contents of files! There's no need to explode strings, map the char command, or anything like that. In the above example, newLISP essentially handles all the core logic in this single line:

(write-file output (encrypt (read-file target) (read-file pad)))

It single-handedly reads the pad and target file, XORs them with the encrypt function and writes the resulting garble to the output file.

The line below it figures the length of the target file, skips over that many bytes of the pad file and writes the remaining bytes in the pad out to the remainder file.

Look for more articles like this as I keep playing with newLISP and learning more about it.


Cryptanalysis and histograms

I've been interested in cryptanalysis and encryption for a long time. I can remember using PGP in the early 90's, my little Zenith laptop taking literally hours to create puny 256-bit keys, and being utterly fascinated by the whole process.

One way that cryptography is analyzed is letter frequency counting. There are certain characters that show up more frequently than others depending on what natural language is used. In letter substitution and other simple encryption schemes, creating a histogram of some random samples of that language (for my sake, we'll assume this is English), one can take that and lay it over the histogram of ciphertext, finding letters that are more common in the ciphertext and in the language sample. Analysts begin substituting letters that peak the charts, and eventually may come up with a partial decryption that's complete enough to go trial-and-error.

Histograms are just neat, though. Histograms of color data in photos are cool, too. Loosely speaking, histograms are bar graphs of frequency data.

Here is a histogram of the first chapter of Genesis (KJV):

On the far right are control characters such as carriage returns. The big vertical bar is the frequency count of spaces. To the left of that are numbers, then capital letters, punctuation, and finally lowercase letters toward the middle of the histogram. It's easy to tell that this is a text file from the histogram.

Next I'll show you a binary executable file, next to a GIF image. You can see these are binary files with a lot of "nulls" on the far right, and lots of high-bit characters on the left. They look nothing like a text file.

The beauty of a really good random one-time pad as I'd discussed in Wednesday's post becomes evident. On the left is a histogram of a really good random pad file. On the right is the first chapter of genesis (used in our first example) XORed against the random pad.

The entropy is evident!

I have an implementation of the newLISP one-time pad tool that I'll write about this weekend.

I used PHP/GD to create the histograms used in this article. Here's the quick-and-dirty histogram generator code I made:

# 256x256 byte frequency histogram maker
# by ax0n
header("Content-type: image/png"); // Tell browser to expect a PNG
if(! isset($_GET['file'])){
$im=imagecreate(256,256); // allocate image resource
$background_color = imagecolorallocate($im, 0, 0, 0);
$text_color = imagecolorallocate($im, 233, 14, 91);
$handle = fopen($filename, "r");
$contents = fread($handle, filesize($filename));
$histarray=(count_chars($contents, 1)); // built the frequency array
foreach ($histarray as $i => $val) {
$graph=($val/max($histarray))*256; // Normalize the values
imageline($im,$i,1,$i,$graph,$text_color); // Draw chart
$im=imagerotate($im, 180, 0); // make bars go from down to up (cheap hack)
imagepng($im); // dump image to browser
imagedestroy($im); // release image resource


Cryptography fun with newLISP

Some of you may have seen my article in the latest 2600 magazine about newLISP, a very fast scripting language based on LISP.

Well, the HiR crew has, for the better part of a year, been kicking around cryptography concepts. We keep coming back to one-time pad cryptography. It's fascinating in its simplicity. It's so computationally trivial that a human can quickly encrypt or decrypt a simple modular addition one-time pad scheme with nothing but a pencil and paper. The other thing is that, when implemented properly, OTP is perfectly secret and highly resistant to all forms of cryptanalysis. To this day, OTP is one of the most powerful and feared crypto schemes in existance.

Back here in computer world, we do a comparison on two numeric values assigned to the "cleartext" message. Since all ASCII characters have a decimal value in an 8-bit character space (256 distinct combinations), it's very easy to perform a bitwise Exclusive Or (XOR) on the cleartext and the key. XOR is simply "one or the other but not both". Let's try a cleartext of the letter A (binary 01000001) XOR against a key of "q" (binary 01110001). Comparing the bits vertically, the result will only have a "1" wherever either A or q have a differing bit at that location, but will have a "0" wherever both bits are the same.

-----00110000 (as it turns out, this is an ASCII uppercase "O")

newLISP, like all LISP based languages, handles lists and symbols very well. I just played around with this concept on the newLISP command line, and the result was fun, but not very practical as executed. I'll discuss ways to make this tinkering session a little more practical at the end of the article.

Ideally, the key would not be a string, but a very solid random set of characters known by the parties who are encrypting messages to one another. This doesn't even need to be a string, it may be binary random data...

A few things about this code. First, I'm a newbie at newLISP. Let me describe how some of this stuff works. The "explode" command turns a string variable into a list of characters. "char" turns a character into its ASCII decimal equivalent, or an ASCII decimal number back into a character. "map" simply takes the operation (such as "char") and uses that operation on a list. So (map char (explode cleartext)) would return the output of "char" for each individual character in the contents of the "cleartext" variable. Confusing enough? Okay, awesome!

newLISP code that I type will be in bold, red italics.
newLISP output will be in bold.
My comments will be in italics.

# newlisp
newLISP v.9.0 on OSX UTF-8, execute 'newlisp -h' for more info.

#first, I'll assign a key and convert it to a list of ascii numbers.
> (set 'key "Pa5$w0rd!")

> (set 'kcharlist (map char (explode key)))
(80 97 53 36 119 48 114 100 33)

#Then, I'll assign a cleartext string and convert it to a list of ascii numbers as well.
> (set 'cleartext "HiR ownz.")
"HiR ownz."

> (set 'ccharlist (map char (explode cleartext)))
(72 105 82 32 111 119 110 122 46)

#In many languages, newLISP included, the carat "^" is the symbol for XOR. This line outputs the XOR values for each character compared between the cleartext and key)
> (set 'cryptcharlist (map ^ ccharlist kcharlist))
(24 8 103 4 24 71 28 30 15)

#Note that some of the characters from the XOR operation are non-printable, so their ASCII string notation /nnn is used instead.
> (set 'cryptostring (join (map char cryptcharlist)))

#Now on the receiving end, we take the known key character list and we XOR the crypto character list. In reality we'd have to generate these again but we'd already set the variables above. No sense repeating the process here.
> (set 'decryptcharlist (map ^ cryptcharlist kcharlist))
(72 105 82 32 111 119 110 122 46)

#Finally, we take that string of numbers and join them after converting them from ASCII Decimal to characters again.
> (set 'decryptstring (join (map char decryptcharlist)))
"HiR ownz."

Now, as I'd mentioned before, in order to be really practical, you'd need an actual one-time pad that was very random. What I made above was a variant of Vernam cipher to give you a taste of how simple XOR based encryption is, not a genuine one-time pad. A few things that would make the above more practical:
  • A lot of the steps could have been consolidated. I broke it down to show how things worked. I could have simply put all of the logic in one line, but it would have been confusing.
  • The key and cleartext should be able to be read from a file. As implemented above, this should work with binary data (executables, images, etc) and with a very random binary key (pad) file.
  • In the code above, the key needs to be the exact same number of characters as the cleartext. If implemented practically, the program should read the length of the cleartext and use that many bytes of the random pad.
  • In a true one-time pad scheme, the sender and recipient both possess the same random key data, but the sender must destroy the part of the key that was used as soon as the encryption is performed. That way, only the recipient(s) may decrypt the message, as they have the only existing copy of the key. In turn, the recipient must destroy the part of the key used to decrypt the message so that in the event the encrypted message was compromised, there is no existing copy of the key available to aid in decryption.
  • The above inconveniences have been the main downfall to widespread use of OTP.
  • OTP's strength relies heavily on protocol, not technology.
As I get more free time, I will write a quick one-time pad newLISP script that can do most of the above things. I just got the craving to tinker and write a little bit, and thought I'd share it here.


Greetings from Asmodian X

Greetings from Asmodian X:
If I could describe my self. I am not a Hacker Per-Se but more like a Technologist with a mission to inform. In my eyes less is more. I don't believe in black and white what product is better. I believe in the best tool for the job.

Zero Configuration IP

*** Note from Asmodian X : This was written over a year ago but the
information is still viable from an educational standpoint. ***

Zero Configuration IP


Welcome Back! It is good to be writing again after the 5+ year hiatus. The target audience of this article are people who are of intermediate experience with networking. Almost all certificates and IT related programs have TCP/IP as a goodly sized chunk of their curriculum, therefore I should expect that a reader would know what TCP/IP was and how it works. For more general information on TCP/IP see: http://en.wikipedia.org/wiki/TCP/IP.

Shout outs to Axon, Frogman and Methodic.


0x01 ................... Objective
0x02 ................... Definition of Zero Configuration Networking
0x03 ................... How ZCN works
0x04 ................... The who's who of implementations
0x05 ................... Works Cited


----Part 0x01 Objective

The objective for this discussion is to gain familiarity with a part of the TCP/IP implementations called Zero Configuration Networking. Most notably Apple's newest operating system (OS 10) contains Apple's implementation of ZCN called Bonjour (also known as "Rendezvous"). Bonjour allows apple computers or any other computer using the Zero-Conf standard to immediately be able to use a network with out the use of manual network configuration or some form of DHCP http://en.wikipedia.org/wiki/DHCP). Windows XP implements some form of Zero-Conf networking for their wireless applications. Even MacOS 9 had this automatic configuration feature. The goal for Apple was to replace their Appletalk protocol with something that is more scalable. Zero configuration networking also has a specification for service broadcasting using parts of the DNS protocol called multi-cast-DNS and unicast-DNS.

----Part 0x02 Definition of Zero Configuration networking

Zero configuration networking is the ability for an un-administrated network node to be able to auto negotiate a network configuration requiring little or no user configuration. This configuration system is optimal for Ad-Hoc wireless networks, home networks and for emergency relief stations (Williams, 2002). A zero configuration network system should include the ability to configure itself in a fashion that allows it to talk to other similar hosts using the TCP/IP protocol. The randomly chosen addresses are checked to make sure that nodes do not collide with one another on the network. Part of this networking structure is to implement a service location capability. The reasoning for using a service location protocol is that the end user does not know what address the zero configuration system has chosen and therefore cannot easily find shared resources (Guttman, 2001)(Cheshire, Kochmal, 2004). Other networking protocols which require auto configuration are Multicast IP and IPv6 (Octavian, 2002).

----Part 0x03 How ZCN works

ZCN in most cases consists of a default behavior of a network interface. (Though some OS's have a separate utility for doing it which is not a fail-over condition.) The behavior first starts with the interface being in an automatic mode, such as either DHCP being selected or zero Conf mode being enabled. The interface shall then try to configure itself via DHCP. IF that fails then it will default to zero configuration mode that chooses an IP address on the 169.254/16 subnet. The 169.254/16 subnet being a private address space reserved for ZCN. If ARP detects an address collision (using an ARP broadcast) then it will back off and choose another random place on the network until it has found a suitable unused address. Assuming all hosts on this network follow the same procedure every one is now able to talk to each other. If at any time the interface is configured to use a rout-able address it must leave the link-local addressing scheme (Cheshire, et al. 2004). There are, of course, exceptions such as Un*x's virtual networking interface but because this is a link-local addressing system the addresses used are not rout-able unless something like network address translation (NAT) is used.
The catch at this point is that each computer is now able to speak to each other, but no one at this point realizes that any one else is on the network. In order to find resources on this new improvised network requires some form of advertisement protocol. There are many was to do service location, one way to do service location is NetBIOS. Microsoft originally used NetBIOS, to facilitate the creation of local area networks. Apple computers came from a similar desire to make local area networks and they called their protocol set Appletalk. Both NetBIOS and Appletalk broadcast over a subnet to advertise services. Both Apples Appletalk protocol and NetBIOS had issues when scaling into a large network with its high overhead (Cheshire, Stuart. Krochmal, Marc., August 2004). The newest method for ZCN service location consists of each workstation transmitting a special Multicast DNS broadcast to advertise its services to all of the other connected clients. Aggressive caching of these requests and responses keeps the overall service location traffic low (Cheshire, et al. 2004).
Multicast service broadcasting relies on several key items. Each station must have a mDNS responder that listens for requests and responds with a list of applicable services. The response is via Multicast so that all stations on a given subnet may hear and record this service. Unicast DNS can also be used to do this when crossing subnets. Since this system is designed for small implementations the need for routability is not acute. Recently a draft is being worked on by Apple that defines a NAT-Portmaping protocol so that a router can be added in a ZCN environment and all users can auto-magically gain access to that Internet connected device.(Apple, "Network Address Translation ...", 2004)(Apple, "Rendezvous FAQ", 2005).

----Part 0x04 The who's who of implementations

First and foremost the Apple Computer Corporation has an advanced implementation of zero configuration networking called "Bonjour." ZCN is implemented in various forms since Mac-OS 9 in whatever extent it's full implementation may be found as a part of Mac-OS 10.1 and newer. Apple has released C source for use on any other platform including windows.

A sketchy implementation for Linux and the BSD's called "HOWL"
is available for almost all flavors via source.

The sourceforge ZCN implementation for the link-local addressing
portion is the Zero-Conf project at sourceforge. It does not have the
Multicast DNS portions in working order, instead suggesting the use of
OpenSLP. (http://www.openslp.org/) (http://zeroconf.sourceforge.net)

Avahi Multicast DNS client.

One of the stronger Linux/BSD implementations currently implemented in
many distributions including Ubuntu and more.

----Part 0x05 Works Cited

Apple Corp. (December 2004). Rendezvous

Apple Corp. (January 2005). Rendezvous FAQ.

Apple Corp. (July 2004). Network Address Translation Port Mapping
Protocol. http://files.dns-sd.org/draft-nat-port-mapping.txt

Cheshire, Stuart. Aboba, Bernard. Guttman, Erik. (July 2004).
Dynamic Configuration of IPv4 Link-Local Addresses.

Cheshire, Stuart. Krochmal, Marc. (February 2004). DNS-Based Service

Cheshire, Stuart. Krochmal, Marc. (August 2004).
Requirements for a Protocol to Replace AppleTalk NBP.

Guttman, Erik. (July 2001). Zero-Conf Host Profile Applicability

Octavian, Catrina. Thaler, Dave. Aboba, Bernard. Et al. (October 2002).
Zero-Conf Multicast Address Allocation Protocol (ZMAAP).

Open SLP Website. (January 2005).

Porchdog software inc. (January 2005). Howl Project Website.

Williams, A. (September 2002) Zero Configuration Networking.

Zero-Conf sourceforge website. (January 2005).

Greetings from Ax0n

I'm Ax0n, founder of the old HiR e-Zine, extreme typo-fixer, and tinkerer.

I'm an OS-Agnostic, and use whatever platform gets the job done as comfortably as possible, although I am a little bit of an OpenBSD and MacOS X zealot.

I'm mostly interested in UNIX security, script-interpreted languages, cryptography, and physical security, but I'll probably cover a wider variety of topics.

Hello there.

Frogman here, of the old HiR crew. Longtime friend of ax0n and asmo. I'm a Mac user and spend some of my spare time playing with junk PCs and building them from parts. They usually end up with a Linux or BSD install as a part of the process. Do you want to see how to build a decent system for pocket change? Are you tired of the old upgrade cycle just to run a new OS, or do you want to make use of spare or decommissioned systems? I can give you tips for what to look for when shopping for a deal. Maybe you need tweaks to get your old system online with modern software. If you can build a system to a point where it can get online and browse the web, then it probably has 80% functionality for 95% of home users. Heck, you can even build an OS X capable Mac for well under $100 if you shop well.

Hackers care about value for their money. I'll post with tips on how to make the most of spending $50-100 at the computer stores, and $20-50 at used shops.