impossible de modifier mon propre code dans la memoire
11 réponses
dark poulpo
bonjour, voila, je bosse sur une partie de ma protection, mais le hic est
que je narrive pas a modifier mon code en memoire, jai un access violation
qui apparait. je suis en c++, et jai deja verifie mes regsitres en debug
pour voir si les adresses a modifier etaient bien celle quil faut.
bonjour, voila, je bosse sur une partie de ma protection, mais le hic est que je narrive pas a modifier mon code en memoire, jai un access violation qui apparait. je suis en c++, et jai deja verifie mes regsitres en debug pour voir si les adresses a modifier etaient bien celle quil faut.
Bonjour,
La modification de code en mémoire n'est pas une pratique recommandée en Win32 et elle se justifie rarement, sauf éventuellement pour les jeux et la fabrication de virus. De plus, avec les processeurs modernes, cela oblige à une reset du cache (entre autres) et n'a peut-être pas les effets bénéfiques attendus sur les performances, au contraire. Toute auto-modification de code doit être suivie d'un appel à FlushInstructionCache .
Ceci dit, la méthode la plus largement admise est de copier le code dans un segment de données non protégé (voir VirtualProtect et / ou VirtualProtectEx) et de faire un jump sur cette zone.
Si vous faites une recherche sur Google ou Google Groups avec les mots-clé "Win32 self modifying code", vous trouverez un tas de discussion intéressantes à ce sujet.
-- Patrick Philippot - Microsoft MVP MainSoft Consulting Services www.mainsoft.fr
dark poulpo wrote:
bonjour, voila, je bosse sur une partie de ma protection, mais le hic
est que je narrive pas a modifier mon code en memoire, jai un access
violation qui apparait. je suis en c++, et jai deja verifie mes
regsitres en debug pour voir si les adresses a modifier etaient bien
celle quil faut.
Bonjour,
La modification de code en mémoire n'est pas une pratique recommandée en
Win32 et elle se justifie rarement, sauf éventuellement pour les jeux et
la fabrication de virus. De plus, avec les processeurs modernes, cela
oblige à une reset du cache (entre autres) et n'a peut-être pas les
effets bénéfiques attendus sur les performances, au contraire. Toute
auto-modification de code doit être suivie d'un appel à
FlushInstructionCache .
Ceci dit, la méthode la plus largement admise est de copier le code dans
un segment de données non protégé (voir VirtualProtect et / ou
VirtualProtectEx) et de faire un jump sur cette zone.
Si vous faites une recherche sur Google ou Google Groups avec les
mots-clé "Win32 self modifying code", vous trouverez un tas de
discussion intéressantes à ce sujet.
--
Patrick Philippot - Microsoft MVP
MainSoft Consulting Services
www.mainsoft.fr
bonjour, voila, je bosse sur une partie de ma protection, mais le hic est que je narrive pas a modifier mon code en memoire, jai un access violation qui apparait. je suis en c++, et jai deja verifie mes regsitres en debug pour voir si les adresses a modifier etaient bien celle quil faut.
Bonjour,
La modification de code en mémoire n'est pas une pratique recommandée en Win32 et elle se justifie rarement, sauf éventuellement pour les jeux et la fabrication de virus. De plus, avec les processeurs modernes, cela oblige à une reset du cache (entre autres) et n'a peut-être pas les effets bénéfiques attendus sur les performances, au contraire. Toute auto-modification de code doit être suivie d'un appel à FlushInstructionCache .
Ceci dit, la méthode la plus largement admise est de copier le code dans un segment de données non protégé (voir VirtualProtect et / ou VirtualProtectEx) et de faire un jump sur cette zone.
Si vous faites une recherche sur Google ou Google Groups avec les mots-clé "Win32 self modifying code", vous trouverez un tas de discussion intéressantes à ce sujet.
-- Patrick Philippot - Microsoft MVP MainSoft Consulting Services www.mainsoft.fr
adebaene
"Patrick Philippot" wrote in message news:<cg1jgf$1hlj$...
dark poulpo wrote: > bonjour, voila, je bosse sur une partie de ma protection, mais le hic > est que je narrive pas a modifier mon code en memoire, jai un access > violation qui apparait. je suis en c++, et jai deja verifie mes > regsitres en debug pour voir si les adresses a modifier etaient bien > celle quil faut.
Bonjour,
La modification de code en mémoire n'est pas une pratique recommandée en Win32 et elle se justifie rarement, sauf éventuellement pour les jeux
Pourquoi particulièrement pour les jeux??
et la fabrication de virus. De plus, avec les processeurs modernes, cela oblige à une reset du cache (entre autres) et n'a peut-être pas les effets bénéfiques attendus sur les performances, au contraire. Toute auto-modification de code doit être suivie d'un appel à FlushInstructionCache .
Ceci dit, la méthode la plus largement admise est de copier le code dans un segment de données non protégé (voir VirtualProtect et / ou VirtualProtectEx) et de faire un jump sur cette zone.
Notes que ces méthodes permettent aussi d'écraser du code existant (sans allouer un nouvelle page).
Arnaud
"Patrick Philippot" <patrick.philippot@mainsoft.xx> wrote in message news:<cg1jgf$1hlj$1@biggoron.nerim.net>...
dark poulpo wrote:
> bonjour, voila, je bosse sur une partie de ma protection, mais le hic
> est que je narrive pas a modifier mon code en memoire, jai un access
> violation qui apparait. je suis en c++, et jai deja verifie mes
> regsitres en debug pour voir si les adresses a modifier etaient bien
> celle quil faut.
Bonjour,
La modification de code en mémoire n'est pas une pratique recommandée en
Win32 et elle se justifie rarement, sauf éventuellement pour les jeux
Pourquoi particulièrement pour les jeux??
et
la fabrication de virus. De plus, avec les processeurs modernes, cela
oblige à une reset du cache (entre autres) et n'a peut-être pas les
effets bénéfiques attendus sur les performances, au contraire. Toute
auto-modification de code doit être suivie d'un appel à
FlushInstructionCache .
Ceci dit, la méthode la plus largement admise est de copier le code dans
un segment de données non protégé (voir VirtualProtect et / ou
VirtualProtectEx) et de faire un jump sur cette zone.
Notes que ces méthodes permettent aussi d'écraser du code existant
(sans allouer un nouvelle page).
"Patrick Philippot" wrote in message news:<cg1jgf$1hlj$...
dark poulpo wrote: > bonjour, voila, je bosse sur une partie de ma protection, mais le hic > est que je narrive pas a modifier mon code en memoire, jai un access > violation qui apparait. je suis en c++, et jai deja verifie mes > regsitres en debug pour voir si les adresses a modifier etaient bien > celle quil faut.
Bonjour,
La modification de code en mémoire n'est pas une pratique recommandée en Win32 et elle se justifie rarement, sauf éventuellement pour les jeux
Pourquoi particulièrement pour les jeux??
et la fabrication de virus. De plus, avec les processeurs modernes, cela oblige à une reset du cache (entre autres) et n'a peut-être pas les effets bénéfiques attendus sur les performances, au contraire. Toute auto-modification de code doit être suivie d'un appel à FlushInstructionCache .
Ceci dit, la méthode la plus largement admise est de copier le code dans un segment de données non protégé (voir VirtualProtect et / ou VirtualProtectEx) et de faire un jump sur cette zone.
Notes que ces méthodes permettent aussi d'écraser du code existant (sans allouer un nouvelle page).
Arnaud
Patrick Philippot
Arnaud Debaene wrote:
Pourquoi particulièrement pour les jeux??
Salut Arnaud,
J'ai dit ça par réflexe car souvent le portage des jeux du monde DOS vers le monde Windows / Win32 se fait (ou plutôt s'est fait) en essayant au maximum de reproduire l'environnement DOS et ses possibilités de programmation sauvage. C'est de moins en moins vrai. J'ai même encore sur mes étagères une bibliothèque 16-bit de compilation d'expressions régulières qui s'auto-modifie en mémoire. Je suppose que celui qui veut porter ce code à l'identique va devoir faire des choses intéressantes...
Donc j'aurais pu m'abstenir de cette remarque :-) .
-- Patrick Philippot - Microsoft MVP MainSoft Consulting Services www.mainsoft.fr
Arnaud Debaene wrote:
Pourquoi particulièrement pour les jeux??
Salut Arnaud,
J'ai dit ça par réflexe car souvent le portage des jeux du monde DOS
vers le monde Windows / Win32 se fait (ou plutôt s'est fait) en essayant
au maximum de reproduire l'environnement DOS et ses possibilités de
programmation sauvage. C'est de moins en moins vrai. J'ai même encore
sur mes étagères une bibliothèque 16-bit de compilation d'expressions
régulières qui s'auto-modifie en mémoire. Je suppose que celui qui veut
porter ce code à l'identique va devoir faire des choses intéressantes...
Donc j'aurais pu m'abstenir de cette remarque :-) .
--
Patrick Philippot - Microsoft MVP
MainSoft Consulting Services
www.mainsoft.fr
J'ai dit ça par réflexe car souvent le portage des jeux du monde DOS vers le monde Windows / Win32 se fait (ou plutôt s'est fait) en essayant au maximum de reproduire l'environnement DOS et ses possibilités de programmation sauvage. C'est de moins en moins vrai. J'ai même encore sur mes étagères une bibliothèque 16-bit de compilation d'expressions régulières qui s'auto-modifie en mémoire. Je suppose que celui qui veut porter ce code à l'identique va devoir faire des choses intéressantes...
Donc j'aurais pu m'abstenir de cette remarque :-) .
-- Patrick Philippot - Microsoft MVP MainSoft Consulting Services www.mainsoft.fr
dark poulpo
"Patrick Philippot" a écrit dans le message news: cg2hcj$21r7$
Arnaud Debaene wrote: > Pourquoi particulièrement pour les jeux??
Salut Arnaud,
J'ai dit ça par réflexe car souvent le portage des jeux du monde DOS vers le monde Windows / Win32 se fait (ou plutôt s'est fait) en essayant au maximum de reproduire l'environnement DOS et ses possibilités de programmation sauvage. C'est de moins en moins vrai. J'ai même encore sur mes étagères une bibliothèque 16-bit de compilation d'expressions régulières qui s'auto-modifie en mémoire. Je suppose que celui qui veut porter ce code à l'identique va devoir faire des choses intéressantes...
Donc j'aurais pu m'abstenir de cette remarque :-) .
-- Patrick Philippot - Microsoft MVP MainSoft Consulting Services www.mainsoft.fr
merci pour vos reponses, entre temps, je me suis penché sur le format PE pour les entetes de fichiers, et je n'ai pas encore verifier, j'attend d'ecrire un reader de format PE, mais si je change les caracteristiques de la section en rajoutant: IMAGE_SCN_CNT_CODE || IMAGE_SCN_MEM_EXECUTE || IMAGE_SCN_MEM_READ || IMAGE_SCN_MEM_WRITE il se pourait que je puisse ecrire dans la memoire dans la partie du code. A tester kan j'aurais du temps!!!
"Patrick Philippot" <patrick.philippot@mainsoft.xx> a écrit dans le message
news: cg2hcj$21r7$1@biggoron.nerim.net...
Arnaud Debaene wrote:
> Pourquoi particulièrement pour les jeux??
Salut Arnaud,
J'ai dit ça par réflexe car souvent le portage des jeux du monde DOS
vers le monde Windows / Win32 se fait (ou plutôt s'est fait) en essayant
au maximum de reproduire l'environnement DOS et ses possibilités de
programmation sauvage. C'est de moins en moins vrai. J'ai même encore
sur mes étagères une bibliothèque 16-bit de compilation d'expressions
régulières qui s'auto-modifie en mémoire. Je suppose que celui qui veut
porter ce code à l'identique va devoir faire des choses intéressantes...
Donc j'aurais pu m'abstenir de cette remarque :-) .
--
Patrick Philippot - Microsoft MVP
MainSoft Consulting Services
www.mainsoft.fr
merci pour vos reponses, entre temps, je me suis penché sur le format PE
pour les entetes de fichiers, et je n'ai pas encore verifier, j'attend
d'ecrire un reader de format PE, mais si je change les caracteristiques de
la section en rajoutant:
IMAGE_SCN_CNT_CODE || IMAGE_SCN_MEM_EXECUTE || IMAGE_SCN_MEM_READ ||
IMAGE_SCN_MEM_WRITE
il se pourait que je puisse ecrire dans la memoire dans la partie du code. A
tester kan j'aurais du temps!!!
"Patrick Philippot" a écrit dans le message news: cg2hcj$21r7$
Arnaud Debaene wrote: > Pourquoi particulièrement pour les jeux??
Salut Arnaud,
J'ai dit ça par réflexe car souvent le portage des jeux du monde DOS vers le monde Windows / Win32 se fait (ou plutôt s'est fait) en essayant au maximum de reproduire l'environnement DOS et ses possibilités de programmation sauvage. C'est de moins en moins vrai. J'ai même encore sur mes étagères une bibliothèque 16-bit de compilation d'expressions régulières qui s'auto-modifie en mémoire. Je suppose que celui qui veut porter ce code à l'identique va devoir faire des choses intéressantes...
Donc j'aurais pu m'abstenir de cette remarque :-) .
-- Patrick Philippot - Microsoft MVP MainSoft Consulting Services www.mainsoft.fr
merci pour vos reponses, entre temps, je me suis penché sur le format PE pour les entetes de fichiers, et je n'ai pas encore verifier, j'attend d'ecrire un reader de format PE, mais si je change les caracteristiques de la section en rajoutant: IMAGE_SCN_CNT_CODE || IMAGE_SCN_MEM_EXECUTE || IMAGE_SCN_MEM_READ || IMAGE_SCN_MEM_WRITE il se pourait que je puisse ecrire dans la memoire dans la partie du code. A tester kan j'aurais du temps!!!
Quentin Pouplard
Patrick Philippot wrote:
J'ai même encore sur mes étagères une bibliothèque 16-bit de compilation d'expressions régulières qui s'auto-modifie en mémoire.
C'est d'ailleurs amusant de voir qu'avec les plate-formes managés... on en revient un peu à ça, compilation au vol d'assembly, etc... c'est bcp plus clean, mais l'idée reste ;)
J'ai même encore sur mes étagères une bibliothèque 16-bit de
compilation d'expressions régulières qui s'auto-modifie en mémoire.
C'est d'ailleurs amusant de voir qu'avec les plate-formes managés... on
en revient un peu à ça, compilation au vol d'assembly, etc... c'est bcp
plus clean, mais l'idée reste ;)
J'ai même encore sur mes étagères une bibliothèque 16-bit de compilation d'expressions régulières qui s'auto-modifie en mémoire.
C'est d'ailleurs amusant de voir qu'avec les plate-formes managés... on en revient un peu à ça, compilation au vol d'assembly, etc... c'est bcp plus clean, mais l'idée reste ;)
"dark poulpo" a écrit dans le message news: cg03co$64o$
bonjour, voila, je bosse sur une partie de ma protection, mais le hic est que je narrive pas a modifier mon code en memoire, jai un access violation qui apparait. je suis en c++, et jai deja verifie mes regsitres en debug pour voir si les adresses a modifier etaient bien celle quil faut.
// p1[0] = 0xeb; mov eax,dword ptr [ebp-4] mov byte ptr [eax],0cch // <---------- ici ca plante en access violation
merci d'avance
jai la reponse, il me suffit just en assembleur de patcher le seh pour detourner le exception handler, et continuer mon code
"dark poulpo" <syn-ack@wanadoo.fr> a écrit dans le message news:
cg03co$64o$1@news-reader2.wanadoo.fr...
bonjour, voila, je bosse sur une partie de ma protection, mais le hic est
que je narrive pas a modifier mon code en memoire, jai un access violation
qui apparait. je suis en c++, et jai deja verifie mes regsitres en debug
pour voir si les adresses a modifier etaient bien celle quil faut.
"dark poulpo" a écrit dans le message news: cg03co$64o$
bonjour, voila, je bosse sur une partie de ma protection, mais le hic est que je narrive pas a modifier mon code en memoire, jai un access violation qui apparait. je suis en c++, et jai deja verifie mes regsitres en debug pour voir si les adresses a modifier etaient bien celle quil faut.
// p1[0] = 0xeb; mov eax,dword ptr [ebp-4] mov byte ptr [eax],0cch // <---------- ici ca plante en access violation
merci d'avance
jai la reponse, il me suffit just en assembleur de patcher le seh pour detourner le exception handler, et continuer mon code
Arnaud Debaene
dark poulpo wrote:
"dark poulpo" a écrit dans le message news: cg03co$64o$
bonjour, voila, je bosse sur une partie de ma protection, mais le hic est que je narrive pas a modifier mon code en memoire, jai un access violation qui apparait. je suis en c++, et jai deja verifie mes regsitres en debug pour voir si les adresses a modifier etaient bien celle quil faut.
// p1[0] = 0xeb; mov eax,dword ptr [ebp-4] mov byte ptr [eax],0cch // <---------- ici ca plante en access violation
merci d'avance
jai la reponse, il me suffit just en assembleur de patcher le seh pour detourner le exception handler, et continuer mon code
NON! Ca c'est une bidouille monstrueuse, et ca signifie que n'importe quel débordement mémoire ensuite dans ton application passera inapercu.
A quoi ca sert que Intel et Microsoft ils se décarcassent à mettre en place un mécanisme de protection mémoire si tu le fais sauter à la 1ère occasion ;-) ?
Si tu veux un exemple de code généré à la volée, regarde du côté des "thunjs" dans les sources d'ATL.
Arnaud
dark poulpo wrote:
"dark poulpo" <syn-ack@wanadoo.fr> a écrit dans le message news:
cg03co$64o$1@news-reader2.wanadoo.fr...
bonjour, voila, je bosse sur une partie de ma protection, mais le
hic est que je narrive pas a modifier mon code en memoire, jai un
access violation qui apparait. je suis en c++, et jai deja verifie
mes regsitres en debug pour voir si les adresses a modifier etaient
bien celle quil faut.
// p1[0] = 0xeb;
mov eax,dword ptr [ebp-4]
mov byte ptr [eax],0cch // <---------- ici ca plante en
access violation
merci d'avance
jai la reponse, il me suffit just en assembleur de patcher le seh pour
detourner le exception handler, et continuer mon code
NON! Ca c'est une bidouille monstrueuse, et ca signifie que n'importe quel
débordement mémoire ensuite dans ton application passera inapercu.
A quoi ca sert que Intel et Microsoft ils se décarcassent à mettre en place
un mécanisme de protection mémoire si tu le fais sauter à la 1ère occasion
;-) ?
Si tu veux un exemple de code généré à la volée, regarde du côté des
"thunjs" dans les sources d'ATL.
"dark poulpo" a écrit dans le message news: cg03co$64o$
bonjour, voila, je bosse sur une partie de ma protection, mais le hic est que je narrive pas a modifier mon code en memoire, jai un access violation qui apparait. je suis en c++, et jai deja verifie mes regsitres en debug pour voir si les adresses a modifier etaient bien celle quil faut.
// p1[0] = 0xeb; mov eax,dword ptr [ebp-4] mov byte ptr [eax],0cch // <---------- ici ca plante en access violation
merci d'avance
jai la reponse, il me suffit just en assembleur de patcher le seh pour detourner le exception handler, et continuer mon code
NON! Ca c'est une bidouille monstrueuse, et ca signifie que n'importe quel débordement mémoire ensuite dans ton application passera inapercu.
A quoi ca sert que Intel et Microsoft ils se décarcassent à mettre en place un mécanisme de protection mémoire si tu le fais sauter à la 1ère occasion ;-) ?
Si tu veux un exemple de code généré à la volée, regarde du côté des "thunjs" dans les sources d'ATL.
Arnaud
dark poulpo
"Arnaud Debaene" a écrit dans le message news: 412599b3$0$13477$
dark poulpo wrote: > "dark poulpo" a écrit dans le message news: > cg03co$64o$ >> bonjour, voila, je bosse sur une partie de ma protection, mais le >> hic est que je narrive pas a modifier mon code en memoire, jai un >> access violation qui apparait. je suis en c++, et jai deja verifie >> mes regsitres en debug pour voir si les adresses a modifier etaient >> bien celle quil faut. >> >> >> // _asm mov p1, offset protect1 >> mov dword ptr [ebp-4],offset protect1 (00401058) >> >> // p1[0] = 0xeb; >> mov eax,dword ptr [ebp-4] >> mov byte ptr [eax],0cch // <---------- ici ca plante en >> access violation >> >> >> merci d'avance >> > > jai la reponse, il me suffit just en assembleur de patcher le seh pour > detourner le exception handler, et continuer mon code
NON! Ca c'est une bidouille monstrueuse, et ca signifie que n'importe quel débordement mémoire ensuite dans ton application passera inapercu.
A quoi ca sert que Intel et Microsoft ils se décarcassent à mettre en
place
un mécanisme de protection mémoire si tu le fais sauter à la 1ère occasion ;-) ?
Si tu veux un exemple de code généré à la volée, regarde du côté des "thunjs" dans les sources d'ATL.
Arnaud
bein ca sert parcque c'est une protection logiciel que jecris. mais merci kan meme
"Arnaud Debaene" <adebaene@club-internet.fr> a écrit dans le message news:
412599b3$0$13477$626a14ce@news.free.fr...
dark poulpo wrote:
> "dark poulpo" <syn-ack@wanadoo.fr> a écrit dans le message news:
> cg03co$64o$1@news-reader2.wanadoo.fr...
>> bonjour, voila, je bosse sur une partie de ma protection, mais le
>> hic est que je narrive pas a modifier mon code en memoire, jai un
>> access violation qui apparait. je suis en c++, et jai deja verifie
>> mes regsitres en debug pour voir si les adresses a modifier etaient
>> bien celle quil faut.
>>
>>
>> // _asm mov p1, offset protect1
>> mov dword ptr [ebp-4],offset protect1 (00401058)
>>
>> // p1[0] = 0xeb;
>> mov eax,dword ptr [ebp-4]
>> mov byte ptr [eax],0cch // <---------- ici ca plante en
>> access violation
>>
>>
>> merci d'avance
>>
>
> jai la reponse, il me suffit just en assembleur de patcher le seh pour
> detourner le exception handler, et continuer mon code
NON! Ca c'est une bidouille monstrueuse, et ca signifie que n'importe quel
débordement mémoire ensuite dans ton application passera inapercu.
A quoi ca sert que Intel et Microsoft ils se décarcassent à mettre en
place
un mécanisme de protection mémoire si tu le fais sauter à la 1ère occasion
;-) ?
Si tu veux un exemple de code généré à la volée, regarde du côté des
"thunjs" dans les sources d'ATL.
Arnaud
bein ca sert parcque c'est une protection logiciel que jecris.
mais merci kan meme
"Arnaud Debaene" a écrit dans le message news: 412599b3$0$13477$
dark poulpo wrote: > "dark poulpo" a écrit dans le message news: > cg03co$64o$ >> bonjour, voila, je bosse sur une partie de ma protection, mais le >> hic est que je narrive pas a modifier mon code en memoire, jai un >> access violation qui apparait. je suis en c++, et jai deja verifie >> mes regsitres en debug pour voir si les adresses a modifier etaient >> bien celle quil faut. >> >> >> // _asm mov p1, offset protect1 >> mov dword ptr [ebp-4],offset protect1 (00401058) >> >> // p1[0] = 0xeb; >> mov eax,dword ptr [ebp-4] >> mov byte ptr [eax],0cch // <---------- ici ca plante en >> access violation >> >> >> merci d'avance >> > > jai la reponse, il me suffit just en assembleur de patcher le seh pour > detourner le exception handler, et continuer mon code
NON! Ca c'est une bidouille monstrueuse, et ca signifie que n'importe quel débordement mémoire ensuite dans ton application passera inapercu.
A quoi ca sert que Intel et Microsoft ils se décarcassent à mettre en
place
un mécanisme de protection mémoire si tu le fais sauter à la 1ère occasion ;-) ?
Si tu veux un exemple de code généré à la volée, regarde du côté des "thunjs" dans les sources d'ATL.
Arnaud
bein ca sert parcque c'est une protection logiciel que jecris. mais merci kan meme
Thierry
Bonjour,
dark poulpo a écrit :
bein ca sert parcque c'est une protection logiciel que jecris.
Elle va pas proteger longtemps, la tendance etant a bien separer les pages mémoires de code et de données pour empecher d'ecrire dans les premieres et executer dans les secondes (prochains proc -4 bits).
-- « Always look at the bright side of the life... »
Bonjour,
dark poulpo a écrit :
bein ca sert parcque c'est une protection logiciel que jecris.
Elle va pas proteger longtemps, la tendance etant a bien separer les pages
mémoires de code et de données pour empecher d'ecrire dans les premieres et
executer dans les secondes (prochains proc -4 bits).
--
« Always look at the bright side of the life... »
bein ca sert parcque c'est une protection logiciel que jecris.
Elle va pas proteger longtemps, la tendance etant a bien separer les pages mémoires de code et de données pour empecher d'ecrire dans les premieres et executer dans les secondes (prochains proc -4 bits).
-- « Always look at the bright side of the life... »
Thierry
Bonjour,
dark poulpo a écrit :
bein ca sert parcque c'est une protection logiciel que jecris.
Elle va pas proteger longtemps, la tendance etant a bien separer les pages mémoires de code et de données pour empecher d'ecrire dans les premieres et executer dans les secondes (prochains proc 64 bits).
-- « Always look at the bright side of the life... »
Bonjour,
dark poulpo a écrit :
bein ca sert parcque c'est une protection logiciel que jecris.
Elle va pas proteger longtemps, la tendance etant a bien separer les
pages mémoires de code et de données pour empecher d'ecrire dans les
premieres et executer dans les secondes (prochains proc 64 bits).
--
« Always look at the bright side of the life... »
bein ca sert parcque c'est une protection logiciel que jecris.
Elle va pas proteger longtemps, la tendance etant a bien separer les pages mémoires de code et de données pour empecher d'ecrire dans les premieres et executer dans les secondes (prochains proc 64 bits).
-- « Always look at the bright side of the life... »
