Inhaltsverzeichnis

Xerox-Scankopierer verändern geschriebene Zahlen

Vorabanmerkungen:

  • Eine (lange nicht erschöpfende) Presseschau habe ich anlässlich meiner Gastvorlesung zum Thema hier zusammengestellt. Ich bin selbst überrascht, wie viele Artikel es gibt.
  • Eine Zeitleiste der ganzen Angelegenheit gibt es weiter unten. Darin kann man sich einen Überblick verschaffen, und findet auch die relevanten Blogartikel verlinkt. Daraus geht auch klar hervor, dass ich Xerox sehr viel Zeit gelassen habe, also nicht einfach mit der Sache an die Öffentlichkeit gegangen bin. Das ist mir wichtig, weil ich erstmal versuche, im nicht-öffentlich auf Leute zuzugehen, wenn ich etwas zu beanstanden habe.

Video und Folien zu meinem Vortrag "Traue keinem Scan, den du nicht selbst gefälscht hast" (31C3)

Hier gibt es auch noch die Vortragsfolien.

Hier könnt ihr mir Feedback über den Vortrag geben! Das ist mir wichtig, danke! :-) (Achtung: 5 ist das beste, 1 ist das schlechteste, das sind keine Schulnoten.)

Einleitung

In diesem Artikel dokumentiere ich ausführlich, wie weit verbreitete Firmen-Scankopierer der Firma Xerox bei gescannten Seiten Ziffern, Zahlenreihen oder andere Bildfragmente unvorhersehbar vertauschen/ersetzen – und zwar nicht aufgrund irgendwelcher Texterkennung, sondern richtig hart in den Pixeldaten. Das Ergebnis sind Dokumente, die subtil falsch sind, aber perfekt aussehen – so, dass man es auf den ersten Blick nicht bemerkt. So etwas kann extrem gefährlich sein oder sogar Menschenleben kosten. Der Phantasie sind keine Grenzen gesetzt:

  1. Abrechnungen, die plötzlich nicht mehr stimmen.
  2. Baupläne mit vertauschten Quadratmeterzahlen.
  3. Falsche Ingenieurspläne, die wiederum Menschenleben gefährden würden (stellt euch vor, eine Autobahnbrücke hat in der Statik einen Zahlendreher verbaut).
  4. Arzneimitteldosierungen mit Zahlendrehern, eigentlich noch schlimmer.

Ihr seht schon: Was sich zunächst locker anhört, ist absolut kritisch und kann schnell lebensgefährlich werden. Es handelt sich um einen acht (!) Jahre alten Bug, der nach Händlerinformationen hunderttausende Xerox-Multifunktionskopierer weltweit betrifft. Mehrere große Gerätefamilien sind betroffen (eine Liste gibt es weiter unten). Jeder, der diese in den letzten acht Jahren eingesetzt hat oder jetzt noch einsetzt, muss sich fragen:

  • Wieviele fehlerhafte Unterlagen, die auf den ersten Blick richtig aussehen, habe ich in den letzten Jahren gespeichert oder gar an dritte herausgegeben?
  • Sind durch diese denkbaren Fehler Menschen oder Vermögenswerte gefährdet?
  • Kann ich für diese Fehler verantwortlich gemacht werden?

Bis zur Behandlung des Fehlers in meinem Blog war er nicht entdeckt oder veröffentlicht. Seine Tragweite entfaltete sich auch erst in Laufe meiner verschiedenen Blogartikel, die von den Massenmedien aufgegriffen und verbreitet wurden. In welcher Reihenfolge was geschah, lässt sich anhand der nachfolgenden Zeitleiste sehen. Es waren zwei interessante Wochen, das kann ich euch versprechen. :-)

Der Rest des Artikels ist wie folgt gegliedert.

  • Es wird an einer Zeitleiste beschrieben, wie die Angelegenheit sich entfaltet hat
  • Es wird an konkreten Beispielen beschrieben, wie der Fehler entdeckt wurde, und wie subtil er auftritt. Weil schwer zu glauben ist, dass ein Scankopierer Zahlen verdreht, liefere ich natürlich Beweismaterial mit.
  • Danach kommt eine Liste der betroffenen Kopierer.
  • Es folgt eine grobe Anleitung, wie sich der Fehler reproduzieren lässt.
  • Zuletzt gibt es eine kurze, laienhafte rechtliche Würdigung der rechtlichen Folgen. Kurzform: Die letzten 8 Jahre an PDF-Scans von betroffenen Geräten kann nicht nur Fehler enthalten, sie sind anscheinend auch rechtlich komplett wertlos, und zwar unabhängig davon, ob Fehler tatsächlich nachgewiesen werden.

Kurze Zeitleiste, was wann geschah

Ich werde immer wieder gefragt, ob es eine Kurzzusammenfassung gibt, was in welcher Reihenfolge geschah – hier ist sie. Die relevanten meiner Blogartikel sind verlinkt (teilweise schlecht sichtbar, aber die Links sind da). Die Liste wird ggfs. aktualisiert, der aktuelle Status ist immer mit einem :!: markiert.

