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.