Pourquoi?
Parce qu'il y a une différence entre constante et variable.
Et je me répète : vas plus lentement. Laisse l'analyse.
Bug V5.50 x64 ?
Re: Bug V5.50 x64 ?
GG Dr @ollivier , c est un bug
Code : Tout sélectionner
;****************************************************/************************
;asm code gen by x64dbg
mov qword ptr ss:[rsp+8],rcx; $par1 = @""
push r15 ; stack - 8 :: var1
xor rax,rax
push rax ; stack - 8 :: var2
sub rsp,28 ; stack - 0x28
mov rax,sss.140005020 ; rax = sss.140005020 = ""
mov r15,rax ; r15 = ""
;/!\i/!\ here the error why push ? /!\i/!\
push qword ptr ds:[1400051E0] ; push Constant var
mov rcx,sss.140005020; $par1 = @""
sub rsp,28;allocate memory for call
call sss.1400020C0 ; call Procedure create_string_and_paste($par1)
add rsp,28
sub r15,qword ptr ss:[rsp+48];@"" - *Q
mov qword ptr ss:[rsp+30],r15,sav...
xor rax,rax,return = 0
add rsp,30 ; stack + 0x28 + push rax :: add 8 to fix bug
pop r15; stack + 8
ret ;goto addr = [stack]
;END
.....i Love Pb
Re: Bug V5.50 x64 ?
Dr : Abbréviation de... de Docteur. Donc << Docteur @ollivier >>.Celtic88 a écrit :GG Dr @ollivier , c est un bug
Je vais montrer moi un truc qui va vite fait redescendre le bonhomme que je suis. Tu vas voir, c'est simple !
Le 2 Septembre 2018, à midi et sept minutes...
Quand tu auras vu un Docteur écrire comme ça, fais tes points de suture toi-même : faut pas qu'il te touche le Docteur !!!Docteur Ollivier, diplômé en concentré ès pur jus de la faculté Pulco (Etat du Aqua à côté le Mas-à-chaussettes Institute) a écrit :2) Do each word be different of all the other one ?
M'enfin, content de te voir participer. Ça permet de voir DebugGen64 à l'oeuvre.
La soluce actuelle : laisser @"" tout seul comme ça:
Code : Tout sélectionner
*Void = @""
Et surtout, ne pas balancer ce pointeur à une DLL dont on n'est pas l'auteur : ça fout à poil toutes les données des chaînes présentes dans le code source.
Préférez un *JeSuisMoinsGrillé = AllocateMemory(StringByteLength(MaChaîne + " ") )
Avec copie mémoire
Avec isolation de la pile par modification de RSP
Avec... Oh et puis zut hein : faites du OpenSource, c'est plus serein !
Re: Bug V5.50 x64 ?
je confirme lol , et je suis loin d'être mieu que toi dans ce casDr : Abbréviation de... de Docteur. Donc << Docteur @ollivier >>.
Je vais montrer moi un truc qui va vite fait redescendre le bonhomme que je suis. Tu vas voir, c'est simple !
Le 2 Septembre 2018, à midi et sept minutes...
Code : Tout sélectionner
Quand tu auras vu un Docteur écrire comme ça, fais tes points de suture toi-même : faut pas qu'il te touche le Docteur !!!
pour moi c'est un bug sérieux !..
salutations..
.....i Love Pb
Re: Bug V5.50 x64 ?
Ce qui me complimente, c'est ta présence contributive : c'est très impressionnant.
Pour le reste, ce bug de gestion de pile n'est plus si sérieux que cela, dès lors qu'il existe une solide solution.
Et cette solution...... est solide puisque ça ne buguera jamais, et cela remplit bien le but recherché :
Enregistrer l'adresse mémoire d'une chaîne constante vide dans un code source, à l'endroit voulu dans ce code source.
Cela permet d'observer différentes choses actuellement, notamment qu'une chaîne semblable a toujours la même adresse : c'est une adresse dont l'évolution est propre à la session d'exécution.
On ne peut distinguer la session de compilation avec l'adresse d'une seule chaîne vide : il faut ajouter une autre chaîne dans le code sourceCeci permet de constater quereste constant. Cette constance quelqu'en soit l'exécution donne une configuration cadrée par la compilation.
C'est après quelques tests de contenus de chaînes, que l'on remarque que chaque adresse de chaîne correspond à un mapage dont les contenus servent de clés de hachage. Il y a un voisinage des adresses de chaînes. Je n'ai pas vérifié mais il me semble que les données (caractères) des chaînes sont contigües. Donc d'où cette situation où utiliser cet adressage doit rester contrôlé et ne pas circuler dans les arguments des appels de procédures externes non conformes.
Pour le reste, ce bug de gestion de pile n'est plus si sérieux que cela, dès lors qu'il existe une solide solution.
Et cette solution...
Code : Tout sélectionner
*pointeurZZ = @""
Enregistrer l'adresse mémoire d'une chaîne constante vide dans un code source, à l'endroit voulu dans ce code source.
Cela permet d'observer différentes choses actuellement, notamment qu'une chaîne semblable a toujours la même adresse : c'est une adresse dont l'évolution est propre à la session d'exécution.
On ne peut distinguer la session de compilation avec l'adresse d'une seule chaîne vide : il faut ajouter une autre chaîne dans le code source
Code : Tout sélectionner
*a0 = @""
*a1 = @"hello"
Code : Tout sélectionner
Delta01 = *a1 - *a0
C'est après quelques tests de contenus de chaînes, que l'on remarque que chaque adresse de chaîne correspond à un mapage dont les contenus servent de clés de hachage. Il y a un voisinage des adresses de chaînes. Je n'ai pas vérifié mais il me semble que les données (caractères) des chaînes sont contigües. Donc d'où cette situation où utiliser cet adressage doit rester contrôlé et ne pas circuler dans les arguments des appels de procédures externes non conformes.