Предлагаю тут постить запросы на реверс малвары или файлов в которых вы не уверены.

Формат запроса:
1. Краткое описание задачи, к примеру "Прошу помочь удалить" или "Не пойму почему антивирус называает ...."
2. Аномалии при работе с компом, которые заметили.
3. Ссылка на файл, точная ссылка. К примеру rapidshare. Архив со всем необходимым обязательно должен быть с паролем "virus" (без кавычек).
4. Описание того, что вы уже сделали и какие получили результаты. Рекомендую отказаться от "Вероятно, это...", а лучше "Запустил тулзу... и увидел что...". Вобщем лучше лишний раз проверить, чем писать что вы всего лишь думаете, что это или хотя бы не так открыто, а после каких-нить телодвижений.

-----
My love is very cool girl.

| Сообщение посчитали полезным:

DeeDee
Перезалей
гляну

| Сообщение посчитали полезным:

http://rgho.st/8f8gB9W2G пасс virus
поймал вместо кейгена ,сам под энигмой у меня не запускается что за хрень?

| Сообщение посчитали полезным:

[deleted]

-----
z+Dw7uLu5+jqLCDq7vLu8PvpIPHs7uMh

| Сообщение посчитали полезным:

APK для андройд нужно узнать адрес куда сливает информацию, пишите в личку телеграм или жабер: за вознагрождение
Код не обфусцированный

| Сообщение посчитали полезным:

Все тот же APK для андройд пересобрал кое че, стало жестко глючить, кто может отладить чтобы работало стабильно?

| Сообщение посчитали полезным:

Подцепил вероятно зверя, заметил случайно, в процессэксплорере увидел необычный хром ехе, после просмотра параметров увидел такую запись



--disable-client-side-phishing-detection
--enable-auto-reload
--no-v8-untrusted-code-mitigations

Untrusted code mitigations
In early 2018, researchers from Google’s Project Zero disclosed a new class of attacks which exploit speculative execution optimizations used by many CPUs. Because V8 uses an optimizing JIT compiler, TurboFan, to make JavaScript run quickly, in certain circumstances it is vulnerable to the side-channel attacks described in the disclosure. Update to the latest V8 to benefit from mitigations and enable mitigations
Mitigations for this class of attack are available in V8 itself starting with V8 v6.4.388.18, so updating your embedded copy of V8 to v6.4.388.18 or later is advised. Older versions of V8, including versions of V8 that still use FullCodeGen and/or CrankShaft, do not have mitigations for SSCA.

Starting in V8 v6.4.388.18, a new flag has been introduced to V8 to help provide protection against SSCA vulnerabilities. This flag, called --untrusted-code-mitigations, is enabled by default at runtime through a build-time GN flag called v8_enable_untrusted_code_mitigations.

These mitigations are enabled by the --untrusted-code-mitigations runtime flag:

Masking of addresses before memory accesses in WebAssembly and asm.js to ensure that speculatively executed memory loads cannot access memory outside of the WebAssembly and asm.js heaps.
Masking of the indices in JIT code used to access JavaScript arrays and strings in speculatively executed paths to ensure speculative loads cannot be made with arrays and string to memory addresses that should not accessible to JavaScript code.
Embedders should be aware that the mitigations may come with a performance trade-off. The actual impact depends significantly on your workload. For workloads such as Speedometer the impact is negligible but for more extreme computational workloads it can be as much as 15%. If you fully trust the JavaScript and WebAssembly code that your embedded V8 instance executes, you may choose to disable these JIT mitigations by specifying the flag --no-untrusted-code-mitigations at runtime. The v8_untrusted_code_mitigations GN flag can be used to enable or disable the mitigations at build time.

Note that V8 defaults to disabling these mitigations on platforms where it is assumed the embedder will use process isolation, such as platforms where Chromium uses site isolation.

Sandbox untrusted execution in a separate process
If you execute untrusted JavaScript and WebAssembly code in a separate process from any sensitive data, the potential impact of SSCA is greatly reduced. Through process isolation, SSCA attacks are only able to observe data that is sandboxed inside the same process along with the executing code, and not data from other processes.

