Záchrana dat z RAM zaseklého běžícího počítače

[RDa]

Btw jako nejjenodussi pristup je pridat do kompu:
- PCI/PCIe kartu s DMA pristupem (umeli to stare FireWire karty, ktere meli explicitni podporu ve win debuggeru)
- pripadne pouzit modernejsi nahrazku - PCILeech, DMA Warrior, LeetDMA, atd

Vsechno tohle ale vyzaduje:
- vypnuti IOMMU v biosu a v OS
- pristupovat jen na adresy kde fyzicka pamet je, jinak se muze stat ze se komp rovnou resetne

[Reklama]

[Rovano _]

+ Jestli to jde (na windows) nějak řeši do budoucna. Se na to připravit, třeba něco jako telnet do windows, do kterého by se i v této situaci šlo připojita killnout dwm. exe. NEbo nějak se připojit přes sériový port nebo nějak vykonat třeba příkaz pro restart dwm.exe nebo restart grafického driveru.

Tento Win umí restart dwm nebo ovladače. Obávám se, že právě z důvodu opakovaného selhání je v tomto stavu.

[CFM]

Pokud si dobře pamatuji při rebootu z RAM zmizí elektrické napětí, opětovně se objeví a to pamětové buňky " tvz. smaže".  Ty biti(příp. bajty) tam nezůstanou, což je dobře.

Nějaký relevantní zdroj k takovému tvrzení? Též bych si vsadil na variantu, že k tomu nedojde.

* Případná ECC (nebývá běžná u úplně obyčejných kancelářských strojů) může na jednu stranu pomoci (větší šance u cold bootu, aspoň teoreticky – nevím, jak je to prakticky významné u dnešních RAM), na druhou stranu tam BIOS typicky přemaže obsah RAMz aby zabránil falešným chybám při čtení neinicializované RAM.

Dobrá připomínka. Že v případě ECC může paměť mazat BIOS mě nenapadlo.

BTW debugoval jsem custom zařízení s FPGA/DDR2, kde byl právě problém s DDR2 a překvapilo mě, jak dlouho data v paměti drží při vypnutém napájení. Očekával jsem, že po pár sekundách tam nebude nic, ale i po několika minutách tam byly rozpoznatelné zbytky původních dat. Spolu s ECC a chybou v řadiči to způsobovalo takové náhodné chování, které mě dost mátlo. Právě při krátkých vypnutích se to tvářilo celkem bezproblémově a po dlouhém odležení nastaly potíže, když už to ECC nedokázala opravit. Takže především ráno a po obědě to nechtělo naběhnout :-)

[kanoe22]

Ħαℓ₸℮ℵ ␏⫢ ⦚

Moznost A) Ak ten pocitac este bezi, skuste napisat do NSA, CIA, a ostatnych troj (a štvor) pismenkovych agentur a za par tisic eur isto rad prileti typek s vybavou - tekutym dusikom a masinou upravenou na cold boot attack. Ten typek vam vytiahne data co este zostali vo vasich ramkach do svojich, tie ulozi na disk, a ten disk s tou kopu neusporiadanych smeti vam potom da. Nasledne mozte travit niekolko mesiacov az desatroci skladanim dat do niecoho co bude davat zmysel.

Moznost B) Prestat sa divat na rozne CSI kriminalky, skodi vam to.

[Mintaka]

Něco z těch "kriminálek" je nesmysl, spousta věcí nesmysl není, ale bývá to bývá podáno "uměleckou zkratkou"

V realitě je toho možného dokonce mnohem víc, než ukazují ve filmech/seriálech a je to o znalostech a vybavení.

V domácích podmínkách by minimálně stál za pokus rychlý hw restart (pokud na to nemáte tlačítko, tak by mohly být piny na základovce), nabootování do nějakého minimalistického Linuxu a odtud dump paměti někam na externí disk.
Pokazit by to mohl BIOS, kdyby dělal kontrolu a vynulování RAM. Novější počítače už to, hádám, nedělají, ale volba typu "Fast Boot" a podobné by tomu měly napomoci.

Pro Linux bych hledal něco ke čtení z /dev/mem

Pro Widle je nějaký návod zde:
https://knowledge.broadcom.com/external/article/179911/create-a-full-memory-dump.html

[Reklama]

[Ħαℓ₸℮ℵ ␏⫢ ⦚]

