PDF: Textverschlüsselung

Hab ich mir doch gedacht...

...vergiß es ;)
*und nicht böse sein. Dieses PDF bekommst Du nicht frei. Eher die Texte in kostenpflichtigen Ausschreibungstools*
 
Hab ich mir doch gedacht...

...vergiß es ;)
*und nicht böse sein. Dieses PDF bekommst Du nicht frei. Eher die Texte in kostenpflichtigen Ausschreibungstools*

Ein letztes Mal: ICH WILL DIESES PDF NICHT FREI KRIEGEN!

Aber du denkst es hängt mit Auschreibungstools zusammen. Das wäre eine logische Erklärung. Das sollte für unsere Firma auch mal ein Thema sein.
 
:D achsooo, sach das doch gleich... :eek:

Dann frag doch mal beim Ersteller nach, wie er das gemacht hat :)
Und poste die Lösung hier, das würde mich auch interessieren.
 
Äh, also ich denk' ja immer noch, daß es daran liegt, daß die Zeichensatzcodierung der Texte entweder auf "ANSI" oder "Custom" lautet. In Latin 1 oder Unicode umgesetzt muß das seltsame Resultate ergeben.

Das ist garantiert unabsichtlich geschehen und wird damit zu tun haben, daß das Original mit FrameMaker und das PDF mit Distiller 4.05 für Windows erstellt wurde.

Hier ist kein Tool im Spiel.
 
Also eine Verschlüsselung im eigentlichen Sinn liegt definitiv nicht vor!

Beweis: Oben das Gelesene Word und drunter das Copy&Paste

Anwendung
^åïÉåÇìåÖ

Bitte beachten Sie
_áííÉ=ÄÉ~ÅÜíÉå=páÉ


Wie man unschwer erkennt wird für jedes Zeichen immer das gleiche Symbol benutzt, d.h es kann sich eigentlich nur um einen, warscheinlich ungewollten, Effekt handeln, der seinen Ursprung irgendwo in der Zeichenkodierung hat, wie auch muellermanfred schon vermutet hat.

edit:
hab noch weiter gestöbert. es liegt definitiv am benutzten Font. Hier z.b. der eigebettete "TT50C9o00". Ändert man diesen in zb "Complex" bekommt man das gleich gekritzel wie mit copy&paste.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: ben-pen und muellermanfred
hab noch weiter gestöbert. es liegt definitiv am benutzten Font. Hier z.b. der eigebettete "TT50C9o00". Ändert man diesen in zb "Complex" bekommt man das gleich gekritzel wie mit copy&paste, die in Framemaker benutzt wurde.
genau deswegen liegt es nicht am Font.

Es liegt vermutlich an einer Kombi verschiedener Dinge:
Codierung als UTF8 und daran, dass die Daten wohl aus einer Datenbank (xml - würde bei solch technischen Beschreibungen passen) stammen und das ganze in Framemaker 6.0 auf Windows (siehe PDF, Eigenschaften) gelandet ist und von dort als PDF exportiert wurde.

Das Problem soll mit Framemaker 7 behoben sein.

So mein Reim auf die Sache.

http://de.wikipedia.org/wiki/Byte_Order_Mark
http://stuff.mit.edu/afs/athena/software/frame_v7.2/distrib/sun4x_510/FM72_UserGuideSupplementG.pdf
 
Zuletzt bearbeitet von einem Moderator:
  • Gefällt mir
Reaktionen: ben-pen
Wenn man die Codierung umsetzt ist alles in Butter, es ist dann zwar immer noch größtenteils nicht deutsch, aber lesbar ;-)

Wenn man sich aber mal ansieht per Apfel-D was da alles an Codierungen drin vorkommt, bis hin zu Custom, dann wird ein Rekonstruieren der Texte aus so einem PDF doch zu einer ziemlichen Fleissaufgabe.

Letztendlich fällt das Ganze eher unter Security by obscurity. ;)

Oder noch anders ausgedrückt: Würdest du die entstandenen Fontuntergruppen aus dem PDf extrahieren, die dazu gehörenden Texte kopieren und dann irgendwo diese Texte wieder dieser Schrift zuordnen, würde wieder was lesbares dabei herumkommen.

Zu testen wäre das evtl. per Kopieren einer Passage eines solchen Textes und das in ein anderes PDF dieser Serie einzufügen, in der Hoffnung das sie gleich codiert sind.

Wenn man die Texte z.B. per Pitstop kopiert und im selben Dokument einsetzt, und dieses ja bei solchen Aktionen tunlichst nur im Dokument verwendete Schriften verwendet, sieht das eingesetzte wieder so aus wie das kopierte.

MfG

ThoRic
 
Ist schon interessant. Ob die Verschlüsselung so gewollt ist oder nicht. Ich denke fast, diese Art der "Verschlüsselung" ist aufwendiger zu knacken als der herkömmliche Kopierschutz von Acrobat.
 
Zurück
Oben Unten