Sie sind hier: Startseite / Blog

Blog

decompyle is still alive

I just got a call from somebody who tried to get an ancient version of decompyle running. Some words about he status of decompyle.

Yes, decompyle, the Python byte-code decompiler, is still alive and functioning. It simply is not longer available for download and ancient versions are not able to decompile recent Python byte-code.

Still alive: My Decompyle Service

To be frank: I recommend using the my Python decompyle service at crazy-compilers.com. It's cheap, its fast, it's reliable. Don't waste your time with ancient versions, see below for reasons.

The future of decompyle

At the very moment I'm working on a complete rewrite of the decompyle-engine as the currently used spark parser got to it's limits. This will allow support for Python 2.7 and 3.x soon. The first bucket of test-patterns for 2.7 just passed an hour ago.

Ancient Versions floating around the Internet

When searching the Internet, you may find old tarball or even Subversion-Repos of decompyle at approx. version 2.3. You may get it work on your recent system, but you may need to spend quite some time, as it contains C extension modules. But I do not recommend wasting your time trying to get this run: it will not be able to decompile recent Python byte-code.

You may even find some sources saying to have a patched or enhanced or further developed version of decompyle. You may have tough luck and one of these variants may really decompile our file. But chances are very low (I do not bother trying it). From Python version to version there have been too many changes to the byte-code: Starting with simple stuff lik

  • changing the "magic number" written into each byte-code file,
  • code-optimizations which make the (old) parser fail,
  • new features like generator-expressions, decorators, conditional expression or the `with`-statement, up to
  • changed and new byte-codes.

Summary

Don't wast your time, but simply use the decompyle service.

11.04.2012 18:40

Neues aus meiner Toolbox: Webseiten "wie sie sind" als PDF speichern

Alle, die einen "Screenshot" der Webseite als PDF machen wollen, können das brauchen.

Wer schon einmal versucht hat, Webseiten als PDF zu speichern -- und zwar so, wie sie am Bildschirm erscheinen --, kennt das Problem: es geht nicht. Entweder kann der Browser gar kein PDF erzeugen, oder man kann nur "als PDF drucken". Beim Drucken bekommt man aber die Druck-Ansicht, und nicht das, was am Bildschirm steht (zum Hintergrund unten mehr).

Meine Software erzeugt ein PDF, das den Bildschirminhalt wiedergibt (so wie links zu sehen).

Screenshot einer Webseite Gleiche Webseite ausgedruckt
So sieht die Webseite am Bildschirm aus
Und so der Ausdruck

Das kann die Software:

  • Erzeugt ein PDF einer beliebigen, öffentlichen Webseite
  • Das PDF ist durchsuchbar, enthält also noch den "Text" (und nicht nur ein Bild vom Text)
  • Fast alle Webseiten lassen sich gut darstellen, denn als Render Engine wird die gleicher verwendet, die auch in Safari steckt (Webkit)
  • Die Webseite wird automatisch auf die Seitenbreite skaliert
  • wenn die Webseite zu lang für ein Blatt ist, werden mehrere Seiten erzeugt
  • Seitenformat, -ränder und -orientierung können angegeben werden
  • Firefox-Addon: 1 Klick und das PDF wird geliefert
  • In zwei Varianten nutzbar:
    • kleiner HTTP-Server, der die Umwandlung übernimmt (den verwendet das Addon)
    • Kommandozeilen-Tool
  • kann leicht an die Bedürfnisse der Kunden angepasst werden, beispielsweise
    • andere Seitenaufteilungen, andere Dateiformate
    • Integration in komplexere Tools (siehe Successtory unten)

Die Software ist plattformunabhängig (Linux, Windows, Mac), benutzt Qt und Python.

Vergleich mit Alternativen

Alternative 1: Für Firefox (und wohl auch andere Browser) gibt es Add-ons, die die komplette Seite in ein Bild packen. Sie greifen dabei auf der "Bild" zurück, das der Browser intern von der Seite erstellt hat. Vorteil: es wird das ausgegeben, was momentan im Browser angezeigt wird, also auch private Seiten.

