Прекъснете криптирането тип XOR с целия известен текст от вируса

Бях засегнат от инфекция с ransomware, която криптира първите 512 байта в горната част на файла и ги поставя в дъното. При разглеждане на шифрования текст изглежда, че е някакъв тип XOR шифър. Знам целия обикновен текст на един от файловете, който беше шифрован, така че реших, че на теория би трябвало да мога да го xor, за да получа ключа за дешифриране на останалите ми файлове. Е, много ми е трудно с това, защото не разбирам как създателят наистина го е xor'ed. Мисля, че ще използва двоичен четец, за да прочете първите 512 байта в масив, да го XOR и да го замени. Но това означава ли, че той го е XOR в HEX? или десетичен? Доста съм объркан в този момент, но вярвам, че просто пропускам нещо.

Опитах Xor Tool с python и всичко, което се опитва да кракне, изглежда безсмислено. Опитах също скрипт на Python, наречен Unxor, на който давате известния обикновен текст, но дъмп файлът, който извежда, винаги е празен.

Думп на добър заглавен файл: Good-Header.bin a>

Дамп на шифрован заглавен файл: Enc-Header.bin

Това може да не е най-добрият пример за файл, за да видите модела XOR, но това е единственият файл, който имам, който също има оригиналния хедър 100% преди криптиране. В други заглавки, където има повече промени, шифрованата заглавка се променя с него.

Някакви съвети за метод, който трябва да опитам, или приложение, което трябва да използвам, за да опитам да продължа това? Благодаря ви много за помощта!

P.S. Stackoverflow ми се развика, когато се опитах да публикувам 4 връзки, защото съм толкова нов, така че ако предпочитате да видите шестнадесетичните дъмпове на pastebin, отколкото да изтеглите заглавните файлове, моля, не ми позволявайте. Файловете по никакъв начин не са злонамерени и са само извлечените 512 байта, а не цял файл.


person user3546043    schedule 17.04.2014    source източник
comment
Генерирах общ отговор за вас, за да разберете по-добре темата. Поради малкия шанс за успех и факта, че резултатът ще бъде приложим само за вас, малко вероятно е някой да направи дешифрирането вместо вас.   -  person Maarten Bodewes    schedule 18.04.2014
comment
Няма xor модел, който да се види. Ако винаги има друг поток, който е бил използван за шифроване на заглавки на файлове, той се счита за неразбиваем, освен ако потоците не са свързани по същия начин например. en.wikipedia.org/wiki/One-time_pad   -  person Luka Rahne    schedule 18.04.2014
comment
Owlstead, Благодаря за отговора :) и никой не е помолил никого да направи някакво дешифриране вместо мен, както можете да видите по-горе, поисках съвет :)   -  person user3546043    schedule 18.04.2014


Отговори (2)


За да възстановите ключовия поток XOR на байтовете на обикновен текст с байтовете на шифрован текст. Направете това с два различни файла, за да можете да видите дали рансъмуерът използва един и същ ключов поток или различен ключов поток за всеки файл.

Ако използва същия ключов поток (малко вероятно), тогава проблемът ви е решен. Ако ключовите потоци са различни, тогава най-лесното ви решение е да възстановите засегнатите файлове от архиви. Пазехте резервни копия, нали? Като алтернатива проучете конкретната инфекция, която имате, и вижте дали някой друг е разбил този конкретен вариант, така че можете да извлечете използвания(те) ключ(ове) и по този начин да генерирате повторно необходимите ключови потоци.

Ако имате много пари, фирма за възстановяване на данни може да е в състояние да ви помогне, но със сигурност ще таксува.

person rossum    schedule 17.04.2014
comment
Е, мога да кажа, че един и същ ключ се използва за всеки файл, защото в 2 различни pdf файла маркерът %PDF encrypted изглежда абсолютно еднакъв. Случайно да знаете за някакъв .net код, който би ми помогнал да коригирам двоичен файл с познат текст? намерих няколко, но всички добавят допълнителни неща във функцията. Благодаря - person user3546043; 18.04.2014
comment
Вие не използвате XOR с текст, а XOR с двоичното представяне на текста. Всъщност вие четете файла като байтове данни, а не текст. Третирайте го като байт [], а не като низ. Вие XOR два байта [] един с друг, за да произведете трети байт [], ключовият поток. - person rossum; 18.04.2014
comment
@user3546043, един и същ [блок от] обикновен текст винаги ще води до един и същ [блок от] шифрован текст дори със силен симетричен блоков шифър, — при условие че шифърът работи в режим на електронна кодова книга (ECB), т.е. д. без вектор за инициализация. Така че вашето наблюдение не доказва практически нищо. - person Anton Samsonov; 18.04.2014
comment
Така че днес успях да пробия, мисля (може би?). Така че послушах съвета на Rossum и сложих първия байт на шифрования файл с първия байт на оригиналния файл. След това успях да взема резултатния байт и го направих с Xor на първия байт на множество шифровани файлове и винаги създаваше първата буква от маркера за този файл. Но си спомням, че човекът, с когото тествах по-рано, каза, че следващият байт е свързан с последния (мисля CFB?), така че не мога просто да го XOR като първия? - person user3546043; 18.04.2014
comment
@user3546043, блоковите шифри работят с блокове, а не с байтове или битове. „Блок“ е например поредица от 64 бита, която може да бъде разделена на двойка 32-битови „крайници“. Шифър, подобен на Feistel, смущава крайниците, като ги смесва с няколко „кутии за заместване“ и „кръгъл подключ“ - до няколко десетки кръга на един блок. Така че не е толкова просто, колкото c = p ^ k очаквахте. Дори с 8-битов ключ като "A", изходът ще изглежда напълно случаен. - person Anton Samsonov; 18.04.2014
comment
Добре, така че въпреки че можем да върнем първия байт от всеки шифрован файл, има нещо много по-сложно, което се задава - person user3546043; 18.04.2014

Основно правило, за да различите приличен шифър от шифър на играчка, е да шифровате силно компресируем файл и да се опитате да го компресирате в неговата криптирана форма: тъп шифър ще произведе файл с ниво на ентропия, подобно на това на оригиналния, така че криптираният файл ще се компресира, както и оригиналният; от друга страна, добър шифър (дори без вектор за инициализация) ще произведе файл, който ще изглежда като случаен боклук и следователно няма да се компресира изобщо.

Когато компресирах вашия Enc-Header.bin от 512 байта с PKZIP, изходът също беше 512 байта, така че шифърът не е толкова тъп, колкото очаквахте — лош късмет. (Но това не означава, че зловредният софтуер изобщо няма слаби места.)

person Anton Samsonov    schedule 18.04.2014
comment
Не знаех това, благодаря за тази полезна информация! - person user3546043; 18.04.2014