I am disappoint

That's my "oh FUCK IT" face right there.

As you know it's been a Very Bad Year for the hardware that populates DinkNET.  Not a single box that was running in January 2011 is still running in December 2011.  The one, tiny little bright spot in all this carnage was the fact that all the replacement hardware, a motley collection of refurbs and loss leader deals, came with 10/100/1000 NICs, making me think I could easily upgrade from my old 100Mbps and get some 21st century performance out of all this crap.  So I bought a (cheap) Gigabit unmanaged switch and jacked all the hardware into it, expecting to be dazzled by the sheer speed of it all.

But reality threw me a "Not so fast, sucker" on that plan.

One box, although it was "new enough" to have a 10/100/1000 NIC inside did not, in fact have one.  I had anticipated this and had ordered four of the cheapest gigabit NICs I could find.  Five bucks each, unbranded, which turned out to be generically packaged RealTek 8169s (shown below).

I was fine with RealTek, although I learned later that the brand was somewhat universally disliked by Linux driver developers.  Check out this comment:

The RealTek 8139 PCI NIC redefines the meaning of 'low end.' This is probably the worst PCI ethernet controller ever made, with the possible exception of the FEAST chip made by SMC. The 8139 supports bus-master DMA, but it has a terrible interface that nullifies any performance gains that bus-master DMA usually offers.

Srsly?  All I ever used were RTL8129s & RTL8139s (in the 90s I used a variety of NE2000 clones but let's not go there... the memories are too painful... and don't get me started on 3com 3C905s!).

Anyway, it was a Good Thing that I bought four of them because I ended up disabling every built-in 10/100/1000 NIC on the network.  They were all Broadcom, using the Linux tg2 (Tigon 2) driver.  After that, three out of four boxes talked to each other at full gigabit speed.

The slowpoke is the BOT House box, which is still running Debian 4.0r0, as it has been for nearly four years now.  The Windows 7 box I bought earlier this year did not have a Broadcom chipset (it was RealTek - go figure) and doesn't have a problem running full speed on the network now.

Enter The Fifth Box, my old WinXP dog.  Recently brought back from the dead to work on PoTTY 0.62, I installed the last $5 RealTek NIC to bring it up to speed.  No luck.  This is typical of the results I'm getting:

I get maybe 30 seconds of "near gigabit" speed and it immediately drops to 100 megabit-ish territory, regardless of being set to autonegotiate or 1Gbps/full duplex.

Considering that particular box is going back to the boneyard, it's probably not a Big Deal, but I'm still Mighty Pissed and Quite Disillusioned by the entire experience.

TCP Port 36081

Happy Annual Gift Day!

I woke up bleary-eyed this morning at around 3AM, disappointing the cats who thought it was breakfast time, and sat down at the computer and pulled up the proxy list. I was greeted with a smattering of new proxies on port 36081.

This struck me as unusual so I did a quick check of the database to see how long it's been going on.

And it's only been going on for the last five days (see also SANS data on 36081), but let me qualify that. I have been finding live, High Anon, CERN-ish proxies on this port for the last five days. Not SOCKS!

I had a smattering of hits in 2008 and 2010 on port 36081, nothing at all in 2009, and seven between January 1st and December 1st of this year (2011).

328 of them—96%—in the last five days. 100% are located on residential IPs in the US, making them useless for me, since I don't do US proxies, and they're spread out in 44 states pretty much by population with the top three states being Texas, California, and Ohio.

What's special about 36081, the number? Nothing. It falls in an "UNASSIGNED" IANA port range, which in itself is meaningful and probably not random. It's not prime. It's the Zip code of Troy (as in "Trojan"), Alabama. It's the part number of a popular surge protector.

Oh, GOODIE!

Something new and wonderful is happening!

PoTTY v.0.62 Testing Begins!

Last week, Simon Tatham announced the release of PuTTY v.0.62 which included a security fix that seemed serious enough to fire up the old compiler and shit out a new version of PoTTY.

I got to work on it last night and have the working binaries ready to rock and roll as soon as I can get them all tested.

This has gone much faster than the last time. I started hacking away at 1AM this morning and had a working PoTTY binary by 3AM. After a few hours of Sleepy Time I banged away at it and had the entire PoTTY "suite" done by noon.

Sometimes I amaze myself.

Not this time, though. I had a little help from our friends at AT&T. You see, we still have a land line here at Hinky House. For about a month the line started to degrade and it finally got so bad we had to call them out to the house to check the line.

Apparently the line had rotted out, so they replaced it. For a few days the new line laid on top of the lawn. Then on Thursday some time after 9AM they buried the line.

Cutting our CATV cable—and our Internet access—in the process.

So basically I had no distractions. I thought it would take a lot longer to "get 'er done" than it did, so in the process I decided to move the code over to VC++ 2010 Express, which I really haven't touched since I installed it. I thought that would add a half a day to the project but I was pleasantly surprised the transition went as smooth as it did.

Versions 0.60 and 0.61 were VC++ 2005 and 2008, respectively. 0.60 took forever to write. 0.61 took a whole weekend. I thought the cable would be fixed before I was finished, but it wasn't.

It still hasn't been fixed. And I have a funny feeling they're going to come here and say "we'll be back Monday" if they get here at all today.

Right now, I'm jacking in to the Web courtesy of one of my neighbors. The less said about that, the better, but in the process I learned an interesting lesson about using iwconfig (on BT5) to connect to open access points.

I couldn't stay connected for more than a dozen pings at a time. Then I noticed that whenever the link died the connection rate had been negotiated up to 30-54Mbps, which is not going to happen over your garden variety 802.11b link. You have to limit it yourself, since the default is "auto".

Check the man page. You'll figure it out.

UPDATE:

12/17/2011 — They fixed it. Now we have a coax cable running across the lawn. Maybe they'll cut AT&T's line when they bury it. This could go on forever!

UPDATE:

12/18/2011 — I missed a lot of cosmetic touches, mostly replacing almost every instance of "PuTTY" with "PoTTY". Then I checked to see what version OpenSSL was up to. Sure enough it had gone up a click since PoTTY 0.61 to version 1.0.0e. Building OpenSSL on a quad core machine is a lot more fun than on the old box 0.61 was built on.

After all that, I have what I believe to be the final build.

I checked to see if the old RDP back-tunneling issue had been fixed, but no luck there. Same old Black Screen of Death.

Another issue that might be Windows' problem concerns IPv6. I have had several PoTTY sessions connected over IPv6 that lasted for days and then all of them crash all at once. I have never seen this with IPv4. I'd like to get a Wireshark capture of this happening, but like I said it takes days of waiting.

The Unending Saga Of the Disappearing Access Point

Yeah... about that.

I rewrote my scripts to double-check the availability of the AP. It waits 30 seconds and checks again. The "problem" disappeared immediately.

That lasted about a month before it came back. Now, it dies about twice a week. Seven times since rewriting the script, and only once when anyone was at home to notice it (and no one did).

It's not a power failure issue, since it's on the UPS. It is using POE (Power Over Ethernet) now, so that's another change.

