FORUM JudgeHype

Résumé de l’épisode précédent
Avant de commencer une nouvelle routine, il est important de voir ce que nous savons depuis la dernière fois.
 
Mécanismes
Nous avons appris que le MF des suivants était ajouté à celui du maitre s’ils sont les tueurs.  
Il est possible de savoir si le MF s’applique dans n’importe quelle hypothèse de Drop. Et en plus de savoir combien nous avons de MF Réél.
Une autre question à laquelle on peut répondre est
Si j’ai 2 armes avec du MF. Les 2 bonus s’appliquent-il ou seulement celui de l’arme qui a donné le coup final ?
Plus compliqué ? La même question avec 2 armes, Si on laisse mourir le monstre du poison ? Je ne connais même pas la réponse
 
Assembleur
On connaît les opérations basiques et les tests. Je ne les reprendrais pas ici
 
La structure des routines.
 En 1.11 elles sont entourées par le compilateur de section non codantes les INT3 qui sont des spaceurs.
 En général elles récupèrent leur paramètres sur la pile. Et retourne le résultat dans EAX.
 
On sait à partir de ItemStatCost.txt et des breakpoints trouver les fonctions qui utilisent les caractéristiques d’un personnage.
Pour le MF on cherche PUSH 50.
 
Autre Exemple de recherche
Si vous Cherchiez PreventMonsterHeal il faut chercher PUSH 75 (itemstatcost ID de PMH) --> 4 résultats :
- Le premier n’a pas le bon format
- Pour le deuxième on peut lire Source\Game\AI\AiBaal.cpp On devine facilement que la routine en question traite de l’intelligence artificielle de Baal. C’est au passage une autre méthode de recherche de code que de parcourir D2Game.dll à la recherche de ces messages.
- Le troisième n’a pas le bon format non plus
- Le dernier a le bon format. Il utilise bien la même fonction (10537) et en plus c’est la bonne fonction
 
Ca ne fonctionne pas pour toutes les caractéristiques. Mais c’est souvent par la que je commence.
 
 
Structure du jeu
On sait que les monstres et joueurs sont des unités.
Que ces unités sont accessibles par des pointeurs. Et qu’à des position fixes on trouve des informations sur ces unités
En +00 on a l’unitType. 0 = Joueur 1=Monstre
En +04 on a l’UnitClass. Pour les joueurs c’est dans PlayerClass.txt (Avec Amazon = 0) pour les monstres c’est l’ID dans Monstats.txt
En +0C on a le numéro unique pour chaque type d’unité qui est l’ordre de création.
 
On Connaît 3 Fonctions
D2Common 10537 qui retourne dans EAX la valeur d’une caractéristique (stat) pour une unité.
3 paramètres poussés sur la pile (je donne ici l’ordre des PUSH, c’est pas forcément la convention adoptée par tous :lol : )
- L’étendu 0 pour tous Base + item + …
- La stat = ID Dans ItemStatCost.txt
- Le pointeur sur l’unité à tester.
 
D2Game.009A8D40 qui retourne dans EAX soit 0 soit le pointeur de l’unité MAITRE
 
D2Game.009FEB30 celle du topic précédent qui retourne dans EAX le MF = MF Tueur + MF de son maitre
 
Pour les Unités et les Fonctions. Il est important de constituer un catalogue un fichier de référence … tout ce qui peut vous servir pour gagner du temps la prochaine fois que vous les rencontrerez.
 
 
Trouver la fonction
 
Maintenant nous allons voir une nouvelle fonction. Celle ou nous sommes retournée à la fin de la fonction de calcul du MF.
On revient en plein milieu de la fonction. La 2 choix s’offrent à nous.  
1) Soit on continue à partir de la ou l’on revient.  
2) Soit on reprend la nouvelle fonction depuis son commencement.
 
Comme on veut voir le drop dans son ensemble, on va revenir en arrière. Mais à force on remonterait jusqu’à la mort du monstre, ce qui ne présentera plus d’intérêt et il sera temps alors de continuer dans l'autre sens pour voir la détermination des propriétés de l’objet.
 
OK Identifions la nouvelle fonction elle commence en 9FEF60 pour moi (juste après la série de INT3) et se termine en 9FF2DA
OK Je place un breakpoint en 9FEF60 Et je part tuer du monstre.
 
Nous avons de la chance, la fonction étant linéaire nous pourrons la suivre comme la première de la première à la dernière instruction.
 
Je vais la découper par méthode, c’est plus important de voir comment je fais , que de voir le résultat qui pour l’instant est assez connu.
 
L’assembleur? Pour quoi faire
 
Commençons par le code
Le voici  

 
Ce que vous devez savoir avant de commencer (dorénavant CQVDSADC)
Comment commence les fonctions ?
Le nombre de registres étant limité, et ces registres étant réutilisés d’une fonction à l’autre il faut les sauvegarder au départ puis les restaurer à la fin.
 
On commence par faire de la place sur la PILE.
ESP est le pointeur indiquant la position de la pile.
 
Il suffit de soustraire X a ESP(SUB = Substact = Soustraire) pour faire X place. --> Instruction SUB  ESP, X
Ensuite on sauvegarde les registres sur la pile avec des PUSH
Le reste (Opération MOV (pour move)) on connaît déjà
 
L’analyse du code
J’ai laissé les INT3 qui ne font pas partie de la fonction.
Ensuite les 4 instructions c’est la place sur la pile et la sauvegarde de 3 registres qui vont être réutilisés.
Ensuite vient l’unique instructions dont nous avons besoin
MOV EDI,EAX soit EDI = EAX.
 
L’assembleur ne nous apprendra pas grand chose ici.
Ce qui compte ces de regarder les valeurs que prennent les registres et comment ces valeurs interagissent entre elle.
 
Bref dans l'a,alyse d'aujourd'hui pas besoin d'assembleur (d'ou les titres si vous suivez )
 
Construire les références. La base de l'analyse
 
Ici je me retrouve avec un nombre ??? Pour moi 210
Comment deviner ce que c’est ?
 
Par l'hypothèse
C'est très important, c'est souvent tout ce dont on dispose pour commencer.
On se trompe souvent, sans gravité on s'en rend vite compte le moment venu.
 
CQVDSADC
 
Les fonctions n’ont en général qu’une fonction (c’est la définition non). Elles sont généralement écrites pour faire 1 calcul (qui peut être complexe comme dans les formules) ou 1 manipulation.  
Autrement dit on attend un seul résultat (Dans EAX rappelez vous).
Attnetion quand même il y a beaucoup d’exception.
 
Notre Hypothèse.
 
On sait que la fonction dans laquelle nous sommes va demander combien nous avons de MF ?
Vous connaissez bien les mécanismes. Vous savez que l’ordre est  
1) Détermination de l’objet
2) Détermination de la qualité en utilisant le MF.
 
Notre fonction retournait le MF.  
Cette fonction retournerait la qualité de l’objet.  
Celle d’avant retournerait le type d’objet.
 
Je suppose que ce nombre est le numéro qui indique le type d’objet venant comme paramètre de la fonction précédente.
 
Le test
 
Ok je retourne jouer et j’obtient un carquois.
Si mon hypothèse est bonne 210 = Carquois de carreau
 
Je fait plusieurs essais pour valider que.
Un même ID donne toujours le même objet
Un même objet donne toujours le même ID.
 
OK Plusieurs essais donnent:
0x210 = Carquois Bolt
0x211 = Parchemin ville
0x20B = Or
0xF = Sceptre.
0x139 = Armure matelassée
0x20b = OR
C’est bon (ok l’échantillon n’est pas terrible, mais j’ai encore le temps plus tard de voir si mon hypothèse est fausse)
 
