Discussion:
RAM auslesen nach dem Strom aus war
(zu alt für eine Antwort)
Michael Reichenbach
2008-01-24 21:45:27 UTC
Permalink
Kann man aus normalen RAM Speicher (SD, DDR, etc.) definitiv nichts mehr
wiederherstellen nach dem die Stromzufuhr unterbrochen war oder gibt es
da noch Möglichkeiten?
Carsten Krueger
2008-01-24 21:52:16 UTC
Permalink
Post by Michael Reichenbach
Kann man aus normalen RAM Speicher (SD, DDR, etc.) definitiv nichts mehr
wiederherstellen nach dem die Stromzufuhr unterbrochen war oder gibt es
da noch Möglichkeiten?
Da kann man kann man nichts mehr auslesen.
Wenn die Stromversorgung für Millisekunden zusammenbricht ist nichts mehr
zu holen.

Gruß Carsten
--
ID = 0x2BFBF5D8 FP = 53CA 1609 B00A D2DB A066 314C 6493 69AB 2BFB F5D8
http://www.realname-diskussion.info - Realnames sind keine Pflicht
http://www.spamgourmet.com/ + http://www.temporaryinbox.com/ - Antispam
cakruege (at) gmail (dot) com | http://www.geocities.com/mungfaq/
Sebastian G.
2008-01-24 22:49:22 UTC
Permalink
Post by Carsten Krueger
Post by Michael Reichenbach
Kann man aus normalen RAM Speicher (SD, DDR, etc.) definitiv nichts mehr
wiederherstellen nach dem die Stromzufuhr unterbrochen war oder gibt es
da noch Möglichkeiten?
Da kann man kann man nichts mehr auslesen.
Wenn die Stromversorgung für Millisekunden zusammenbricht ist nichts mehr
zu holen.
Peter Gutmann war/ist da anderer Meinung. Der sprach von Sekunden, und bei
sofortiger Applikation von Kuehlung sogar von Tagen und Wochen.

Natuerlich ist die Erfolgsrate nicht sonderlich hoch...
Andreas Beck
2008-01-24 23:14:42 UTC
Permalink
Post by Sebastian G.
Post by Carsten Krueger
Post by Michael Reichenbach
Kann man aus normalen RAM Speicher (SD, DDR, etc.) definitiv nichts mehr
wiederherstellen nach dem die Stromzufuhr unterbrochen war oder gibt es
da noch Möglichkeiten?
Da kann man kann man nichts mehr auslesen.
Wenn die Stromversorgung für Millisekunden zusammenbricht ist nichts mehr
zu holen.
Peter Gutmann war/ist da anderer Meinung.
/me too.

Schließlich sind _D_RAMs _d_ynamische RAMs, bei denen eine Speicherzelle
im wesentlichen durch einen Kondensator und einen Transistor
implementiert ist.

Solange ersterer noch genügend Ladung hat, ist die theoretisch
auslesbar.
Post by Sebastian G.
Der sprach von Sekunden,
Das klingt realistisch. Sieht man auch ab und zu bei RAM, das beim
Rechnerstart nicht (vollständig) gelöscht wird, z.B. bei Grafikkarten-RAM.

Nach kurzen Stromunterbrechungen sieht man beim Booten ab und zu "Reste"
des letzten Bildes, nachdem der Mode schon eingetsellt ist und bevor der
Inhalt dann tatsächlich gelöscht wird (ja, ich halte das für einen Bug
im Treiber).

Es ist nur ein wenig schwierig, abzuschätzen, wie lange die Bauteile
dann tatsächlich stromlos waren. Ist das Bild noch komplett vorhanden
(bis auf überschriebene Teile), hat evtl. einfach ein Kondensator auf
der Grafikkarte noch eine Weile gehalten.

Ich habe allerdings auch schon teilzerstörte Bilder gesehen, die nicht
nach "bisher schon überschrieben" aussahen. Mehr nach "diese Zeile/Spalte
im RAM hatte wohl einen etwas schwächeren Treiber."


Allerdings dürfte der genaue Mechanismus für die Frage des OP keine
Rolle spielen. Ich denke mal, was er wissen will ist:

"Wie lange muß es her sein, daß man auf den Aus-Schalter gehauen hat,
damit ein sofort danach loslegender Experte nichts verwertbares mehr
findet?"

Das dürfte im Normalfall im Bereich von 10s liegen. Bis eben die
Pufferkondensatoren leer sind. Wie lange danach das RAM noch hält
ist eher sekundär.


10s kann in einige Fällen auch noch zu kurz geschätzt sein:

Bei einer alten Grafikkarte hatte ich auch den Effekt, dass diese ab und
zu nach einem ungeplanten Reboot nicht mehr zum Starten brachte.
Bis man den Rechner > ca. 30s ausschaltete.
Ich vermute, dass irgendwelche Stützkondensatoren einige
Konfigurationsregister ziemlich lange erhalten konnten.
Post by Sebastian G.
und bei sofortiger Applikation von Kuehlung sogar von Tagen und Wochen.
Möglich. Man muß halt die Leckströme runterdrücken.
Post by Sebastian G.
Natuerlich ist die Erfolgsrate nicht sonderlich hoch...
Zumal relevante Kühlung eher sperrig ist.


CU, Andy
Sebastian G.
2008-01-25 00:08:40 UTC
Permalink
Post by Andreas Beck
Schließlich sind _D_RAMs _d_ynamische RAMs, bei denen eine Speicherzelle
im wesentlichen durch einen Kondensator und einen Transistor
implementiert ist.
Solange ersterer noch genügend Ladung hat, ist die theoretisch
auslesbar.
Wobei Gutmann da eine interessantee Entdeckung anstellte: Je oefter man den
Inhalt der Zelle wechselt, umso wahrscheinlicher ist es, dass sich ihr
letzter Zustand im Dielektrum des Kondensators (typischerweise
Siliziumdioxid) niederschlaegt. Je laenger man den gleichen Inhalt behaelt
und immer wider refreshed, desto mehr wird das Dielektrum strapaziert und
desto schlechter ist die Wiederherstellbarkeit.

Natuerich sollte man trotzdem wichtige Daten im RAM so bald wie moeglich
ueberschreiebn, da das Risiko, dass die Daten von anderen Prozessen
ausgelesen oder gar auf die Plate geswappt werden, deutlich relevanter ist.
Post by Andreas Beck
"Wie lange muß es her sein, daß man auf den Aus-Schalter gehauen hat,
damit ein sofort danach loslegender Experte nichts verwertbares mehr
findet?"
Wobei auch hier durch einen externen Schalter sicherzustellen ist, dass
wirklich ein Hard-Out und kein Soft-Out erfolgt.Bei Soft-Out werden
ueblicherweise die PS/2- und USB-Ports sowie das Mainboard noch mit Strom
versorgt, und wenn man bedenkt, dass fuer Suspend-to-RAM ebenfalls eine
Logik auf dem Mainboard implementiert ist, dann sollte einen es nicht
wundern, wenn auch bei Soft-Out noch der RAM refreshed wird.
Post by Andreas Beck
Post by Sebastian G.
und bei sofortiger Applikation von Kuehlung sogar von Tagen und Wochen.
Möglich. Man muß halt die Leckströme runterdrücken.
In der Beschreibung las sich das aber ganz anders. Relevant ist nicht die
Ladung des Kondesnators, sondern die physichemische Struktur des Dielektrums.
Post by Andreas Beck
Post by Sebastian G.
Natuerlich ist die Erfolgsrate nicht sonderlich hoch...
Zumal relevante Kühlung eher sperrig ist.
Wobei es Leute gibt, die mit sowas ihre CPU kuehlen und sich dann freuen,
fuer 200 Watt mehr ihre CPU von 3 auf 4 GHz hochgepruegelt zu haben und
dabei immernoch konstant -40 deg C zu erreichen, um regelmaessig
Kondenswassereis abzukratzen.
Juergen P. Meier
2008-01-25 08:09:56 UTC
Permalink
Post by Sebastian G.
Post by Carsten Krueger
Post by Michael Reichenbach
Kann man aus normalen RAM Speicher (SD, DDR, etc.) definitiv nichts mehr
wiederherstellen nach dem die Stromzufuhr unterbrochen war oder gibt es
da noch Möglichkeiten?
Da kann man kann man nichts mehr auslesen.
Wenn die Stromversorgung für Millisekunden zusammenbricht ist nichts mehr
zu holen.
Peter Gutmann war/ist da anderer Meinung. Der sprach von Sekunden, und bei
Millisekunden. Es mag langsame Schaltungen geben, die sekunden
ueberdauern, aber mit einer FEhlerquote, die alles ausgelesenes
unbrauchbar machen wuerde.
Post by Sebastian G.
sofortiger Applikation von Kuehlung sogar von Tagen und Wochen.
Ein Trick waere das Die mit einem empfindlichen Infrarotmikroskop
abzufotographieren. Da waere das eher Kontraproduktiv.
Post by Sebastian G.
Natuerlich ist die Erfolgsrate nicht sonderlich hoch...
Wenn du ein Bit pro 10000 erfolgreich richtig auslesen kannst, hilft
dir das als Angreifer genau garnichts. Da ist Raten effektiver.

Juergen
--
Juergen P. Meier - "This World is about to be Destroyed!"
end
If you think technology can solve your problems you don't understand
technology and you don't understand your problems. (Bruce Schneier)
Sebastian G.
2008-01-25 15:33:37 UTC
Permalink
Post by Juergen P. Meier
Post by Sebastian G.
Natuerlich ist die Erfolgsrate nicht sonderlich hoch...
Wenn du ein Bit pro 10000 erfolgreich richtig auslesen kannst, hilft
dir das als Angreifer genau garnichts. Da ist Raten effektiver.
Man wird von 10000 Bits statistisch im Mittel etwa 5000 richtig auslesen,
allein durch Raten. Selbst nur 5100, also eine Rate von 51%, ist schon ein
deutlicher Gewinn, der statistisch signifikant ist.
Dirk Ohme
2008-01-28 20:56:49 UTC
Permalink
Sebastian G. schrieb im Newsbeitrag
Post by Sebastian G.
Man wird von 10000 Bits statistisch im Mittel etwa
5000 richtig auslesen, allein durch Raten.
Schön ... nachdem aber nicht nur die Anzahl der Treffer von Bedeutung
sind, sondern auch die Reihenfolge bzw. man hinterher wissen sollte,
welche aufeinanderfolgenden Bits richtig geraten wurden oder nicht,
bringt Dir Deine Erkenntnis wohl nur eines: Sie ist nutzlos! Es geht
hier nicht um Lotto, wo es egal ist, in welcher Reihenfolge die Zahlen
gezogen werden. Es geht hier um ein System von 10.000 mal 0,5
multipliziert ... 0,5 * 0,5 * 0,5 * ... also viel Spaß beim Raten!
Post by Sebastian G.
Selbst nur 5100, also eine Rate von 51%, ist schon ein deutlicher
Gewinn, der statistisch signifikant ist.
Blubber, sülz ... mit etwas Nachdenken wirst Du feststellen, dass es
eine Illusion ist! Und dazu braucht man das noch nicht einmal studiert
haben ... denn mit jeder Speicherstelle halbiert sich Deine
Wahrscheinlichkeit der genauen Vorhersage. Dazu wird noch kommen,
dass, ganz un-statistisch, manche Bereiche ein Block-Verhalten
aufweisen werden, d.h. Du noch nicht einmal sicher sein kannst, dass
die Umgebung im gesamten Speicher stabil ist.

