DCAlice, un souci en mode MC10 et Alice 4k

[Carl]

Daniel, je viens de tester un jeu pour Tandy MC10 sur VMC10 et pas de souci ( +16k de ram)

Battlot.jpg (22.63 Kio) Consulté 669 fois

Battlot2.jpg (49.29 Kio) Consulté 669 fois

Sur Dcalice, en mode MC10 ou Alice 4K (+16k), intro ok puis plantage...?

DCalice.jpg (10.29 Kio) Consulté 669 fois

battlot (mc10).7z

(6.37 Kio) Téléchargé 8 fois

Le hard reset n'est pas suffisant !

Carl

[Daniel]

Merci Carl d'avoir signalé le problème.
C'est un beau bug, probablement une anomalie dans la gestion de la pile système : un sous-programme ne revient pas à la bonne adresse.
La cause n'est pas facile à trouver car ce sous-programme est très compliqué, il en appelle de nombreux autres.
Je vais chercher mais je ne promets rien...

[hlide]

Ce jeu a peut-être été codé en ASM8 et Cate (sorte de C), alors j'imagine que le lecture du code ne doit pas être facile mais avec un peu de chance, il y a aussi le source. Reste à savoir si le code incriminé est dans la partie assembleur ou la partie pseudo-c.

[Carl]

Hlide, pas vu de source...
http://inufuto.web.fc2.com/8bit/battlot/

Carl

[hlide]

Alors cette version prédate la période où il s'est mis au ASM8+Cate. Bon ben à la dure.

[Daniel]

Le bug est dans l'émulateur, pas dans le jeu. Les sources n'apporteraient rien de plus.
La difficulté est de localiser et d'identifier le problème. C'est long et difficile. Toute aide sera la bienvenue.
Je suppose que le jeu a été testé sur la vraie machine et fonctionne. Avez-vous vérifié ?

[Carl]

Daniel, pas de souci avec Alice 4k + 16K Ram

thumbnail_IMG_3912.jpg (79.85 Kio) Consulté 529 fois

thumbnail_IMG_3913.jpg (81.57 Kio) Consulté 529 fois

Carl

[Daniel]

Carl, merci pour le test. De mon côté j'ai continué la recherche du bug et je viens tout juste de le trouver.
La cause du plantage est l'envoi intempestif d'une interruption IRQ1 par dcalice.
Ce bug est très vieux, déjà présent dans la version dcmicrocolor du 06/08/2008. En seize ans il n'a pas été découvert !
Heureusement Carl voit tout. Merci encore pour le signalement.

Nouvelle version de dcalice :

dcalice_20240303.zip

(137.5 Kio) Téléchargé 24 fois

Dans les jours qui viennent je mettrai la nouvelle version en ligne (site dcalice).

##.png (896 octets) Consulté 503 fois

[Dominique]

@Daniel,
je n'ai pas d'antivirus spéciaux, sauf la protection habituelle Windows et il refuse de télécharger sur Opéra.

[Daniel]

L'analyse avec VirusTotal montre que 4 antivirus sur 64 considèrent dcalice comme une menace.
Ce sont évidemment de faux positifs. Les antivirus sont une véritable plaie.
C'est probablement le contenu de la ROM Alice qui déclenche leur fureur. J'ai le même problème avec mes émulateurs Thomson.

virustotal.png (26.46 Kio) Consulté 477 fois

[Dominique]

OK.

J'ai fini par désactiver la protection puis la remettre.

[Daniel]

La version dcalice 2024.03.04 a été diffusée sur le site http://alice32.free.fr/

Il y a deux petites améliorations par rapport à la version 2024.03.03 :
- En mode Alice 4K, la petite bande noire en bas de l'écran est remplacée par la couleur de bordure
- Dans l'outil de mise au point les différents modes d'exécution sont accessibles directement par bouton poussoir

Le contrôle du fichier zip avec VirusTotal donne toujours quatre faux positifs sur 64 antivirus. Je ne sais pas si c'est à cause de la ROM Alice ou à cause de la compression UPX. A l'occasion je modifierai le zip pour ne plus avoir de positifs. Ce n'est pas facile car d'un jour à l'autre les résultats changent, dans un sens comme dans l'autre.

[EDIT1]
Nouveau test avec VirusTotal sans compresser dcalice.exe avec UPX. Il n'y a plus qu'un seul faux positif.
Donc trois faux positifs sont provoqués par UPX et un par les ROMs des ordinateurs.
Il faudrait enlever les ROMs, mais je refuse de le faire. Les utilisateurs ne sauront pas les trouver.

Une autre solution serait de protéger le fichier .zip par mot de passe. J'ai essayé, il ne détecte plus aucune menace, par contre l'antivirus du PC le bloquera lors de la décompression. Ce n'est donc pas une bonne parade. Comprenez-vous pourquoi je n'aime pas les antivirus ?

