Autor Thema: Emulator erkennen - Funktion wirft beim zweiten Aufruf Bomben  (Gelesen 197 mal)

0 Mitglieder und 1 Gast betrachten dieses Thema.

Offline Count

  • Benutzer
  • Beiträge: 61
Hallo, ich mal wieder. ;)

Einige kennen sicher diese kleine Assembler-Routine, mit der man erkennen kann, ob ein Programm in bestimmten Emulatoren ausgeführt wird.

Ich habe die Routine etwas gestutzt als Funktion in eine GNU-C-Library eingebaut. Der Prototyp sieht so aus:

extern short detect_emulator();

Die Funktion liefert einen Wert, abhängig vom erkannten Emulator oder 0, wenn kein Emulator erkannt wurde. Beim ersten Aufruf bekomme ich auch den richtigen Wert (Steem = 3, echte Hardware = 0). Rufe ich die Funktion ein zweites Mal auf, bekomme ich drei Bomben (Busfehler/ungerade Adresse).

Leider habe ich mich seit fast dreißig Jahren nicht mehr mit Assembler beschäftigt, so dass ich etwas auf dem Schlauch stehe, was die Ursache sein könnte.

| Detect emulators
|
| short detect_emulator();
|

#define __ASSEMBLY__
#include "../../include/emudet.h"

    .globl  _detect_emulator

_detect_emulator:

        move.l  #0x456d753f,d5  | Emu?
        move.l  d5,d7
        move.l  d5,d6
        move    #0x25,-(a7)
        trap    #0x0e
        addq.l  #2,a7

        cmp.l   d5,d6
        bne.s   .under_emu
        cmp.l   d5,d7
        bne.s   .under_emu

        moveq   #NO_EMU,d0
        bra.s   .return

.under_emu:

        cmp.l  #0x50614369,d6  | PaCi
        bne.s  .not_pacifist
        cmp.l  #0x66695354,d7  | fiST
        bne.s  .not_pacifist

        moveq   #PACIFIST_EMU,d0
        bra.s   .return

.not_pacifist:
        cmp.l   #0x54426f78,d6  | TBox
        bne.s   .not_tosbox

        moveq   #TOSBOX_EMU,d0
        bra.s   .return

.not_tosbox:

        cmp.l   #0x53544565,d6  | STEe
        bne.s   .not_steem
        cmp.l   #0x6d456e67,d7  | mEng
        bne.s   .not_steem

        moveq   #STEEM_EMU,d0
        bra.s   .return

.not_steem:
        moveq   #OTHER_EMU,d0

.return:
        rts

emudet.h:
#ifndef LIBPB_PBEMUDET_H
#define LIBPB_PBEMUDET_H


#ifndef __ASSEMBLY__
# include "../include/config.h"
#endif /* defined __ASSEMBLY__ */


#define NO_EMU        0
#define PACIFIST_EMU  1
#define TOSBOX_EMU    2
#define STEEM_EMU     3
#define OTHER_EMU     64


#ifndef __ASSEMBLY__
extern short detect_emulator();
#endif /* defined __ASSEMBLY__ */


#endif /* LIBPB_PBEMUDET_H */

Wer kann helfen?

Gruß
Oliver

Offline czietz

  • Benutzer
  • Beiträge: 2.052
Re: Emulator erkennen - Funktion wirft beim zweiten Aufruf Bomben
« Antwort #1 am: Do 06.06.2019, 20:30:17 »
Du darfst in einer Assembler-Funktion nicht einfach D5, D6, D7 überschreiben. Der Compiler geht davon aus, dass deren Inhalt erhalten bleibt. Davon abgesehen: Hatari erkennst Du damit ohnehin nicht. Was ist also der Sinn der Emulator-Erkennung?

Offline Thorsten Otto

  • Benutzer
  • Beiträge: 466