Denn: Ist der Speicher ohne Refresh, so benötigt das Auslesen eine
Zeit x ... womöglich entzieht der Lesevorgang dem Speicher Energie,
d.h. gegen Ende des Speichers wird die Genauigkeit weitaus schlechter
sein als zu Beginn des Speicher(auslesens). Ist der Refresh hingegen
wieder aktiviert, ist es denkbar, dass in diesem Moment Speicherzellen
im undefinierten Bereich willkürlich auf einen definierten Zustand
umkippen. Also ich weiss ja nicht, aber bei einem digitalen Auslesen
scheinen mir da doch zuviele Störeinflüsse zu bestehen ...

Da halte ich ein Angriffszenario, bei dem das laufende System
kompromittiert wird und so der Schlüssel mitgeschnitten wird, für
deutlich wahrscheinlicher! Oder man wendet gleich "brute force" auf
die verschlüsselten Daten an ... falls der Algorithmus nicht bereits
in Teilen von der NSA kompromittiert wurde ;-)

Gruß, Dirk
Sebastian G.
2008-01-29 01:54:12 UTC
Permalink
Post by Dirk Ohme
Schön ... nachdem aber nicht nur die Anzahl der Treffer von Bedeutung
sind, sondern auch die Reihenfolge bzw. man hinterher wissen sollte,
welche aufeinanderfolgenden Bits richtig geraten wurden oder nicht,
bringt Dir Deine Erkenntnis wohl nur eines: Sie ist nutzlos!
Selbst ein einfacher Wiederholungscode bringt dir schon eine Steigerung der
Zuverlaessigkeit um 50%...
Post by Dirk Ohme
Post by Sebastian G.
Selbst nur 5100, also eine Rate von 51%, ist schon ein deutlicher
Gewinn, der statistisch signifikant ist.
Blubber, sülz ... mit etwas Nachdenken wirst Du feststellen, dass es
eine Illusion ist! Und dazu braucht man das noch nicht einmal studiert
haben ...
Oeh, doch, sollte man. Ich jedenfalls kann dir problemlos einen Kodierer
geben, der bei 5000 Fehlern auf 10000 Bits mit an Sicherheit grenzender
Wahrscheinlichkeit total versagt, aber bei nur einem Fehler weniger mit
ebensolcher Sicherheit eine vollstaendige Rekonstruktion vornimmt.

Und ja, solche Sachen weren praktisch eingesetzt. Bei Festplatten, bei
DVB-S2, bei Warez-durch's-Usenet-Schiebern, ...
Post by Dirk Ohme
Dazu wird noch kommen,
dass, ganz un-statistisch, manche Bereiche ein Block-Verhalten
aufweisen werden, d.h. Du noch nicht einmal sicher sein kannst, dass
die Umgebung im gesamten Speicher stabil ist.
Sowohl Interleaver als auch Ausloeschungscodes freuen sich sehr ueber
erkannte Buendelfehler.
Post by Dirk Ohme
Da halte ich ein Angriffszenario, bei dem das laufende System
kompromittiert wird und so der Schlüssel mitgeschnitten wird, für
deutlich wahrscheinlicher!
Kommt auf die Situation an.
Michael Lawnick
2008-01-29 07:50:26 UTC
Permalink
Post by Dirk Ohme
Denn: Ist der Speicher ohne Refresh, so benötigt das Auslesen eine
Zeit x ... womöglich entzieht der Lesevorgang dem Speicher Energie,
d.h. gegen Ende des Speichers wird die Genauigkeit weitaus schlechter
sein als zu Beginn des Speicher(auslesens).
NAK.
Ein Auslesen bewirkt automagisch einen Refresh der Seite.
Wenn deine CPU also nichts besonderes zu tun hat, kann sie den Refresh
ausschalten und einfach den Speicher auslesen (in Seitensprüngen, sonst
wird evt. die Zeit knapp), dann geht auch nichts verloren.
--
Gruß,
Michael
Carsten Krueger
2008-01-25 13:08:35 UTC
Permalink
Post by Sebastian G.
Der sprach von Sekunden, und bei
sofortiger Applikation von Kuehlung sogar von Tagen und Wochen.
Wenn du den RAM 10% zu langsam refreshst hast du schon lustige
Speicherfehler, im bereich von Sekunden hast du nichts mehr was du lesen
kannst.

Gruß Carsten
--
ID = 0x2BFBF5D8 FP = 53CA 1609 B00A D2DB A066 314C 6493 69AB 2BFB F5D8
http://www.realname-diskussion.info - Realnames sind keine Pflicht
http://www.spamgourmet.com/ + http://www.temporaryinbox.com/ - Antispam
cakruege (at) gmail (dot) com | http://www.geocities.com/mungfaq/
Ansgar -59cobalt- Wiechers
2008-01-25 00:42:58 UTC
Permalink
Post by Michael Reichenbach
Kann man aus normalen RAM Speicher (SD, DDR, etc.) definitiv nichts
mehr wiederherstellen nach dem die Stromzufuhr unterbrochen war oder
gibt es da noch Möglichkeiten?
Da kann man kann man nichts mehr auslesen. Wenn die Stromversorgung
für Millisekunden zusammenbricht ist nichts mehr zu holen.
Das ist schlicht und ergreifend falsch. Selbst mehrere Minuten nach
Unterbrechung der Stromversorgung bestehen noch recht gute Aussichten,
Daten wiederherzustellen. BTST.

cu
59cobalt
--
"The Mac OS X kernel should never panic because, when it does, it
seriously inconveniences the user."
--http://developer.apple.com/technotes/tn2004/tn2118.html
Wolfgang Gerber
2008-01-25 07:06:57 UTC
Permalink
Post by Ansgar -59cobalt- Wiechers
Da kann man kann man nichts mehr auslesen. Wenn die Stromversorgung
für Millisekunden zusammenbricht ist nichts mehr zu holen.
Das ist schlicht und ergreifend falsch. Selbst mehrere Minuten nach
Unterbrechung der Stromversorgung bestehen noch recht gute Aussichten,
Daten wiederherzustellen. BTST.
Das erzähle doch mal den RAMs. Die wissen das anders.


Gruss Wolfgang
--
Achtung Spamfilter: Bei Mailantwort muss das Subjekt
das Wort NGANTWORT enthalten.
Andreas Keppler
2008-02-25 10:11:14 UTC
Permalink
Post by Carsten Krueger
Post by Michael Reichenbach
Kann man aus normalen RAM Speicher (SD, DDR, etc.) definitiv nichts mehr
wiederherstellen nach dem die Stromzufuhr unterbrochen war oder gibt es
da noch Möglichkeiten?
Da kann man kann man nichts mehr auslesen.
Wenn die Stromversorgung für Millisekunden zusammenbricht ist nichts mehr
zu holen.
;-)
(Das Video!)

http://citp.princeton.edu/memory/


Gruß
Andreas
Bernd Eckenfels
2008-01-24 22:11:00 UTC
Permalink
Post by Michael Reichenbach
Kann man aus normalen RAM Speicher (SD, DDR, etc.) definitiv nichts mehr
wiederherstellen nach dem die Stromzufuhr unterbrochen war oder gibt es
da noch Möglichkeiten?
Es geht mit mehr oder weniger hardware Aufwand eine gewisse Zeit.
Sogar/Insbesondere nach einem Reboot (also wenn nicht längere Zeit stromlos).

Allerdings (bei normalem ram) geht es nicht rein mit software (nach
stromlos).

Auslagerungsdatei nicht vergessen.

Gruss
Bernd
Wolfgang Gerber
2008-01-24 23:22:41 UTC
Permalink
Post by Bernd Eckenfels
Post by Michael Reichenbach
Kann man aus normalen RAM Speicher (SD, DDR, etc.) definitiv nichts mehr
wiederherstellen nach dem die Stromzufuhr unterbrochen war oder gibt es
da noch Möglichkeiten?
Es geht mit mehr oder weniger hardware Aufwand eine gewisse Zeit.
ja - ein paar Millisekunden
Post by Bernd Eckenfels
Sogar/Insbesondere nach einem Reboot (also wenn nicht längere Zeit stromlos).
bei einem Reboot wird das RAM nicht stromlos und behält theoretisch
seinen Inhalt. Allerdings wird der wegen kurz fehlendem Refresh
ziemlich durcheinander sein. Also so ziemlich alles verlieren.
Post by Bernd Eckenfels
Allerdings (bei normalem ram) geht es nicht rein mit software (nach
stromlos).
Auch nicht mit Hardware
Post by Bernd Eckenfels
Auslagerungsdatei nicht vergessen.
Was hat jetzt die wieder mit dem RAM zu tun?


Gruss Wolfgang
--
Achtung Spamfilter: Bei Mailantwort muss das Subjekt
das Wort NGANTWORT enthalten.
Michael Lawnick
2008-01-25 07:57:12 UTC
Permalink
Post by Wolfgang Gerber
Allerdings wird der wegen kurz fehlendem Refresh
ziemlich durcheinander sein. Also so ziemlich alles verlieren.
NAK.
Bei mir hielt das Ram (DDR2) mit abgeschaltetem Refresh mind. 30
Sekunden. Um eine hinreichende Wahrscheinlichkeit eines Bitfehlers bei
128MB zu bekommen, musste ich den Refresh 2-3 Min ausschalten.
Ein Cache-Flush vor Start der Untersuchung empfiehlt sich.

Die allg. geforderten 64ms Zykluszeiten sind entweder Bequemlichkeit der
Hersteller oder notwendig für eine *Garantie*.

Gruß,
Michael
Carsten Krueger
2008-01-25 13:09:41 UTC
Permalink
Post by Michael Lawnick
Bei mir hielt das Ram (DDR2) mit abgeschaltetem Refresh mind. 30
Sekunden.
Wie hast du den Refresh deaktiviert?

Gruß Carsten
--
ID = 0x2BFBF5D8 FP = 53CA 1609 B00A D2DB A066 314C 6493 69AB 2BFB F5D8
http://www.realname-diskussion.info - Realnames sind keine Pflicht
http://www.spamgourmet.com/ + http://www.temporaryinbox.com/ - Antispam
cakruege (at) gmail (dot) com | http://www.geocities.com/mungfaq/
Michael Lawnick
2008-01-25 13:35:02 UTC
Permalink
Post by Carsten Krueger
Post by Michael Lawnick
Bei mir hielt das Ram (DDR2) mit abgeschaltetem Refresh mind. 30
Sekunden.
Wie hast du den Refresh deaktiviert?
Den DRAM-Controller abgeschaltet.
Um weiteres Grübeln über die Machbarkeit abzukürzen: Das war eine
PPC-Embedded-Platform, incl. JTAG-Debugger, Codeexecution im Flash. Da
gibt es (fast) nichts, was man nicht tun kann.
--
Gruß,
Michael
Carsten Krueger
2008-01-25 15:01:11 UTC
Permalink
Post by Michael Lawnick
Den DRAM-Controller abgeschaltet.
Bist du sicher, daß der sofort aus war?
10% Abweichung beim Refresh haben bei mir schon ausgereicht um sporadische
Bitfehler zu erzeugen.

Gruß Carsten
--
ID = 0x2BFBF5D8 FP = 53CA 1609 B00A D2DB A066 314C 6493 69AB 2BFB F5D8
http://www.realname-diskussion.info - Realnames sind keine Pflicht
http://www.spamgourmet.com/ + http://www.temporaryinbox.com/ - Antispam
cakruege (at) gmail (dot) com | http://www.geocities.com/mungfaq/
Stefan Reuther
2008-01-25 18:11:19 UTC
Permalink
Post by Carsten Krueger
Post by Michael Lawnick
Den DRAM-Controller abgeschaltet.
Bist du sicher, daß der sofort aus war?
Wenn man das Enable-Bit ausknipst, gehe ich mal davon aus, dass das
wirklich aus ist. Im Zweifelsfall kann man mit einem Oszilloskop
nachschauen. BTDT.
Post by Carsten Krueger
10% Abweichung beim Refresh haben bei mir schon ausgereicht um sporadische
Bitfehler zu erzeugen.
Dann ist da was kaputt.

DDRs reagieren etwas allergisch auf Schwankungen im Takt bzw. zu
langsamen Takt (weil sie halt auf die Bitmitte synchronisieren müssen).
SDRAMs sind da recht robust. Wobei es bei mir darum ging, das SDRAM-
Protokoll "kaputt" zu machen, nicht Daten zu erhalten. Wenn nämlich die
CPU ein Reset bekommt, nachdem sie gerade vom SDRAM ein paar Daten
angefordert hat, belegt der SDRAM nach CL Takten den Bus solange, bis
der ebenfalls durch den Reset ausgeschaltete SDRAM-Controller einen
Taktimpuls schickt und das Byte abholt. Ungünstig, wenn die CPU jetzt
lieber erstmal mit einem anderen Busteilnehmer reden will.


Stefan
Michael Lawnick
2008-01-25 19:16:00 UTC
Permalink
Post by Carsten Krueger
Post by Michael Lawnick
Den DRAM-Controller abgeschaltet.
Bist du sicher, daß der sofort aus war?
Ja.
Post by Carsten Krueger
10% Abweichung beim Refresh haben bei mir schon ausgereicht um sporadische
Bitfehler zu erzeugen.
Da kann ich nichts dazu sagen.
--
Gruß,
Michael
Hanno Foest
2008-01-28 13:44:22 UTC
Permalink
Post by Michael Lawnick
Bei mir hielt das Ram (DDR2) mit abgeschaltetem Refresh mind. 30
Sekunden. Um eine hinreichende Wahrscheinlichkeit eines Bitfehlers bei
128MB zu bekommen, musste ich den Refresh 2-3 Min ausschalten.
Ui, das ist länger, als ich dachte, aber sicherlich möglich. Kommt aber
auch auf die Qualität des eingesetzen RAMs ein.

Folgendes Szenario: Rechner mit Plattenverschlüsselung und verriegeltem
Bildschirm (GUI) wird aufgefunden/gestohlen. Reboot bedeutet: Die Platte
ist verschlüsselt, man kommt nicht mehr an die interessanten Daten ran.
Der Key steht aber irgendwo im RAM, schließlich muß das OS ja die Platte
irgendwie benutzen können.

Also: Bootmedium einlegen, Rechner resetten. Das RAM ist nur für kurze
Zeit (Hardwareinitialiserung) ohne Refresh, der Speichertest
überschreibt fast nichts. Das Bootmedium lädt minimalen Code, der nichts
anderes macht, als den restlichen Arbeitsspeicher über irgendeine
Schnittstelle rauszukopieren, wo man ihn dann bequem untersuchen kann.

Ich denke mal, die Chance, darin den Key für die Plattenverschlüsselung
zu finden, ist ziemlich groß.

http://events.ccc.de/camp/2007/Fahrplan/events/2002.en.html BTW.

Gute Verteidigungsstrategien gegen derartige Angriffe würden mich mal
interessieren. Auf dem Camp wurden IIRC permanentes Außerbetriebsetzen
aller Schnittstellen von Laptops (besonders gefährdet) mit Epoxy
empfohlen. BIOS-Passwörter helfen auch, solange es keinen
harteingestellten Default gibt - allerdings befürchte ich, daß in der
Zeit mit dem BIOS-Prompt auf dem Bildschirm der Refesh-Controller
bereits läuft, und damit die Zeit nicht für den rechtmäßigen Besitzer
bzw. Zersetzung des RAM-Inhalts läuft.

Angesichts der von dir genannten Zeiten muß ich zugeben, die Gefahren
eines derartigen Angriffs bisher unterschätzt zu haben. Danke für die Info.

Hanno
Maik Zumstrull
2008-01-28 13:51:45 UTC
Permalink
Post by Hanno Foest
Folgendes Szenario: Rechner mit Plattenverschlüsselung und
verriegeltem Bildschirm (GUI) wird aufgefunden/gestohlen. Reboot
bedeutet: Die Platte ist verschlüsselt, man kommt nicht mehr an die
interessanten Daten ran. Der Key steht aber irgendwo im RAM,
schließlich muß das OS ja die Platte irgendwie benutzen können.
Also: Bootmedium einlegen, Rechner resetten. Das RAM ist nur für
kurze Zeit (Hardwareinitialiserung) ohne Refresh, der Speichertest
überschreibt fast nichts.
Gute Verteidigungsstrategien gegen derartige Angriffe würden mich mal
interessieren.
Alle Keys in genau das "fast nichts" schreiben, das beim Reboot dann
doch vom BIOS gekillt wird? Hilft allerdings nicht dagegen, dass jemand
den Speicher ausliest, *ohne* den Rechner abzuschalten/rebooten.
Hanno Foest
2008-01-28 14:56:12 UTC
Permalink
Post by Maik Zumstrull
Alle Keys in genau das "fast nichts" schreiben, das beim Reboot dann
doch vom BIOS gekillt wird?
Ich stelle mir das anstrengend vor, herauszubekommen, welcher Bereich
das ist, ohne selber einen Angriff wie beschrieben auf seine eigene
Hardware zu fahren. Bei jeder Hardware von neuem, natürlich.
Post by Maik Zumstrull
Hilft allerdings nicht dagegen, dass jemand
den Speicher ausliest, *ohne* den Rechner abzuschalten/rebooten.
Ich bilde mir ein, mich mit einem anständigen OS, das nicht einfach so
fremden Code bei Hotplug-Aktionen ausführt, davor schützen zu können.
Falls ich mich darin irre, bitte ich um Korrektur. Die PC-Architektur
heutzutage hat manchmal wundersame Features, die ich nicht allesamt kenne.

Hanno
Christian Marg
2008-01-28 15:13:29 UTC
Permalink
Hallo,
Post by Hanno Foest
Ich bilde mir ein, mich mit einem anständigen OS, das nicht einfach so
fremden Code bei Hotplug-Aktionen ausführt, davor schützen zu können.
Falls ich mich darin irre, bitte ich um Korrektur. Die PC-Architektur
heutzutage hat manchmal wundersame Features, die ich nicht allesamt kenne.
man kann wohl über Firewire direkt auf den Speicher zugreifen,
möglicherweise auch vom Betriebssystem unbemerkt...

bye
Christian
Ansgar -59cobalt- Wiechers
2008-01-28 15:29:40 UTC
Permalink
Post by Christian Marg
Post by Hanno Foest
Ich bilde mir ein, mich mit einem anständigen OS, das nicht einfach
so fremden Code bei Hotplug-Aktionen ausführt, davor schützen zu
können. Falls ich mich darin irre, bitte ich um Korrektur. Die
PC-Architektur heutzutage hat manchmal wundersame Features, die ich
nicht allesamt kenne.
man kann wohl über Firewire direkt auf den Speicher zugreifen,
möglicherweise auch vom Betriebssystem unbemerkt...
Da ist ein "möglicherweise" zuviel, das müssen wir leider abziehen.

cu
59cobalt
--
"The Mac OS X kernel should never panic because, when it does, it
seriously inconveniences the user."
--http://developer.apple.com/technotes/tn2004/tn2118.html
Hanno Foest
2008-01-28 16:02:46 UTC
Permalink
Post by Ansgar -59cobalt- Wiechers
Post by Christian Marg
man kann wohl über Firewire direkt auf den Speicher zugreifen,
möglicherweise auch vom Betriebssystem unbemerkt...
Da ist ein "möglicherweise" zuviel, das müssen wir leider abziehen.
Ich schätze mal, das wird eher schwierig, wenn das OS keinen Treiber für
die Karte laden mag. Aber OK, mit dem Feuerdraht hab ich noch nicht mehr
gemacht, als nen externes Laufwerk anzuschließen. Falls jemand nen Link
dazu hat, was man alles für unituitive Dinge man damit noch so alles
anstellen kann: Interesse.

Hanno
Christian Marg
2008-01-28 16:29:04 UTC
Permalink
Post by Hanno Foest
Ich schätze mal, das wird eher schwierig, wenn das OS keinen Treiber
für die Karte laden mag.
Nix Treiber - einfach nur einen Standardkonformen (OHCI)
Firewire-Controller braucht man dafür, und wahrscheinlich sind die
meisten konform.
Post by Hanno Foest
[...] Falls jemand nen Link dazu hat, was man alles für unituitive
Dinge man damit noch so alles anstellen kann: Interesse.
Google: firewire memory access

Relevante Treffer beim ersten überfliegen der Trefferseiten:
http://blogs.23.nu/RedTeam/topics/firewire/ (Fängt unten mit einem
Advisory an)
http://www.matasano.com/log/695/windows-remote-memory-access-though-firewire/

bye
Christian
Hanno Foest
2008-01-28 17:00:11 UTC
Permalink
Post by Christian Marg
Post by Hanno Foest
Ich schätze mal, das wird eher schwierig, wenn das OS keinen Treiber
für die Karte laden mag.
Nix Treiber - einfach nur einen Standardkonformen (OHCI)
Firewire-Controller braucht man dafür, und wahrscheinlich sind die
meisten konform.
***@atlas:~$ lsmod | grep 1394
ohci1394 36684 0
ieee1394 368472 2 sbp2,ohci1394

Ich vermute mal, daß nach Entfernung dieser Kernelmodule (aka Treiber)
mein Firewire-Controller nicht mehr sonderlich kooperativ sein wird,
egal für welchen Anwendungszweck. OK, sie sind vorhanden und geladen,
das ist Default, insofern ist die Gefahr real.
Post by Christian Marg
http://blogs.23.nu/RedTeam/topics/firewire/ (Fängt unten mit einem Advisory an)
Danke.

Hanno
Juergen P. Meier
2008-01-28 19:01:48 UTC
Permalink
Post by Hanno Foest
Post by Christian Marg
Post by Hanno Foest
Ich schätze mal, das wird eher schwierig, wenn das OS keinen Treiber
für die Karte laden mag.
Nix Treiber - einfach nur einen Standardkonformen (OHCI)
Firewire-Controller braucht man dafür, und wahrscheinlich sind die
meisten konform.
ohci1394 36684 0
ieee1394 368472 2 sbp2,ohci1394
Ich vermute mal, daß nach Entfernung dieser Kernelmodule (aka Treiber)
mein Firewire-Controller nicht mehr sonderlich kooperativ sein wird,
egal für welchen Anwendungszweck. OK, sie sind vorhanden und geladen,
das ist Default, insofern ist die Gefahr real.
Falsche vermutung. Das ist /KEIN/ Treiberfeature, das ist ein
HW-Feature.
Hanno Foest
2008-01-29 11:11:29 UTC
Permalink
Post by Juergen P. Meier
Falsche vermutung. Das ist /KEIN/ Treiberfeature, das ist ein
HW-Feature.
Man lernt nicht aus. Damit muß ich mal rumspielen, danke.

Hanno
Ansgar -59cobalt- Wiechers
2008-01-28 17:40:44 UTC
Permalink
Post by Hanno Foest
Post by Ansgar -59cobalt- Wiechers
Post by Christian Marg
man kann wohl über Firewire direkt auf den Speicher zugreifen,
möglicherweise auch vom Betriebssystem unbemerkt...
Da ist ein "möglicherweise" zuviel, das müssen wir leider abziehen.
Ich schätze mal, das wird eher schwierig, wenn das OS keinen Treiber
für die Karte laden mag.
Das beeinflusst den Erfolg des Auslesens, ändert jedoch nichts daran,
dass das OS vom Auslesen selbst genau gar nichts mitbekommt.

