Monday, August 31, 2009

Conficker Detector

I received an interesting piece of feedback over the weekend. A user wanted to let us know that even though he had AVG installed as an antivirus, and runs Spybot (Search & Destroy, presumably), PeerBlock was the only tool that detected that his machine was infected with the Conficker worm!

I'm not sure which list(s) he was using, and we probably only caught it because PeerBlock is a new enough project that the worm creators didn't put in anything to check if we were running (and torch us if so), but that's just neat, and I thought it worth sharing.

Anyone else find any unexpected uses of running an IP-blocker like PeerBlock or PG2?

        ---  Mark  ---

Friday, August 28, 2009

Tell Us What to Do

We try to use our Issue Tracker to manage our "To-do List" for PeerBlock. All bugs we find get added to the list, whether we run into them ourselves, or someone reports them to us either using the Issue Tracker itself or via email or a forum-post, or sometimes even if we notice someone complaining somewhere about something that's always bugged them with PG2. When we're trying to figure out what to work on next, we go through this list and try to pick out the most useful bug out of them all. (Well, okay, I admin it, sometimes we instead pick out the "low hanging fruit", the easiest ones to fix, just because we can get a quick rush out of fixing something that easily...)

One of the fields in those Issues that is very helpful to this effort is the "Starred" field. You can "star" an Issue to have the system email you updates whenever that issue is updated - when we start working on it, if we need additional info from people hitting it, if we have a potential fix we need some help testing, when the bug's actually fixed, etc. And from our perspective, issues with more stars are more likely to get attention first, since we assume that more people care about them.

Now, we won't always work on the most popular bugs first, but this is an important metric we use to decide what we should spend our time on. Especially now since we're gearing up for a PeerBlock 1.0 release, and are trying to ensure that the most important bugs are resolved before that point.

This is where you can help!

Please take a look at our Issue Tracker, and if you see anything you'd like to see fixed sooner rather than later, put a star on it!

Yes, this will require having a Google Account - but we all have one of those anyway, for "junk mail" purposes if nothing else, right? And yes this may take a few minutes of your time - but isn't helping make PeerBlock the best it can be worth it?

So please, take a few minutes and tell us what to do!

...and in other news

In case you haven't been following along in our Forums, we're very close now to getting our grubby paws on that elusive Signed Driver. The NY Department of State has finally finished up the paperwork, and "PeerBlock, LLC" is now an official entity. Armed with our new company registration - and $230 worth of your donations - we have filled out the online "paperwork" to get a code-signing certificate from GlobalSign.

At this point we're simply waiting for them to verify that we do in fact exist as a company, and we should then receive our code-signing certificate. I'm hoping that shouldn't take too long, would (optimistically?) hope that should take less than a week. Once we receive that code-signing certificate, I'm hoping to have an official PeerBlock 1.0 Public Release ready to go within a week . . . with an Interim Release coming here to the Dev Blog a few days beforehand.

Thanks for staying interested in PeerBlock, and I hope to hear from you soon!

        ---  Mark  ---

Wednesday, August 19, 2009

PeerBlock r93 Interim Release

A fair amount of development has gone on since the release of PeerBlock 0.9.1 (and the follow-on bugfix release 0.9.2). While these changes have been pretty well-tested by our Beta Team, I wanted to share a wrapup of of them with a slightly wider community. So I'm releasing this new Interim Release, r93.

Please note that this release is not necessarily entirely stable! It is labelled an "Interim Release" for a reason, that reason being that we haven't spent as much time ensuring that it's stable as we generally do with the Public Releases released on the main website. However if you'd like to stay on the "bleeding edge" of PeerBlock development, this is the release you're going to want to check out.

What's Changed

