Commentaires sur une source : BUFFER OVERFLOW ET LA PILE

oez Messages postés 1 Date d'inscription dimanche 25 mai 2003 Statut Membre Dernière intervention 2 novembre 2003
2 nov. 2003 à 03:07

Eh bé...

Des commentaires comme on voudrait en voir sur tous les forums, même si on s'est un poil éloigné du sujet :-p

tytyi11 Messages postés 6 Date d'inscription jeudi 3 juillet 2003 Statut Membre Dernière intervention 24 septembre 2006
26 sept. 2003 à 17:54

wa fine a zikasse !!!!!

ta des mondes ici .

ton programme a harsse les tete diyale benademe.

BruNews Messages postés 21040 Date d'inscription jeudi 23 janvier 2003 Statut Modérateur Dernière intervention 21 août 2019
25 sept. 2003 à 12:25

Hors directives d'alignement, correctes sur les 2 (heureusement):
Ne sera analyse que le bloc SinScroll.
VS 2003 a produit en 187 lignes: 531 octets de code.
GCC en 195 lignes: 837 octets soit 57.62 % + gros que VS.
A suivre, suivant disponibilite.

cs_Nebula Messages postés 787 Date d'inscription samedi 8 juin 2002 Statut Membre Dernière intervention 7 juin 2007 2
25 sept. 2003 à 08:17