Consider tuning your offered high-precision timers
A high-precision timer makes it easier to observe side channels in the SSCA vulnerability. If your product offers high-precision timers that can be accessed by untrusted JavaScript or WebAssembly code, consider making these timers more coarse or adding jitter to them.

Если посмотреть Job вкладку -


Процесс находится в суспендет режиме, сдампить нельзя -

---------------------------
Process Explorer
---------------------------
Error writing dump file: Only part of a ReadProcessMemory or WriteProcessMemory request was completed.
---------------------------
OK
---------------------------

Артилерию не подключал, важные данные в работе, но не критичные для инета, боюсь в бсод улетит, но чуть позже конечно попытаюсь сдампить. Может кто имел дело?!

P.S> отбой, ложная тревога ..
Хром вкладка была переведена в суспендет из-за отсутствия оперативки доступной, а в логе это стандартный запуск хрома с параметром --disable-client-side-phishing-detection ⊗ Disables the client-side phishing detection feature. Note that even if client-side phishing detection is enabled, it will only be active if the user has opted in to UMA stats and SafeBrowsing is enabled in the preferences.

UMA (User Metrics Analysis) is user metrics that are reported to help make Chrome/Chromium better. e.g. latency metrics, HTML/CSS feature usage, etc. These are the bits that are sent back to Google when you check the "Help make Google Chrome better by automatically sending usage statistics..." box on installation.

-----
RE In Progress [!] Coding Hazard [!] Stay Clear of this Cube

| Сообщение посчитали полезным:

Народ, может у кого-то завалялся экземпляр Dharma с bitlocker@foxmail.com? Я хотел бы поковырять.
На зараженной системе мальварь подчистили. Диск SSD и TRIM все уничтожил, восстановить не могу.
Пример пошифрованного файла:
./comp/AppData/Local/Microsoft/CLR_v4.0/UsageLogs/GACInstaller.exe.log.id-XXXXXXXX.[bitlocker@foxmail.com ].wiki

| Сообщение посчитали полезным:

kunix пишет:
./comp/AppData/Local/Microsoft/CLR_v4.0/UsageLogs/GACInstaller.exe.log.id-XXXXXXXX.[bitlocker@foxmail.com ].wiki
Содержательный семпл
Если по существу, то файлы шифрует в несколько потоков AES256. У каждого зашифрованного файла свой уникальный ключ+вектор. Ключ AES шифруется RSA1024.
Зашифрованный ключ + вектор (в открытом виде) лепится в конец зашифрованного файла.
При расшифровке, зашифрованный файл передается на сервер и там расшифровывается(дабы нельзя было бы перехватить приватную экспоненту), присылается обратно и перезаписывает зашифрованный файл.
Одним словом, ничего интересного

| Сообщение посчитали полезным:

Я совершенно сознательно не выкладывал файлы, чтобы не палить ID компа/файла. Там вроде у каждой версии свой отдельный email.
Короче, мне нужно точные алгоритмы восстановить. Есть чо подизасмить?

| Сообщение посчитали полезным:

А смысл? Или вы обладаете неким тайным навыком факторизации больших чисел в реальном времени?

| Сообщение посчитали полезным:

Например, есть надежда на ошибки в криптографии, генерации ключей и подобном.

| Сообщение посчитали полезным:

Если б это был некий самописный алгоритм - возможно. Но это RSA и AES, искать в которых коллизии - все равно, что железобетонную стену лбом прошибать. За такое нобелевка вполне реальна была б (если б, конечно, в свое время математик жену Нобеля не трахнул)

| Сообщение посчитали полезным:

AES бывает разный. Бывает ECB или что-то посложнее.
На RSA вообще хватает чисто математических атак.
Я прекрасно понимаю, что шанс мизерный, но я типа как обещал глянуть.

| Сообщение посчитали полезным:

kunix пишет:
AES бывает разный. Бывает ECB или что-то посложнее
Забыл уточнить, там AES256 CBC.

| Сообщение посчитали полезным:

А откуда вы это все знаете, если не секрет?
Меня не надо убеждать в бесполезности этой идеи.
Я прекрасно понимаю, что правильно реализованную крипту не взломать (хотя, RSA1024 наводит на определенные мысли, что там не все так хорошо).
Нужно либо дать семпл, либо послать подальше.

