Disabling PayWave

A short follow-up to my previous post about disabling PayPass antennas: here’s an x-ray of a Visa card issued by BZWBK in Poland. Next step: disabling it. I’ll try to think of something less invasive than previously.


R.I.P. PayPass (mBank)

We recently got issued a PayPass-enabled debit card. Not that we wanted one, no. But there seems to be a crazy push for wireless payment going on in Poland and it’s getting hard to get a card without it (or PayWave). Given the security concerns of these solutions (remote cloning), I decided to give it a go and try to disable PayPass while keeping other functions working. Turns out there’s a cheap and fairly reliable way to do it and it involves… x-rays. And drilling. 🙂

Here’s what the card I got looks like internally:

You can clearly see where the chip is, how the antenna is connected to it and where it goes on the card. Since it’s basically an RFID chip, it requires an external power source to function. In this case electrical current is inducted in the antenna. In theory it should be enough to break the loop to disable wireless payments. Why not drill through it, then? 😀

The card was tested to work OK in ATMs, POS terminals and wirelessly before any changes were made to ensure that it’s the changes that disabled it, not chance. I decided to drill two 3mm holes through it, just to make sure, and here’s what it looked like after the operation:



As you can see I’ve messed up a little bit and drilled right through the magnetic stripe, but it still works! ATMs, POS terminals do, PayPass… doesn’t. Mission successful!


Getting Atom Zombie Smasher to run under Ubuntu 12.04

There’s a number of forum posts asking for help with Atom Zombie Smasher crashing after the loading screen with recent versions of Linux distros on the Internet, but I’ve been unable to find one with a solution – so here it is.

In short, there seems to be a race condition somewhere in the initialization code that makes the process terminate in xcb code. Not having the sources available, my solution was to set the game’s CPU affinity to just one core, thus greatly reducing the chances of the crash. It’s quite reliable (9/10 I’d say), but don’t be surprised if it does crash on some attempts!

To apply the “fix”, change the last line in the data/atomzombiesmasher script to:

MONO_LOG_LEVEL="debug" taskset 0x00000001 ./mono ./release.exe "$@"

Good luck!

“private” methods in Python

Python supports semi-private methods through a name mangling trick. The interpreter transforms method names starting with two underscores by prepending it with the class name and some additional underscores, so it becomes impossible to call the method by its original name. Here’s an example:

>>> class T(object):
... def __m(self): pass
>>> t = T()
>>> dir(t)
['_T__m', '__class__', '__delattr__', '__dict__', '__doc__', '__format__', '__getattribute__', '__hash__', '__init__', '__module__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__sizeof__', '__str__', '__subclasshook__', '__weakref__']
>>> t.__m()
Traceback (most recent call last):
 File "<stdin>", line 1, in <module>
AttributeError: 'T' object has no attribute '__m'

It is still possible to call the method using its mangled name.

Fortunately, one can still use the original name from within other methods of the same class:

>>> class T(object):
... def __m(self): print "m"
... def public(self): self.__m()
>>> t = T()
>>> t.public()

It works because bytecode generated for this method uses the mangled name:

>>> import dis
>>> dis.dis(t.public)
 3 0 LOAD_FAST 0 (self)
 3 LOAD_ATTR 0 (_T__m)
 10 LOAD_CONST 0 (None)

Post prompted by a colleague’s question.