Kaid > J'ai jamais dit que GCC était le meilleur, il a même de grosses lacunes sous windows (on doit recourir à des manipulations bizarres pour COM, par exemple), c'est juste qu'un particulier n'a pas vraiment les moyens (ou l'envie) de se tourner vers un MSVC payant (et cher) pour faire juste un "passe-temps"...

Et quand je dis que ce comparatif est "honnête", c'est dans le sens où il reste objectif et ne tombe pas dans les vieux trolls auquels je me suis habitué en lisant les articles sur GCC, lol

cs_Kaid Messages postés 949 Date d'inscription mardi 2 octobre 2001 Statut Membre Dernière intervention 8 juillet 2006 1
24 sept. 2003 à 18:00

Nebula >> Testé en version beta Visual C++ 2002 donc attention. Mais au final la conclusion est assez bonne: "pour les professionnels travaillant sous Windows, Visual C++ reste incontournable pour son environnement [...]".

cs_Nebula Messages postés 787 Date d'inscription samedi 8 juin 2002 Statut Membre Dernière intervention 7 juin 2007 2
24 sept. 2003 à 14:07

Oui, quand j'aurais le même niveau je serais content ;-)

J'ai trouvé un comparatif honnête entre MSVC, GCC, ICC et BCC :
http://casteyde.christian.free.fr/cpp/benchmarks/

En gros MSVC est performant mais buggé et ne respecte pas la totalité de la norme C++, BCC est le plus rapide mais génère du code merdique, ICC est la rolls pour processeurs Intel et GCC est le plus portable, le plus respectueux des standards mais également le plus lent (ce qui n'est plus vrai depuis la version 3.3.1), tout en générant du code honnête mais sans plus.

J'attend les conclusions de BruNews pour savoir à quoi m'en tenir :p

zikoasm Messages postés 15 Date d'inscription mercredi 3 septembre 2003 Statut Membre Dernière intervention 25 juin 2005
20 sept. 2003 à 21:23

nebula>> brunews est tres fore en assembleur il ne y a rien a dire en cela :)

cs_Nebula Messages postés 787 Date d'inscription samedi 8 juin 2002 Statut Membre Dernière intervention 7 juin 2007 2
19 sept. 2003 à 22:15

çà peut venir de mes options de compilation, y'en a une qui est marquée "may or not produce better code, try before use"... je tente de réassembler sans, histoire de voir !

BruNews Messages postés 21040 Date d'inscription jeudi 23 janvier 2003 Statut Modérateur Dernière intervention 21 août 2019
19 sept. 2003 à 22:07

bon je vais copier coller tout cela et en faire des mesures, c'est tres interessant.
Tu vois cela:
xor ebx, ebx
cmp ebx, DWORD PTR _m_rcClient+8
grosse erreur de GCC, eax est libre, il nous fait prendre un AGI STAL de plein fouet alors qu'il l'evitait avec eax, pour preuve il fait une affectation directe sur eax a la ligne suivante donc il pouvouvait XORer sur eax. On va analyser + en details, a ++ tard.

cs_Nebula Messages postés 787 Date d'inscription samedi 8 juin 2002 Statut Membre Dernière intervention 7 juin 2007 2
19 sept. 2003 à 21:55

J'ai zappé toutes les directives de GAS (align, etc), çà donne :

_sinScroll:
push	ebx
sub	esp, 72
mov	edx, DWORD PTR _m_nPixLeft
test	edx, edx
jle	L33
L18:
mov	DWORD PTR [esp+32], 13369376
mov	edx, DWORD PTR _m_rcScroll+8
mov	ebx, DWORD PTR _m_hdcScroll
mov	DWORD PTR [esp+28], 0
mov	ecx, DWORD PTR _m_rcScroll+12
sub	edx, 2
mov	DWORD PTR [esp+20], ebx
mov	DWORD PTR [esp+16], ecx
mov	DWORD PTR [esp+12], edx
mov	DWORD PTR [esp], ebx
mov	DWORD PTR [esp+24], 2
mov	DWORD PTR [esp+8], 0
mov	DWORD PTR [esp+4], 0
call	_BitBlt@36
mov	edx, DWORD PTR _m_hdcSinus
sub	esp, 36
mov	ecx, DWORD PTR _m_rcClient+12
mov	DWORD PTR [esp+20], 66
mov	ebx, DWORD PTR _m_rcClient+8
mov	DWORD PTR [esp], edx
mov	DWORD PTR [esp+16], ecx
mov	DWORD PTR [esp+12], ebx
mov	DWORD PTR [esp+8], 0
mov	DWORD PTR [esp+4], 0
call	_PatBlt@24
mov	edx, DWORD PTR _m_nSinusSpeed
sub	esp, 24
mov	eax, DWORD PTR _m_nSinusOffset
add	eax, edx
test	edx, edx
mov	DWORD PTR _m_nSinusOffset, eax
jle	L20
cmp	eax, 719
jle	L20
xor	ebx, ebx
xor	eax, eax
mov	DWORD PTR _m_nSinusOffset, ebx
L21:
mov	DWORD PTR _m_nSinusPos, eax
xor	ebx, ebx
cmp	ebx, DWORD PTR _m_rcClient+8
jge	L31
L28:
mov	eax, DWORD PTR _m_nSinusPos
xor	ecx, ecx
inc	eax
cmp	eax, 720
cmovl	ecx, eax
mov	DWORD PTR _m_nSinusPos, ecx
sar	ecx
push	ecx
fild	DWORD PTR [esp]
add	esp, 4
fmul	QWORD PTR LC0
fdiv	DWORD PTR LC1
fstp	QWORD PTR [esp]
call	_sin
mov	ecx, DWORD PTR _m_rcScroll+12
mov	edx, DWORD PTR _m_rcClient+12
lea	eax, [ecx+ecx]
sub	edx, eax
mov	eax, ecx
sar	eax
sar	edx
add	edx, eax
push	edx
fild	DWORD PTR [esp]
add	esp, 4
fnstcw	WORD PTR [esp+60]
mov	eax, DWORD PTR [esp+60]
mov	DWORD PTR [esp+24], ebx
mov	DWORD PTR [esp+4], ebx
or	ax, 3072
inc	ebx
mov	WORD PTR [esp+58], ax
fmulp	st(1), st
mov	DWORD PTR [esp+32], 13369376
mov	DWORD PTR [esp+28], 0
mov	DWORD PTR [esp+12], 1
fldcw	WORD PTR [esp+58]
fistp	DWORD PTR [esp+52]
fldcw	WORD PTR [esp+60]
mov	eax, DWORD PTR [esp+52]
add	edx, eax
mov	DWORD PTR [esp+8], edx
mov	eax, DWORD PTR _m_hdcScroll
mov	DWORD PTR [esp+20], eax
lea	eax, [ecx+edx]
mov	edx, DWORD PTR _m_hdcSinus
mov	DWORD PTR [esp+16], eax
mov	DWORD PTR [esp], edx
call	_BitBlt@36
sub	esp, 36
cmp	ebx, DWORD PTR _m_rcClient+8
jl	L28
L31:
sub	DWORD PTR _m_nPixLeft, 2
mov	ebx, DWORD PTR _m_hwnd
mov	DWORD PTR [esp], ebx
call	_GetDC@4
sub	esp, 4
mov	ebx, eax
test	eax, eax
je	L17
mov	DWORD PTR [esp+32], 13369376
mov	ecx, DWORD PTR _m_hdcSinus
mov	edx, DWORD PTR _m_rcClient+12
mov	DWORD PTR [esp+28], 0
mov	DWORD PTR [esp+20], ecx
mov	ecx, DWORD PTR _m_rcClient+8
mov	DWORD PTR [esp+16], edx
mov	DWORD PTR [esp+24], 0
mov	DWORD PTR [esp+12], ecx
mov	DWORD PTR [esp+8], 0
mov	DWORD PTR [esp+4], 0
mov	DWORD PTR [esp], eax
call	_BitBlt@36
mov	edx, DWORD PTR _m_hwnd
sub	esp, 36
mov	DWORD PTR [esp+4], ebx
mov	DWORD PTR [esp], edx
call	_ReleaseDC@8
sub	esp, 8
L17:
add	esp, 72
pop	ebx
ret
L20:
test	edx, edx
js	L34
mov	eax, DWORD PTR _m_nSinusOffset
jmp	L21
L34:
mov	eax, DWORD PTR _m_nSinusOffset
test	eax, eax
jns	L21
mov	ecx, 719
mov	eax, 719
mov	DWORD PTR _m_nSinusOffset, ecx
jmp	L21
L33:
mov	DWORD PTR [esp], OFFSET FLAT:_m_szText
call	_strlen
mov	edx, DWORD PTR _m_nTextPos
cmp	edx, eax
jl	L19
xor	eax, eax
xor	edx, edx
mov	DWORD PTR _m_nTextPos, eax
L19:
movzx	ecx, BYTE PTR _m_szText[edx]
lea	ebx, [edx+1]
mov	edx, DWORD PTR _m_rcScroll+8
mov	DWORD PTR _m_nTextPos, ebx
mov	ebx, DWORD PTR _m_rcScroll+4
mov	BYTE PTR [esp+63], cl
mov	ecx, DWORD PTR _m_rcScroll+12
mov	DWORD PTR [esp+12], edx
mov	edx, DWORD PTR _m_hdcScroll
mov	DWORD PTR [esp+16], ecx
mov	ecx, DWORD PTR _m_rcClient+8
mov	DWORD PTR [esp], edx
mov	DWORD PTR [esp+8], ebx
mov	DWORD PTR [esp+4], ecx
mov	DWORD PTR [esp+20], 66
call	_PatBlt@24
sub	esp, 24
mov	ecx, DWORD PTR _m_hdcScroll
lea	ebx, [esp+64]
mov	DWORD PTR [esp+12], ebx
lea	ebx, [esp+63]
mov	DWORD PTR [esp+4], ebx
mov	DWORD PTR [esp], ecx
mov	DWORD PTR [esp+8], 1
call	_GetTextExtentPoint32A@16
sub	esp, 16
mov	edx, DWORD PTR _m_rcScroll+4
mov	ecx, DWORD PTR _m_hdcScroll
mov	DWORD PTR [esp+12], ebx
mov	ebx, DWORD PTR _m_rcClient+8
mov	DWORD PTR [esp+8], edx
mov	DWORD PTR [esp+16], 1
mov	DWORD PTR [esp+4], ebx
mov	DWORD PTR [esp], ecx
call	_TextOutA@20
sub	esp, 20
mov	edx, DWORD PTR [esp+64]
mov	DWORD PTR _m_nPixLeft, edx
jmp	L18

Sans parler des performances, je trouve déjà sa version plus digeste lol Je te fais confiance pour l'évaluation des perfs, là çà dépasse mon niveau en assembleur !

BruNews Messages postés 21040 Date d'inscription jeudi 23 janvier 2003 Statut Modérateur Dernière intervention 21 août 2019
19 sept. 2003 à 21:45

_c$55848 = -13 ; size = 1
tv262 -12 ; size 4
_y$55865 -8 ; size 4
_size$55850 -8 ; size 8
?sinScroll@@YGXXZ PROC NEAR
mov eax, DWORD PTR ?m_nPixLeft@@3HA
sub esp, 16
test eax, eax
push ebp
push esi
mov esi, DWORD PTR __imp__PatBlt@24
jg $L55845
mov eax, OFFSET FLAT:?m_szText@@3PADA
lea edx, DWORD PTR [eax+1]
$L56033:
mov cl, BYTE PTR [eax]
inc eax
test cl, cl
jne SHORT $L56033
mov ecx, DWORD PTR ?m_nTextPos@@3HA
sub eax, edx
cmp ecx, eax
jl SHORT $L55847
xor ecx, ecx
$L55847:
mov al, BYTE PTR ?m_szText@@3PADA[ecx]
mov edx, DWORD PTR ?m_rcScroll@@3UtagRECT@@A+8
inc ecx
push 66
mov DWORD PTR ?m_nTextPos@@3HA, ecx
mov ecx, DWORD PTR ?m_rcScroll@@3UtagRECT@@A+12
push ecx
mov ecx, DWORD PTR ?m_rcClient@@3UtagRECT@@A+8
push edx
mov edx, DWORD PTR ?m_hdcScroll@@3PAUHDC__@@A
mov BYTE PTR _c$55848[esp+36], al
mov eax, DWORD PTR ?m_rcScroll@@3UtagRECT@@A+4
push eax
push ecx
push edx
call esi
mov edx, DWORD PTR ?m_hdcScroll@@3PAUHDC__@@A
lea eax, DWORD PTR _size$55850[esp+24]
push eax
push 1
lea ecx, DWORD PTR _c$55848[esp+32]
push ecx
push edx
call DWORD PTR __imp__GetTextExtentPoint32A@16
mov ecx, DWORD PTR ?m_rcScroll@@3UtagRECT@@A+4
mov edx, DWORD PTR ?m_rcClient@@3UtagRECT@@A+8
push 1
lea eax, DWORD PTR _c$55848[esp+28]
push eax
mov eax, DWORD PTR ?m_hdcScroll@@3PAUHDC__@@A
push ecx
push edx
push eax
call DWORD PTR __imp__TextOutA@20
mov ecx, DWORD PTR _size$55850[esp+24]
mov DWORD PTR ?m_nPixLeft@@3HA, ecx
$L55845:
mov eax, DWORD PTR ?m_hdcScroll@@3PAUHDC__@@A
mov edx, DWORD PTR ?m_rcScroll@@3UtagRECT@@A+12
mov ecx, DWORD PTR ?m_rcScroll@@3UtagRECT@@A+8
mov ebp, DWORD PTR __imp__BitBlt@36
push 13369376
push 0
push 2
push eax
push edx
add ecx, -2
push ecx
push 0
push 0
push eax
call ebp
mov edx, DWORD PTR ?m_rcClient@@3UtagRECT@@A+12
mov eax, DWORD PTR ?m_rcClient@@3UtagRECT@@A+8
mov ecx, DWORD PTR ?m_hdcSinus@@3PAUHDC__@@A
push 66
push edx
push eax
push 0
push 0
push ecx
call esi
mov eax, DWORD PTR ?m_nSinusOffset@@3HA
mov ecx, DWORD PTR ?m_nSinusSpeed@@3HA
add eax, ecx
test ecx, ecx
mov DWORD PTR ?m_nSinusOffset@@3HA, eax
jle SHORT $L56039
cmp eax, 720
jl SHORT $L56038
xor eax, eax
jmp SHORT $L56040
$L56038:
test ecx, ecx
$L56039:
jge SHORT $L55858
test eax, eax
jge SHORT $L55858
mov eax, 719
$L56040:
mov DWORD PTR ?m_nSinusOffset@@3HA, eax
$L55858:
mov ecx, DWORD PTR ?m_rcClient@@3UtagRECT@@A+8
push edi
xor edi, edi
test ecx, ecx
mov DWORD PTR ?m_nSinusPos@@3HA, eax
jle $L55862
push ebx
jmp SHORT $L55860
$L56037:
mov eax, DWORD PTR ?m_nSinusPos@@3HA
npad 6
$L55860:
inc eax
cmp eax, 720
mov DWORD PTR ?m_nSinusPos@@3HA, eax
jl SHORT $L55863
xor eax, eax
mov DWORD PTR ?m_nSinusPos@@3HA, eax
$L55863:
sar eax, 1
mov DWORD PTR tv262[esp+32], eax
fild DWORD PTR tv262[esp+32]
mov ebx, DWORD PTR ?m_rcScroll@@3UtagRECT@@A+12
mov esi, DWORD PTR ?m_rcClient@@3UtagRECT@@A+12
lea edx, DWORD PTR [ebx+ebx]
fmul QWORD PTR __real@3f91df46a25ca311
sub esi, edx
mov ecx, ebx
fsin
sar ecx, 1
sar esi, 1
add esi, ecx
mov DWORD PTR _y$55865[esp+32], esi
fimul DWORD PTR _y$55865[esp+32]
call __ftol2
mov edx, DWORD PTR ?m_hdcScroll@@3PAUHDC__@@A
push 13369376
push 0
push edi
add esi, eax
mov eax, DWORD PTR ?m_hdcSinus@@3PAUHDC__@@A
push edx
add ebx, esi
push ebx
push 1
push esi
push edi
push eax
call ebp
mov eax, DWORD PTR ?m_rcClient@@3UtagRECT@@A+8
inc edi
cmp edi, eax
jl $L56037
pop ebx
$L55862:
mov esi, DWORD PTR ?m_nPixLeft@@3HA
mov ecx, DWORD PTR ?m_hwnd@@3PAUHWND__@@A
sub esi, 2
push ecx
mov DWORD PTR ?m_nPixLeft@@3HA, esi
call DWORD PTR __imp__GetDC@4
mov esi, eax
test esi, esi
pop edi
je SHORT $L55869
mov edx, DWORD PTR ?m_hdcSinus@@3PAUHDC__@@A
mov eax, DWORD PTR ?m_rcClient@@3UtagRECT@@A+12
mov ecx, DWORD PTR ?m_rcClient@@3UtagRECT@@A+8
push 13369376
push 0
push 0
push edx
push eax
push ecx
push 0
push 0
push esi
call ebp
mov edx, DWORD PTR ?m_hwnd@@3PAUHWND__@@A
push esi
push edx
call DWORD PTR __imp__ReleaseDC@8
$L55869:
pop esi
pop ebp
add esp, 16
ret 0
?sinScroll@@YGXXZ ENDP

cs_Nebula Messages postés 787 Date d'inscription samedi 8 juin 2002 Statut Membre Dernière intervention 7 juin 2007 2
19 sept. 2003 à 21:41

Ok, je vais faire pareil !

BruNews Messages postés 21040 Date d'inscription jeudi 23 janvier 2003 Statut Modérateur Dernière intervention 21 août 2019
19 sept. 2003 à 21:33

oui bien entendu, je ne suis pas actionnaire chez MS. Ce serait interessant de voir, j'ai meme une idee de ce qu'on peut essayer.
ABOUTBOX SINUSOID a une mechante boucle de calcul:
void sinScroll(), on se la publie ici tous les 2 depuis le PROC jusqu'au ENDP, ok ? on vire les lignes vides etc pour reduire, je prepare.

cs_Nebula Messages postés 787 Date d'inscription samedi 8 juin 2002 Statut Membre Dernière intervention 7 juin 2007 2
19 sept. 2003 à 21:21

BruNews > c'est pas pour faire chier mais on pourrait comparer les sorties asm de MSVC et GCC ? histoire de voir les différences :p

BruNews Messages postés 21040 Date d'inscription jeudi 23 janvier 2003 Statut Modérateur Dernière intervention 21 août 2019
19 sept. 2003 à 21:19

Tout a fait d'accord avec Kaid, VC++ 2003 possede un compilo superbe, y a pas que le rad de bien. Pour s'en convaincre suffit d'editer la sortie asm generee en modifiant les options, il obeit impec et produit un code difficile a battre, rien a voir avec la version 6.

cs_Nebula Messages postés 787 Date d'inscription samedi 8 juin 2002 Statut Membre Dernière intervention 7 juin 2007 2
19 sept. 2003 à 21:09

Kaid> Sympa le lien en effet ! Et un avantage indéniable de MSVC, c'est effectivement son support de Windows (normal, non ? il est édité par la société conceptrice de l'OS), tout comme GCC trouve sa place sous Linux...