Nachteile diese Alternative

a) Ein Bild lässt sich schlecht auf mehrere Blätter aufteilen,

b) man bekommt ein Bild, also eine Ansammlung von Bildpunkten. Das Bildschirmfoto ist nicht durchsuchbar.

c) Je nach Addon muss man viel klicken

Alternative 2: "Drucken als PDF" scheidet aus, da die Druckansicht gewählt wird.

Alternative 3: Bestehende Online-Dienste, davon gibt es einige, ein paar habe ich ausprobiert, die haben nicht überzeugt. Teilweise nicht zuverlässig erreichbar, teilweise muss man zu oft klicken. Oft ist das Papierformat fest auf "Letter" eingestellt. Das druckt sich gar nicht gut auf A4. Und man muss Dritten vertrauen (ggf. Auftragsdatenverarbeitung, BDSG ist zu beachten).

Successtory ;-)

Mein Kunde setzt das Tool seit einem halben Jahre bei der Medienbeobachtung ein, auf zwei Arten:

  1. Findet ein Mitarbeiter eine interessante Webseite im Netz, wird diese mit einem Klick als PDF gespeichert.
  2. Ein Ausschnittdienste schickt interessante Links per Mail. Diese Mail werden automatisch ausgewertet und die PDFs an die Mitarbeiter geschickt -- zusammen mit einem Vorschaubild und den Infos aus der Mail. (Das Ganze ist eine Erweiterung des Kommandozeilen-Tools.)
  3. [Nachtrag] Die Mail-Schnittstelle kann inzwischen auch Mails auswerten, die nur Links enthalten. Die nötigen Meta-Informationen (für welchen Kunden, etc.) werden dem Betreff entnommen. Letzterer muss dafür natürlich einem bestimmten Format entsprechen.

Hintergrund

Das Phänomen kennt Ihr: Ihr wollt eine Webseite ausdrucken, und das Ergebnis sieht völlig anders aus, als das am Bildschirm. Diese Mail erklärt, weshalb das so ist und zeigt, was man dagegen tun kann, ohne fünf Bildschirmphotos zusammenkleben zu müssen.  Und sie zeigt eine Lösung als PDF, das man dann durchsuchen kann?

Die Ursache ist: Für den Ausdruck verwendet der Browser eine eigene "Formatvorlage" (ein sogenanntes Cascading Style Sheet, CSS). Idee Idee dahinter ist: Wer die Siete ausdruckt, will keine Navigation, keine Werbung, etc. Also werden solche Elemente in der Formatvorlage für den Ausdruck auf "nicht anzeigen" gestellt.

Dabei ist es egal, ob Ihr auf einen physikalischen Drucker druckt, oder mit FreePDF, PDF Creator oder ähnlichem ein PDF erzeugt. Für den Browser ist das alles "drucken", als verwendet er die Formarvorlage für "Drucken".

Früher hatten Webseiten dafür eine Link "Druckansicht". Der ist heute ziemlich ausgestorben, weil die Browser die Formatvorlagen für den Ausdruck verwenden, und da sich Content Management Systeme verbereitet haben, die solche Vorlagen schon mitbringen.

Wer dennoch ein "Bild" der Webseite haben möchte, muss ein Bildschirmphoto machen. Mit den Bordmitteln der Betriebssysteme bekommt man damit aber immer nur einen Teil der der Seite auf ein Bild -- soviel der Browser halt auf einem Bildschirm anzeigen kann. Blöd, wenn der Inhalt der Seite über drei Bildschirme geht.

Interesse?

Wenn Sie das Produkt für Ihren eigenen Bedarfs nutzen wollen, mache ich Ihnen gerne ein Angebot. Setzen Sie sich dazu bitte mit mir in Verbindung.

 

20.03.2012 23:00

rsync "protocol incompatibility" caused by --dry-run

I just spend approx. one hour to track down a nasty problem, caused by using ssh with authorized keys and forced command. This is for the records and hopefully will help others to solve the problem ...

When trying to move a working script to a different machine and a different user-account, my rsync-script failed with this message:

rsync error: protocol incompatibility (code 2) at io.c(1332) [sender=3.0.8]
rsync: connection unexpectedly closed (2668 bytes received so far) [receiver]
rsync error: error in rsync protocol data stream (code 12) at io.c(601) [receiver=3.0.7]
rsync: connection unexpectedly closed (70 bytes received so far) [generator]
rsync error: error in rsync protocol data stream (code 12) at io.c(601) [generator=3.0.7]

Now in this special constellation, there are many possible reasons, since the machines are quite different:

Server: Fedora 13, x86_64, openssh 5.4p1, rsync  version 3.0.8  protocol version 30

Old client: Mageia 1, i686, openssh 5.8p1, rsync  version 3.0.8  protocol version 30

New Client: Debian Squeeze, armv5tel, openssh 5.5p1, rsync  version 3.0.7  protocol version 30

To make a long story short: The error message is absolutely misleading. The error is not caused by a protocol incompatibility, but simply by my forced command. And the error is simply triggered by using --dry-run.

Explanation

When running rsync with --dry-run, obviously the command, which is send to the server, differs. Now the SSH-Server drops the connection, since the received command does not match the forced command. rsync get communication errors which it is misinterpreting and talking about "protocol incompatibility".

23.02.2012 19:14

Neues aus meiner Toolbox: pdfjoin-Droplet

Ich habe ein Programm pdfjoin erstellt, das PDF-Dateien bequem aneinander hängen kann. Das Programm kann auch als "droplet" arbeiten.

Was ist das Besondere?

Mit meinem Tool braucht man das PDF nicht zu öffnen oder sich mit einem "Split and Merge" Programm beschäftigen. Einfach die PDFs der Reihe nach auf das Icon werfen und auf dem Desktop erscheint ein neues PDF.

Das Zusammenhängen geht zwar auch über die Druck-Funktion des PDF-Readers, aber dazu muss man das PDF erst öffnen und und dann drucken. Und unter Windows braucht man einen Pseudeo-Drucker, der PDF erzeugt und "multidoc" beherrscht (z.B. FreePDF). Das ist einfach umständlicher.

Was ist ein Droplet?

Der Begriff droplet stammt aus der Apple-Welt. Es bezeichnet ein Programm oder Skript, das eine bestimmte Funktion ausführt, wenn man ein anderes Icon auf das Icon des Programms zieht und dort fallen läßt (eben "to drop").

Geht es auch anders?

Ja, das Programm läßt sich auch mit Parametern über die Kommandozeile ausführen.

Für welche Plattformen?

Wie bei mir üblich, ist das Tool plattform-unabhängig in Python geschrieben. Den Quelltext gibt es unter https://gitorious.org/pdftools/pdfjoin. Einen Windows-Installer und ein ein OSX-Bundle kann ich bei Bedarf erstellen.

16.02.2012 18:24

Seitenlänge eines Monitors bei gegebener Diagonale

Bei Monitoren wird immer nur die Bildschirmdiagonale und die Auflösung oder das Seitenverhältnis angegeben. Diese keine Python-Funktion berechnet daraus die Breite und Höhe des Bildschirms

from math import sqrt
"""
Basierend auf <http://www.mediengestalter.info/forum/29/seitenlaengen-diagonale-monitor-106559-1.html>
"""
def seitenlaengen(diag, w,h):
    w, h = map(float, sorted([w,h], reverse=True))
    b = sqrt(diag**2 / (1+ (w/h)**2) )
    a = (w/h)*b
    return round(a,2), round(b,2)
01.02.2012 11:16

Preferring git over mercurial

Being a Python programmer, my favorite distributed version control system (DVCS) was Mercurial (hg) -- was until a few days ago. Here are some reasons why I now prefer git.

Mercurial was my favorite since it is written in Python, which is my preferred programming language (more precise: the only Programming language I use unsolicited).

Until now, I had bad experiences with git: I'm urged to use git on other projects and I often stumble over things that do not work as I expect or are described in a way I do not understand or is much to complicated. Whenever I try to learn how to select revisions from `man gitrevisions` I get enervated.

