Not blogged much lately. However, there’s a whole bunch of stuff I’ve been up to that hasn’t been in any suitable condition to make public or that I just plain haven’t got around to yet. (Well, one or two thing, anyway.) It’s about time they got blogged, and that’s exactly what I’m going to do over the next week or so. First up is Cajeput.
There’s an interesting issue in SOSSE that prevents it from running right on some Atmega163-based smartcards if you just make the obvious changes to port it. The usual symptom is that the card ATRs correctly, but won’t listen to any commands.
Most of these cards connect the smartcard’s IO pin to both the normal pin PB6 and to an additional pin which SOSSE doesn’t use. SOSSE configures all the pins it doesn’t use as outputs and sets them HIGH during the startup code. This results in an additional and unwanted strong pull-up to Vcc on the IO pin, which prevents most smartcard readers from being able to pull it low and actually talk to the card.
The easy solution: open hal.c, find the lines that read:
and change the 0xFFs to 0x00s in these lines.
Will upload a patch and link it from this post when I get around to it.
If you’re not familiar with Funcards, they’re basically standard AT90S8515 AVR microcontrollers in smartcard format. Once upon a time, you could apparently use them for the legally dubious purpose of watching pay TV without paying. That’s ancient history, but they’re still a useful way of developing simple hobbyist smartcards. For example, you can install SOSSE or a modified version thereof on one. Plus, now that they’re outdated and not all that useful for illicit purposes, you can pick them up quite cheap.
Note that you can’t program the external EEPROMs on cards that have them with this software. (I don’t use the external EEPROM for anything, and so didn’t bother adding this feature.)
To make this work, you’ll need: a computer, a copy of avrdude, an Arduino or clone, a smart card socket correctly wired to the Arduino (see the comments in the source and the pin-out information on the SOSSE site), and a Funcard to program. Connect everything up, program the Arduino with this sketch, insert the Funcard, and use avrdude in avr910 mode to program it.
Don’t forget to reset the Arduino between Funcard programming runs – there’s some weird bug that means it won’t work unless you do.
Edit 23 Feb 2010: New version. Now I’ve removed some dubious local modifications of my own, you no longer need to reset the Arduino between runs and programming is also faster. Plus, I added the ATmega163 to the list of supported devices, and you can now program smartcards based on it too.
Having read today’s xkcd, I wonder how quickly the number of Google results for 1girl10000cups, 2girls(5+3i)cups, 65536girls65536cups, and 3frenchhens2turtledoves1cup will increase.
Edit: I’ve now backported the neccesary changes to v4l-dvb-makomk in order to make it compile on 2.6.24 (it was actually easier than I expected).
In case you haven’t noticed, both Markus’ v4l-dvb-experimental and my v4l-dvb-makomk are slowly dying. (v4l-dvb-experimental can be coerced to compile on modern kernels, but is old and unsupported;
v4l-dvb-makomk is worse, since it doesn’t even compile on 2.6.24). So what should you use?
- For non-em28xx based devices that use the xc3028 tuner, try http://linuxtv.org/hg/v4l-dvb/ – support for that tuner and probably most of these devices has been added to here. If there’s anything of this sort that v4l-dvb-experimental supports and v4l-dvb doesn’t, it should be easy to add, and there may even be another tree at http://linuxtv.org/ that does support it (e.g. http://linuxtv.org/hg/~mkrufky/cx88-xc2028/). Try asking on the appropriate mailing list. (v4l-dvb-makomk never supported any of these devices, so if you’re reading this you probably don’t have one.)
- For em28xx-based devices (what v4l-dvb-makomk supported), you have a choice:
you only want analogyou’re lucky, your device may be supported by http://linuxtv.org/hg/v4l-dvb/ – it even supports digital on some devices. You can find a list of supported devices here, though other hardware may work with some small changes – try asking the developers.
- You can carry on using v4l-dvb-makomk, though I can’t make any guarantees about what’ll happen when 2.6.25 is released. It should now work on 2.6.24 if it did on earlier versions, which for most hardware was the case. Please poke either me or one of the main linuxtv developers about adding support for your device to the main linuxtv driver.
- Finally, some hardware may require you using one of Markus’ driver versions. v4l-dvb-experimental is in a pretty bad state and getting worse, but there’s probably some hardware that’s not supported by anything else. Note that there’s no one driver version that I can recommend – they all have different caveats, and I don’t think there’s any one version that supports all the hardware that the rest do.
Scientology scares me. Then again, even the IRS seems to be afraid of them.
Well, that’s the Mercurial repositories back up. I think that should be the last of the public-facing stuff; the rest can wait.
Well, I managed to get my new VPS set up and working. Then random programs started segfaulting, to the point where it wouldn’t boot up. I pulled the affected programs off and ran clanscan over them – they were infected by the Linux.RST.B-1 virus. Shut the VPS down, started pulling the important data off via the web-based admin console, and went to check my e-mail. Hey presto – an e-mail saying that the provider had been getting reports of SSH brute force attempts from my box, sent at about the same time I’d started seeing issues.
Took a look at the logs, and there was a ssh brute force attempt followed by a successful login as root from a strange IP yesterday evening. I don’t login as root to ssh ever – in fact, I wasn’t even sure if it was enabled. Of course, this left the question of why the attack succeeded – sure, the VPS came with a horribly insecure root password, but I’d reimaged it and changed the password before ssh had even had a chance to start. Turns out the management software (HyperVM) had its own idea of what the root password should be, and automatically reset it to that on every boot. Since I don’t use the root password, I didn’t notice.
(The management software is interesting in itself. For example, it stores the root password in plaintext, and it inserts it into /etc/shadow using the ancient and not particularly secure DES-based hashing algorithm. I also wouldn’t like to make any bets on the security of the web administration interface in general.)
Finally got round to reinstalling WordPress after the bout of massive filesystem corruption that took out the last installation (along with the rest of the virtual server it was installed on). It’s only two or three months since then…
This time round, I used Debian’s package. I can’t be bothered to keep up with security fixes myself, so I’ll leave it for them to keep track of. After all, now that I’ve found that nice script for e-mailing me about pending updates to packages, I may as well make good use of it…