Seasick Steve

I've just downloaded his album (from 7Digital - all MP3!) and I'm loving it!

TriCaster - very impressive

Earlier in the year I banged on about the TriCaster after I had a demo. We've just finished an install at the College of Law using it as the centre-piece of their little three camera studio and I am even more impressed than I was! Driving the virtual environment is so easy and it really does perform well. Having a selection of four shots per camera (you set the shot for the close-up and then each camera is available as the close-up, MCU, twp-shot and long-shot) with an environment that tracks perfectly is a revelation. The in-set virtual monitors work as well. The perspective and reflections on desks etc are all very convincing and once you get past the fact that all the virtual sets look like CNN or ESPN you can really produce some expensive looking tele.

I hope Root6 pick this up as a product because there is nothing to match it sub £100k.

Interesting

I picked up this flyer in Borders yesterday - it's the first time I've seen this in any kind of retail outlet, let alone a book shop;

Customers can choose from items in an e-catalogue or an instore printed version. Once purchased from the console, the software is pressed onto a disc with a special inlay card and user manual. The entire process is planned to only take a few minutes.

I got a GoogleWhack!

Whilst searching for details of some monitors I have to calibrate later this week!

Adeona - stolen laptop tracker

I installed Adeona on my MacBook Pro over a week ago and promptly forgot I had it on there - it consumes little processor time and you're unaware of it. What is does is continually send photos from the iSight camera and any useful info - IP, nearby DNS servers, router names etc - basically anything to help physically locate a stolen computer. Best of all it's open source and the OpenDHT storage it uploads to is 256-bit encrypted.

BBC64 camera line-up 'chip-chart'

I'm at the studio build today setting up camera channels and doing general line-up. We've supplied the good-old BBC64 camera chart which I used to spend many happy hours staring at whilst lining-up cameras for studio/OB shoots. When I die (and they lay me to rest....) I want this and Test Card F on my gravestone!
The info sheet has all the reflectance figures and frequency gratings for when you have the camera focused full-frame on the chart.
Oh, does anyone know why the light-trap in the middle of the chart is called a Gregory Hole?
Also - ex-BBC type, can you still get hold of Cardboard Kate?

Fibre patch cords protected with Copex

A facility that we're just finishing has a lot of tight-buffered patch cords running between four bays (twelve Avids with SAN attachment and DVI extenders) - since it's impracticle to run loose-tube cable in such a restricted space Simon came up with this method of running the fibres through Copex and under the bays, breaking it out at the height of each pair of workstations - a very good solution that I'll use every time!

Cheeky cheeky!

I've just been finishing off a studio build at The Law College - I chose a Yamaha 01v96 as the audio mixer - it has loads of ins and outs and very controllable. They didn't want to go for a full-blown talkback so I used a couple of ins for the director's open and switched mics and a couple of the spare Aux'es to feed the wallbox foldback feeds (the interviewer's earpiece and the floor foldback wedge). For the director's desk I had the metalwork dept at Bryant make me a panel with a mic on it and talkback key so that the director can key the mic and talk to the whole studio over the floor foldback but the interviewer's earpiece always gets the feed. You could also send a mix of the playback out of the wedge so that the studio crew get in the mood(!).
Anyhow - a combination of a mic that wasn't very sensitive and the general noise in the control room meant that the earpiece feed was a bit noisy and possible distracting to the interviewer.
The solution - the 01v96 has a noise gate and compressor per main input channel - I stuck a gate set to -50dB on each mic input (the open and switched feeds) and all was good. On one hand it seemed a bit naughty to use a noise gate but on the other hand it worked brilliantly!

Sorry to not be blogging so much at the moment - I'm working late most nights to stay on top of my day-job.

Nice cat5 SVGA extender

I've used several SVGA over cat5 extenders to send Tektronix rasteriser displays around buildings (typically the unit sits in the MCR and the display is in the suite). This is the best little combo I've found so far for the job - good quality (the Tek is only 1024x768) and it has a DA built in so you can have a local display (for the tape op) and the remote display hanging off the small unit.

Burning DVDs for TV replay

For the longest time I've been using Nero Vision Express v.3 (it used to come with v.6 & 7 Nero Burning ROM) as it is a very simple way to make menu-driven DVDs and not bad at transcoding whatever files you throw at it. In the case of .dvr-ms files (the MPEG2 transport stream container format used by most PVRs including MediaPortal and Microsoft MCE) it would only re-encode the video packets if they were non-compliant (i.e. ITV or Channel Four!). My only criticism is that it's pre-set templates look poor compared to iDVD (for example).
For menu-free DVDs I used DivXtoDVD (which despite the name does many formats) to create a VIDEO_TS folder. Very clean transcoding.
For manipulating ready-made DVDs (either off the disk or from a VIDEO_TS folder on your HD) I find DVD Shrink to be superb.
Anyway - WindowsXP SP3 kills Nero Vision Express so I've been looking around for an alternate and I think I've found the answer - and it's open source! DVD Flick is where it's at (link in the title).

My birthday and the LHC gets booted-up!

...and the BBC's programmes were superb - click the title link.

The Wrekin and other transmitters

ON Wenlock Edge the wood’s in trouble
His forest fleece the Wrekin heaves;
The gale, it plies the saplings double,
And thick on Severn snow the leaves.

I few years ago I took the kids climbing up The Wrekin in Telford. When we got to the top we found the Wrekin transmitter which serves Shropshire and a lot of the Welsh borders. I remember as a teenager being puzzled that the picture on my parent's new TV was so bad when I could see this mast from my bedroom window. It wasn't until (having unplugged the Belling-Lee connector from the back of the TV) I tried a small PO-1 screwdriver and got perfect pictures I discovered how demodulators in TVs can be over-driven! A 24dB RF pad sorted out our problem.

Anyway - although I only did a couple of weeks in transmitters during my BBC training in the eighties I did find it immensely interesting and so you can learn a bit more at the MB21 website.

Jailbreaking & unlocking v 2.0.2 iPhone

What a jolly kind fellow Kevin King is - The product manager for ContentAgent (the encoding machine made by Root6 - the firm I currently work for) - his blog and Flickr - donated his v.1 iPhone to Joseph (my eldest) and of course I had to re-pave, update, jailbreak and unlock (for use on Orange).
So - don't pay for this service. There are numerous companies offering to do it for twenty or even thirty quid and it's all on the web. The tool you need is WinPwn (it easiest if done from Windows) and I've packaged it all into a ZIP archive here along with a PDF explaining it all.

The official Apple firmware (which WinPwn modifies for your handset) is here.

London at night, aerial pictures

Not technical - but some great photos of my beloved home town!

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.