mgrzeg

Mogę poprosić o wrzucenie raz jeszcze? Przeterminowały się m.

Coś chyba poszło nie tak podczas przygotowania poprzedniego logu, czy można poprosić o powtórzenie? m.

Nie chodziło mi o zrzut ekranu, a pamięci Użyj procdump, albo z poziomu menadżera zadań (ale nie 64-bit, tylko 32-bit taskmgr z katalogu syswow64). m.

Najwyraźniej program źle zarządza pamięcią. Jak możesz, to przygotuj zrzut, a pewnie da się znaleźć przyczynę. Jeśli aplikacja jest tylko w wersji 32-bit, to szanse są słabe, choć nie zerowe Tak czy owak, daj zrzut, może uda się coś wydłubać i poprawić. m.

Piękny opis! Może pomyśl nad przygotowaniem jakiegoś tutka w artykułach serwisu? Dodaj kilka zrzutów ekranu i w zasadzie prawie gotowiec Szkoda, żeby się wiedza marnowała... BTW - popraw może linki, bo przechodzą przez fb i jest problem z otwarciem stron.

Nie, nie chodziło mi o przenoszenie na partycję FAT - to rozwiązanie działa dla plików zaszyfrowanych z użyciem EFS, ponieważ program przenosząc te dane na dysk FAT wyodrębnia atrybut $efs w postaci osobnego pliku (FAT nie obsługuje alternatywnych strumieni plików). W przypadku przeszukiwania (w trybie RAW) dysku w poszukiwaniu struktur, z których można wydzielić pliki, być może uda się znaleźć część danych w postaci nietkniętej w przypadku plików szyfrowanych pojedynczo (a nie całych katalogów, które szyfrowane są bez tworzenia dodatkowych kopii). Obawiam się jednak, że to już jest 'ostatnia deska ratunku', bo w moim odczuciu szanse na odzyskanie jakichkolwiek plików tą drogą są bardzo małe. m.

W przypadku, gdy szyfrowane są pojedyncze pliki, a nie całe katalogi, EFS tworzy kopię pliku i ją szyfruje, a oryginalne dane zostają na dysku nietknięte. Jest więc zatem szansa, że część danych po prostu leży sobie odłogiem, choć oczywiście mogła zostać już nadpisana podczas późniejszych zapisów. Poza tym nie widzę za bardzo możliwości odzyskania plików, bez dostępu do danych, o których pisałem wcześniej. m.

Obawiam się, że artus72 słusznie prawi i lepiej przygotuj się na najgorsze. Wykonaj to, o co artus72 poprosił i czekaj na odpowiedź Picasso. m.g.

Witam na forum, po pierwsze: proszę na razie nie pracować na tym komputerze, należy zacząć od odzyskania danych z dysku, a przy ciągłej pracy może się okazać, że będzie to niewykonalne. Czy mówimy o 'zielonych plikach', czyli szyfrowaniu EFS, czy chodzi o jakiś inny mechanizm szyfrujący? m.g.

Nie trać nadziei Czekam zatem na pliki. m.

