Discussion :

[le mage tophinus]

J'aurais voulu savoir ce que fait l'instruction ARPL en général et dans les deux cas particuliers suivants :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
arpl [si+100h],bx  ; c'est ds:[si+100h] ou cs:[si+100h] ???
arpl dx,ax

Merci d'avance

[Smortex]

out ce que je peut donner comme info, c'est ca, mais je n'en sais pas plus (et tu as déjà trouvé ca je pense) :

Adjusted Requested Privilege Level of Selector

Compares the RPL bits of "dest" against "src". If the RPL bits of "dest" are less than "src", the destination RPL bits are set equal to the source RPL bits and the Zero Flag is set. Otherwise the Zero Flag is cleared.

Syntaxe :
ARPL dest,src

Registres modifiés :
ZF

[le mage tophinus]

effectivement, j'avais déjà trouvé un truc de ce genre. J'ai quelques connaissances en Anglais mais là j'avoue je suis largué . Can I have some help please ???

[Blustuff]

moi aussi je me posait la question, mais pas parce que cxa m'était indispensable, et puis là tu m'a fait rechercher. En fait c'est pour les os qui fonctionnent en pmode. Ca permet d'ajuster un niveau de privilège.

http://webster.cs.ucr.edu/Page_TechDocs/Doc386/arpl.html

c'est assez clair sur cette page (recherche google avec "arpl", deuxième page) et l'anglais est pas très compliqué, la preuve, j'ai compris !

[le mage tophinus]

Ok,en fait, ARPL j'avais à peu près compris sauf que l'info que tu me donnes en plus grâce à ta page web Blustuff me fait énormément réfléchir (ARPL ne fonctionne pas sous Rmode ???)

En fait, mon véritable problème c'est les RPL bits. J'ai compris que c'était en rapport avec le niveau de privilège du Pmode. Le truc c'est comment on peut lier un RPL à AX ou BX ???

[Blustuff]

bah d'après ce que j'ai compris (déja ca commence mal) tu peux mettre dans ax, l'identifiant du selecteur, mais tu peux aussi utiliser une variable qui contient l'identifiant du selecteur. L'instrtuction va chercher dans la GDT le niveau de privilège corespondant au selecteur, et le modifie si il est inferieur à l'autre niveau de privilège.

Et ca fonctionne evidement pas en rmode, puisqu'on ne parle ni de selecteur ni de niveau de privilège en rmode. Cela dit, j'ai aucune idée de ce qui se passe si on appelle arpl en rmode, certainement pas une exeption vu qu'il n'y en a pas en rmode

[le mage tophinus]

Ok, ça devient plus clair pour l'instruction en elle-même. Thank you

En fait, je vais m'expliquer. Je "désassemble" l'interruption 10h et en suivant le code(et surtout le far jump, en posant ax=7) je remarque au bout d'un moment que je tombe sur un ARPL (louche en Rmode). Donc il doit bien exister une action d'ARPL en Rmode et j'ai été scruté l'nterruption 6h (comme dans la page web) mais j'ai abandonné, je pense que c'est pas ça

[Blustuff]

Ma doc est formelle, pas de ARPL en rmode. Et c'est la seule instruction qui porte cet opcode. Tu es sur qu'il n'y a pas d'erreur de désassemblage ??

[le mage tophinus]

J'en suis sûr, j'y ai bien regardé à 2 fois (ou plutôt 10 fois) avant de dire des choses pareilles. En plus, j'utilise deux désassembleur différents pour être sûr que le résultat soit correct. Alors maintenant, je suppose que ARPL doit avoir une autre fonction en Rmode ou sinon, le codage de APRL, càd 63h doit donner une autre fonction en Rmode, c'est la seule solution que je vois.

[golem]

Bonsoir,

ARPL fait partie de la stratégie de conception en anneau des systèmes d'exploitation. (i.e. ring 0==mode noyau, 1,2==couches basses et drivers, 3==application, mode user).

ARPL (avec ses cousines LAR, LSL, VERR, VERW) est une instruction non privilégiée donc executable quelque soit le niveau de privilège, en mode protégé évidemment, la notion de sélecteur n'ayant pas de sens en mode réel. On la trouvera néanmoins très rarement dans les appli, mais moins rarement dans des drivers.

Cette instruction donne la capacité de vérifier si le niveau de privilège de la tâche courante est suffisant pour déférer un pointeur et donc accéder à un segment donné. Ceci est utile pour des échanges de pointeurs inter-couches (ex: une appli passant un pointeur vers un driver ou vice versa). C'est une action préventive à l'exception. (i.e. on execute cette instruction afin de vérifier plutot que de déclencher une exception).