| Сообщение посчитали полезным:

kunix пишет:
А откуда вы это все знаете, если не секрет?
Я разбирал этот вирус, это была рабочая задача, и писал полный отчет по ней, за это мне ЗП платили
kunix пишет:
Меня не надо убеждать в бесполезности этой идеи.
Делать больше нечего мне, как заниматься тем, чтобы вас в чем-то убеждать...
Я просто поделился инфой и только
Это вам решать, целесообразность изучения данного вируса.
kunix пишет:
Нужно либо дать семпл, либо послать подальше.
Глянул сейчас у себя, к сожалению семпла не осталось, дело было в прошлом году. Увы)
Семпл можно поискать --> Здесь <--

| Сообщение посчитали полезным: kunix, _MBK_

kunix пишет:
RSA1024 наводит на определенные мысли, что там не все так хорошо
А что именно не так с RSA1024?

| Сообщение посчитали полезным:

Зачем использовать RSA1024 (который, маловат для 2020 года, ибо десять лет назад факторизовали 768 бит), если можно использовать RSA2048 без особой разницы в производительности?
Это означает. что разработчик вируса, вероятно, не очень щепетилен в вопросах криптографии (а не то, что я собрался щас тут факторизовать 1024 бит).

| Сообщение посчитали полезным:

kunix пишет:
Зачем использовать RSA1024
Скорость вычисления, RSA и так достаточно медленный алго, а в шифровальшиках важна скорость обработки файлов, чтобы юзер не успел опомниться.
На большом объеме шифруемых файлов будет сильно заметна скорость работы.
К тому же, RSA1024 пока не факторизовали.
А 768 бит факторизовали "искусственно" созданный модулус, со слабым RND.

| Сообщение посчитали полезным:

А по моему, это означает, что разработчик вируса просто не хочет решать меньшую задачу посредством большего. 768 бит насколько я помню, факторизовывали больше чем два года и про факторизацию более длинных ключей я чтото не слыхал.
От шифровальщика требуется в первую очередь скорость, поэтому вполне прагматично использовать более короткий ключ, факторизовывать который в домашних условиях явно никто не станет

| Сообщение посчитали полезным:

> Скорость вычисления, RSA и так достаточно медленный алго, а в шифровальшиках важна скорость обработки файлов, чтобы юзер не успел опомниться.
Дык там еще блоков AES хватает, тот тоже небыстрый. Неужели будет заметна разница RSA1024 vs. RSA2048.
Забудем про AES-NI, его может не быть в процессоре.
Плюс, шифрование RSA с публичной экспонентой должно быть относительно быстрым. Операций вычисления по модулю мало.

> А 768 бит факторизовали "искусственно" созданный модулус, со слабым RND.
Неа, там факторизовали полноценный модуль RSA из RSA Factoring Challenge. В этом и была суть вот этого всего (Number Field Sieve), а не в поиске специфичных атак.
https://www.schneier.com/blog/archives/2010/01/768-bit_number.html
https://eprint.iacr.org/2010/006.pdf

> От шифровальщика требуется в первую очередь скорость, поэтому вполне прагматично использовать более короткий ключ
Я не исключаю и этот вариант.

> про факторизацию более длинных ключей я чтото не слыхал.
В 2017 посчитали дискретный логарифм в 768-битном простом конечном поле. Но этом малость из другой оперы.
https://www.researchgate.net/publication/315859095_Computation_of_a_768-Bit_Prime_Field_Discrete_Logarithm

| Сообщение посчитали полезным:

kunix пишет:
https://www.schneier.com/blog/archives/2010/01/768-bit_number.html

The number RSA-768 was taken from the now obsolete RSA Challenge list as a representative 768-bit RSA modulus. This result is a record for factoring general integers. Factoring a 1024-bit RSA modulus would be about a thousand times harder

| Сообщение посчитали полезным:

> Factoring a 1024-bit RSA modulus would be about a thousand times harder
Ага, все зашибись, но с тех пор и компы стали мощнее, и Number Field Sieve уже другой.
Ну короче, мало смысла 1024 бита использовать.