Díky za všechny odpovědi je to dost rozmanité  a já spíš myslel něco "in-band" a bez externího hardwaru ,ale asi bych nic nenašel.

Ten hajzl celou dobu běžel, zapisoval do protokolu událostí, jen jsou umazané asi kvůli počtu záznamů, je jich tam posledních 60 tisíc
 (když dám filtr "-140", tak jich to podobných 59800  skryje, každou sekundu něco o protokolu transakcí, ale to už registroval jsem předtím, asi se nějak zbláznil driver virtuálního disku v RAM i když nebyl ani jeden disk v RAM vytvořen).Nezahrnuje bohužel už okamžik crashe, ale den poté. A zahrunuje den před vypnutím.

Takže nic zajímavého jsem tam nenašel, zřejmě se během těch dvou dnů slepoty nic zajímavého nedělo (kromě odpojování ethernetu a monitoru).

Jo, je tam že předchozí vypnutí systému bylo neočekávané a asi 30x něco ve smyslu, že driver síťové karty požádl o restartování síťovky po 73, po 74 ...

Je tam jedna zajímavá událost ne z Záložky Systém, ale aplikace, tak ji sem postnu. upoutalo mě to hodně kostrbatým překladem.

[Marek Staněk]

...
vědecké knihovny (na kterou jsem se štěstím čekal jen 1/2roku), jsem vyčetl, že by za to mohly vadné RAM moduly. Tehdá ...
zvuk, ty které byly vadné vydávaly nepěkné šumoruchy. Pak bylo potřeba ty vadné vydolovat z patic a dát tam funkční z jiného počítače. Po téhle proceduře zbyly dva nefunkční, zkanibalizované, počítače a 8 perfektně šlapajících mašinek.

Jo, tohle nám PCčka ze svrchní křídy ve škole dělala taky, úplně stačilo DIPové brouky zamáčknout na jednom konci, pak na druhém, čímž se částečně povytáhly, a zmáčknutím uprostřed zatlačit zpátky. Docházelo totiž k elektrochemické oxidaci na styku nohou s kontakty patice. Pak to zase měsíc až dva chodilo. Jak to začlo zlobit, rinse & repeat.

[Jan Fikar]

Pokud si dobře pamatuji při rebootu z RAM zmizí elektrické napětí, opětovně se objeví a to pamětové buňky " tvz. smaže".  Ty biti(příp. bajty) tam nezůstanou, což je dobře.

Nějaký relevantní zdroj k takovému tvrzení? Též bych si vsadil na variantu, že k tomu nedojde.

Ztráta napětí právě data nesmaže. A vydrží tam tím dýl, čím je nižší teplota. DRAM jsou v podstatě kondenzátory a normálně za běhu se musí čas od času přečíst a znovu zapsat.

https://en.wikipedia.org/wiki/Memory_refresh

Takže když paměti ochladíte, opojíte a do pár sekund zase uděláte refresh, tak tam nějaká data zbudou.

https://www.pdl.cmu.edu/PDL-FTP/NVM/dram-retention_isca13.pdf

[Vít Šesták (v6ak)]

Ten experiemnt probíhal s DDR3. IIRC, novější DDR4 se typicky po ztrátě napětí mažou výrazně rychleji než DDR3.

Pokud ale něco při resetu RAM vymaže, bude to spíš BIOS (zmíněná kontrola RAM nebo vynulování ECC RAM) než vypnuté napájení, které by vyžadovalo další elektroniku, bylo by do nějaké míry zbytečné a jehož dopad (zvlášť na tak krátkou dobu) je přinejmenším s otazníkem.

[technomaniak]

...

No já si to pamatuji trochu jinak. Tu informaci mě vysvětlovali na nějaké kurzu na konci 90tek. To tehdy byli ještě SDRAM (nebo jak se to tehdy jmenovalo)a je možné že u nich to fungovalo jinak.  Bez ohledu na to jak to v těch pamětích funguje se všichni shodneme, že neexistuje jednoduché("domácí") řešení jak z pamětí získat data v případě zamrznutí softwaru (OS či Biosu/uefi) či  hw(procesoru, či jiných). Navíc se jedná ještě binární data které si "náhodně" v paměti umísťuje OS a i kdyby se dali získat je velmi obtížné a velmi pracné z nich nějaké informace vyčíst.

[RDa]

Btw na modernich procesorech jsou data scramblovana, jakozto ochrana predtim, kdyz vam "nekdo" vynda celou dimm a bude se ji snazit precist. Takze smolik tak jako tak. Imho kazdy boot bude generovat novy nahodny klic.

https://en.wikipedia.org/wiki/Memory_controller#SCRAMBLING
https://security.stackexchange.com/questions/251715/disable-memory-scrambling

https://www.amd.com/system/files/documents/amd-memory-guard-white-paper.pdf

[Vít Šesták (v6ak)]

Že zběžného projití odkazů jsem pochopil:

a. Memory scrambling tu není primárně pro bezpečnost a lze obejít. Navíc pro malé bloky dat nemusí být žádnou překážkou.
b. AMD memory guard je něco jiného, sami v dokumentu píší, že scrambling nestačí. A tuším, že to podporují jen některé procesory, navíc to nemusí být vždy zapnuté.

[Jan Fikar]

...

No já si to pamatuji trochu jinak. Tu informaci mě vysvětlovali na nějaké kurzu na konci 90tek. To tehdy byli ještě SDRAM (nebo jak se to tehdy jmenovalo)a je možné že u nich to fungovalo jinak.  Bez ohledu na to jak to v těch pamětích funguje se všichni shodneme, že neexistuje jednoduché("domácí") řešení jak z pamětí získat data v případě zamrznutí softwaru (OS či Biosu/uefi) či  hw(procesoru, či jiných). Navíc se jedná ještě binární data které si "náhodně" v paměti umísťuje OS a i kdyby se dali získat je velmi obtížné a velmi pracné z nich nějaké informace vyčíst.

No to myslíte SRAM, tam není potřeba refresh a po odpojení a připojení napájení se to většinou samo vnitřně resetuje.

https://en.wikipedia.org/wiki/Random-access_memory#Memory_cell

[Michal Kubeček]

Pokud operační systém "tvz. zamrzne" neexistuje žádné software řešení jak data z RAM získat.

Existuje a celkem běžně se i používá, příkladem je linuxový kdump. Má to ale dva háčky: za prvé je potřeba ho mít nakonfigurovaný a připravený předem, za druhé nevím, jestli je něco podobného běžně dostupné i pro Windows, které používá tazatel.

[František Ryšánek]

Velmi matně si pamatuju, že v dávných dobách snad existovaly "ladící" karty do PCI, které pomocí bus masteringu dokázaly sáhnout kamkoli do hostitelovy DRAM, tzn. také udělat kompletní obraz RAM zaseklého počítače, pokud byl do té míry funkční.

Nejsem si jistý, zda přístup z PCI do adresního prostoru hostitelova procesoru (resp. fyzické DRAM) podléhá nějakým omezením, a jakým. Vím že PCI host bridge (a další bridge za ním) filtrují/dekódují přístup z hostitele do MMIO oken periferií - ale opačným způsobem... nevím. Je možné, že se toto v průběhu desítek let vývoje PCI nějak vyvíjelo, předpokládal bych směrem k utužení bezpečnosti. Určitě do toho má co mluvit IOMMU v případě mapování PCI(e) zařízení guestům, ale nejsem si jistý, zda v defaultní konfiguraci prostě pustí BM transakce ze strany PCI sběrnice kamkoli do RAMky fyzického hostitele.

A pokud se k obrazu RAMky dostanete, k nápadu "něco z toho zjistit" se tu vyjádřili ostatní. Kdyby aspoň ten obraz byl "plochý", ale ony user-space aplikace dostanou fyzickou RAMku přidělenou několikapatrovým překladem adres stránkovacího mechanismu, a pak nad tím přídělem ještě běží nějaký alokátor... Takže najít a parsovat kernelové page allocation tables, a nad tím alokátor příslušné "runtime knihovny" dané aplikace... a pak se snad dostanete k nějakým datům.

Zkusil bych tomu stroji dát kouř Memtest86+. Přes noc, nebo pár dnů v kuse.
Pokud PC tohle ustojí, tak to pořád není garance, že tam není nějaký další bug. Třeba pokud je načatá grafika, tak zatuhlý grafický ovladač asi dokáže systému taky solidně zamotat hlavu.
Čerstvá verze memtestu je koukám sedmička (hledejte string "latest version"), já tuším jedu ještě na 6.20 - viz archiv, pokud nemáte rád kulaté verze.