cu
59cobalt
--
"The Mac OS X kernel should never panic because, when it does, it
seriously inconveniences the user."
--http://developer.apple.com/technotes/tn2004/tn2118.html
Carsten Krueger
2008-01-28 18:00:46 UTC
Permalink
Am Mon, 28 Jan 2008 18:40:44 +0100 (CET) schrieb Ansgar -59cobalt-
Post by Ansgar -59cobalt- Wiechers
Das beeinflusst den Erfolg des Auslesens, ändert jedoch nichts daran,
dass das OS vom Auslesen selbst genau gar nichts mitbekommt.
Die Frage ist doch ob der Firewirekrempel soweit initialisiert ist, daß er
benutzbar wird wenn man keine Treiber installiert hat.

Gruß Carsten
--
ID = 0x2BFBF5D8 FP = 53CA 1609 B00A D2DB A066 314C 6493 69AB 2BFB F5D8
http://www.realname-diskussion.info - Realnames sind keine Pflicht
http://www.spamgourmet.com/ + http://www.temporaryinbox.com/ - Antispam
cakruege (at) gmail (dot) com | http://www.geocities.com/mungfaq/
Ansgar -59cobalt- Wiechers
2008-01-28 18:30:17 UTC
Permalink
Post by Carsten Krueger
Post by Ansgar -59cobalt- Wiechers
Das beeinflusst den Erfolg des Auslesens, ändert jedoch nichts daran,
dass das OS vom Auslesen selbst genau gar nichts mitbekommt.
Die Frage ist doch ob der Firewirekrempel soweit initialisiert ist,
daß er benutzbar wird wenn man keine Treiber installiert hat.
Auf die Gefahr hin, mich zu wiederholen: für den Erfolg ja, für die
Bemerkbarkeit nein.

cu
59cobalt
--
"The Mac OS X kernel should never panic because, when it does, it
seriously inconveniences the user."
--http://developer.apple.com/technotes/tn2004/tn2118.html
Juergen P. Meier
2008-01-28 19:02:29 UTC
Permalink
Post by Carsten Krueger
Am Mon, 28 Jan 2008 18:40:44 +0100 (CET) schrieb Ansgar -59cobalt-
Post by Ansgar -59cobalt- Wiechers
Das beeinflusst den Erfolg des Auslesens, ändert jedoch nichts daran,
dass das OS vom Auslesen selbst genau gar nichts mitbekommt.
Die Frage ist doch ob der Firewirekrempel soweit initialisiert ist, daß er
benutzbar wird wenn man keine Treiber installiert hat.
IdR. Ja. BIOSe enthalten genuegend Initialsierungscode im POST.
Carsten Krueger
2008-01-28 19:20:38 UTC
Permalink
Post by Juergen P. Meier
IdR. Ja. BIOSe enthalten genuegend Initialsierungscode im POST.
Ausprobiert oder schätzt du?

Gruß Carsten
--
ID = 0x2BFBF5D8 FP = 53CA 1609 B00A D2DB A066 314C 6493 69AB 2BFB F5D8
http://www.realname-diskussion.info - Realnames sind keine Pflicht
http://www.spamgourmet.com/ + http://www.temporaryinbox.com/ - Antispam
cakruege (at) gmail (dot) com | http://www.geocities.com/mungfaq/
Juergen P. Meier
2008-01-28 19:23:49 UTC
Permalink
Post by Carsten Krueger
Post by Juergen P. Meier
IdR. Ja. BIOSe enthalten genuegend Initialsierungscode im POST.
Ausprobiert oder schätzt du?
Bei meinem ShuttlePC mit Nvidia Chipsatz reichts. Bis zum Treiberladen
(der das Feature abschaltet), kann man auf DMA-Mappings zugreifen.

Allerdings ist vor dem Start des OS nicht viel DMA verfuegbar, und
der Speicher, den man auslesen kann, ist fast ausnahmslos leer.
Selbst nach einem Reset mitten im gestarteten Wintendo (was das RAM
bekanntlich mit allem moeglichen Scheiss fuellt).

Beim Powerbook ging das nach dem Update damals laut Releasenotes
auch nicht mehr, vorher hatte ich das aber auch nicht ausprobiert.
Juergen P. Meier
2008-01-28 19:00:03 UTC
Permalink
Post by Hanno Foest
Post by Ansgar -59cobalt- Wiechers
Post by Christian Marg
man kann wohl über Firewire direkt auf den Speicher zugreifen,
möglicherweise auch vom Betriebssystem unbemerkt...
Da ist ein "möglicherweise" zuviel, das müssen wir leider abziehen.
Ich schätze mal, das wird eher schwierig, wenn das OS keinen Treiber für
die Karte laden mag. Aber OK, mit dem Feuerdraht hab ich noch nicht mehr
gemacht, als nen externes Laufwerk anzuschließen. Falls jemand nen Link
dazu hat, was man alles für unituitive Dinge man damit noch so alles
anstellen kann: Interesse.
Firewire bietet Zugriff auf die DMA-Schnittstelle der FW-Bridge,
mithin also auf den gesammten DMA-zugreifbaren Speicher.

Unabhaengig vom OS.

Neuere Firewire-controller haben das jedoch defaultmaessig deaktiviert.
Maik Zumstrull
2008-01-28 15:22:43 UTC
Permalink
Post by Hanno Foest
Post by Maik Zumstrull
Alle Keys in genau das "fast nichts" schreiben, das beim Reboot dann
doch vom BIOS gekillt wird?
Ich stelle mir das anstrengend vor, herauszubekommen, welcher Bereich
das ist, ohne selber einen Angriff wie beschrieben auf seine eigene
Hardware zu fahren. Bei jeder Hardware von neuem, natürlich.
Könnte man kontrollieren, wenn man das BIOS genauer kennt. Mit
LinuxBIOS zum Beispiel.
Post by Hanno Foest
Post by Maik Zumstrull
Hilft allerdings nicht dagegen, dass jemand
den Speicher ausliest, *ohne* den Rechner abzuschalten/rebooten.
Ich bilde mir ein, mich mit einem anständigen OS, das nicht einfach
so fremden Code bei Hotplug-Aktionen ausführt, davor schützen zu
können. Falls ich mich darin irre, bitte ich um Korrektur. Die
PC-Architektur heutzutage hat manchmal wundersame Features, die ich
nicht allesamt kenne.
Brutal an jeglichem OS und jeder Architektur vorbei: Mit hochwertigem
Digitaloszilloskop direkt auf den Speicherbus hängen. Hardwarekosten im
unteren sechsstelligen Bereich, aber machbar. Den genau so
durchgeführten XBox-Hack zitiere ich immer wieder gerne. (Genau deshalb
hat das Nachfolgemodell übrigens teilweise verschlüsselten Speicher.)
Hanno Foest
2008-01-28 16:16:03 UTC
Permalink
Post by Maik Zumstrull
Könnte man kontrollieren, wenn man das BIOS genauer kennt. Mit
LinuxBIOS zum Beispiel.
Auf die Idee bin ich auch schon gekommen :) Wird es aber wohl kaum für
beliebige Laptops geben. Falls doch: Beim Boot einfach das gesamte RAM
überschreiben.
Post by Maik Zumstrull
Brutal an jeglichem OS und jeder Architektur vorbei: Mit hochwertigem
Digitaloszilloskop direkt auf den Speicherbus hängen. Hardwarekosten im
unteren sechsstelligen Bereich, aber machbar.
Möglich, aber nicht sonderlich zuverlässig, IMO. Laptop (gehen wir mal
davon aus) im Betrieb auseinanderschrauben, bis das RAM freiliegt, -zig
Kontakte an den Speicherbus anklemmen, und hoffen, daß der Key
vorbeikommt (im beschriebenen Betriebszustand hat die Kiste wenig Grund,
auf die Platte zuzugreifen). Man hat nur einen Versuch, einmal zuviel
gewackelt und die Kiste schmiert ab. - OK, möglich isses, aber andere
Angriffszenarien halte ich erst mal für wahrscheinlicher.

Hanno
Juergen P. Meier
2008-01-28 19:03:43 UTC
Permalink
Post by Hanno Foest
Möglich, aber nicht sonderlich zuverlässig, IMO. Laptop (gehen wir mal
davon aus) im Betrieb auseinanderschrauben, bis das RAM freiliegt, -zig
Kontakte an den Speicherbus anklemmen, und hoffen, daß der Key
vorbeikommt (im beschriebenen Betriebszustand hat die Kiste wenig Grund,
auf die Platte zuzugreifen). Man hat nur einen Versuch, einmal zuviel
gewackelt und die Kiste schmiert ab. - OK, möglich isses, aber andere
Angriffszenarien halte ich erst mal für wahrscheinlicher.
Hat dein Notebook keinen Docking-Port? ODer wenigstens einen CARDBUS
Slot? Oder So einen netten Mini-PCI Adapter, wo die Netzwerkbuchse
drinsteckt?
Hanno Foest
2008-01-29 11:05:22 UTC
Permalink
Post by Juergen P. Meier
Hat dein Notebook keinen Docking-Port?
Außerbetriebsetzung z.B. mit Epoxy, wie von mir eingangs erwähnt. Ich
hab Docking-Ports selten in der Praxis benutzt gesehen.
Post by Juergen P. Meier
ODer wenigstens einen CARDBUS Slot?
Ich bilde mir ein, daß ich dessen Treiber/Hotplug-Fähigkeiten abschalten
kann. Vielleicht liege ich damit aber auch, wie beim Firewire, neben der
Spur. Muß ich mir noch anschauen.

Danke für den Input übrigens. Bisher hab ich auf Plattenverschlüsselung
bei Notebooks verzichtet, weil ich mir sicher war, wesentliche Lücken
nicht zu kennen, und auf eine Sicherheitsillusion hab ich wenig Lust. So
langsam kristallisiert sich aber heraus, wo diese Lücken sind und wie
man sie schließen kann. Zumindest theoretisch - sämtliche Schnittstellen
physikalisch außerbetriebsetzen ist wenig praxistauglich.
Post by Juergen P. Meier
Oder So einen netten Mini-PCI Adapter, wo die Netzwerkbuchse
drinsteckt?
Älteres Notebook, das ist irgendwas proprietäres, und sicherlich nicht
hotplugfähig.

Gibt es eigentlich erfolgreiche Angriffe auf nichthotplugfähige
Schnittstellen, während der Rechner läuft? Laptop zerlegen + BIOS
tauschen oder diverse dutzend Kabel anbringen, ohne daß was crasht,
stelle ich mir ähnlich sportlich und für einen praktikablen (halbwegs
zuverlässigen) Angriff eher irrelevant vor.

Praktikabel ist vermutlich eher: RAM kräftig kühlen,
abschalten/rausrupfen/woandersreinstecken/auslesen. Müßte gehen.

Hanno
Juergen P. Meier
2008-01-28 18:57:35 UTC
Permalink
Post by Hanno Foest
Post by Maik Zumstrull
Alle Keys in genau das "fast nichts" schreiben, das beim Reboot dann
doch vom BIOS gekillt wird?
Ich stelle mir das anstrengend vor, herauszubekommen, welcher Bereich
das ist, ohne selber einen Angriff wie beschrieben auf seine eigene
Hardware zu fahren. Bei jeder Hardware von neuem, natürlich.
Aeh, jeder PC schreibt beim booten in das stueckchen RAM, dass von der
Graphikkarte als Videospeicher verwendet wird.