> This result is a record for factoring general integers.
Ну то есть, факторизовали модуль общего вида, без специфических уязвимостей. Как я и сказал.

| Сообщение посчитали полезным:

kunix пишет:
Дык там еще блоков AES хватает, тот тоже небыстрый.
Откровение) AES используют для сквозного (на лету) шифрования, в том числе и в программах шифрования разделов жестких дисков, в том числе и системного, из-за скорости работы в первую очередь.
Плюс, из-за скорости, используют в сессионном шифровании web пакетов.
Так что в случае с вирусом-шифровальщиком использование AES вполне оправданно.
kunix пишет:
Ага, все зашибись, но с тех пор и компы стали мощнее, и Number Field Sieve уже другой.
Ну короче, мало смысла 1024 бита использовать.
Не подскажите софт для факторизации, с битностью начиная от 768?
Связка Msieve+ggnfs у меня лично падает

| Сообщение посчитали полезным:

Я например "obsolete RSA Challenge list" перевел именно как лист уязвимых скомпрометированных ключей
kunix пишет:
Number Field Sieve уже другой.
Ну да и второй закон термодинамики уже не торт
Вывод у них совершенно футуристический - примерно как прогноз на начало двадцатого века улиц Парижа, на несколько метров заполненных конским дерьмом, учитывая перспективы роста конного транспорта

| Сообщение посчитали полезным:

> Откровение) AES используют для сквозного (на лету) шифрования
Ну давайте уже посчитаем, чо.
Вот берем бенчмарк https://bearssl.org/speed.html
RSA 2048-bit public 4513.53 операций в секунду.
AES-256 CBC encrypt 125.27 мегабайт в секунду.
Итого, скорость шифрования файла AES-256 CBC станет сравнима со скоростью шифрования AES-ключа при помощи RSA2048 уже на файлах размером 125 мегабайт/4513 ~ 27 килобайт.
Поэтому я говорю, что в среднем будет доминировать время вычисления AES или даже запись на диск, а не RSA.
Кстати, у меня вопрос - зачем AES256, если есть чуть более быстрый AES128?

> Не подскажите софт для факторизации, с битностью начиная от 768?
Если это не стеб, то самое практичное вроде бы вот это
http://cado-nfs.gforge.inria.fr/

> Я например "obsolete RSA Challenge list" перевел именно как лист уязвимых скомпрометированных ключей
Вы неправильно поняли. Ключи полноценные и сильные (для своей битности), просто конторка RSA уже не выплачивает бабло за факторизацию.

> Ну да и второй закон термодинамики уже не торт
И причем тут ваш сарказм? Алгоритмы Number Field Sieve за 10 лет ушли далеко вперед.
Я с большим трудом понимал старый добрый GNFS, а эти новые фокусы типа Function Field Sieve вообще не понимаю.

> Вывод у них совершенно футуристический
Они серьезные криптографы. Делать параноидальные выводы - их работа.

| Сообщение посчитали полезным:

kunix пишет:

Я с большим трудом понимал старый добрый GNFS, а эти новые фокусы типа Function Field Sieve вообще не понимаю.
Вы, вероятно, путаете сам алгоритм и его реализацию. Но, тем не менее

kunix пишет:
Если это не стеб, то самое практичное вроде бы вот это
http://cado-nfs.gforge.inria.fr/
Вы сами при помощи этого хоть один 1024битный ключ факторизовали или лотя бы 768битный?
kunix пишет:
Они серьезные криптографы. Делать параноидальные выводы - их работа.
Вообще то студенты. И не сбылись их прогнозы - в новом прекрасном мире даже за десять лет не слышно о факторизации 1024. Да я уже говорил про цену подобным прогнозам, например, один советский вождь нам к 1980 году коммунизм обещал, а вместо него олимпиаду провели

| Сообщение посчитали полезным:

