Kinda works, but something’s still wrong with output voltages, hmmm…
Edit: Of course, a typo late in the night that became obvious in the light of the day. Output-enabled the wrong port. Doh!
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!
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 "$@"
This is not an advertisement – I’m just so amused I have to mention it. Look here. It’s basically a digital cookbook. And it’s rated 12+ because it mentions topics such as… alcohol! O tempora…
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() m
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) 6 CALL_FUNCTION 0 9 POP_TOP 10 LOAD_CONST 0 (None) 13 RETURN_VALUE
Post prompted by a colleague’s question.
So, Google is running an another edition of Google Code-In this year. I’ve been involved in its very first edition (called Google Highly Open Participation Contest) for the MoinMoin wiki project. Long story short, I volunteered to help this year too. It will probably be just one small task, but I’m looking forward to it anyway.