SentinelLM!Vendor_Id — Архив WASM.RU

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 предлагает два-три способа:

1. прямое использование lsapiw32.dll (распространяется вместе с дистрибутивом);
2. статическая линковка lsapiw32.lib (lsapiw32.dll НЕ фигурирует в дистрибутиве);
3. нездоровые комбинации из 1 и 2.

В любом случае, SLM должен будет вызвать специальную функцию для получения своего VId. Наша цель -- перехватить эту самую функцию и подсмотреть значение EAX.

Анализируем дистрибутив нашей жертвы на предмет наличия lsapiw32 или подобной DLL. Нашли? Если да, то грузите её в IDA. В противном случае имеет смысл предположить, что lsapiw32 статически прилинкована к главному исполнимому модулю программы. Как бы то ни было, наложение сигнатуры W32MCST1 (sentinel static lib) в IDE должно обнаружить БОЛЬШОЕ количество сентинельных функций. Если не обнаружит, попробуйте загрузить другой модуль и т.д. Терпение постепенно превращается в опыт.

Далее, жмите на Ctrl+L и удивляйтесь: зачем SLM столько вспомогательных функций? Попытаемся угадать функцию, возвращающую VId. Первый, но не единственный, кандидат -- _computeVendorCode. Далее приводится примерное содержание функции:

Код (Text):

1.  
2. .DATA
3.   Error       db "SentinelLM",0
4.   SentinelLM  db "%s error: Illegal vendor identification.",0Ah,0
5.  
6. .CODE
7. _computeVendorCode PROC param:WORD
8.   LOCAL lVar:DWORD
9.   invoke _DencVendId,param + 18h,ADDR lVar
10.   test eax,eax
11.   jnz @@1
12.   invoke _VLMwriteFrontendMsgs,0,OFFSET Error,OFFSET SentinelLM
13.   mov eax,0FFFFFFFCh
14.   jmp @@2
15. @@1:
16.   mov eax,lVar
17. @@2:
18.   ret
19. _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". Например:

Код (Text):

1.  
2.  :MAP32 myprog
3.  Owner     Obj Name  Obj#  Address        Size      Type
4.  MYPROG    .text     0001  01AF:00401000  000ECF70  CODE  RO
5.  MYPROG    .data     0002  01B7:004EE000  00001BE4  IDATA RW
6.  MYPROG    .rsrc     0003  01B7:00508000  00026800  IDATA RO

С полученными данными можете приступать к релокации символов NMS:

Код (Text):

1.  
2.  :SYMLOC 1 1AF 401000
3.  :SYM
4.  .text(01AF:00401000, 002772F7 bytes)
5.        01AF:006782F3 _computeVendorCode

'1' в SYMLOC обозначает порядковый номер сегмента кода в MAP-файле. "1AF 401000" соответствует адресу "01AF:00401000". В данном случае, имеется ввиду именно сегмент CODE (aka .text), так-как в коде находится _computeVendorCode (не среди данных или ресурсов). Команда SYM показывает местоположение нашей функции, тем самым подтверждая успешную релокацию символов. Далее, ставим бряк на _computeVendorCode и закрываем окно отладчика. При повторном появлении оного жмём на F12 и записываем VId.

Как и прежде, жду ваши комментарии. До следующей главы. Отдыхайте.

Примечание

Если вы не совсем поняли или совсем не поняли содержание последних абзацев, советую поискать и почитать туториалы по IDA и SoftIce. Последние лучше всего напечатать перед изучением. © Quantum