kunix пишет:
Вот берем бенчмарк https://bearssl.org/speed.html
RSA 2048-bit public 4513.53 операций в секунду.
AES-256 CBC encrypt 125.27 мегабайт в секунду.
Так..так..
Ну давайте не будем лукавить и разберемся.
В нашем случае (вируса-шифровальщика) мы имеем 32битную реализацию.
А значит нам подходит из приведенных данных, на данном ресурсе:
AES-256 CBC encrypt (x86ni) ~ 488 MB/s (данные для х64 и х86 разница в сотых)
RSA private (i15) 47.10 (i386 (ops/s)) (почему я указываю private? в нашем случае процесс шифрования использет паблик экспаненту. так что private == encrypt)
И еще, в случае с AES и с RSA используются разные единицы измерения, так что сравнивать мегабайты в секунду и операции в секунду не корректно.
И в нашем случае RSA1024 а не 2048, т.е. данные для вычислений в 2 раза меньше.
Я утрирую конечно, но вы пытаетесь сравнить возведение в степень по модулю с банальным перексором
kunix пишет:
стати, у меня вопрос - зачем AES256, если есть чуть более быстрый AES128?
Этот вопрос к разработчику вируса надо адресовать

| Сообщение посчитали полезным:

> Вы, вероятно, путаете сам алгоритм и его реализацию. Но, тем не менее
Я имею ввиду вполне конкретную версию General Number Field Sieve, которую описывает статья https://core.ac.uk/download/pdf/15590206.pdf

> Вы сами при помощи этого хоть один 1024битный ключ факторизовали или лотя бы 768битный?
Не факторизовал, но из этого не следует, что не факторизует кто-то другой с помощью более совершенных алгоритмов. В этом суть параноидальности криптографии.

> Вообще то студенты.
Thorsten Kleinjung, Emmanuel Thomé, Paul Zimmermann - это для вас студенты?

Короче, прекращайте тут хамить.

Добавлено спустя 12 минут
> AES-256 CBC encrypt (x86ni) ~ 488 MB/s (данные для х64 и х86 разница в сотых)
Вы взяли AES-NI. Мы вроде договаривались его не брать, т.к. он может быть недоступен.

> RSA private (i15) 47.10 (i386 (ops/s)) (почему я указываю private? в нашем случае процесс шифрования использет паблик экспаненту. так что private == encrypt)
Это бред, сорри. Вирусу нужно зашифровать случайный ключ AES с публичной эккспонентой, чтобы его можно было расшифровать только зная приватную экспоненту (=приватный ключ).
Соответственно, вирус считает C=M^e (mod N), где e=0x10001. Это и есть RSA public, т.к. e маленькое и всем известное.
Эта операция может называться как encrypt, если мы шифруем сообщение, так и decrypt, если мы проверяем цифровую подпись. Разница только в используемом паддинге.
Ну суть остается одной и той же, C=M^e (mod N), где e=0x10001.

> И еще, в случае с AES и с RSA используются разные единицы измерения, так что сравнивать мегабайты в секунду и операции в секунду не корректно.
Я посчитал такой объем файла, чтобы время его шифрования AES-ом равнялось времени шифрования одного блока RSA. Могу я это сделать? Могу.
На файлах большего объема время шифрования AES будет доминировать, а время работы RSA будет, грубо говоря, незначительным.

> И в нашем случае RSA1024 а не 2048, т.е. данные для вычислений в 2 раза меньше.
Отлично. Разница в два раз - 54 килобайта. Мы все равно считаем порядок величины, а не точное значение.

> Этот вопрос к разработчику вируса надо адресовать
Вот вот. Является ли разрабочик вируса таким уж докой в оптимизации?

| Сообщение посчитали полезным:

kunix пишет:
Я имею ввиду вполне конкретную версию General Number Field Sieve, которую описывает статья https://core.ac.uk/download/pdf/15590206.pdf
Это какого года статья? Вы мне покажите некое принципиально новое усовершенствование классического алгоритма решета начиная с прошлого десятилетия?

kunix пишет:
Короче, прекращайте тут хамить.
Здрасти-приехали, плесните в меня стаканом виртуального сока еще
kunix пишет:
Вот вот. Является ли разрабочик вируса таким уж докой в оптимизации?
Ему и не надо. Он просто прикинул приемлемое время необходимое для шифрования и соответственно алгоритм подобрал. А вы какие то выводы относительно его профессионализма делаете на основании этого. Не он выдумывал эти алгоритмы, за него это умные дяди сделали, они и криптоустойчивость оценили

| Сообщение посчитали полезным: