Thursday, July 30, 2015

A quick review of the BIND9 code

BIND9 is the oldest and most popular DNS server. Today, they announced a DoS vulnerability was announced that would crash the server with a simply crafted query.  I could use my "masscan" tool to blanket the Internet with those packets and crash all publicly facing BIND9 DNS servers in about an hour. A single vuln doesn't mean much, but if you look at the recent BIND9 vulns, you see a pattern forming. BIND9 has lots of problems -- problems that critical infrastructure software should not have.

Its biggest problem is that it has too many feature. It attempts to implement every possible DNS feature known to man, few of which are needed on publicly facing servers. Today's bug was in the rarely used "TKEY" feature, for example. DNS servers exposed to the public should have the minimum number of features -- the server priding itself on having the maximum number of features is automatically disqualified.

Another problem is that DNS itself has some outdated design issues. The control-plane and data-plane need to be separate. This bug is in the control-plane code, but it's exploited from the data-plane. (Data-plane is queries from the Internet looking up names, control-plane is zones updates, key distribution, and configuration). The control-plane should be on a separate network adapter, separate network address, and separate port numbers. These should be hidden from the public, and protected by a firewall.

DNS should have hidden masters, servers with lots of rich functionality, such as automatic DNSSEC zone signing. It should have lightweight exposed slaves, with just enough code to answer queries on the data-plane, and keep synchronized with the master on the control-plane.

But what this post is really about is looking at BIND9's code. It's a nicer than the OpenSSL code and some other open-source projects, but there do appear to be some issues. The bug was in the "dns_message_findname()" function. The function header looks like:

dns_message_findname(dns_message_t *msg, dns_section_t section,
    dns_name_t *target, dns_rdatatype_t type,
    dns_rdatatype_t covers, dns_name_t **name,
    dns_rdataset_t **rdataset);

The thing you should notice here is that none of the variables are prefixed with const, even though all but one of them should be. A quick grep shows that lack of const correctness is pretty common throughout the BIND9 source code. Every quality guide in the world strongly suggests const correctness -- that's it's lacking here hints at larger problems.

The bug was an assertion failure on the "name" parameter in the code above, as you can see in the picture. An assertion is supposed to double-check internal consistency of data, to catch bugs early. But this case, there was no bug being caught -- it was the assertion itself that was the problem. The programmers are confused by the difference between in, out, and in/out parameters. You assert on the expected values of the in and in/out parameters, but not on write-only out parameters. Since the function doesn't read them, their value is immaterial. If the function wants it to be NULL on input, it can just set it itself -- demanding that the caller do this is just bad.

By the way, assertions are normally enabled only for testing, but not for production code. That's because they can introduce bugs (as in this case), and have performance problems. However, in the long run, aggressive double-checking leads to more reliable code. Thus, I'm a fan of such aggressive checking. However, quickly glancing at the recent BIND9 vulns, it appears many of them are caused by assertions failing. This may be good, meaning that the code was going to crash (or get exploited) anyway, and the assertion caught it early. Or, it may be bad, with the assertion being the bug itself, or at least, that the user would've been happier without the assertion triggering (because of a memory leak, for example). If the later is the case, then it sounds like people should just turn off the assertions when building BIND9 (it's a single command-line switch).

Last year, ISC (the organization that maintains BIND9) finished up their BIND10 project, which was to be a re-write of the code. This was a fiasco, of course. Rewrites of large software project are doomed to failure. The only path forward for BIND is with the current code-base. This means refactoring and cleaning up technical debt on a regular basis, such as fixing the const correctness problem. This means arbitrarily deciding to drop support for 1990s era computers when necessary. If the architecture needs to change (such as separating the data-plane from the control-plane), it can be done within the current code-base -- just create a solid regression test, then go wild on the changes relying upon the regression test to maintain the quality.

Lastly, I want to comment on the speed of BIND9. It's dog slow -- the slowest of all the DNS servers. That's a problem firstly because slow servers should not be exposed to DDoS attacks on the Internet. It's a problem secondly because slow servers should not be written in dangerous languages like C/C++ . These languages should only be used when speed is critical. If your code isn't fast anyway, then you should be using safe languages, like C#, Java, or JavaScript. A DNS server written in these languages is unlikely to be any slower than BIND9.