As you may know, I'm involved in the development of PyInstaller where we are currently migrating from Subversion to git. The project's founder, Giovanni Bajo, made me looking deeper into git. I'm still fighting with some of it's rough edges, but I'm really impressed: It has much more power-features than mercurial has.

gitk

At the beginning  was missing `hg serve`. But then I discovered `gitk` -- a GUI front-end for history browsing. Meanwhile I'm used to it and prefer it over the web-based `hg serve`. One can search messages, authors, commiters, focus on one or several branches, easily jump to tags, directly display the changes in several diff-formats, and a lot more. And all commits are on a single page, no need to browse through page over pages.

git gui

The next killer app is `git gui`, a tool for preparing your commits.

I often find myself committing to large changes, since I did several smaller changes until I mind to commit. With `git gui` these is solved elegantly: One can select which part of the current changes are to be used in the commit, even include or exclude single lines. At the very moment, I'm splitting my hacked version of reposurgeon into small commits so somebody else can reproduce what I've done. You can see the result at https://github.com/htgoebel/reposurgeon: All commits until today midday have been created this way.

And another plus: Commit message entered within `git gui` are spell-checked. The language can be selected either globally or per project.

Summary

So for new projects, or when migrating my existing projects to DVCS, I'll choose git. It has the far superior tools.

28.12.2011 11:50

Website des (ISC)² Chapter Germany e.V. ist online

Seit ca. April 2011 haben sich CISSPs und anderen (ISC)²-Mitglieder in Deutschland zu einem Chapter, also einer regionalen Verband, zusammengeschlossen. Das Ziel des (ISC)² Chapter Germany e.V. ist es, das Verständnis und die Bedeutung der Informationssicherheit zu fördern.

Mehr dazu direkt auf der Website des Vereins.

Die Website wird übrigens von mir gesponsert.

10.10.2011 00:00

Write error with twisted plugin cache

I'm just toying around with some Python program which uses twisted and twisted plug-ins. I hot errors since twisted wants to write a cache file into /usr/lib/python2.6/site-packages/, which a normal ...

If twisted is not installed properly by you distribution, you will get errors like

exceptions.IOError: [Errno 13] Permission denied: '/usr/lib/python2.6/site-packages/twisted/plugins/dropin.cache.new'

In this case you need to (re-) build the twisted plugin cache by running as root:

python -c 'import twisted.plugin as P; list(P.getPlugins(P.IPlugin))'
19.06.2011 14:07

Ein Mini-Webserver für die linuxrc

Für das bereits erwähnte NAS möchte ich natürlich auch die Root-Partition verschlüsseln. Nur: wie geben ich beim Booten den Schlüssel ein? Ein Mini-Webserver muss her!

Falls das NAS neu gestartet werden muss -- beispielsweise nach einem Stromausfall -- darf das Eingeben den Filesystem-Passworts nicht an mir hängen. Vielleicht bin ich ja unterwegs. Also muss eine Lösung her, die einfach zu bedienen ist.

Das NAS hat keine serielle Schnittstelle, also scheidet Alles in diese Richtung aus. Den Schlüssel auf einem USB-Stick zu speichern geht nicht, denn der USB-Stick könnte in falsche Hände gelangen. Ein winziger Webserver, der das Passwort abfragt, scheint mir die sinnvollste Lösung.

Eine schöne Lösung hierzu hat das Projekt CryptoNAS (ehemals Cryptobox) entwickelt. Für meinen Einsatzzweck ist das leider (noch) nicht geeignet, da es a) noch keinen RAID unterstützt und b) den Server erst startet, wenn das System schon gebootet hat.

Da bei mir auch die Root-Partition verschlüsselt werden soll, muss das "Entsperren" geschehen, ehe diese eingebunden wird. Also muss der Webserver in der linuxrc gestartet werden, was wiederum bedeutet, dass der Webserver in die initrd muss. Und die möchte ich möglichst klein halten.