Pour ce qui est de trouver ARPL dans du code en mode réel, j'émet l'hypothèse (c'est à vérifier) que la zone que tu désassembles est une zone de données du BIOS (ex: des valeurs à transférer vers les registres du controleur vidéo) . Tu peux donc y trouver n'importe quoi (et donc des ARPL) si tu cherches à interpréter des opcodes.

Autre hypothèse, mais là j'ai franchement des doutes, surtout pour l'int 10h, il s'agit bien de code pour du mode protégé, le bios passant en pmode juste avant et repassant en mode réel (hum hum, difficile) juste après, en exploitant par exemple les fonctions 87h et 89h de l'int. 15h du BIOS.

golem
+++

[le mage tophinus]

Merci Golem pour les explications bien détaillées sur ARPL.

Par contre, au niveau de mon désassemblage, je suis sûr que ce n'est pas des datas car je "déroule à la main" l'interruption 10h qui me mène finalement à une instruction 'ARPL'. Je postulerais donc pour ta deuxième solution, le hic c'est qu'on est en mode réel et qu'en 'déroulant à la main' l'interruption, je ne vois jamais le prog passait en Pmode avant de tomber sur l'ARPL. Alors, soit il y a une astuce inconnue à ARPL en mode réel, soit il y a eu du cryptage dans mon fichier au moment où je l'ai saisi. Je pencherais plutôt pour cette solution car en faisant la même chose sur windows millenium mais avec l'interruption 15h cette fois-ci, je trouve que l'interruption 15h pointe à l'origine (IDT) vers FF00:A93E ou quelque chose dans ce genre. En gros je pointe vers quelque chose au dessus du mégaoctet en mode réel... donc problème

Je vous donne quand-même le prog que j'utilise pour peut-être un peu plus de compréhension (il copie de l'adresse 0000:0000 à F000:FFFF dans un fichier test.txt)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
 
code segment
assume cs:code
assume ds:data
assume ss:pile
debut:
mov ax,data
mov ds,ax
xor ax,ax
mov es,ax
push ax
; ouverture d'un fichier
xor cx,cx
mov dx,offset namefile
mov ah,3ch
int 21h
;  preparation écriture
mov bx,ax
mov dx,offset carac
mov di,offset carac
xor cx,cx
boucle:
mov ah,40h
mov si,cx
mov al,es:[si]    ; lecture dans la mémoire
mov ds:[di],al
push cx
mov cx,0001h
int 21h
pop cx
inc cx
cmp cx,0FFFFh
jne boucle
mov ah,40h
mov si,cx
mov cx,01h
mov al,es:[si]
mov ds:[di],al
int 21h
pop ax
cmp ax,0F000h
je fermeture
mov cx,1000h
add ax,cx
push ax
mov es,ax          ; on passe au segment suivant
mov dx,offset carac
mov di,offset carac
xor cx,cx
jmp boucle
 
fermeture:
; fermeture du fichier
mov ah,3Eh
int 21h
 
 
attente_sortie:
xor ah,ah
int 16h         ; attente d'une touche
sortie:
mov ah,4Ch
int 21h         ; sortie du prog
code ends
 
data segment
namefile db "test.txt",0
carac db " "
data ends
 
pile segment stack
remplissage db 256 DUP (?)
pile ends
 
end debut

[Blustuff]

Et tu as supposé l'hypothèse, que le programme est en pmode depuis le debut ? Si tu desassembles windows, et notement l'emulation du dos par windows, tu vas forcement tomber sur des arpl non ? Enfin, c'est qu'une hypothèse

[le mage tophinus]

Effectivement, c'est pas une mauvaise idée, je dirais même que c'est une très bonne idée . Vu que l'interruption 10h est responsable du mode vidéo, il est vrai qu'en choisissant un mode vidéo "tordu", tu fais basculer ton écran dans ce mode vidéo là et tu ne vois plus rien de ce qui se passe sous windows (je sais pas comment ça s'appelle ce flip-flop de l'écran où tu ne vois plus que l'exécution courante). Je suppose que pour faire une telle chose en Pmode, il faut un niveau de privilège donc potentiellement un APRL. Donc, en finissant ce raisonnement, il y a des chances que l'on soit de base en Pmode. Merci Blustuff pour la soluce 8)

Par contre, si tu regardes mon message juste avant, je parle de l'int 15h qui pointe au-dessus de 1MO, y a une astuce de calcul(et de pointage) ou est-ce véritablement un problème qu'on laisse tomber ?

[Blustuff]

mééé je sait pas. mais de toute facons, windows est en pmode il est hors de question de passer en mode réel, que ce sois l'int 10h ou 15h, Mais ca veut rien dire si on en sait pas ce qui est emulé et ce qui ne l'est pas

En pmode FF00:A93E doit vouloir dire Selecteur FF00 (ca fait bcp non ?) et deplacement A93E.

Cela dit ton desassembleur desassemble en 16 ou 32 bits ? *parce que ton programme dos est ecrit en 16 et l'emulation en 32 non ? (moi je trouve ca bizare, de toutes facons je comprends plus rien)

[le mage tophinus]

Alors, pour être clair, je désassemble en 16bits (vu que c'est censé être du DOS).

Au niveau des adresses, je pense qu'elles sont quand-même comptées en Rmode car si je prends par exemple l'int 15h, 15h*4=54h et en faisant un "call far 0:54h"(ce que fais l'int 15h) je pointe vers quelque chose de compréhensible, comparaison de AH avec 84h, 85h ou 87h .... Je voulais juste savoir s'il existait un moyen de pointer vers une adresse inférieure à 1MO quand cette adresse compatibilisée est supérieure à 1MO, avec un 'overflow flag' ou quelque chose de ce genre (comme pour les opérations d'addition ou de multiplication mais avec des adresses de type segment:offset)

Il est vrai que ce Post commence à me rendre marteau