# The Action Replay card for the PC - from Dirk Gently

We've been waiting for such a card since 1981. We used to envy Commodore users their cracking/hacking cards, while we had to wait for some 14 years for the first card on the PC. I think I needn't tell you why such a card is so important for a cracker/hacker, or even a usual PC-user. There are lots of picture dumper utilities on the market, for one, but most commercial applications disallow these programs. Not to mention the misery a cracker encounters when trying to 'freeze' the actual contents of the memory. Of course, such freezing is very dangerous under MS-DOS, regarding the logic (relocating the executable code when loading it) of the entire operating system. This is why I was very happy when I heard of this card.

The card itself is being manufactured by Datel Electronics. It has an upgradeable ROM, allowing us to update our cards regularly (still, I don't think these updates will eliminate the biggest problems of this card - unable to work under Windows 3.1 Enhanced mode/Win95, limited and unreliable tracking functions, improper handling of unofficial VGA modes with different screen refresh values etc). Of course, it requires our card to be a REAL card and not a copy - I've encountered quite a lot of copied cards everywhere.

### Cracking capabilities

Having got the card, I started testing it to find out whether it is a usable replacement for my widely used tools - Turbo Debugger, Soft-ICE etc, because on Commodore machines these Action Replay cards offer much better cracking capabilities than any software-based debuggers/tracers.

Well, I have to announce that the card is NOT for crackers. Unfortunately. It can't handle anti-debug codes - for example, we CAN switch on its INT 3-tracing function, but the card won't ever stop running the program, however frequently it uses INT 3s- and the same stands for INT 0, 1 and 2 as well. What do I mean? Very simple. If one points these interrupt vectors to a NEW address, the card will NO LONGER notice that there is an INT 0...3-call in progress.

It was HyperLock 386 that I tested first (you can find an article and my crack for this protection in Scanner 8). I've chosen this protection because I know it well enough and I consider it quite cool. As for me, it took me one day to crack it, back in 1993, when, as a novice user of my newly purchased GUS, I was astonished to find out that there were utilities to emulate Roland soundcards on it and I got angry with its author's announcing in MegaEM FAQ that 'No sources!'. Well, I set tracking of INT 3 in the menu of the card, started MegaEM.exe, and what happened? Nothing... I tried it once more, but setting up INT 0 as well.. Nothing at all, the protection of Mega-EM worked and it woulnd't give the card a chance. I started to write some codes to find out what made Action Replay be unable to see that there were INT 3 (0, etc...) calls. I checked the usual DOS Int 21h's function 25h to see whether it recognizes the 'usual' and 'official' rewriting of interrupt table. No success. At last, it turned out that if these interrupts are addressed to a routine in the memory that doesn't call the original routines at all, the Interrupt Interceptor function won't work. Of course, if we stop the execution of the program being run just after it has rewritten the interrupt table, and starting tracking any interrupt, it WILL work - but how would YOU stop a code that is being executed in some millisenconds when you can't rewrite its code to cause e.g. INT a0h (just an example - I use such unused interrupt vectors when cracking / debugging/ saving memory to disk etc...) because the code of HyperLock 386 is self-modifying - one can't enter an additional INT command anywhere (neither rewriting some 2-byte command work) after the protection's rewriting the interrupt descriptor table)?

So, we've seen the most important thing that makes this card almost unusable. The other is the following: assuming there are no new interrupt addresses, we simply want to track an interrupt that is being called frequently. One might assume that it works without problems, but the actual situation is far worse, because there are a lot of interrupt calls that aren't catched. Just try out the 'slow' function on the card - you can see how improperly it works. The movement is sluggish and extremely unfavourable - I mean for some 200-300 ms the original program runs at full speed, and for the next 10-400 ms (depending on the slow-down factor) it completely stops. And it applies to not only the slow- down mode, but also the interrupt tracking. When the original program runs at full speed, not only the slow mode is switched off, but also the entire card. It may sound ridiculous, but it's, unfortunately, true- there will be a lot of missed interrupt calls. Just try running the following code:

    .model small
    .code

    mov ax,cs
    mov ds,ax

    mov ax,3505h
    int 21h

    mov dx,bx
    mov ax,es
    mov ds,ax

    mov ax,25a5h   ; we'll be tracking Int 5 and we save the
                   ; original Int 5 to int a5
    int 21h

    mov ax,seg terve
    mov ds,ax
    mov dx,offset terve
    mov ax,2505h   ; updating the interrupt table, pointing to
                   ; our routine called 'terve', which will be
                   ; executed some 5-30 times a second,
                   ; depending on our frequency of calling it
    int 21h

    mov ah,8
    int 21h        ; the program is waiting for a keypress-
                   ; press the freezer button and set up
                   ; tracking int 5, as we've already modified
                   ; its address so we've avoided the
                   ; problems caused by the unability of the
                   ; card to track modified interrupts.

    takaisin:
    mov cx,00009h  ; setting the value of the outer loop. The
                   ; smaller the value, the more frequently int
                   ; 5's will be called (and the more calls that
                   ; the card won't succeed in intercepting)

    push cx

    outti:
    mov ddx,offset hi
    mv ah,9
    int 21h        ; there is a 9*$ffff cycle here. In this
                   ; loop, after having dumped the 'Hi!' on
                   ; the screen, we immediately call int 5
                   ; (iret)
    int 5
    pop cx
    dec cx
    je takaisin

    push cx
    mov cx,0ffffh
    inner: loopnz inner      ; the inner loop
    jmp outti

    hi db 'Hi!$'

    terve:
    int 0a5h       ; of course, we can omit this interrupt call
                   ; if we DO set tracing int 5 just after our
                   ; routine's setting up the new int 5 address
                   ; (look at the wait for a keystroke above)
    iret

    end

If the execution is fast enough (some 20-30 Int 5 calls a second), you'll see that there will be more than one 'Hi!''s between Action Replay's screen re-appearing on the screen. And it means there were missed interrupt calls.

Other serious drawbacks:

1. the card doesn't work under the Enhanced mode of Windows 3.1, only the standard (/s) (not to mention Win 95/ OS/2/ Linux/ Solaris/PC). As nowadays most programs don't have MS-DOS versions, this reduces the usability of the card. So, I can imagine only one usage for the card: ripping MODs etc... from various scene-products, as they run under MS-DOS and they, in general, use XMS to store their gfx/mzx, making it very hard to save them using software- based debuggers, memory dumpers etc. But the fact that it lacks the Win95-compatibility is a real pain in the ass.
2. it has problems with saving/restoring unofficial videomodes. Most X-mode etc... programs WORK, but there is C64s, for one, that doesn't. Even returning to Miha Peternel's great C64 emulator, C64s causes the screen to become jumbled.

One should also mention its advantages, anyway. The most important is the fact that it allows us to freeze not only the conventional area, but also the XMS area. Nowadays everybody has at least 8MB of memoy so the card's requirements (1 MB of XMS memory if we want to exploit its freezing capabilities) can be easily met. The freezing is almost unusable when talking about freezing + restarting programs at a particular point. Almost no programs worked after restarting the PC. The manual says that the card saves/restores the entire memory and all the registers/readable I/O ports, but I don't think so. Even simple programs like Turbo Pascal 6.0 (without frequent video- and soundcard-usage :-)) didn't run after restoring them. Not to mention programs that use sound/graphics modes as well. I couldn't recall ANY program that runs after freezing and restoring.

There is one advantage in using the freezing function, of course. It doesn't use ANY compression when saving the contents of the memory to disk, it dumps the entire used (I don't know whether it works well when trying to determine what area of memory is used and what is not) RAM into a file so one can rip MODs, gfxes from demos very easily, with the help of a simple CUT program :-).

IMHO the card sucks big time. 95% of the new programs run under Win95 or Win 3.1 Enhanced mode, and under these circumstances the usability of the card is very limited. I don't recommend buying it.