Доброго здравия! Не удивлюсь, что Вы раньше даже не слышали об этой программе. Как и я, до того дня, когда мне пригодился Python Debugger. Да, знаю, есть pdb, но его функционал и то, как он представлен, мне совершенно не приглянулось. После непродолжительных поисков я наткнулся на этот замечательный продукт. Тут есть все, что может пригодиться в отладке ваших Python приложений (скажу сразу: данный язык я не изучал, поэтому, если какие-то неточности всплывут, просьба не ругаться).
Предостережение: повторяя действия из статьи, вы действуете на свой страх и риск!
Итак, мы начинаем...
Пациент, сразу скажу, необычный. Во-первых: он поставляется с исходниками (!!!), пускай и в байт-коде; во-вторых, как это иногда бывает… в общем, увидите.
Первым делом, качаем программу (Wing IDE Professional v 5.1.4). Устанавливаем, осматриваем папку. Главный исполняемый файл находится по адресу ./bin/wing.exe. Запустим его. Ругается на отсутствие Python, поэтому установим и его. Нужен версии 2 (на данный момент это версия 2.7.9). Снова запускаем программу. На этот раз предлагает установить патчи, и перезапуститься. Так и сделаем.
Теперь вылезает окошко с запросом лицензии (т.к. у нас про-версия). Введем какую-нибудь ерунду:
Получаем следующий ответ:
Что забавно: программа нам сама говорит длину ключа (20, не учитывая дефисов), и символы, с которых он должен начинаться. В принципе, с этого уже можно и начать исследовать защиту — найдем эту строчку в файлах программы.
Дальше — интереснее. Результат поиска нашелся в файле ./bin/2.7/src.zip!
Да-да. Все действительно так: программа идет с исходниками. В них-то нам и придется копаться.
Этап два: роемся в исходниках
Включим в Total Commander поиск по архивам, и найдем ту строку снова. Строка лежит в файле: ./bin/2.7/http://ift.tt/1HCotDm. PYO-файлы представляют из себя бинарники с "оптимизированным" байт-кодом Python.
К нашему счастью, для Питона существует парочка декомпиляторов байт-кода. Чтобы не утруждать Вас поисками, дам ссылки на те, которые мне пригодились:
- Easy Python Decompiler (EPD) — оболочка, в которой зашиты два декомпилятора (Uncompyle2 и Decompyle++);
- Форк Uncompyle2 — иногда распаковывает то, что не могут распаковать другие.
Итак, распакуем весь архив src.zip в папку src (рядом уже есть папка src, пускай туда распаковывается и все остальное) и натравим на нее EPD:
Дожидаемся окончания процесса, и идем осматривать что получилось. А получились на выходе декомпилированные файлы с окончанием _dis. Их мы переименуем в .py. Все бы хорошо, но, выясняется, что имеются также файлы с окончанием _dis_failed, что говорит о том, что эти файлы декомпилятор не осилил. К счастью, файл только один: edit/editor.pyo_dis_failed
Попробуем на него натравить Decompyle++… Та же беда. Не зря я дал ссылку на запасной декомпилятор, т.к. именно он и сделал то, что не удалось другим. Теперь удалим все pyo/pyc файлы из папки src, а .py*_dis переименуем в .py.
Далее повторим все вышеописанное для архива opensource.zip, распаковав его в соседнюю одноименную папку. Архив external.zip я решил не трогать, т.к., осмотрев его, можно увидеть, что там лежат библиотеки, которые можно установить отдельно для нашего Питона. Так и сделаем:
-
pip install docutils
- py2pdf — его положим в папку external;
- Imaging-1.1.7 — запустить и установить. Из папки external можно удалить;
- pygtk — то же, что и с предыдущим файлов.
Остальные библиотеки (pyscintilla2 и pysqlite) просто извлечем из архива external.zip, и декомпилируем, как и раньше.
Этапы три и четыре: собственно исходный код. Отладка.
Порыскав по питоновским скриптам, я наткнулся на файлик wing.py в корне папки с программой. И, первый же коментарий нам подсказывает:
# Top level script for invoking Wing IDE. If --use-src is specified
# as an arg, then the files in WINGHOME/src, WINGHOME/external,
# WINGHOME/opensource will be used; otherwise, the files in the version
# specific bin directory will be used if it exists.
В двух словах: если скрипту дать параметр --use-src, то при запуске будут использоваться исходники из папок src, external, opensource корневого каталога с Wing IDE (а не со скриптом).
Заглянув в корневую папку, я обнаружил еще одну папку src, и .py-файлы в ней. Подкинем их в нашу папку src, с перезаписью (здесь все таки оригиналы, а не декомпилированные файлы).
Теперь все три папки (указанные чуть выше), скопируем в корневой каталог программы. Попробуем подебажить…
Запускаем Wing IDE, и открываем в ней файл wing.py из каталога bin. Далее в меню Debug -> Debug Environment... в поле параметров указываем --use-src. Теперь стартанем дебаггер (клавиша F5). Если все махинации с копированиями папок прошли успешно, мы получим вторую копию запущенной Wing IDE. Прекрасно!
Далее: откроем в родительском Wing IDE тот файлик, в котором мы нашли ранее строку о плохом license id (wingctl.py), и поставим бряку до этого сообщения:
В отлаживаемом Wing IDE зайдем в меню Help -> Enter License..., и введем ключик согласно правилам (помните?: 20 символов, при том, первый из набора ['T', 'N', 'E', 'C', '1', '3', '6']):
Жмем Continue и попадаем на бабки бряку. Первая же интересная функция: abstract.ValidateAndNormalizeLicenseID(id). Зайдем в нее по F7. Там еще одна: __ValidateAndNormalize(id). Зайдем и в нее.
Первая проверка на валидность:
for c in code:
if c in ('-', ' ', '\t'):
pass
elif c not in textutils.BASE30:
code2 += c
badchars.add(c)
else:
code2 += c
Видим, что от нас требуют, чтобы символы License ID принадлежали набору textutils.BASE30:
BASE30 = '123456789ABCDEFGHJKLMNPQRTVWXY'
Вроде других проверок в __ValidateAndNormalize(id) нет. Исправляем введенный нами идентификатор и повторяем снова. Проверку на первый символ мы уже прошли:
if len(id2) > 0 and id2[0] not in kLicenseUseCodes:
errs.append(_('Invalid first character: Should be one of %s') % str(kLicenseUseCodes))
А вот и второй символ:
if len(id2) > 1 and id2[1] != kLicenseProdCode:
kLicenseProdCodes = {config.kProd101: '1',
config.kProdPersonal: 'L',
config.kProdProfessional: 'N',
config.kProdEnterprise: 'E'}
kLicenseProdCode = kLicenseProdCodes[config.kProductCode]
Т.к. у нас Professional версия, то второй символ должен быть N — исправляем, и возвращаемся. abstract.ValidateAndNormalizeLicenseID(id) прошелся без ошибок. Прекрасно. Упс:
if len(errs) == 0 and id[0] == 'T':
errs.append(_('You cannot enter a trial license id here'))
Фиксим (я выбрал E), и продолжаем. Пробежавшись глазами ниже по коду, ничего дополнительно к предыдущим проверкам я не обнаружил, поэтому смело отпустил отладку далее по F5. Новое окно:
Вводим случайный текст, получаем сообщение об ошибке (опять 20 символов, и начинаться код активации должен с AXX), находим его в файлах, ставим бряку:
Первая функция проверки: abstract.ValidateAndNormalizeActivation(act). В ней снова проверка на принадлежность BASE30. Проверка на префикс, которую мы уже прошли:
if id2[:3] != kActivationPrefix:
errs.append(_("Invalid prefix: Should be '%s'") % kActivationPrefix)
Следующее интересное место:
err, info = self.fLicMgr._ValidateLicenseDict(lic2, None)
if err == abstract.kLicenseOK:
Заходим в self.fLicMgr._ValidateLicenseDict. Тут формируется хэш от лицензии:
lichash = CreateActivationRequest(lic)
act30 = lic['activation']
if lichash[2] not in 'X34':
hasher = sha.new()
hasher.update(lichash)
hasher.update(lic['license'])
digest = hasher.hexdigest().upper()
lichash = lichash[:3] + textutils.SHAToBase30(digest)
errs, lichash = ValidateAndNormalizeRequest(lichash)
Если посмотреть на содержимое lichash после выполнения этого блока, можно заметить, что текст ее похож на request code, отображаемый в окошке ввода кода активации, хотя несколько цифр и отличается. Ладно, будем думать, что здесь имеют место быть какие-то рандомные части, не влияющие на активацию (что, кстати, далее подтвердится!).
Далее из кода активации отрезают три первых символа, убирают дефисы, преобразовывают в BASE16, и дополняют нулями, если нужно:
act = act30.replace('-', '')[3:]
hexact = textutils.BaseConvert(act, textutils.BASE30, textutils.BASE16)
while len(hexact) < 20:
hexact = '0' + hexact
И вот оно, самое интересное:
valid = control.validate(lichash, lic['os'], lic['version'][:lic['version'].find('.')], hexact)
Какой-то control вызывает функцию validate, передавая ему lichash (request code), имя операционной системы, для которой делается ключ, версию программы, и преобразованный код активации. Почему я остановил на этом месте внимание? Дело в том, что этот control — это pyd-файл (в чем можно убедиться, добавив имя объекта в watch, и глянув поле __file__), которые представляют из себя обычные DLL с одной экспортируемой функцией (не validate), которая дает Питону информацию о том, что она умеет делать. Ну что же, давайте посмотрим на нее со стороны декомпилятора Hex Rays…
Этап пять: это уже не Python
Затащим в IDA Pro наш control (ctlutil.pyd) и посмотрим на экспортируемую функцию initctlutil:
int initctlutil()
{
return Py_InitModule4(aCtlutil, &off_10003094, 0, 0, 1013);
}
off_10003094 представляет из себя структуру, в которой указаны имена и адрес экспортируемых методов. Вот и наш validate:
.data:100030A4 dd offset aValidate ; "validate"
.data:100030A8 dd offset sub_10001410
Из всего кода, который содержит процедура sub_10001410 самым интересным выглядит этот:
if ( sub_10001020(v6, &v9) || strcmp(&v9, v7) )
{
result = PyInt_FromLong(0);
}
Зайдем и в sub_10001020 тоже. Интересно было бы не на глаз давать имена переменным, а подебажить и обозвать их как следует. Так и сделаем. Настроим отладчик IDA Pro:
Думаю, все понятно из скриншота: мы указали приложение, которое в итоге будет подгружать наш pyd-файл.
Теперь ставим бряк на начало sub_10001020, и начинаем заглядывать в переменные и входные параметры. После непродолжительного процесса отладки приходим к такому вот листингу функции:
int __usercall convert_reqest_key@<eax>(char *version@<eax>, const char *platform@<ecx>, const char *activation_key, char *out_key)
{
unsigned int len_1; // edi@1
const char *platform_; // esi@1
char *version_; // ebx@1
int ver_; // eax@2
signed int mul1; // ecx@3
signed int mul2; // esi@3
signed int mul3; // ebp@3
bool v11; // zf@15
const char *act_key_ptr; // eax@31
char v13; // dl@32
const char *act_key_ptr_1; // eax@35
unsigned int len_2; // ecx@35
char v16; // dl@36
const char *act_key_ptr_2; // eax@39
unsigned int len_3; // ecx@39
char v19; // dl@40
int P3_; // ebx@42
const char *act_key_ptr_3; // eax@45
unsigned int len_4; // ecx@45
char v23; // dl@46
unsigned int P4; // ebp@47
signed int mul4; // [sp+10h] [bp-18h]@0
unsigned int P3; // [sp+14h] [bp-14h]@1
unsigned int P2; // [sp+18h] [bp-10h]@1
unsigned int P1; // [sp+1Ch] [bp-Ch]@1
len_1 = 0;
platform_ = platform;
version_ = version;
P1 = 0;
P2 = 0;
P3 = 0;
if ( !strcmp(platform, aWindows) )
{
ver_ = (unsigned __int8)*version_;
if ( *version_ == '2' )
{
mul1 = 142;
mul2 = 43;
mul3 = 201;
mul4 = 38;
goto LABEL_31;
}
if ( (_BYTE)ver_ == '3' )
{
mul1 = 23;
mul2 = 163;
mul3 = 2;
mul4 = 115;
goto LABEL_31;
}
if ( (_BYTE)ver_ == '4' )
{
mul1 = 17;
mul2 = 87;
mul3 = 120;
mul4 = 34;
goto LABEL_31;
}
}
else if ( !strcmp(platform_, aMacosx) )
{
ver_ = (unsigned __int8)*version_;
if ( *version_ == '2' )
{
mul1 = 41;
mul2 = 207;
mul3 = 104;
mul4 = 77;
goto LABEL_31;
}
if ( (_BYTE)ver_ == '3' )
{
mul1 = 128;
mul2 = 178;
mul3 = 104;
mul4 = 95;
goto LABEL_31;
}
if ( (_BYTE)ver_ == '4' )
{
mul1 = 67;
mul2 = 167;
mul3 = 74;
mul4 = 13;
goto LABEL_31;
}
}
else
{
v11 = strcmp(platform_, aLinux) == 0;
LOBYTE(ver_) = *version_;
if ( v11 )
{
if ( (_BYTE)ver_ == '2' )
{
mul1 = 48;
mul2 = 104;
mul3 = 234;
mul4 = 247;
goto LABEL_31;
}
if ( (_BYTE)ver_ == '3' )
{
mul2 = 52;
mul1 = 254;
mul3 = 98;
mul4 = 235;
goto LABEL_31;
}
if ( (_BYTE)ver_ == '4' )
{
mul1 = 207;
mul2 = 45;
mul3 = 198;
mul4 = 189;
goto LABEL_31;
}
}
else
{
if ( (_BYTE)ver_ == '2' )
{
mul1 = 123;
mul2 = 202;
mul3 = 97;
mul4 = 211;
goto LABEL_31;
}
if ( (_BYTE)ver_ == '3' )
{
mul1 = 127;
mul2 = 45;
mul3 = 209;
mul4 = 198;
goto LABEL_31;
}
if ( (_BYTE)ver_ == '4' )
{
mul2 = 4;
mul1 = 240;
mul3 = 47;
mul4 = 98;
goto LABEL_31;
}
}
}
if ( (_BYTE)ver_ == '5' )
{
mul1 = 7;
mul2 = 123;
mul3 = 23;
mul4 = 87;
}
else
{
mul1 = 0;
mul2 = 0;
mul3 = 0;
}
LABEL_31:
act_key_ptr = activation_key;
do
v13 = *act_key_ptr++;
while ( v13 );
if ( act_key_ptr != activation_key + 1 )
{
do
P1 = (P1 * mul1 + activation_key[len_1++]) & 0xFFFFF;
while ( len_1 < strlen(activation_key) );
}
act_key_ptr_1 = activation_key;
len_2 = 0;
do
v16 = *act_key_ptr_1++;
while ( v16 );
if ( act_key_ptr_1 != activation_key + 1 )
{
do
P2 = (P2 * mul2 + activation_key[len_2++]) & 0xFFFFF;
while ( len_2 < strlen(activation_key) );
}
act_key_ptr_2 = activation_key;
len_3 = 0;
do
v19 = *act_key_ptr_2++;
while ( v19 );
if ( act_key_ptr_2 != activation_key + 1 )
{
P3_ = 0;
do
P3_ = (P3_ * mul3 + activation_key[len_3++]) & 0xFFFFF;
while ( len_3 < strlen(activation_key) );
P3 = P3_;
}
act_key_ptr_3 = activation_key;
len_4 = 0;
do
v23 = *act_key_ptr_3++;
while ( v23 );
P4 = 0;
if ( act_key_ptr_3 != activation_key + 1 )
{
do
P4 = (P4 * mul4 + activation_key[len_4++]) & 0xFFFFF;
while ( len_4 < strlen(activation_key) );
}
sprintf(out_key, a_5x_5x_5x_5x, P1, P2, P3, P4);
return 0;
}
А место вызова этой функции приобретает следующий вид:
if ( convert_reqest_key(version, platform, request_key, out_key) || strcmp(out_key, act_key_hash) )
{
result = PyInt_FromLong(0);
}
Из этого всего можно сделать вывод, что request code преобразовывается с помощью функции convert_reqest_key и сравнивается затем с тем преобразованным кодом активации. Помните то преобразование?
Далее из кода активации отрезают три первых символа, убирают дефисы, преобразовывают в BASE16, и дополняют нулями, если нужно
Значит, чтобы получить правильный код активации нам теперь можно поступить следующим образом:
- Дать выполниться функции преобразования convert_reqest_key;
- На месте выполнения strcmp высмотреть содержимое out_key;
- Убрать лишние нули в начале out_key;
- Преобразовать out_key обратно в BASE30;
- Дописать в начало получившейся строки убранные три символа (AXX);
- По-желанию навтыкать дефисов через каждые пять символов.
Не буду мудрствовать лукаво, а втисну print прямо в python-код программы:
print("AXX" + textutils.BaseConvert("FCBCFEFD2FF684FA6A4F", textutils.BASE16, textutils.BASE30))
На выходе получил ключик:
wingide — 2015/05/24 04:03:47 — AXX3Q6BQHKQ773D24P58
Введя его в поле ввода ключа активации, получил заветное:
ИТОГИ
Как видите, процесс взлома не столько сложный, сколько интересный получился! Исследовать свои же исходники в скомпилированном их варианте… это, конечно, забавно.
Не знаю, зачем авторы приложили к своей программе ее исходники (хоть и в большинстве своем, в виде байт-кода). Но, думаю, вы понимаете, что так делать не стоит!
Всем спасибо.
This entry passed through the Full-Text RSS service - if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.
Комментариев нет:
Отправить комментарий