Здравствуйте всем!
Как следует из назвения темы, предлагаю обсудить Starforce 3 Pro. (Исследовал Starforce под WinMe).
Для начала - под S-Ice Starforce работать отказывается, FrogsIce не помогает, т.к никакими известными способами защита не пользуется, вернее пользуется, но скрытие их не помогает, т.к FrogsIce на такие зверства, как перехват физических обращений к DDB насколько я знаю, не идет. При ближайшем рассмотрении кода одного из драйверов защиты - ntprotect.vxd я обнаружил, что он шпарит по всем DDB и проверяет DEVICE_ID на сходесть с 0202h и 7a5fh, т.е SICE & SIVWID. Изменил прямо в памяти значения идентификаторов и значения имен - (0028:c002eeda - SICE, 0028:c001fdaa - SIVWID) все заработало. При попытке снять дамп получилось зависание и reboot, а ProcDump перед этим сказал "Process cannot be dumped!". При ближайшем рассмотрении обнаружил, что сие получается после применения функции VMMCALL LinPageLock. Затер ее в памяти, заменив на:
xor eax,eax
mov al,1
clc
ret
Дамп стал сниматься элементарно, но с пустой protect.dll
Посмотрел внимательнее - обнаружил функцию VXDLDR PELDR InitCompleted, ... FreeModule, ...RemoveExportTable и т.д.
Их постигла та же участь, что и LinPageLock - дамп снимается элементарно, все на месте. Но в коде остается псевдокод - нелепые call'ы, и т.д.
Исследовал idt до запуска и после запуска Starforce - выяснилось, что на перехваченом int3 (о том, что Starforce перехватывает int3 и int1 было известно и ранее)
висит движок псевдокода, который как раз и срабатывает на нелепых заранее ошибочных call'ах, адрес возврата которых после преобразования движком превращается в валидный. Думаю, стоит подумать: что сделать проще - сделать драйвер, висящий на CDFS и по номерам читаемых одиночных секторов делающий соответствующие задержки в выдаче ответов (кардинальное, по моему, решение), или убрать загрузчик Starforce, разместив на int3 свой движок псевдокода, загружая и выгружая его из protect.dll? Там, кстати, весь код - ~300 байт, ~5000 байт - данные для изменения адресов.

Спасибо большое за разъяснение, но не мог бы ты подсказать, какую игру или программу пытался взломать?
Основана ли она на старфорце3
Просто следуя из всего тобою выше сказанного:

Думаю, стоит подумать: что сделать проще - сделать драйвер, висящий на CDFS и по номерам читаемых одиночных секторов делающий соответствующие задержки в выдаче ответов (кардинальное, по моему, решение)

я так понимаю, твоя игра/программа обращается напрямую к к виндовскому CDFS, но начиная с версии StarForce3 защита обращается к своим ATAPI драйверам, тоесть заменяя тем самым CDFS. Кардинальное решение уже есть с эмуляторами типа Alcohol или Daemon Tools, но они срабатывают как раз когда в системе не присутствуют ATAPI приводы. Только при чтении со SCSI приводов защита передаёт дальнейшее управление CDFS. Поэтому надо сначала как-то обрубить опознание ATAPI приводов в системе, вот и вопрос, как?

или убрать загрузчик Starforce, разместив на int3 свой движок псевдокода, загружая и выгружая его из protect.dll? Там, кстати, весь код - ~300 байт, ~5000 байт - данные для изменения адресов


Вот пожалуй не плохой подход. Но надо было бы развивать идею в обоих направлениях.

Игра - Gangland, Starforce 3 Pro, наверное, проще написать WDM драйвер, который будет первоначально устанавливаться из тела .dll (при DLL_PROCESS_ATTACH), загружаться, ставить себя на int 3, а при DLL_PROCESS_DETACH - возвращать int 3 оригинальному обработчику. Относительно первого подхода - в любом случае, можно поставить драйвер между ATAPI и IOS, обрабатывая обращение к CDROM для чтения отдельных секторов. Где-то видел инфу, что читается небольшое количество отдельных секторов, т.е ограниченное количество и c неизменными номерами для конкретной игры - достаточно провести один пуск с нормальным или эмулированным диском, выводя на dprint все обращения к чтению одиночных секторов и время обращений, снабдить дровину этими данными и запускать спокойно. К тому же, можно просто написать свой ATAPI драйвер, настроенный под чтение конкретных номеров секторов. Не уверен отн. WinXP/2K, но под WinMe можно установиться между IOS'ом и драйверами в стат. VXD и контролировать все обращения к CDROM.

Не уверен отн. WinXP/2K, но под WinMe можно установиться между IOS'ом и драйверами в стат. VXD и контролировать все обращения к CDROM.

Про WinMe сразу скажу - не занимался, да это и не интересно.
А вот под WinNT я сидел в самом низу - хучил функции HAL.DLL, которые осуществляют вывод в порты. При этом, начиная с SF3 действительно ничего на эти хуки не перепадало. Т.е. очевидно, что StarForce так или иначе обращается к IDE ATAPI приводам напрямую через порты, не используя для этого, даже функции HAL.DLL. (возможно что как раз через собственные ATAPI драйвера).

Поэтому если копать кардинально, то действительно надо разобраться, как SF определяет наличие с системе IDE приводов. Наиболее вероятно, что его же собственные драйвера этим и занимаются, опять же напрямую сканируя шину IDE.. Тогда непонятно как можно эту проверку обломать.

К тому же, в protect.dll есть пять экспортируемых функций - (после снятия дампа они распакованы) protect_1, protect_2, AreDriversInstalled, InstallDrivers, UninstallDrivers. Смотрел AreDriversInstalled, похоже, там в случае удачного завершения проверки возвращается ноль в eax, таким образом, возможно, можно пропатчить этот вызов и удалить все драйвера. Защита, в принципе, сама по себе загружается при подгрузке protect.dll к программе, на DLL_PROCESS_ATTACH. Если сделать свою функцию на DLL_PROCESS_ATTACH, и пропатчить AreDriversInstalled, оставшаяся задача сводится к распаковке call'ов на обработчике int 3. К тому же: главное отличие Starforce x.x от остальных защит: физ. данные диска никак не влияют на процесс распаковки, в смысле, в качестве ключей эти данные не используются и не могут быть использованы по условию (цитата из Starforce whitepaper "... после изготовления тиража...с помощью StarForce Profiler и одного! диска из партии... извлекается ключ диска" - то есть, на момент записи диска ключа нет и быть не может, а следовательно, использоваться в распаковке он не может!) Похоже, по аналогии с криптографией, на "очередную дымовую завесу" и маскировку тривиальной задачи под NP-полную.

Обращение напрямую к IDE ATAPI, как я понимаю, становится возможным только после анализа наличия таковых устройств в системе, а следовательно, если в момент такой проверки подсунуть обратное, обращение пойдет штатными методами - судя по алгоритму обнаружения отладчика, ничего сверхъестественного в таких проверках быть не может.

если в момент такой проверки подсунуть обратное, обращение пойдет штатными методами
Вот это самое главное, как их заставить не находить. Памятник при жизни обеспечен ;)

Наиболее вероятно, что его же собственные драйвера этим и занимаются, опять же напрямую сканируя шину IDE.. Тогда непонятно как можно эту проверку обломать.
Так тут гадать нет необходимости, я уже обсуждал это с разработчиками Daemon Tools, а они уже собаку съели на этом. Star Force 3 устанавливает собственный АТАПИ драйвер, который напрямую отпрашивает IDE шину.
По всей видимости это StarForce Protection Synchronization Driver (v1)

физ. данные диска никак не влияют на процесс распаковки, в смысле, в качестве ключей эти данные не используются
Тяжело сказать, вполне возможна пермутация основного ключа с физическими данными, а основной ключ может добываться из логических данных, например то же название цд или какая нибудь часть цдромовского fat, у них же в программе как я понимаю собственный CD-ROM maker, они что хотят могут взять за основу, хотя ничего нельзя утверждать. Если разобраться, как происходит изготовление, то эта теория вполне вписывается.

