Популярный среди разработчиков софта протектор Enigma предлагает несколько вариантов защиты приложений. Один из них — установить пробный режим с ограничением на количество запусков, дней использования или рабочего времени. Кажется, преодолеть такую защиту непросто. Оказывается, очень просто!
Еще по теме: Удаленная отладка вредоносных программ
Может показаться, что взлом защиты Enigma представляет собой какое‑то архисложное действие, доступное лишь избранным специалистам, обладающими навыками работы с отладчиками и вооруженными специальными инструментами. Правильно показалось, но есть слабые места, которыми пользуются многочисленные сетевые авторы обучающих видео и «однокликовых утилит». Сегодня мы рассмотрим одно из таких слабых мест защиты Enigma — триальный режим.
Вся информация предоставлена исключительно в ознакомительных целях. Ни редакция, ни автор не несут ответственности за любой возможный вред, причиненный материалами данной статьи.
Очень часто перед покупкой разработчики дают пользователю возможность поиграть с программой ограниченное время или определенное число запусков, чтобы он оценил все возможности софтины. И конечно же, защита Enigma имеет в своем джентльменском наборе такую фичу. Ленивые разработчики могут создавать триальные версии своих программ фактически нажатием одной кнопки. Однако такое доверие Enigma Protector может оказаться неоправданным, и сейчас я расскажу почему.
Для понимания процесса скачаем с официального сайта последнюю демоверсию защиты, благо они ее свободно раздают. Запустив программу, мы увидим в меню Settings вкладку Trial Control. Здесь находятся нужные нам разделы:
- Limitation by Executions Count (ограничение на количество запусков)
- Limitation by Days Count (ограничение на количество дней)
- Limitation of Execution Time (ограничение на количество программного времени)
- Time Control (проверка мухлежа с переводом времени)
Особенности этих режимов заключаются в том, что при первом запуске программа «привязывается» к текущему моменту и ведет отсчет своей работы именно от него. Технология сброса подобного триала заключается в том, чтобы вернуть систему в состояние, предшествующее запуску, после чего программа будет стартовать как будто в первый раз после установки. Например, с режимом Limitation from Date till Date (ограничение на запуск в конкретный временной отрезок) такой номер не пройдет, поскольку приложение уже не привязано к моменту первого запуска.
Защита проверяет лишь текущее системное время, независимо от того, запускалась программа до этого на данном компьютере или нет. Хотя, конечно, можно обмануть и этот метод защиты, сбросив триал (чтобы исключить запоминание текущего времени с целью обмануть Time Control, если этот режим также включен) и переведя часы на нужный временной интервал.
Однако хватит лирических отступлений, пора браться за дело! Давайте защитим любое приложение, ограничив количество его запусков, а потом взломаем эту защиту. По счастью, разработчики Enigma и здесь пошли нам навстречу, бесплатно предоставив такую возможность в демоверсии своего протектора. Для этого открываем вкладку Limitation by Executions Count, устанавливаем верхний чекбокс и в окошке Maximum count of executions указываем нужное количество запусков (скажем, три).
Теперь соберем защищенную версию программы, которая при каждом старте будет показывать пятисекундное окошко рекламы Enigma (что поделать, за халяву приходится платить) и считать запуски. Через три запуска вместо программы вы увидите сообщение о превышении лимита, означающее, что халява закончилась.
Для начала попробуем пойти самым тернистым путем — попытаемся снять защиту совсем. Программа, защищенная Enigma версии старше 4, просто не дампится. Вернее, дампится, но на выходе получается только слепок кода реализации защиты, который нам не сильно нужен. Попробуем разобраться, как сдампить программу руками, благо незащищенная версия у нас есть. Открыв исходную программу, мы увидим в ней 12 секций:
1 2 3 4 5 6 7 8 9 10 11 12 13 |
Name VirtSize RVA PhysSize Offset Flag .text 00E8CEBC 00001000 00E8D000 00001000 60D00060 .data 000103F8 00E8E000 00010400 00E8E000 C0700040 .rdata 003C0A80 00E9F000 003C0C00 00E9E400 40600040 .qtmetad 00000620 01260000 00000800 0125F000 40600040 .eh_fram 002B5648 01261000 002B5800 0125F800 40300040 .bss 00003AC0 01517000 00000000 00000000 C0600080 .edata 00000E04 0151B000 00001000 01515000 40300040 .idata 000055C4 0151C000 00005600 01516000 C0300040 .CRT 00000038 01522000 00000200 0151B600 C0300040 .tls 00000008 01523000 00000200 0151B800 C0300040 .rsrc 000428B0 01524000 000428B0 0151BA00 C0300040 .reloc 00062CFC 01567000 00062E00 0155E400 42300040 |
В защищенной программе эти секции тоже присутствуют, правда без названий, флагов и в зашифрованном виде:
1 2 3 4 5 6 7 8 9 10 11 12 |
1 00E8D000 00001000 0061CC00 00000600 E0000040 2 00011000 00E8E000 00001A00 0061D200 E0000040 3 003C1000 00E9F000 001E8E00 0061EC00 E0000040 4 00001000 01260000 00000200 00807A00 E0000040 5 002B6000 01261000 000BFA00 00807C00 E0000040 6 00004000 01517000 00000000 00000000 C0600080 7 00001000 0151B000 00000000 008C7600 E0000040 8 00006000 0151C000 00000800 008C7600 E0000040 9 00001000 01522000 00000200 008C7E00 E0000040 10 00001000 01523000 00000000 008C8000 E0000040 11 00043000 01524000 00000000 008C8000 E0000040 12 00063000 01567000 00000000 008C8000 E0000040 |
То, что они зашифрованы, — еще полбеды, поскольку по мере загрузки секции расшифровываются: в этом мы можем убедиться, «всплыв» отладчиком во время работы уже загруженной программы. Однако здесь нас ожидает неприятный сюрприз — жизненно необходимые нам секции импорта и экспорта (в нашем примере .<wbr />edata и .<wbr />idаta) заполнены нулями. Зловредная Enigma очищает их после загрузки приложения в память, чтобы осложнить нам жизнь. В принципе, таблица экспорта у нас есть, но импорт, оригинальные названия и флаги секций отсутствуют, не говоря уже о точке входа в приложение.
Как ни крути, а придется лезть в виртуальную машину. Заодно посмотрим, как она выглядит в 32-битной версии (в прошлой статье была описана 64-битная реализация). Уже при попытке сдампить приложение мы с огорчением обнаружим, что при данном способе защиты из нее уже не торчат уши интерпретатора в виде экспортируемых символов, — интерпретатор придется искать самим. Загрузив программу в отладчик (не забываем о ScyllaHide) и тупо запустив, с ходу спотыкаемся о первую попытку исключения на одной из двух рогаток:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 |
01AF05A5 div eax ; <---------------------- Деление на ноль 01AF05A7 call 1B04618 01AF05AC xor eax,eax 01AF05AE pop edx 01AF05AF pop ecx 01AF05B0 pop ecx 01AF05B1 mov dword ptr fs:[eax],edx 01AF05B4 jmp 1AF05EB 01AF05B6 jmp 1A108B4 01AF05BB call 1A10C1C 01AF05C0 jmp 1AF05EB 01AF05C2 xor eax,eax 01AF05C4 push ebp 01AF05C5 push 1AF05E1 01AF05CA push dword ptr fs:[eax] 01AF05CD mov dword ptr fs:[eax],esp 01AF05D0 ud2 ; <----------------------------- Недопустимая инструкция 01AF05D2 call 1B04618 01AF05D7 xor eax,eax 01AF05D9 pop edx 01AF05DA pop ecx 01AF05DB pop ecx 01AF05DC mov dword ptr fs:[eax],edx 01AF05DF jmp 1AF05EB |
Игнорируем их: они нам не мешают, даже наоборот. Ибо, провалившись в следующий за ними вызов, в паре шагов мы обнаруживаем знакомую нам по предыдущей статье связку
1 2 |
push 7E7D14B3 jmp.1B91420 |
Мы нашли адрес 32-битного интерпретатора шитого кода 32-битной виртуальной машины, аналогичной той, что я описал в предыдущей статье. Здесь он выглядит вот так:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
pushad pushfd mov dl,1 mov esi,0 lea edi,dword ptr ds:[esi+1B937E4] lea edi,dword ptr ds:[edi] mov ecx,1 xor eax,eax lock cmpxchg dword ptr ds:[edi],ecx je 1B9144D cmp dl,byte ptr ds:[1B937E0] je 1B91422 inc dl add esi,64 jmp 1B91429 lea eax,dword ptr ds:[esi+1B937E4] lea eax,dword ptr ds:[eax+10] mov ecx,dword ptr ss:[esp] ... |
Далее, с использованием уже знакомого нам способа, ставим на него условную точку останова с печатью в лог {<wbr />RAX} {[<wbr />RSP]<wbr />}. Нам предстоит анализировать логи и искать развилки в виртуальном коде на предмет экспирации триала или наличия уже расшифрованной, но еще не обнуленной секции импорта.
Процесс непростой, и осложняется он еще и тем, что актуальная Enigma, как и любая взрослая виртуализированная защита, вдобавок профилирует время работы отдельных участков виртуального кода. То есть нельзя просто так взять и включить логирование с самого начала первого запуска виртуальной машины и получить полный листинг ее вызовов до загрузки приложения.
В этом случае в определенный момент защита обнаружит наличие точки останова и выкинет ошибку Internal <wbr />Protection <wbr />Error, <wbr />please <wbr />contact <wbr />to <wbr />author!. Поэтому надо отслеживать в виртуальном коде критические точки таких проверок и аккуратно обходить их. Возможно, я когда‑нибудь расскажу и об этом. Но в начале статьи я, кажется, обещал раскрыть простой способ?
Вы будете смеяться, но, чтобы заставить программу заработать вновь, нам не понадобится даже отладчик. Что нам потребуется, так это Process Monitor (ProcMon можно бесплатно скачать с сайта Microsoft) и встроенный редактор реестра RegEdit.
Чтобы отследить, куда Enigma прячет свои данные, запускаем ProcMon в момент старта защищенной программы на компьютере. Если мы предусмотрительные, то делаем это при первом запуске, если нет и мы проморгали этот трогательный момент — тоже не беда. ProcMon, по своему обыкновению, вываливает огромнейший список всевозможных системных вызовов, непрерывно удлиняющийся с каждой секундой, и, кажется, разобраться в нем нет никакой возможности. Не спасает даже то, что, притормозив программу, мы ставим фильтр на обращения к реестру и файловой системе исключительно от нашего приложения.
Но если мы выполним в этом списке поиск по слову Enigma, произойдет чудо! Пошуршав несколько секунд байтами, Process Monitor находит ближе к середине списка обращение к ветке реестра:
1 |
HKCU\Software\Enigma Protector\29AEB4A0365755F6-B862CAE984EA4D0E\02F01F553A112DCE-00C9DB38C18D5FD1 |
Причем при первом запуске нашей программы ветка создается, а при повторных — читается. Не веря своим глазам (неужели все так просто?), открываем редактор реестра и аккуратно выпиливаем данную ветку (в каталоге Enigma <wbr />Protector может оказаться много подобных веток для других программ, тоже защищенных «Энигмой», их мы не трогаем).
Перезапускаем программу, и тут нас подстерегает облом — снова сообщение о истекшем количестве запусков. Лезем в реестр: убитая ветка опять на своем месте. Что ж, снова убиваем, ее запускаем ProcMon и программу — ага, пытается обратиться к убитой ветке, обламывается, и сразу вслед за этим происходит обращение к файлу C:\<wbr />Users\<wbr />Username\<wbr />AppData\<wbr />Local\<wbr />Temp\<wbr />80EB2F5C. Странный файл, расположенный во временном каталоге, размер 14 байт.
Пробуем удалить его вместе с веткой, и — бинго! Триал‑версия софтины, как ни в чем не бывало, запускается и прекрасно работает. Поэкспериментировав с разными триалами на разных программах, мы видим, что, несмотря на свою дубовость, способ получился универсальным. Хотя названия ветки реестра и файла Enigma генерирует все время новые, для каждой программы они одни и те же. То есть достаточно первый раз их определить, и можно смело в пакетном режиме убивать их перед запуском защищенной программы. Трудно поверить, но надо признаться, что все довольно просто.
Выводы из всего описанного здесь напрашиваются элементарные: даже очень популярный и навороченный инструмент защиты исполняемых файлов может использовать довольно примитивные методы работы. Которые запросто можно сломать при помощи лома и кувалды парочки бесплатных утилит и природной смекалки.
Еще по теме: Отладка программ с помощью WinDbg