Jedes Nicht-DOS OS biegt diesen sowieso um.

Dort die Keys zu halten ist also nicht unmoeglich, und braucht nur
ein Stueck code fuer x86 PC-Architekturen.
Post by Hanno Foest
Post by Maik Zumstrull
Hilft allerdings nicht dagegen, dass jemand
den Speicher ausliest, *ohne* den Rechner abzuschalten/rebooten.
Ich bilde mir ein, mich mit einem anständigen OS, das nicht einfach so
fremden Code bei Hotplug-Aktionen ausführt, davor schützen zu können.
Falls ich mich darin irre, bitte ich um Korrektur. Die PC-Architektur
heutzutage hat manchmal wundersame Features, die ich nicht allesamt kenne.
Bei einigen Notebooks gibts diese Dockingports, die man dafuer sicher
misbrauchen kann. Ansonsten hilft Firewire.
Hanno Foest
2008-01-29 11:10:12 UTC
Permalink
Post by Juergen P. Meier
Aeh, jeder PC schreibt beim booten in das stueckchen RAM, dass von der
Graphikkarte als Videospeicher verwendet wird.
Hmm, stimmt eigentlich.
Post by Juergen P. Meier
Dort die Keys zu halten ist also nicht unmoeglich, und braucht nur
ein Stueck code fuer x86 PC-Architekturen.
Macht das irgendeine existierende Implementation einer
Plattenverschlüsselung?

Hanno
Dirk Ohme
2008-01-28 20:47:02 UTC
Permalink
Hanno Foest schrieb im Newsbeitrag
Post by Hanno Foest
Folgendes Szenario: Rechner mit Plattenverschlüsselung und
verriegeltem Bildschirm (GUI) wird aufgefunden/gestohlen.
Reboot bedeutet: Die Platte ist verschlüsselt, man kommt
nicht mehr an die interessanten Daten ran. Der Key steht
aber irgendwo im RAM, schließlich muß das OS ja die Platte irgendwie
benutzen können.
Man könnte den Key auch extern in einen USB-Crypt-Stick oder in einer
Smart-Card ablegen.
Post by Hanno Foest
Also: Bootmedium einlegen, Rechner resetten.
Lustig ... der PC ist sonst so gut abgesichert, aber ansonsten so
konfiguriert, dass von einem (unsicheren) Boot-Medium gestartet werden
kann? Tja, da würde ich mir erstmal was anderes überlegen ... zum
Ersten: Booten nur von Festplatte. Zum Zweiten: Neben der
Verschlüsselung vielleicht auch noch das ATA-Passwort der Festplatte
einschalten.

Und dann, der Klassiker: Rechner mit einem Kensington-Lock oder
anderen Verfahren fest mit der Umgebung verbinden. Denn - was
mechanisch gesichert ist, kann man nicht so leicht wegtragen.
Post by Hanno Foest
Gute Verteidigungsstrategien gegen derartige Angriffe würden
mich mal interessieren.
Die Frage ist doch auch: Wieso kann der PC gestohlen werden? Durch
welche Umstände ist die Hardware schutzlos dem widerrechtlichen
Abtransport ausgesetzt? Kann man an diesen Umständen was ändern?
Post by Hanno Foest
Angesichts der von dir genannten Zeiten muß ich zugeben,
die Gefahren eines derartigen Angriffs bisher unterschätzt
zu haben. Danke für die Info.
Für mich stellt sich da eher die Frage, ob man in manchen Bereichen
nicht die Messlatte zu hoch ansetzt. Wenn ich große Teile des
Betriebssystems anschaue, dann sehe ich darin keinen Grund, diese zu
verschlüsseln, weil allgemein bekannt. Vielleicht sollte man die Daten
trennen in Klassen und nicht gleich alles mit *EINEM* Schlüssel
verschlüsseln.

Wie gesagt: Das eigentliche Betriebssystem muss nicht verschlüsselt
sein, genauso wenig installierte Programme. Es geht vornehmlich um
Daten. Und hier wäre zu überlegen, ob man nicht den Schutz auf "per
Zugriff" definiert, ggfs. unterstützt durch externe Hardware, die man
*IMMER* bei Verlassen des Gerätes abzieht.

Ansonsten denke ich bei der Mehrzahl der Anwender, dass jede dieser
Maßnahmen doch letzten Endes zu einem Aufschrei führen wird "Hilfe,
meine Platte ist gecrasht, Backup ist x Monate alt - wie komme ich an
meine Daten?" ;-)

Gruß, Dirk
Maik Zumstrull
2008-01-28 22:30:55 UTC
Permalink
Post by Dirk Ohme
Hanno Foest schrieb im Newsbeitrag
Post by Hanno Foest
Folgendes Szenario: Rechner mit Plattenverschlüsselung und
verriegeltem Bildschirm (GUI) wird aufgefunden/gestohlen.
Reboot bedeutet: Die Platte ist verschlüsselt, man kommt
nicht mehr an die interessanten Daten ran. Der Key steht
aber irgendwo im RAM, schließlich muß das OS ja die Platte
irgendwie benutzen können.
Man könnte den Key auch extern in einen USB-Crypt-Stick oder in einer
Smart-Card ablegen.
Während das Dateisystem gemountet ist? Kaum. Da muss das OS schon
wissen, wie es an die Daten kommt. Das heißt: Key im RAM.
Post by Dirk Ohme
Post by Hanno Foest
Also: Bootmedium einlegen, Rechner resetten.
Lustig ... der PC ist sonst so gut abgesichert, aber ansonsten so
konfiguriert, dass von einem (unsicheren) Boot-Medium gestartet
werden kann?
Boot von externen Medien im BIOS abschalten ist Pseudoschutz. Einmal
NVRAM löschen und es macht alles.
Post by Dirk Ohme
Zum Zweiten: Neben der Verschlüsselung vielleicht auch noch das
ATA-Passwort der Festplatte einschalten.
Kann jedenfalls nicht schaden, sollte man sich aber auch nicht drauf
verlassen.
Post by Dirk Ohme
Und dann, der Klassiker: Rechner mit einem Kensington-Lock oder
anderen Verfahren fest mit der Umgebung verbinden. Denn - was
mechanisch gesichert ist, kann man nicht so leicht wegtragen.
Kann jedenfalls nicht schaden, sollte man sich aber auch nicht drauf
verlassen.
Post by Dirk Ohme
Wie gesagt: Das eigentliche Betriebssystem muss nicht verschlüsselt
sein, genauso wenig installierte Programme. Es geht vornehmlich um
Daten.
Die Argumentation ist gleichzeitig richtig und gefährlich. Wenn man nur
einzelne Pfade verschlüsselt, ist es sehr leicht, dann doch einen oder
zwei zu übersehen, in denen Daten liegen, an die man nicht gedacht hat.
Hingegen kostet es einen nicht ernsthaft etwas, wenn *alles*
verschlüsselt ist, und dann hat man bestimmt nichts übersehen. Der Weg
ist daher vorzuziehen.
Sebastian G.
2008-01-29 02:08:21 UTC
Permalink
Post by Maik Zumstrull
Post by Dirk Ohme
Man könnte den Key auch extern in einen USB-Crypt-Stick oder in einer
Smart-Card ablegen.
Während das Dateisystem gemountet ist? Kaum. Da muss das OS schon
wissen, wie es an die Daten kommt. Das heißt: Key im RAM.
Das OS kann ihn regelmaessig loeschen und vom Key nachladen. Ueberhaupt kann
es ganz einfach regelmaessig die Anwesenheit des Mediums pruefen und sich
bei Bdarf abschalten.
Post by Maik Zumstrull
Boot von externen Medien im BIOS abschalten ist Pseudoschutz. Einmal
NVRAM löschen und es macht alles.
Ohne die Moeglickeit, von was externem zu booten, musst du dafuer schon die
Hardware angehen. Und wenn du das kannst, stehen dir weitaus maechtigere
Angriffe zur Verfuegung...
Post by Maik Zumstrull
Post by Dirk Ohme
Zum Zweiten: Neben der Verschlüsselung vielleicht auch noch das
ATA-Passwort der Festplatte einschalten.
Kann jedenfalls nicht schaden, sollte man sich aber auch nicht drauf
verlassen.
Kann sehr wohl schaden, wenn die ver****te Schei**e mal nicht funktioniert.
Weiterhin gilt, dass bei aktivem Passwortschutz Malware, die mit
Adminrechten zur Ausfuehrung kommt, das Passwort jederzeit aendern kann,
mithin dich von deinen eigenen Daten aussperrt. Von daher waere es sinnvoll,
kein Passwort zu verwenden und diese Funktion permanent zu sperren.
Maik Zumstrull
2008-01-29 09:01:07 UTC
Permalink
Post by Sebastian G.
Post by Maik Zumstrull
Post by Dirk Ohme
Zum Zweiten: Neben der Verschlüsselung vielleicht auch noch das
ATA-Passwort der Festplatte einschalten.
Kann jedenfalls nicht schaden, sollte man sich aber auch nicht drauf
verlassen.
Weiterhin gilt, dass bei aktivem Passwortschutz
Malware, die mit Adminrechten zur Ausfuehrung kommt, das Passwort
jederzeit aendern kann,
Nur, wenn das Betriebssystemimitat deines Vertrauens ATA Security
falsch implementiert hat. Was beim Marktführer für Softwarelösungen,
die gerne ein Betriebssystem wären, zugegebenermaßen so ist.
Post by Sebastian G.
mithin dich von deinen eigenen Daten aussperrt. Von daher waere es
sinnvoll, kein Passwort zu verwenden
Wenn man (nicht) möchte...
Post by Sebastian G.
und diese Funktion permanent zu sperren.
Das geht nicht. Zwar gibt es einen Befehl, um die Security Features
abzuschalten. Der wirkt aber nur bis zum nächsten Reset der Platte.
(Ein korrekt implementiertes BIOS schickt diesen Befehl allerdings auf
Wunsch bei jedem Einschalten, noch bevor das OS zum Zug kommt.)
Sebastian G.
2008-01-29 13:05:13 UTC
Permalink
Post by Maik Zumstrull
Post by Sebastian G.
Post by Maik Zumstrull
Post by Dirk Ohme
Zum Zweiten: Neben der Verschlüsselung vielleicht auch noch das
ATA-Passwort der Festplatte einschalten.
Kann jedenfalls nicht schaden, sollte man sich aber auch nicht drauf
verlassen.
Weiterhin gilt, dass bei aktivem Passwortschutz
Malware, die mit Adminrechten zur Ausfuehrung kommt, das Passwort
jederzeit aendern kann,
Nur, wenn das Betriebssystemimitat deines Vertrauens ATA Security
falsch implementiert hat. Was beim Marktführer für Softwarelösungen,
die gerne ein Betriebssystem wären, zugegebenermaßen so ist.
Nicht implementiert != falsch implementiert.
Post by Maik Zumstrull
Das geht nicht. Zwar gibt es einen Befehl, um die Security Features
abzuschalten. Der wirkt aber nur bis zum nächsten Reset der Platte.
(Ein korrekt implementiertes BIOS schickt diesen Befehl allerdings auf
Wunsch bei jedem Einschalten, noch bevor das OS zum Zug kommt.)
Genau das meine ich. Allerdings ist diese Implementierung nicht zwingend,
andererseits kan natuerlich auch das OS oder ein darin laufendes
Drittanbieterprogramm dies erledigen.
Sebastian G.
2008-01-29 01:48:23 UTC
Permalink
Post by Dirk Ohme
Und dann, der Klassiker: Rechner mit einem Kensington-Lock oder
anderen Verfahren fest mit der Umgebung verbinden. Denn - was
mechanisch gesichert ist, kann man nicht so leicht wegtragen.
Ironie? Kensignton-Lock kriegt man mit 'n bisschen gerollter Pappe von 'ner
Klopapierrolle in 10 Sekunden auf. Fuer mehr als Anspruchserhebung auf
Versicherungsleistungen taugt das also nix.
Post by Dirk Ohme
Für mich stellt sich da eher die Frage, ob man in manchen Bereichen
nicht die Messlatte zu hoch ansetzt. Wenn ich große Teile des
Betriebssystems anschaue, dann sehe ich darin keinen Grund, diese zu
verschlüsseln, weil allgemein bekannt. Vielleicht sollte man die Daten
trennen in Klassen und nicht gleich alles mit *EINEM* Schlüssel
verschlüsseln.
Wie waer's, wenn du einfach alles prinzipell mit dem einen Schluessel
verschluesselt, aber wichtige Sachen noch zuasetzlich mit einem separaten
Schluessel?
Juergen P. Meier
2008-01-29 09:39:10 UTC
Permalink
Post by Sebastian G.
Post by Dirk Ohme
Und dann, der Klassiker: Rechner mit einem Kensington-Lock oder
anderen Verfahren fest mit der Umgebung verbinden. Denn - was
mechanisch gesichert ist, kann man nicht so leicht wegtragen.
Ironie? Kensignton-Lock kriegt man mit 'n bisschen gerollter Pappe von 'ner
Klopapierrolle in 10 Sekunden auf. Fuer mehr als Anspruchserhebung auf
Versicherungsleistungen taugt das also nix.
Bei den neuen brauchst du eine "Nase" die auch bisschen Scherkraefte
aushalten kann. Ein Metallstift z.B. Damit gehts dann aber wieder
einfach.

