Узнал тут, что оказывается есть конторы, которые файлы XTBL после вирусной атаки типа расшифровывают. У них даже «гарантии» с синей печатью есть — свидетельства о регистрации в ЕГРЮЛ труЪ-ынтырпрайзной конторы ООО «Рога и Копыта» =).
Это возможно в двух случаях — либо они действуют как посредники, оказывая по сути тех-поддержку в процессе общения с вымогателями, либо сами как-то в доле, участвовали в разработке или связаны с разработчиками исходного трояна. В любом случае, халявы не ожидается.
Третий вариант — что они взломали стойкое асимметричное крипто — отметаем как слишком уже невероятный. Сервисная контора год от роду, ничем не примечательная, примусы починяющая да ноутбуки от пыли продувающая — и сразу с величайшим математическим открытием в духе Перельмана с Рамануджаном ? Не смешите мои тапочки.
Вирусне такого типа (со стойкой криптографией) уже год. Не ждите универсального расшифровщика — он может появиться только при невероятном стечении обстоятельств! Для этого:
а) должны поймать мошенников (применение тора и биткойна этому не способствует)
б) На момент их предполагаемого ареста должны быть целы мастер-ключи (но отнюдь не обязаны!!).
в) Либо в мире родится совершенно невероятно гениальный математик, чьё имя запишут рядом с Пифагором.
Пишите бэкапы, господа. На DVD/BD-R и прочие носители однократной записи. Фотки из отпуска стоят для вас явно дороже, чем 10-20 или даже 200 рублей за болванку. Админам — не спать!! На антивирусы не надеяться, только эшелонированные бэкапы могут спасти ваши данные!
Из нового: вирусы-шифровальщики такого типа не только научились убивать точки восстановления, но и при наличии доступа сеять хаос и разрушения в облачных хранилищах — есть случаи разрушения данных на Яндекс-Диске и в уязвимых NAS от Synology.
Для PGP, RSA и ECDSA способов взлома может не появиться ВООБЩЕ. Совсем. Грубой силой это тоже не ломается, никакой закон Мура и прогресс в микроэлектронике длину шифров не передавят, так что никакой брутфорс на суперкомпьютере тут тоже не светит. А прорывные открытия в математике (в частности, в теории чисел) могут в этом тысячелетии и не случиться.
Всех призываю К ПРАВИЛЬНЫМ БЭКАПАМ.
P.S. немного тегов для роботов:
xtbl как расшифровать
xtbl дешифратор скачать без смс 😀 😀
ctb locker как расшифровать
ctb locker дешифратор скачать без смс 😀 😀
Amin 's Blog 
Многотерабайтовую базу не очень-то и запишешь на болваночки)))
blueray даже 100 гигов — не напасёшься. даже 400 гиговые — надо много бабла.
Даже в моей конторе, где всего терабайт постгреса блюреем писать — плохо.
Лучше жестаки покупать.
У моего другана стелаж с архивами жёсткие диски в металлических футлярах.
У меня дома вариант такой — все критичные данные пишутся копиями на raid1,
сетевой диск включается только в момент записи. запись происходит только новых
данных,старые не перезаписываются.
Такие крупные базы обычно напрямую недоступны пользователям для деструктивных действий, и на этих масштабах уже другие решения. Те же ленточные стриммеры или СХД-шки разной степени энтерпрайзнутости.
Терабайт — это очень и очень много, тем более для базы данных. Обслуживание такой системы — требует весьма специфичных навыков, и добраться до них шифровальщику трудно.
Что касается бэкапов — важно, какая сторона инициирует копирование и как поделён доступ.
Угадаламана, нащальнике!
Мине попрыгаманать прищлос и с бубном
танцевать- баальшой баз.
На самом деле — большие сейчас — от 10 теров и выше.
И петабайты попадаются, в астрономии, например.
Лично я не видел, но может если буду на pgconf — пообщаюсь с
людьми, которые видели.
Тут ещё от нагрузки зависит и от характера задач.
Самая «плохая» ситуёвина — когда нагрузка смешанная,
в моём случае 60% запись однократная и потом
последующее считывание с выносом устаревших данных
на медленный сервак.
Ещё 30% данных это всякие справочники. Они не меняются,
их получается даже на упорядочивать по ключам.
И оставшиеся — как раз конкурентная нагрузка.
По моей практике — самые дубовые и простые решения — самые безотказные.
ЗЫ
Вообще, стоит следить за новостями о postgres — будет интересно.
По моим прогнозам, по функциональным возможностям и быстродействию
oracle отстанет. Он уже сдаёт, и за 1-2 года им надо будет сильно напрячься,
чтоб не разделить судьбу Novell NetWare.
Хорошо бы эти копирасты разорились вообще.
Компании, ворочающие петабайтными базами на постгресе, шифровальщиков обычно не боятся. Напрямую такие БД недоступны для деструктивных действий, для ценных баз есть бэкапы, а файлос всякий мелкий и пакостный должен лежать на самба-сервере и бэкапиться ещё чаще.
Что касается всяких крутых возможностей БД — мало кто использует.
Подавляющее большинство систем — тупо реляционное хранилище. Хорошо, если с построенными по-уму индексами, а не как в 1С. Иногда используются вьюхи / хранимки и всякие местечнковые расширения SQL (например, крутейший LIMIT в MySQL, аналог которого в M$SQL делался каким-то очень зело ректальным способом).
До умного использования транзакций начинают доходить только в достаточно важных системах, и то далеко не всегда, хотя казалось бы… (говнобиллинги и сервера телефонии за десятки килобаксов, шлю вам привет с лучами ненависти)
Полноценно использовать всю мощь расширений SQL от конкретной СУБД получается у ничтожной доли софта. Да, очень мощно, надёжно и при наличии прямых рук и толкового DBA в штате — очень неплохо по производительности Расплата за это — жесточайший вендор-лок с анальным порабощением подписавшихся.
А оракел хоронить не надо — у них отличная СУБД, да и виртуалбокс они отлично развивают.
А напрячься в условиях жестокой конкуренции с опен-сурсным софтом придется адски — и тут целая куча факторов играет против проприетарного софта.
[…] — «как расшифровать XTBL». Это пиздец. Я написал заметку про XTBL в начале лета, а тема до сих пор не остыла. Похоже, […]
[…] Данный зверь, в отличие от крутейшего VAULT-а, брутального XTBL и няшного CTB-Locker-а, смотрится гораздо более убогой […]