Z podesłanych plików wydaje mi się, że mamy: 1. Zawartość katalogu "Protect" - jest 9 masterkeys, ale bez credhist - może być problem, jeśli hasło było zmieniane. 2. Kilka przykładowych zaszyfrowanych plików + odpowiadające im strumienie $EFS. W strumieniach jest odniesienie do certyfikatu o tym samym thumbprincie, więc wyglądają na ok (dla przykładu sparsowany header dla readme.txt): EFS Stream Header: Len: 680, state: 0, ver: 2, crypto api ver: 0 Num of DDFs: 1, DRFs: 0 DDFs: SID: S-1-5-21-4086565395-1801921026-186742713-1001: Certificate: Thumbprint: 0C4E4D97201AB64CA36C03B3C9A98D47F5C4C2C8 Container name: 12609a1d-c1cf-41a1-8ae1-12d1ec724be5 Provider name: Microsoft Enhanced Cryptographic Provider v1.0 User name: Arcade(mailto:Arcade@Arcade-PC) Encrypted FEK: 8B 0F 33 98 34 CE E9 98 8A 46 71 82 16 EB 46 D7 ?.3?4Îé??Fq?.ëF× 85 2B 13 CA 0B 9F C6 24 72 AB 33 76 8E 11 6A 50 ?+.E.?A$r«3v?.jP A2 71 CF DF DD 23 29 58 F0 07 8D 42 AB C2 BB 54 cqIßÝ#)X?.?B«Â»T 0D 92 FD 3C B6 B7 FC 56 3B E0 64 1A 10 67 8D 06 .?ýEA F3 70 B0 80 F5 E4 05 4D 21 93 40 AA 93 B2 B1 eóp°?oä.M!?@a?2+ 4C D7 F4 F0 54 BA 86 A9 ED CB 9D EA 94 91 18 03 L×ô?To?cíË?e??.. 8E 7B 6B 76 55 48 6A EB 58 23 08 8E E5 61 13 62 ?{kvUHjëX#.?aa.b A4 A7 93 66 B0 5E A7 10 EB 9D 61 E4 3B 98 8D D5 ¤§?f°^§.ë?aä;??O B7 B8 AD B7 30 02 61 32 D2 1A DC 6C C4 6F 5B 82 ¸­0.a2O.ÜlÄo[? CC 08 E2 10 05 A8 C1 58 6B C3 63 D5 FC C7 A7 42 I.â..¨ÁXkAcOüǧB 6B F4 C3 8C 5D 4C 40 F0 E6 AC 50 D9 40 5C D7 F4 kôA?]L@?a¬PU@\×ô FA 4B 0F 42 E3 8D B1 82 44 D0 1A 8B 6D 11 1A 33 úK.Ba?+?D?.?m..3 67 CB A5 1C 81 B4 88 BB ED 31 AA F2 C8 4B 4B 9B gËY.?´?»í1aoEKK? 15 49 BF 40 E6 61 B5 29 CC 52 EB A7 8B 67 FE D2 .I?@aau)IRë§?g.O 4E 47 5B EB E2 DC 49 72 5A D5 F4 67 53 7F E4 C6 NG[ëâÜIrZOôgS.äA DD EB A8 CC B9 D5 DF 22 A1 59 75 AA AB 17 27 05 Ýë¨I1Oß"!Yua«.'. Niestety kilku rzeczy jeszcze nie mamy: 1. W katalogu data1\NTFS 0\$Volmue\Users\Arcade\AppData\Roaming\Microsoft\Crypto\RSA jest to samo, co w Protect - zamiast zaszyfrowanych kluczy RSA mamy masterkeys. Sprawdź, czy przypadkiem coś się nie pomieszało przy wysyłce, ewentualnie jeszcze raz wyciągnij te pliki. 2. Wszystkie pliki rejestru (data1\NTFS 0\$Volmue\Users\Arcade\NTUSER(i).DAT oraz z katalogu data1\NTFS 0\$Volmue\Windows\System32\config\) są uszkodzone. Oczywiście nie są dla nas niezbędne, ale mogą być pomocne. Koniecznie potrzebuję zawartość RSA, przydałby się też CREDHIST z Protect. Pliki rejestru możesz podesłać później (zacznij od pliku SOFTWARE, skoro mam thumbprint, to pliki NTUSER.DAT użytkownika już nie są potrzebne) m.g.

Brakuje jeszcze jakiegoś zaszyfrowanego pliku, który chcesz odzyskać Tak, jak pisałem - potrzebne są dane + zawartość atrybutu $EFS. Wszystko razem spakuj z hasłem np. 7-zipem, wrzuć na jakiś hosting i zapodaj mi link w prywatnej wiadomości. Niestety, wszystkie moje narzędzia, z których korzystam, nie nadają się do publikacji i muszę prosić Cię o podesłanie danych do mnie. Nie ukrywam, że pracuję nad możliwością wygenerowania .pfx-a, który mógłbyś sobie zaimportować, bez konieczności proszenia mnie o pomoc, ale na razie jestem jeszcze w lesie m.

Odnośnie rejestru: można spróbować sięgnąć do rejestru użytkownika (czyli pliku ntuser.dat z profilu) i wyciągnąć zawartość podklucza "Software\Microsoft\Windows NT\CurrentVersion\EFS\CurrentKeys", a z pliku SOFTWARE (czyli gałęzi HKLM\Software) wyciągnąć podklucz "Microsoft\SystemCertificates" wraz ze wszystkimi podkluczami i blobami. Co do systemu plików: niewiele pomogę, sam korzystam z własnych narzędzi opartych o TSK [KLIK], ale nie są to narzędzia do odzyskiwania danych, a raczej prostej analizy. m.g.

