Converting unencrypted .VOBs to .DV files

What a great little app - I have one of those camcorders that shoots straight to DVD which is hugely convenient for showing people what you did that day (who can't play a DVD? You can't do that with a miniDV tape!) - and 8cm DVD-R's are so cheap you tend never to tape-over anything. But! iMovie, ExpressPro, Final Cut etc etc won't read .VOBs directly (well, iMovie '08 will, but not iMovieHD which I have on the home Mac).
Drop2DV doesn't seem to degrade the video (not so that I can tell) and it is quick - even though it is going between a long-GOP and iframe format - it has no GUI!

Windows XP SP3 & Parallels VM

As I mentioned a few months ago I ditched Vista after a year of really wanting to like it but being intensely frustrated at how unproductive I felt using it - staring at the spinning blue disk and finding my gigabit LAN behaving like a dial-up connection!

Anyhow - I've been rocking XP in Parallels on my MacBook Pro - XP runs faster in the virtual machine than Vista ever did on the metal! The only time I ever boot natively into Windows is for gaming (you'd not expect Halo to run well in an emulated environment!). A couple of days ago I upgraded to SP3 and although booting into XP directly showing no problems I realised that now my VM under OS-X was broken. So - I did what I should have done before starting(!) and read the release notes. The approved way to do it is;

• Boot XP directly and upgrade Apple BootCamp to v 2.1 here


• Install SP3 (again, booted natively into Windows)


• In OS-X upgrade to Parallels v 3 release 5600

I did it in the opposite order and found myself unable to even create a new working VM from my BootCamp partition. The solution;

• Once OS X boots and you are logged in, start Parallels, but DO NOT start the VM!


• Open your VM configuration, and select 'Hard Disk -> Advanced'


• Click on the "Clear..." button under the "Cleanup Boot Camp partition" section. This allows Parallels to 'learn' about the changes made by the SP3 install.


• Start your VM.


• Once the VM is started and logged in, *RE-INSTALL* the Parallels Tools!

Interestingly the guys who work for me in the Systems Integration deptartment at Root6 (the firm I work for currently) all use Parallels but the guys in Tech Support all use VMWare Fusion. I think the two are as good as each other. All of Root6's engineers run Intel Macs and the Sales guys all run Dell laptops.

Gaping hole opened in Internet's trust-based BGP protocol

My interest in BGP grows;

....Pilosov and Kapela, however, have found and demonstrated a way to intercept communication and then forward it back along to its original intended recipient. This is normally impossible; having established himself as the most direct router for a given address, any data the hijacker attempts to follow is promptly returned. Pilosov and Kapela bypass this issue by prepending the IP address they feed to certain routers. Prepending refers to attaching additional numbers to their own advertised route, in order to ensure that certain routers reject it. Once a router has rejected their address, the hacker feeds the data to be forwarded on to it. The data is processed and sent to where the router thinks it should go, which means it ends up forwarded on to its intended recipient.

XBox360 - multiple displays?