As compared with the latest available PeerBlock Release, here's what's new:
  • Checks for Updates - Public Releases from 0.9.2 on will always check for new Public Releases, and Interim Releases like this one will now check for new Interim Releases (redirecting here to the Dev Blog main page if one is found). (Issue #7, #46)

  • Smaller History.db - When archiving/deleting history file, perform an SQL "vacuum" operation on history.db to cause it to shrink in size. This means that your history.db should generally be much smaller than it might have been previously, so long as you have the "History" section on page 1 of the Settings panel set to "Archive and Remove". (Issue #29)

  • Permanent Blocks list now actually Blocks - Prior to this fix, this list defaulted to Allow; you needed to manually reset it to Block after adding something to it. (Issue #27)

  • Auto-Close Update Window - For new installations (i.e. where no .conf file is found, and it runs you through the Startup Wizard) we default to auto-closing the Update Window after 10 seconds. (Issue #34)

  • Fixed FwpmCalloutAdd0 Error and Crash - Rare bug and accompanying OS crash; fixed in 0.9.2 as well. (Issue #33)

  • XP Pro x64 Detection - Previously, the program would detect XP Pro x64 as Windows Server 2003 x64, and log it as such to peerblock.log. (Issue #31)

  • iBlocklist Lists - Switched P2P, Ads, and Spy lists from PeerGuardian-hosted ones to the iBlocklist-hosted variants; removed Gov list as it was long ago merged into P2P. Note that this will not update your pre-existing blocklists, only if you run through the Startup Wizard (e.g. first run after clean install) or add new lists via the List Manager. (Issue #30)

  • Exception Logging - We now should be logging information on all exceptions to peerblock.log. (Issue #39)

  • Log Timestamps - Peerblock.log now includes date/time-stamps. This should help us track down performance issues, and figure out what was going on closer to the time of failure when troubleshooting. (Issue #39)

  • FwpmEngineOpen0 Messagebox - If the "Base Filtering Engine" isn't set to Automatic (and running), we used to get a very obtuse error message before PeerBlock terminated. We're now trapping this error, and displaying a much more user-friendly message I think. (Issue #25)

Known Issues

The primary issue I'm concerned with is that the automatic list-updates feature doesn't appear to be working as you'd expect it to right now, I think only if you're running with "Auto-close Update Window" on though. I believe this is a "day one" bug we inherited from the old PG2 code, which is why I'm letting this one out the door. So make sure that you manually-update lists every so often. Will be working on a fix for this soon, don't you worry.

Get it Here

PeerBlock r93 Installer


That's it for now. Like I said I wanted to get something out to y'all, since I think there's some goodness in there. And it's been a little while now since we last released anything publicly, and I know that many of you like getting releases relatively often. With this release you should be able to stay on the Interim Release train as well, since as I said it will automatically check for updates and direct you here if a new version is found.

And of course, if you find any bugs in this or any other version of PeerBlock, let us know! You can report them on our Issue Tracker over at Google Code, or via email, or at our new Forums.


        ---  Mark  ---

Monday, August 17, 2009

PeerBlock Forums!

We've been working on setting up some forums for a little while now, especially so after the PG2 site went down a couple weekends back. We're happy to announce that they're live now!

We are still ironing some of the kinks out, so expect to see a few funky things for awhile yet. Strange outages as we update things, features appearing/disappearing almost at random as we enable/disable them, etc. And the default forum template we're using is, um, well, nothing like any of our other sites. But it's clean and perfectly serviceable for now, and should serve us well until we get a chance to create a Grand Unified Look & Feel (tm) for our sites, program, installer, etc.

So come on over to our new PeerBlock Forums, register an account, and talk about any problems you've encountered or suggestions you have!

        ---  Mark  ---

P.S. Thanks to ss18 for working like a madman to set this all up, and to LANsquared for graciously donating server space and bandwidth for it!

Tuesday, August 11, 2009

Out of Town

I'm out-of-state this week, up in Massachusetts for work. And while I brought my laptop to hopefully get some more work done on PeerBlock in the evenings, the place where I'm staying does not have internet access so expect me to be much less-easily contactable until this weekend.

Just thought I'd let y'all know, in case you're wondering why I'm not being my usual chatty self...

        --- Mark ---

Sunday, August 9, 2009

Updating to iBlocklist Lists

Update: It now (9:00 PM EST on 8/9/09) appears as though the servers are back online. The fact remains: the Peer Guardian list servers are notoriously unreliable, and I still strongly recommend that people update their PeerBlock configuration to switch over to the lists outlined in this post.

As of right now (5:06 PM EST on 8/9/09) the servers belonging to Phoenix Labs appear to be down - or at least extremely slow to respond - and have apparently been so for most of the weekend thus far. Since PeerBlock still defaults to using the old PeerGuardian lists hosted by Phoenix Labs, this means that PeerBlock may not be able to update its lists. Even worse - especially since so many people have been downloading PeerBlock this weekend - this means that PeerBlock may not be able to download any lists when you first install it!

Because of this, I strongly recommend that you update your list URLs to point to the blocklists maintained by These include the same "Bluetack" blocklists that PeerBlock/PG2 use, along with many (many) others. Many people on the PG2 forums have been using iBlocklist lists for quite awhile now, and everybody seems extremely pleased with them. In fact, PeerBlock will be switching over to them by default starting with our next release. The servers seem to be much faster than the Phoenix Labs ones, and are much more reliable. And they're run by "Fakhir", a member of the Phoenix Labs crew, so are even from a reputable source. I'm sure you'll like them.

How to Switch

It's actually pretty easy to switch over to using iBlocklist lists!
  1. Open List Manager - Open the main PeerBlock UI, and click on the "List Manager" button.
  2. Edit Entries - For each "" URL in your list of lists, either double-click on the list's row or highlight it and click the "Edit" button.
  3. Enter New URL - In the "URL" field, cut-and-paste the new URL you want to use from the iBlocklist list. Then click "OK".
That's it! After closing the List Manager window, PeerBlock should automatically download the updated blocklists and re-generate the list cache. After that, everything should just work!

Or, if you're more of a "visual learner", iBlocklist has a video tutorial of this available.

Which List to Use?

The only remotely confusing part of this whole process may be selecting which of the iBlocklist lists you should use. The trick is that the original PeerGuardian renamed some of these lists to make them more meaningful, and PeerBlock has so far kept that renaming.

Here's the mapping of which iBlocklist list to use to replace each PeerGuardian one:
  • PeerGuardian Name (PeerGuardian URL): iBlocklist Name (iBlocklist URL)
  • Ads ( Ads, from Bluetack (
  • Educational ( Edu, from Bluetack (
  • Government ( this list actually doesn't exist anymore; its contents have since been merged into the "P2P" list. Remove this list from the List Manager window by clicking once on it to highlight it, then clicking the "Remove" button.
  • P2P ( level1, from Bluetack (
  • Spyware ( spyware, from Bluetack (
They also have many other lists available over there at iBlocklist, I strongly recommend checking them out.

Hope That Helps!

That's all there is to it, really. Like I said I strongly recommend migrating your lists away from the Phoenix Labs hosted ones at this point. Not sure why their servers are down/slow right now, but since their list-servers have been notoriously problematic over the past few years this is probably a good idea regardless.

And as always, if you have any questions or concerns - about this or anything else PeerBlock related - please feel free to comment here or to send me an email!

        ---  Mark  ---

Tuesday, August 4, 2009

Branches and Versions

A new public release will be coming tonight, to fix a Windows-crash reported by a few people. This "bugfix release" is going to be kind of a new thing for us, so I wanted to take a moment to explain how we're handling these bugfix releases and how it affects versioning.

In case you missed the earlier post on PeerBlock Versioning, the "R Number" of a release isn't actually a release number - it's the revision number of the source-code used to build that release. These numbers are used by the source-control system we in the dev team use to coordinate our efforts, and are incremented each time we a change is "committed". So this revision number identifies the exact state of the source-code at the time a release was built, and makes it easy for us to find the version of code to look at when troubleshooting problems with released versions.

Historically, each PeerBlock release has contained every change committed to the source-control tree, so r52 included every change since r33, and r71 included every change since r52. This is about to change.


For this upcoming bugfix release, we're in an interesting position. We have a fix that we want to get out to the public because it fixes a critical problem, but we don't want to release all the changes we've made since r71 because they haven't been tested enough yet and may introduce yet more bugs. So what do we do? We "branch" the code.

Imagine that the program's source-code is like a tree. We initially start out with one continuous stream of changes - this forms the trunk of the tree as we move up. At some point though, we reach a point where we want to have two different sets of source-code changes. The code now branches off in another direction so that we have two versions of the code both "current" at any given time, the "trunk" and the "branch".

That's what we'll be doing here. The Trunk version of code is where all the latest-and-greatest (and potentially unstable) changes are going. The "0.9.x Bugfix Branch" is where we'll be putting only the code we absolutely need to fix bugs in the 0.9.1 release, like this one.

With me so far?


Now most people are familiar with progam versions, so when you see PeerBlock 0.9.2 coming out tonight you'll know that obviously comes after the 0.9.1 that you're running. And when PeerBlock 1.0 comes out later on, you'll know that is a later release than 0.9.2.

The problem comes in with these "R Numbers" though. Remember, they tell us the specific version of the code used to build a particular release. The problem is, they're shared amongst all branches in our source-code "tree" - this means that if we make a change in the "trunk", our rev is incremented. If we then make a dozen more changes to the trunk, our rev is incremented a dozen more times. If we then make a change in the "0.9.x branch", our rev is incremented again.

So What Does This Mean To Me?

What this all boils down to is that our new shiny PeerBlock 0.9.2 release will have an "R Number" of probably r86 or so. And even though this number is way bigger than the r71 of PeerBlock 0.9.1, it doesn't actually include many of those 14 changes that went in, because it came from a different branch.

Going forward, it also means that one given R Number does not necessarily have more stuff in it than a lower R Number. For example, let's pretend we released a r81 Interim Release. This release would have been built from trunk, and would have contained a whole lot of new features. We then came out with v0.9.1 (r86), built from the 0.9.x branch. r86 is a bigger number than r81, but r81 actually is the "newest" build, since it has more new features built into it.

So don't trust the R Numbers anymore. Think of them as a name, and that's about it.

        --- Mark ---

Saturday, August 1, 2009

Auto-close Update Window by Default (r75)

Another thing that's always annoyed me about PG2 was that by default the Update window stays open until you click the Close button. For the most part I don't care that it's checking for updates, or that it just downloaded a new version of my block-lists . . . that's what I expect it to do. Just do it already!

This is exceptionally annoying on startup, as the program will not actually start blocking anything until you dismiss the window.

It's trivial to fix this problem on your own, but I don't think you should need to fix this at all. And it annoys new users, those who are least likely to know how to resolve it, so I've decided to change the default to be to auto-close that window after a 10 second delay. This change will only affect new installations, when the "startup wizard" is first run (or if no peerblock.conf file is found), so if you already have things changed to some other settings you won't be affected at all.

Technical Details

An embarrassingly simple change, really, only two characters in length. Updated the configuration class's initialization-list, which is what holds the default config for if that setting isn't found in peerblock.conf (or of course if that .conf file doesn't exist). If the UpdateCountdown value is less than 0 the program will leave the Update window open until you click the Close button; otherwise that's the number of seconds we'll wait until the window closes.

Permanent Blocks List Actually Blocks (r74)

Another of the nagging problems with PG2 has always been that when you first add an ip-address to your "Permanent Blocks" list, for example right-clicking on an ip-address in the main UI and selecting "Block (ip) permanently", the permblocks.p2b list the program creates ends up being created as being an "Allows" type list. Easy to fix - you just have to edit that list and set it to a Blocks type - but this has always annoyed new users of the program.

Thanks to a patch from night_stalker_z, this problem has now been fixed!

With the r74 commit, PeerBlock now correctly creates the Permanent Blocks list as type Blocks. So hopefully nobody should complain about that one anymore, once we release our next version.

Technical Details

Not much to speak of here really, just a simple "oops" on the part of the original PeerGuardian coders.

Smaller History.db (r73)

There's been a longstanding issue with the "archive and delete history" functionality. While it does (if configured to do so) save aside a text-dump copy of the history as it should, the history.db file never actually shrinks in size! In theory it shouldn't necessarily grow too much either as it should be making use of all that pre-allocated space, it still bothers some people (including me).

With the r73 commit, this problem has been fixed. As part of its "delete" processing, PeerBlock now compacts the database file, removing all that pre-allocated space.

Technical Details

Turns out that sqlite3 - which we're using to handle our cache.db and history.db information - has a "quirk" in it such that when you delete rows from database tables it doesn't actually remove the memory/filespace allocated to them. It adds them to a free-list, but still keeps them lying around.

For more details on this, see section 9.1 of the SQLite Optimization FAQ.

This is probably efficient for certain operations, but it does leave this file unnecessarily large sometimes. For example if you're logging a whole lot of traffic on one day, but then don't do that again for a month or so (or ever!), the database file will forevermore be big enough to store that one crazy day's worth of traffic. Seems like a waste to me.

What you need to do in order to actually shrink the database is perform a "vacuum" command. This will release all those empty data structures on the free-list, so that the file will shrink a bit.

Now looking at the code for r73, you'll see that I'm performing the delete, then a commit, then the vacuum. I'm not entirely sure how the sqlite3x wrapper we use works (I looked into it a bit, but since I was able to get my code working didn't bother spending the time to fully grok it), but it appears as though once a commit is made you can't make any more commits. Trying to "stack" the delete and vacuum commands into one commit threw an exception. So this is the only way I could find to get it to work. I guess vacuum doesn't require a commit?