Цитата (http://www.starforce.ru/products/prof30/index.htm)
"Уникальная технология, разработанная инженерами компании Protection Technology, позволяет, используя только один из лицензионных дисков и обыкновенный привод CD-ROM, определить (извлечь) 24-символьный буквенно-цифровой ключ, который содержит информацию об оригинальных физических параметрах всей заводской партии. Этот ключ не является секретным и используется модулем защиты, встраиваемым в выполняемый файл программного приложения, в качестве эталона для идентификации лицензионных CD."

То есть, ключ получается после изготовления всей партии, и что-либо изменить в этой партии невозможно(она уже наштампована) - то есть, вся защита сводится к сравнению, и дальнейшему ветвлению - если не равно, "ошибка", в противном случае - игра. Где-то видел предложение купить кейген, проверяющий текущий диск и выдающий ключ для текущего диска, который (как утверждают продавцы), принимается (в большинстве случаев) за подлинник.

А насчет драйвера ATAPI - в prosync1.vxd есть обращение в порты, и куча ветвлений (я пробовал менять их условия прямо в памяти - иногда говорит "Ошибка С0010001", иногда "Драйверы установлены успешно, перезагрузитесь"). Первоначально у меня создалось впечатление, что эти обращения в порты - провокация с целью определить наличие в системе отладчика, но в данном контексте похоже, что это контроль устройств (в принципе, контрольный блок драйвера распознает пять команд - 1bh, 23h,46530000h,46530001h,46530002h в CONTROL_0) и если изменить 23h на что-нибудь другое, начинает ругаться "Ошибка С0010001", если изменить 465300хх, говорит "Драйверы установлены успешно, перезагрузитесь". Как я понял, "Драйверы установлены успешно..." выдается в случае, если при попытке открыть один из драйверов через CreateFile получен -1. Но, в принципе, если сменить EP в .dll на свою функцию, загрузчик SF не загрузится - останется только установить на int 3 дешифратор и не заботиться о том, какого типа CD-привод.

Изменил прямо в памяти значения идентификаторов и значения имен - (0028:c002eeda - SICE, 0028:c001fdaa - SIVWID) все заработало

Сорри, и ты хочешь сказать, что банально падченого айса тебе хватило? Что защита определяет присутствие отладчика лишь по именам внутри sys-файла? Сорри, не верю. Надо будет поглядеть.

Исследовал idt до запуска и после запуска Starforce - выяснилось, что на перехваченом int3 (о том, что Starforce перехватывает int3 и int1 было известно и ранее)


А вот это уже больше похоже на правду. У тебя есть предложения как заставить работать айс при перехваченном int 3?

Погляди. Это не лишь имена внутри sys файлов, а содержимое DDB, средство для IPC(Inter Process Communication). Вообще, если активировать перед этим FrogsIce и вести лог попыток обнаружения, показывает три попытки: доступ к реестру, попытка загрузки SICE, попытка загрузки NTICE (причем, попробуй без изменения идентификаторов в памяти - скажет "программа не может работать при запущеном отладчике", несмотря на то, что все три попытки FrogsIce пресекает и обнаруживает). Причина, по моему, в том, что FrogsIse перехватывает VMMCall_GetDDB, а SF использует VMMCall_DDBList, которая остается незамеченой. Теперь, если ты убираешь из DDB S-Ice его символьное имя и числовой идентификатор - для IPC он становится недоступен. Вся эта проверка на наличие 202h видна под S-ice.
Относительно работы при перехваченом int 3 - а при чем здесь int 3 ? Если тебе нужно снять дамп или посмотреть чего, int 3 не нужно (начал уровень, затем Ctrl-D и /dump address length filename) - или банальным PETools или ProcDump'ом, свернув игру по Alt-Tab.

Если тебе нужно снять дамп или посмотреть чего, int 3 не нужно

Сорри, к стыду своему не могу пока сказать, что дизассемблировал Soft-Ice. Все руки не доходят. Ты хочешь сказать, что Ctrl+D не вызывает никаких "триггеров" никаких int? Что айс не проверяет вектора, которые сам же и хватает?

volodya

Дык он уже дизассемблирован и на reversing'е лежит его idb кажется ;-)

Никаких триггеров. Ctrl-D - реакция на пропатченный S-Ice'ом драйвер клавиатуры. И потом, он их хватает после bpx (на момент проверки, которая происходит до верификации диска, int 3 не перехвачено, перехват происходит тогда, когда защита убедится в отсутствии S-Ice, т.к на этом перехваченом int 3 находится распаковщик, распаковывающий в том числе и процедуру проверки диска). При любом кривом адресе в call'ах происходит переход на обработчик ошибок, т.е на int3: происходит изменение адреса на валидный и возврат управления по валидному адресу. Т.е. даже к концу игры большинство адресов в call'ах будет в дампе кривым (если не исправить, используя алгоритм распаковщика с int3).