Datum Was geschah
24. Juli 2013 Nummernvertauschen entdeckt
25. Juli Xerox das erste mal Bescheid gesagt dass Buchstaben vertauscht werden. In den nächsten Tagen wusste der Xerox-Support über mehrere Level hinweg nicht, woher das kommen könnte. Mitarbeiter eines Xerox Helpdesks vor Ort haben sich angestrengt, den „Fehler“ bei sich zu reproduzieren – erfolgreich. Ich finde das wichtig, weil es darstellt, dass ich mich nicht sofort aufmerksamkeitssuchend ans Internet gewendet habe, sondern erst einmal an Xerox. Später sollte ich noch erfahren, dass das Problem durchaus bei Xerox bekannt ist.
1. August Bis jetzt keine Hilfe von Xerox, fast eine Woche, über alle Ebenen des Supports hinweg. Alle schauen nur erstaunt. Ich finde das beängstigend und schreibe diesen Blogartikel.
2. August Der Artikel schlägt ein. Ich erhalte Mails von Leuten, die den „Fehler“ reproduzieren können sowie Informationen zur JBIG2-Kompression, die ich in meinen Artikel einpflege.
6. August, morgens Von einem Leser kriege ich Infos, dass es im Adminpanel der Kopierer eine winzige Meldung über Character substition gibt und der Fehler weg sei, wenn man die Kompression von „normal“ auf „higher“ schickt. Mir wird klar, dass das ganze bei Xerox ja wohl bekannt sein muss, wenn es da eine Meldung gibt. Das Problem bleibt: Leute können unwissentlich subtil falsche Dokumente produzieren, da die Meldung nur beim Setzen der Kompressionseinstellung angezeigt wird. Ich präsentiere dennoch einen Workaroundartikel.
6. August, nachmittags Telefonkonferenz mit Rick Dastin und Francis Tse. Rick Dastin, Vizepräsident bei Xerox, ist der erste Xerox-Angestellte, der mir sagt, dass Zahlen vertauscht werden können – aber auch, dass das gewollt ist. Ich kritisiere, dass der fragliche Kompressionsmodus „normal“ heißt. Ich lerne, dass auch in den gängigen Anleitungen zu Xeroxkopierern zwei kleine Anmerkungen über Character Substitution drin sind (inmitten von ca. 300 Seiten). Beide Anmerkungen beziehen sich ebenfalls auf die Kompression „normal“. Mir wird versichert, dass „normal“ entgegen der Intuition nicht die Fabrikeinstellung ist.
während der Telefonkonferenz Xerox veröffentlicht erstes Pressestatement. „For data integrity purposes, we recommend the use of the factory defaults with a quality level set to “higher.”“ Sie sagen außerdem, dass es den besagten Hinweis über Character Substitition gibt und bestätigen den Work Around aus meinem Blog.
7. August Zweites Statement, Softwarepatch wird angekündigt, liest sich so als würde der „normal“ mode damit eliminiert werden. Xerox sagt klar: „You will not see a character substitution issue when scanning with the factory default settings.“ In einem weiteren Document werden die factory Defaults definiert: Kompression „higher“, mindestens 200 DPI.
9. August Es gelingt mir, mit Kompression „higher“ und sogar 300 DPI Nummernvertauschungen zu erzeugen. Ich rufe zunächst Xerox an, warte, bis sie unter den gleichen Einstellungen vertauschte Zahlen sehen, und veröffentliche danach in Zusammenarbeit mit Xerox einen ausführlichen, warnenden Blogartikel, da nun hunderttausende Geräte in den Fabrikeinstellungen betroffen sind.
11. August Auf einem Xerox WorkCentre 7545 scheinen sogar alle drei Kompressionsmodi betroffen, also auch der höchste. Ein Leser berichtet das gleiche vom 7655. Völlig kompressionsunabhängig werden Zahlen und Buchstaben im Bild vertauscht, wobei der Effekt geringer wird, aber nicht verschwindet, wenn man die Qualität höherschraubt.Blog-Artikel hier.
August 12 Xerox bestätigt mir einen Software-Bug, der tatsächlich alle Kompressionsmodi umfasst und kündigt einen Patch an. Es können tatsächlich über alle Kompressionsmodi hinweg Zahlen vertauscht werden – und das seit acht Jahren! *uff* Dann gehe ich ja doch nicht in die Geschichte ein als der Typ, der zu doof war, die Anleitung zu lesen. 8-) Hier ist ihr Pressestatement.
August 19 Ich habe heute das Xerox-Softwareupdate vorab getestet. Sieht gut aus. Sie haben das Pattern Matching komplett eliminiert. Leider bestätigen mir heute diverse Xeroxvertriebler, dass die Zahl der Geräte tatsächlich in die Hunderttausende geht.
August 22 Die ersten Patches werden von Xerox released. Aufgrund der großen betroffenen Geräteanzahl werden die Patches in mehreren Wellen released werden.
Sept 11 Da ich immer mehr gefragt werde, warum ich von Xerox kein Geld verlangt habe: Dafür gibt es klare Gründe. Klickt hier für einen Blogartikel darüber.
Ab da Da Xerox einen dezentralen Vertrieb hat, können sie ihre Kunden nicht einfach auflisten und erreichen. Daher ist es komplett unklar, wieviele Geräte gepatched wurden. Ich würde denken, dass noch hunderttausende ungepatchte Geräte im Feld stehen. Also: Spread the word.
März 2015 Das Bundesamt für Sicherheit in der Informationstechnik rät in seiner technischen Richtlinie RESISCAN von der Verwendung von JBIG2 ab.

Fallbeispiele und Entdeckung des Fehlers

Das erste mal aufgefallen ist dem betroffenen Unternehmen der Fehler am vergangenen Mittwoch, als ein Bauplan zu einem PDF gescannt und wieder gedruckt wurde. Baupläne enthalten für jeden Raum des zu bauenden Hauses Boxen mit Quadratmeterzahlen, die irgendwie in den betreffenden Raum hineinlayoutet sind. In einigen Räumen standen nun sauber layoutete, jedoch schlicht falsche Quadratmeterzahlen – man muss wirklich die Zahlen lesen, um den Fehler zu bemerken. Der Fehler ist nur entdeckt worden, weil man hier nicht tatsächlich die Originalzahlen auswendig kennen musste, sondern es hat sich einfach jemand gewundert, warum ein Raum mit angeblich 14 Quadratmetern deutlich größer ist, als der danebenliegende 22-Quadratmeter-Raum.

Vorab hier eine Komplettansicht der Originalversion der betroffenen Seite – zu den Unterschieden kommen wir danach. Ich musste die Seite natürlich teilweise schwärzen. Klickt zum vergrößern drauf. Die gelben Markierungen habe ich zugefügt, das werden meine Beispielfehlerstellen sein. Achtet auf die Quadratmeterzahlen in den Boxen – diese sind mies aufgelöst, aber lesbar. Ich nummeriere sie für spätere Nennung durch, sei die obere „Stelle 1“, die untere linke „Stelle 2“ und die untere rechte „Stelle 3“.

Jetzt scannen wir den Bauplan auf dem Scankopierer als PDF ein. Ohne Texterkennung oder sonstige Späße. Dann stehen an den drei Stellen andere Nummernwerte 8-O. Ich liefere Screenshots der drei Stellen in den PDFs als Tabelle. Die Originale sind zur direkten Vergleichbarkeit in einer Zusatztabellenzeile eingeblendet. Das Xerox WorkCentre 7535 produzierte immer dieselben Fehler, weswegen hier nur eine Tabellenzeile notwendig ist; das WorkCentre 7556 produzierte immer andere Fehler, hier sind einfach zur Demonstration drei Durchläufe abgebildet:

