Ce soir, 15 mai 2010, j'ai réussi à dumper 3 nouvelles ROMs sans fer à souder:
* une TI-30X
* une TI-34MV
* une TI-Collège Plus
Comment ai-je fait? Je les ai dumpées à partir des émulateurs TI-SmartView.
Le dumping électronique semblait mal parti...
En effet, la puce ROM (de format inconnu) est cachée sous une grosse goutte d'epoxy sur ces calculatrices.
Faire fondre cet epoxy nécessiterait une attaque par un acide/solvant, ou un chauffage à près de 100°C.
(avec toutes les chances de se blesser, d'endommager la puce ROM, et même la calculatrice...)
Depuis le début, j'étais convaincu que les émulateurs TI-SmartView-Collège-Plus, et TI-SmartView-30X-34MV contenaient les ROMs des calculatrices émulées.
Mais depuis des mois, je n'avais jamais trouvé où...
Les fichiers exécutables binaires, et les librairies dll ne semblaient pas contenir quoi que ce soit qui ressemble à une ROM de calculatrice...
Bref, TI avait probablement crypté/encodé cette ROM...
TI-Cares m'avait déjà répondu que le processeur des TI-30X/34MV/CollègePlus n'était pas un z80, mais avait refusé de donner plus d'informations, prétextant qu'elles étaient confidentielles...
Bref, triple protection: epoxy sur le matériel, encodage/cryptage de la ROM dans le logiciel, et muselière sur TI-Cares... (quoique même sans muselière... pardon, je m'égare
)Cela faisait donc des mois que je fouillais mes dossiers d'installation des émulateurs TI-SmartView, que j'envisageais plusieurs pistes...
Et ces pistes se sont rejointes ce soir! En seulement 2 heures, j'ai obtenu les 3 ROMs.
Où est la faille?
Et bien TI a eu beau mettre des protections partout, et notamment sur l'émulateur... ils ont aussi laissé la clef pour faire sauter cette protection.
En effet, les émulateurs sont développés en Java.
Et les dossiers d'installation contiennent les fichiers .class (Java compilé).
Il suffit avec un logiciel d'archivage (WinRAR) d'ouvrir "emuCollege.jar" ou "emu30X34MV.jar".
Les fichiers .class qui nous intéressent sont alors situés dans "cometiepsemu".
Plus précisément, nous intéressent les fichiers "TIEmulator3034.class" et "TIEmulatorCollege.class".
Ceux qui connaissent le Java, savent qu'il est très facile de décompiler un fichier .class, pour réobtenir le fichier source .java.
Après analyse, bien sûr, on se rend compte que ces fichiers ne contiennent pas la ROM, ni aucun des autres fichiers .class du dossier d'ailleurs.
(encore une protection de TI)
Mais... ces fichiers récupèrent la ROM, via une fonction native externe (encore une protection...).
Cette fonction se trouve dans les fichiers DLL dont le nom est précisé dans le code source.
Dans "TI30X34MVEmulator.dll":
* void CommunicatingWithC30(int[]) décode la ROM de la TI-30X
* void CommunicatingWithC34(int[]) décode la ROM de la TI-34MV
Dans "TICollegeEmulator.dll":
* void CommunicatingWithC(int[]) décode la ROM de la TI-College Plus
Ces ROMs sont récupérées dans un tableaux d'entiers de taille 65536.
On pourrait donc penser à une ROM de 64Ko...
Mais en fait après analyse, les entiers peuvent être largement supérieurs à 255 (8 bits).
Ils restent toutefois strictement inférieurs à 65536 (16 bits).
Donc chaque case du tableau stocke en fait 2 octets.
La ROM semble faire 128Ko (comme sur les TI-82 et TI-85!!! impressionnant pour un modèle non graphique
)Une simple modification des fichiers .java cités ci-dessus, avec amputation de tout le code superflus, permet d'écrire le contenu de ce tableau d'entiers dans un fichier.
Et voilà... TI s'est crevé à mettre 34 protections partout...
Mais nous a gentillement laissé le code source qui contourne ces protections!!!
Les messages système sont visibles dans les fichiers générés, ce qui est bon signe pour la validité de la ROM.
Les 3 ROMs semblent très similaires: les TI-30X/34MV/CollègePlus utilisent donc la même architecture.
Chaque fichier fait 128Ko.
Toutefois, le code utile fait un peu moins de 64Ko.
Après, il y a une série de caractères "CD" qui franchit la barrière matérielle des 64Ko... plus une série de "00" jusqu'à la fin du fichier.
On peut donc hésiter sur le matériel entre une puce ROM de 64Ko et de 128Ko.
En tous cas, je confirme que le code de ces fichiers n'est pas "visible" dans les DLL.
Il est donc bien encodé ou crypté.
Regardez un petit aperçu:
Maintenant, il y a quelques questions à se poser...
De quel type de langage assembleur s'agit-il ? . . .
z80 ? Autre langage connu? Propriétaire?
Je n'ai lu qu'en diagonale, mais cela ne m'a pas l'air d'être du z80...
De plus, les fonctions de DLL organisant les octets par paires, il pourrait bien s'agir d'un processeur 16 bits...
Et si c'était la saleté de processeur de la TI-80 ?
Et aussi, il convient de se demander si il s'agit bien de la ROM originale des calculatrices, ou si elle a été partiellement ou totalement modifiée pour l'émulation...
Le problème est posé... il reste à trouver des gens capables d'analyser ces fichiers.
Des volontaires?
Edit: Une décompilation du fichier "comtiepsngiexamcalcemucoreProcessorCoreT4x.class" laisserait supposer qu'il s'agit d'un processeur de la famille T4x, plus précisément un T49.
En effet, beaucoup de fonctions présentent ce suffixe.
Problème, totalement inconnu sous Google... Ou alors je me suis complètement planté.
Une lecture plus attentive du code nous apprend que le processeur dispose de 64 registres, et bien d'autres choses...
Petit extrait du squelette du processeur:
Show/Hide spoilerAfficher/Masquer le spoiler
package com.ti.eps.ngiexamcalc.emucore;
import java.util.logging.Logger;
public class ProcessorCoreT4x
{
private static final Logger LOG = Logger.getLogger("Calculator");
long CycleCount;
public int SP;
public int PC;
public int[] Register = new int[64];
public Timer[] m_pTimer = new Timer[2];
boolean BRegAcc;
public int[][][] DRamArray = new int[16][16][16];
public int[][][] WRamArray = new int[4][16][16];
public int KeyBuff = 255;
public int KeyBuff1 = 255;
public boolean CEErr;
public boolean f_in2ndmode = false;
public int PCOnKey;
public int PCKeyin;
public int PCTimer1;
public int PCTimer2;
public int PCDMA;
public int PCLCD;
public boolean benchmarking = false;
public boolean FHALT;
public boolean m_DisplayMode;
public boolean FOnKey = false;
public boolean FTimer1 = false;
public boolean FTimer2 = false;
public boolean FTimer1InterruptEnabled = false;
public boolean FTimer2InterruptEnabled = false;
public boolean FKeyin = false;
public boolean FDMA = false;
public boolean FLCD = false;
public boolean f_updatescr = false;
public boolean f_ChknSetTimerInt = false;
import java.util.logging.Logger;
public class ProcessorCoreT4x
{
private static final Logger LOG = Logger.getLogger("Calculator");
long CycleCount;
public int SP;
public int PC;
public int[] Register = new int[64];
public Timer[] m_pTimer = new Timer[2];
boolean BRegAcc;
public int[][][] DRamArray = new int[16][16][16];
public int[][][] WRamArray = new int[4][16][16];
public int KeyBuff = 255;
public int KeyBuff1 = 255;
public boolean CEErr;
public boolean f_in2ndmode = false;
public int PCOnKey;
public int PCKeyin;
public int PCTimer1;
public int PCTimer2;
public int PCDMA;
public int PCLCD;
public boolean benchmarking = false;
public boolean FHALT;
public boolean m_DisplayMode;
public boolean FOnKey = false;
public boolean FTimer1 = false;
public boolean FTimer2 = false;
public boolean FTimer1InterruptEnabled = false;
public boolean FTimer2InterruptEnabled = false;
public boolean FKeyin = false;
public boolean FDMA = false;
public boolean FLCD = false;
public boolean f_updatescr = false;
public boolean f_ChknSetTimerInt = false;
)
top#: 
