Проблема выглядит так:
Есть прога Кредо 3 Топоплан. Защищена новексом GS II.
С выдиранием дескрипторов из ключа образовалась проблема, поэтому решил идти по пути наименьшего сопротивления - а именно достать все проверочные 16-ти байтовые пары (запрос/ответ) так как фильтром, конечно хорошо, но дюже долго их выковыривать. И столкнулся с тем, что прога при попытке поставить бряки на _lopen, например, молча отправляет комп в горячую перезагрузку. То-же проиходит если ставить бряки где-нибудь вглубине проги. Как быть?

| Сообщение посчитали полезным:

поставь поглубже... не на _lopen, а на _lopen+1, например. Хотя второй стелс еще не смотрел

| Сообщение посчитали полезным:

Canakau пишет:
столкнулся с тем, что прога при попытке поставить бряки на _lopen, например, молча отправляет комп в горячую перезагрузку. То-же проиходит если ставить бряки где-нибудь вглубине проги. Как быть?

ана по ходу применяет проверку на бряки в своем теле и в теле апи, тебе нада поставить бряк на доступ к памяти (на том же месте где ты ставил обычные бряки), тогда скорее всего ты её поймаешь на проверке, а там уже можно править эту процеруру.

| Сообщение посчитали полезным:

2MoonShiner: так я тоже пробовал. И еще глубже пробовал - не помогает. И внутри тела АПИ Guardant'а ставил - то-же... амое интересное- ели бряки тоят вначале проги в районе ОЕП, все нормально. А тоит поставить много глубже (даже не внутри АПИ) происходит перезагрузка.

2Warrior: попробую... то-есть ты предлагаешь поставить бряк на выполнение и бряк на доступ к памяти одновременно? попробую...

я както раз столкнулся с защитой, где было что-то похожее... Старфорс на Автодилер Авто каталог №11. но там была ДЛЛ px3p.dll в которой были почти все функции из kernel32.dll переписаны. заменил ее соответственно на kernel32 и как бабка пошептала здесь такого нет...

| Сообщение посчитали полезным:

2Warrior: попробовал. не помогает. При установке bpx _hread; bpm _hread машина перезагружается. при простом bpm _hread отрабатывает и ничего.. как так можно...

| Сообщение посчитали полезным:

а воспользоваться ODbg ты не пробовал?
или в данном случае обязательно требуется в ring 0 забираться?

| Сообщение посчитали полезным:

2stalker: а под ним тоже не работает... Видишь-ли... хотелось бы кавалерийки набегом - раз, бряку на head потом два - найти вызов трансформа и три - разгрести завалы,где зырыты q&a пары. А тут вырисовывается первым пунктом разгребать завалы по поводу детекта отладчика. Тяжелая форма в случае Olly и, как я подозреваю, по-легче - с софтайсом. Вот я и интересуюсь - есть ли что-нибудь поновее да позаковыристее чем IceExt. Неспортивно... но время поджимает или, все-таки придется запускать фильтр и долбить прогу раз 300 для отлова некоторого количества q&a. А после 50 запусков ни одного повтора пар - это заставляет задуматься...

| Сообщение посчитали полезным:

Canakau

что-то мне кажется, что сия прога перенаправляет вектор 3-го прерывания (int3) на свой обработчик, и когда он срабатывает(на бряках), делает следующее :

mov ax, 0911
mov dx,@'HBOOT'
mov si, 4647
mov di, 4a4d
jmp на обработчик int 3 софтайса.
................................
=ушел в нирвану=
................................
про backdoor SoftICE можешь тут почитать:
http://xtin.km.ru/view.shtml?id=88 http://xtin.km.ru/view.shtml?id=88

если так, то нужно вернуть родной обработчик int 3 (SoftICE) на базу (в IDT).

-----
Research is my purpose

| Сообщение посчитали полезным:

Canakau пишет:
При установке bpx _hread; bpm _hread машина перезагружается. при простом bpm _hread отрабатывает и ничего.. как так можно...

попробуй BPR _hread поставить

| Сообщение посчитали полезным:

> что-то мне кажется, что сия прога перенаправляет вектор 3-го прерывания (int3)

Ну уж это она точно не делает, для этого драйвер нужен

| Сообщение посчитали полезным:

а чем nvkeynt.sys не драйвер? И потом, может прога еще и другие драйверы имеет?

| Сообщение посчитали полезным:

2MoonShiner: Вроде IceExt от этого спасает? INT3 protection. Но тут еще одна вещь... если ставишь бряку на ф-цию, оторая не используется (например bpx MessageBoxIndirectA), то прога отрабатывает нормально. То-есть срабатывает не тогда, когда бряки есть вообще, а тогда, когда прога об них спотыкается.

| Сообщение посчитали полезным:

Вот вопрос, можно ли скрыть отладчики и прочие инструменты с помощью руткитов? Технология просто жо безобразия, но на сколько я знаю, это имеет место быть..... Тот же ОЛЛИ прекрсано маскируется с помщью этого...... а вообще, особо не тестил, т.к. нет необходимого опыта во взломе..... В использовании руткитами есть

-----
The blood swap....

| Сообщение посчитали полезным:

Canakau пишет:
С выдиранием дескрипторов из ключа образовалась проблема, поэтому решил идти по пути наименьшего сопротивления - а именно достать все проверочные 16-ти байтовые пары (запрос/ответ) так как фильтром, конечно хорошо, но дюже долго их выковыривать. И столкнулся с тем, что прога при попытке поставить бряки на _lopen, например, молча отправляет комп в горячую перезагрузку. То-же проиходит если ставить бряки где-нибудь вглубине проги. Как быть?

esli filter ne nravitsya - mozhet prosto v ide nait vse vyzovy transform i bryak na nego?


[and of course, usual excuse for translit]

| Сообщение посчитали полезным:

Canakau пишет:
Вроде IceExt от этого спасает? INT3 protection

Ну сам понимаешь, вчера спасал - сегодня уже может и не спасать... Поскольку перезагрузка возникает именно при срабатывании бряков, а не при их установке, то вполне разумно предположить, что код, вызывающий перезагрузку находится в обработчике... А что мешает сравнить несколько дампов IDT? При загрузке виндовс, при загрузке айса, при загрузке проги... уже можно былобы кое-какие выводы сделать, утилит для этого хватает...
P.S. to DrGolova Безусловно, для этого нужен драйвер

-----
Research is my purpose

| Сообщение посчитали полезным:

в общем !bpr X _hread 1 - тоже не помог (вместо _hread пришлось вставить реальный адрес процедуры) давно я с таким не встречался... со времен первого знакомства с китайской защитой... печально. Думаю, придется выпаивать микруху памяти с ключа и читать напрямую. одно плохо - марку ее не знаю. известно, что проц - пик16ф84 а вот память... все спилено. мож кто подскажет? вероятно - это самый эффективный метод будет.
2 ssx: знаешь, даже в хэлпе от новекса пишут, что эти вещи лучше прятать. А ребята явно не профаны. В проге еще есть кодированные участки...попробую, конечно, но думаю - это не оптимальный путь. попробую "разрубить Гордиев узел" и залезу в хардварь...

| Сообщение посчитали полезным:

т.е. ты хочешь прошивку со второго стелса снять (от первого уже есть)? сильно.
upd: и разве второй слес на пике сделан?

| Сообщение посчитали полезным:

ssx: прошивку пока не знаю буду пробовать снять или нет. надо дескрипторы выдрать с микрухи внешней памяти. Да вроде на пике.. А кто-нибудь смотрел - по схеме второй от первого отличается? или все идентично и разница только в прошивке? (пардон за оффтоп)

| Сообщение посчитали полезным:

хм. считать дескрипторы из eeprom проще, чем просчитать их?
насчет того, на pic 2-ой сделан или нет - пусть лучше гуру выскажутся

| Сообщение посчитали полезным:

ssx: боги молчат...
вообще я нашел эту падлу. драйвер printsrv.sys в systemroot\system32\drivers. Не знаю - стандартная это приблуда от новекса или нет, но она- определенно. В нем установлен только Create и Close события. При открытии драйвера, если есть бряки где-либо в теле проги, происходит все плохое. Причем драйвер (как я понял) вызывается всего один раз. ставить бряку на "после вызова" бесполезно. Ребут - однозначно. При остановке сервиса, запускаться не хотит. В деталях разобраться не успел. Место вызова драйвера шифрованое. драйвер просто вызывается через CeateFileA затем, если возврат не -1 то закрывается. если нет, то процесс закрытия опускается. То-есть скорее всего он что-то выставляет в памяти. Данные ему не передаются. Короче еще одна головоломка В аттаче тот самый драйвер, если кому интересно. не знаю - есть он в стандартной поставе отновекса, или это местное нововведение.

4199_printsrv.rar.zip

| Сообщение посчитали полезным:

неа, у новекса в sdk да и вообще где бы то ни было такого не встречал

странно, в version info - microsoft
но что ms может иметь общего с \Device\NVKEYNT - не представляю

да, D:\Protection\Echelon\Bin\Drv\WinNT\Src\objfre_wxp_x86\i386\printsrv.p db - это точно не ms

| Сообщение посчитали полезным:

кстати, а может отписать в microsoft - типа, вот, эти люди прикрываясь вашим честным именем обманывают простых пользователей с отладчиками?

| Сообщение посчитали полезным:

Canakau пишет:
Думаю, придется выпаивать микруху памяти с ключа и читать напрямую. одно плохо - марку ее не знаю. известно, что проц - пик16ф84 а вот память... все спилено. мож кто подскажет? вероятно - это самый эффективный метод будет.
само по себе чтение микросхемы внешней памяти мало что дает - вся память пошифрована.

| Сообщение посчитали полезным:

2nd
а второй стелс все-таки на pic сделан? или на cypres?

| Сообщение посчитали полезным:

ssx: на cypress сделан 2-й стеллс в версии USB. А в ЛПТ - не знаю...то-есть предполагаю, что как и в 1-м пик
2nd: ну да.. я тоже подумал, что прошивку тоже дергать придется. Но За это сложно браться не зная маркировки микрух. Как узнаю, занесу Соболю..Махом их сдует и прочитает

| Сообщение посчитали полезным:

Как спрятать SoftIce, если IceExt 0.65 не помогает?

Попробовать IceExt 0.67 http://stenri.pisem.net/ ?

| Сообщение посчитали полезным:

ssx пишет:
а второй стелс все-таки на pic сделан? или на cypres?
не знаю, да и не так это важно. На коленке читались только старые стелсы-1. Потом если не ошибаюсь F84 поменяли на F84A и старый метод чтения отпал. Те кто смогли прочитать F84A думаю и с cypres справятся.
Внешняя память, если не изменяет склероз, была на 93C56A (или на чем схожем по интерфейсу).

| Сообщение посчитали полезным:

2nd: За информацию огромное спасибо. Буду пробовать.да, я тут в проге нашел большой таой массив с парами q&a. Олно плохо - таблицысоответствия нет. то есть какому q какое a соответствует. Экстраполяция, разумеется, не помогла. при бряке !bpr R adr len все так же вылетает. В драйвере по смещению C6C находится call в котором заносится куча вякого хлама в память. При одном из таких занесений происходит бум. При игнорировании и всего этого call и, даже, только одной-двух подмен в памяти драйвер отрабатывает хорошо, но прога вылетает (правда только выдает стандартное виндовое окошко об ошибке). Трассировать это все - Сизифов труд. Появилась мысль, древняя как мир - если гора не идет... Решил забить блок q&a нулями (чем не решение?) но прога проверяет свою чексумму. причем такой умо помрачительной матеатикой... ессно даже поменять 2 рядом тоящих байта и +1 -1 тоже не прокатывает. правда спасает то, что проверка эта до загрузки (ненависсссстного..горлум горлум...) драйвера. сегодня утром пришел мысэл - а если прога считает себя ВСЮ целиком (от 401000 и до упора) то где-то же ей надо хранить что-то, с чем оно сравнивается? Дай бог, что бы не с нулем. и если это что-то и есть, то оно где-то вне проверяемого участка... сегодня буду искать.

| Сообщение посчитали полезным:

Прогу я таки запустил. Скопировал секцию .text в конец файла (а целостность проверялась только ее) и подправил адрес, откуда проверять. Забил нулями массив запросов/ответов. Прога запустилась. (при наличии эмулятора ессно) Но, возникли проблемы с созданием/открытием проекта. Правда, как мне кажется, это поправимо (я воспрял духом! результат налицо) Если все удастся, напишу статью о гибридном взломе. Кстати, драйвер отправляет машину в перезагрузку, если после его запуска СРАБАТЫВАЕТ какой-либо бряк, а нге просто стоит. Причем, после запуска проги, при попытке выгрузить драйвер (вероятно он запускается еще раз) прога опять же летит в космос.

| Сообщение посчитали полезным:

да, IceExt новый я скачал, но пока не пробовал. Gideon Vi - огромное спасибо.
На счет чтения прошивы из pic16f84a сведения противоречивые. Одни говорят, что не читается, другие, что читается с помощью power glitch. Про cypress Соболь сказал, что бит защиты хрен перешибешь, а в Сети ничего нет...

| Сообщение посчитали полезным: