Reverse Engineering: Pin sucht Kontakt
Im dritten Teil meiner fünfteiligen Serie zur Analyse eines Oszilloskops per Reverse Engineering versuche ich, herauszufinden, welche Funktion die GPIO-Pins des SoC haben. Bis jetzt habe ich es geschafft, Linux auf dem Oszilloskop zum Laufen zu bekommen und weiß, was alles in dessen Flashspeicher steckt.
Wo anfangen?
Disassemblierten Binärcode zu analysieren, ist aufwendig und langweilig. Die 3 MByte große Binärdatei mit dem originalen Betriebssystem des Oszilloskops durchzugehen, würde Jahre brauchen, deswegen habe ich beschlossen, eine Abkürzung zu nehmen.
Was mich am meisten interessiert, ist Code, der mit der Hardware interagiert, sprich die GPIO-Pins. Üblicherweise lädt der entsprechende Code zum Zugriff auf die GPIO-Register die Basis-Adresse der zugehörigen GPIO-Bank in ein CPU-Register und steuert dann den Pin mit einer Kombination aus CPU-Register plus Offset-Wert des jeweiligen GPIO-Registers des betreffenden Pins. Eine Bank ist hier ein zusammenhängender Speicherbereich, der eine Anzahl von Pins und ihre Eigenschaften repräsentiert.
Die Basis-Adresse für die GPIO-Register ist 0x56000000. Und der Binärcode für eine ARM-Instruktion, um einen Wert in ein CPU-Register zu laden, ist 0xe3a0?456. Das Fragezeichen steht für die CPU-Register-Nummer und die 56 am Ende sind die höchsten 8 Bit der Adresse. Die Suche ist nun recht trivial, ich gebe die Betriebsystemdatei "os" aus, leite die Ausgabe an das Kommandozeilenprogramm less um und verwende dessen /-Kommando, um nach den Bytes der Instruktionen suchen zu lassen.
Dann benutze ich das Programm Medusa, um den Code um die Fundstellen anzuschauen und zu analysieren. Immer noch aufwendig, aber immer noch besser, als den gesamten Code durchzugehen.
Ein Blick auf die Fundstellen
So finde ich zum Beispiel einige Wrapper-Funktionen, mit denen die GPIO-Pins GPB4 und GPB9 gesteuert werden.
Das ist an sich noch wenig nützlich. Aber ich versehe die Funktionen mit beschreibenden Namen und setze die Disassemblierung fort. So stoße ich auf den Code, wo diese Funktionen aufgerufen werden.
Wie bereits an den Funktionsnamen erkennbar, habe ich schon herausgefunden, dass diese Pins für den I2C-Bus benutzt werden. Die erste Funktion i2c_start konfiguriert die beiden Pins für die Ausgabe und setzt dann GPB4 und GPB9 auf Low. Die zweite Funktion setzt GPB4 zuerst auf Low, GPB9 auf High und danach GPB4 ebenfalls auf High.
Hier ist eine Abbildung aus einem I2C-Tutorial(öffnet im neuen Fenster), wie der Signalverlauf auf dem I2C-Bus aussieht:
Wenn GPB4 die SDA-Leitung ansteuert und GBP9 die SCL-Leitung entspricht der Code perfekt den I2C-Start- und Stop-Signalen. Weitere Funktionen im Binärcode an dieser Stelle implementieren Schreib- und Lese-Operationen für den I2C-Bus.
I2C mit Linux
Wenden wir das Wissen unter Linux an. Linux bringt bereits den I2C-Treiber i2c-gpio mit, der zwei beliebige GPIO-Pins als I2C-Bus ansteuern kann. Ich ergänze die Maschinendefinition des Betriebssystems "mach-smdk.4110.c" in meiner Linux-Portierung entsprechend:
pre> static struct i2c_gpio_platform_data sds7102_i2c_pdata = { .sda_pin = S3C2410_GPB(4), .scl_pin = S3C2410_GPB(9), }; static struct platform_device sds7102_i2c_chrontel = { .name = "i2c-gpio", .id = 1, .dev = { .platform_data = &sds7102_i2c_pdata, }, }; static struct platform_device *smdk2416_devices[] __initdata = { ... &sds7102_i2c };Ich starte wieder das Oszilloskop, lade den Treiber und benutze das Programm i2cdetect aus der I2C-Tools-Suite, um auf den I2C-Bus zu schauen:
pre> # i2cdetect -y 1 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 70: -- -- -- -- -- -- 76 --Es gibt anscheinend tatsächlich ein I2C-Gerät mit der Adresse 0x76 auf dem Bus. Ich blättere durch die Datenblätter der Bauteile des Oszilloskops, die ich inzwischen angesammelt habe. Für den VGA-Chip Chrontel CH7026 kann ich keines finden, aber eines für den CH7028, der wie ein naher Verwandter scheint. Und tatsächlich, der Chip verwendet I2C für die Kommunikation und seine Adresse ist 0x76!
Das Registerformat des Chrontel-Chips wird vom i2cdump-Werkzeug unterstützt, so gebe ich mir die Registerinhalte aus.
Register 0 enthält die Geräte-ID und sollte laut Datenblatt den Wert 0x54 beinhalten. Das ist ebenfalls richtig. Nicht dass ich im Moment sehr an VGA interessiert wäre, aber wenn ich den Ausgang nutzen wollte, wäre das mein Startpunkt.
Vielleicht werde ich bei Gelegenheit probieren, einen VGA-Monitor anzuschließen und Linux neu zu starten, ohne einen Reset des Chrontel-Chips durchzu führen. Vielleicht erhalte ich dann auf dem Monitor ein Bild und kann die Chrontel-Konfiguration für eine Analyse in einer Datei sichern.
Das sind zwei weitere Pins von hundert, deren Funktion ich jetzt kenne. Schritt für Schritt erfahre ich so mehr.
Den FPGA programmieren
Ich stoße schließlich auch auf den Code, der die "fp"-Datei lädt und danach anscheinend den FPGA anspricht.
Übersetzt in Pseudo-C macht er ungefähr das, die Kommentare sind von mir:
pre> /* Reset FPGA by driving PROG_B low for a short while */ gpio_set_value(GPK7, 0); /* drive PROG_B low */ delay_calibrated(100); gpio_set_value(GPK7, 1); /* drive PROG_B high */ /* Wait for INIT_B to go high which indicates that the FPGA is ready */ for (i = 0; 100 > i; i++) { if (gpio_get_value(GPK13)) /* read INIT_B */ break; delay_calibrated(50); } if (i == 100) { /* error handling */ }Dann durchläuft der Code jedes Byte der Datei und tut das:
In Pseudo-C:
pre> /* Shift 8 bits of data into the FPGA */ uint8_t b = fpga_data[i]; for (j = 0; 8 > j; j++) { gpio_set_value(GPK3, 1); /* drive CCLK high */ if ((b < j) & 0x80) gpio_set_value(GPK11, 1); /* set DIN to 1 */ else gpio_set_value(GPK11, 0); /* set DIN to 1 */ gpio_set_value(GPK3, 0); /* drive CCLK low */ }Das sieht sehr danach aus, als ob die FPGA-Daten Bit für Bit auf die Datenleitung geschoben werden.
Wenn alle Bytes durchlaufen wurden, passiert das:
Der Algorithmus entspricht praktisch genau der Beschreibung aus dem Spartan-6-FPGA-Konfigurationshandbuch(öffnet im neuen Fenster) zum Programmieren eines Xilinx-FPGA im Serial-Slave-Mode.
Mal eben einen Treiber schreiben
Ich habe bereits Ladeprogramme für Xilinx-FPGAs geschrieben, finde aber spontan davon keines wieder, so schreibe ich einen neuen Linux-Treiber. Der Treiber erzeugt ein Device namens /dev/fpga, das genauso funktioniert wie der oben beschriebene Binärcode.
Wird das "/dev/fpga/"-Device geöffnet, setzt der Treiber den Pin PROG_B am FPGA, der mit dem Pin GPK7 des SoC verbunden ist, kurz auf Low und wartet darauf, dass am Pin INIT_B/GPKG13 ein High-Pegel anliegt. Daten, die an das Device geschrieben werden, schiebt der Treiber an den Pin DIN/GPK11 weiter und benutzt den Pin CCLK/GPK3 für das Taktsignal. Wird das Device geschlossen, wartet der Treiber darauf, dass der Signalpegel an Pin DONE/GPK5 auf High wechselt. Das FPGA-Image kann so unter Linux durch einen einfachen Schreibvorgang auf den FPGA geladen werden.
Damit kann das originale FPGA-Image, das sich in der "fp"-Datei im Speicherabbild befindet, unter Linux geladen werden. Ich habe auch ein eigenes kleines FPGA-Image erzeugt, das am Pin INIT_B vom FPGA einmal pro Sekunde ein Signal an- und ausgeschaltet. Ich muss in Linux nur den Zustand des SoC-Pins GPK13 anschauen und kann den Wechseln verfolgen.
Fünf weitere Pins erledigt, trotzdem noch jede Menge übrig.
Mehr, mehr, mehr!
GPB3 kontrolliert die Display-Helligkeit. Ist er aus, ist das Display etwas dunkler, ist er an, wird es heller. Da GPB3 auch als Timer- beziehungsweise PWM-Ausgang programmiert werden kann, könnte es möglich sein, die Helligkeit in mehreren Schritten zu dimmen. Außerdem finde ich heraus, dass GPF3 die Run/Stop-LED an- und ausschaltet. Wie die Farbe gesteuert wird, weiß ich noch nicht.
GPF2 steht in enger Verbindung mit dem Code, der sich um den USB-Client-Anschluss kümmert. Wenn ich die Firmware richtig verstanden habe, dient er zum Erkennen einer eingesteckten USB-Verbindung (VBUS detect), wie es auch bei den SoC der SMDK2416-Familie dokumentiert wird. Allerdings hat sich dessen Signal nicht verändert, wenn ich einen PC über ein USB-Kabel angesteckt oder herausgezogen habe. Hier muss ich noch einmal intensiver testen. Ich stoße zudem auf den Code zur Ansteuerung des Ethernet-Chips per SPI-Bus über die Pins GPE11, GPE12 und GPE13, der Pin GPF1 empfängt Interrupt-Signale vom Chip. Das wusste ich aber schon.
Ich finde aber auch einige Dinge, die keinen Sinn ergeben. Einige Codeteile betreffen die Pins GPJ2 und GPJ3 des SoC. Diese Pins gibt es nicht und sie sind auch in der Dokumentation nicht zu finden. Es gibt eine einzelne Zeile in der Dokumentation, welche die Adressen der Pins angibt. Eventuell hat jemand bei Samsung diese Zeile einfach übersehen, als das Handbuch geschrieben wurde und Inhalte von früheren Dokumentationen eingefügt wurden. Es ergibt für die Firmware trotzdem keinen Sinn, dass diese Pins angesprochen werden.
Die Firmware steuert noch eine ganze Reihe weiterer Pins an, die ich bislang nicht kenne, aber sie stehen auf meiner Todo-Liste.
Pin-Suche, die Zweite
Mittlerweile habe ich das Oszilloskop erneut aufgeschraubt, diesmal will ich weitere Pins und ihre Verwendung identifizieren. Wieder fange ich an, Pins an- und auszuschalten, diesmal allerdings systematischer.
Ich beginne mit GPA1, dem ersten GPIO-Pin, der ein Klickgeräusch im Oszilloskop verursachte. Dafür schreibe ich ein Shell-Programm, das den Pin einmal pro Sekunde schaltet:
pre> # Use /sys gpio support to export GPA1 to userspace echo 1 >/sys/class/gpio/export # Make GPA1 an output echo out >/sys/class/gpio/gpio1/direction # Toggle GPA1 every second while sleep 1; do echo 0 >/sys/class/gpio/gpio1/value sleep 1 echo 1 >/sys/class/gpio/gpio1/value doneIch kann wieder das Klicken hören, aber nicht genau bestimmen, von welchem Relais es stammt. So teste ich die Anschlüsse der Relais mit dem Multimeter durch. Ich finde heraus, dass GPA1 einen der Relais für Kanal 1 am Analog-Frontend ansteuert.
Durch den disassemblierten Quellcode der Firmware weiß ich, dass GPA12 und GPA15 oft zur gleichen Zeit geändert werden, sie analysiere ich als Nächstes. GPA12 bleibt erst einmal ein Mysterium, aber GPA15 steuert das andere Relais von Kanal 1.
Ich gehe die Liste der als Ausgang geschalteten GPIO-Pins weiter durch und teste viele Bauteile im Analog-Frontend. Dabei gehe ich teilweise von Vermutungen aus, die ich aufgrund des Firmware-Codes aufgestellt habe. Zum Beispiel werden GPA0 und GPD8 meist gemeinsam geschaltet und es zeigt sich, dass sie zwei Solidstate-Relais steuern.
So gelingt es mir schließlich, folgende Liste aufzustellen:
pre> GPA0 Channel 1 solid state relay (U8) GPA1 Channel 1 mechanical relay (KE) GPA15 Channel 1 mechanical relay (KD) GPD8 Channel 2 solid state relay (U7) GPE1 Channel 2 mechanical relay (KC) GPH12 Channel 2 mechanical relay (KB) GPC7 External trigger mechanical relay (KA) GPE3 Mechanical relay with unknown function (KF)In der Firmware werden GPC7 und GPE3 ebenfalls gleichzeitig gesteuert. Es ist deshalb sehr wahrscheinlich, dass das unbekannte Relais an GPE3 etwas mit dem Eingang des externen Triggers zu tun hat.
Als Bonus kann ich auch die Buzzer-Ansteuerung finden:
Ich dachte ursprünglich, dass ich den Pin GPB0 bereits ausprobiert hätte, aber dabei habe ich wohl einen Fehler gemacht. Darum ist es wichtig, alles zweimal zu testen. Da der Pin auch mit einem Timer für eine PWM-Ausgabe kombiniert werden kann, sollte es einfach sein, denn Buzzer verschiedene Frequenzen spielen zu lassen.
Das wird mir langsam alles etwas zu aufwendig. Auf diese Weise jeden Pin zu bestimmen, würde viel Zeit kosten. Schließlich gibt es mehr als hundert Pins und eine Vielzahl potenzieller Bausteine. Ich müsste Tausende von Kombinationen mit dem Multimeter testen. Außerdem würde ich so keine Eingabe-Pins finden.
Arbeite cleverer, nicht fleißiger
Um das zu beschleunigen, schreibe ich einen kleinen Linux-Treiber, der alle unbekannten GPIO-Pins als Eingabe-Pins mit einem Pull-up-Widerstand konfiguriert. Der Treiber liest dann in einer Schleife die Datenregister der Pins und überwacht die Änderungen der Werte. Ändert sich der Wert eines Pins, gibt der Treiber eine Meldung auf der Linux-Konsole aus.
ᐸbild von Multiplexer?>Ich messe zuerst die Spannung am Pin A0 des Multiplexers von Kanal 1 (U31, Pin 8), sie beträgt 3,3 Volt. Mit einem Kabel schließe ich dann A0 mit der Masse kurz. Durchatmen – aber es gibt keine Funken und ich erhalte eine Ausgabe auf der Konsole:Ich schaue auf die Ausgabe und sie besagt, dass das fünfte Bit des GPCDAT-Registers auf Low wechselt, wenn ich den Pin mit dem Kabel berühre und wieder auf High, wenn ich das Kabel entferne. Der SoC hat einen schwachen Pull-up-Widerstand am Pin, wodurch er auf High schaltet. Berühre ich den Endpunkt der Leiterbahn des Pins am A0-Pin, erzwinge ich ein Low-Signal auf der Leiterbahn. Es ist also sehr wahrscheinlich, dass der SoC-Pin GPC5 mit dem A0-Pin des Multiplexers verbunden ist.
Tatsächlich benutze ich kein blankes Kabel, um die Verbindung mit der Masse herzustellen. Einen aktiven Ausgang mit der Masse zu verbinden, kann dazu führen, den Treiberschaltkreis zu beschädigen oder die Stromversorgung kurzzuschließen, sollte es sich um eine Stromschiene handeln. Stattdessen benutze ich zusätzlich einen 330-Ohm-Widerstand. Liegt an einem Pin 3,3 Volt an, begrenzt der Widerstand den Strom auf 10 mAmpere. Dieser Strom ist hoffentlich klein genug, um keine sofortigen Beschädigungen auszulösen. Es ist trotzdem immer noch riskant, aber sicher genug, um Pins zu testen – solange die Verbindung nicht zu lang besteht.
Mit dem Linux-Treiber gelingt es mir schnell, andere Verbindungen zu finden. Der Multiplexer ist mit den folgenden Pins verbunden:
An dieser Stelle habe ich vergessen, die Shutdown- und Enable-Pins des Multiplexers zu prüfen. Ich glaube, die Funktionen sind fest verdrahtet, aber eine Prüfung ist immer besser.
Noch mehr Pins
Ich setze meine Messungen fort und verbinde alle möglichen Pins und Kontakte mit der Masse, um sie auf ein Low-Signal zu ziehen. Es ist sinnvoll, zuerst die Spannung am Kontakt beziehungsweise dem Pin zu prüfen. Beträgt sie bereits 0 Volt, dann ist es sinnlos, den Pin auf Low zu ziehen. Beträgt die Spannung mehr als 3,3 Volt, ist der Pin nicht mit dem SoC oder dem FPGA verbunden, denn sie können nicht mit höheren Spannungen umgehen.
Wenn auf einem Kontakt oder Pin ein Low-Signal anliegt, kann er trotzdem mit dem SoC verbunden sein. Möglicherweise ist ein externer Pull-down-Widerstand stärker als der interne Pull-up-Widerstand im SoC. In dem Fall könnte ich das Kabel über einen Widerstand mit einem 3,3 oder 1,8 Volt-Anschluss verbinden statt dem Masse-Anschluss und so ein High-Signal erzeugen. Alternativ könnte ich im Linux-Treiber auch die internen Pull-down-Widerstände aktivieren und auf den Pins ein High-Signal anlegen.
Ich finde heraus, dass der Pin GPF3 mit dem Widerstand R174 verbunden ist, der nahe beim Steckverbinder für das Frontpanel sitzt. Das ist nicht so merkwürdig, wie es mir zuerst vorkam. Wenn ich GPF3 umschalte, leuchtet der Run/Stop-Button auf. Der Pin muss also irgendwie mit dem Frontpanel verbunden sein. GPH3 ist mit dem Widerstand R80 daneben verbunden, aber nichts passiert, wenn ich den Pin ansteuere. Keiner der anderen Kontakte am Steckverbinder für das Frontpanel löst irgendetwas bei meinem Test aus.
Der mysteriöse Steckverbinder U60 scheint mit vielen GPIO-Pins des SoC verbunden zu sein. Anscheinend handelt es sich um eine Debug-Schnittstelle, wo einige ungenutzte Pins anliegen:
pre> 1 GPL8 2 GPE8 3 GPE10 4 GPH2 5 GPF7 6 GPB5 7 GPH5 8 GPF4 9 GPG3 10 GPG1 11 GPG5 12 GPK9 13 GPK14 14 GPK10 15 GPK12 16 GPK3 17 GND 18 GND 19 7.3V, not the same wire as for pin 20 20 7.3V, not the same wire as for pin 19An den GPK-Pins liegen 1,8 Volt an, an den übrigen 3,3 Volt. Ich hatte zuerst keine Ahnung, wo die 7,3 Volt herkamen und ob die beiden Kontakte sich überhaupt unterschieden. Wie mir aber später aufgeht, handelt es sich wohl um die Spannung der Stromversorgung des Oszilloskops. Ich speise es mit 7,5 Volt aus einem Netzteil über den Batterieeingang. Die Differenz ergibt sich wohl durch mein nicht kalibriertes Multimeter.
Ich finde es schade, dass die Owon-Ingenieure die Verbindungen der Pins vom SoC nicht etwas anders angeordnet haben. Es wäre mit kleinen Layoutänderungen auf der Platine wohl möglich gewesen, die Kontakte der SD/MMC-Schnittstelle am Steckverbinder anzulegen. Oder wenigstens eine serielle Schnittstelle oder die I2S-Schnittstelle. Natürlich können viele Protokolle einfach durch Bitbanging an den obigen Pins simuliert werden. Aber ohne Hardware-Unterstützung ist das langsamer.
Den Pin GPF2 und seine Funktion habe ich bereits früher durch Zufall entdeckt. Er dient zum Erkennen einer USB-Verbindung am USB-Client-Anschluss über das VBUS-Signal. Allerdings gibt er mir immer noch Rätsel auf. Wenn ich ein USB-Kabel einstecke und entferne, liefert mein Linux-Treiber keinerlei Ausgabe. Wo liegt mein Fehler? Schließlich finde ich heraus, dass das VBUS-Signal in einen Spannungsteiler eingespeist und von dort aus Pin GPF2 zugeführt wird. Ist der interne Pull-up-Widerstand durch meinen Treiber aktiviert, liegt an GPF2 ein High-Signal an, wenn keine USB-Verbindung besteht. Wird ein USB-Kabel angeschlossen, wird der GPF2 ebenfalls auf High gezogen. Da sich das Signal also nicht ändert, registriert mein Treiber auch keine Änderung. Ich deaktiviere also den Pull-up-Widerstand für GPF2 und nun funktioniert die VBUS-Erkennung. Bis dahin habe ich die direkte Verbindung von VBUS-Signal und dem Signalwert an GPF2 als gegeben vorausgesetzt.
Mein Linux-Treiber macht mich auch auf den merkwürdigen Pin GPB6 aufmerksam. Sein Zustand ändert sich gelegentlich, ohne dass ich bislang einen Grund oder einen Zusammenhang zu meinen Aktionen erkennen konnte.
Ein kurzer Schreckmoment
Indem ich die GPIO-Pins gegen Masse schalte, erfahre ich mehr über ihre Verwendung. Dabei mache ich aber einige Fehler. Ich vergesse, das Register für den Pin GPH2 korrekt zu konfigurieren. Als ich ihn am Kontakt 4 der Debug-Schnittstelle kurzschließe, passiert deshalb gar nichts, weshalb ich zuerst denke, der Kontakt wäre gar nicht belegt. Mehrmals verliere ich auch die Übersicht, was ich schon getestet habe, und muss von Neuem beginnen. Und hin und wieder verbinde ich auch die Stromschiene mit der Masse. Es gibt Funken und das Oszilloskop stellt den Betrieb ein. Ich empfehle das nicht zur Nachahmung.
Einige GPIO-Pins des SoC, wie die in der GPA-Bank, können nur als Ausgang konfiguriert werden, nicht als Eingaben. Hier bleibt mir nichts Anderes übrig, als sie einzeln zu schalten und mögliche Kontakte auf der Leiterplatine durchzutesten.
Einige Bauteile wie die variablen Verstärker (Variable Gain Amplifier), die Digital-Analog-Konverter (DAC, U2, U24 und U37), der ADF4360-7-Taktgenerator (U97) und der AT88SC Cryptomemory-Chip (U38) scheinen nicht mit dem SoC verbunden zu sein.
Manche Pins habe ich immer noch nicht ausfindig ausmachen können, wie GPA12, GPA5, GPA7, GPG2 und GPH13, obwohl sie in der Firmware angesprochen werden. Ich hoffe, sie machen nichts Wichtiges.
Im vierten Teil der Artikelserie wird Christer Weinigel die Pinbelegung des FPGA erkunden. Dazu wird er eine ähnliche Technik nutzen wie beim SoC, muss diese aber deutlich modifizieren.
Christer Weinigel(öffnet im neuen Fenster) ist freiberuflicher Ingenieur in seinem eigenen Unternehmen (Weinigel Ingenjörsbyrå AB). Er entwickelt hardwarenahe Software, arbeitet mit Embedded Betriebssystemen und spielt deshalb auch öfters direkt mit Hardware.
Diese Artikelserie erschien zuerst in seinem Blog. Mit seiner Erlaubnis hat Golem.de seine Artikel ins Deutsche übersetzt und dabei einige Kürzungen und Ergänzungen vorgenommen, damit der Inhalt auch Einsteigern verständlich ist.
- Anzeige Hier geht es zu Linux: Das umfassende Handbuch bei Amazon Wenn Sie auf diesen Link klicken und darüber einkaufen, erhält Golem eine kleine Provision. Dies ändert nichts am Preis der Artikel.