Smörgåsbord

Nice hardware, but no channel 13

Last week I got myself a TP-Link TL-WR1043ND and pressed it into service as a smart 5-port gigabit switch (with VLAN capabilities) and wireless-N bridge. It is a fine piece of hardware and unbelievably cheap. Best of all, you can install the OpenWRT linux distribution on it. OpenWRT doesn’t target the inexperienced, but it is very customizable, offers a fair amount of documentation, and the build system seems very worthy of giving it a spin.

However. I noticed I couldn’t select a wireless channel >11. That’s odd, because over here in Europe we’re allowed to use the frequencies of channel 12 and 13, too.

Here’s what dmesg told me:

cfg80211: Calling CRDA to update world regulatory domain
cfg80211: World regulatory domain updated:
    (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
    (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
    (2457000 KHz - 2482000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
    (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
    (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
    (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
ath: EEPROM regdomain: 0x0
ath: EEPROM indicates default country code should be used
ath: doing EEPROM country->regdmn map search
ath: country maps to regdmn code: 0x3a
ath: Country alpha2 being used: US
ath: Regpair used: 0x3a
phy0: Selected rate control algorithm 'ath9k_rate_control'
phy0: Atheros AR9100 MAC/BB Rev:0 AR2133 RF Rev:a2 mem=0xb80c0000, irq=2
cfg80211: Calling CRDA for country: US
cfg80211: Regulatory domain changed to country: US
    (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
    (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2700 mBm)
    (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 1700 mBm)
    (5250000 KHz - 5330000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
    (5490000 KHz - 5600000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
    (5650000 KHz - 5710000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
    (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 3000 mBm)

So why does the system think I am in the US? And how can I tell it that I’m actually in the Netherlands? At first glance, it should be as easy as iw reg set NL. Result:

cfg80211: Calling CRDA for country: NL
cfg80211: Regulatory domain changed to country: NL
    (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
    (2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A, 2000 mBm)
    (5170000 KHz - 5250000 KHz @ 40000 KHz), (N/A, 2000 mBm)
    (5250000 KHz - 5330000 KHz @ 40000 KHz), (N/A, 2000 mBm)
    (5490000 KHz - 5710000 KHz @ 40000 KHz), (N/A, 2700 mBm)

Looks about right, doesn’t it? Because 2482000 > 2472000. 2472 KHz is the upper bound of the 22 KHz wide channel 11. Likewise, 2482 KHz is the upper bound of channel 13. So am I all good for channel 13 now? Turns out I am not. iwlist wlan0 channel says:

wlan0     11 channels in total; available frequencies :
          Channel 01 : 2.412 GHz
          Channel 02 : 2.417 GHz
          Channel 03 : 2.422 GHz
          Channel 04 : 2.427 GHz
          Channel 05 : 2.432 GHz
          Channel 06 : 2.437 GHz
          Channel 07 : 2.442 GHz
          Channel 08 : 2.447 GHz
          Channel 09 : 2.452 GHz
          Channel 10 : 2.457 GHz
          Channel 11 : 2.462 GHz
          Current Frequency=2.452 GHz (Channel 9)

The wherefore and the why. And the how.

No channel 13. Wut? I found this informative mailing list post detailing what’s happening here. Basically, the kernel first loads the rules for the ‘world’ domain. On planet Earth, no countries exist that allow you to go beyond these frequencies (for domestic wifi). But many countries have additional restrictions. In Japan, you can use channel 14, in Europe you can’t. You can use 12 and 13 though, which in the US you can’t.
The kernel (well, the “ath” driver) then proceeds to look for any hints from the hardware. In my case the value burned into the hardware EEPROM is 0×0. That’s a value, which, per the Atheros specs, should map to the US. The kernel calls a userspace program crda to get the list of allowed frequencies and signal strenghts for the US.
After this has been done, you can do iw reg set FOO until you drop but you wont be able to go beyond the limits set previously.

The weird thing with radio hardware is that not only the users are subject to regulation, the sellers are too. You can’t sell non-compliant radio hardware. Now, the wifi chip manufacturers do not physically limit a chip intended for sale in the US to channels 1-11. Rather, they mass produce chips and then the equipment manufacturers are supposed to configure the chip in compliance with its target market. (As if you’d never take your equipment to Japan).
As I understand it, TP-Link messed up here.

Compare the above setup with what happens on my laptop’s Atheros chip:

ath: EEPROM regdomain: 0x65
ath: EEPROM indicates we should expect a direct regpair map
ath: Country alpha2 being used: 00
ath: Regpair used: 0x65

Looking at the Linux 2.6.35 sourcecode in drivers/net/wireless/ath/regd_common.h you’ll see that 0×65 maps to WOR5_ETSIC, which holds rules for compliance with EU regulation. Which I suppose is right since I’ve bought that laptop in the EU. But my TP-link comes out as FCC3_FCCA ­— that’s FCC-land, the US.

Fixing it

So either patch the kernel’s mappings, or patch the userspace ‘crda‘ program to supply a modified list of allowed frequencies for the ‘US’. I chose the latter. Reading a bit more about this program and its database, it didn’t appear I could fix it easily — the database is digitally signed and the public key needs to be known to the crda program at compile-time. No problem on a Gentoo system, but the target system was OpenWRT. On a MIPS machine. That meant cross-compiling, so I proceeded by downloading the OpenWRT dev environment for the Backfire release, and had a look around. And whaddayaknow, package/crda/patches/101-make_crypto_use_optional.patch made me hope that signature checking wasn’t even compiled in! On my OpenWRT box:

root@t33t:~# ldd /sbin/crda 
	libnl-tiny.so => /usr/lib/libnl-tiny.so (0x2aabe000)
	libm.so.0 => /lib/libm.so.0 (0x2aad6000)
	libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x2aaff000)
	libc.so.0 => /lib/libc.so.0 (0x2ab1f000)
	ld-uClibc.so.0 => /lib/ld-uClibc.so.0 (0x2aaa8000)

(Don’t you just love it). Now I don’t know a lot about embedded environments and uclibc, but I don’t see any libcrypto.so or libgcrypt.so in there. It looks like I can just supply any old unsigned database. More reading of documentation, some compiling of tools.
regdbdump /usr/lib64/crda/regulatory.bin gives me an editable version of the database. I didn’t feel like limiting myself, so I replaced this:

country 00:
	(2402.000 - 2472.000 @ 40.000), (3.00, 20.00)
	(2457.000 - 2482.000 @ 20.000), (3.00, 20.00), PASSIVE-SCAN, NO-IBSS
	(2474.000 - 2494.000 @ 20.000), (3.00, 20.00), NO-OFDM, PASSIVE-SCAN, NO-IBSS
	(5170.000 - 5250.000 @ 40.000), (3.00, 20.00), PASSIVE-SCAN, NO-IBSS
	(5735.000 - 5835.000 @ 40.000), (3.00, 20.00), PASSIVE-SCAN, NO-IBSS

country US:
	(2402.000 - 2472.000 @ 40.000), (3.00, 27.00)
	(5170.000 - 5250.000 @ 40.000), (3.00, 17.00)
	(5250.000 - 5330.000 @ 40.000), (3.00, 20.00), DFS
	(5490.000 - 5600.000 @ 40.000), (3.00, 20.00), DFS
	(5650.000 - 5710.000 @ 40.000), (3.00, 20.00), DFS
	(5735.000 - 5835.000 @ 40.000), (3.00, 30.00)

with this:

country 00:
  (2402.000 - 2494.000 @ 40.000), (N/A, 30.00)
  (4910.000 - 5835.000 @ 40.000), (N/A, 30.00)

country US:
  (2402.000 - 2494.000 @ 40.000), (N/A, 30.00)
  (4910.000 - 5835.000 @ 40.000), (N/A, 30.00)

and then I converted the database to its binary form with db2bin.py which one can find in the wireless-regdb source code releases. Copied the new database over to my OpenWRT machine, restarted it, dmesg, presto:

cfg80211: Calling CRDA to update world regulatory domain
cfg80211: World regulatory domain updated:
    (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
    (2402000 KHz - 2494000 KHz @ 40000 KHz), (N/A, 3000 mBm)
    (4910000 KHz - 5835000 KHz @ 40000 KHz), (N/A, 3000 mBm)
ath: EEPROM regdomain: 0x0
ath: EEPROM indicates default country code should be used
ath: doing EEPROM country->regdmn map search
ath: country maps to regdmn code: 0x3a
ath: Country alpha2 being used: US
ath: Regpair used: 0x3a
phy0: Selected rate control algorithm 'ath9k_rate_control'
phy0: Atheros AR9100 MAC/BB Rev:0 AR2133 RF Rev:a2 mem=0xb80c0000, irq=2
cfg80211: Calling CRDA for country: US
cfg80211: Regulatory domain changed to country: US
    (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
    (2402000 KHz - 2494000 KHz @ 40000 KHz), (N/A, 3000 mBm)
    (4910000 KHz - 5835000 KHz @ 40000 KHz), (N/A, 3000 mBm)

root@t33t:~# iwlist wlan0 channel
wlan0     14 channels in total; available frequencies :
          Channel 01 : 2.412 GHz
          Channel 02 : 2.417 GHz
          Channel 03 : 2.422 GHz
          Channel 04 : 2.427 GHz
          Channel 05 : 2.432 GHz
          Channel 06 : 2.437 GHz
          Channel 07 : 2.442 GHz
          Channel 08 : 2.447 GHz
          Channel 09 : 2.452 GHz
          Channel 10 : 2.457 GHz
          Channel 11 : 2.462 GHz
          Channel 12 : 2.467 GHz
          Channel 13 : 2.472 GHz
          Channel 14 : 2.484 GHz
          Current Frequency=2.452 GHz (Channel 9)

Legality

This is a rather libertarian approach. Not legal on Earth, it doesn’t even comply with the ‘World’ regulatory domain. Yes, among other things, this gives you access to the ‘Japanese’ channel 14. The rules don’t prevent you from going totally EMP on your neighbourhood. (Your hardware does, though).
It’s now YOUR responsibility to comply with local regulations. If you look out the window and see an airliner perform a barrel roll, you know it’s time to iw reg set $YOURCOUNTRYCODE.
And remember, interference works both ways. The fact that your neighbours cannot use some frequencies doesn’t necessarily mean you’ll get good performance using those (frequencies I mean). It may well be that you’ll have lousy reception because other (possibly more powerful) equipment is legally being used on those channels. Just stick with your country’s regulations OK?

I kept the previous ‘US’ entry as ‘UX’ so I can still comply with US regulations if necessary. I hear they’re big on regulations in the US. Especially if it involves foreigners.

In this post I’ll show you how to do basic ‘cracking’ of a piece of software and make WebDAV work well in Windows Vista (32-bit).

WebDAV. Accessing a filesystems, or anything collection-like, over HTTP. It’s a fantastic invention. Sadly, every Windows version in the past decade has contained a botched client implementation of this protocol.
Fact #1. I run WebDAV servers.
Fact #2. Some people still use ‘Windows’.
Herein lies a problem.

So I have been on the hunt for a sane third-party implementation for Vista. And it just so happens that a certain ISP (XS4ALL) offers WebDAV access. They must have run into trouble with Vista’s anti-implementation of WebDAV too as they’re offering a third-party WebDAV client to the Windows hoi polloi.
And it happens to work rather well. You get an extra ‘drive’ so to any userspace program it’s just as if it’s interfacing a regular filesystem. One problem, though:

It seems to be ‘configured’ to disallow access to other servers than XS4ALL’s.
Of course, we could locally spoof their DNS record and pray the software will accept our dodgy SSL certificate, but that does not scale to the end-users that wish to connect to my WebDAV server.

Start by downloading XS4ALL-webdisk.exe from this page. It says its version number is 5.00.06 and its MD5sum should be 9d008d79099cd1c74abe6e0f1397b0a1. If you get a different checksum don’t worry – you may still be able to crack it, because at the very least you know what to look for when you’re done reading this. I can’t provide you with the version I downloaded because I don’t own the copyright and I haven’t received a license to redistribute.
Go ahead and run the installer. Then, try connecting to a WebDAV server of choice and observe that any attempts will be defeated.

Next, get a hex editor. Here’s the freeware one that I picked. With your editor, open wdfsctl.exe from wherever it is you installed the Webdisk. You should see something resembling this:

To the left, in blue, is the offset. It’s the position in the file. To the right of the offset are bytes in hexadecimal representation. To the far right is the text representation of those bytes.
Now, an .exe can have text mixed in with executable code. A text representation of executable instructions does not make sense which is why you encounter copious amounts of gibberish in the right column. But, as you scroll up and down in the file, you’ll discover lots of proper English sentences in the right column. Select the text and the corresponding bytes will be highlighted. Move over to those bytes in the middle column, change them, and observe that the corresponding text representation also changes. It works the other way around, too. Fun as that may seem we can’t go around changing strings (bits of text are called strings) willy-nilly. Specifically, we cannot change their length or position. Why not? Well, bits and pieces of the program are referenced from other bits and pieces of the program by their offset. Change the offset (position) of some program instruction in the binary (by adding text in front of it or something) and you’ll have to update any and all references to this position. It can be done but we aren’t going to do it. HxD helpfully warns you if you’re trying to do it.
OK, let’s go string hunting. We’re looking for something that is matching xs4all.nl since the restriction most probably works by whitelisting. It took me a quite a while to find it, but it’s at offset 6DAB2. You’ll find the string x.s.4.a.l.l...n.l there. Look over to the hex representation and you’ll find it’s a pattern of characters separated by 00. That’s called null-delimited. Mind you, the 00 you see in the hex representation is not the same as ‘00′ in the text representation:

• Enter a ‘.’ in the text representation and you get 2E in the hex representation.
• Enter a ‘0′ in the text representation and you get 30 in the hex representation.
• Enter a 00 in the hex representation and you get a ‘.’ in the text representation.

It’s the hex representation that counts. Now, after some poking around I established that this string itself is null-terminated, too. So, to end the string, the hex representation has to read 00 00 00 because the characters inside the string are null-terminated as well. That’s two levels of null-termination.
After discovering this, it’s time to dick around with patterns. Change the ‘4′ in x.s.4.a.l.l...n.l to a null by typing ‘00′ in the hex representation at byte 06, offset 0006DAB0. Run the program. Try to connect to https://ha.xs/quux . Chances of success are very slim, but the program doesn’t stop you from trying! You can put anything in front of ‘.xs’ and it will try to connect. Change byte 00 to ‘a’ (in the text representation) and convince yourself that the program will now get out of your way should you attempt to connect to https://fabuloushaxs/quux, but it still stops you from connecting to https://fabuloushaxz/quux.
It appears that the string we’ve just changed has to match the end of the host we’re trying to connect to. So, originally, for https://justconnectmetomyserveralready.net/mydir it would check whether it ends with xs4all.nl which, of course, it doesn’t. However, we can make the string very, very short. In fact, we can make it empty, causing it to always match the end of any host we enter. To do that, just enter 00 in the hex representation at byte 00 at offset 0006DAB0. Connect to your favourite WebDAV server. It works, doesn’t it?

What we have just done is actually pretty basic. ‘Real’ crackers, the folks that let you bypass registration requirements or serial number checks, use tools to look into the memory area of a running program to see which steps make up its behaviour. They don’t just edit some strings, they add and change instructions (and offsets). That requires a much deeper understanding of what’s going on.

There’s various other stuff to be modified. You can change the window title or the help texts. I disabled the auto-update by replacing the URLs at offset 0006BA60, maybe you should do so too.

Now for some legalities. For me, to publish how I edited this .exe, is perfectly legal — especially considering the educative character of this post.
Redistributing the original program wouldn’t be legal. Me or you distributing any modified versions wouldn’t be legal, either. That’s basic copyright law.