Facile à retrouver dans les MPQ.
Mon hypothèse est la suivante
 
0x0xx – 0x132= Weapons.txt -> ID = Ligne - 2 (car le premier objet = HandAxe est en deuxième ligne avec un ID = 0) Exemple Sceptre Ligne 17 = ID 15 (OxF) Ca colle avec ce que j’ai trouvé.  
 
0x132 – 0x1FD = Armor.txt . Idem Ligne + 2 (après avoir retirer 0x132) Ca colle pour mon armure.
 
0x1FE – 2xx = Misc.txt . 0x20B -0x1F3 = 0xF = 15 en décimal Ligne 17 = Or ca colle.
 
C’est pas tout à fait vrai et peut être vous en rendrez vous compte. C’est à cause des objets non activés et/ou spéciaux. Je vous laisser découvrir les raisons de sauts de ligne tout seul  
 
Moralité Weapons.txt Armor.txt et Misc.txt donne une seule et même liste en mémoire. Notre ID est bien l’ID de l’objet dans cette méga liste.
Je l’appellerais désormais WeapArmoMisc.bin
 
 
Henkô No Jutsu
 
Place maintenant à LA METHODE que je préfère entre toutes (et pour laquelle l’assembleur ne m’apporte rien en tant que langage, oui oui j’insiste)
Pour garder la référence, je dirais même que c’est ma voie d’ollydebuggueur
 
CQFSADC
Un peu d’ollydbg. On peut modifier n’importe quelle valeur (Registre Pile Mémoire..) en se plaçant dessus puis en cliquant droit / Modify
Ok Ca suffit pour ce que l’on va voir.
 
Analyse
Pas besoin de code, réutilisons la dernière ligne de la section précédente.
 
Revenons sur ce que nous venons de faire.
Compter sur le hasard pour tomber 2 fois sur le même objet c’est long, même si avec l’ID 0x20B (l’or) c’est assez fréquent
 
C’est la que la technique de modification rentre en compte. Pour valider mon hypothèse et même plus.
Juste après la ligne MOV EDI,EAX. Je peux modifier EDI et mettre la valeur de mon choix.  
Si je transforme EDI en 210 je dropperais toujours un carquois de Bolt ?
 
Même mieux je pourrais tester les valeur de EDI de 1 à 500 et écrire la liste obtenue.
Pour diablo2 ce n’est pas la peine, car les listes sont déjà disponibles dans les MPQs il faut juste les identifier (on vient de le voir avec WeapArmoMisc.bin)
 
Place à la pratique
Comment ? Je me place sur le registre EDI / Bouton Droit / Modify et je rentre la valeur que je veux. 210 pour tester mon hypothèse
ET la rien
Franchement vous croyiez que c’est si facile
Ce n’est pas que je fasse le malin mais j’ai décidé de décrire ce que j’ai fait, même mes erreurs.
OK C’est un Fiasco. Et pourtant EDI contient bien L’ID de l’objet.
 
Ce qui indique que ce n’est qu’un copie de la véritable variable. Et probablement mon hypothèse selon laquelle la fonction appelant et celle qui est chargée de déterminer le type d’objet est fausse. On verra bien plus tard.
 
Rien n’est perdu. Rappelez vous.
Comme je l’ai indiqué, le nombre de registre pour contenir les variables est très restreint. On a vu que l’on pouvait les pousser sur la pile au moment ou on commence la fonction. Mais on peut également les sauver sur la pile ou ne mémoire ou dans une unité à d’autre moment.
 
Regardons.
OK J’ai de l’or 0x20B dans EDI. J’ai aussi 0x20B sur la pile en position +48

P.S Pour avoir les position relative il suffit de cliquer sur l’adresse mémoire à partir de laquelle on veut avoir la position relative
 
Et comme vous pouvez vous y attendre c’est toujours le cas.
Ok remplaçons sur la pile le 20B par 282 et vous obtiendrez le drop d’une Rune ZOD. Et oui autant voir les choses en grand
 
Au passage pensez quand même à changer les 2 valeurs (EDI + Pile) en effet il y a un risque si on remplace une épée par la rune SOD que notre routine renvoie Epée Rare alors que la ZOD ne peut pas l’être (rare).
 
 
Remarques
 
On a encore appris beaucoup de chose sur les mécanismes du jeu et ce pratiquement sans assembleur (Juste 4 ligne et encore pas directement)
C’est la moralité du jour.  
Le plus important n’est pas l’assembleur mais les DONNNEES et COMMMENT ELLES SONT TRAITEES.
C’est la compréhension du contenu des variables (qu’elles soient représentées par un registre, un dword sur la pile, une zone mémoire, une position +XX dans une unité), de leur interaction.
Pas besoin de comprendre les mécanismes complexes en assembleur de comment le système d’exploitation lit les fichiers. Notre compréhension de l’assembleur doit se limiter à comment on traite les données et souvent c’est de l’arithmétique d’école primaire. Jusqu’à présent nous avons vu  
 A est Négatif , Nul ou Positif
 A est plus grand ou plus petit ou egal = B
 A = B
 A = A + B
Et regarder tout ce que cela nous permet de savoir.
 
Ne nous leurrons pas Sans l’assembleur nous n’irons pas loin, cela reste indispensable, mais pas besoin de savoir programmer ni d’être un expert en assembleur pour faire ce que je fais ici (D’ailleurs je ne pense pas en être un d’expert )
 
C’est la conclusion du jour. N’ayez pas peur de suivre ce topic et les suivants, s’il vous manque des notions d’assembleur, ce n’est pas essentiel pour comprendre.  
Même si je le répète je me doute bien qu’il faut avoir un bon niveau de base en informatique pour suivre, donc pas d’inquiétude si vous ne pouvez pas suivre, chacun son domaine.
 
Publicité
Enormément de blabla dans ce topic. Désolé.
Dans le prochain nous verrons plus de ligne de code et encore des nouvelles techniques (dont identifier le parcours des fichiers .bin) et je le promet moins de blabla
 
Revenons sur ma technique préférée (Celle de modification/ Altération)
Elles est universelle et est la base que j’utilise quand je ne connais pas du tout le programme.
Avec diablo2 c’est facile, les listes sont déjà faites (les MPQs) pour les autres jeux c’est assez rares. Remplacé un ID en le faisant varier de 1 à XXX et en regardant le résultat vous permettra de construire l’équivalent des MPQs pour tous les jeux.
 
La modification peut être utilisé pour des choses aussi variées (du moment que vous avez les outils) que  
 
- L’ouverture d’un coffre à Gauntlet II sur CPC464
- Le pokémon rencontré dans les herbes hautes sur GBA (En plus avec l’ID du pokedex c’est du gateau)
- Le contenu de la caisse explosée à coup de pied de biche dans HalfLife2
J’espère que vous aimez mes références
 
Mon exemple de la ZOD est très mauvais, le but n’est évidemment pas de tricher même quand il n’existe pas d’éditeur (même si c’est si facile avec ollydbg) mais bien de construire les listes et fichiers de référence qui vous donnerons la base pour suivre les varaibles.
 
La suite bientôt dans ce même topic. Je changerais de topic seulement pour changer de fonction.
En attendant jouer avec la technique de modification. Essayez de comprendre WeapArmoMisc.Bin. J’ai fait exprès d’écrire quelque chose de faux à son sujet.
 