Und die Zahlenschloesser, egal ob Immitationen oder Original
Kensington(r)[tm], bekommt man auch schnell auf. (Kensington: <1 Minute)
Post by Sebastian G.
Wie waer's, wenn du einfach alles prinzipell mit dem einen Schluessel
verschluesselt, aber wichtige Sachen noch zuasetzlich mit einem separaten
Schluessel?
Und wie genau sollte das gegen den Angriff auf die im RAM liegenden
Schluessel nach Reset des physisch kompromittierten Rechners schuetzen?

Diesem Angreifer ist doch egal, wieviele Schluessel er aus dem RAM
auslesen muss.

Juergen
--
Juergen P. Meier - "This World is about to be Destroyed!"
end
If you think technology can solve your problems you don't understand
technology and you don't understand your problems. (Bruce Schneier)
Juergen P. Meier
2008-01-29 09:27:58 UTC
Permalink
Post by Dirk Ohme
Hanno Foest schrieb im Newsbeitrag
Post by Hanno Foest
Folgendes Szenario: Rechner mit Plattenverschlüsselung und
verriegeltem Bildschirm (GUI) wird aufgefunden/gestohlen.
Reboot bedeutet: Die Platte ist verschlüsselt, man kommt
nicht mehr an die interessanten Daten ran. Der Key steht
aber irgendwo im RAM, schließlich muß das OS ja die Platte irgendwie
benutzen können.
Man könnte den Key auch extern in einen USB-Crypt-Stick oder in einer
Smart-Card ablegen.
Der symmetrische Schluessel muss waehrend des Ent- und Verschluesselns
(bei Festplatten also staendig) im Mapbaren Speicher des Prozesses
liegen. Bei Wintendo also irgendwo RAM des Hosts. Dass du Kopien ggf.
asymmetrisch verschluesselt noch woanders rumliegen hast, ist fuer
dieses Angriffszenario unerheblich. Es geht hier um den "session Key".
Post by Dirk Ohme
Post by Hanno Foest
Also: Bootmedium einlegen, Rechner resetten.
Lustig ... der PC ist sonst so gut abgesichert, aber ansonsten so
konfiguriert, dass von einem (unsicheren) Boot-Medium gestartet werden
kann? Tja, da würde ich mir erstmal was anderes überlegen ... zum
Ersten: Booten nur von Festplatte. Zum Zweiten: Neben der
Verschlüsselung vielleicht auch noch das ATA-Passwort der Festplatte
einschalten.
Woo, wie willst du verhindern, dass jemand den PC von einem CDROM oder
einer anderen Festplatte bootet, die er einfach dazusteckt?

Per BIOS vielleicht? Und wie verhinderst du, dass der Angreifer das
BIOS einfach aendert? PAsswort? Wie verhinderst du, dass der Angreifer
dein Passwortgeschuetztes BIOS einfach durch eines ohne Passwort
austauscht? (Im Zweifel muss er dafuer halt auf dem Mainboard
herumloeten).
Post by Dirk Ohme
Und dann, der Klassiker: Rechner mit einem Kensington-Lock oder
anderen Verfahren fest mit der Umgebung verbinden. Denn - was
mechanisch gesichert ist, kann man nicht so leicht wegtragen.
Kensington-locks (die ich selbst kategorisch verwende) schuetzen nur
gegen Gelegenheitsmitnehmer, nicht aber gegen gezielten Diebstahl.
Es ist trivial die meisten Schloesser zu knacken (Die Papprolle von
Klopapier reicht fuer die Rundschluesselkensingtons, bei den neueren
braucht man zusaetzlich noch einen Metallhaken wie er an Schweizer
Taschenmessern bestimmter Modellreihe zu finden ist.) Die
Zahlenschloesser sind ein Witz und in weniger als 1 Minute offen.

BTDT.

Und wenn es dem Angreifer nicht auf die aeussere Unversehrtheit
des Notebookgehaeuses ankommt, bricht er das Schloss einfach ab.
Auch das geht, auch wenn das einzige mal, wo ich das beobachten
konnte, ein Unfall war.
Post by Dirk Ohme
Post by Hanno Foest
Gute Verteidigungsstrategien gegen derartige Angriffe würden
mich mal interessieren.
Die Frage ist doch auch: Wieso kann der PC gestohlen werden? Durch
welche Umstände ist die Hardware schutzlos dem widerrechtlichen
Abtransport ausgesetzt? Kann man an diesen Umständen was ändern?
Bei Notebooks, die man in Aussendienst mit herumschleppt ist das nicht
durch technische Mittel verhinderbar. Es ist erschwerbar
(Kensington-Lock), aber nicht zu verhindern. Zumindest im realen
Alltag.
Post by Dirk Ohme
Post by Hanno Foest
Angesichts der von dir genannten Zeiten muß ich zugeben,
die Gefahren eines derartigen Angriffs bisher unterschätzt
zu haben. Danke für die Info.
Für mich stellt sich da eher die Frage, ob man in manchen Bereichen
nicht die Messlatte zu hoch ansetzt. Wenn ich große Teile des
Betriebssystems anschaue, dann sehe ich darin keinen Grund, diese zu
verschlüsseln, weil allgemein bekannt. Vielleicht sollte man die Daten
trennen in Klassen und nicht gleich alles mit *EINEM* Schlüssel
verschlüsseln.
Wie gesagt: Das eigentliche Betriebssystem muss nicht verschlüsselt
sein, genauso wenig installierte Programme. Es geht vornehmlich um
Daten. Und hier wäre zu überlegen, ob man nicht den Schutz auf "per
Zugriff" definiert, ggfs. unterstützt durch externe Hardware, die man
*IMMER* bei Verlassen des Gerätes abzieht.
Ansonsten denke ich bei der Mehrzahl der Anwender, dass jede dieser
Maßnahmen doch letzten Endes zu einem Aufschrei führen wird "Hilfe,
meine Platte ist gecrasht, Backup ist x Monate alt - wie komme ich an
meine Daten?" ;-)
Du hast das OP durchgelesen? Hier geht es nicht darum, was
verschluesselt wird oder nicht, sondern um einen bestimmten Angriff
gegen real existierende Verschluesselungsimplementierungen, die was mit
der Nicht-Fluechtigkeit von Datenstrukturen im RAM eines PCs zu tun
haben, insbesondere des symmetrischen Schluessels.
Deine Ausfuehrungen, so zutreffend sie sein moegen, gehen an diesem
Thema voellig vorbei.

Juergen
--
Juergen P. Meier - "This World is about to be Destroyed!"
end
If you think technology can solve your problems you don't understand
technology and you don't understand your problems. (Bruce Schneier)
Hanno Foest
2008-01-29 10:33:23 UTC
Permalink
Post by Juergen P. Meier
Und wie verhinderst du, dass der Angreifer das
BIOS einfach aendert? PAsswort? Wie verhinderst du, dass der Angreifer
dein Passwortgeschuetztes BIOS einfach durch eines ohne Passwort
austauscht? (Im Zweifel muss er dafuer halt auf dem Mainboard
herumloeten).
Das zumindest stelle ich mir bei einem Notebook, das im Betrieb, aber
gesperrt, aufgefunden wurde und das man nicht abschalten/rebooten
möchte, damit der Schlüssel im RAM nicht verloren geht, eher sportlich vor.

Hanno
Maik Zumstrull
2008-01-29 10:52:21 UTC
Permalink
Post by Hanno Foest
Post by Juergen P. Meier
Und wie verhinderst du, dass der Angreifer das
BIOS einfach aendert? PAsswort? Wie verhinderst du, dass der
Angreifer dein Passwortgeschuetztes BIOS einfach durch eines ohne
Passwort austauscht? (Im Zweifel muss er dafuer halt auf dem
Mainboard herumloeten).
Das zumindest stelle ich mir bei einem Notebook, das im Betrieb, aber
gesperrt, aufgefunden wurde und das man nicht abschalten/rebooten
möchte, damit der Schlüssel im RAM nicht verloren geht, eher
sportlich vor.
Um ein solches ging es in dem Absatz nicht mehr. Sondern darum, dass
jemand das Booten von etwas anderem als der vorgesehenen Festplatte
gerne verhindern wollte. Was bei üblicher PC-Hardware kaum möglich ist.
Hanno Foest
2008-01-29 13:12:15 UTC
Permalink
Post by Maik Zumstrull
Um ein solches ging es in dem Absatz nicht mehr. Sondern darum, dass
jemand das Booten von etwas anderem als der vorgesehenen Festplatte
gerne verhindern wollte. Was bei üblicher PC-Hardware kaum möglich ist.
Im Rahmen dieser Diskussion geht es schon darum. Das Booten von einem
Fremdmedium sollte schließlich dazu dienen, den alten Datenbestand des
RAM zügig auszulesen.

Daß man irgendwie mit möglicherweise tiefgehenden Hardwareingriffen
PC-Hardware dazu bringen kann, von allem möglichen zu booten - geschenkt.

Hanno
Richard W. Könning
2008-01-30 03:04:16 UTC
Permalink
Post by Hanno Foest
Post by Juergen P. Meier
Und wie verhinderst du, dass der Angreifer das
BIOS einfach aendert? PAsswort? Wie verhinderst du, dass der Angreifer
dein Passwortgeschuetztes BIOS einfach durch eines ohne Passwort
austauscht? (Im Zweifel muss er dafuer halt auf dem Mainboard
herumloeten).
Das zumindest stelle ich mir bei einem Notebook, das im Betrieb, aber
gesperrt, aufgefunden wurde und das man nicht abschalten/rebooten
möchte, damit der Schlüssel im RAM nicht verloren geht, eher sportlich vor.
Warum? Es soll durchaus Leute gegeben haben, die in Ermangelung eines
Flashers einen Rechner mit einem funktionierenden BIOS-Baustein
hochgefahren und dann im laufenden Betrieb diesen gegen den
zerflashten ausgetauscht und letzteren dann neu geflasht haben.
Ciao,
Richard
--
Dr. Richard Könning Heßstraße 63
Tel.: 089/5232488 80798 München
Ralph A. Schmid, dk5ras
2008-01-30 10:57:54 UTC
Permalink
Post by Richard W. Könning
Warum? Es soll durchaus Leute gegeben haben, die in Ermangelung eines
Flashers einen Rechner mit einem funktionierenden BIOS-Baustein
hochgefahren und dann im laufenden Betrieb diesen gegen den
zerflashten ausgetauscht und letzteren dann neu geflasht haben.
*fingerheb* Mehrmals, als ich das bei uns in der Firma verwendete BIOS
(bzw. dessen Konfiguration) gebaut habe, und feststellen mußte, daß
unser x kEUR-teurer EPROMer das blöde PLCC32-FLASH nur lesen, aber
nicht schreiben kann. Das geht absolut schmerzfrei und auf den ersten
Versuch, ohne Verrenkungen.



