Vendor Id (далее просто VId) -- уникальное 16-битное значение в диапазоне 0x0000 -- 0xFFFF, присваиваемое каждому из клиентов Sentinel. Таким образом, Borland (aka Inprise) имеет свой VId; у Tanner Research тоже имеется по крайней мере один идентификатор. Инсталлятор SentinelLM SDK косвенно запрашивает VId и помещает его в некоторые исполнимые файлы SDK при установке. Значит нам необходимо будет узнать соответствующий VId нашей жертвы, как для установки SDK, так и для корректной генерации новых лицензий.
Откуда нам достать VId нашей жертвы? Можно спросить у синьора Донгла, если таковой имеется. Вторая ячейка слева -- искомый VId (серьёзно ;-). Умелые электронщики могут попробовать попытать Донгл под беспощадным программатором EEPROM'ов. Более простой подход -- чтение Донгла через порт. Я не советую вам делать ни то ни другое. Ещё спалите Донгл и тогда уж точно: кроме как брелок он вам больше ничем не послужит. Кстати, у обоих методов есть существенный недостаток -- Донгла-то может и не быть, если у вас копия совсем пиратская. Самый универсальный подход -- спросить у самой жертвы. Она уж точно знает, просто сказать стесняется. Да вот беда -- дистрибутив-то состоит из нескольких исполнимых файлов (экзешников и DLL-ок) -- поди узнай, кто из них за регинфу отвечает... Если ваша интуиция молчит, я вам подскажу. Читайте дальше.
Сентинельная защита, как такова, распространяется Reinbow Technologies ввиде оболочки API, т.е. комплекса драйверов, DLL, документации и прочих любимых программистами мелочей. Таким образом, пользовательская программа может вызвать некоторую API-функцию для проверки наличия донгла, запросить целостность лицензионной информации через другую API-функцию и т.д. и т.п. Для доступа ко всем этим функциям, т.е. для подключения к API, Reinbow предлагает два-три способа:
- прямое использование lsapiw32.dll (распространяется вместе с дистрибутивом);
- статическая линковка lsapiw32.lib (lsapiw32.dll НЕ фигурирует в дистрибутиве);
- нездоровые комбинации из 1 и 2.
Анализируем дистрибутив нашей жертвы на предмет наличия lsapiw32 или подобной DLL. Нашли? Если да, то грузите её в IDA. В противном случае имеет смысл предположить, что lsapiw32 статически прилинкована к главному исполнимому модулю программы. Как бы то ни было, наложение сигнатуры W32MCST1 (sentinel static lib) в IDE должно обнаружить БОЛЬШОЕ количество сентинельных функций. Если не обнаружит, попробуйте загрузить другой модуль и т.д. Терпение постепенно превращается в опыт.
Далее, жмите на Ctrl+L и удивляйтесь: зачем SLM столько вспомогательных функций? Попытаемся угадать функцию, возвращающую VId. Первый, но не единственный, кандидат -- _computeVendorCode. Далее приводится примерное содержание функции:
.DATA
Error db "SentinelLM",0
SentinelLM db "%s error: Illegal vendor identification.",0Ah,0
.CODE
_computeVendorCode PROC param:WORD
LOCAL lVar:DWORD
invoke _DencVendId,param + 18h,ADDR lVar
test eax,eax
jnz @@1
invoke _VLMwriteFrontendMsgs,0,OFFSET Error,OFFSET SentinelLM
mov eax,0FFFFFFFCh
jmp @@2
@@1:
mov eax,lVar
@@2:
ret
_computeVendorCode ENDP
Обратите внимание на то, что _computeVendorCode является враппером к _DencVendId, которая, в свою очередь, вызывает _VLM_deMorphId. Особого внимания заслуживают и строковые константы, так? ;-)
Пора перейти к софтайсу... Создаём MAP-файл (если хотите, можете убрать все символы кроме _computeVendorCode или _DencVendId). Ищем утилиту msym.exe в softice_path/util16 и перегоняем наш MAP в SYM ("MSYM file.MAP"). Полученный SYM транслируем в NMS с помощью nmsym.exe в softice_path/ ("NMSYM file.sym") и загружаем в Symbol Loader ("NMSYM /SYM:file.NMS"). Далее, если _computeVendorCode находится в DLL, загружаем её в Symbol Loader ("Open module...") и смело жмём на "Load". Потом заходим в SoftIce (Ctrl+D) и ставим бряк на _computeVendorCode (bpx _computeVendorCode). Запускаем наше подопытное приложение (*.EXE) обычным способом и терпеливо ждём появления дружелюбного отладчика. Дождались? F12 и записываем содержимое EAX на бумажку!!!
А что если _computeVendorCode находится в EXE? Тогда чуть сложнее... После загрузки NMS, грузим *.EXE через Symbol Loader (!) и жмём на "Load". При появлении окна отладчика клацаем по F8 для попадания в код приложения. Задаём команду TASK и находим имя нашего подопытного процесса. Передаём полученное имя в качестве параметра команде MAP32 (вроде "MAP32 myprog") и смотрим на поля "Obj Name" и "Address". Например:
:MAP32 myprog
Owner Obj Name Obj# Address Size Type
MYPROG .text 0001 01AF:00401000 000ECF70 CODE RO
MYPROG .data 0002 01B7:004EE000 00001BE4 IDATA RW
MYPROG .rsrc 0003 01B7:00508000 00026800 IDATA RO
С полученными данными можете приступать к релокации символов NMS:
:SYMLOC 1 1AF 401000
:SYM
.text(01AF:00401000, 002772F7 bytes)
01AF:006782F3 _computeVendorCode
'1' в SYMLOC обозначает порядковый номер сегмента кода в MAP-файле. "1AF 401000" соответствует адресу "01AF:00401000". В данном случае, имеется ввиду именно сегмент CODE (aka .text), так-как в коде находится _computeVendorCode (не среди данных или ресурсов). Команда SYM показывает местоположение нашей функции, тем самым подтверждая успешную релокацию символов. Далее, ставим бряк на _computeVendorCode и закрываем окно отладчика. При повторном появлении оного жмём на F12 и записываем VId.
Как и прежде, жду ваши комментарии. До следующей главы. Отдыхайте.
Примечание
Если вы не совсем поняли или совсем не поняли содержание последних абзацев, советую поискать и почитать туториалы по IDA и SoftIce. Последние лучше всего напечатать перед изучением.
[C] Quantum