Answer from Ivan Roshchin.

┌─────────────────────────── Answer: I know everything so far 3 methods to distinguish real hardware
KF>>> from emulators

AN>> All methods (and there are not 3) are _detailed_and_with_examples_ described
AN>> ALK /Stars of Keladan H.G. in one of the borned issues...
AN>> Fifth, if I haven’t forgotten (correct).

AA> Not all, although we must give credit where credit is due - the material was interesting.

Can you send this borned issue by e-mail?

[skip]

AN>> The most reliable method is the method based on the discovery
AN>> Ivan Roshchin... Although, as life has shown, everything happened
AN>> was stolen before us and this method was first used
AN>> by the bourgeoisie, and Roshchin only documented it. In Russian. ;)

AA> The method was used earlier in our country, for example, in Realsoft's
AA> protections in 1997. Nevertheless, it was undeniably Ivan Roshchin who unveiled the method
AA> Regarding the use of this method in Realsoft's defenses:
I already wrote to you, but apparently you did not receive my letter, so
I repeat again:

--- cut ---

15 Mar 99 Arseniy Astapenko wrote to All:

[skip]

AA> Still, I must admit, Realsoft came across this feature
AA> before Ivan Roshchin. I just remembered ;) a fragment of Xorka on
AA> his programs from 1997 (SGEN 4.8,Technodrom):

The specified fragment in no way uses the processor glitch that I discovered and described - see below.

AA> === Cut ===
AA> ; .....
AA> ;There were a bunch of small xorks from the address #C000
AA> ; .....
AA> LLC02C LD HL,#C0B6
AA> EX (SP),HL ;save the output address on the stack
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 ;turn on the “empty” handler IM2
AA> IM 2
AA> LD HL,#C000 ;checking the mistakes made :)
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 ;reset the 7th bit
AA> PUSH AF
AA> EI
AA> HALT ;synchronize
AA>EI ;4 let's go!
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 false output glitch

This is not a “false exit due to a glitch” at all. Let me remind you once again what the glitch of the Z80 (both ZILOG and domestic
analogues) that I described was: with interrupts enabled, the LD A, R (and LD A, I) command incorrectly sets the P/V flag (as if interrupts were
disabled) if a masked
interrupt occurred during its execution. Well, how can an interrupt occur during the execution of LD A,R
if this command is always executed in
the interval between two interrupts?
The LD A, R: RET PO commands are used in the given fragment
to complicate the tracing. Let's say I want to trace
this fragment in STS. During real operation of the fragment
it is guaranteed that no interruption will occur, but during tracing
this is possible. STS does not track the number of clock cycles until
the next interrupt pulse, but when tracing a command
it simply runs it from the resident - and if interrupts are enabled
(and when this fragment is running, they are enabled) - it is quite
possible that when tracing an interrupt will occur andwill be
processed. What will happen? Firstly, since
the handler consists of a single RET instruction (and not EI:RET!),
interrupts will be disabled (and then RET PO will work!!!).
Secondly, when processing an interrupt, the value in
the R register will change and, even if there were no RET PO, further
decoding of the block would go wrong.
To avoid an interruption during tracing, there is
the temptation to trace with prohibited interruptions - but no!
RET PO is right there! And the only way out without using “tricky”
methods is to trace with interrupts disabled, but after
executing the LD A,R command, manually set the P/V flag.
However, due to the large amount of manual work, this is unacceptable.
I traced a similar xork in another program - so
I know well what I’m writing about. There, however, the protection was even more abrupt - the contents of the TR-DOS ROM were used, i.e. in Xork
there were approximately the following commands:

CALL XXXX ;CALL to TR-DOS ROM
│
└───> XXXX: LD A,(HL) ;A:=byte from TR-DOS ROM
RET ;return to Xork
┌────────────┘
XOR ... ;decode the block using
;byte taken from ROM

An additional difficulty when tracing such a xor is
thatSTS incorrectly traces the LD A,(HL) command to the TR-DOS ROM: according to this command, it places a byte in the A register not from the TR-DOS ROM, but from the BASIC-48 ROM, and accordingly, the decryption of the block occurs incorrectly. However, with a skillful approach
this difficulty can be overcome.

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 let's check that we are not being broken
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 normal exit
AA> JP LLC063 ;17
AA> === Cut ===

[skip]

Now I’ll tell you about the reasons why Xorka doesn’t work on
some computers. It's not about the processor, it's about
durationsignal INT. If the INT signal is long, the interrupt
can be processed again (after the EI command), and in this case
(since the handler contains only the RET command) interrupts
will be disabled, which will lead to a RET PO crash. It is
because of this that programs with such
protection do not work on my Pentagon.
Well, the fact that such a xor does not work on some
emulators most likely indicates incorrect emulation
of changing the value of the R register.

AA> Yes, that’s another thing. By inserting a VM3 processor into the Spec, you can
AA> trace this section without any problems. The same thing happens in
AA> emulator 031, but 032 and 033 should glitch ;-)

Trace? Ha ha! (see above).

This section will work on any Spectrum-compatible
computer, with any processor, as long as the
length of the INT pulse and the gap between two pulses are normal.
On the emulator it will also work on any, as long as the change in the value of the R register is correctly
emulated (and so that the
other commands are executed correctly ;)).

--- cut ---

And RealSoft itself admitted that the problem here is not a glitch of the processor.

Sincerely, Ivan Roshchin.

[BestView 2.8 - 50%] [BestView 3.0 - 5%]
└─────────────────────────────── ───────────────────────────────┘< p>
Best regards, Alex from FFC COMPUTERS.

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