Bonjour,
Je voudrais avoir des précisions sur les fonctions ROL et ROR.
par exemple avec
EAX=A0F060A0
et après
ROL EAX,0D
pourquoi EAX=0C14141E
?
de même,avec
EBX=30E0F0D1
et après
ROR EBX,0D
pourquoi EBX=86898707
?
Merci pour vos réponses !
Bigbang








Bonjour,
Je voudrais avoir des précisions sur les fonctions ROL et ROR.
par exemple avec
EAX=A0F060A0
et après
ROL EAX,0D
pourquoi EAX=0C14141E
?
de même,avec
EBX=30E0F0D1
et après
ROR EBX,0D
pourquoi EBX=86898707
?
Merci pour vos réponses !
Bigbang








c'est simple, c'est le même chose que pour shl et shr sauf que les bits qui sont expulsés sont remis de l'autre coté. c'est un peu comme une rotation de bits.
exemple :
al = 11000011
si on effectue un rol al, 2
alors al = 00001111
si on effectue un ror al, 2
alors al = 11110000








ok ok ...
merci !








je vois bien comment ca marche ...
mais si j'ai une équation de ce style (où l'on cherche x) :
ROL(x,0D)=102E2E2E
comment peut trouver x ?
De même si j'ai
ROR(y,0D)=0B018B0E
Comme trouver y ?
Merci à vos réponses !
Bigbang








ben faut tout simplement faire l'opération inverse :
si ROL(x,0D)=102E2E2E
alors x=ROR(102E2E2E,0D)
et si ROR(y,0D)=0B018B0E
alors y=ROL(0B018B0E,0D)








oui c'est bien ce que j'ai fais, mais lorsque je le fais et que je compare avec la valeur donnée par le débugger, elles sont différentes...
si ROL(x,0D)=102E2E2E alors x=ROR(102E2E2E,0D)
alors je convertit 102E2E2E en binaire :
102E2E2E <-> 10000001011100010111000101110
et donc après j'effectue la rotation à droite (je pense que c'est ici qu'il y a un problème) :
Je prends le chiffre de droite et je le mets a gauche. Et je recommence cette opération 13 fois (0D fois). Voici le détail des opérations, les 13:
10000001011100010111000101110 ; nombre initial
01000000101110001011100010111 ; déplacement 1
10100000010111000101110001011 ; déplacement 2
11010000001011100010111000101 ; déplacement 3
11101000000101110001011100010 ; déplacement 4
01110100000010111000101110001 ; déplacement 5
10111010000001011100010111000 ; déplacement 6
01011101000000101110001011100 ; déplacement 7
00101110100000010111000101110 ; déplacement 8
00010111010000001011100010111 ; déplacement 9
10001011101000000101110001011 ; déplacement 10
11000101110100000010111000101 ; déplacement 11
11100010111010000001011100010 ; déplacement 12
01110001011101000000101110001 ; déplacement 13
donc j'obtiens ce nombre : 01110001011101000000101110001
que je convertis en hexadécimal, ce qui donne : E2E8171
Le problème est que lorsque je mets cette valeur (E2E8171) dans EAX juste avant l'execution de
ROL EAX,0D
et que j'execute ensuite cette commande, elle modifie EAX par cette nouvelle valeur : D02E21C5
or D02E21C5 et 102E2E2E ne sont pas égaux..
Où réside le problème ?
Bigbang
Allez, je me lance...
Le ROL/ROR place son bit du coté dans la carry ou pas ?
Parce que s'il y a qqchose dans la carry avant et qu'elle circule, ça casse tout ton résultat...








c'est quoi la carry ? elle sert à quoi ? elle fait quelle taille ?
pourriez-vous reprendre le raisonnement avec mon exemple ?








ça c'est bon pour la calculatrice windows seulement.102E2E2E <-> 10000001011100010111000101110
n'oublies pas que le proc il lui faut 32 bits, et dans ta conversion y en a que 29.
le carry c'est le bit 0 du FLAGS c'est un indicateur de retenu mais elle sert surtout par exemple dans un cas ou il y a une erreur
Non non, je pense que c'est Executter qui a raison. A mon avis, le carry n'a rien à voir dans tout ca...
Il faut par contre impérativement prendre en compte le fait que windows travaille en 32 bits et les "0" sont très importants, même s'il sont positionnées en premier dans ton nombre binaire, car après avoir appelé les instructions ROL et ROR, ils se retrouveront à la fin du nombre et deviendront essenciels!!!
Imagine par exemple que ton processeur travaille avec des nombres décimaux codés sur 4 chiffres (ce qui est bien sur complètement faux!)
Tu prends : 145 , qui sera codé 0145
Il va ensuite devenir 1450 après l'appel de ROL
Alors que toi, tu aurais obtenu 514 car tu n'aurais pas pris en compte la présence du "0" devant le nombre "145"








ok ...
c'est bon j'ai réussi à résoudre mon problème .. avec l'aide d'un petit programme en C, en faisant appel aux fonctions rotl et rotr
A++
Bigbang
(La fonction première du carry flag est de dire si il y a retenue dans une opération ou non)
Partager