Perso j'utilise GCC sous Windows uniquement parce qu'il est gratuit, mais bon plus je m'en sers et moins il me déçoit ce petit... Il ne lui manque qu'un environnement RAD et tout serait parfait ;)

Quand à Borland, c'est une bouse (du moins la version gratuite en ligne de commande), il est incapable de faire des applis de moins de 40Ko. (même un int main(void) { return 0; } !!!)

cs_Kaid Messages postés 949 Date d'inscription mardi 2 octobre 2001 Statut Membre Dernière intervention 8 juillet 2006 1
19 sept. 2003 à 21:03

BumpMANN >> Nebula >> Je ne suis pas d'accord avec toi BumpMANN, VC++ est certainement le meilleur environnement de dév. et compilateur pour faire du développement Windows.
Ce n'est pas un produit que Microsoft a imposé comme IE ou le Media Player, les gens ont le choix et VC++ doit être plus utilisé qu'une solution Borland ou des portages de GCC en Win32.

cs_Kaid Messages postés 949 Date d'inscription mardi 2 octobre 2001 Statut Membre Dernière intervention 8 juillet 2006 1
19 sept. 2003 à 20:59

Nebula >> Il suffit, pour les versions 2002 et 2003 de Visual C++ en tout cas, d'aller dans les options de compilation du projet et de faire 'F1' sur une ligne choisie pour avoir une page d'aide.