Durchlauf / Gerät Stelle 1 Stelle 2 Stelle 3
Original, aus einem Tif-Scan entnommen, Korrektheit verifiziert
Xerox WorkCentre 7535
Xerox WorkCentre 7556, Durchlauf 1
Xerox WorkCentre 7556, Durchlauf 2
Xerox WorkCentre 7556, Durchlauf 3

Die Auflösung ist gering, aber die Zahlen sind deutlich lesbar. Zudem werden hier offensichtlich ganze Bild-Patches vertauscht und/oder mehrfach verwendet. Ich wiederhole, dass das kein OCR-Problem ist, oder zumindest haben wir OCR extra ausgeschaltet, und man sieht ja auch ganz deutlich, wie Pixeldaten durch die Gegend kopiert wurden. Man kann auch nicht einfach sagen „ja, dann nutzt doch eine andere DPI-Zahl“, weil das auch nicht ausschließt, dass irgendwo Bilddaten durcheinandergewürfelt werden.

Nächstes Beispiel: Ein Kostenregister auf dem WorkCentre 7535. Auch hier wieder ein plausibel aussehender Scan, aber bei näherem Hinsehen fällt ein Zahlenfehler auf. In diesem Fall wurde er gefunden, weil Zahlen in Kostenregistern aufsteigend sortiert sind:

Vorher Nachher

Man beachte, wie aus der 65 eine 85 geworden ist (zweite Spalte, dritte Zeile). Edit: Ich werde gerade darauf hingewiesen, dass oben rechts auch noch aus einer 60 eine 80 geworden ist. Das ist auch nicht einfach ein Pixelfehler, man kann ganz deutlich sehen, wie die 8 im unterschied zur 6 auf der linken Seite die charakteristische mittige Einbeulung hat. Der Scan war schon mehrere Wochen alt zum Zeitpunkt des Entdeckens, der Fehler ist also auch nicht erst eben aufgetreten. Wer weiß, wieviele Unterlagen schon subtil falsch sind.

Betroffene Geräte

Als die Sache sich noch entfaltete, habe ich in diesem Abschnitt eine „Hörensagen-Liste betroffener Geräte“ anhand Mails von Lesern aufgebaut. Da der Bug mittlerweile von Xerox bestätigt ist, ist die folgende Liste nun keine Hörensagen-Liste mehr, sondern offiziell. Der Buchstabe x kann für beliebige Ziffern stehen, hier sind ganze Gerätefamilien betroffen:

WorkCentre-Reihe 232, 238, 245, 255, 265, 275, 5030, 5050, 51xx, 56xx, 57xx, 58xx, 6400, 7220, 7225, 75xx, 76xx, 77xx, 78xx
WorkCentre Bookmark-Reihe 40, 55
WorkCentre Pro-Reihe 232, 238, 245, 255, 265, 275
ColorQube-Reihe 8700, 8900, 92xx, 93xx

Fehler selbst reproduzieren

Nach dem Kostenregister habe ich nach einem Weg gesucht, den Fehler zu reproduzieren. Der Weg ist naheliegend: Zahlenkolonnen generieren, drucken, scannen, OCR drüberjagen und mit der Ausgangszahlenkolonne vergleichen. Da das OCR auch selbst Fehler machen kann, muss man die gefundenen Stellen natürlich noch mal von Hand überprüfen. Die Schriftart für die ich den Fehler hier reproduzieren konnte, war Arial 7pt, mit den Scaneinstellungen wie oben und der neueren Softwareversion des 7535er Workcentres. Und siehe da, aus 6en werden wieder 8en (Beispiele gelb markiert, nicht erschöpfend):

Vorher Nachher

Man beachte, wie die 6en drumrum korrekt aussehen und die falschen 8en wieder die charakteristische 8-Eindellung erhalten, es sind also nicht nur einfach wieder irgendwelche falschen Pixel, sondern ausgetauschte Ziffern. Es ist also nicht die Originaldatei (wenn auch die Bilder darin die Originalpixel sind).

Falls ihr mal selbst gucken wollt:

  • Hier ist ein Tif-Scan der Seite, fehlerfrei. DEN KÖNNT IHR DRUCKEN UND ALS TESTDOKUMENT NUTZEN. Dass der dann schon mal gescannt und gedruckt ist, ist gewollt – das verrauscht die ziffern leicht, sie sind aber noch gut lesbar. So tritt der Fehler häufiger auf, so dass ihr besser sehen könnt ob ihr betroffen seid.
  • Hier ein PDF-Scan mit ein paar für euch vormarkierten falschen Achten auf dem 7535er. Das OCR habe ich nachträglich gemacht, um die Ziffern sauber markieren zu können.
  • Auf vielfachen Wunsch: Der gesamte PDF-Scan ohne jegliches Postprocessing meinerseits. Einfach so, wie er aus dem 7535er herausgekommen ist. Viele Seiten.

Ursache und rechtliche Folgen

Der Fehler tritt auf, weil Bildbestandteile, die der Kopierer für gleich hält, nur einmal gespeichert und dann immer wieder verwendet werden. Irrt sich das Ähnlichkeitsmeßverfahren (Pattern Matching) der kopierer, werden eben Zeichenblöcke durch andere ersetzt, zum Beispiel eine 6 durch eine 8. Anders als von Xerox im Rahmen der – verständlichen – PR-Bemührungen suggeriert, tritt der Fehler nicht nur bei schwer lesbaren Ziffern auf (7pt-Schrift auf 300 DPI würde wohl kaum jemand als schwer lesbar bezeichnen), auch wenn die Zeichen relativ klein sind.

Es ist wichtig zu beachten, dass das in den betroffenen PDFs benutzte JBIG2 ein Bildformat ist, und kein Kompressionsalgorithmus, also eine Vorschrift, wie die Kompression eines Bildes an sich erfolgen soll, es definiert nur, wie es danach gespeichert werden soll. Es ist also sozusagen eine Dekompressionsvorschrift, während die kompressionsweise flexibel ist. JBIG2 wurde eigens entwickelt, um effizient Bilder zu speichern, die gescannten Text enthalten. Dafür wird es auch üblicherweise benutzt und so haben sich auch einige übliche Vorgehensweisen der Kompression etabliert, die wir uns in den folgenden Absätzen ansehen können, ohne den Sourcecode von Xeroxmaschinen oder denen anderer Hersteller zu kennen. Insbesondere kann, wie wir gleich sehen werden, das Komprimieren verlustbehaftet und verlustfrei erfolgen. Also bedeutet die folgend beschriebene Fehlerursache, dass nicht JBIG2 der Grund für die bei Xerox aufgetretenen Verfälschungen ist, sondern fehlerhafte Parametrierung beim Kodieren in JBIG2. Der Fehler liegt nicht in JBIG2 selbst. Es wurden durch einen Bug Verluste eingebaut, wo keine hätten sein dürfen.

