Oct 062011

I recently bought a DE0-nano FPGA development board, which I’m currently using to mine Bitcoins. It’s kind of a neat board, but one downside to it is that it uses linear regulators to provide the 1.2V core supply to the FPGA, and they’re incredibly inefficient at this. Only about 25% of the power supplied to them actually goes into the 1.2V supply; the other 75% is wasted as heat in the regulators. Since Bitcoin mining is very power-hungry, an awful lot of the power usage is in the 1.2V core supply and the regulators get really hot.

Fortunately, it’s possible to mod the board to use a more efficient external buck regulator to supply the 1.2 volts required by the FPGA core logic. (In theory this should even allow USB-powered mining; in practice this doesn’t seem to work for some reason.)
Continue reading »

 Posted by at 8:16 pm
Apr 132011

A while back, I picked up a bunch of 4 assorted smartcard programmers off eBay. A CLaNZeRS Phoenix/Smartmouse version 2.1 with at least one bad solder joint and no crystal in its socket, a CLaNZeRS MCESDK that requires Windows-only software, something with “TITANIUM www.smartchips.co.uk” on the bottom that appears to be for PICs, and the aforementioned Zeus programmer.

Of them, the Zeus seems to be the nicest from my point of view. There are two catches though: it requires a 15-18V center-positive power source and my regulated PSU tops out at 12V, and mine seems to have a 6MHz oscillator installed rather than the usual frequency (yours may vary). Oh, and documentation is severly lacking.
Continue reading »

 Posted by at 4:47 pm
Mar 152011

OK, didn’t post as many things as I’d have liked, partly because they required masses of cleanup and partly because I finally figured out an easy way to do something I’d been puzzling over for a while: encrypted webcam chat. (Your definition of “easy” may vary.)

What does it do?
It allows two people with webcams to conduct a secure video chat with each other, complete with audio. The connection is encrypted, authenticated with a shared secret so you know you’re connected to the right person, and in theory has perfect forward secrecy.

What’s the catch? Continue reading »

 Posted by at 5:49 pm
Feb 282011

I’ve been having a fun time trying to use VLC’s official Python bindings on 64-bit Linux, and by “fun” I really mean “swearing as pointers get truncated to 32 bits and my app segfaults”. Anyway, turns out the bindings are broken. They make use of a ctypes (mis?)feature that allows you to pass a Python callable as the return type of your function and have ctypes call that function with the actual value and return the result. This is used to make various libvlc_*_new functions wrap the pointer they return in an appropriate Python class.

Unfortunately, there’s a catch. As the docs say, “You can also use a callable Python object (a function or a class for example) as the restype attribute, if the foreign function returns an integer. The callable will be called with the integer the C function returns, and the result of this call will be used as the result of your function call.” A pointer is not an integer, and on 64-bit systems doesn’t fit into one. Worse still, there doesn’t seem to be a way of changing this behaviour – this bad assumption is baked into the lowest layers of ctypes.

Edit: Have managed to fix this issue and put a GIT repository up. You can download the generated vlc.py here. (For some reason, the diff for vlc.py is horribly messy; dunno why.)

 Posted by at 12:22 pm
Feb 252011

Hmmmm. Kinda got distracted and didn’t post as much as I should’ve. Anyway, the next thing is an ISO-7816 smartcard interface based on the Arduino.

What is it?
This Arduino sketch lets you talk to some ISO-7816 smartcards that use the T=0 protocol at the usual baudrate and with the direct convention – in other words, quite a lot of them. In particular, it lets you speak to smartcards you’ve developed yourself using the open source SOSSE framework. It uses the same pinout as the Funcard programmer, so you can use the same hardware to program the cards with SOSSE as you do to communicate with them.

What’s the catch?
It only supports the T=0 protocol with direct convention, and only at one particular baud rate. It uses interrupts and timers in a very low-level way, which also means that you can’t easily change what pin is used for what. The protocol it uses to speak to the computer is oddball, and you need to write your own software to understand it… for now. It has very little intelligence, leaving the host PC to do most of the work.

Where do I get it from?
You can download it from here for now.

 Posted by at 7:50 pm
Feb 222011

What is it?
Cajeput’s the server end of a virtual world, written in C++ and intended to be vaguely compatible with OpenSim (which makes it a clone of a clone of Second Life). It’s actually surprisingly lightweight, especially compared to OpenSim!

What’s the catch?
Basically, it’s horribly unfinished. There’s a whole bunch of stuff that’s just not implemented yet or is incomplete. It’s also meant to be usable with the OpenSim grid servers (because on its own, it can only run as a standalone install running on a single server), but this doesn’t work anymore due to OpenSim changes. Finally, it’s horribly undocumented and a bit of a pain to set up.

I don’t care about that, how do I get it?
Continue reading »

 Posted by at 6:35 pm
Feb 212011

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.

 Posted by at 5:22 pm
Mar 172010

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.

Uploaded the patch here. It also fixes some compilation issues on newer avr-libc versions

 Posted by at 11:57 am
Feb 042010

Some months ago, I hacked up some existing Arduino-based AVR programming code (avr910_ard.pde) in order to program Funcards with it. You can download it here.

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.

 Posted by at 4:25 pm