The next step is either triple-checking or using a dedicated wireless NIC to do the scan.

BT5 on a Stick

A STICK!!!!

I've been running BT5[r1] as a "disposable OS" almost every day on a laptop for months now, booting up from a CD. Great stuff. Boot up, do your dirty work, shut down, and all the evidence is gone.

A few weeks back I installed the BT5 ISO to a USB stick with UNetbootin and tossed the CD forever. Excellent perfomance. Now it boots up fast and quiet. But there's one tiny issue: it still thinks it's a CD so I have to run my apt-get script every time to get the utilities I can't live without. I thought I could get the same performance by installing the OS itself onto stick, so I bought a cheap 16G thumb drive and tried it out.

Boy was I wrong!

I installed using the defaults and booted the stick up. It was dog shit slow—slower than using a CD at times—but it was still usable. Disappointing, but usable.

After a few days of this I did some research to see what I did wrong. And I found that it's not a good idea to install onto USB using the ext4 filesystem (the default). Either ext2 or UVFAT (formerly known as UMSDOS) is recommended, and UVFAT doesn't work on 2.6 kernels.

I reinstalled to ext2 and booted the stick up. It didn't boot because it switched from sdc during installation to sdb at boot time. Editing grub.cfg took care of that, but after rebooting it was still dog shit slow. Not sure why that wasn't a problem with ext4.

So I decided to simplify things. Instead of messing around with multiple partitions I made one big one and used a swap file instead of a swap partition. This offered a mild improvement but it's still a dog.

There must be a better way.

Oh and by the way... if you've ever installed BT5 to anything, you will find that the last 1% of "almost finished copying files" does indeed take for-fucking-ever. With the ext4 install, it took twenty minutes. With the ext2 install, it took from one hour to "screw it I'll check it in the morning". So be patient. And don't use a CD. Install it from USB.

Proxy Browser Round-Up October 2011

The other day it dawned on me I had not run Internet Explorer for a very long time. IE9 may be better than sliced shit for all I know. I have it, never use it. It's different back at the Salt Mines. Some "intranet applications" simply barf on anything else, or flat out refuse to run.

Last year, on the ill-fated Proxy Obsession blog, I proclaimed SRWare Iron as the best browser ever for using proxies. Now, meh... not so much. Iron has always lagged behind in updates compared to Chrome and though they're getting better they're still dog shit slow.

In fact, with all those fucking persnickety SOCKS proxies out there in the wild, I'm no longer convinced there is a single, one-size-fits-all proxy browser available today. So unless you want to fuck around with a CERN type proxy that uses SOCKS as a backend, you're going to be running at least two browsers. And that leaves us with two options: the Chromes and the Foxes.

The Chromes

Here is my ranking of the available chrome-ish browsers I've been using, from most-preferred to least-preferred:

1. Comodo Dragon - surprised? So was I. I never liked it much because they want to push their crap on you (like the Comodo Secure DNS servers, which are natural born ass-suckers). The last Flash update convinced me. Adobe was all butthurt because Google released a Flash fix for Chrome before Adobe could fix everyone else. Comodo was second, just a couple of hours behind. Impressive.
   
2. SRWare Iron - still an old stand-by. The best thing you can say about them is they aren't Google.
3. Chrome - fast, but... it's Google for crying out loud.

Chromes are great for CERN type proxies because they have the "-proxy-server=" command line switch. Just close the browser, edit the shortcut, and you're in business. But use a SOCKS proxy? You're fux0r3d.

The Foxes

Firefox is taking a beating in the marketplace and is expected to have it's 2nd place position usurped by Chrome by the end of the year, but it is still the most versatile from a proxy perspective, and all the myriad plug-ins make hacking fun! It's so versatile, you still need more than one. Here's my picks, from first to last.

1. Firefox 7.0.1 - or you can pick your own version. The only disappointment I've ever had with FF is the inability of the plug-in authors to keep up with it. And then there's that memory issue...
2. SeaMonkey - an ugly-as-fuck browser if there ever was one, but it doesn't eat memory up quite like FF. SeaMonkey was semi-abandoned a while ago but it's back now and better than ever.
   
3. Pale Moon - a serious contender for the #2 spot. I have only recently discovered it myself, but it's been around for a few years. There's even a 64bit version, but you may have plug-in issues.
   

It amazes me that all the Foxes still have that old, annoying "disappearing caret" problem they inherited from Netscape Navigator and sometimes they're just not paying attention when you click on a link.

You must run Ad Block Plus and NoScript on any Fox-like browser. User Agent Switcher is recommended, but not required.

DO NEVER USE

Added for completeness:

1. Safari - ugh. Just... don't
2. IE - any version
3. Any browser that can't override IE proxy settings (like Safari)
   

Feel free to add your least favorite browser to the DO NEVER USE list.

KB921245.exe

Hey look! This link's not in Chinese!

My advice: don't run it.

If you ran it, you're probably fucked. But you should try running MSRT to get rid of it. Maybe it'll work. Maybe it won't.

Have a nice day!

I ain't lyin'

When the Proxy List came back online in May, I added this little warning...

Times have changed, little ones. You cannot hide. By using a proxy you attract the attention of Powerful Forces™. The consequences will never be the same.

Recent events have shown this to be Sage Advice. They may try to convince you they're hiding your ass, but when the chips are down, they'll cover their own ass first.

It's your ass or their's and you will lose every time.

The Amazing, Disappearing SSID, Part II

The replacement access point arrived yesterday. I set it up identically to the old AP. I rewrote my kidscript to work with the new AP's Web interface, rebooting it when iwlist can't find the SSID anymore.

It's been up for slightly more than 24 hours now.

In that time, the SSID has dropped seven times. We can now conclude that either a) there was nothing wrong with the original AP, or b) that both APs suffer from the same, mysterious denial of service (DoS) vulnerability.

Whatever that may be.

But it got me to thinking about the timing of this thing, which started some time in August. Then it finally dawned on me...

The HP Printer Driver From HELL!

You might recall, when trying to install this Pile Of Crap over the WiFi network, the driver setup program would say "Testing network connectivity..." and then kill the wireless connection every time.

I had the driver installed in two places: my laptop, and the XP desktop I recently retired. I never installed it on my new Windows 7 box, and I only use the laptop occasionally. Now, the driver is no longer on either side of the AP, but of course the printer still exists on the wireless side.

And up until about 6PM this evening it was on 24x7 during this entire fiasco. Not anymore.

I believe—but can't prove—the printer may run it's own code to "test network connectivity" in the same way the driver setup did. Why? I can only speculate, but HP does want to entice you to buy consumables—ink and paper—directly from them. Either the driver polls the printer or the printer notifies the driver or both. I'm inclined to believe "both". Ink alone is a cash cow and HP wouldn't want to miss the chance to make a sale, popping up a dialog box when you're trying to play UT (this has in fact happened to me at least once on the old XP box).

That would explain everything nicely.

And further confirm my personal opinion that "HP" stands for "Horse Poop".

SSID: "XDA-Wifi-Sharing"