„Pattern Matching & Substitution“ (PM&S) ist eine der Standardvorgehensweisen bei lossy JBIG2, und „Soft Pattern Matching“ (SPM) die bei lossless JBIG2 (Infos hier oder in den Veröffentlichungen von Paul Howard et al.1)). Im JBIG2-Standard heißt das ganze „Symbol Matching“.

PM&S ist verlustbehaftet, SPM verlustfrei. Beide Kompressionsmodi von JBIG2 arbeiten zunächst nach dem gleichen Schema: Das Bild wird in Symbole zerlegt, diese werden nach Ähnlichkeit gruppiert. Für jede Gruppe werden dann nur Repräsentanten gespeichert und diese wiederverwendet. Im Unterschied zu PM&S werden bei SPM aber die so entstandenen Pixelfehler korrigiert, indem ein Differenzbild zum Original dazugespeichert wird. Dieser Korrekturschritt scheint bei Xerox weggelassen worden zu sein.

Da nun für die PDFs, die mit den Geräten in den letzten 8 Jahren erzeugt wurden, nicht mehr nachgewiesen werden kann, was eigentlich auf dem Blatt Papier stand, dürfte der rechtliche Wert aller dieser gescannten PDFs gegen null gehen! Das bedeutet, dass es eigentlich egal ist, ob tatsächlich Fehler auftreten – bei keinem PDF, wo ganze Bildsegmente wiederverwendet werden, kann der Originalinhalt noch nachgewiesen werden.

Ist Ihr Unternehmen vom Xerox Scanning-Bug betroffen?

Bei mir melden sich gerade immer mehr namhafte Unternehmen, die sich fragen, ob sie erhebliche Probleme haben, jedoch Angst vor Publicity verspüren. Manche sind sich auch schon sicher, dass sie Probleme haben, teils in sicherheitskritischen Tätigkeitsfeldern. Betroffene Unternehmen haben in der Regel drei Ziele:

  1. Sie wollen das Problem lösen, nach Möglichkeit rückwirkend
  2. Sie wollen keine Publicity, bei vielen Angestellten nach Möglichkeit nicht einmal intern
  3. Sie wollen eligible für Schadenersatz bleiben, müssen also aufpassen, nicht im Überschwang Beweismittel für die Fehlfunktion zu vernichten.

Diese Ziele widersprechen teilweise einander; auch große Unternehmen sind nicht gefeit vor Anfängerfehlern. Darum pauschal: Jeder, der sich bei mir meldet, um überhaupt erst einmal die Lage einzuschätzen, kann sich darauf verlassen, dass ich seine Identität nicht preisgebe. Das habe ich über die ganze Angelegenheit so gehandhabt, und damit höre ich jetzt auch nicht auf. Kontaktdaten stehen im Impressum.

1)
vgl. z.B. Howard, P.G.; Kossentini, F.; Martins, B.; Forchhammer, S.; Rucklidge, W.J., „The emerging JBIG2 standard“, IEEE Transactions on Circuits and Systems for Video Technology, vol.8, no.7, pp.838,848, Nov 1998, doi: 10.1109/76.735380.
Eintrag vom 2013-08-02 von David Kriesel. Tags:

Comments

Aufgrund von Caching kann es bis zu zwei Minuten dauern, bis ein Kommentar erscheint!

Da ich gerade ziemlich viel manuellen Spam aus Russland und Pakistan bekomme und keine Zeit habe, da wirksam gegen anzugehen, ist die Kommentarfunktion bis auf weiteres abgeschaltet. Wenn's pressiert, mailt mir!

Ich hab mir das auch mal angeschaut und war über 2 Dinge verwundert:

1) Xerox scannt in Graustufen, sucht dann rein schwarze Pixel, verschiebt die in ein überlagertes 1-Bit-Bild-Objekt (mit häßlich niedriger Auflösung!) und wendet dann lossy JBIG2 Kompression drauf an, was dann beinahe schon schiefgehen muß

2) Wenn man bei Xerox nach TIFF scannt, kommt – intern – JPEG 'bei raus. Auch hier dürfte das nicht das sein, was der User erwartet.

Wie sieht das denn nach dem Firmware-Update aus? Machen Sie immer noch den Unsinn mit „reines Schwarz erkennen und als separates 1-Bit-Objekt in PDF einbetten“, setzen jetzt aber auf lossless JBIG2?

Details übrigens hier noch:

https://groups.google.com/d/msg/de.comp.sys.mac.misc/q8hQT1XdgRA/AFLvvgPlt6MJ

1 |
Thomas Kaiser
| 2013/09/08 23:33 | reply

Hi Thomas,

ich weiß nicht genau, wie sie es jetzt machen, aber auf Wunsch mache ich gerne bei Gelegenheit ein paar Scans und lasse sie dir zukommen :-)

2 |
David Kriesel
| 2013/09/09 12:36 | reply

Also irgendwie check ich's nicht :-D ich mein ein Scanner ist doch eig. nix anderes als ein superauflösender hightech special Fotoapparat - also wirklich ganz blöd ausgedrückt. Das Teil denkt ja nicht mit o.ä. sondern erschafft einfach ein Abbild von etwas in digitaler Form. Aus dem Artikel wurd ich jetzt auch nicht wirklich schlau wie es zu diesem Fehler gekommen ist. Gerne eine kurze Aufklärung per mail :-D

3 |
Holger
| 2013/10/21 15:31 | reply

Danke für die mail. Jetzt hab auch ich's kapiert xD

4 |
Holger
| 2013/10/21 16:22 | reply

Hi, also ich zähle mal 1 und 1 zusammen und behaupte, dieser Beitrag ist (Real-) Satire, ja? Anders kann ich Deine Autorbox in Verbindung mit dem letzten Kommentar von Holger nicht deuten ;)

5 |
Viktor
| 2014/09/23 20:55 | reply