Ralph.

http://www.dk5ras.de/
Hanno Foest
2008-01-30 12:32:37 UTC
Permalink
Post by Richard W. Könning
Warum? Es soll durchaus Leute gegeben haben, die in Ermangelung eines
Flashers einen Rechner mit einem funktionierenden BIOS-Baustein
hochgefahren und dann im laufenden Betrieb diesen gegen den
zerflashten ausgetauscht und letzteren dann neu geflasht haben.
Ich weiß, aber das geht mit von vorneherein freiliegender Platine,
DIL-Bauteil und Sockel. Nicht mit einem laufenden, zugeschraubten
Notebook und eingelötetem SMD-Bauteil. Ich sehe da gewisse Unterschiede.

Hanno
Richard W. Könning
2008-01-31 02:42:31 UTC
Permalink
Post by Hanno Foest
Post by Richard W. Könning
Warum? Es soll durchaus Leute gegeben haben, die in Ermangelung eines
Flashers einen Rechner mit einem funktionierenden BIOS-Baustein
hochgefahren und dann im laufenden Betrieb diesen gegen den
zerflashten ausgetauscht und letzteren dann neu geflasht haben.
Ich weiß, aber das geht mit von vorneherein freiliegender Platine,
DIL-Bauteil und Sockel. Nicht mit einem laufenden, zugeschraubten
Notebook und eingelötetem SMD-Bauteil. Ich sehe da gewisse Unterschiede.
Die Rechner laufen in beiden Fällen, für Schrauben gibt es im
Fachhandel entsprechendes Werkzeug, bleibt also der Unterschied
gesockeltes DIL- vs. eingelötetes SMD-Bauteil. Ich habe selbst zwar
keine Erfahrung mit dem Löten und insbesondere dem Entlöten von
SMD-Bauteilen, sehe aber nicht, warum das nicht prinzipiell auch im
laufenden Betrieb gehen sollte.
Ciao,
Richard
--
Dr. Richard Könning Heßstraße 63
Tel.: 089/5232488 80798 München
Hanno Foest
2008-01-31 12:54:42 UTC
Permalink
Post by Richard W. Könning
Die Rechner laufen in beiden Fällen,
Bei BIOS-umflashen-Stunts legt man aber erst die Platine frei und
schaltet dann den Rechner ein, man kann sich das zumindest aussuchen.
Post by Richard W. Könning
für Schrauben gibt es im
Fachhandel entsprechendes Werkzeug,
Hast du schon mal einen Laptop zerlegt? Insbesondere so ein beschissen
verbautes Billigding?
Post by Richard W. Könning
bleibt also der Unterschied
gesockeltes DIL- vs. eingelötetes SMD-Bauteil. Ich habe selbst zwar
keine Erfahrung mit dem Löten und insbesondere dem Entlöten von
SMD-Bauteilen,
Ich schon.
Post by Richard W. Könning
sehe aber nicht, warum das nicht prinzipiell auch im
laufenden Betrieb gehen sollte.
Prinzipiell geht das. Prinzipiell kann man auch im Lotto gewinnen, aber
im konkreten Einzelfall ist das eher unwahrscheinlich. - Ich wüßte zwar.
wie ich das angehen müßte, aber die Erfolgsquote dürfte sehr gering
sein. Wie erwähnt, RAM kühlen und schnell umbauen dürfte erheblich
einfacher und erfolgversprechender sein.

Hanno
Ralph A. Schmid, dk5ras
2008-01-31 15:25:23 UTC
Permalink
Post by Hanno Foest
Ich wüßte zwar.
wie ich das angehen müßte, aber die Erfolgsquote dürfte sehr gering
sein.
Wo ist der Unterschied? Heißmachen, rausheben. Man braucht natürlich
das Werkzeug dazu, klar...mit einer entspr. SMT rework station
machbar.



Ralph.

http://www.dk5ras.de/
Hanno Foest
2008-01-31 17:58:53 UTC
Permalink
Post by Ralph A. Schmid, dk5ras
Wo ist der Unterschied? Heißmachen, rausheben. Man braucht natürlich
das Werkzeug dazu, klar...mit einer entspr. SMT rework station
machbar.
Ohne zwischenzeitliches Kurzschließen der Pins? Heißmachen, rausheben:
Bloß nicht zittern. Kontakte einzeln säubern? Ohne Lötsauglitze,
natürlich. Einzeln verlöten ohne Kurzschluß?

Klar, *möglich* ist das. Aber nicht zuverlässig im Einzelfall.

Hanno
Ralph A. Schmid, dk5ras
2008-02-02 07:57:01 UTC
Permalink
Jau.
Post by Hanno Foest
Bloß nicht zittern. Kontakte einzeln säubern? Ohne Lötsauglitze,
Nein, Kontakte so lassen, wie sie sind.
Post by Hanno Foest
natürlich. Einzeln verlöten ohne Kurzschluß?
Nö, einfach wieder so aufsetzen wie den Alten. Bissl FLußmittel, mehr
braucht es da nicht.
Post by Hanno Foest
Klar, *möglich* ist das. Aber nicht zuverlässig im Einzelfall.
Nun ja, kommt darauf an, worauf es ankommt. Sind die Daten jemandem
hinreichend wichtig, dann ist jeder Aufwand drin.



Ralph.

http://www.dk5ras.de/
Richard W. Könning
2008-02-03 19:44:37 UTC
Permalink
Post by Hanno Foest
Post by Ralph A. Schmid, dk5ras
Wo ist der Unterschied? Heißmachen, rausheben. Man braucht natürlich
das Werkzeug dazu, klar...mit einer entspr. SMT rework station
machbar.
Bloß nicht zittern. Kontakte einzeln säubern? Ohne Lötsauglitze,
natürlich. Einzeln verlöten ohne Kurzschluß?
Klar, *möglich* ist das. Aber nicht zuverlässig im Einzelfall.
Mir scheinen die Anforderungen auch nicht höher zu sein als bei einer
etwas komplizierteren Operation,, wo der Patient auch die Erwartung
hat, daß die Erfolgsrate deutlich höher als 2% ist.
Ciao,
Richard
--
Dr. Richard Könning Heßstraße 63
Tel.: 089/5232488 80798 München
Ralph A. Schmid, dk5ras
2008-01-31 15:24:14 UTC
Permalink
Post by Richard W. Könning
Ich habe selbst zwar
keine Erfahrung mit dem Löten und insbesondere dem Entlöten von
SMD-Bauteilen, sehe aber nicht, warum das nicht prinzipiell auch im
laufenden Betrieb gehen sollte.
Im Zweifelsfall wird es, so es PLCC ist (häufig gesehen)
'rausgezwickt, dann die Beinchen einzeln abgelötet und ein Sockel oder
ein anderes IC aufgelötet. Aber bei meinen bisherigen notebooks war
das BIOS eh gesockelt.
Für einen Profi mit entspr. guter Ausstattung ist viele möglich, was
dem ambitionierten Laien undenkbar scheint. Selbst ein µBGA-chip kann
da gewechselt werden...



Ralph.

http://www.dk5ras.de/
Jens Sülwald
2008-01-31 15:43:52 UTC
Permalink
Post by Ralph A. Schmid, dk5ras
Für einen Profi mit entspr. guter Ausstattung ist viele möglich, was
dem ambitionierten Laien undenkbar scheint. Selbst ein µBGA-chip kann
da gewechselt werden...
Im laufenden Betrieb?
Ralph A. Schmid, dk5ras
2008-02-02 07:59:05 UTC
Permalink
Post by Jens Sülwald
Im laufenden Betrieb?
Der IR-Lampe oder der Heißluft ist es egal, ob da noch irgendwo 3V
sind. Freilich ist es ungleich schwerer, aber wer solche Operationen
öfters durchführt, der hat seine Ausrüstung entspr. angepaßt. Es ist
rein für den Lötvorgang wirklich irrelevant, ob die Schaltung läuft,
oder nicht.



Ralph.

http://www.dk5ras.de/
Hanno Foest
2008-01-31 18:00:33 UTC
Permalink
Post by Ralph A. Schmid, dk5ras
Im Zweifelsfall wird es, so es PLCC ist (häufig gesehen)
'rausgezwickt, dann die Beinchen einzeln abgelötet und ein Sockel oder
ein anderes IC aufgelötet.
Womit zwickst du, wenn du die Beinchen nicht untereinander kurzschließen
darfst?

Hanno
Richard W. Könning
2008-02-01 03:16:27 UTC
Permalink
Post by Hanno Foest
Post by Ralph A. Schmid, dk5ras
Im Zweifelsfall wird es, so es PLCC ist (häufig gesehen)
'rausgezwickt, dann die Beinchen einzeln abgelötet und ein Sockel oder
ein anderes IC aufgelötet.
Womit zwickst du, wenn du die Beinchen nicht untereinander kurzschließen
darfst?
Mit einem hinreichend feinen "Zwicker".
Ciao,
Richard
--
Dr. Richard Könning Heßstraße 63
Tel.: 089/5232488 80798 München
Andreas Beck
2008-02-01 10:17:08 UTC
Permalink
Post by Hanno Foest
Post by Ralph A. Schmid, dk5ras
Im Zweifelsfall wird es, so es PLCC ist (häufig gesehen)
'rausgezwickt, dann die Beinchen einzeln abgelötet und ein Sockel oder
ein anderes IC aufgelötet.
Womit zwickst du, wenn du die Beinchen nicht untereinander kurzschließen
darfst?
Mit einer Trennscheibe auf ner Minibohrmaschine. BTDT. Geht am
schnellsten. Ganze ICs auslöten nervt, besonders wenn man nicht das
passende Werkzeug da hat.

Hab ich aber noch nie im Betrieb gemacht - mangels Veranlassung.

CU, Andy
Ralph A. Schmid, dk5ras
2008-02-02 07:59:50 UTC
Permalink
Post by Hanno Foest
Womit zwickst du, wenn du die Beinchen nicht untereinander kurzschließen
darfst?
Keramische Klinge, oder einfach mit dünnen Isolierfolien. Aber wer
wirklich den Aufwand mit Profimitteln treibt, der zwickt nicht.



Ralph.

http://www.dk5ras.de/
Jens Sülwald
2008-01-30 15:55:46 UTC
Permalink
Post by Richard W. Könning
Warum? Es soll durchaus Leute gegeben haben, die in Ermangelung eines
Flashers einen Rechner mit einem funktionierenden BIOS-Baustein
hochgefahren und dann im laufenden Betrieb diesen gegen den
zerflashten ausgetauscht und letzteren dann neu geflasht haben.
Yo. Sind das aber nicht auch etwas zu einfache Bedingungen?

