6Fermer8
Kevin KoflerLe 13/04/2013 à 01:30
Folco (./5) :
La solution qui me paraitrait la plus propre :
- ne pas tenir compte du flag ro sous AMS, dans le cas d'un kernel::exec, kernel::LibsExec ou kernel::LibsCall, car nécessairement ça va planter, on le sait d'avance.
- laisser le programme en ROM s'il est ro lors d'un kernel::LibsPtr, ou d'un relogement à résoudre, car ça ressemble tout à fait à de l'accession de données, pas de code.Cette solution serait totalement transparente pour les anciens programmes, dont les utilisations de libs de données sont très probablement basées sur des relogements.

À mon avis, c'est probablement la meilleure solution. Ça ressemble un peu à l'heuristique de TitaniK pour savoir quand il faut mettre directement l'adresse de destination (accès aux données) et quand il faut interposer le fameux stub de déprotection (appel de code), mais dans ton cas, où le chargement est dynamique, c'est moins risqué parce qu'on a une API différente pour les 2 cas, alors que TitaniK n'a que l'instruction utilisée devant le relogement, qu'il compare bêtement à jsr.l et jmp.l, sans gérer aucun autre cas (genre l'appel indirect avec lea et jsr (%an) etc.).

Mais PpHd a peut-être une autre idée, comme d'habitude. wink