So my analysis of my Wacky WiFi access point continues while I wait for the new one to arrive. I watched it drop about three times so far today, with the same results on the airodump-ng screen: my AP disappears and a dozen other SSIDs disappear as well. It comes back up and so do the missing APs. All the novelty is gone. It just happens now. It's almost predictable, but not quite.

But a new AP showed up out of the blue, with the SSID "XDA-Wifi-Sharing". Google took all the mystery out of that. It's some kind of WiFi router for your smart phone that sets up an Ad Hoc connection you can attach other devices to. Nice trick. I've done it myself, but don't see the point for dedicated software, although it does make a lot of sense as a phone app.

OK, fine. But according to airodump's analysis of the power this thing was putting out, it was in my freakin' house!

Then, as quick as it appeared, it disappeared. Then, my AP dropped out of site, too. Of course, my kidscript kicked in and brought it back, but still...

Coincidence? Maybe. This just keeps getting weirder.

GoDaddy DNS Issues Finally Explained?

It's all water under the bridge now, but I just ran across this link in the outages mailing list.

Most of my original complaints about GoDaddy DNS were on the old ProxyObsession blog, so you may have missed it. What it came down to was I couldn't resolve my own domain name from home, but I could resolve it from anywhere else. GoDaddy finally fixed it but then that whole DMCA nastiness hit the fan and I was outtathere for good. Never looked back.

So... check it out...

What seems more likely is that the new owners of GoDaddy are trying to improve on the "Premium DNS" service, which appears to have been a failure. The Premium DNS service started around January, 2011. However, it appears not to be meeting their sales goals (99% of domains using GoDaddy DNS hosting are still using the free service)... We now know that GoDaddy is willing to block DNS queries. Will it continue, or will others follow? What will happen to the Internet if all DNS hosting companies follow the same path? Only time will tell.

That explains a lot.

The Amazing, Disappearing SSID

Lately, after running dependably for several years, my wireless access point has started to disappear from the airwaves.

Firmware upgrade? Got it, no luck. I went from rev 1.0 (2006) to rev 2.12 (2009) with the same issue.

Here's an odd side effect: while troubleshooting this problem, I've been running airodump-ng on a wired PC. Normally I can "see" ~16 access points. When my access point dies, it takes about a dozen with it. When I bounce it, they all come back.

WTF is up with that? It's probably no big mystery. I'm assuming that the radio pulse from my access point coming back online somehow boosts the sensitivity of the NIC running airodump, but it's a strange process to watch.

I have responded to this by writing a kidscript that runs iwlist on another PC. If it finds that the SSID is not being broadcasted, it runs a quickie curl one-liner that presses the "Apply" button on the "Advanced Settings" page of the access point's Web config, which acts like a soft reboot. The process repeats every ten minutes with a cron job.

This is entirely unacceptable! In the past I've had laptops connected wirelessly for days without interruption. On version 1.0 of the firmware!

Since it's seen Better Days, I have to assume it may just be going bad, although in my testing I have made it fail reliably at definite intervals (long story). With that in mind, I've ordered a replacement. If that one works, great.

If not, then there must be a mystery somewhere.

I hate mysteries.

PowerDNS 3.0

PowerDNS 3.0 came out in May of this year and I've been fucking around with it ever since, in between other things like the PoTTY upgrade, those crazy Chinese proxies, and replacing hardware on DinkNet.

I started running pdns in February of 2009 after my jerkwater ISP started "improving my online experience" by hijacking DNS requests. Two years later I got on IPv6 through Hurricane Electric, but pdns 2.x couldn't handle it—or DNSSEC for that matter—so an upgrade was inevitable.

Unfortunately, building pdns and pdns-recursor from scratch is an incredible pain in the ass. Sure, there are packaged binaries available, but I'm dealing with an older platform (Debian 4) that can't meet the prereqs.

One of those prereqs is Boost version 1.35 or greater. Boost is a collection of fast-as-fuck C++ libraries. Or so they say. The PowerDNS people are Boost believers. Building it isn't too bad, but you have to forget everything you know about building from source.

But wait... according to the pdns-recursor docs...

You only need to download it, there is no need to compile.

This is absolutely, 100% TRUE. Well... 99% true. After you download it, you need to extract it (details!). After that all you need is a CXXFLAGS variable pointing to the source.

Quick and easy. For the recursor. Not so for the pdns authoritative server. You'll need to compile and install the libraries. Sucks to be you.

Once you realize and accept that Boost isn't "normal", compiling and installing it is easy. You run "./bootstrap.sh" and then "./b2 install" (or "./bjam install", depending on the version).

Aside from being Boost evangelists, the PowerDNS people also adore Lua. There's a lot of that going around lately. You'll need version 5.1 and the development libraries. Lucky for me, 5.1 was current way back when Debian 4 came out, so I only had to install the packages.

After that, building pdns is relatively simple. For me, pdns has a lot more functionality than I actually want. And what I want is a caching-only slave server. I don't have any domains to be authoritative for. Everything on the inside is in the .local multicastdns domain, which is served up by Bonjour and avahi.

PowerDNS supports a number of database backends for holding authoritative data. Or, you can just use bind-like data files (pdns was originally designed as a drop-in replacement for bind).

So when you run ./configure, use --with-modules="" not --with-modules="bind", because it won't know what the fuck you're talking about.

After finally getting pdns to compile—I already had the v3 recursor installed—I decided to do some testing. This turned out to be difficult with version 2 running at the same time. At this point I realized I probably needed two DNS servers anyway, so I took my "lessons learned" and built another pdns server and recursor on Experimental V. Plus Boost. Plus Lua.

Testing was silly. One of the variables in the config file—which can only be named "pdns.conf" no matter how badly you want to change it—is called "config-dir" and it specifies the path to pdns.conf.

Think about that for two seconds and you'll realize the profound silliness of putting the path to the config file inside the config file itself. What is the point? How does it use a path in a file it can't find?

Here's a clue... check the manual page! DAMN! It's dated December 2002!

It's shit like this...

Once you get around obvious crap like that (use the --config-dir command line option) testing should go fine, and it did. After pdns was running on EXP V, I took my second round of lessons learned back to BOT House, where pdns 2.9 was running, and finally upgraded it to 3.0.

The final touch on the upgrade was to take Hurricane Electric's IPv6 DNS sever out of radvd.conf and put my own in.

When both servers were up and running, I had a sublime issue with DNSSEC. One server could retrieve dnssec records, but the other couldn't. After staring at both configs for an hour it came down to a setting in the recursor config called "query-local-address", which is the IPv4 address the recursor uses for sending recursive queries out to the Internet. It was set to "0.0.0.0" by default. After changing that to the server's "real" (RFC1918) IPv4 address, there were no more issues with DNSSEC.

