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

Все статьи

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. Далее приводится примерное содержание функции:

.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. Последние лучше всего напечатать перед изучением.

2002-2013 (c) wasm.ru