cs_Nebula Messages postés 787 Date d'inscription samedi 8 juin 2002 Statut Membre Dernière intervention 7 juin 2007 2
19 sept. 2003 à 20:59

Kaid > je fonce jeter un oeil, merci ! mais j'ai compris et adapté à partir de la source de ziko, avant je connaissais que de nom sans connaitre le principe :s

cs_Nebula Messages postés 787 Date d'inscription samedi 8 juin 2002 Statut Membre Dernière intervention 7 juin 2007 2
19 sept. 2003 à 20:57

BumpMANN> Sérieux ??? Hallucinant :| Pour l'éditeur je sais pas, je m'en suis jamais servi, j'utilise un programme que j'ai codé en Delphi y'a un moment (enfin codé... j'ai utilisé un composant quoi... lol)

cs_Kaid Messages postés 949 Date d'inscription mardi 2 octobre 2001 Statut Membre Dernière intervention 8 juillet 2006 1
19 sept. 2003 à 20:56

Nebula >> Oui mais il faudrait connaitre l'ensemble des paramètres qu'utilise GCC pour tunner comme il faut la compilation sous VC++.
Sinon je viens de trouver un lien où tout est bien mieux expliqué qu'ici: http://www.securiteinfo.com/attaques/hacking/buff.shtml

cs_Nebula Messages postés 787 Date d'inscription samedi 8 juin 2002 Statut Membre Dernière intervention 7 juin 2007 2
19 sept. 2003 à 20:55

C'est sûr, mais de toute façon je ne garde le frame pointer que durant le développement et je le vire pour compiler les release... J'ai épluché toute la doc de GCC pour savoir quelles étaient les meilleures optimisations possibles et surtout, stables... Çà m'a pris une après-midi, mais je ne le regrette pas :p

D'ailleurs, une question en passant : sous MSVC, les options de compilation/liaison sont documentées ou non ?

Sans être parano j'aime pas ne pas pouvoir mettre mes mimines dans le cambouis ;)

BumpMANN Messages postés 330 Date d'inscription jeudi 22 mai 2003 Statut Membre Dernière intervention 26 janvier 2009
19 sept. 2003 à 20:52

Nebula > biensur qu'il y'a pas que vc++ dans la vie!! au contraire vc++ est nul comme compilateur, mais bien comme éditeur!

genre il ne peut pas écrire dans un pointeur directement ("*p+=4;" marcherais pas, il mettrait illegal chéputrokoi (c'est microsoft hein!))

BruNews Messages postés 21040 Date d'inscription jeudi 23 janvier 2003 Statut Modérateur Dernière intervention 21 août 2019
19 sept. 2003 à 20:46

Nebula, si une stackframe a ses avantages, il y a aussi l'enorme inconvenient d'avoir un registre de moins pour les calculs donc + d'acces memoire.

cs_Nebula Messages postés 787 Date d'inscription samedi 8 juin 2002 Statut Membre Dernière intervention 7 juin 2007 2
19 sept. 2003 à 20:43

Kaid > Ma version (commentaire n°5) tourne sur GCC, avec une application console tout ce qu'il y a de 32 bits. Je suis sûr qu'en l'adaptant un peu on peut la faire tourner sur MSVC...

Mais c'est clair que si çà ne fonctionnait qu'en DOS, bôf !

cs_Kaid Messages postés 949 Date d'inscription mardi 2 octobre 2001 Statut Membre Dernière intervention 8 juillet 2006 1
19 sept. 2003 à 20:40

Nebula >> Enfin il est vrai que si ce programme ne marche qu'en 16 bits DOS il a intérêt plutôt limité non ?

cs_Nebula Messages postés 787 Date d'inscription samedi 8 juin 2002 Statut Membre Dernière intervention 7 juin 2007 2
19 sept. 2003 à 20:38

Y'a pas que VC++ dans la vie.

BumpMANN Messages postés 330 Date d'inscription jeudi 22 mai 2003 Statut Membre Dernière intervention 26 janvier 2009
19 sept. 2003 à 16:10

De toute facon ca marche pas sur vc++... bye!

Kuuuuuuupo ^^

cs_JCDjcd Messages postés 1138 Date d'inscription mardi 10 juin 2003 Statut Membre Dernière intervention 25 janvier 2009 4
18 sept. 2003 à 17:18

Ah merci , je fais donc laisser tomber.

BruNews Messages postés 21040 Date d'inscription jeudi 23 janvier 2003 Statut Modérateur Dernière intervention 21 août 2019
18 sept. 2003 à 14:54

JCDjcd, te prends pas le crane avec cela, c'etait cense provoque un saut d'instruction precis provoque en externe, il se trouve que c'est un peu plus complique que cela a effectuer.

cs_JCDjcd Messages postés 1138 Date d'inscription mardi 10 juin 2003 Statut Membre Dernière intervention 25 janvier 2009 4
18 sept. 2003 à 14:44

Mais tout depend du mode de compilation, il y en a ou le premier argument est passer dans le pile, et d'autre ou le premier argument dans un des registres du mircoprocesseur, et est donc pas dans la pile.

Je voudrais comme meme poser un question :
a quoi ca sert ??

Parceque moi j'ai mieux:

goto toto;
var=1;
toto:

cs_Nebula Messages postés 787 Date d'inscription samedi 8 juin 2002 Statut Membre Dernière intervention 7 juin 2007 2
18 sept. 2003 à 08:55

c'est sûr que si on le met directement en assembleur... lol

en tout cas j'ai compris pourquoi GCC sauvait esp puis utilisait ebp tout au long du programme, puisque çà gagne un octet :)

zikoasm Messages postés 15 Date d'inscription mercredi 3 septembre 2003 Statut Membre Dernière intervention 25 juin 2005
17 sept. 2003 à 23:16

je crois qu il vaut mieux enleve le buffer2 et ajouter un 6 p=buffer1+6
pour que sa puisse marcher sur un autre compilateur mais je ne suis pas sur mais avant tout faite le sur un turboc3 est vous allez voir que sa marche tres bien.

BumpMANN Messages postés 330 Date d'inscription jeudi 22 mai 2003 Statut Membre Dernière intervention 26 janvier 2009
17 sept. 2003 à 22:59

Psycopathe va ^^

c'est même plus un travail de mog! kubo!!!!

BruNews Messages postés 21040 Date d'inscription jeudi 23 janvier 2003 Statut Modérateur Dernière intervention 21 août 2019
17 sept. 2003 à 22:53

option casemap :none
option prologue:none
option epilogue:none

include masm32includewindows.inc
include masm32includekernel32.inc
include masm32includeuser32.inc

includelib masm32libkernel32.lib
includelib masm32libuser32.lib

include masm32nLib32nLib32.inc
includelib masm32nLib32nLib32.lib

.data
szbuff DB 24 dup(0)
szappname DB "Taille",0

.code
start:
ALIGN 4
jmp short debut
label1:
mov dword ptr[esp], 0
label2:
mov dword ptr[esp-4], 0
label3:
mov dword ptr[ebp], 0
label4:
mov dword ptr[ebp-4], 0
debut:
mov eax, label2 - label1
mov ecx, offset szbuff
call ultoa
push 0
push offset szappname
push offset szbuff
push 0
call MessageBox

mov eax, label3 - label2
mov ecx, offset szbuff
call ultoa
push 0
push offset szappname
push offset szbuff
push 0
call MessageBox

mov eax, label4 - label3
mov ecx, offset szbuff
call ultoa
push 0
push offset szappname
push offset szbuff
push 0
call MessageBox

mov eax, debut - label4
mov ecx, offset szbuff
call ultoa
push 0
push offset szappname
push offset szbuff
push 0
call MessageBox

progEnd:
push 0
call ExitProcess
end start

RESULTATS des tailles d'instructions:
mov dword ptr[esp], 0 DONNE 7
mov dword ptr[esp-4], 0 DONNE 8
mov dword ptr[ebp], 0 DONNE 7
mov dword ptr[ebp-4], 0 DONNE 7 donc + court avec ebp
SALUT a tous.

cs_JCDjcd Messages postés 1138 Date d'inscription mardi 10 juin 2003 Statut Membre Dernière intervention 25 janvier 2009 4
17 sept. 2003 à 18:59

Heu ... ca fais un Unhandel Exception sur "var = 0;" !!!!

BumpMANN Messages postés 330 Date d'inscription jeudi 22 mai 2003 Statut Membre Dernière intervention 26 janvier 2009
17 sept. 2003 à 15:57

d'accooooord. (j'y pensait plus aux compilateurs :S )

Kuuuuuuuuuupooooooo !!!!! allez a + !!

cs_Nebula Messages postés 787 Date d'inscription samedi 8 juin 2002 Statut Membre Dernière intervention 7 juin 2007 2
17 sept. 2003 à 15:47

JCDjcd> Si, le but est bien de sauter var=1. Toutefois, je pense que son code ne fonctionne que sous DOS (TurboC), l'instruction var=1 devant faire 4 octets. Sous Windows (BCC, MSVC, GCC...), elle doit en faire 6, sauf erreur de ma part. Essaie plutôt avec mon programme (commentaire n°5), qui a été adapté à Windows.

BumpMANN> ma version fonctionne chez moi, la sienne fonctionne chez lui... tout dépend du compilateur utilisé, le code généré n'ayant probablement pas la même taille, et sauter arbitrairement 4 ou 7 octets dans ces conditions est suicidaire... c'est d'ailleurs la raison pour laquelle j'ai donné la ligne de compilation exacte du code : pour essayer de rendre cette astuce reproductible.

A+

BumpMANN Messages postés 330 Date d'inscription jeudi 22 mai 2003 Statut Membre Dernière intervention 26 janvier 2009
17 sept. 2003 à 15:39

JCDjcd > c'est pour ca que je disais que c'est mal écrit. le prog de marche même pas. il explique c'est tout.

sinon effectivement un long, 4 octels

cs_JCDjcd Messages postés 1138 Date d'inscription mardi 10 juin 2003 Statut Membre Dernière intervention 25 janvier 2009 4
17 sept. 2003 à 15:30

Des que je quitte ton programme, mon PC se comporte bizzatrement ... ton programme bug ...

De plus : il manque l'inclusion de conio.h et le cast pour le p=(int*)buffer+12

cs_JCDjcd Messages postés 1138 Date d'inscription mardi 10 juin 2003 Statut Membre Dernière intervention 25 janvier 2009 4
17 sept. 2003 à 15:25

Je ne comprend pas , le but n'est pas de suter la ligne "var=1;" ?

parceque moi a l'ecran il y a :
*****************
100
var = 1
*****************

Donc je comprend RIEN ...

cs_Nebula Messages postés 787 Date d'inscription samedi 8 juin 2002 Statut Membre Dernière intervention 7 juin 2007 2
17 sept. 2003 à 14:44

Je pense que BumpMANN t'a fait cette remarque à cause du void main(). Il est vrai qu'il est plus propre d'écrire int main(), mais de toute façon la plupart des compilateurs traduisent le void main() en un int main() retournant 0, donc bôf.

De plus, l'emploi des éléments entre accolades pour initialiser un tableau doit être spécifique à ton compilateur, en tout cas GCC n'en veut pas (erreur de dimension).

Par contre je n'ai plus Linux, donc si quelqu'un pouvait essayer mon code et nous dire le résultat, ce serait sympa :)