Ich frage mich, wann das erste Mal sowas bei der Sprachübertragung passieren wird, wie zB. bei Mobiltelefonie oder Internet-Telefonie!

Kompression wird ja dort auch immer besser, und ich sehe keinen Technischen Grund, warum sowas dort nicht auch passieren könnte, wenn die Kompression einzelne sich wiederholende Silben codiert…

Grüße aus Wien!

6 |
Philipp Prause
| 2014/10/01 21:40 | reply

Ich befürchte das Xerox nicht die einzige Marke mit diesem Problem ist. Auf em Minolta merkte ich beim Testscan auch schon die ersten gröberen Fehler… Das auch auf die Kompression zu schliessen lässt.

7 |
Xaver Aernu
| 2014/12/31 14:00 | reply

Hallo David,

danke für den coolen, lustigen (obwohl todernstes Thema) Vortrag bei 31C3, den ich im Livestream mitverfolgen durfte. Ich habe meinem Freund gleich die Info weitergegeben, damit der im Forschungsinstitut einmal nachschaut ob der Admin auch brav die Software geupdated hat (physikalische/chemische Messungen sollten schon stimmen, wenn eingescannt ;-).

Deine Analyse des Problems mit selbstgenerierten Zeichenketten finde ich interessant und führt zu meinem Punkt. Ich beschäftige mich sehr ausgiebig (lange Praxiserfahrung) mit Softwaretest (u.a. nach der Methodik des ISTQB).

Meiner Meinung hat hier Xerox starken Nachholbedarf, da genau diese Tests mit Selbstgenerierten Zeichenketten (= selbstgenerierte Testdaten) ausgeblieben sind. Ansonsten kann ich mir nicht erklären, warum keinen 8 Jahre lang die Diskrepanz zwischen Soll (bspw. Zahl „6“) und Ist (bspw. Zahl „8“) aufgefallen ist.

Man könnte das „Spielchen“ auch mit Äquivalenzklassen (je nach Granularität „Buchstaben“, „Zahlen“, „Sonderzeichen“, … „andere Zeichensätze wie ASCII, Unicode, etc.“, „verschieden Schriftarten“) in einem Blackboxtest testen. Dies ist offensichtlich nicht gemacht worden, daher hoffe ich, dass Xerox hier in Zukunft das Testmanagement „verstärkt“.

Viele Grüße,

Stefan

8 |
Stefan Bregenzer
| 2015/01/01 10:12 | reply

Hallo David,

ich möchte dir nur mitteilen, das ich deinen Betrag gerade eben angesehen habe und einfach begeistert bin, wie du dieses Thema aufgearbeitet hast! Toll! Habe dich direkt in meine Feeds aufgenommen! Weiter so.

Was mich besonders fasziniert ist die Frage, was das Unternehmen durch diesen Bug für einen Schaden hat. Hoffentlich einen großen, damit Sie auch was daraus lernen. Xerox ist ab jetzt tabu!

Gruß, Michael

9 |
Michael Koch
| 2015/01/02 21:09 | reply

Hallo David,

ich habe eben unser 1 Jahr altes WC7845 getestet mit unterschiedlichen Einstellungen. Da in starker Vergrößerung alle Zahlen unterschiedlich gepixelt aussehen, gehe ich davon aus, dass JBig2 nicht mehr angewendet wird.

Wir haben allerdings seit Sommer 2014, wo mir ein XEROX-Techniker von dem Problem berichtete (er sprach von der „höchsten Auflösung“, die ab dem Update nicht mehr anwählbar sei und nicht von „normal“), schon 3-4 Firmware Updates wegen anderer Fehler bekommen, zuletzt vor ca. 2 Wochen. Damit könnte der Fehler aus der Welt sein.

Oder hast Du eine Idee, was ich beim Testen falsch gemacht haben könnte?

Viele Grüße Hans Jürgen

10 |
Hans Jürgen Lenzen
| 2015/01/05 18:28 | reply

Ich antworte auf direkte Anfragen via Mail. Nicht, dass sich einer wundert.

11 |
David Kriesel
| 2015/01/05 18:33 | reply

Die Sprachkompression ist wirklich ein Thema, das beobachtet werden sollte. Ich habe eine Tetra-Schulung besucht, da wurde genau so etwas angedeutet. Es sollen wohl Silben, die oft gebraucht werden, quasi in Steno übertragen werden. Die Stimme ist daher auch nicht mehr wirklich originalgetreu, schon wegen einer Kompression. Wir erinnern uns: 11.9. WTC, da sind Menschen zu Schaden gekommen, weil der Funk nicht ordentlich ging. Nun müsste man das mal recherchieren, was da gemeint war. Und da gibt es sicher noch viele andere Beispiele.

12 |
Sönke Mahrt
| 2015/01/06 12:59 | reply

Hallo David, mit Interessen habe ich deinen Vortrag gelesen und mir gestern auch noch angesehen. Vielen Dank dafür. Meine Frage bezieht sich jetzt auch das direkte Kopieren mit diesen Geräten. Normalerweise werden ja vor dem Kopieren erst Scans von den Seiten erstellt, die dann temporär abgelegt werden, oder? Da jetzt der Fehler nur bei PDF-Scans auftritt, aber nicht bei Tiff-Schans, tritt der Fehler nun dann auch bei der direkten Kopie auf? Mit welcher Kompression wird dort gearbeitet?. Ich hoffe, meine Frage war nicht zu doof. Viele Grüße Markus

13 |
Markus Kubitza
| 2015/01/09 10:50 | reply

Hi, soweit ich weiß tritt der Fehler beim direkten kopieren nicht auf.

14 |
David Kriesel
| 2015/01/09 11:10 | reply

Ich habe heute von der Geschichte man in der Firma (GMP Umfeld) dem Leider der QS, Zulassung und IT berichtet damit man bei der nächsten Inspektion auf Fragen vorbereitet sein kann. Meine Antwort für die Inspektion: „Problem bekannt und validiert mit deinen Testseiten, außerdem machen wir nur TIF>PDF/A bevor die Dokumente ins DMS kommen.“ Weißt du was viel schlimmer als der Bug ist? Die wollen davon nichts wissen. Weil macht nur Arbeit. Mir fehlen die Worte…

15 |
Basti
| 2015/01/15 16:18 | reply