What a mission! My kids saved for nine months and between them bought a 360 - I'd always maintained that because we have a powerful PC a console is not needed but they disagreed! Anyhow - we have it connected to the living-room standard-def TV over RGB but there are occasions when Sarah and I want to watch the TV and nobody is using the PC next door in the dining room. The Dell LCD panels I have on the main family machine have several inputs - using the mighty Synergy is what I use for taking control of Sarah's Mac on the PC and by switching the right-hand monitor to the 2nd DVI input you can have a proper two-machine setup without all the laggy behavior of VNC/ARD. I also have the output of the MediaPortal PVR on another input of that right-hand monitor and so if I want to watch TV recordings full-screen (or window'ed - the Dells do that) I can.
So, with all these inputs I figured I could just take an HDMI output from the xBox and feed it into the LH monitor and because the controllers are wireless we'd be good - however - if the xBox sees two monitors (i.e. terminations on the analogue SD output - RGB) and the HD HDMI output it won't boot! No problem I thought - I'll just feed the YUV output (which is also available on the analogue connector) to the Dell - but no, all the TV outputs (Composite PAL, SVideo, RGB & YUV) are at the mercy of the frame rate of the game (typically 60hz for 90% of the titles) which the Dell won't display! They assume that 625-line signals are going to be 50hz and display an error message for all analogue inputs from the xBox for most games.
Hmmm - at this point I was starting to think it would be impossible to have two displays fed off the console if one was a Dell LCD monitor - however, help was at hand in my box of bits with an on Lindy video->SVGA convertor. This takes composite or SVideo and converts it to SVGA in a veriety of rasters - but it maintains the frame rate. It turns out that the Dells are entirely happy with 60hz SVGA (no suprise there!) and so I attached the Lindy (oh, it's a 32555 and still available) BUT the SVideo output of the xBox uses the same driver amps for the green and blue outputs as the Y and C (on the 4-pin SVideo connector) - so, if you hang an SVideo output at the same time as the RGB the screen goes a funny shade of Cyan on the RGB and very dim on the SVideo! Given that both connectors are there on the breakout cable this seems like a poor bit of design!

So - next step was to lift the 75ohm terminating resisitors in the Lindy box - colours all good now but some reflections present on both inputs while the Lindy box is powered. The eventual config was to use a remote mains switch on the Lindy controlled of my NetIOm remote system. An icon on the XP desktop switches on the Lindy, switches the left-hand Dell to SVGA input and routes the xBox audio to the windows mixer! All this automation is done with a MacroScheduler macro.

The SVideo -> SVGA adaptor produces a very usable feed and although is only standard def on what is an HD-capable display the kids are very happy to have a 2nd location to play xBox!

Channel Five installation on the cover of Broadcast Engineering

This is the install I designed and put in last winter - quite a good article (right-click > save-as the link above) but I don't even get a name-check! Oh well - I was quite pleased with how it all worked out!

DNS cache poisoning - the state of things!

After reading the excellent book on BGP that Kip got me I've been turning my attention more to how the internet works and the subject on everyone's lips at the moment is the problems with DNS that Dan Kaminsky discovered earlier this year. Traditional DNS-cache poisoning has been around for ages (I blogged an article from my institute's magazine back in 2005 - read it here). The aspect that made that kind of DNS spoofing not so much of an issue was that the window of opportunity that a hacker had to persuade a DNS server to point a domain name at an incorrect (i.e. compromised!) IP address was tiny - you had to get the fake DNS response in between the end of the record's TTL and the next time the server made a proper query. For that reason it was never a big deal.
The best explanation I've heard about the new attack was best summerised by the mighty Steve Gibson on this week's Security Now podcast;

LEO: ...you stated that the idea of debouncing spoofed DNS by requiring two identical query results had been aired but discarded because this would double the number of packets required for each lookup. Is that really true? The key point is to only allow changes to the DNS when they've been validated with a second query and reply. Each DNS server holds a cache of results from previous lookups. So it will only generate a new request in one of two cases: One, it hasn't seen the address before, boom, then you're going to ask again; or, two, the TTL, the time to live, has run out on the cached result. In this case a single request would be generated. If the result is the same as the cache, no second request necessary. If it has changed, then it would be verified with another request.

So what he's saying is you'd only have to make that second request if something seemed out of the ordinary or was a new address. Assuming that DNS records rarely change, the number of additional verification query packets related to TTL expiration would be very low. The question then becomes, how often are DNS lookups a complete cache miss, that is, no record exists, expired or not, because that's the only case when the 2x increase would occur. Is that often enough that you get a cache miss? Is it still a problem? So is he understanding the idea of debounce properly?

STEVE: Well, kind of. First of all, I liked his clever notion that, if a DNS name server had an entry in its cache which it was going to verify by asking again, then if it got the same answer, and we know that, I mean, the whole concept of DNS is that it's a distributed database, so chunks of the current mapping between domain names and IP addresses are able to float around on servers that only periodically check in to see if there's been any change. So that's a really nice tradeoff. It means that there's no, like, sort of central server that bears the brunt of everyone asking questions. But the tradeoff is that you don't get instantaneous updates in the event that an IP address changes. So, for example, I know you and I, Leo, have from time to time needed to change the IP address of a domain and there's this notion of it needing to propagate through the Internet. What that really means is that all spread around the world are, in locations where people have accessed a domain recently, there is a slowly expiring copy. And as long as it's not yet expired, then when questions come to that server, they'll be answered from the cache rather than going back and having to re-resolve it immediately. So it's a clever, beautifully clever solution. So he's noted that, in the event that a name server has some data in its cache, when it sees that it's expired it could only make a single query in order to verify that what's there is still current. And if the result it gets back is different, then that raises its suspicion that, oh, wait a minute, maybe I need to check this a few more times to increase confidence that I didn't get a spoofed response.
The one thing that this misunderstands, which is why I really liked the question, is that what it was that Dan Kaminsky realized was that you could force servers to make queries rather than waiting for their caches to expire. That was the brilliant gotcha that occurred to him. It used to be, I mean, if you - like three months ago, before this whole DNS spoofing nightmare arose, you could put DNS spoofing or spoofing DNS or something into Google, and you'd get pages and pages and pages. I mean, this notion of spoofing DNS is not new. But everyone believed that you had to wait for the server's existing cached record to expire, and then you could make - as soon as it expired, it's not going to replace it all by itself. It's going to wait for a query. And then, upon receiving a query, it checks the record to see if it's expired, thereby launching its own query out to resolve that name.

So the idea would be you would, you know, you bad hacker person would sit there, wait for the record to expire - because when you ask the server, it tells you how much time there is left remaining on that record. And that's a cool thing, too. If you think about it, it has to because then you might be caching that record, and you don't want to start at eight hours again. You want to understand how stale the record is so that your own cache will expire at the same time that the cache of the source of that record was. So anyone asking a DNS server - you can tell I've been living in DNS for a couple weeks, and I've really got this stuff now on the tip of my tongue. Anyone talking to a DNS server, querying it, knows how much longer it'll be before one of its records will expire. So they're able, as soon as that happens, that's when they launch their query to it, knowing that it's having to launch a query out, and then they rush their spoofed response back in. That's the traditional way. And that limited you to one shot at replacing a record, only every TTL interval. Which is typically one day. A standard Internet time to live for DNS is a day. So once a day you had a tiny window of opportunity. Clearly this wasn't a huge problem.

What Dan realized is you could ask it for a bunch of nonexistent machines in a domain, forcing it to constantly ask upstream for that domain's name server if this machine exists. And you could sneak in a response to that request that carried replacement name server records. And of course that's the nature of the attack. So Paul was right that, if we didn't have what Kaminsky realized happening, then you could do verification essentially in a cost-effective manner, only duplicating some queries if a domain was asked for that was not in the cache, and then only again if a verification that the IP had not changed from what was in the cache came back with a different answer. So I think Paul was clever, but that doesn't solve the problem that we've just had.

LEO: Could you rewrite the way DNS works so that you couldn't ask for these multiple updates? I mean, isn't that a bug, too?

STEVE: Oh, yeah. I mean, there's all kinds, well, I'm sure right now, Leo, there are firewall vendors, you know, corporate firewall vendors madly adding code to their firewalls, and they'll have new bullet points on their new brochures in a month saying "Special next-generation DNS spoof-proofing for your corporate DNS server." So there's all kinds of things you could do that would, I mean, make it really obvious that, you know, here comes a flood of responses in response to one query? Okay, that's wrong. I mean, it stands out like a sore thumb. But right now nothing is aware of that. So I'm sure there are - doubtless firewall vendors are madly rushing to get theirs to market first because essentially one query goes out and 10,000 come in. It's like, okay, maybe I'm going to ask that question again.

As mentioned previously OpenDNS suffers none of these issues and protects you from ISP snooping via the Phorm or NebuAD 'services'(!)

If you go back and listen to the last couple of Security Now podcasts you'll see that the thing that DNS server writers (who maintains BIND?) are going for is to increase the entropy in their DNS look-up requests (and hence DNS responses which is where the poisoning can be inserted) - Randomising the transaction ID and the UDP-port number means that the chance of the spoofed response being accepted drop but the real clever hack that requires no changing to the upstream DNS is the one Steve spoke about last week;

STEVE: This is the galactic hack. I don't know if I can think of something that is more a hack, more sort of like, oh my goodness, but clever. And so, I mean, this is the definition of a hack. And it works without any additional overhead, without any additional packets, without any additional anything within the existing infrastructure of DNS. So, and remember that, as I said toward the beginning of the show, what we want is more bits. The idea being, we want the query that the resolving name server sends out to contain more entropy, more bits of randomness which the responder will be able to easily send back, such as the matching query ID and the matching port number, but also something else. What more could it possibly send back within the existing definition of DNS? It's referred to as the 0x20, or the 0X20 hack. It refers to the 20 bit because that is the difference in an ASCII representation of text between uppercase and lowercase.

LEO: Right. You add that bit, and it's uppercase.

STEVE: For example, 41 and 61 are the hex for upper and lowercase A. The difference being that 20 bit. So get a load of this. The DNS spec, the original RFC that everybody wrote to and coded to and follows, says that case is not significant, but it will be preserved. Meaning that - and you'll notice this. You could do GRC.com in all uppercase, or GRC.com in all lowercase, or GRC.com in any random combination of upper and lowercase, and you'd get to GRC.com. And I notice that, like, TWiT.tv is capital T, capital W, lowercase I, capital T; right? And that works. The point is, case doesn't matter. But in a DNS query and response, case is preserved, meaning that when I issue a query, the response I get comes back with the same case of the alphabetic characters as I issued. Yet the authoritative name server that is checking to see if it's got a match within its records, it ignores the case, doesn't care if the alphabetic characters are upper or lower, to find a match. That gives us more bits.

LEO: Oh. That is clever.

STEVE: Oh my goodness, isn't that just incredibly cool? What it means is that the querying server can randomly upper and lowercase all the alphabetic characters in its query. So, you know, we've got www.domainname.com. So we've got, okay, www, there's three; com is three more alphabetic characters. Plus however many alphabetic characters are in the name. And more if you are several - if you have several domain, dotted domain names. All those characters can have a random case. They will go to the resolver that will - I'm sorry. They will go to the authoritative name server that will ignore your wacky casing that you've done.

LEO: Right, because it's case insensitive, yeah.

STEVE: But it will return your - it will return in its reply, it returns the same case that you sent it, which means you can - you the querier, who is trying to be spoof-resistant, can verify...

LEO: Oh, if it's the same one you sent.

STEVE: In addition to. So the domain name - basically the response echoes the query and adds the answers. So you get back what you queried as part of the answer.

LEO: Plus the dotted quad. But now if somebody's in the middle, if they're doing a man in the middle, they're going to see your randomly capitalized query. So can't they just copy it back?

STEVE: Oh, Leo, DNS is completely hosed by man in the middle. Man in the middle...

LEO: Oh, this doesn't protect against that. This - okay.

STEVE: No, no. In fact, man in the middle is a single query attack because if you're able to see the query and block the reply, you simply respond because you know exactly...

LEO: Okay, all right, all right. So this only is good against cache poisoning.

STEVE: Well, this is good - well, and which is the problem that we're trying to solve. This is good against a third party trying to guess queries in order to spoof replies. What this means is the query is now much more difficult to guess by the number of alphabetic, you know, two to the power of the number of alphabetic characters in the name being queried. So, for example, there could easily be 10 alphabetic characters - www and com gives us six. Seven, eight, nine, 10, so even a four-letter domain would give us ten additional bits. Well, 10, that's another 1,024 possibilities. So we've just added 10 bits of difficulty, looking up www and a four-letter domain, and many domains are much longer than that. So it's just, I mean, that is a hack. I mean, it's like, it's ugly, but it works.

LEO: So that's just something you obviously have to patch the DNS servers to do.

STEVE: You don't have to patch the authoritative name servers. That is to say, they're already programmed to echo the incoming packet's case and ignore the incoming packet's case.

LEO: Oh, so it only would have to be the querying servers you'd have to change.

STEVE: Right. So, I mean, just as we - we just changed the querying servers this month so that they would do reliable source port randomization. So we would just need to change them again if the decision were made or if anyone wanted to make the decision, or you could imagine this would be, you know, all this stuff is open source, in the case of BIND, for example. So you could have a BIND compile time flag saying I want this server to employ the 0x20 hack, and then your build of your BIND would issue queries with random alphabetic case on all the alphabetic characters, thus making itself far more difficult to spoof. And the beauty is it would automatically work with all the other servers on the 'Net that don't need to be changed. So this is something that individual, for example, BIND users, companies, ISPs, end-users, could easily do when this is an available compile-time or run-time option of BIND that just makes that one server much more resistant to spoofing.

LEO: Easy thing to add. But it would be a patch. You'd have to change the send, and you'd also have to remember that and the query and look at the result and make sure that they matched. But that's an easy compare. That's pretty fast.

STEVE: Right. So we're talking, exactly, we're talking additional code. Already obviously there is code which verifies that the incoming port and the incoming transaction ID match up with what's expected. So you just increase the expectation to verify that the incoming reply had case of its alphabetic characters that matched what you sent out, which is what you were expecting. Right now, no servers, as far as I know, care. So all you need to do is to add that they care about matching returning response case, and then randomize your outgoing case, and you've got a much harder to spoof server. Just you. You don't need anything of anybody else. Your server is now substantially more difficult to spoof.

Sorry to cut'n'paste so much from another source but Security Now really is essential listening if you are at all interested in the inner workings of the Internet.

Why work when you can have a meeting?!

I have been in some awfully boring and unproductive meetings. I think some of the worse reasons are:

• People like to blow their own trumpet - there are always people who enjoy the sound of their own voice more than actually getting things done.


• Implied responsibility transfer - I worked on a project a few years ago where the customer's project manager would get all the subcontractors together once a week and for hours (really - often four hours or more!) every trade had to explain what they'd done that week and how it impact the project. I think he hoped that any conflicts would magically be resolved because everyone would in part be responsible. The only outcome was that the only people who attended were those who weren't working hard on the site!


• If, like me, you're not very vocal with people who's discipline isn't yours (broadcast electronics in my case) then meetings are a terrible way to transfer knowledge. I end up not saying much (when perhaps I should) and the manager/bean-counter/sales-person talks a lot more and nobody gets the info they need.

Anyway - some of this is covered superbly in Oliver Burkeman's column from today's Guardian.

Almost everyone hates meetings, and yet the idea of doing away with them is seen as revolutionary, or ridiculous. Jim Buckmaster, chief executive of the hugely successful website Craigslist, has a simple policy - "No meetings, ever" - but if you're a manager, you're probably already thinking of reasons why you couldn't do the same. An important new book, Why Work Sucks And How To Fix It, proposes a total shift in how we think about office life, but one part is considered so startling, it's singled out on the cover: "No meetings." Senior executives find at least half of all meetings unproductive, studies show. Yet still they happen. "Meetings," writes the humorist Dave Barry, "are an addictive, highly self-indulgent activity that corporations and other large organisations habitually engage in only because they cannot actually masturbate."

Why Work Sucks And How To Fix It reports on an experiment I mentioned here during its earlier stages, at the US electronics chain BestBuy: a "results-only work environment", in which staff could work where and when they liked, so long as their jobs got done. The first casualty was meetings. "Why do we spend so much of our business life talking about the business we need to take care of?" the authors write.

There are several reasons why meetings don't work. They move, in the words of the career coach Dale Dauten, "at the pace of the slowest mind in the room", so that "all but one participant will be bored, all but one mind underused". A key purpose of meetings is information transfer, but they're based on the assumption that people absorb information best by hearing it, rather than reading it or discussing it over email, whereas in fact, only a minority of us are "auditory learners". PowerPoint presentations may be worse. The investigation into the 2003 Columbia space shuttle disaster, caused by a fuel tank problem, suggested that Nasa engineers might have been hampered in addressing it sooner because it was presented on PowerPoint slides, forcing the information into hierarchical lists of bullet points, ill-suited to how most brains work.

The key question for distinguishing a worthwhile meeting from a worthless one seems to be this: is it a "status-report" meeting, designed for employees to tell each other things? If so, it's probably better handled on email or paper. That leaves a minority of "good" meetings, whose value lies in the meeting of minds itself, for example, a well-run brainstorming session.

Countless books advise managers on how to motivate staff. But motivation isn't the problem. Generally, people want to work; they gripe when things like meetings stop them doing so. Indeed, a 2006 study showed there's only one group of people who say meetings enhance their wellbeing - those who also score low on "accomplishment striving". In other words: people who enjoy meetings are those who don't like getting things done.

My boys and their music

Joe and Dan have been doing some music at the EC1 project here in Islington. Our local council paper ran a feature on them here.

Use right-click & save to grab the PDF