The point I'm trying to make here is that BIND9 should not be exposed to the public. It has code problems that should be unacceptable in this day and age of cybersecurity. Even if it were written perfectly, it has far too many features to be trustworthy. It's feature-richness makes it a great hidden master, it's just all those feature get in the way of it being a simple authoritative slave server, or a simple resolver. They shouldn't rewrite it from scratch, but if they did, they should choose a safe language and not use C/C++.

Example#2: strcpy()

BIND9 has 245 instances of the horribly unsafe strcpy() function, spread through 94 files. This is unacceptable -- yet another technical debt they need to fix. It needs to be replaced with the strcpy_s() function.

In the file lwresutil.c is an example of flawed thinking around strcpy(). It's not an exploitable bug, at least not yet, but it's still flawed.

{ unsigned int target_length;

target_length = strlen(name);
if (target_length >= sizeof(target_name))
strcpy(target_name, name); /* strcpy is safe */

The problem here, which I highlighted in bold. The problem is that on a 64-bit machine, an unsigned int is only 32-bits, but string lengths can be longer than a 32-bit value can hold. Thus, a 4-billion byte name would cause the integer to overflow and the length check to fail. I don't think you can get any name longer than 256 bytes through this code path, so it's likely not vulnerable now, but the "4-billion bytes of data" problem is pretty common in other code, and frequently exploitable in practice.

The comment /* strcpy is safe */ is no more accurate than those emails that claim "Checked by anti-virus".

Modern code should never use strcpy(), at all, under any circumstances, not even in the unit-test code where it doesn't matter. It's easy to manage projects by simply grepping for the string "strcpy()" and whether it exists or not, it's hard managing project with some strcpy()s. It's like being some pregnant.

Wednesday, July 22, 2015

Infosec's inability to quantify risk

Infosec isn't a real profession. Among the things missing is proper "risk analysis". Instead of quantifying risk, we treat it as an absolute. Risk is binary, either there is risk or there isn't. We respond to risk emotionally rather than rationally, claiming all risk needs to be removed. This is why nobody listens to us. Business leaders quantify and prioritize risk, but we don't, so our useless advice is ignored.

An example of this is the car hacking stunt by Charlie Miller and Chris Valasek, where they turned off the engine at freeway speeds. This has lead to an outcry of criticism in our community from people who haven't quantified the risk. Any rational measure of the risk of that stunt is that it's pretty small -- while the benefits are very large.

In college, I owned a poorly maintained VW bug that would occasionally lose power on the freeway, such as from an electrical connection falling off from vibration. I caused more risk by not maintaining my car than these security researchers did.

Indeed, cars losing power on the freeway is a rather common occurrence. We often see cars on the side of the road. Few accidents are caused by such cars. Sure, they add risk, but so do people abruptly changing lanes.

No human is a perfect driver. Every time we get into our cars, instead of cycling or taking public transportation, we add risk to those around us. The majority of those criticizing this hacking stunt have caused more risk to other drivers this last year by commuting to work. They cause this risk not for some high ideal of improving infosec, but merely for personal convenience. Infosec is legendary for it's hypocrisy, this is just one more example.

Google, Tesla, and other companies are creating "self driving cars". Self-driving cars will always struggle to cope with unpredictable human drivers, and will occasionally cause accidents. However, in the long run, self-driving cars will be vastly safer. To reach that point, we need to quantify risk. We need to be able to show that for every life lost due to self-driving cars, two have been saved because they are inherently safer. But here's the thing, if we use the immature risk analysis from the infosec "profession", we'll always point to the one life lost, and never quantify the two lives saved. Using infosec risk analysis, safer self-driving cars will never happen.

In hindsight, it's obvious to everyone that Valasek and Miller went too far. Renting a track for a few hours costs less than the plane ticket for the journalist to come out and visit them. Infosec is like a pride of lions, that'll leap and devour one of their members when they show a sign of weakness. This minor mistake is weakness, so many in infosec have jumped on the pair, reveling in righteous rage. But any rational quantification of the risks show that the mistake is minor, compared to the huge benefit of their research. I, for one, praise these two, and hope they continue their research -- knowing full well that they'll likely continue to make other sorts of minor mistakes in the future.

Monday, July 20, 2015

My BIS/Wassenaar comment

This is my comment I submitted to the BIS on their Wassenaar rules:


I created the first “intrusion prevention system”, as well as many tools and much cybersecurity research over the last 20 years. I would not have done so had these rules been in place. The cost and dangers would have been too high. If you do not roll back the existing language, I will be forced to do something else.

After two months, reading your FAQ, consulting with lawyers and export experts, the cybersecurity industry still hasn’t figured out precisely what your rules mean. The language is so open-ended that it appears to control everything. My latest project is a simple “DNS server”, a piece of software wholly unrelated to cybersecurity. Yet, since hackers exploit “DNS” for malware command-and-control, it appears to be covered by your rules. It’s specifically designed for both the distribution and control of malware. This isn’t my intent, it’s just a consequence of how “DNS” works. I haven’t decided whether to make this tool open-source yet, so therefore traveling to foreign countries with the code on my laptop appears to be a felony violation of export controls.

Of course you don’t intend to criminalize this behavior, but that isn’t the point. The point is that the rules are so vague that they become impossible for anybody to know exactly what is prohibited. We therefore have to take the conservative approach. As we’ve seen with other vague laws, such as the CFAA, enforcement is arbitrary and discriminatory. None of us would have believed that downloading files published on a public website would be illegal until a member of community was convicted under the CFAA for doing it. None of us wants to be a similar test case for export controls. The current BIS rules are so open-ended that they would have a powerful chilling effect on our industry.

The solution, though, isn’t to clarify the rules, but to roll them back. You can’t clarify the difference between good/bad software because there is no difference between offensive and defensive tools -- just the people who use them. The best way to secure your network is to attack it yourself. For example, my “masscan” tool quickly scans large networks for vulnerabilities like “Heartbleed”. Defenders use it to quickly find vulnerable systems, to patch them. But hackers also use my tool to find vulnerable systems to hack them. There is no solution that stops bad governments from buying “intrusion” or “surveillance” software that doesn’t also stop their victims from buying software to protect themselves. Export controls on offensive software means export controls on defensive software. Export controls mean the Sudanese and Ethiopian people can no longer defend themselves from their own governments.

Wassenaar was intended to stop “proliferation” and “destabilization”, yet intrusion/surveillance software is neither of those. Human rights activists have hijacked the arrangement for their own purposes. This is a good purpose, of course, since these regimes are evil. It’s just that Wassenaar is the wrong way to do this, with a disproportionate impact on legitimate industry, while at the same time, hurting the very people it’s designed to help. Likewise, your own interpretation of Wassenaar seems to have been hijacked by the intelligence community in the United States for their own purposes to control “0days”.

Rather than the current open-end and vague interpretation of the Wassenaar changes, you must do the opposite, and create the narrowest of interpretations. Better yet, you need to go back and renegotiate the rules with the other Wassenaar members, as software is not a legitimate target of Wassenaar control. Computer code is not a weapon, if you make it one, then you’ll destroy America’s standing in the world. On a personal note, if you don’t drastically narrow this, my research and development will change. Either I will stay in this country and do something else, or I will move out of this country (despite being a fervent patriot).

Robert Graham
Creator of BlackICE, sidejacking, and masscan.
Frequent speaker at cybersecurity conferences.

Wednesday, July 15, 2015

Software and the bogeyman

This post about the July 8 glitches (United, NYSE, WSJ failed) keeps popping up in my Twitter timeline. It's complete nonsense.

What's being argued here is that these glitches were due to some sort of "moral weakness", like laziness, politics, or stupidity. It's a facile and appealing argument, so scoundrels make it often -- to great applause from the audience. But it's not true.


Layers and legacies exist because working systems are precious. More than half of big software projects are abandoned, because getting new things to work is a hard task. We place so much value on legacy, working old systems, because the new replacements usually fail.

An example of this is the failed BIND10 project. BIND, the Berkeley Internet Name Daemon, is the oldest and most popular DNS server. It is the de facto reference standard for how DNS works, more so than the actual RFCs. Version 9 of the project is 15 years old. Therefore, the consortium that maintains it funded development for version 10. They completed the project, then effectively abandoned it, as it was worse in almost every way than the previous version.

The reason legacy works well is the enormous regression testing that goes on. In robust projects, every time there is a bug, engineers create one or more tests to exercise the bug, then add that to the automated testing, so that from now on, that bug (or something similar) can never happen again. You can look at a project like BIND9 and point to the thousands of bugs it's had over the last decade. So many bugs might make you think it's bad, but the opposite is true: it means that it's got an enormous regression test system that stresses the system in peculiar ways. A new replacement will have just as many bugs -- but no robust test that will find them.

A regression test is often more important than the actual code. If you want to build a replacement project, start with the old regression test. If you are a software company and want to steal your competitors intellectual property, ignore their source, steal their regression test instead.

People look at the problems of legacy and believe that we'd be better off without it, if only we had the will (the moral strength) to do the right thing and replace old system. That's rarely true. Legacy is what's reliable and working -- it's new stuff that ultimately is untrustworthy and likely to break. You should worship legacy, not fear it.

Technical debt

Almost all uses of the phrase "technical debt" call it a bad thing. The opposite is true. The word was coined to refer to a good thing.

The analogy is financial debt. That, too, is used incorrectly as a pejorative. People focus on the negatives, the tiny percentage of bankruptcies. They don't focus on the positives, what that debt finances, like factories, roads, education, and so on. Our economic system is "capitalism", where "capital" just means "debt". The dollar bills in your wallet are a form of debt. When you contribute to society, they are indebted to you, so give you a marker, which you can then redeem by giving back to society in exchange something that you want, like a beer at your local bar.

The same is true of technical debt. It's a good thing, a necessary thing. The reason we talk about technical debt isn't so that we can get rid of it, but so that we can keep track of it and exploit it.

The Medium story claims:
A lot of new code is written very very fast, because that’s what the intersection of the current wave of software development (and the angel investor / venture capital model of funding) in Silicon Valley compels people to do.
This is nonsense. Every software project of every type has technical debt. Indeed, it's open-source that overwhelmingly has the most technical debt. Most open-source software starts as somebody wanting to solve a small problem now. If people like the project, then it survives, and more code and features are added. If people don't like it, the project disappears. By sheer evolution, that which survives has technical debt. Sure, some projects are better than others at going back and cleaning up their debt, but it's something intrinsic to all software engineering.

Figuring out what user's want is 90% of the problem, how the code works is only 10%. Most software fails because nobody wants to use it. Focusing on removing technical debt, investing many times more effort in creating the code, just magnifies the cost of failure when your code still doesn't do what users want. The overwhelmingly correct development methodology is to incur lots of technical debt at the start of every project.

Technical debt isn't about bugs. People like to equate the two, as both are seen as symptoms of moral weakness. Instead, technical debt is about the fact that fixing bugs (or adding features) is more expensive the more technical debt you have. If a section of the code is bug-free, and unlikely to be extended to the future, then there will be no payback for cleaning up the technical debt. On the other hand, if you are constantly struggling with a core piece of code, making lots of changes to it, then you should refactor it, cleaning up the technical debt so that you can make changes to it.

In summary, technical debt is not some sort of weakness in code that needs to be fought, but merely an aspect of code that needs to be managed.


More and more, software ends up interacting with other software. This causes unexpected things to happen.

That's true, but the alternative is worse. As a software engineer building a system, you can either link together existing bits of code, or try to "reinvent the wheel" and write those bits yourself. Reinventing is sometimes good, because you get something tailored for your purpose without all the unnecessary complexity. But more often you experience the rewriting problem I describe above: your new code is untested and buggy, as opposed to the well-tested, robust, albeit complex module that you avoided.

The reality of complexity is that we demand it of software. We all want Internet-connected lightbulbs in our homes that we can turn on/off with a smartphone app while vacationing in Mongolia. This demands a certain level of complexity. We like such complexity -- arguing that we should get rid of it and go back to a simpler time of banging rocks together is unacceptable.

When you look at why glitches at United, NYSE, and WSJ happen, it because once they've got a nice robust system working, they can't resist adding more features to it. It's like bridges. Over decades, bridge builders get more creative and less conservative. Then a bridge fails, because builders were to aggressive, and the entire industry moves back into becoming more conservative, overbuilding bridges, and being less creative about new designs. It's been like that for millennia. It's a good thing, have you even seen the new bridges lately? Sure, it has a long term cost, but the thing is, this approach also has benefits that more than make up for the costs. Yes, NYSE will go down for a few hours every couple years because of a bug they've introduced into their system, but the new features are worth it.

By the way, I want to focus on the author's quote:
Getting rid of errors in code (or debugging) is a beast of a job
There are two types of software engineers. One type avoids debugging, finding it an unpleasant aspect of their job. The other kind thinks debugging is their job -- that writing code is just that brief interlude before you start debugging. The first kind often gives up on bugs, finding them to be unsolveable. The second type quickly finds every bug they encountered, even the most finicky kind. Every large organization is split between these two camps: those busy writing code causing bugs, and the other camp fixing them. You can tell which camp the author of this Medium story falls into. As you can tell, I have enormous disrespect for such people.

"Lack of interest in fixing the actual problem"

The NYSE already agrees that uptime and reliability is the problem, above all others, that they have to solve. If they have a failure, it doesn't mean they aren't focused on failures as the problem.

But in truth, it's not as big a problem as they think. The stock market doesn't actually need to be that robust. It's more likely to "fail" for other reasons. For example, every time a former President dies (as in the case of Ford, Nixon, and Reagan), the markets close for a day in mourning. Likewise, wild market swings caused by economic conditions will automatically shut down the market, as they did in China recently.

Insisting that code be perfect is absurd, and impossible. Instead, the only level of perfection the NYSE needs is so that glitches in code shut down the market less often than dead presidents or economic crashes.

The same is true of United Airlines. Sure, a glitch grounded their planes, but weather and strikes are a bigger problem. If you think grounded airplanes is such an unthinkable event, then the first thing you need to do is ban all unions. I'm not sure I disagree with you, since it seems every flight I've had through Charles de Gaulle airport in Paris has been delayed by a strike (seriously, what is wrong with the French?). But that's the sort of thing you are effectively demanding.

The only people who think that reliability and uptime are "the problem" that needs to be fixed are fascists. They made trains "run on time" by imposing huge taxes on the people to overbuild the train system, then putting guns to the heads of the conductors, making them indentured servants. The reality is that "glitches" are not "the problem" -- making systems people want to use is the problem. Nobody likes it when software fails, of course, but that's like saying nobody likes losing money when playing poker. It's a risk vs. reward, we can make software more reliable but at such a huge cost that it would, overall, make software less desirable.


Security and reliability are tradeoffs. Problems happen not because engineers are morally weak (political, stupid, lazy), but because small gains in security/reliability would require enormous sacrifices in other areas, such as features, cost, performance, and usability. But "tradeoffs" are a complex answer, requiring people to thinki. "Moral weakness" is a much easier, and more attractive answer that doesn't require much thought, since everyone is convinced everyone else (but them) is morally weak. This is why so many people in my Twitter timeline keep mentioning that stupid Medium article.

More ProxyHam stuff

Somebody asked how my solution in the last post differed from the "ProxyGambit" solution. They missed my point. Just because I change the tires on the car doesn't mean I get credit for inventing or building the car. The same thing with this ProxyHam nonsense: nobody is "building a solution". Instead, we are all just using existing products the way they are intended. We are all just choosing a different mix of components.

People get all excited when they see a bare Raspberry Pi board, but the reality is that there's nothing interesting going on here, no more than lifting the hood/bonnet on your car. This is photograph from ProxyGambit:

What ProxyGambit is doing here is using cellular data on the far end rather stealing WiFi from Starbucks or the local library. Their solution looks fancy, but you can do the same thing with off-the-shelf devices for a lot cheaper. Here is the same solution with off-the-shelf products:

This is just a TL-WR703N ($26) router with a 3G USB dongle. You can get these dongles cheap off eBay used, or new for around $17. Combined, they are cheaper than a Raspberry PI. If you want to customize this, you can replace the firmware on the router with dd-wrt/OpenWRT Linux.

Like my solution, they chose Ubquiti's NanoStation. However, they went with the 2.4 GHz version (locoM2 for $49) rather than my choice of 900 MHz (locoM9 for $125). There's also a 5 GHz version one could choose from (locoM5 for $62).

The 900 MHz, 2.4 GHz, and 5 GHz are all unregulated ISM bands. They all require relatively direct line-of-sight. The 5 GHz band requires absolutely no obstructions -- you have to be able to see the other end of the connection with binoculars. The 2.4 band allows some light foliage to be in the way. The 900 MHz band is very forgiving, allowing heavy foliage and possibly a house in the way.

The upshot is that the difference between "ProxyGambit" and my solution is the use of a cellular modem on the far end rather than hitching a ride with Starbucks, and the choice of a 2.4 GHz for the long distance connection rather than 900 MHz. But don't be limited by these choices -- there is a huge range of choices that can be made here. ProxyGambit made some interesting choices -- give it a try yourself and make some different ones.

Tuesday, July 14, 2015

How to build your own ProxyHam

"ProxyHam" created controversy because the talk was supposedly suppressed by the US government. In this post, I'll describe how you can build your own, with off-the-shelf devices, without any code.

First, head on over to NewEgg. For a total of $290.96, buy two locoM9 repeaters (for $125.49 each), and two WiFi routers, like the TL-WR700N for $19.99 each.

Grab your first WiFi device. Configure it in "client" mode, connecting it to the "Starbucks" SSID. In this mode, you can then connect your laptop via Ethernet to this device, and you'll have access to the Internet via your WiFi device to Starbucks. In other words, it acts as a WiFi dongle, but one that you attach via Ethernet instead of USB.

Now grab your two locoM9 devices and configure them for "transparent bridging". In this mode, whatever Ethernet packets that are received on one end get sent over the air to the other end. Connect each localM9 via the TL-WR700N via the supplied Ethernet cable.

Now grab the second WiFi device and configure it as a normal WiFi router.

Now, assuming you aim the localM9's correct toward each other with reasonable line-of-sight, you've got a "ProxyHam".

The reason this works so easily is that everything has been designed to work this way. Bands like 900 MHz, 2.4 GHz, and 5 GHz are the "ISM bands" that are largely unregulated by the government. Unregulated means that if somebody is causing interference in those bands, you can't complain to the government to make them stop.

The 900 MHz band is attractive because the signal will go a lot further than 2.4 GHz. On the other hand, it's a smaller band, so can't carry the same speed as 2.4 GHz band or the 5 GHz band.

Industrial equipment use the 900 MHz band extensively. There are an enormous number of devices that'll bridge two wires in this band. Most of them are for simple serial protocols like RS232. Some are for Ethernet, like the locoM9. They tend be industrial grade things that cost a lot more. The locoM9 is the cheapest device that does this from Ubiquiti, but they have a lot of more expensive stuff to choose from, often with better directional antennas that'll go farther.

WiFi, too, is supposed to work this way. When you buy a WiFi router, you normally set it up in "access-point" mode. But virtually every router supports other modes, such as the "client" or "bridging" mode described above. It's supposed to work this way.

The point of "ProxyHam" isn't that there is some new magic out there, but that hackers can take existing stuff, for their expected purpose, but achieving an unexpected outcome.

Monday, July 13, 2015

ProxyHam conspiracy is nonsense

This DEF CON conspiracy theory is about a canceled talk about "ProxyHam", which has been canceled under mysterious circumstances. It's nonsense.

The talk was hype to begin with. You can buy a 900 MHz bridge from Ubquiti for $125 (or MicroTik device for $129) and attach it to a Raspberry Pi. How you'd do this is obvious. It's a good DEF CON talk, because it's the application that important, but the technical principles here are extremely basic.

If you look careful at the pic in the Wired story on ProxyHam, it appears they are indeed just using the Ubuiti device. Here is the pic from Wired:

And here is the pic from Ubquiti's website:

I don't know why the talk was canceled. One likely reason is that the stories (such as the one on Wired) sensationalized the thing, so maybe their employer got cold feet. Or maybe the FBI got scared and really did give them an NSL, though that's incredibly implausible. The feds have other ways to encourage people to be silent (I've personally been threatened to cancel a talk), but it wouldn't be an NSL.

Anyway, if DEF CON wants a talk on how to hook up a Raspberry Pi to a UbiQuiTi NanoStation LOCOM9 in order bridge WiFi, I'll happily give that talk. It's just basic TCP/IP configuration, and if you want to get fancy, some VPN configuration for the encryptions. Just give me enough lead time to actually buy the equipment and test it out. Also, if DEF CON wants to actually set this up in order to get long distance WiFi working to other hotels, I'll happily buy a couple units and set them up this way.

Update: Accessing somebody's open-wifi, like at Starbucks, is (probably) not a violation of the CFAA (Computer Fraud and Abuse Act). The act is vague, of course, so almost anything you do on a computer can violate the CFAA if prosectors want to go after you, but at the same time, this sort of access is far from the original intent of the CFAA. Public WiFi at places like Starbucks is public.

This is not a violation of FCC part 97 which forbids ham radios from encryption data. It's operating in the unlicensed ISM bands, so is not covered by ham rules, despite the name "ProxyHam".

Update: An even funner talk, which I've long wanted to do, is to do the same thing with cell phones. Take a cellphone, pull it apart, disconnect the antenna, then connect it to a highly directional antenna pointed at a distant cell tower -- several cells away. You'd then be physically nowhere near where the cell tower thinks you are. I don't know enough about how to block signals in other directions, though -- radio waves are hard.

Update: There are other devices than those I mention:

Thursday, July 02, 2015

Some notes when ordering Google's Project Fi

I just ordered my "Project Fi" phone. You probably should, too. Here are some notes (especially near the bottom on getting a new phone number).

Project Fi is Google's MVNO. An "MVNO" is a virtual mobile phone company -- they don't have any of their own network backbone or cell towers, but just rent them from the real mobile phone companies (like AT&T or T-Mobile). Most mobile phone companies are actually MVNOs, because building a physical network is expensive.

What makes Google's MVNO interesting:
  • Straightforward pricing. It's $20 a month for unlimited calling/texting, plus $10 per gigabyte of data used during the month. It includes tethering.
  • No roaming charges, in 120 countries. I can fly to Japan, Australia, and France, and still use email, Google maps, texting -- for no extra charge.
The pricing is similar to other phone companies, a little less or a little more depending on exactly what you want. For around 3 gigs a month, Project Fi is cheaper than AT&T, but for 30 gigs, it's more expensive.

There are more and more MVNOs providing easy international roaming (like, and your own phone company is increasingly solving the problem. T-Mobile, for example, provides free roaming at 2G speeds, enough to check email and maybe enough to navigate.

In-country phone calls are free, but international phone calls still cost $0.20 a minute -- unless you are on WiFi, in which case it's free. Again, this is a feature provided by other mobile phone companies and MVNOs.

In short, Google is really doing nothing new. They are just providing what you'd expect of a 21st century phone service without all the pricing shenanigans that other companies go through in order to squeeze extra money out of you.

One of the big things is which number you will use. In the United States, you can now take your phone number with you when you switch phone companies. But there are other options. For example, you can get a new phone number with the phone in order to try out the service, then switch numbers later. Or, you can switch your current number to Google Voice, and then simply forward it to the new phone. I'm choosing the third option -- using both phones for a while, and if I decide to keep my new Google phone, switch my old number over using Google Voice.

If you plan on getting a new phone number, there is a trick to it. In most areas, you'll just get a recycled phone number that was previously used by somebody else. You'll spend the next several years getting phone calls for that person. In particular, you'll get phone calls from collection agencies trying to collect money from dead beats that used to have your number. That's because people with credit problems go through a lot of phone numbers, either because they run up phone debt they can't pay, or because they deliberately change phones to avoid creditors. Consequently, on average, any recycled phone number you get will have one time been used by somebody with credit problems. Collection firms will then aggressively go through all the former numbers of a target and call you many times, sometimes in the middle of the night.

The way to fix this is to choose an area code without recycled numbers. In the United States, several new area codes are created every year for areas of the country that are growing, when they exhaust their existing area codes. Since long distance is free in the US, it doesn't really matter which area code you have anymore, so pick one of these new area codes for your number.

The way I did this with Project Fi was to first go to this website that documents new area codes. I then went to Google Voice to create a new number. I had to go about 10 area codes down the list to find one that Google Voice supports. I chose a number in that area, and to be certain, Googled it to make sure nobody had used it before. When I get my new Project Fi phone, the number will transfer over, becoming a real phone number instead of a virtual Google Voice number.

Thus, I get a virgin telephone number, albeit one from another state, rather than a recycled number that has been used by somebody else.

The main reason I'm getting a Project Fi phone is to hack it. The WiFi calling looks interesting, so I want to see how much I can mess with it, such as fuzzing the WiFi stack, or intercepting and decrypting my own communications. I suppose the Nexus 6 is necessary for the WiFi calling feature, but otherwise it should be possible to just stick the SIM in an iPhone. If anybody has any suggestions on what to play with, please tweet me @ErrataRob.