Basti: IT-ler die in ihrem Job schlecht sind und/oder keine Lust auf diesen haben, gibt es verbreitet. Ich empfehle dir, Kontakt zum Management zu suchen und auf das Kaufmännische Risiko hinzuweisen und gleichzeitig diese Einstellung eurer IT zu skizzieren.

Dass ihr Tif macht ist doch aber ganz positiv.

16 |
David Kriesel
| 2015/01/15 16:28 | reply

Hi David, super Vortrag beim CCC mit entsprechender Brisanz.

Sorry, was soll der Quatsch mit den echten Kopien?

Scans sind hier viel kritischer!!! Hier werden Originaldokumente in DMS Systemen abgelegt und mittels OTR Systemen automatisch in Datenbanken eingetragen. Bei einer Kopie kann man erkennen, auf welchem Kopierer die erzeugt wurde - das ist seit Jahren bekannt. Sobald das Ganze aber per OTR in Datenbanken verschwindet, ist hier nichts mehr nachzuvollziehen.

Das ist in den Firmen aber heute Standard!-nennt sich automatische Rechnungserkennung o.ä. (KdNr, ReNr, Beträge, Daten, evtl. Autokennzeichen, PA-Nummern, KK-Nummer etc.). Man stelle sich eine Fa. Allianz mit sehr vielen Lebensversicherungen vor, die über Jahre alle falsch berechnet und verzinst sind - und das wird bekannt. Wie lange könnten die noch überleben?

17 |
jeremiah
| 2015/02/17 19:20 | reply

Lieber David, anderthalb Jahre nach der Entdeckung des #XEROX_bug findet die Story nunmehr auch Nachhall bei den offiziellen Gremien. Das Bundesamt für Sicherheit in Informationstechnik (BSI) „verbietet“ am 16.3.2015 #JBIG2 Kompression generell (https://www.bsi.bund.de/DE/Publikationen/TechnischeRichtlinien/tr03138/index_htm.html). Auch die Schweizer Koordinationsstelle für die dauerhafte Archivierung elektronischer Unterlagen (KOST) lehnt JBIG2 gänzlich ab (http://kost-ceco.ch/cms/index.php?id=312,569,0,0,1,0). Bei Beratern (http://www.project-consult.de/ecm/in_der_diskussion/das_wiesbadener_urteil_zum_scannen#comment-2657) und in der Presse (http://www.ecmguide.de/news/xerox-fall-wird-nun-amtlich-bsi-aktualisiert-tr-resiscan-20931.aspx) findet dies Widerhall. Das ursprüngliche Problem, dass in einer bestimmten Einstellung mit niederiger Auflösung und dem JBIG2-Verfahren mit Pattern-Matching für die Erzeugung von PDFs Zahlen- und Buchstabendreher entstanden, ist meines Erachtens zweitrangig. drei Thesen: (1) Der eigentliche Skandal beim XEROX-Fall ist nicht der technische Fehler sondern, daß bei tausenden Installationen niemand über Jahre hinweg etwas gemerkt hat. Soviel zum Thema visuelle Qualitätssicherung beim Scannen. Ein kurzer Blick auf einen Bildschirm ohne dass das Original daneben liegt, langt einfach nicht solche Fehler festzustellen. (2) Es gibt keine Rechtssicherheit. Sicherheit beim Scannen durch elektronische Signaturen erzeugen zu wollen ist ein Irrweg. Durch das Signieren und Nachsignieren des Dokumentes wird die Ursprungsqualität nicht besser. Nun stellt sich nach der BSI Empfehlung „Kontra“ JBIG2 die Frage, wie all die bereits gescannten Dokumenten zu behandeln sind, die entsprechend der Auflistung in der ursprünglichen TR-03138 ResiScan mit JBIG2 komprimiert worden sind: nunmehr alle und zu dem rückwirkend nicht mehr rechtssicher und vor Gericht als Beweis anzuerkennen? (3) Verbote helfen nicht. Es geht nicht um ein technisches Problem, sondern um Sorgfalt und Qualität in den Erfassungs- und Verarbeitungsprozessen von Information. Hier müssen anstelle oder zumindest zusätzlich automatische Verfahren der Überprüfung der Lesbarkeit und inhaltlichen Korrektheit implementiert werden. Jedes Dokument per OCR und Klassifikation nebst Abgleich auswerten. Dies ist sicherer und schneller als manuelle Sichtkontrollen. JBIG2 gleich ganz zu verbieten, schießt außerdem über das Ziel hinaus. Ohne eine Klärung, was mit bereits gescannten Dokumenten zu geschehen hat (siehe 2) und ohne Erklärung, dass es sich letztlich nur um ein Einstellungs- oder Parametriesierungsproblem moderner Scannersoftware handelt, erzeugt dies wieder Unsicherheit und Angst gegenüber elektronischen Verfahren. Dies ist falsch und kontraproduktiv. Ulrich Kampffmeyer

18 |
Ulrich Kampffmeyer
| 2015/03/23 11:02 | reply