Re: Emulator erkennen - Funktion wirft beim zweiten Aufruf Bomben
« Antwort #2 am: Fr 07.06.2019, 08:24:26 »
Für Hatari, ARAnyM und auch STonX müsstest du die sogenannten NatFeats benutzen. Habe jetzt gerade kein Beispiel an der Hand, müsste aber in der Wiki von ARAnyM zu finden sein. Oder du schaust dir die EmuTOS-Sourcen an, da wird das auch benutzt.

Die von dir benutzte Abfrage funktioniert nur für die speziellen Emulatoren auf die du da testet, und von denen wird (ausser vlt.Steem) keiner mehr weiter entwickelt.

Abgesehen davon taugt diese Abfrage sowieso höchsten als Info, viel anfangen kann man damit ansonsten nicht.

Offline czietz

  • Benutzer
  • Beiträge: 2.052
Re: Emulator erkennen - Funktion wirft beim zweiten Aufruf Bomben
« Antwort #3 am: Fr 07.06.2019, 08:35:41 »
Für Hatari, ARAnyM und auch STonX müsstest du die sogenannten NatFeats benutzen.

In Hatari muss der Nutzer NatFeats erst aktivieren, sonst lässt sich Hatari auch darüber nicht erkennen.

Ein Beispiel zur Nutzung von NatFeats findet sich unter https://git.tuxfamily.org/hatari/hatari.git/tree/tests/natfeats.
« Letzte Änderung: Fr 07.06.2019, 08:38:40 von czietz »

Offline Petari

  • Benutzer
  • Beiträge: 128
Re: Emulator erkennen - Funktion wirft beim zweiten Aufruf Bomben
« Antwort #4 am: Fr 07.06.2019, 11:11:27 »
Was Ich sehe ist das im Instrukcion       move    #0x25,-(a7)  size ist nicht specifiert.
Und dann es anfangt von wie assembler (im C compiler) ist eingestellt.
Probiere mit        move.w    #0x25,-(a7)

Und:  Ich finden dieses Weg - sehts als erfunden by Pacifist Autor, und als nicht sehr klug.
Frage ist: wann 'magic' Wert ist nicht eingestellt vor Aufruf, wird Wait Vblank im Emulator retten höcher CPU Registern d4-d7 ? Vielleicht es steht im einige Doc für. Aber haben alle lesen es ?
Sage Ich es, nach sehen jede Menge von schlimm Programmierung. Letzt Beispiel:  D-Day - aufruft Malloc, aber braucht nach das register a0 ohne Rettung, Was wann im neuer TOS v. a0 wechselt im Malloc ?
Besser wurde einfach brauchen niedere d1-d3 .
Es ist nicht wichtig ist es alt oder neu - wann Benutzer kann ausziehen Maximum von Komputer. Und wegen das es braucht sehr viel Zeit, wir sind nur jetzt at Punkt, wann man kann ausziehen max. von Atari ST :-)

Offline Count

  • Benutzer
  • Beiträge: 61
Re: Emulator erkennen - Funktion wirft beim zweiten Aufruf Bomben
« Antwort #5 am: Fr 07.06.2019, 11:27:34 »
Eigentlich interessiert mich nur, ob es sich um Steem handelt, weil hier der 200 Hz-Counter arg ungenau ist. Aber der Hinweis mit den Registern war ein Volltreffer.

Offline Petari

  • Benutzer
  • Beiträge: 128
Re: Emulator erkennen - Funktion wirft beim zweiten Aufruf Bomben
« Antwort #6 am: Fr 07.06.2019, 14:44:15 »
Eigentlich interessiert mich nur, ob es sich um Steem handelt, weil hier der 200 Hz-Counter arg ungenau ist. Aber der Hinweis mit den Registern war ein Volltreffer.
Ich habe nicht erfahren das Timer C, 200 Hz ist ungenau im Steem. Natürlich, es anfangt viel von wie es ist eingestellt. Alle diese verschiedene speed, refresh rate, ++ Möglichkeiten machen es nicht einfach.
Es ist nicht wichtig ist es alt oder neu - wann Benutzer kann ausziehen Maximum von Komputer. Und wegen das es braucht sehr viel Zeit, wir sind nur jetzt at Punkt, wann man kann ausziehen max. von Atari ST :-)