One minor issue remains: I can't get pdns to listen on the link local fe80::/10 address of either server. I works fine on the yes-I-know-it's-deprecated site local fec0::/10 addresses, as it does on the global IPv6 addresses (yes, since they only service the inside network they're firewalled).

In the end, it was way too much work.

awmproxy.com

There's a lot of buzz lately about the guy who runs/ran awmproxy.com as being the "kingpin" behind the TDSS botnet, which was the bug responsible for all those port 27977 SOCKS proxies.

Not surprisingly, I used to scrape that site all the time, from the Fall of 2008 until early Winter 2010. According to the Krebs article, awmproxy started offering up proxies on March 16, 2008 which is—coincidentally—the day after I started the proxy project.

That site, as it existed back then at least, seemed like a typical proxy-for-pay scam, selling you a list of proxies you could get for nothing on your own. In fact, they had a slightly insecure way of passing out proxies to their paying customers. I stumbled across their "secret URL" with a random Google search and scraped thousands of good proxies every day throughout that whole time period.

Maybe they changed hands since then, but if you look at their offerings, they have never advertised port 27977 proxies. Compare this Google search to this one. Do the same search on the .net site and you'll find there are none there, either. But you will find the standard ports listed.

Sure, they're conspicuous by their absence, but every proxy lister and his brother had port 27977 proxies in their lists over the past year, so the advertising value alone would be worth listing them. Here are my numbers:

As you can see, they're gone now.

So why finger the only site that wasn't advertising these proxies?

Some consider Firefox plug-in to be a smoking gun, but it seems like a logical offering for a proxy provider. In fact, it's still available. I don't see how this plug-in would be valuable to a "bot" and would love to see someone evaluate the code and prove that it's inherently malicious.

Of course, there's no way in Hell I'd install it.

I don't want to appear to be an apologist or a defender of cybercriminals, but I'll be on the sidelines watching this drama pan out.

"subrepticious"

About 3,870 results.

Srsly?

UPDATE: 09/05/2011

I now have the #1 Google hit for this silly non-word. However, when searching for it, I spelled it right and discovered "subreptitious" is a real adjective derived from from the noun "subreption", which means:

1. A calculated misrepresentation through concealment of the facts.
2. An inference drawn from such a misrepresentation.

I did not know that.

Neither did the guy who wrote "subrepticiously" when he meant "surreptitiously".

You learn something new every day. If not, you're doing it wrong.

4.1 million proxies!

Almost a month after the 4,000,000 mark, that's about right. 100K proxies per month is a little high, just a little above average.

Here's the thing: that 0.1 million is 100% TCP port 8909 proxies.

Between midnight August 1st and this very moment (6AM on the 28th) I've snarfed up 105,272 of these suckers. That's over 2.5% of the entire database.

It looks like I was right about the demise of port 9415. Those boxes are gone. Here are the daily numbers from April 1st to now.

I am still looking for the port 8909 culprit. I downloaded QQPlayer_Setup_32_845.exe from "somewhere in China" and installed it on a VM to see if it opened up port 8909, but it didn't. It was a good suspect because it came out in June. Here it is...

Since it's in Chinese, running it is something of an issue for me. Even though this thing didn't open up port 8909, it does have some kind of built-in proxy capabilities. Take this DLL for example:

It's even signed by Verisign! Anyway, taking a quick peek reveals some interesting details (click for a larger view):

The presence of CStunClient and CStunSvr struck a note. "STUN" means "Session Traversal Utilities for NAT" and you can read all about it here. The problem is, STUN is typically a UDP thing whereas proxies (besides SIP proxies) use TCP. Still... it looks like a smoking gun.

Otherwise, the Youku/Tudou/QQ hegemony has been making a lot of news lately. Take this article for example. You may recall Tudou was responsible for port 9415.

This month I have learned that these proxies have more staying power than their port 9415 predecessors, which tended to disappear forever after they were gone. They do disappear, but they can come back after a few days. This means all those "dead" proxies that never made it into the gold table (over 88,000 timed out or the port was closed when they were first scraped) may still be usable.

Back in the USA, the SOCKS proxies march on, with the notable exception of port 27977. What is going on there?

Apparently this was the TDSS rootkit. This is one of the few sources I have found that specifically link TDSS with port 27977. TDSS was a tool leveraged by the Rustock botnet, which was taken down in March.

So you can put a fork in that one.

PoTTY 0.61 released

Now available at the PoTTY Download Page!

• For completeness, PoTTY now consists of all of the PuTTY utilities
• The DLL injection issue has been fixed
• Restoring the Obfuscated Keyword from the Registry now works
• Private key authentication with *.ppk files has been fixed

PoTTY: BUG hunts & dirty tricks

PoTTY 0.61 field testing marches on this week. Sunday night I really thought I had it hammered, but Monday morning brought a surprise.

I was testing out all my stored SSH profiles and ran across one that just hung at a black screen. No logon prompt at all. It just timed out and died.

I exported the Registry entry for that profile and imported it into another machine. PoTTY 0.60 handles it fine. PuTTY 0.61 handled it fine.

Monday night I decided to compile a new "Debug" build to chase this issue down, and although it compiled fine, it crashed every time I tried to run it. This was a very bizarre linker problem. Basically I had to cast some functions from

(BOOL (*)()...)

to

(BOOL (WINAPI *)()...)

...in arc4random.h, code I pulled from somewhere back in 2010 when I first hacked this thing together. When the debug version finally ran without crashing—about three hours later—it was no help.

The PoTTY log was no help either, so I did a Wireshark snoop on the line, which I should have done in the first place. And I saw the handshake in clear text, so something definitely wasn't right, since this was supposed to be an obfuscated connection. And I noticed the version was "SSH2.0-PuTTYObfuscated".

I didn't like that one bit.

The bug turned out to be the "2 only" radio button under "Protocol options" in the "Connection\SSH" section of the config. Set to "2", it's fine. It took at least another three hours to find it.

Something has changed in ssh.c and I can't seem to find exactly where it is. Some functions are called in a different order and at least one from 0.60 is simply gone in 0.61. Otherwise as long as you don't select "2 only" everyone's happy.

I have a work-around for a saved profile with "2 only" selected, but nothing prevents the user from switching it back. That won't work in the long run so it remains unresolved right now.

While I was poking around in that part of the code, it occurred to me that I knew nothing about using SSH 1.0 with obfuscation. It didn't work. Was it supposed to work?

I did a reality check with brl's code on both the client and the server ends and found that it doesn't work with SSH 1.0, but it also doesn't throw any "not supported" errors. I changed that. Now you get a "not supported" messagebox before obfuscation bombs out against a 1.0 connection.

The "SSH2.0-PuTTYObfuscated" handshake bothered me a lot, since that makes for an easy IDS signature when you have to connect to an unobfuscated server. Of course, it's no big deal when the connection is obfuscated, but you don't want to tip your hand with an off-the-wall SSH version string like that.

So I changed it to "SSH2.0-Debian4.3[something]", which is the dirty trick. Not having "PuTTY" somewhere in the string would put the finger on someone running Linux instead of Windows (sure, you can run PuTTY on Linux, but few people do).

That appealed to my Dark Side, but it would make SSH purists shit their pants, especially if that particular SSH version ever has problems in the future. I looked at extending this to make a user supplied version string, but there isn't enough real estate on any of the dialog boxes to add it. It just won't fit.

I have yet to hack the SSH1.0 version string, but the "2 only" problem has to be fixed by tomorrow night in order to release 0.61 for the weekend.

I told you not to hold your breath.

UPDATE 08/25/2011

The "2 only" bug really sucked ass in a big way. I have made the hack-around permanent. Your "Preferred SSH protocol version" will always be "2" and only "2" (not "2 only") whenever you have obfuscation enabled.

The bug was curiouser than it first appeared. It did not disable obfuscation. What actually happened was the plain text version string was getting copied into the buffer that held the already obfuscated data. Really weird.

This issue relates to the "-2" switch for the command-line utilities, so I'll need to do some testing on that as well. Other than that I feel like we're back on track for a weekend release.

PoTTY version 0.61

heh... "clean potty"

That always cracks me up.

The first time at least. After a few hours, not so much.

So anyway Simon Tatham released version 0.61 of PuTTY a few months ago and I knew that sooner or later I'd have to dig up the PoTTY code, do some cutting and pasting, and pull a new version out of my ass. I really wasn't looking forward to it, since as far as I know nobody uses it. In fact when I moved the PoTTY page from GoDaddy to CheapBastard it was so broken no one could even download the damned thing.

I happened to mention PoTTY on reddit, exposing my ineptitude globally, and after I fixed the page some guy downloaded it... and liked it. And then he immediately found a bug in it. It didn't restore the ObfuscatedKeyword—which I had in error called the "ObfuscatedPassword"—when it loaded a previously saved profile.

I downloaded the PoTTY 0.60 code, checked it out, and quickly found that problem. I mulled over releasing a 0.60a or a 0.60.01 version for a few minutes, but I thought if I was going to go through that kind of hassle (new MD5 sums, rewriting the page, etc) I might as well download the 0.61 code from Simon just to see what I was up against.

I liked the changelog, especially these bullets:

• Bug fix: corruption of port forwarding is fixed (we think).
• Bug fix: various crashes and hangs when exiting on failure,
• Bug fix: Windows clipboard is now read asynchronously, in case of deadlock

I am very familiar with the first and last bullets, so this sealed the deal. That stupid clipboard trick has nailed my ass to the wall numerous times in the past.

Hours later, after cutting and pasting the old code to the new code (that's how I roll), I managed to get a clean compile—linking was the hardest part—and got it to run.

But there is much more to be done before it's released. For one thing, I need to update the OpenSSL libraries.

Most importantly, I need to fix that damned DLL injection problem. The good news is Simon fixed it in PuTTY 0.61, but it's still broken in PoTTY 0.61 (I just now tested both with Luigi's proxocket 0.1.6a DLLs and somehow Simon nailed it). I looked into that last Fall but never found a solution. If you have a clue I could use one.

Then there's little shit, like fixing the ProxyObsession link in the "About" dialog box.

And then it all has to be tested.

So don't hold your breath.

UPDATE 08/20/2011 9:00PM

Bet you didn't know private key authentication was broken, too. PoTTY used to bomb out ungracefully whenever you used a *.ppk file for authentication. Not anymore... but I have no clue how I fixed it. Well, I do have a small clue. It stopped crashing after I included pageant in the build.

This also mysteriously cured the DLL injection issue.

On to OpenSSL...

UPDATE 08/21/2011 7:30AM

The fix to the DLL injection issue was here (click for full size)...


... in winmisc.c, which is not in PuTTY's project files. It is in pageant's project. Another mystery solved.

This function doesn't exist at all in PuTTY 0.60, and dll injection isn't mentioned as being fixed in the 0.61 changelog.

I also upgraded my OpenSSL static libraries to OpenSSL 1.0.0d, which means 1.0.0e should be out any day now. I doubt if that was absolutely necessary, since PoTTY uses a very small chunk of functions in libssl, but I like to stay current.

Skipped a beat... or two

Make that three.

I woke up this morning at about 6:15AM—which is late for me, but it's a weekend—and checked the proxy list to find there had been no updates since 4AM.

I did a hard Ctrl-F5 and came up with a "Host not found".

This is not the first time this has happened, and I've been waiting for it to happen again.

The first thing I did was do an nslookup on www.mrhinkydink.com.

SERVFAIL

So I tried www.Mrhinkydink.com (with a capitol "M")...

SUCCESS

Not this shit again.

I really didn't want to deal with it so I grudgingly added the addresses back into good old faithful /etc/hosts. WTF, it worked last time.

The 7AM and 8AM updates ran fine. Then, working on something else entirely, I borked the box—sucked up all the RAM & CPU cycles—during the 9AM run. By 10AM the list was back on schedule. Now, it's 11AM and it's back to normal, which is entirely different from "on schedule".

While messing around with all that crap, I popped in to the hosting provider to poke around. While there, I grabbed my stats, below. The bar graph is slightly truncated on the right.


These stats only go back to May, when I moved the list off GoDaddy. The Cameroonians lost their top spot to the USA, unless you consider "Hits" more important than "Pages". Then they're Numero Uno again. But Germany beats them all in bandwidth.

This is completely different from the Extreme-DM stats page, which only counts "unique visitors".

Russia didn't even make it to the top ten. No love for хинки? Probably not, considering I scraped all their proxies.

Port 8118 Proxies in the UAE

Besides all that proxy action going down in China, there have also been numerous flash mobs of port 8118 proxies lately in Muslim countries, especially the United Arab Emirates. But don't go rushing off to the List to find any. At the moment there's only one live port 8118 proxy in there.

Here is the breakdown by country. You can see the UAE (listed as AE below) is responsible for half of the total count.


They show up in groups and then they're gone, but if you can catch one on the first or second page, chances are it's alive.

8118 is well-known as the default port for Privoxy. In my experience, it's barely in the top twenty-five ports. As a matter of fact, it was #25 last time I checked. And when I checked, there were less than 8,000 total in the database.

Of those, about 2800 were in the UAE. 96% were listed this year. Of that number, 99.7% (2675) were listed since June first, which definitely qualifies as a flash mob.

Here is the breakdown by city...


It is definitely following the population of the UAE, but then these data always do.

My gut feeling is this is a symptom of the "Arab Spring", although the UAE has seen little civil unrest on that front. Perhaps they're opening their ports for their neighbors.

Or maybe they're just downloading porn protecting their privacy with Bit Torrent, since Privoxy seems to be a common Bit Torrent helper program.

Whatever the reason, they are there (when they're there), they're fast, and they're High Anon. If you find one, you might get an hour out of it.

The Last Days of Port 9415?

I just ran some quick numbers on the proxy database to see what's going on with ports 8909 and 9415. I did a couple of blog entries in May and June about port 9415, but I dropped the ball in July and then got distracted by port 8909 the first week of August.

What I found was this...


Port 9415 (blue) is indeed dropping like a rock and port 8909 (red) is becoming the dominant port.

Considering the source—public proxy lists—I have to wonder whether the proxy scanners have given up on 9415 or whether 9415 has simply run its course. With that in mind I looked at Dshield's data.


meh.

Hard to say. The "Target" line (green) reveals attempted port scans. Dshield gets their data from network dweebs who think their firewall logs are meaningful in some way, so their results are screwed skewed.

Here is Dshield's report on 8909...


Once again, we're looking at the green line. And once again... meh

Too bad there isn't a Chinese Dshield.

Have the scanners given up on port 9415? I would have to say no, but considering how awful those proxies were, I wouldn't blame them if they dropped 9415 in favor of the vastly superior port 8909 proxies. 9415 is just one number in a list of 65,535 numbers, and—trust me—they're scanning all of them.

I think there's some kind of real effect going on here. It would be nice if it was a result of my April disclosure about PPLiveAV, but it could be something else entirely.

Only about 750 unique addresses have been seen listening on both ports. Whether this is simply "DHCP churn" or users running both clients concurrently is unknown, but if it were a mass migration from the PPLive player to the Youku player, you'd think there would be more dual port database hits. However, from my research—which is limited at this time—I don't believe that the client software is interchangeable.

Time will tell where this trend is headed, but it's been less than a month since port 8909 showed up with the daily numbers it has now. If PPLiveAV was fixed, the "lessons learned" were lost on the developers of the Youku client software.

Hinky Dink SEO almost back to normal

Lots of shit hit the fan back in April. It seemed like everyone wanted to put the smackdown on the Dinkster after that security announcement about PPLiveAV—those damned port 9415 proxies in China—hit the wire.

As if the GoDaddy DMCA takedown wasn't bad enough—taking out both ProxyObsession and MrHinkyDink.com—the next insult hit my "brand" like a rock. Some stupid cop show announced an episode titled "Bathhouse and Hinky Dink" and in the process snatched up all my Google search hits. (See also here).

Motherfuckers couldn't even spell "BOT House" right. heh. (If you don't play UT on my server you won't get it.)

FOX finally cancelled Chicago Code. I rejoiced, but it took a long time for the "Bathhouse and Hinky Dink" hits to go away.

As we say in UT, "DIE BITCH!"

This was the latest Hinky Dink hit...


... which is the new link on the "Hinky Links" side panel on the right. It is my public PGP key, with which you can use to send me encrypted email (dink-at-mrhinkydink-dot-you-know-what). I should have done that long ago, but I didn't.

You may have noticed other changes to the right-hand sidebar. Just trying to clean things up a bit. The link to the Proxy List was removed when it was taken down and I never put link back in. It has been restored. The Twitter bar was moved up and the search box was moved down. The BOT House tweets are gone since that hasn't worked for months (it was fun while it lasted).

Of things not working, the World Domination link is still down. I haven't fixed that yet. I wonder if it will ever get fixed because Google has lately made some "improvements" to the Maps API that are driving me nuts elsewhere. Never, ever depend on someone else's code because you'll always get screwed in the end.

AT&T Hiring Hot Streetwalkers

Oh, my.

That's what I'm talkin' 'bout.

Had she been selling anything else, I probably would have bought it. This girl is definitely in the wrong industry. No, I don't mean that industry. Maybe she couldn't make it as a suitcase Suzie for Big Pharma.

But pushing AT&T U-verse® door-to-door? That's sinking pretty low.

Then again, times are tough. You take what you can get in this economy.

[Not shown: the twink partner. Something for everyone, I guess.]

Whatever you want to say about AT&T, that's fine and dandy. Maybe U-verse® is the best thing since flushed shit, but I have a history. And a tightly held grudge.

And I'm not letting go.

And lucky for you I'm not going to bore you with it.

The things I do for you kidz

You may recall in March of this year, before the Great GoDaddy DMCA Takedown Incident, the machine running the Proxy Project died a terrible death. The sucker popped a heat sink and burnt itself out. I moved the project to a physical box—it had been a VM—and restored everything from backup. More precisely, I built a new box and restored the project—database and kidscripts—from backup.

I thought I had it nailed, but today I noticed I had missed one minor utility, gifsicle.

From the manpage...

gifsicle is a powerful command-line program for creating, editing, manipulating, and getting information about GIF images and animations.

I used it mostly on this site, one of those "dicey .ru domains" I've warned you about in the past...

It's not all that obvious at first glance, but the address/ports above are GIFs.  A number of proxy lists do this to prevent scraping, but it's ineffective and mostly it pisses off users who would rather simply cut&paste the information.

Since gifsicle was nowhere to be found on the hard drive, this site hadn't been scraped since March.  All gifsicle did was scale up the image for further processing by gocr, which converted the image back into text.

Once fixed, I ran my kidscript to see what I was missing.

I wasn't missing Jack Shit.  Same old crap.  Nothing that wasn't already in the database.  And less than 100 proxies total.

On top of the GIF trick this guy requires a cookie, which is a pain but not hard to pull off, but for this crap?  Dude, you're gonna get scraped and that guy will put your proxies in a list that will get scraped, so what is the point?  You're not guarding Fort Knox here.

Why do I bother?

Because I love doing this shit.

It's an obsession.

Hinky Hack - ipconv.c

This little program takes a dotted-quad IP and returns the 32 bit unsigned integer that is the "real" address.  Given a 32 bit "real" address, it will return the dotted-quad representation.

Given an FQDN it will return 0.

I already know there are a zillion different ways to do this, so spare me your Better Way.

#include <stdlib.h>
#include <stdio.h>
#include <arpa/inet.h>
#include <string.h>

void main( int argc, char **argv )
{
   struct in_addr x;


   if ( argc==1 || argc>2 ) return ;
   if ( (strchr(argv[1], '.'))!=NULL) {
      inet_aton( argv[1], &x );
      printf( "%u\n", ntohl(x.s_addr) );
   } else {
     x.s_addr=htonl((uint32_t)(atoll(argv[1])));
     printf("%s\n", inet_ntoa(x) );
     }
}

Compiles fine under Cygwin or vanilla Linux.

Oh and screw you if you don't like my coding style.

And I mean that in the most positive way possible.

TCP Port 8909 Proxies

If you've been paying attention to the Proxy List you will have noticed the ramp up of Chinese proxies on port 8909.

In May, I pulled a paltry 32.

Things picked up in June. I scraped up 185.

In July things took off for port 8909, with a grand total of 23807.

Less than a week into the month of August, I have over 16,000 new ones!

At this point I have only scraped the surface of this, but it appears to be a mobile product called Youku player. You can download the Android version here if you dare.

Once again, like port 9415, these things come and go.

But they're not going away.

UPDATE 9:30AM

Unlike their cousins on port 9415 these are actually pretty damned good High Anon proxies. The speed is great. None were blocked by 4chan, which is highly unusual for any proxy. It seems like those in Shanghai are the most reliable, but that's just my first impression.  YMMV.

Government spooks and contractors take note: you can use these to stage your false flag attacks!

UPDATE 08/07/2011 7:30AM

I pulled 3,268 of these proxies since midnight. Out of those, 116 were alive. That's a 3.5% live hit rate, which is about 3.5 times the usual live hit rate for public proxy lists (1 out of 100 is typical).

At this rate—assuming they don't fix it—August should end with over 60,000 of these proxies.

And, so far, they have staying power. I routinely overcheck all Chinese proxies, since they historically have been so ephemeral. This is why the List expands and contracts during the day.

UPDATE 08/09/2011 5:50AM

Wow. August's count is already past July's, with 27,190 of these proxies scraped since the first. The List is 20 pages long and 79% of the proxies are 8909'ers.

Just... wow.

Insecure Storage Of Liquid Confections

Recently it was disclosed that a giant, well-known, multinational confection supplier was hacked. Their proprietary recipes were altered—for reasons unknown—by malicious actors.

Seasoned security professionals can only shake their heads and sigh. To them the security flaws of this company are legendary, although in the past the company has managed to escape publicity and accountability for their haphazard security practices.

The most notorious incident happened over fifty years ago to a Mr. Y. Y. Mann (not his real name). In those days it was common practice in the industry to store liquid confectionery ingredients in large, unguarded, 30 foot deep vats in publicly accessible areas, protected only by a cheap metal railing.

Mr. Mann—who was walking down the street minding his own business—happened upon one of these vats in his neighborhood. A skilled and talented acrobat, he balanced himself on the railing as he had done many times before.

Little did he know that someone had greased the railing earlier that day. Due to a documented history of filial rivalry, police immediately suspected a conspiracy between his brother and his mother, but nothing was ever proven beyond a shadow of a doubt and to this day the miscreant has yet to be identified.

Inevitably, Mr. Mann slipped and fell into the vat, but his quick thinking enabled him to summon help and he was extricated from his predicament.

However, the incident left him horribly scarred for life (WARNING: graphic image). The company attempted to settle out of court but Mann, shaken by the incident, refused. Thereafter the company staged an effective public relations campaign to keep the story out of the public eye.

Angered by this, Mann became a tireless protester during the tumultuous 1960s, fighting for new public safety laws to prevent this kind of atrocity from ever happening again and documenting his ordeal in popular folk music of the day.

His struggle ended with the passage of the Secure Confectionery Storage Act of 1967, which effectively outlawed the practice of storing dangerous ingredients in public areas. Despite these reforms accidents of this nature continue to this day, although less frequently.

3.99 Million Proxies

We'll probably hit the 4 million mark tomorrow morning during the 4AM run, but there's a slight chance of it happening before midnight.

3,425 to go.  Right on schedule.  We always seem to roll over another mill in August.

The List is here, in case you forgot.  The count is buried in the HTML, in a comment under the closing "head" tag.

UPDATE

08/04/2011 0615 — Hung at 3,999,984 proxies. 6AM run A.W.O.L.
08/04/2011 0715 — 4,000,571 proxies! w00t!

Windows Horrors: HP Photoshit Software

I don't see how your average Windows user survives day-to-day life.  The malware is bad enough, with millions of infected PCs across the globe, but it gets worse when so-called "trusted" hardware manufacturers pass out buggy software with their devices.

Of course, I'm talking about HP.  I swore off HP printer hardware for many years because of their crappy software and their snooty corporate policies.

As an example of their corporate snobbery, back in the pre-Internet, Windows 3.1 days I had a DeskJet 500 printer, a very popular model at the time, widely described in the PC press as a "workhorse".  Their driver was damned near perfect.  I especially liked it for printing envelopes, which it spit out flawlessly.  Then along came 1995.  Shortly before the arrival of Windows 95, HP announced they wouldn't be making printer drivers for 95 until they were convinced that people would actually buy it.  In reality this was an upgrade scheme for a "New Generation of HP Printers" (they were doing the same thing with iPads last year).  Because of this, when 95 came out in August, every HP driver distributed with 95 was written by Microsoft.

I never printed another envelope again on my DeskJet.  I think the issue was deep inside the Windows GDI (Graphic Device Interface).  No matter what you did, Windows decided a letter was "landscape" format, so it dutifully printed the address sideways.  There were work-arounds, but it was an incredible pain.

Once 95 took off, to the surprise of HP, and people started using the Internet for downloading drivers, HP forced its "HP Webprint" software on anyone looking for the "latest driver" for any printer, regardless of the model.  It never worked well.  And it still doesn't.

Forward to 1996 and the introduction of the fundamentally flawed OS we knew as "NT4".  Once again, all the HP drivers were written by Microsoft (shudder).  By the time Service Pack 3 came out this was a common scenario:

• Customer buys HP printer, finds there's no NT4 driver
• Customer installs HP driver from original NT4 CD
• NT4 print server explodes the first time it prints to the new printer

Yeah, there was a little trick to that: you had to re-install SP3 after installing the driver or suffer the consequences.  In fact any time you pulled anything off the original NT4 CD you had to re-install the service pack (3,4,5, or 6—whatever version you were on).  Even though you could point to Microsoft technical articles explicitly stating this, most people refused to believe it.  I think they were just lazy.

Witnessing all this Happy Horseshit as a "professional services"... umm... professional, tainted my view of HP for at least five years and I avoided HP like... herpes ("the Plague" is so Old School).

But that's all Ancient History.  The years rolled by and the pain receded.  Perhaps my memory grew dim.  Multi-function printers became ubiquitous and I decided it was time to throw out the old printer and the old scanner.  I bought an HP Photosmart C4580.  Although the software interface was butt-ugly it worked fine for my needs... for about two years.

Honestly, I think there are hidden "features" in HP software that determine when you need to buy a new printer.  There's code in there, waiting... watching... ready to make your life miserable when HP's stock starts to drop...

Among the new features in the HP printer driver suite are automatic updates.  I always chose to update whenever I got a notification.  Then, things started to get flaky.  The "update" would ask for the original CD and no matter how many times you clicked "Cancel" it would refuse to stop asking for it until you killed the process in Task Manager.  This got so bad I disabled it on most of my Windows boxes.  I printed through Linux (CUPS, a surprisingly competent HP sponsored project for Linux) anyway, so life went on.

Until yesterday, when I wanted to scan two lousy items for my RFID post.  It just wouldn't work, so I determined it was finally time to upgrade the software.  I decided to give my aging XP box a break and install it on my Windows 7 laptop.  After downloading and running the 150MB package at 12:30PM, the horrors began.  I wouldn't be scanning until 8PM that evening.  I was multitasking all day, so it wasn't quite as bad as it sounds.

The first thing the new software (lucky version 13) tried—and failed—to do was remove the old software (version 12).  Somewhere around "step 4 of 38" in this uninstall process, it hung.  I killed it with Task Manager and it restarted, completing—or appearing to complete—the remaining 34 steps.  In hindsight this was a mistake.  I should have manually uninstalled the old stuff and started fresh, but what the heck.  The software thought it could pull it off.

So this things chugs along and finally comes to the "printer detection" part.  It finds the C4580 on the wireless network and then decides—after the printer has been found—to "test" the wireless adapter.

And by "test" it meant "break".

I didn't notice this at first and the software offered to put an icon on the desktop so it could "try later".  OK, I'll go for that.  Click "OK" and reboot.

Once it's back up, I click the icon and it goes through the same process.  Still can't find the printer.  Click "OK" and the damned thing reboots again.  After a few more of these I finally notice the WiFi indicator has the yellow piss stain of FAIL on it after the "testing your connection" phase, so I reconnect to the access point before the printer identification part.  It works.  It churns.

It FAILS.  And reboots again.

So I disable the wireless NIC and jack into the wired network.  The laptop can still get to the printer through the access point, verified by pinging it.  I run the detect printer program again and it tells me my wireless connection doesn't work.  Fucking DUH.  This time there's an edit box where you can put in an IP address, so I try that.  No go.  Reboot again.

There's an option to connect directly to the printer via USB, so I try that.  It finds the printer and dies again.  Click "Finnish" to reboot.

At this point I decide to rip everything out and re-install from scratch.  After removing everything HP, I reboot, log in, and Windows tells me it's no longer genuine.  WHAT THE MOTHERFUCKING FUCK.  Yes, those were my exact words.  So I did the Windows Genuine Advantage song and dance thing and Microsoft forgave me, saying there, there everything's OK now.

Well, that was a relief, but I was in no mood for drama at this point.

And re-installing did the trick, seven and a half hours after starting.  I scanned my shit and posted the article.

HP... never again.

Again.

UPDATE 08/16/2011

The last time I rebooted my laptop, the HP Photoshit software popped up and asked me if I wanted to participate in their customer survey program.

I declined.

Then it asked again.

What part of "I Decline" is so hard to understand, HP?

Mystery RFID

Lately I've been reading a lot of E.L. Doctorow. I'm not sure why. The latest is Loon Lake, shown at left. I bought it at a Half Price Books store. In fact I buy all my books at Half Price because I'm a cheap bastard (I might buy a Kindle when they get the cost down to $29.95).

I started with a collection of Doctorow's short stories—I forget the title—and really enjoyed it, but it's all been downhill since then.

But this isn't a book review.

About halfway through Loon Lake—page 159 to be exact—an odd thing happened.

An RFID barcode sticker fell out.

And there it is on the right, sticky side up and slightly larger than life. The exposure's been tweaked a bit so you can see it through the peel-off backing. The number on the barcode on the other side is "79797 97979".

I thought this was odd since RFIDs are supposed to replace barcodes, but I can see the utility of a dual-purpose item like this. But Loon Lake already had a barcode printed on the back cover and the number "79797 97979" wasn't there. And I've never known Half Price Books to use RFIDs, although there's no reason they shouldn't.

RFIDs are everywhere, and chances are you'd never know it anyway.

One thing lead to another and I watched the 24C3 presentation on the MiFare fiasco, found the OpenPCD project, and ordered the parts to start hacking around with this stuff.

It's good to have a new project.

Loon Lake was getting boring anyway.

UPDATE 08/10/2011:

I should have Googled first. Mystery solved, seven years ago. An old Barnes & Noble trick.  No wonder they went out of business.

Oddly enough, there was another hit with a UT connection!

I finished Loon Lake. No book report. Advice: pass on this one.

Observations On Evil Access Points

This is not a HOWTO. There are gazillions of those on the Interwebs, which is how I got started into this. BT5's intro in April really boosted the interest in wireless hacking, especially considering Vivek Ramachandran's Megaprimer on SecurityTube, which leveraged the fuck out of BT5.

This brings me to my first observation: it only works on BT5. Now, before you protest and tell me about your wonderful experience with Aircrack-ng on Ubuntu or Fedora, let me explain. I've done a lot of custom kernels in my time chasing new features in netfilter only to find that I broke something else that ran just fine with a stock distro kernel. Mea culpa.

The first thing I bumped up against was a kernel bug that sets the WiFi channel to 255 when you try to create an access point with airbase-ng. This doesn't happen with BT5's "2.6.38 #1 SMP Thu Mar 17 20:52:18 EDT 2011 i686 GNU/Linux" kernel, so stick with BT5.  I hope it doesn't break in BT5 R1.

Another curiosity: BT5's implementation of wicd can't see access points made with airbase-ng. This is what I get (entry at top is the evil access point):

I haven't found a work-around for that, but Windows 7 sees the AP just fine, as does NetworkManager in Linux Mint LXDE.

Which brings up another point: do not try to make an access point on any box that uses NetworkManager! Personally, I despise NetworkManager, and generally remove it whenever possible. I learned this from the Mint box, so stick with BT5.

The Mint box did surprise me as a client, though. Evidently ndiswrapper has come a long way from whenever the last time I used it was (2006? 2007?). There's even a gui, ndisgtk, for painless installation of drivers.

If you can find them. Case in point: the NetGear WG111v1 wireless USB NIC I've had since 2005. I knew I had them somewhere but I thought it would be quicker to hit NetGear's site to download them. Nope. No way am I going to register with a company I have no intention of ever doing business with again. But luckily I found the original drivers buried deep on a dusty old hard drive. I installed the drivers and the damned thing actually worked. I never got that damned thing to work on Linux before! It's not perfect and a lot of features just aren't there, but for basic functionality in a pinch you can't beat it.

Which brings up another observation: there's no ndiswrapper in BT5. You can download all the tools, but the kernel module isn't there (I had the exact same problem with JFS in BT4). You really wouldn't want it for making an AP, but if you're short a NIC, ndiswrapper would be nice to have around.  If they do add support for ndiswrapper and you need it, you're stuck in 32-bit land, which is not always a bad place to be.

Eventually I had three useless access points hanging off my BT5 laptop. Useless because I didn't have a DHCP server. ISC's dhcp3d is fine, but I settled on udhcpd because it's simpler and it's in BT5's software repository.

Here comes another observation: udhcpd is broken. Well, that's not entirely true. The manual page is broken. The date on the man page is "2001-09-26", so that should be a dead giveaway that it just ain't right. It states that "option namesvr" is the setting for DNS in the config file but oddly... it doesn't work! A quick Google search and you'll find the real setting is "option dns". As long as you take the man page with a grain of salt you'll be OK.

Another "gotme" was the "subnet" line in the config file. The man page says:

subnet ADDRESS

But they meant...

subnet MASK

Jeez. Woe betide the literal-minded. "255.255.255.0" is not an "address", people!

Oh, and speaking of man page fuck-ups, the airbase-ng option for the BSSID is not --bssid or -b, it's -a! Fucking -a! -b and --bssid do nothing. That was a real WTF moment. I quote then man page:

If the BSSID is not explicitly specified by using "-a  ", then the current MAC of the specified interface is used.

-b and --bssid are "Filter Options", which are never clearly explained in the man page.  Some HOWTOs out there make the same mistake, so beware.

So much for RTFM.

You need to assign an address to the atx adapter airbase-ng pulls out of its ass and make that the gateway ("option router"), enable IP forwarding in the kernel and set up iptables to forward everything from your DHCP scope out to the Internet.

Once you have all that in place, you're ready to rock and/or roll. The first thing you'll notice is it's a damn slow access point. But it gets the job done.

Put everything into scripts so it'll all be there when you need it. I would hate to have to do this cold on a spur of the moment assignment. Your victim/suspect would drink his coffee and be out the door before you got your first packet.