Autre endroit ou utiliser la technique de modification.
Dans la routine de calcul du MF. Remplacez le 50 sur la pile (celui de la fonction 10537) par l’ItemStatCost ID d’une autre caractéristique pour lire les différentes valeurs de vos skelettes par exemple (leur niveau, leur force, leur AR, Leur Défense, Leur Dégat, leur fastCast …). C’est bien meilleur que tout les calculateurs du monde ( si ca c’est pas de la bonne pub)
Et comme d'ahbitude. Si vous trouvez n'importe quel type de résultat (même la force des golems) je suis preneur et vous remercie d'avance.

Salut Myrdinn!  Bon déja chapeau pour le boulot j'hallucine toujours en voyant comment D2 est décortiqué j'avais jamais vu ca pour un jeu!  
 
J'ai pas tout lu parce que casiment tout ce que tu raconte me dépasse completement mais j'ai regardé en diagonale et quelque chose m'a paru bizarre:
 

 
ce serais pas plutot ID = Ligne - 2 ?
 
tient je viens de voir ca en tapant d'ailleurs :
 

 
Ce serais pas ca?
 

---------------

Tradelist hype  
GW: Jesper Friden - Heal Arante - Agna Friden - Labyala Fiend
 

Je soupçonne fortement que Weapons.bin ne soit pas en premier lors de la fabrication de "WeapArmoMisc.Bin" (bon il faut encore que je vérifie)
 
Edit : OK il faut lire, c'est marqué explicitement que l'ordre est Weap, Armo, Misc. Un gage pour Ulmo
 
Par contre il y a une erreur de calcul sur le nombre de ligne de Armor.bin, suivie d'une soustraction fausse pour retomber sur la bonne ligne pour l'or.

Merci pour les encouragement. Pour mener ce projet à terme il me faudra probablement plus de 300 heures de travail.
 
Pour la petite histoire. J'ai mis ce que j'avais noté en premier pour WeapArmoMisc.
Il faut que je montre que souvent mes hyptothèses sont fausses, ou partiellement inexactes.
Pourtant mon modèle semblait collez avec mes résultat (LA preuve que mon échantillion initial était trop faible )
 
De plus j'ai trouvé assez interessant de vous laissez me corriger (je préfère quand même l'indiquer, des fausses légendes font croire que je saurais tout, j'ai peur d'être cru à la lettre, non mais) , c'est bien plus formateur que vous donnez les résultats tout fait.
 
Le ligne - 2 par  contre j'en était même pas conscient, une de mes erreurs d'étourderie habituelles

J'ai remanié le topic, cependant je ne suis toujours pas satisfait du résultat. On verra cela plus tard.
Je retourne désassembler la suite pour écrire quelque chose de cohérent

OK Il est temps de reprendre un peu de code et notre belle routine de détermination de la qualité (ca reste une hypothèse que l’on va confirmer aujourd’hui)
 

 
CQVDSADC
Rien vous êtes des champions.
 
L’analyse
Rappelez-vous. EDI Contient l’ID dans WeapArmoMisc.bin. Appelons le Item ID
Rappelez vous surtout que les PUSH en plein milieu d’une routine, c’est généralement pour passer un paramètre à une fonction (alors qu’en tout début c’est pour la sauvegarde du registre)
On aura bientôt un call fonction XXXX(ITEM ID)
 
MOVE EBX,ECX. Vous connaissez EBX=ECX. Encore un paramètre non passé par la pile.
Nouvelle variable qu’il nous faut deviner.
Si je fais varier EBX, je ne vois pas de différence notable !!!
Bref il va falloir trouver un autre moyen.
 
Il faut établir une liste en jouant
Comme nous n’en avons pas besoin aujourd’hui je vais vous mettre sur la piste.
Allez faire des drops (il faut jouer de temps en temps ca fait du bien) et noter le résultat. Pour cela
 
Allez jouer en Nightmare, choisissez un coin que vous aimez particulièrement et regarder ce qui se passe (a mon avis il va falloir jouer beaucoup)
Tous les drops donnent toujours la même valeur.
Sauf pour les champions ou la valeur est augmentée de 2 et les boss uniques ou la valeur est +3.  
Maintenant notez également le résultat avec les coffres /Rack ….
Avec ça si vous trouvez pas pour la prochaine fois
 
Bon la suite
 
Accès aux fichiers des MPQs
 

 
CQVDSADC
Coté assembleur vous connaissez presque tout.
Juste une petite explication sur la première ligne.
Vous avez appris ce qu’étais un pointeur et comment il permettait d’aller voir des positions relative sur l’unité qu’il pointe.
La pile c'est un peu comme une unité, elle est référencée par un pointeur. C’est toujours le registre ESP et il ne sert qu’à cela (nous l’avons vu au début). Et pour modifier une valeur de la pile on utilise le pointeur et la position relative.
MOV DWORD PTR SS:[ESP+10],0
MOV A,B => Copier B dans A on a déjà vu.
Faite pas trop attention à la nomenclature, je ne veux pas que l’on accorde trop d’importance à l’assembleur ici.  
Jusqu’ici on copiait la valeur d’un registre dans un autre.
Ici = A = DWORD PTR SS :[ESP+10] et B=0
 
Comme ce n’est pas un registre (dont la taille est connue DWORD pour les Registre E(extended)XX) il faut indiquer la taille ici DWORD également (32 bit ou 4 Bytes)
On change la valeur en position 10 sur la pile (DWORD mets à zéro les position 10 11 12 et 13 )  
 
L’analyse
A chaque fois que je modifie la pile, je fais une “photo”  
C’est important car la pile sert de stockage à de nombreuses informations qu’il est impératif d’identifiées et de suivre.  
 
Pile après ma modification
$ ==>    > 00000210 Id dans le .bin (Le push en attente pour la fonction)
$+4      > 00000000 ??
$+8      > 0000001C ??
$+C      > 0731E800 Mster Ptr (le tué par opposition au tueur de l’autre fonction)
$+10     > 00000000 On vient de le mettre à 0
$+14     > 00000001 A vous de me le dire
$+18     > 00A024E1  RETURN to D2Game.00A024E1 from D2Game.009FEF60
 
On pourrait deviner les DWORD en +04 et en +08.  
Comme ce sont les sauvegardes du départ, nous n'en avons normalement pas besoin.
Si vous essayez de deviner (par essai ou par substitution je suis toutes ouïes)
 
 

Vous avez le niveau pour comprendre tout seul ces 2 lignes
On récupère le résultat de la fonction dans EAX et on le copie dans ESI.
2 solutions.
Soit on trace la fonction 10262.
Soit on regarde le résultat dans EAX et on essaye de deviner
 
Commençons comme d’habitude par le plus simple
Dans EAX je récupère un pointeur. Regarder la zone mémoire autour vous n’aurez aucun mal à reconnaître WeapArmoMisc.bin en mémoire. En plus si je regarde en mon pointeur pour ID210 je trouve le code ASCII flpqvr (Graphisme de drop des carquois et oui je suis le roi du drop de carquois et en plus l'ID 210 que j'ai passé est justement Carquois).
OK Hypothèse, cette fonction retourne le pointeur sur la ligne dans WeapArmoMisc.bin correspondant à l’objet (identifié par son ID)
Pour le moment cela me suffit. Pas besoin d’aller chercher des mécanismes complexes en assembleur pour savoir comment on fait pour aller chercher la bonne ligne. (Moi j’aime le faire mais c’est une autre histoire)
 
Donc D2Common.#10262 (ItemID) = PtLine (Weapon / Armor / Misc .bin)
 
Continuons

 
Je vais le faire cette fois ci encore mais normalement vous savez tout faire
JNZ (Jump Not Zero) c’est l’inverse de JE (Jump Equal)
TEST ESI avec lui-même => Négatif Nul ou Positif ????
 
Conclusion ? Si Non Nul (<=> Positif ou Negatif <=> Existe) alors on saute à la section suivante. Autrement dit si la ligne n'existe pas on ne continue pas la routine. Dans ce cas le jump n’est pas pris et on arrive à une procédure de sortie
 
Une sortie c'est comment ?
On a la restauration des 3 registres du départ (Les 3 PULLs),  
l’ajout à la pile pour la remettre comme au départ (ADD ESP,8)
et le retour RETN10.
 
N'oubliez pas le rôle de la fonction c'est de retourner un résultat ici c'est 0 (XOR EAX,EAX)
 
Validation du role de la fonction
 
Il est temps de reprendre le Henkô No Jutsu pour prouver l'hyptohèse par laquelle j'ai commencé cette troisième partie.
 
Choisissez votre objet (Epée Dague Anneaux …) comme vu dans la partie 2 (en modifiant sur la pile)
Avant de tester ESI avec lui-même transformez le en 0 pour amorcer la procédure de sortie.
Au lieu de retourner EAX= 0, modifier EAX en 0,1,2,3,n… jusqu’à 7 et regarder le résultat.
 
2 choses à en retenir.
1) La procédure retourne bien la qualité dans EAX
2) Vous devez être capable de faire la liste Qualité = Nombre
1 = Qualité normale
2 = Qualité magique
…
4 = Rare
…
Attention d’avoir un ILVL suffisant pour les uniques et sets (normalement vous savez déjà ou regarder et modifier si besoin)
 
C’est le moment de faire une pause et de vous laissez répondre aux questions et listes.
La suite est déjà prête, faite moi signe On reparlera de la fonction 10262 et de son résultat qui ne sont qu’une hypothèse pour le moment.  
On verra surtout plus de détails sur les fichier MPQs et quelques astuces et méthodes (by Myrdinn) sur leur utilisation

 
 
Bon pour l'instant j'ai lu que la première partie et j'arrive à m'accrocher    
 
Mais y a quand même un truc qui me chiffonne.
 
La pile, c'est bien la liste des actions qui attendent d'être faites?
Donc quand tu voit que le monstre va te donner un carquoi, c'est que le jeu a déjà calculé ce qu'il va te donner, qui il me semble, est calculé au moment de la mort du monstre.
 
Donc dans ce cas là, tu peux pas changer le nature du drop puisqu'il te lache les objets au moment de sa mort justement    
 
Donc deux solutions :  
Soit tu freeze le jeu au moment de la mort du monstre, soit tu revient en arrière sur les actions qui se sont passée avec ton débuggeur, auquel cas tu peut rien changer puisque l'action s'est déjà déroulée dans le jeu...
 
C'est un peut confu mon post là
 
Enfin si quelqu'un a compris ce que je comprend pas...

---------------

5 ans de solo, 2 ans d'arrêt, reprise HCL5
Liste de (non) drops HC solo avec  screens des persos // Testez le faucheur en HC // Présentation du Faucheur // WW-sin PvM

Très bon début.
 

Non ça c'est la pile de MAgic The Gathering
En informatique considère cela comme une zone mémoire particulière.
Elle permet de stoquer des valeurs rapidement et à cour terme.
On l'appelle pile à cause du FILO (First In Last Out (EDIT Merci Bygirz pour la correction) - Premier rentré dernier Sorti) Comme une Pile d'assiette tu réutilises en premier la dernière que tu as posée.
Dans le cas de diablo2, elle permet  

• de stoquer des valeurs jusqu'à ce qu'elles soient utilisées
• De passer rapidement des valeurs d'une fonction à une autre (on l' a dejà vu)
• A héberger des structures temporaires
• Tout ce qui est fonctionnement assembleur (l'adresse de la fonction appelante, sauvegarde temporaire des registres de la fonction appelante ...)
• ...

Bref de la mémoire et non une action
 

Tu as tout compris. Il a calculer qu'il va me donner un carquois, mais il ne sait pas encore de quelle qualité, c'est justement la ou on l'a arrêté
 

 
Oui je freeze le jeu au moment du calcul du drop (un peu plus loin que la mort du monster. C'est le rôle de nos breakpoint (point d'arrêt du jeu soigneusement sélectionné)
On est donc entre la mort du monstre et le drop, au moment ou le jeu est en train de mettre sur la pile (et ailleurs) ce qui va être droppé. Tant que nous n'arriverons pas à la création de l'objet au sol, on peut faire tout ce que l'on veut. Changer l'objet, changer sa qualité ...
 

 
J'espère que mes explications t'aideront à mieux comprendre.
N'hésite pas à me demander quoique ce soit si une partie te semble toujours obscure.

Oui en effet j'ai confondu la pile de Magic avec celle que j'ai vu en info y a 2 ans    
Mais la pile c'est pas plutôt Fist In Last Out? (tu utilise en premier la dernière que t'as posé)
Et les listes en Fist In Fist Out?
 
OK les breakpoints, c'est compris...
 
Allez on s'attaque au 2ème post :
 

 
Vu les indices donné, c'est assez trivial en effet    
EBX contient l'Ilvl de l'objet.
 

 
Aucune idée, je ne vois pas d'indices dans le code...
Mais comme ça ressemble à un booléen, ca pourait être le fair que l'objet soit identifié ou pas dans le jeu
 
 
Pour le reste j'ai pas le programme donc je fait pas  

---------------

5 ans de solo, 2 ans d'arrêt, reprise HCL5
Liste de (non) drops HC solo avec  screens des persos // Testez le faucheur en HC // Présentation du Faucheur // WW-sin PvM

Ah oui FILO Comme quoi je devrais réfléchir avant de d'écrire. Parfait la preuve que tu as très bien compris
 
Non c'est pas un booléen c'est le ILVL que tu viens de trouver C'est même pour cela que j'ai fait une image de la pile après la sauvegarde du ILVL sur la pile.

Bon j'ai relu un peut le post.
 
En fait je comprend pas non plus ce qu'il est censé y avoir dans le DWORD, et donc ce que ça modifie quand on le met à 0...
 
autre chose

 
J'ai la liste des 8 qualités que l'on devrai trouver :
Mauvaise qualité
Normale
Bonne qualité
Magique
Rare
Set
Unique
Craft
 
Mais quand on voit "glaive de mauvaise facture", ou "glaive de facture abimée", ca me fait 2 qualités différentes pour quelque chose qui devrai grosso modo être la même chose (mauvaise qualité) . C'est géré comment?

---------------

5 ans de solo, 2 ans d'arrêt, reprise HCL5
Liste de (non) drops HC solo avec  screens des persos // Testez le faucheur en HC // Présentation du Faucheur // WW-sin PvM

Il y a 3-4 variantes pour les "mauvaise qualité", et pareil pour les "bonne qualité". Le nom exact et les bonus/malus varient.

Le but n'est pas de deviner (Les résultats sont déjà connus pour le moment) Mais de comprendre comment les trouver.  
Tu devrais absolument utiliser ollydbg Bygirz. C'est un logiciel gratuit, il n'y a pas d'installation tu n'as qu'à cliquer ici
 
Le DWORD c'est juste une question de taille.
Un bit valant 0 c'est 0
Un Byte c'est 00000000
Un WORD c'est 00000000 00000000
un DWORD c'est 00000000 00000000 00000000 00000000
Dans tous les cas cela revient au même ici notre opération mais la variable à 0.  
On peut faire la même chose avec 1
 
1
00000001
00000000 00000001
00000000 00000000 00000000 00000001
 
Tu verras que ta liste de qualité est incomplète, et tu comprendras plus facilement cette histoire de DWORD en la voyant. Sur ce je vous laisse encore travailler  

Bon, ben, j'ai bossé un peu sur cette partie aujourd'hui, histoire de ne pas perdre la main. J'ai donc tenté d'établir le tableau des qualités. C'est un bon exercice.
 
Tout d'abord, comment procéder au test ? Comme d'hab, les petites captures de service !
 
Nous allons modifier certains registres (voir les explications de Myrdinn). J'ai tout entouré en rouge dans cette capture. J'ai identifié les registres de la pile, et le niveau où je me trouvais. J'ai changé le niveau en 85 (55 héxa), et j'ai choisi une baguette de nécro, la baguette macabre ou Grim wand, 13 (D en héxa). J'ai utilisé de la même façon le sort esprit d'os qui ne tue qu'un seul ennemi à la fois.
 
Pour faciliter le test, j'ai utilisé une bonne vieille astuce. Myrdinn va pas aimer Nous allons "Noper". Vous avez lu qu'il suffit de modifier dans la pile le résultat de TEST ESI, ESI pour modifier facilement la qualité d'un objet. C'est bien, mais c'est chiant. Nous allons donc supprimer ce test purement et simplement. Pour cela nous allons remplacer les instructions qui nous gênent par des NOP (no opération). Il suffit juste de se mettre sur l'instruction à noper, ctrl + E, et on remplace les valeurs héxa des instructions (85F6) par 90. <== Ca, il ne va pas aimer...
 
Maintenant, en placant astuctieusement 2 points d'arrêt, il est facile de faire le test, un simple F9 entre les données à modifier et le tour est joué ! (NB : Mes points d'arrêt sont volontairement mal placés )
 
Alors le tableau que j'ai obtenu :
 

 
Commentons les résultats :
 
Voici pour la facture abîmée ce que j'ai obtenu comme type de qualité. C'est le seul type de qualité variable.
 
Un résultat extrêment intéressant est l'unique : l'unique n'est pas reproductible. Une fois qu'un unique est tombé, les uniques suivants deviennnent des rares !!! Il n'est donc possible que de dropper un seul unique d'une même qualité par partie. Exemple : J'ai obtenu une Complainte d'Ume (snif...) sur mon premier "drop", les suivants n'étaient plus que des rares. Par contre en baissant la qualité à baguette en os, j'ai pu obtenir un nouvel unique, etc. Donc : Un seul unique par qualité dans une même partie, ce qui est plutôt cohérent Je n'ai pas vérifié ce qui se passe si portant une complainte d'Ume je peux en dropper une autre... A vérifier.  
 
Le code 9 m'a donné d'étranges objets que je n'avais jamais vu à ce jour. Je vous livre en direct une capture. J'ai obtenu des objets de cet accabit, à savoir verts, mais sans rien. Pas de mode...    
 
Voilà pour aujourd'hui. La suite quand j'aurai le temps

Bon je me met pas encore à Ollydbg, mais je peux répondre aux questions de pralinor à la fin...
 
Quand tu porte un unique c'est certain que tu peux le retrouver alors que tu le porte, de par ma longue experience du jeu.
 
Enfin les objets verts en 9, il me semble que les moddeurs les appellent les objets tempered, mais je sais pas ce que ça fait

---------------

5 ans de solo, 2 ans d'arrêt, reprise HCL5
Liste de (non) drops HC solo avec  screens des persos // Testez le faucheur en HC // Présentation du Faucheur // WW-sin PvM

J'avais fait pas mal de tests (sans OllyDbg), et le seul critère qui compte est que l'objet unique n'ai pas été créé dans la partie en cours (ce qui incluerait les paris). Avoir l'objet sur soi ne pose pas de problème.
Notez que je crois que cela a changé depuis le début, à une époque on disait qu'il suffisait de parier des anneaux avec Manaheal et MachinChose en main pour obtenir la Pierre de Jordanie.
J'imagine qu'il y a un tableau de booléen qui indique si l'unique à été crée. As-tu vu passer un tel tableau ?
 
D'autre part, il y a moyen dans les MPQ de permettre de créer plusieurs exemplaire des uniques. C'est la colonne "NoLimit" de UniqueItems.txt. On doit pouvoir reperer facilement l'accès à cette colonne (chercher un "test XXX[2C], 02" précédé d'une multiplication par 14C. C'est l'accès au bit 1 de l'octet 2C d'un tableau dont les lignes font 14C octets. Une ligne par UniqueItem). Ce pourrait être un moyen de trouver la routine qui se rappelle si l'objet à déjà été créé.
 
Enfin, si le jeu t'as déjà fournit une complainte d'Ume, mais qu'il existe un autre unique basé sur le même objet (et de UniqueLvl atteignable), tu ne devrais pas avoir un rare mais cet autre unique.
 
Il y a d'autres cas où un objet est "déclassé". Voila l'occasion de voir ce qui arrive à un rare qui ne trouve pas d'affixe à son niveau.
 

Ce sont des abandonnés par blizzard, dit "tempered". Le principe est d'y ajouter des bonus au choix avec des recettes de cube. Les moyens d'obtenir ces objets ne sont pas dans le jeu, mais il est facile de les faire apparaitre (voir le mod de 1.11 qu'avait développé Myrdinn).
 
 

Très bien tout cela.
On continuera ce soir pour la suite.
 
OK pour les qualités, pour le ILVL de Bygirz ce n'est pas la bonne réponse. En réalité pour le moment c'est le MLVL du monstre ou le niveau de l'objet qui fait le drop (coffre ....)
 
Pour les NOP, au contraire c'est une très bonne initiative, je n'aime pas le remplacement dans le code quand on peut le faire dans les registres ou sur la pile. Donc la très bien
 
Ulmo commence à aborder un point (le parcours des .bin) que l'on verra ce soir justement. (quoique je n'avais pas encore décidé de donner ce niveau de détail )

Je sais pas pourquoi mais je sens une instruction genre :
MOV ???,EBX  
avec ??? contenant l'Ilvl    
 
(Y a aucune différence entre le Mlvl et l'Ilvl sinon que l'Ilvl est donné aux objets créés? )

---------------

5 ans de solo, 2 ans d'arrêt, reprise HCL5
Liste de (non) drops HC solo avec  screens des persos // Testez le faucheur en HC // Présentation du Faucheur // WW-sin PvM

Il y en a au moins une, le Ilvl est coupé à 99, alors que le niveau du monstre peut être plus haut. L'exemple le plus "courant" est l'annihilus, droppé par un monstre de Mlvl 110, mais de Ilvl 99.

Ah oui j'avais oublié ce cas là...
De même pour la torche.

---------------

5 ans de solo, 2 ans d'arrêt, reprise HCL5
Liste de (non) drops HC solo avec  screens des persos // Testez le faucheur en HC // Présentation du Faucheur // WW-sin PvM

C'est le MLVL vous comprendrez quand on l'utilisera plus tard. Même s'il sera utilisé par le ILVL plus tard, il faut appeler les choses par leur nom, ne serait ce que pour comprendre que ILVL=MLVL du monstre tué, c'est une évidence aujourd'hui ce n'était pas le cas quand cette routine a été débuggué la première fois.
La remarque pertinente d'Ulmo montre également que ce n'est pas la même chose, mais même si c'était strictement équivalent le problème resterait le même.
 
La rédaction du post me prendra plus de temps que prévu. Je fais au plus vite.

Note à ceux qui prendrait l'etude du MF en cours de route.
N'hésitez pas à revenir sur le premier topic et y poser des questions. Je fais des topics  séparés exprès.
 
Retournons à l’étude du code.
Cette fois ci nous nous intéresserons uniquement aux traitements des fichiers txt et à leur reconnaissance
 
Je ne fais pas de capture d’écran.
Je trouve que celle de Pralinor sont excellentes, cela permet de réexpliquer les choses par une autre personne, c’est très important et je suis certain que cela fonctionne mieux ainsi (en plus c’est une excuse en or pour mon coté feignant)
 
UTILISATION DU  FICHIER TXT
 

 
CQVDSADC
Rien de nouveau
 
Analyse
C’est facile.
Essayez par vous-même avant de me lire.
 
Solution :
Appel de 11147(Item ID)
Si le résultat n’existe pas alors on entame la procédure de sortie.
Trivial pour vous maintenant.
 
Conclusions
Qu’est ce que j’obtiens
Pour mon Carquois = 6  
Pour un ID d’objet donné, j’ai toujours le même nombre.
Par contre pour un même nombre je peux avoir plusieurs objets.
 
Ca dépend de l’objet (on passe l’item ID et on récupère toujours le même résultat pour un objet donné.)  
Hypothèse que vous devez en tirer. C’est probablement une info tirée des fichiers Weapons Armors ou Misc.txt.
 
2 possibilités s’offrent à nous :
 
1) On trace la routine 11047 .c’est la plus complexe (c’est pourquoi nous l’évitions jusqu’à aujourdhui) mais elle donnera toujours le résultat de façon certaine, après à voir si nous le comprenons ou pas
 
2) On cherche le chiffre obtenu dans la ligne pour l’objet. Ca devient vite compliqué quand on cherche des 0,1 et tous les chiffres archi commun dans les MPQs.
2 Bis) On prépare un MOD pour simplifier la recherche de type 2 ou pour la confirmer.  
Je vais forcer le drop de mon carquois (ID 210) et pour celui dans Misc.txt je vais modifier toutes valeurs par des valeurs uniques facilement identifiables pour mon carquois (le modifier pour tous les objets serait ingérable. Gd merci à la technique de modification.)
 
Exemple de 2 BIS No Jutsu
Sans MOD 11147(210) donne toujours 6
Si je change uniquement la valeur de la colonne AA en 85 sous Excel pour le carquois et que 11147(210) donne toujours 85 avec ce MOD, c’est que la fonction 11147 lis la colonne AA pour la ligne correspondant à l’ID passé en paramètre. CQFD
 
 
La méthode 2 ne donne rien rapidement.
Par contre si vous regardez le résultat pour toutes les armes / armures … vous devinerez surement très vite de quoi il s’agit.
Mais bon c’est assez long. Essayons pour une fois la méthode 1)
 
Je ne donnerais pas la démarche en détail comme d’habitude, cette procédure n’étant pas notre étude en soit.
 
Moi j’arrive ici avec un PUSH 210 avant l’appel de la fonction. Le 210 est mon unique paramètre (210 Toujours pour mon carquois)
 
6FDC141E      CC            INT3
6FDC141F      CC            INT3
6FDC1420 >/$  8B4424 04     MOV EAX,DWORD PTR SS:[ESP+4]
EAX = Param1 pour moi 210 récupéré sur la pile
Cette fonction ca être courte et simple, cela se voit par l’absence de sauvegarde de registre
 
6FDC1424  |.  3B05 10FBDE6F CMP EAX,DWORD PTR DS:[6FDEFB10]
Param1 Versus Valeur prise dans un tableau dans la DLL (on reverra ca plus loin)ici c’est  28E.
C’est la qu’il faut revenir sur un point très important.
Si vous avez suivi mes conseils, ce chiffre 28E doit vous sauter aux yeux
On reverra la méthode en détail plus tard, je n’insiste pas.
C’est la dernière ligne du fichier WeapArmoMisc.bin.
 
6FDC142A  |.  73 1B         JNB SHORT D2Common.6FDC1447
Le CMP Compare si l’objet est bien dans le fichier
 
Si ce n’est pas le cas On saute à l’Assertion Error (Message d’erreur qui sera affichée au joueur)  
On reverra cela plus tard également. Mais grâce à ces messages on apprend des choses très précises sur les variables et la fonction que l’on debug
 
6FDC142C  |.  8B0D 14FBDE6F MOV ECX,DWORD PTR DS:[6FDEFB14]
6FDC1432  |.  85C9          TEST ECX,ECX
6FDC1434  |.  75 07         JNZ SHORT D2Common.6FDC143D
Dans ECX on charge le pointeur vers le début de WeapArmoMisc.bin
Le test valide que le pointeur pointe bien sur quelque chose
Si vous regarder les valeurs des registres analysées par ollydbg c’est le Premier de la liste flpHax (Hachette) qui apparaît.  
Ca nous fait une confirmation que le fichier commence bien par le premier objet de Weapons.txt associé au 28E c’est certain, nous manipulons WeapArmoMisc.txt
 
 
6FDC1436  |.  68 EF010000   PUSH 1EF
6FDC143B  |.  EB 0F         JMP SHORT D2Common.6FDC144C
Si le test que l’on viens de faire échoue alors on se branche sur le l’assertion ERROR 1EF (l’autre jump amenait sur l’erreur 68E)
 
6FDC143D  |>  69C0 A8010000 IMUL EAX,EAX,1A8
EAX = Param1 * 1A8(taille de la ligne probablement)
Param1 = ID in WeapArmoMisc . bin c’est également la ligne puisque celles ci sont organisées par objet.
 
6FDC1443  |.  03C1          ADD EAX,ECX
Ajoute déplacement (Ligne multipliée par la taille de la ligne) au début de fichier  
 
6FDC1445  |.  75 1F         JNZ SHORT D2Common.6FDC1466
Assertion Error si le déplacement est nul
 
ASSERTION ERROR
6FDC1447  |>  68 8E060000   PUSH 68E
6FDC144C  |>  E8 AF7DF9FF   CALL <JMP.&Fog.#10265>
6FDC1451  |.  50            PUSH EAX
6FDC1452  |.  68 F4A6DD6F   PUSH D2Common.6FDDA6F4
6FDC1457  |.  E8 9E7DF9FF   CALL <JMP.&Fog.#10024>
6FDC145C  |.  83C4 0C       ADD ESP,0C
6FDC145F  |.  6A FF         PUSH -1
6FDC1461  |.  E8 A706F9FF   CALL D2Common.6FD51B0D
Je ne rentrerais pas dans les détail.
Mais ce morceaux de code prépare le message d’erreur à afficher dans la bonne langue et fait la demande d’affichage
Avant la 1.11 la structure fait qu’ollydbg donnait la syntaxe de l’assertion error. Maintenant il faut se brancher dessus exprès et lire le message d’erreur.
Ici j’obtient une fenêtre Daiblo2 Error
Le contenu est  

ICI ca ne nous apprend pas grand chose. Mais ne vous inquiétez pas nous reparlerons des assertions le moment venus.
Par contre très intéressant. On voit que le message d’erreur nous renvoie la bonne adresse dans la DLL d’ou a été appelé la boite de message d’erreur.
 
 
6FDC1466  |>  0FBF80 1E0100>MOVSX EAX,WORD PTR DS:[EAX+11E]
 
EAX = 6 pour mon Bolt ???
Rappelez vous EAX contient le début de la ligne nous concernant.
On lit donc la position +11E sur la ligne.
C’est bien une information contenu dans WeapArmoMisc.bin. Mais cette information a subit une transformation entre le passage des fichiers TXT et la compilation en .bin puisque je ne retrouve pas la valeur dans les txt de départ.
 
On a vu un début d’explication d’ULMO, mais je ne reprendrais pas tout de suite la méthode.
Disons pour le moment, que nous n’avons rien appris de plus sur notre 6 associé aux carquois
 
6FDC146D  \.  C2 0400       RETN 4
6FDC1470   .  33C0          XOR EAX,EAX
6FDC1472   .  C3            RETN
6FDC1473      CC            INT3
6FDC1474      CC            INT3
La fin classique d’une fonction.
 
CONCLUSION.
Nous ne savons toujours pas ce que signifie ce chiffre. Par contre on sait que le fonction retourne dans EAX la valeur en position +11E sur la ligne correspondant à l’objet dans le fichier weaparmomisc.bin
 
Je l’ai déjà dit. Nous pourrions aller plus loin et trouver l’info.
Mais je préfère vous montrez que ce n’est pas obligatoire de comprendre tout de suite, et que si cette infirmation est utile alors on découvrira rapidement à quoi elle sert par d’autres moyen.
Continuons.
 
UTILISATION DU  FICHIER TXT – Autre méthode – nouvelle astuce
 

 
CQVDSADC
2 MOV
Un CMP Suivi de JGE.  
OK JGE c’est nouveau c’est Greater ou Equal, supérieur ou égal.  
Tout ca c’est trivial
 
Par contre de nouveau on n’attaque pas des registres comme nous l’avions vu auparavant.
On récupère dans D2Common.dll une valeur (de la taille d’1 DWORD) qui est dans une  section de D2COMMON qui est un tableau. DS:[<&D2Common.sgptDat>; D2Common.sgptDataTables
Peu importe la syntaxe, on comprend intuitivement. Nous n’avons pas besoin de devenir des experts en assembleur ni en dll.
ECX est un pointeur sur ce tableau
 
Analyse
ECX = Valeur lue dans une table de D2Common.dll (La deuxième ligne copie dans ECX la valeur en position +00 de ce Tableau)
Cette valeur est un pointeur
 
C’est complexe, et nous n’avons aucun besoin de comprendre ce type d’imbrication. On en reparlera Hors Topic ou le jour ou vous serez des experts en tracage de DLL de D2
 
Ensuite on compare EAX (Dont nous ignorons toujours la signification)  
Avec la valeur en position +BFC dans le tableau (Le ECX+BFC ), normalement 103 (0x67)
 
Si le résultat que nous avons obtenu est supérieur à ce MAX alors on sort de la routine
 
CONCLUSION
On ne sait toujours pas ce qu’est notre valeur mais on sait que le maximum est 103
 

 
CQVDSADC
La nouveauté c’est IMUL
Ca signifie simplement multiplication.
Le format est un peu étrange puisqu’il y a trois opérandes.
Le but n’est pas de vous faire un cours d’assembleur mais je vais quand même donner l’explication.
Quand on multiplie 2 DWORD entre eux, il est peu probable que le résultat tienne dans un DWORD. C’est un paramètre qu’il faut indiquer
 
Commençons par un petit aparté Les registres ont chacun leur particularité.
Par exemple on a vu que EAX reçoit les résultats
Très souvent les pointeurs sur des structures utilisent les registres ESI et EDI  
…
 
Quand les résultat sont sur 64 Bits, ils sont donnés dans EDX :EAX (Nous verrons plus tard la commande assembleur qui prépare ce super registre)
Ici on force le résultat à rester dans EAX seulement
IMUL EAX,EAX,0E4 signifie EAX = EAX * 0E4
IMUL EAX, 0E4 signifierait EDX :EAX = EAX * 0E4
C’est d’autant plus important que on est en train d’utiliser EDX pour autre chose.
 
Analyse
On récupère une valeur dans le tableau de D2Common.dll.  
Etrangement on nous signale ASCII =  «       «  Soit une case Vide ????
Ensuite on ajoute à cette valeur EAX*0E4 (Le IMUL suivi du ADD)
On test le résultat et on sort s’il est NUL
Ensuite on le sauvegarde sur la pile.
 
Si on regarde EDX (bouton droit Follow in Dump)on s’aperçoit rapidement qu’il s’agit d’un fichier .BIN
 
Si on observe le trace pour plusieurs objets on en déduit très facilement que  
EAX est le numéro de la ligne. C’est aussi notre inconnue de toute à l’heure.
0E4 est la taille de la ligne
 
Nous l’avons vue rapidement tout à l’heure avec la fonction 11147
Pour calculer le pointeur sur la bonne ligne on fait le calcul suivant
Pointeur sur la ligne = Pointeur début de fichier + Numéro de la ligne * Taille de la ligne
C’est facile à comprendre, et en assembleur on retrouvera quasiment toujours ce schéma pour la gestion des fichier. Ce schéma que vous finirez par reconnaître facilement dans le code.
 
Du coup on peut même dire que le paramètre d’entrée qui est la valeur que nous ne connaissons pas est la ligne dans ce fichier .BIN.  
 
Comment reconnaitr le fichier d’origine
Ma méthode est simple.
Je les connais très bien donc je les reconnais facilement. Mais cette méthode n’est pas très sure et n’est pas facile à transmettre  
 
Ici on a une tonne d’information capitale qui nous permet de confirmer à coup sur quel est ce fichier.

• On sait que la ligne max est 103, donc le fichier .txt doit contenir 103 Lignes de valeurs.
• On a également la taille de la ligne une fois compilé (c’et moins simple, mais si vous extrayez les .bin au lieu des txts c’est assez facile à retrouver)
• On sait que la première ligne donne ASCII =  «       «  donc que la première ligne commence probablement par NONE

C’est d’ailleurs la méthode que j’ai utilisée tout à l’heure avec notre 28E de weaparmomisc.bin.
 
Je pourrais vous laissez chercher, mais vous verrez très rapidement que le fichier en question est ItemTypes.txt.
 
Donc le 6 est l’ItemType de mon carquois.
Allons Vérifier. Ca marche pour mon bolt je trouve xboq pour l’ID 6 (Ligne 8)
A priori la première colonne (pour humain) n’est pas reprise dans le .bin
Pourquoi ligne 8 = ID 6
Les listes commencent toujours avec l’ID 0. Donc le premier NONE (2eme ligne) à l’ID Zéro.
Pourquoi 2 NONE ???
Souvent quand le déplacement est NUL (premier NONE) alors on considère que c’est un bug et on se retrouve avec une assertion error. Du moins c’est mon hypothèse.
 
Détail important. Que pensez vous qu’il se passe si je fais un mod ou je rajoute des lignes dans ces fichiers ??? L’objet est forcément non magique ??? Faite le test, on en reparle après
 
Conclusion
Je vous l’avais bien dit
Si la valeur est utilisée plus loin nous pourrons la reconnaître plus loin, en voici la preuve.
 
Avant de terminer, un conseil. N’oubliez pas de faire une photo de la pile, car nous venons d’y sauvegarder le pointeur sur la bonne ligne de itemtypes.bin
Je vous laisse le faire et me décrire ce que vous devriez y trouver
 
 
Utilisation de itemType.txt
 

 
CQVDSADC
 
Un MOV 1 TEST c’est trivial
Il faut noter 2 choses ICI
EAX contient le pointeur sur notre ligne dans ItemTypes.txt
CL est la version réduite de ECX
Explication
ECX est un DWORD format xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx
La version réduite est CX qui est un WORD xxxxxxxx xxxxxxxx
CX est lui-même divisé en 2 registres 8bits C :  
CH(igh)- CL(ow)  chacun de la taille d’un byte xxxxxxxx
 
Ensuite une celèbre procédure de sortie qui n’a plus rien à vous apprendre avec qualité = 2 = Normal
 
Analyse
Facile on se déplace de +16(bytes) sur la ligne et on place la valeur dans CL.
Ici je présente le résultat pour le drop d’un arc. (itemptype = Bow)
 
Test valeur en position EAX +16  

 
+16 = 00 pour mon BOW donc continue
 
Si la valeur est 0 on continue.
Autrement on sort avec la valeur 2 pour la qualité.
C’est facile à deviner, on regarde le chiffre dans la colonne Normal de itemTypes.txt (Colonne R sous Excel)
 
Mais rappelez vous ma méthode 2B) Modifier le fichier txt pour reconnaître qu’elle valeur est lue dans le .bin
C’est ce qu’il faut absolument faire ici et je vous invite vivement à réaliser la manipulation
 
Conclusion
Si l’objet à une valeur indiqué dans la colonne Normal dans ItemTypes.txt alors il est forcément dropper avec la qualité NORMAL
 
 

 
CQVDSADC
 
Même structure que la dernière. Rien de nouveau
 
Rien mais vous devez absolument avoir testé dans la leçon précédente les qualités pour comprendre que 7 = Qualité Unique
 
Analyse
OK On test une condition qui amène forcément au résultat unique.
 
Attention on se déplace de +129 bytes dans ESI. Rappelez vous (plusieurs leçon en arrière) ESI est le résultat de la fonction 10262, pour laquelle notre hypothèse était C’est le pointeur sur la ligne de WeapArmoMisc.bin
C’est l’occasion de vérifier.
On pourrait deviner s’il s’agit de la colonne unique (Colonne BH sous Excel) Mais je vous invite vivement à faire la modification des .txt qui permettra de prouvez que c’est le cas
 
Conclusion
Si la valeur de la colonne (a vous de me le dire) est non nulle alors l’objet est forcément unique.
 
 

 
Voici un double test qui amène soit à  
On continue  
Soit l’objet est unique.
 
Un bon exercice.
A vous de me dire à quoi correspondent ces colonnes.
 
Ensuite à vous d’écrire le mécanisme d’utilisation des fichiers Weapons.txt Armor txt et itemtypes.txt pour déterminer la qualité des objets lors du drop.
 
REMARQUES et PUBLICITE
 
Si vous posez la question suivante à des experts des fichier txt :
Quelles sont les 2 conditions pour qu’un objet soit forcément unique à partir des fichiers Weapons.txt et ItemTypes.txt ?
je ne sais pas si vous trouverez quelqu’un pour répondre.
 
Bah très simple il suffit de répondre aux questions du topic  
 
Normalement ce topic devrait amener des tas de question sur la gestion en particulier de itemTypes.txt. Des questions dont nous avons déjà débattues avec Ulmo.
J’en profite pour faire une remarque au passage. Il ne faut pas me croire sur parole, je me trompe régulièrement (Cf ;. Le ligne +2 de la dernière fois) et en plus parfois je fais exprès de glisser des fausses informations (assez évidentes quand même pour ne pas vous faire fuir )
 
La prochaine fois, quand vous aurez terminé nous verrons
Une autre utilisation d’un fichier TXT (au travers du .bin chargé en mémoire) Une révision ultra simple.
 
la fin de la procédure de calcul de la qualité avec l’archi classique  
Est –ce un unique ?
NON alors est ce que c’est un objet de SET
NON alors est ce que c’est un objet RARE
…
NON alors c’est un objet de mauvaise qualité.

Un grand merci pour ce post très instructif Voici ma floppée de commentaires/réponses/questions...
 

11147 si j'ai bien suivi.
Ce que je ne comprend pas sur ce passage :
Tu parles de la colonne AA, qui chez moi est la colonne "Transmogrify". As-tu bougé tes colonnes ?
Pourquoi lis-tu un numéro pour la colonne "type" ?
 
Et la méthode 2Bis, sans assembleur :
On cherche que vaut 11147(item ID). Par exemple on voit que pour un carquois, le résultat vaut 6. Dans ce cas mon réflexe est d'aller voir la ligne du "Bolts" de Misc.txt. Il n'y a pas de valeur 6 sur cette ligne. Par contre un effort d'imaginiation (et parce que j'ai une idée de comment ça marche) me fait regarder la colonne type (je sais que c'est l'index d'une ligne d'un autre fichier, à savoir ItemTypes.txt), j'y trouve "xboq". C'est la 7ème entrée de ItemTypes.txt, donc le numéro 6 si on numérote depuis 0. Voila pour mon hypothèse.
 
 
 

Pourquoi 28E alors quavec ma version je n'ai que 288 (648 en décimal) lignes au total ? J'ai raté des ajout de lignes hardcodés ? Tu utilises les fichiers de ton mod ?
Autre question très troublante, comment le numéro de la dernière ligne peut-il être inclu dans la DLL ? Ce numéro doit être calculé au chargement des tableau et pas à la compilation du jeu. Ou alors cet emplacement n'est pas un tableau mais en fait une variable globale...
Ah oui, en fait c'est le début de WeapArmoMisc.bin (vient ensuite le début de Weapons.bin). Les fichiers *.bin commencent par le nombre de lignes, puis les lignes du tableau. Et la première colonne de WeapArmoMisc.bin, c'est le "flippyfile", suivi du "invfile".
 

Ca veut dire quoi ce "associé au 28E" ??
 
Bon la taille des lignes, c'est effectivement 1A8 pour WeapArmoMisc.bin. Et en 11E, ce sera bien l'ItemType, codé sur 2 octets (au lieu des 4 habituels, attention).
 
 

Tiens, si tu peux m'expliquer comment il trouve la ligne 495 et l'adresse 6FDC1451...
 
 

Voila quelque chose de très interessant : Visiblement PTR DS:[ECX+BFC] est le début de ItemTypes.bin. Donc PTR DS:[ECX] au dessus serait une structure avec les pointeurs vers tous les *.bin. Et enfin D2Common.sgptDat est un pointeur (variable globale probablement) vers la structure précédante. Voila probablement le moyen de retrouver tous ces tableaux dans le code.
Par contre il est bizarre que certains *.bin aient aussi un accès plus direct (WeapArmoMisc.bin, on l'a vu plus haut, est accessible par PTR DS:[6FDEFB14]).  
 
 

Colonne Q chez moi (fichiers tout droit sortis de D2_Patch.mpq, version 1.11b)...
 
 
 

Interessant, j'apprend 2 choses :

• "Quest" de WeapArmoMisc impose à l'objet d'être unique.
• Mais il faut que "Magic" de ItemTypes soit vrai pour que ce test ait lieu.

 
 
A noter aussi : j'ai décodé les structures des tables *.bin, ce dont je me sers assez souvent on l'a vu. Le problème est que les principaux usages de telles notes sont de lire le code (comme ici), et de réécrire les fichier *.txt. Ce dernier usage permet de voler le contenu des mods (ou d'y tricher facilement). C'est pourquoi ce genre d'info n'est pas dispo sur PK, et pourquoi je ne peut pas les mettre à disposition en l'état.
Maintenant si quelqu'un est intéressé par ces structures (Myrdinn ou Joël j'en doute, Pralinor peut-être, ou un autre), je peux lui envoyer par MP les infos sur les fichiers qui l'intéresse.

Merci pour le retour surtout
 

Non c'est un exemple générique. Le AA n'a pas de réalité.
Ce que je fait c'est que je change toutes les colonnes numérique de mon Quiver dans Misc.txt de façon incrémentale (1 dans l