[EDIT2]
J'ai voulu ruser en mettant le fichier .zip dans un autre zip (double compression). Je me disais que ça pouvait masquer le faux positif. A ma grande surprise ça ne masque rien, au contraire, ça ajoute un deuxième faux positif

[Carl]

Merci Daniel pour cette nouvelle version !
Carl

[Pocket]

Salut,

Et chiffrer/déchiffrer la ROM avec un simple XOR, ça pourrait changer quelques chose au niveau des antivirus ?

A+

[__sam__]

Probablement pas. Ils se basent sur la présence d'une certaine suite d'octets dans un exe (une signature) pour heuristiquement déclarer l'exe vérolé.

Or si cette signature est courte, elle peut apparaitre dans des exe ayant de grosses quantité de données, cryptées ou non qui sont assimilables à du bruit. Plus la signature est courte par rapport à la taille des données embarquées, plus la probabilité d'apparition est forte.

Par exemple avec 64k de données aléatoires,

• une signature de 1 octet apparaitra en moyenne 65536/256 = 256 fois -> ca n'est plus une probabilité, c'est une certitude: l'exe contient plusieurs fois des traces du virus ! mais bon une signature de 1 octet c'est pas pertinent
• une signature avec 2 octets ca l'est déjà plus. Elle n'apparaitra en moyenne qu'une fois seulement (65536/65536). Hélas une fois suffit à déclarer l'exe vérolé.
• une signature de 3 octets apparaitra en moyenne par hasard 1 fois toutes les 256, soit environ 0.5%. C'est très petit, presque négligeable.
  Si cette signature est présente on a plus de 99% de "chance" que ce ne soit pas le fruit du hasard
• avec 4 octets, la proba pour que la signature apparaisse encore est 256 fois plus petite. Sacrée malchance !

On est sauvé alors ?

Oui mais.... dans un anti-virus il n'y a pas qu'une seule signature qui est vérifiée mais une tétrachiée. En fait, plus il y a de signatures dans l'anti-virus, mieux il est coté certes; mais plus la proba que l'une d'elle figure dans des données aléatoires est forte aussi. Ca joue contre eux

En effet prenons le cas d'un anti-virus qui a disons 1000 signatures de 3 octets qui analyse 64k de données. On a vu que la proba qu'une signature particulière figure dans le fichier est de 1/256, ce qui veut dire qu'il y a 255/256 chances qu'elle n'y figure pas (99.6%). Donc, la proba pour qu'aucune des 1000 signatures ne soit trouvée est de (255/256)^1000 = 2%. Ce qui veut dire que dans 98% des cas, au moins une des 1000 signatures sera retrouvé dans les 64k de données aléatoires, autant dire quasiment tout le temps.

Alors bien sur, les signature d'un antivirus ne font pas 3 octets mais peut-être 128 octets (et on peut déjà faire des trucs avec si peu) et leur database ne se contente pas de 1000 entrées, mais peut-être de 10 000 000 voir plus. Mais le résultat sera le même: la proba de trouver une correspondance dans une grosse zone de données aléatoires sera loin d'être nulle. Le faux-positif rôde (je laisse faire le calcul aux amateurs de probas).

Un fichier aléatoire aura toute les chances d'être déclaré vérolé quand on se base sur le principe des signatures. C'est contre-intuitif, mais c'est le même genre de contre intuition que celle du paradoxe des anniversaires. Le principe des signature a des limites et les faux positifs sont très très nombreux. Leur spécificité est notoirement faible.

En fait plus la donnée à analysée est aléatoire, plus l'approximation ci-dessus est réaliste. Ce qui sauve les anti-virus de la faillite totale, c'est que les exe, généralement parlant, n'embarquent pas tellement de données aléatoires mais des trucs bien organisés à l'entropie relativement faible. Cela réduit drastiquement les probas de correspondance par rapport à du bruit. Par contre on a pas de bol, les ROMs compressées (ou cryptées) sont une énorme source d'entropie et les programmes en contenant sont très susceptibles de contenir l'une des millions de signatures de virus.

Ce qu'il faudrait serait d'externaliser les ROMs dans des fichiers binaires à coté de l'exe de sorte que l'émulateur ne contienne plus que du vrai code, nettement moins aléatoire. Les fichiers externes n'étant pas exécutables, ils ne seront pas analysés, et l'exe contenant peu d'aléatoire (s'il n'est pas lui-même compressé) ne matchera aucune signature non plus.

Mais ca veut dire que ce sera fini l'émulateur 100% autonome copiable d'un dossier à l'autre sans trimballer derrière lui une ribambelle de fichiers de ROM comme tant d'autres. Mouais bof