Das ganze im laufenden Betrieb ist ja schön und gut... aber es soll da
ach Dinge geben, wo der besagte Baustein aufgelötet wird (also nicht
gesockelt)...
Juergen P. Meier
2008-01-25 08:08:03 UTC
Permalink
Post by Michael Reichenbach
Kann man aus normalen RAM Speicher (SD, DDR, etc.) definitiv nichts mehr
wiederherstellen nach dem die Stromzufuhr unterbrochen war oder gibt es
da noch Möglichkeiten?
Zuverlaessig? keine.
Hauke Laging
2008-01-29 11:30:09 UTC
Permalink
Post by Michael Reichenbach
Kann man aus normalen RAM Speicher (SD, DDR, etc.) definitiv nichts
mehr wiederherstellen nach dem die Stromzufuhr unterbrochen war
oder gibt es da noch Möglichkeiten?
Das ist definitiv nicht unmöglich.

Ich habe vor wenigen Jahren mal einen Artikel darüber gelesen. Da
haben Wissenschaftler - wohl mit Technik in der Liga eines
Elektronenmikroskops - den Inhalt ausgeschalteter RAM-Zellen
ermitteln können, indem sie mechanische Verzerrungen (die wohl
stabil sind) im umgebenden Material gefunden haben. Das ist wohl die
elektrostatische Abstoßung innerhalb des Kondensators, die da nach
außen drückt und so nachgewiesen werden kann.

Über die Frage, wie massentauglich (also für Untersuchungen von mehr
als 1 KiB RAM) dieses Verfahren ist, mag sich jeder seine eigenen
Gedanken machen. :-)


CU

Hauke
--
http://www.hauke-laging.de/ideen/
http://www.hauke-laging.de/software/
http://zeitstempel-signatur.hauke-laging.de/
Wie können 59.054.087 Leute nur so dumm sein?
Maik Zumstrull
2008-02-21 16:07:29 UTC
Permalink
Post by Michael Reichenbach
Kann man aus normalen RAM Speicher (SD, DDR, etc.) definitiv nichts
mehr wiederherstellen nach dem die Stromzufuhr unterbrochen war oder
gibt es da noch Möglichkeiten?
Ganz frisch: <http://www.freedom-to-tinker.com/?p=1257>

Nichts, was im Thread nicht schon angesprochen wurde, aber jetzt als
wissenschaftliche Veröffentlichung von anerkannten Experten.
Juergen Nieveler
2008-02-21 21:43:35 UTC
Permalink
Post by Maik Zumstrull
Ganz frisch: <http://www.freedom-to-tinker.com/?p=1257>
Nichts, was im Thread nicht schon angesprochen wurde, aber jetzt als
wissenschaftliche Veröffentlichung von anerkannten Experten.
Wobei ich das Risiko da als nicht GANZ so hoch ansetzen würde...
Hauptproblem sind ja Laptops, die aus dem Kofferraum oder dem Zugabteil
gestohlen werden - zu dem Zeitpunkt sind sie aber i.d.R. schon lange
genug aus, damit dürfte der Angriff nicht mehr funktionieren.


Juergen Nieveler
--
As you can see, I have compassion for the mentally retarded
Felix M. Palmen
2008-02-21 22:13:13 UTC
Permalink
Post by Juergen Nieveler
Wobei ich das Risiko da als nicht GANZ so hoch ansetzen würde...
Hauptproblem sind ja Laptops, die aus dem Kofferraum oder dem Zugabteil
gestohlen werden - zu dem Zeitpunkt sind sie aber i.d.R. schon lange
genug aus, damit dürfte der Angriff nicht mehr funktionieren.
Es sei denn man verwendet üblicherweise suspend-to-ram, weil es angenehm
ist, wenn der Rechner in wenigen Sekunden betriebsbereit ist -- ich
glaube ich sollte mich umgewöhnen.

Grüße, Felix
--
Felix M. Palmen (Zirias) \ -PGP- <***@palmen.homeip.net> /"\ ASCII Ribbon
web: http://zirias.ath.cx/ \ http://zirias.ath.cx/pub.txt \ / Campaign
my open source projects: \ FP ED9B 62D0 BE39 32F9 2488 X Against HTML In
http://zirias.ath.cx/?pg=pro \ 5D0C 8177 9D80 5ECF F683 / \ Mail And News
Sebastian G.
2008-02-21 22:31:17 UTC
Permalink
Post by Felix M. Palmen
Post by Juergen Nieveler
Wobei ich das Risiko da als nicht GANZ so hoch ansetzen würde...
Hauptproblem sind ja Laptops, die aus dem Kofferraum oder dem Zugabteil
gestohlen werden - zu dem Zeitpunkt sind sie aber i.d.R. schon lange
genug aus, damit dürfte der Angriff nicht mehr funktionieren.
Es sei denn man verwendet üblicherweise suspend-to-ram, weil es angenehm
ist, wenn der Rechner in wenigen Sekunden betriebsbereit ist -- ich
glaube ich sollte mich umgewöhnen.
Also TrueCrypt registriert sich fuer den Empfang von ACPI-Events und
dismountet vor dem Suspend.
Juergen Nieveler
2008-02-22 20:48:15 UTC
Permalink
Post by Sebastian G.
Also TrueCrypt registriert sich fuer den Empfang von ACPI-Events und
dismountet vor dem Suspend.
Bei dem Angriff geht es aber um HD-Vollverschlüsselung - da ist nichts
mit Dismounten :-)

Aber was anderes: Wie sieht es beim Hibernate aus? Da wird der
Speicherinhalt ja auf die Platte geschrieben, und steht somit erst nach
Kennworteingabe wieder zur Verfügung.

Da dürfte der Angriff auch nicht klappen, oder?


Juergen Nieveler
--
For those who like peace & quiet: a phoneless cord
Sebastian G.
2008-02-22 22:29:36 UTC
Permalink
Post by Juergen Nieveler
Post by Sebastian G.
Also TrueCrypt registriert sich fuer den Empfang von ACPI-Events und
dismountet vor dem Suspend.
Bei dem Angriff geht es aber um HD-Vollverschlüsselung - da ist nichts
mit Dismounten :-)
Eigentlich schon, man muesste nur die Implementierung anpassen.

Viel wichtiger aber ist, dass es beim Shutdown korrekt den Schluessel aus
dem Speicher loescht. Verzichtet man halt auf Suspensd.
Post by Juergen Nieveler
Aber was anderes: Wie sieht es beim Hibernate aus? Da wird der
Speicherinhalt ja auf die Platte geschrieben, und steht somit erst nach
Kennworteingabe wieder zur Verfügung.
Da dürfte der Angriff auch nicht klappen, oder?
Zumindest TrueCrypt unterstuetzt das unter Windows noch nicht, da dort ein
spezieller Treiber (diskdump.sys) geladen wird, welcher am Disk-Treiber
vorbei agiert und direkt die Inhalte schreibt. Unter Linux erst recht nicht,
mangels Implementierung.

Muss mal schauen, wie PGP WDE das verarbeitet. Aber generell hast du recht:
Der Angriff scheitert da.
Michael Reichenbach
2008-02-23 16:57:56 UTC
Permalink
Suspend to disk stelle ich mir ziemlich übel vor. Wenn der Ram auch
abgeschaltet ist wo ist dann der Schlüssel? Na auf der Festplatte
abgespeichert.

Leicht wäre es nicht ihn zu extrahieren, aber möglich schon wenn der
Laptop in dem Moment gestohlen wird.

Auf diese Ruhezustand Funktionen muss man wohl oder übel verzichten wenn
man alles verschlüsselt haben will und denkt in dem Moment könnte der
Laptop gestohlen werden. Oder halt die Verschlüsselungsprogramme müssten
so umgebaut werden das man sich neu authentifizieren muss.
Sebastian G.
2008-02-23 23:29:19 UTC
Permalink
Post by Michael Reichenbach
Suspend to disk stelle ich mir ziemlich übel vor. Wenn der Ram auch
abgeschaltet ist wo ist dann der Schlüssel? Na auf der Festplatte
abgespeichert.
Und zwar verschluesselt mit sich selbst.
Post by Michael Reichenbach
Auf diese Ruhezustand Funktionen muss man wohl oder übel verzichten wenn
man alles verschlüsselt haben will
Wieso?
Post by Michael Reichenbach
Oder halt die Verschlüsselungsprogramme müssten
so umgebaut werden das man sich neu authentifizieren muss.
Momentchen mal... der Bootbloader uebernimmt das doch. Der entschluesselt
das das Hibernate-File, welches in den RAM geladen wird, und transferiert
dann die Kontrolle.

Als einfachen Sanitaetscheck muesste dann der so im RAM landende Schluessel
der gleiche sein wie der zum Entschluesseln verwendete.
Paul Muster
2008-02-25 14:57:26 UTC
Permalink
Post by Michael Reichenbach
Kann man aus normalen RAM Speicher (SD, DDR, etc.) definitiv nichts
mehr wiederherstellen nach dem die Stromzufuhr unterbrochen war oder
gibt es da noch Möglichkeiten?
http://www.heise.de/newsticker/meldung/103908

| Die Daten lassen sich durch Kühlung noch länger haltbar machen: Durch
| Kühlung der Speicherchips mit Druckluft aus Druckluftflaschen auf
| -50 °C blieben Speicherinhalte mit nur sehr geringer Fehlerrate
| mehrere Minuten erhalten. Bei der Kühlung mit flüssigem Stickstoff
| erreichten die Forscher eine Haltbarkeit der Daten im Stundenbereich.


mfG Paul
Stefan Kanthak
2008-02-25 19:36:40 UTC
Permalink
Post by Paul Muster
Post by Michael Reichenbach
Kann man aus normalen RAM Speicher (SD, DDR, etc.) definitiv nichts
mehr wiederherstellen nach dem die Stromzufuhr unterbrochen war oder
gibt es da noch Möglichkeiten?
http://www.heise.de/newsticker/meldung/103908
| Die Daten lassen sich durch Kühlung noch länger haltbar machen: Durch
| Kühlung der Speicherchips mit Druckluft aus Druckluftflaschen auf
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Autsch. Nicht mal mehr richtig abschreiben koennen sie bei Heise!
Typischer Fall von "ueberfliegen" statt "verstehendem Lesen".
Post by Paul Muster
| -50 °C blieben Speicherinhalte mit nur sehr geringer Fehlerrate
| mehrere Minuten erhalten. Bei der Kühlung mit flüssigem Stickstoff
| erreichten die Forscher eine Haltbarkeit der Daten im Stundenbereich.
Stefan
[
--
Die unaufgeforderte Zusendung werbender E-Mails verstoesst gegen §823
Abs. 1 sowie §1004 Abs. 1 BGB und begruendet Anspruch auf Unterlassung.
Beschluss des OLG Bamberg vom 12.05.2005 (AZ: 1 U 143/04)
Juergen P. Meier
2008-02-26 06:19:00 UTC
Permalink
Post by Stefan Kanthak
Post by Paul Muster
Post by Michael Reichenbach
Kann man aus normalen RAM Speicher (SD, DDR, etc.) definitiv nichts
mehr wiederherstellen nach dem die Stromzufuhr unterbrochen war oder
gibt es da noch Möglichkeiten?
http://www.heise.de/newsticker/meldung/103908
| Die Daten lassen sich durch Kühlung noch länger haltbar machen: Durch
| Kühlung der Speicherchips mit Druckluft aus Druckluftflaschen auf
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Autsch. Nicht mal mehr richtig abschreiben koennen sie bei Heise!
Typischer Fall von "ueberfliegen" statt "verstehendem Lesen".
Heisenberg-News...

Lesen Sie weiter auf narkive:
Loading...