28 Mar, 09
Hier auf dem BarCamp Ruhr 2 gab es endlich Poken, der (nicht mehr ganz so) neue Visitenkarten- und Soziale-Kontakte-Ersatz aus der Schweiz. Als Early Adopter haben wir sie auch gleich mal ordentlich genutzt, und dann angefangen, sie zu hacken.
Kurz zur Funktion der Pokens: Ein Poken ist ein RFID/USB-Gerät. Hält man zwei Poken aneinander, wird (magnetisch?) ein RFID-Handshake ausgelöst, wobei die Poken-IDs ausgetauscht werden. Anschließend steckt man sein Poken an einen Rechner und ruft eine HTML-Seite auf, die auf die Poken-Webseite umleitet und Daten in der URL übergibt. Durch Tastendruck kann man außerdem einen “Discreet Mode” aktivieren, wodurch der Gegenüber keine persönlichen Daten erhält, bevor man sie explizit freigegeben hat. Auf einen Poken passen 64 Begegnungen, danach beginnt er, die ersten wieder zu überschreiben. Ich bin nicht sicher, was geschieht, wenn man Begegnungen schon übertragen hat, aber dann die 64 voll macht.
Erste Erkenntnisse:
- Die Verschlüsselung benutzt Blockgrößen von maximal 8 Byte (64 bit). “State of the art encryption” ist also etwas übertrieben.
- Nicht verschlüsselt sind die Poken IDs, weder die eigene noch die der Begegnungen.
- Jede Begegnung hinterlässt einen 16-Byte-Eintrag in der HTML-Datei
- Mehrfache Begegnungen werden auch mehrfach eingetragen
- Poken IDs haben 4 Byte
- Der Ghost Mode / Discreet Mode setzt lediglich ein Flag
- In der Begegnung ist ein Timestamp enthalten (3 Byte)
- Die restlichen drei Byte sehen zufällig aus (Checksumme?)
Scotty wies mich dann darauf hin, dass Didier Stevens in seinem “Poken Peek“-Artikel einiges davon schon beschrieben hat. Na gut, hatten wir halt Spaß beim Hacken.
Mehr morgen.
Update: Kathrin hat natürlich völlig Recht. Meine Formulierung war irreführend: Es ist Absicht, dass mehrfache Begegnungen geloggt werden, damit man eine Social Timeline bauen kann.
Update: Der Timestamp hat nur 3 Byte. Danke, Didier.
10 Apr, 07
Update: I forgot to mention that you must hack a core file and adapt your theme, too. See the end of the article.
Upgrading to WordPress 2.2 bleeding edge is an adventure, always. Not necessarily because they introduce new bugs—it’s the new features that are sometimes worrying. When one svn up changed all the feeds from somewhat-valid RSS to invalid Atom, I didn’t complain because, hey, it’s the bleeding edge, and Atom is so much better anyway. I just fixed the bug, and it was good. (In retrospect, I should have sent a patch. I forgot.)
Having tagging functionality in the WordPress core is a good idea, too. In general. Basically. However, if there already exists a widely-deployed tagging plugin—and for WordPress, one very much does exist—it may be a good idea to look at the functionality and semantics of the existing plugin before reinventing the wheel, badly.
UTW has a function named is_tag(). WordPress 2.2 adds a function of the same name. Ergo, things break. Renaming the plugin dir helps, but your tags are gone. Re-activating the plugin shows you the shiny new plugin sandboxing (which, btw, Habari started in January), but doesn’t bring you back your tags.
Some searching might point you to the UTW tags importer (Options > Import > UTW). After a funny message about deleting unwanted tags from the UTW management page (hey, no plugin, no options page, okay?), the import kinda works. The “Did we say 5 steps? We meant 4. Ha ha ha.” joke is getting pretty old pretty fast, though. Then, instead of the UTW_ShowTagsForCurrentPost() function, you use the_tags() in your template. Of course, the semantics of the_tags() are slightly different from those of the_category(), and completely unlike the old UTW functions semantics.
So I decided to get UTW back. Despite claims to the opposite, the changes required are actually pretty simple: open ultimate-tag-warrior.php and search for occurrences of is_tag(. Replace all occurrences with UTW_is_tag(. Activate the plug-in.
Update: Do the same in your theme - where you use is_tag() now, change it to UTW_is_tag(). Then, open wp-includes/rewrite.php, search for the function get_tag_permastruct, and add return false; directly after the opening brace. (This unbreaks /tag/ pages.)
Done.
04 Mar, 07
If you’re using the latest bleeding-edge SVN version of WordPress with Ultimate Tag Warrior, check your feed’s validity. WordPress is finally getting around to implementing Atom 1.0 instead of sticking with the comparatively ancient Atom 0.3 (even the validator’s support is deprecated).
Unfortunately, due to the way WordPress and UTW work, UTW doesn’t have a way to really know what kind of feed is requested — the hook it registers is called the_category_rss, and it’s called with a parameter that’s either ‘rdf’, ‘rss’, and sometimes blank.
Even more unfortunate is that the_category_rss is called when an Atom feed is requested. UTW happily inserts the hardcoded <dc:subject> tags into the feed, and since that’s been superseded by <category> in Atom 1.0, and WordPress doesn’t declare the Dublin Core namespace anymore, your feed has just become invalid. Fix after the jump.
To fix, open ultimate-tag-warrior-actions.php in your UTW directory, search for dc:subject, and change ultimate_add_tags_to_rss like this:
Replace the line inside the foreach that starts with $the_list with:
$the_list .= "\n\t<category term=\"". $category->cat_name . "\" />";
And replace the line starting with $format, after the foreach, with:
$format="<category term=\"%tagdisplay%\" />";
This is gonna break your RSS/RDF feed, but you should’ve switched over to Atom anyway, right?
It’s also pretty hacky to even build an XML document by string concatenation, but that’s not easily fixed. Don’t use characters in your tag names that would invalidate your XML, ok?