In der initrd ist bereits busybox installiert, alleine, um das Shell-Script linuxrc abzuarbeiten. Da wäre doch ein Webserver cool, der einfach als Shell-Script implementiert ist. Einen davon hat Morty Abzug geschrieben. Der macht einen guten Eindruck, ich müsste dem Server nur noch beibringen, CGI-Scripte zu verarbeiten, um das Webformular auszuwerten.

Bei der Suche, was genau die busybox shell kann, habe ich dann entdeckt: Die busybox hat einen Webserver eingebaut! Der kann auch CGI-Scripte. Sehr schön, das spart mir einen Haufen Arbeit! Und wie gesagt: busybox ist in der initrd sowieso enthalten. Jetzt muss ich "nur noch" die nötigen CGI-Scripte schreiben -- aber das sollte nicht recht aufwändig sein.

BTW: Die Anleitung für den busybox htpd findet sich im Quelltext.

15.05.2011 14:21

Warum man die Performance von /dev/urandom kaum erhöhen kann

Ich baue momentan ein kleines NAS zum Server um. Mein Ziel ist, ein stromsparender kleinen Server für unserer Bürogemeinschaft. Natürlich müssen die Daten darauf verschlüsselt werden. Die Platte ...

Dummerweise habe ich mir ein NAS empfehlen lassen, dass nicht von Haus aus verschlüsseln kann. Habe ich nicht aufgepasst. Dazu und zu anderen Unzulänglichkeiten des NAS ein andermal mehr. Ich hatte auch kurz die Idee, mir ein anderes zu kaufen, statt viel zeit hinein zu stecken. Aber wer weiß, ob ich da nicht vom Regen in die Traufe käme.

Das NAS ist gerootet, Debian ist installiert. Nun baue ich nach dieser Anleitung das verschlüsselte RAID. Die Anleitung ist kurz und gut, und die nötigen Befehle sind in zirka einer halben Stunde eingegeben.

Aber: Ein Schritt ist, die Platte mit Zufallsdaten zu beschreiben. Und das dauert ...
... und dauert ...
... und dauert ...
... und ich werde ungeduldig. Das muss man doch beschleunigen können?!

Zusammengefasst: Schneller geht nur mit schnellem Rechner.

Das Kommando

dd if=/dev/urandom of=/dev/md127 bs=10M

liefert auf dem NAS 1,8 MB/s, bei 2 TB macht das gute 300 Stunden also über 12 Tage. Urgs.

Also Platte ausgebaut, und per USB an den Desktop angeschlossen. Hier die Ergebnisse verschiedener Versuche (alle Messungen am Desktop):

of=/dev/md.. (also über RAID-Schicht)
3,8 MB/s 135 Stunden
5 1/2 Tage
of=/dev/md.. + Runlevel 0
4,0 MB/s 135 Stunden 5 1/2 Tage
of=/dev/md.. + timer_entropyd
3,7 MB/s
135 Stunden 5 1/2 Tage
of=/dev/sd.. (also ohne RAIS-Schicht)
3,8 MB/s
135 Stunden
5 1/2 Tage
if=/dev/zero ca. 66 MB/s 8 Stunden 1/3 Tag


Meine Erkenntnisse daraus:

  • urandom ist der begrenzende Faktor, nicht der USB-Anschluss.
  • Die Blockgröße ist fast egal: Auch größere und kleinere Input-Blocks (ibs=...) ändern nichts Nennenswertes.
  • Mehr Entropie bringt keinen Speed: Ich dachte, dass urandom schneller wird, wenn das System mehr Entropie hat. Dazu habe ich timer_entropyd eingesetzt, um die Entropie zu bekommen. Hat nichts gebracht, ja eher geschadet: Die Performance ist leicht gesunken.
  • Nachdenken hilft: urandom liefert Psuedozufallszahlen, rechnet also und braucht dazu CPU-Power. Mehr Entropie macht die Zufallszahlen zwar "zufälliger", aber deren Erzeugen nicht schneller.

Ich habe nun also ein paar Stunden Zeit, zu entscheiden, ob es das Risiko einer Krypto-Attacke gegen meine Platte wert ist, sie vorher 5 1/2 Tage mit Zufallszahlen zu beschreiben.

11.05.2011 17:40