Lieber David, anderthalb Jahre nach der Entdeckung des #XEROX_bug findet die Story nunmehr auch Nachhall bei den offiziellen Gremien. Das Bundesamt für Sicherheit in Informationstechnik (BSI) „verbietet“ am 16.3.2015 #JBIG2 Kompression generell (https://www.bsi.bund.de/DE/Publikationen/TechnischeRichtlinien/tr03138/index_htm.html). Auch die Schweizer Koordinationsstelle für die dauerhafte Archivierung elektronischer Unterlagen (KOST) lehnt JBIG2 gänzlich ab (http://kost-ceco.ch/cms/index.php?id=312,569,0,0,1,0). Bei Beratern (http://www.project-consult.de/ecm/in_der_diskussion/das_wiesbadener_urteil_zum_scannen#comment-2657) und in der Presse (http://www.ecmguide.de/news/xerox-fall-wird-nun-amtlich-bsi-aktualisiert-tr-resiscan-20931.aspx) findet dies Widerhall. Das ursprüngliche Problem, dass in einer bestimmten Einstellung mit niederiger Auflösung und dem JBIG2-Verfahren mit Pattern-Matching für die Erzeugung von PDFs Zahlen- und Buchstabendreher entstanden, ist meines Erachtens zweitrangig. drei Thesen: (1) Der eigentliche Skandal beim XEROX-Fall ist nicht der technische Fehler sondern, daß bei tausenden Installationen niemand über Jahre hinweg etwas gemerkt hat. Soviel zum Thema visuelle Qualitätssicherung beim Scannen. Ein kurzer Blick auf einen Bildschirm ohne dass das Original daneben liegt, langt einfach nicht solche Fehler festzustellen. (2) Es gibt keine Rechtssicherheit. Sicherheit beim Scannen durch elektronische Signaturen erzeugen zu wollen ist ein Irrweg. Durch das Signieren und Nachsignieren des Dokumentes wird die Ursprungsqualität nicht besser. Nun stellt sich nach der BSI Empfehlung „Kontra“ JBIG2 die Frage, wie all die bereits gescannten Dokumenten zu behandeln sind, die entsprechend der Auflistung in der ursprünglichen TR-03138 ResiScan mit JBIG2 komprimiert worden sind: nunmehr alle und zu dem rückwirkend nicht mehr rechtssicher und vor Gericht als Beweis anzuerkennen? (3) Verbote helfen nicht. Es geht nicht um ein technisches Problem, sondern um Sorgfalt und Qualität in den Erfassungs- und Verarbeitungsprozessen von Information. Hier müssen anstelle oder zumindest zusätzlich automatische Verfahren der Überprüfung der Lesbarkeit und inhaltlichen Korrektheit implementiert werden. Jedes Dokument per OCR und Klassifikation nebst Abgleich auswerten. Dies ist sicherer und schneller als manuelle Sichtkontrollen. JBIG2 gleich ganz zu verbieten, schießt außerdem über das Ziel hinaus. Ohne eine Klärung, was mit bereits gescannten Dokumenten zu geschehen hat (siehe 2) und ohne Erklärung, dass es sich letztlich nur um ein Einstellungs- oder Parametriesierungsproblem moderner Scannersoftware handelt, erzeugt dies wieder Unsicherheit und Angst gegenüber elektronischen Verfahren. Dies ist falsch und kontraproduktiv. Ulrich Kampffmeyer

19 |
Ulrich Kampffmeyer
| 2015/03/23 11:02 | reply

@UlrichKampffmeyer:

Sie schrieben:

<i>„Das ursprüngliche Problem, dass in einer bestimmten Einstellung mit niederiger Auflösung und dem JBIG2-Verfahren mit Pattern-Matching für die Erzeugung von PDFs Zahlen- und Buchstabendreher entstanden, ist meines Erachtens zweitrangig.“</i>

Sie haben aber schon mitgekriegt, dass das zitierte „ursprüngliche“ Problem später umfassender erkannt wurde: nämlich dass die Zahlen- und Buchstabendreher nicht nur bei „bestimmten Einstellungen mit niedrigerer Auflösung“ vorkam, sondern bei ALLEN Einstellungen mit JBIG2 ?

20 |
Kurt Pfeifle
| 2015/03/24 00:44 | reply

@UlrichKampffmeyer:

Sie schrieben:

JBIG2 gleich ganz zu verbieten, schießt außerdem über das Ziel hinaus.
…
es sich letztlich nur um ein Einstellungs- oder Parametriesierungsproblem moderner Scannersoftware handelt
…

So hört sich die Software-Hersteller/Consulting-Lobby an.

21 |
JBIG2-Betroffener
| 2015/10/19 14:12 | reply

In den Top Ten der vernachlässigten Nachrichten hat es der Xerox Bug leider auf Platz 4 geschafft. http://www.derblindefleck.de/top-ten-der-vernachlaessigten-nachrichten-2016/

22 |
Waterhouse
| 2016/03/08 17:54 | reply

Moin

habe mir gerade das Video angeschaut - hammer geil! Meinen Respekt! Is zwar schon älter der Fall, aber ich finds einfach hammer… 8 Jahre der Bug…

So Leute wie dich braucht die IT.

Beste Grüße

23 |
Marco
| 2016/09/13 15:18 | reply

Das ist ja wirklich ungewöhnlich. Das würde mich als Nutzer von Drucker und Scanner sehr ärgern. Vielen Dank für den interessanten Artikel. Ich wusste gar nicht dass so etwas passieren kann.

24 |
Lars
| 2016/10/06 17:11 | reply

Hallo David,

sehr interessanter und erschreckender Vorgang, danke dass Du dich darum gekümmert hast :) Und auch danke für den Vortrag, der das Problem auch Technik-Laien verständlich macht!

Wusstest Du, dass Dein Vortrag inzwischen bei den Verschwörungstheoretikern entsprechenden Widerhall findet? Das war nämlich tatsächlich alles Absicht von Xerox, nur dass das klar ist! Guckst Du hier:

http://alles-absicht.de/xerox-luege

Gruß, Peter

25 |
Peter
| 2016/11/18 15:23 | reply

@Peter: Es darf nicht wahr sein. LOL Aus deinem Link:

Der folgende unterhaltsame Vortrag von David Kreisel beschreibt die Vorgänge im Einzelnen. Leider macht er sich zu Beginn über eine Verschwörungstheorie lustig. Wenn gebildete Menschen selbst verschwörungsähnliche Themen verbreiten, ist es wohl ein universitärer Reflex, dass sie den Zuhörern im gleichen Zuge ihre Immunität dagegen beweisen müssen. Denn sonst wäre ja ihre eigene Seriosität gefährdet.

Ich lache mich schlapp :-)

26 |
David Kriesel
| 2016/11/18 15:31 | reply

Apropos Verschwörungstheorien:

Ne Autobahnbrücke (A7 Schraudenbach) hat's dieses Jahr auch zerlegt…

Unheimlichen Gruß

27 |
Jochen
| 2017/01/12 22:55 | reply

@Jochen: letztes Jahr natürlich

28 |
Jochen
| 2017/01/12 22:56 | reply

Tolles Video! Ich schau den nun mindestens zum dritten mal. Sau geil gemacht und gut vorgetragen. Haben selber Xerox system bei uns im Geschäft und waren leicht betroffen.

29 |
Boris
| 2017/03/03 10:19 | reply