zikoasm Messages postés 15 Date d'inscription mercredi 3 septembre 2003 Statut Membre Dernière intervention 25 juin 2005
17 sept. 2003 à 13:56

je m'excuse pour cbibi parsqu il est debutant mais pour d'autre mon programme est tres simple.
mon programme est bien ecrie et il marche tres bien.si vous etes null en langage C c'est pas mon probleme.
merci pour les intervention de nebula tu as fais une compilation sur linux,sa marche tres bien?

cs_cbibi Messages postés 112 Date d'inscription mardi 24 juin 2003 Statut Membre Dernière intervention 11 novembre 2007
17 sept. 2003 à 11:43

A rien pigé moi ..... Et vous appeler sa du code-source niveau 1 ...
C'est par ce que c'est cour que c simple :(

cs_Nebula Messages postés 787 Date d'inscription samedi 8 juin 2002 Statut Membre Dernière intervention 7 juin 2007 2
17 sept. 2003 à 08:59

BumpMANN : archi faux, sur un 8088, un int fait deux octets (16 bits) alors que sur un itanium, il en fait 8 (64 bits)... Quand à int et long, sur un 32 bits, c'est la même chose (vérifie le si tu me crois pas)

#include <stdio.h>
#include <limits.h>

int main(void) {
  printf("sizeof(char) = %i (%i a %i)
", sizeof(char), SCHAR_MIN, SCHAR_MAX);
  printf("sizeof(short) = %i (%i a %i)
", sizeof(short), SHRT_MIN, SHRT_MAX);
  printf("sizeof(int) = %i (%i a %i)
", sizeof(int), INT_MIN, INT_MAX);
  printf("sizeof(long) = %i (%li a %li)
", sizeof(long), LONG_MIN, LONG_MAX);
  return 0;
}

ce qui donne :

sizeof(char) = 1 (-128 a 127)
sizeof(short) = 2 (-32768 a 32767)
sizeof(int) = 4 (-2147483648 a 2147483647)
sizeof(long) = 4 (-2147483648 a 2147483647)

BumpMANN Messages postés 330 Date d'inscription jeudi 22 mai 2003 Statut Membre Dernière intervention 26 janvier 2009
17 sept. 2003 à 01:16

Rappel:

char, unsigned char, signed char 1 octel (8bits)
short, unsigned short 2 octels (16bits)
int, unsigned int 4 octels (32bits)
long, unsigned long 8 octels (64bits)
float 4 octels (32bits)
double 8 octels (64bits)
long double 8 octels (64bits)

n'oubliez pas aussi __int8,__int16,__int32,et __int64. Utile.

Voila. Juste un pitit commentaire: le code en haut est mal écrit.

Mais sinon effectivement ca explique des trucs,c'est bien...

zikoasm Messages postés 15 Date d'inscription mercredi 3 septembre 2003 Statut Membre Dernière intervention 25 juin 2005
16 sept. 2003 à 19:19

j'ai jamais dis qu'un var=1 est code sur 1 octet,j'ai dis 4 octets et peut etre plus comme nbula a dis.j'utilise comme compilateur turboc3 de borland.
pour monsieur JCDjcd il faut que vous faite un sizeof(*int) est vous allez voir que sa prend 2 octets et si je me trompe pas sa change selon le compilateur et la machine.

cs_Nebula Messages postés 787 Date d'inscription samedi 8 juin 2002 Statut Membre Dernière intervention 7 juin 2007 2
16 sept. 2003 à 17:42

jcd : je ne sais pas si var=1 prend un octet, mais je sais que sa traduction en assembleur doit en prendre 6... d'ou le +7, on se positionne au 7e octet qui suit l'appel de skip...

pour exemple, le code assembleur généré par GCC :

/* on appelle notre fonction skip */
call	_skip
/* var = 0, 6 octets en assembleur */
mov	DWORD PTR [ebp-4], 0
/* la suite au 7e octet suivant le call _skip */
mov	eax, DWORD PTR [ebp-4]

c'est plus clair ? :)

cs_Nebula Messages postés 787 Date d'inscription samedi 8 juin 2002 Statut Membre Dernière intervention 7 juin 2007 2
16 sept. 2003 à 17:25

Hum...

Après pas mal de tests et passages sous GDB, j'ai réussi à faire marcher ton code avec GCC (MinGW/3.3.1), voici le code (les valeurs hexadécimales utilisées ne sont que des drapeaux pour les reconnaitre facilement dans un dump hexadécimal) :

#include <stdio.h>

void skip(int a) {
  int* p = NULL;
  p = &a - 1;
  fprintf(stderr, "ancienne valeur de ret : 0x%x
", *p);
  *p += 7;
  fprintf(stderr, "nouvelle valeur de ret : 0x%x
", *p);
}

int main(void) {
  unsigned int var = 0x33333333;
  fprintf(stderr, "var = 0x%x
",var);
  skip(0x11223344);
  var = 0x00000000;
  fprintf(stderr, "var = 0x%x
",var);
  return 0;
}

La sortie donne, avec frame pointer :

var = 0x33333333
ancienne valeur de ret : 0x4013af
nouvelle valeur de ret : 0x4013b6
var = 0x33333333

et sans frame pointer :

var = 0x33333333
ancienne valeur de ret : 0x4013b5
nouvelle valeur de ret : 0x4013bc
var = 0x33333333

Ce code ne dépend donc pas du frame pointer, mais en revanche il dépend très fortement du niveau d'optimisation du compilateur...

En -O0 (aucune optimisation), tout fonctionne, mais dès qu'on active les optimisations, les tailles et l'ordre des instructions changent et rendent le code inefficace (soit çà finit sur une access violation, soit par une valeur totalement aléatoire pour var).

C'est intéressant au niveau théorique, pour voir les faiblesses d'une architecture, mais je ne sais pas si c'est vraiment utile en pratique ?

Si quelqu'un pouvait me dire si ce code marche sur d'autres compilateurs, ce serait sympa :) Il serait également intéressant de tester une compilation sous linux...

Voici les lignes de compilation que j'ai utilisées :
gcc -s -O0 -Wall -W test.c
gcc -s -O0 -Wall -W test.c -fomit-frame-pointer

A+

cs_JCDjcd Messages postés 1138 Date d'inscription mardi 10 juin 2003 Statut Membre Dernière intervention 25 janvier 2009 4
16 sept. 2003 à 17:21

Petite precision :
un int ne fais pas 2 octets, mais 4 octets
Pour est plus sure il faut faire sizeof(int).

Sinon, comment savez-vous que var=1 prend 1 octets ???
Et une autre question, c'est quoi l'utilite ?

cs_Kaid Messages postés 949 Date d'inscription mardi 2 octobre 2001 Statut Membre Dernière intervention 8 juillet 2006 1
16 sept. 2003 à 12:15

vecchio56 >> En beaucoup plus simple: lorsque tu appelles une fonction dans ton programme, l'adresse courante (c'est-à-dire l'adresse où l'on n'appelle la fonction) est empilée sur le stack. Idem pour les paramètres passées à la fonction qui sont eux aussi empilés. L'idée ici est de modifier l'adresse d'où est appellée la fonction dans la pile pour qu'au retour de la fonction on ne retombe par sur nos pieds mais à la prochaine instruction.

zikoasm >> Pourrais-tu préciser quel compilateur il faut utiliser et quel environnement pour qu'on puisse tester si ca marche vraiment.

zikoasm Messages postés 15 Date d'inscription mercredi 3 septembre 2003 Statut Membre Dernière intervention 25 juin 2005
16 sept. 2003 à 02:19

Je suis désole pour ce petit problème belle 89 ans ;) .J’ai fais une mise en forme a mon commentaire et je l’ai met sur le fichier zip, en plus de cela je crois qu’il vaut mieux de me pose des questions directes.Sa me ferais plaisir de vous répondre et de développer ma source avec vous.

vecchio56 Messages postés 6535 Date d'inscription lundi 16 décembre 2002 Statut Membre Dernière intervention 22 août 2010 14
15 sept. 2003 à 12:11

commentaire: j'ai rien compris

BUFFER OVERFLOW ET LA PILE

Votre réponse

Discussions similaires