Ответ Ивана Pощина.

┌─────────────────────────── Ответ: ───────────────────────────┐

29 Mar 99 Arseniy Astapenko wrote to All:

KF>>> Я пока знаю всего 3 метода отличить pеальное железо
KF>>> от эмулятоpов

AN>> Все методы (а их не 3) _подробно_и_с_примерами_ описаны
AN>> ALK /Stars of Keladan H.G. в одном из номеров борндэда...
AN>> Пятом, если не запамятовал (поправьте).

AA> He все, хотя надо отдать должное - материал был интересным.

А можешь прислать этот номер борндэда по e-mail?

[skip]

AN>> Самый надежный метод - это метод, основанный на открытии
AN>> Ивана Pощина... Хотя, как показала жизнь, все было
AN>> украдено до нас и метод этот был впервые применен
AN>> буржуями, а Pощин лишь документировал его. Hа русском. ;)

AA> Метод использовался ранее и у нас, например в защитах
AA> Realsoft'а 97 года. Тем не менее, обнародавал метод,
AA> неоспоримо, Иван Pощин.

По поводу использования этого метода в защитах Realsoft'а:
я уже писал тебе, но, видимо, ты не получил моего письма, так
что повторяю еще раз:

--- cut ---

15 Mar 99 Arseniy Astapenko wrote to All:

[skip]

AA> Все ж таки, надо признать, Realsoft наткнулся на эту фичу
AA> раньше Ивана Pощина. Я тут вспомнил ;) фрагмент ксорки на
AA> его прогах 97 года (SGEN 4.8, Technodrom):

Указанный фрагмент никоим образом не использует обнаруженный
и описанный мною глюк процессора - см.ниже.

AA> === Cut ===
AA> ; .....
AA> ;Тут была куча мелких ксорок с адреса #C000
AA> ; .....
AA> LLC02C LD HL,#C0B6
AA> EX (SP),HL ;сохраняем на стеке адрес выхода
AA> LD DE,#5B00
AA> EX DE,HL
AA> LD LX,E
AA> LD HX,D
AA> LD B,L
AA> LD A,H
AA> LD I,A
AA> INC A
AA> LLC03D LD (HL),A
AA> INC HL
AA> DJNZ LLC03D
AA> LD (HL),A
AA> LD L,H
AA> LD (HL),#C9 ;включаем "пустой" обработчик IM2
AA> IM 2
AA> LD HL,#C000 ;проверка сделаных ляпсусов :)
AA> LD B,#B6
AA> XOR A
AA> LLC04D ADD A,(HL)
AA> INC HL
AA> DJNZ LLC04D
AA> LD C,A
AA> LD A,R
AA> ADD A,C
AA> AND #7F ;сбрасываем 7-й бит
AA> PUSH AF
AA> EI
AA> HALT ;синхронизируемся
AA> EI ;4 поехали!
AA> LD B,#B5 ;7
AA> LD HL,#C16A ;10
AA> POP AF ;10
AA> LD R,A ;9
AA> LLC063 PUSH IX ;15
AA> LD A,R ;9
AA> RET PO ;5 ложный выход по глюку

Это вовсе не "ложный выход по глюку". Еще раз напомню, в
чем заключался описанный мною глюк Z80 (и ZILOG, и отечественных
аналогов): при разрешенных прерываниях команда LD A,R (и LD A,I)
неправильно устанавливает флаг P/V (так, как будто прерывания
запрещены), если во время ее выполнения произошло маскируемое
прерывание. Hу а здесь-то как может во время выполнения LD A,R
произойти прерывание, если эта команда всегда выполняется в
промежутке между двумя прерываниями?
Команды LD A,R: RET PO используются в приведенном фрагменте
для усложнения трассировки. Допустим, я хочу протрассировать
этот фрагмент в STS'е. Во время реальной работы фрагмента
гарантированно не произойдет прерывания, а вот при трассировке
такое возможно. STS ведь не отслеживает число тактов до
следующего импульса прерывания, а при трассировке команды
просто запускает ее из резидента - и если прерывания разрешены
(а при работе этого фрагмента они разрешены) - вполне
возможно, что при трассировке прерывание произойдет и будет
обработано. Что при этом произойдет? Во-первых, так как
обработчик состоит из одной команды RET (а не EI:RET!),
прерывания запретятся (и вот тогда-то RET PO сработает!!!).
Во-вторых, при обработке прерывания изменится значение в
регистре R и, даже если бы не было RET PO, дальнейшее
раскодирование блока пошло бы неправильно.
Чтобы не случилось прерывания при трассировке, возникает
искушение трассировать с запрещенными прерываниями - ан нет!
RET PO тут как тут! И единственный выход без применения "хитрых"
способов - трассировать с запрещенными прерываниями, но после
выполнения команды LD A,R вручную устанавливать флаг P/V.
Впрочем, из-за большого объема ручной работы это неприемлемо.
Я трассировал подобную ксорку в другой программе - поэтому
я хорошо знаю то, о чем пишу. Там, правда, защита была еще
покруче - использовалось содержимое ПЗУ TR-DOS, т.е. в ксорке
были примерно такие команды:

CALL XXXX ;CALL в ПЗУ TR-DOS
│
└───> XXXX: LD A,(HL) ;A:=байт из ПЗУ TR-DOS
RET ;возврат в ксорку
┌────────────┘
XOR ... ;раскодируем блок, используя
;взятый из ПЗУ байт

Дополнительная трудность при трассировке подобной ксорки в
том, что STS неправильно трассирует команду LD A,(HL) в ПЗУ
TR-DOS: по этой команде он помещает в регистр A байт не из
ПЗУ TR-DOS, а из ПЗУ BASIC-48, ну и соответственно расшифровка
блока происходит неправильно. Впрочем, при умелом подходе и
эта трудность преодолима.

AA> POP IX ;14
AA> XOR (HL) ;7
AA> XOR HX ;8
AA> POP DE ;10
AA> XOR D ;4
AA> XOR E ;4
AA> PUSH DE ;11
AA> CALL #33C5 ;27
AA> DEC SP ;6
AA> DEC SP ;6
AA> POP IY ;14 проверим, что нас не ломают
AA> XOR (IY-#0F) ;19
AA> XOR (IY-#0E) ;19
AA> XOR (IY-#0D) ;19
AA> XOR (IY-#07) ;19
AA> XOR (IY-#03) ;19
AA> XOR (IY+#13) ;19
AA> XOR (IY+#18) ;19
AA> LD (HL),A ;7
AA> DEC HL ;6
AA> DEC B ;4
AA> RET Z ;5 нормальный выход
AA> JP LLC063 ;17
AA> === Cut ===

[skip]

Теперь расскажу о причинах неработоспособности ксорки на
некоторых компьютерах. Тут дело не в процессоре, а в
длительности сигнала INT. Если сигнал INT длинный, прерывание
может быть обработано повторно (после команды EI), а при этом
(так как обработчик содержит лишь команду RET) прерывания
окажутся запрещены, что и приведет к вылету по RET PO. Именно
из-за этого на моем "Пентагоне" не работают программы с подобной
защитой.
Hу а то, что такая ксорка не работает на некоторых
эмуляторах, скорее всего говорит о неправильной эмуляции
изменения значения регистра R.

AA> Да, вот еще. Засунув в Спек процессор ВМ3 можно
AA> потрассировать этот участок без проблем. То же самое в
AA> эмуле 031, а 032 и 033 должны глюкануть ;-)

Потрассировать? Ха-ха! (см. выше).

Pаботать этот участок будет на любом Спектрум-совместимом
компьютере, с любым процессором, лишь бы были нормальными
длина импульса INT и промежуток между двумя импульсами.
Hа эмуляторе тоже будет работать на любом, лишь бы правильно
выполнялась эмуляция изменения значения регистра R (ну и чтоб
остальные команды правильно выполнялись ;)).

--- cut ---

Да и сам RealSoft признал, что дело тут не в глюке проца.

С уважением, Иван Pощин.

[BestView 2.8 - 50%] [BestView 3.0 - 5%]
└──────────────────────────────────────────────────────────────┘

С уважением, Alex from FFC COMPUTERS.

>E-MAIL: asde...@softhome.net ICQ: #13064553