Witam, odnośnie wyciągania danych z dysku moja pomoc jest mocno ograniczona - ani nie znam tego narzędzia, ani nie jestem w tym zakresie specjalistą. Może ktoś jeszcze na forum będzie w stanie coś więcej pomóc? Odnoszę wrażenie, że skoro widzisz zawartość katalogów, to możesz próbować wyciągać dane na jakiś inny dysk. Edit: strumienie $EFS oraz $DATA powiązane są z konkretnymi zaszyfrowanymi plikami. $DATA to po prostu dane pliku, natomiast $EFS - dodatkowy atrybut zawierający informacje o kluczu szyfrującym. Wrzuć listę plików z katalogów Protect oraz RSA - tam powinny być podkatalogi, a w nich pliki. Na podanym przez Ciebie zrzucie widać podkatalog dla RSA, którego nazwa kończy się na 1001 -> to o niego chodzi m.g.

Witam na forum, faktycznie przypadek nieco cięższy od poprzedniego. Do odzyskania danych muszę mieć: - skrót SHA1 ostatniego hasła użytkownika (lub samo hasło); - zawartość katalogu Protect wraz z podkatalogami (tu są zaszyfrowane masterkeys użyte do szyfrowania blobów DPAPI) - zawartość katalogu RSA z podkatalogami (tu są zapisane klucze prywatne, z których jeden jest użyty do szyfrowania FEK); - strumień danych powiązany z atrybutem $EFS (prawdopodobnie w tablicy mft dla rekordu x będzie postaci x-256-8 (albo coś innego na końcu, 256 odpowiada za typ LOGGED_UTILITY_STREAM) - tu jest zaszyfrowany FEK; - strumień $DATA powiązany z zaszyfrowanym plikiem, ale wraz ze slack space, a więc do końca klastra (EFS szyfruje co prawda w porcjach po 512 bajtów, ale nic się nie stanie, jak dostanę nieco więcej. Certyfikaty fajnie byłoby mieć, ale one zawierają tylko część publiczną klucza, która w tym momencie nie jest nam potrzebna. Pewnym utrudnieniem będzie lokalizacja pliku zawierającego klucz prywatny powiązany z certem, ale zakładam, że nie ma ich miliony, więc może uda się znaleźć właściwy mając tylko same klucze. m.g.

Hmm... wygląda na problem ze sterownikiem karty graficznej, lub coś w win32k.sys. Próbowałeś połączyć się RDP z tą maszyną i sprawdzić jak wtedy wygląda ta czcionka? m.

Zapowiada się bardzo dobrze - na podstawie podesłanych przez Ciebie danych wygląda na to, że udało mi się odzyskać klucz prywatny RSA, który był wystawiony razem z certyfikatem EFS Spróbowałem odszyfrować podesłany przez Ciebie plik i w wyniku mam coś, co również wygląda na zaszyfrowany plik z nagłówkiem: "K2T.File.Encrypted:1.0". Ma to sens? Możesz podesłać jakiś czytelniejszy plik jako próbkę? (oczywiście wraz z odpowiadającym mu strumieniem $EFS - każdy plik ma osobny FEK!) m.

7 lat temu, gdy i mi jeszcze dane było być w gronie polskich MVP, powstał tekst wprowadzający w tematykę programu: http://wss.geekclub.pl/baza-wiedzy/program-mvp-w-polsce,1338 Jest też (nieoficjalna) strona poświęcona polskim MVP: http://msmvp.pl/ m.g.

Nie mam gotowego narzędzia do udostępnienia, ale mogę spróbować pomóc w odzyskaniu danych. Niestety będę potrzebował (katalogi wraz z podkatalogami): - komplet kluczy RSA z %APPDATA%\Microsoft\Crypto\RSA - komplet kluczy DPAPI zawierający pliki CREDHIST oraz zaszyfrowany zestaw masterkeys, czyli zawartość katalogu %APPDATA%\Microsoft\Protect - zestaw certyfikatów użytkownika, czyli zawartość katalogu %APPDATA%\Microsoft\SystemCertificates - skróty SHA1 oraz MD4 ostatniego hasła użytkownika zakodowanego jako UTF16-LE, które było używane na tamtej instalacji (do odszyfrowania pierwszego z masterkeys). (lub jeszcze lepiej samo hasło, ale mogę zrozumieć wątpliwości) Przydałaby się także próbka zaszyfrowanego pliku, a więc strumienie $DATA oraz $EFS dla któregoś z plików. Wszystko spakuj 7-zipem (z hasłem) i udostępnij gdzieś, a hasło możesz podesłać via pm. Przygotowanie narzędzia, które mógłbym udostępnić szerzej może mi zająć trochę czasu, więc na razie nic więcej nie mogę pomóc.

I jak idzie odzyskiwanie danych? Jakieś postępy? Metoda 'ręczna' opisana w linku podanym przez Ciebie wydaje się dosyć długa i bez gwarancji powodzenia, niestety... Kilka pytań: - czy zaszyfrowane pliki widzisz w eksploratorze jako 'zaszyfrowane' (na zielono)? Dużo ich jest i tworzonych w różnym czasie? - czy masz komplet plików z poprzedniego systemu z Twojego profilu, tj. %APPDATA%\Microsoft? m.g.

Jest jeszcze inna opcja, właśnie podsunął mi ten pomysł Jean-Michel (ten od DPAPIck) Otóż istnieje implementacja efs w ramach projektu ntfs-3g, który występuje w większości współczesnych dystrybucji linuxa. Wystarczy użyć ntfsdecrypt z pakietu ntfsprogs [KLIK] i podając klucz w postaci .pfx + hasełko do klucza prywatnego + ścieżkę do pliku można odszyfrować zawartość. Nie sprawdzałem, ale z tego co widzę w źródłach, wygląda to jak najbardziej sensownie i powinno działać. Postaram się sam napisać tool do tego celu, działający pod windows, jednak nie jest to kwestia najbliższego czasu, więc niczego nie mogę obiecać. m.g.

Informacja o kluczu zapisana jest w dodatkowym strumieniu do zaszyfrowanego pliku, $EFS. Jest tam informacja zarówno o SIDzie użytkownika, jak i odcisk palca dla certyfikatu, container gui + 256 bajtów zaszyfrowanego klucza (FEK) (plus inne rzeczy, typu suma kontrolna). Wygląda na to, że nad tymi wszystkimi danymi trzeba mieć kontrolę, co zdaje się w tym momencie potrafi bodaj tylko wspomniany przez Ciebie program. Przyznaję, że sam też bawiłem się trochę EFS, jednak bez większych sukcesów. Zatrzymałem się na deszyfrowaniu FEK, bez sukcesu Jestem w kontakcie z autorami DPAPIck, jednak do ostatecznego rozwiązania jeszcze daleka droga Czy udało Ci się coś więcej ustalić? m.g.

Zacznij od aktualizacji systemu, to podstawa. Druga rzecz, to aktualizacje dla wszelkich programów z których korzystasz, poczynając od wszelkiej maści Javy, Adobe Readera, Flash Playera, a także antywirusów, etc. Możesz użyć np. 7-zip i podejrzeć zawartość, bez wypakowywania wszystkiego. Jeśli .rar nie ma ustawionego hasła i zawartość nie jest zaszyfrowana, to programy AV powinny móc wykryć różnego typu zagrożenia. Gdy zdecydujesz się na wypakowanie całości, to zrób to do osobnego katalogu, który możesz przejrzeć np. z poziomu wiersza poleceń. Eksplorator windows może generować miniaturki i próbować interpretować różne pliki, stwarzając zagrożenie nieumyślnego załadowania czegoś (vide przykład stuxnetu). W cmd jesteś względnie bezpieczny W aplikacjach office'owych wyłącz możliwość uruchamiania makr, w Adobe Readerze wyłącz javascript. Pliki tekstowe możesz przeglądać np. notatnikiem, albo notepad++, w przypadku dużych plików (powyżej 100MB) możesz użyć pfe (http://www.lancaster.ac.uk/people/steveb/cpaap/pfe/pfefiles.htm). W przypadku plików binarnych możesz użyć np. hexplorer, lub hexedit (http://www.mitec.cz/hex.html). Oczywiście najlepiej, jeśli użyjesz maszyny wirtualnej dedykowanej do analizy wszelkiego typu podejrzanych plików, ale jeśli źródło jest względnie zaufane, to powyższe kroki powinny wystarczyć. m.

Hmm... dalej widzę adresy IPv6 na kartach + dnsach. Możesz to sprawdzić w ustawieniach karty sieciowej i powtórzyć przygotowanie logu? m.

Zmian w zasadzie nie ma, więc bez zbędnej zwłoki sugestia. Jeśli nie korzystasz z IPv6, to pomyśl o wyłączeniu, lub usunięciu IPv6 i interfejów ISATAP, np. poprzez netsh: netsh int isa set state disabled lub korzystając z FixIt Microsoftu: [KLIK] Po wszystkim poproszę ponownie o kolejny log. (nie wiem, czemu robi się tak długi i duży - ustawione masz prawidłowo 180 sek). m.