Ja Wahnsinn. Die Hilfe aus unserem neuen Dokumentenmanager hat mich hierher geführt (https://www.officemanager.de/handbuch/jbig2-komprimierung.html). Und ich habe tatsächlich eine Menge Scans mit JBIG2 gefunden. Jetzt schauen wir erstmal, was das genau bedeutet. Besten Dank.

30 |
Klaus
| 2017/11/18 16:12 | reply

Puh, Glück gehabt. Xerox wird Fuji-Xerox. https://www.heise.de/foto/meldung/Fujifilm-uebernimmt-Druckerhersteller-Xerox-3957343.html oder http://www.fujifilmholdings.com/en/news/2018/0131_01_02.html Nur veröffentlichen, wenn es zum Thema passt.

31 |
Feinbein
| 2018/02/07 18:21 | reply

Nur Xerox? Ich habe gestern das Video auf Youtube gefunden… gut gemacht! Nun frage ich mich aber ob nicht auch andere Hersteller das gleiche problem haben? HP zum Beispiel verwendet auch die Jbig2 Kompression beim Scan in ein PDF. Gibt es Meldungen über „nicht Xerox“ Geräte, die betroffen sind?

32 |
Christian Müller
| 2018/03/26 09:16 | reply

Danke… Wahnsinn.

Was passiert denn mit Handy-Scannerprogrammen? Welche Art von Kompression verwenden die? Oder wenn Fotos runtergerechnet werden?

33 |
Makob Wegmann
| 2018/05/24 11:11 | reply

Hallo David, vielen Dank für diesen Vortrag. Ich habe die ganze Zeit mit offenem Mund dagesessen.

Sehr gut. Ich werde deinen Blog im Auge behalten.

34 |
Oern
| 2018/07/04 10:00 | reply

Hi, ich habe heute Nacht zufälligerweise deinen Vortrag auf youtube gesehen. Vielen Dank hierfür!

Dank deiner Tif Scan Datei, die ich an meinem Drucker ausgedruckt habe, habe ich das auch mal mit einem „fujitsu scansnap ix500“ getestet. Der fujitsu scansnap ix500 ist auch naja…betroffen. Mein Drucker: Triumph-Adler/Kyocera FS1300D mit 300 dpi gedruckt .

Einstellung des Scanners: Bildqualität: „Beste“ Farbe/Grau 300 dpi, S&W 600 dpi

6er werden zu 8ern. Mit dem OCR Modus wird es dann zu einer 0 umgewandelt!

Nur mal als Beispiel die Zahl der Testreihe war: 171814236428 Als Scan kam heraus: 171814238428 mit copy/paste nach OCR kommt heraus 171014230428

Ich bin etwas schockiert und verwirrt.

35 |
JEH
| 2018/07/17 14:59 | reply

Toller Vortrag, vielen Dank, auch wenn ich jetzt nicht so gut schlafen werde. Eine Sache habe ich nicht verstanden: das Beispiel der Baupläne zeigt, dass nicht nur ähnliche Zeichen verwechselt werden, da beim ersten Versuchsscan der Baupläne ganz unterschiedliche Zahlen alle gleich wiedergegeben wurden (und auch nur die Zahlen in den Kästen, die Kästen selbst sind unterschiedlich). Wie passiert das? Vielen Dank und Grüße Stef

36 |
Stefanie
| 2018/07/24 00:48 | reply

@JEH: Lieber David, ich bin gestern zufällig auf Deine Vortrag gestoßen! Kompliment dazu und vielen Dank dafür!

Ich habe gerade mal meinen Fujitsu Scansnap ix500 getestet und komme - anders als der Kommentator weiter oben - zu Ergebnis, dass mein Setup nicht betroffen ist. Ich verwende den Scanner mit dem ScanSnapManager und lasse das OCR vom „eingebauten“ Tool, dem „Konverter für durchsuchbare PDFs“ durchführen. Qualitätsstufe im ScanSnapManager ist Mittel (3) und der ganze Rest (also Farbe, Auflösung etc.) ist alles Automatik. Welche Algorithmen Fujitsu in diesen Tools verwendet konnte ich nach ein bisschen Recherche leider nicht herausfinden. Man müsste ggf. mal die resultierenden Dateien analysieren. Der Kommentator weiter oben hat dazu leider nicht geschrieben, mit welcher Software er arbeitet. Der Scanner selbst dürfte wohl nichts zum Thema relevantes tun. Ich denke Fujitsu macht alles in der Software auf dem Rechner, nicht im Scanner selbst wie ei Xerox. Der Hardwarepreis liegt ja auch um Größenordnungen niedriger. Evtl. hat der Kollege oben den Abby Fine Reader im Einsatz, den man zu diesem Scanner dazu bekommt, den ich aber nicht verwende. Einzelne Quellen im Internet weisen darauf hin, dass dieser Software wohl mit JBIG2 arbeitet. Evtl. verursacht sie die Probleme. Beim Einsatz der reine Fujitus Tools kann ich das Problem Stand August 2018 (zum Glück) nicht bestätigen.

Gruß Volker

37 |
Volker
| 2018/08/06 08:54 | reply

Hallo David, ich bin kürzlich über deinen Vortrag auf das Thema aufmerksam geworden. Ich musste feststellen, dass auch meine Firma im Besitz eines Xerox WC 7525 ist. Daher habe ich mir es nicht nehmen lassen und mal deine Beispieldatei durchgejagt und siehe da: es kamen die erwarteten falschen Scan-Ergebnisse heraus. Ich habe gleich eine E-Mail mit meinen Ergebnissen an den internen Verteiler geschickt. Vielen Dank an dich! Ohne deinen Einsatz wäre uns das nie aufgefallen.

VG Erik

38 |
Erik
| 2018/08/13 18:09 | reply

Sehr geehrter Herr Kriesel,

danke für diesen Vortrag!

Der Moment, an dem ich am meisten Schlucken musste, war, als Sie in der Fragerunde die damals völlig unverdächtig flappsige Bemerkung mit einer einstürzender Autobahnbrücke machten.

Natürlich will ich hier weder Gerüchte in die Welt setzen, noch Sie in irgendeiner Weise für diese Bemerkung rügen. Das steht mir gar nicht zu, und es ist eher unwahrscheinlich, dass ein Gerät von Xerox daran beteiligt war, aber nach dem Brückeneinsturz in Genua vor ein paar Tagen wirkt diese Bemerkung wie eine erschreckende Vorhersage auf ein Beispiel, was uns bevorstehen könnte, wenn diese Geräte nicht nur Zahlen von Quadratmetern auf Bauplänen, sondern z.B. auch Mischungsverhältnisse von Baumaterialien vertauscht haben.

Man mag es sich gar nicht vorstellen. :(

Viele Grüße, W. Klein

39 |
Wolfgang Klein
| 2018/08/18 18:39 | reply