Seuls les membres ayant 30 points peuvent parler sur le chat.

Forum Casio - Projets de programmation


Index du Forum » Projets de programmation » Exécuter un buffer overflow avec un g1m
ZezombyeHors ligneRédacteurPoints: 1652 Défis: 13 Message

Exécuter un buffer overflow avec un g1m

Posté le 06/08/2017 10:54

Salut, je crossposte mon topic de Casiopeia, peut être que des gens ayant une expérience avec l'assembleur pourraient m'aider

http://casiopeia.net/forum/viewtopic.php?f=25&t=1825&p=14955

En gros c'est tout simplement pour savoir si c'était possible d'exécuter un buffer overflow en important un g1m qui contient un string de plus de 255 octets (j'arrive à en manipuler de 316 octets avec certaines fonctions). S'il est possible d'overwriter l'adresse de retour de la fonction, il suffirait de trouver un pointeur qui mènerait sur un programme contenant du code à exécuter, et là hop des addins en BASIC

(je demande peut être la lune, mais bon connaissant Casio et son OS pas super sécurisé, un buffer overflow doit pas être si difficile à réaliser)


Fmc_Hors ligneMembrePoints: 40 Défis: 0 Message

Citer : Posté le 06/08/2017 12:40 | #


Bonjour

Déjà, faudrait savoir si t'as réellement réalisé un buffer overflow avec ta technique ninja, ou si t'as simplement cassé la limite standard de 256 bytes.
Ensuite, si t'arrives à overflow à l'infini jusqu'au stack, et à overwrite tout pile sur l'adresse de retour de la sous-routine sans toucher aux variables locales, alors bingo.
La mémoire principale commence à l'adresse 0x88030000. Le stack commence à 0x88020000, et faisant 8kiB les données s'empilent à partir de 0x88023FFF en descendant. Ça, c'est sûr pour les add-in, mais normalement l'app PRGM devrait le gérer de la même manière

Le plus compliqué sera surtout de faire un overflow digne de ce nom, je suis pas trop confiant à propos du fait que le système t'indique une str de 316 bytes. Même si c'est hors-limites, ça veut sûrement dire qu'il arrive à la gérer sans bavures.

Sinon, si tu gères, il devrait "suffire" de descendre dans les adresses pour atteindre le stack (y'a 48kiB de heap à franchir attention ).

Voilà, en tout cas ça envoie du rêve ce genre de bidouilles, glhf ^~^
ZezombyeHors ligneRédacteurPoints: 1652 Défis: 13 Message

Citer : Posté le 06/08/2017 12:55 | #


Par définition c'est un buffer overflow, vu que le buffer standard est de 256 octets (comme j'ai dit sur mon post de casiopeia, j'ai testé la limite de 316 octets uniquement pour StrRight, et y'a des fonctions qui bugent et d'autres qui bugent pas). J'imagine que pour les autres fonctions c'est des limites différentes.

Il gère pas la str de 316 bytes sans bavure vu que StrRotate (et d'autres) font des erreurs système.

Pour la mémoire principale c'est intéressant. Il faudrait savoir à quel offset exactement est placé un programme, sachant qu'il y a des trucs planqués si je me souviens bien. Mais il me faudrait le code (en C si possible) de la fonction StrRight (ou une autre) pour que je sache où exactement est le pointeur de retour.

Il faudrait essayer, après le string de 316 octets, de mettre le pointeur vers 0x88030000 (peut être que ça empêcherait l'interruption) ou, mieux, de le mettre sur un syscall qui affiche une popup par exemple.

Après il faudrait aussi savoir la différence entre les 2 erreurs que je vois : "ADDRESS(W)" suivi de 2 pointeurs (comme une tlb error) et "INTERRUPT". Lephé tu as peut être déjà eu ce genre d'erreur avec gint, non?

Je continuerai à expérimenter sur ça après les CPC (j'ai mal choisi le moment aussi )
Divers jeux : Puissance 4 - Chariot Wars - Sokoban
Ecrivez vos programmes basic sur PC avec BIDE
LephenixnoirEn ligneAdministrateurPoints: 17167 Défis: 142 Message

Citer : Posté le 06/08/2017 15:09 | #


Le pointeur de retour est dans le registre pr, et nulle part ailleurs. En général le changement de stack frame fait qu'il arrive sur la pile, mais tu ne peux pas savoir où précisément.

L'erreur ADDRESS(W) c'est un accès illégal en écriture à une zone de la mémoire, mais existante (ie. mappée). C'est peut-être une TLB protection violation, car aucune zone n'est interdite au mode privilégié du processeur, donc les accès en P1-P4 ne sont pas des erreurs.

L'erreur INTERRUPT est peut-être une EBR. En tous cas, ça sent pas bon.

Bon alors, pour les détails. Je ne sais pas si tu as remarqué FMC_, mais la mémoire principale est après la pile de l'add-in, donc aucune chance de faire un overflow dans ce sens-là. Ceci car elle ne s'étend pas vers l'avant (t'as quand même pas écrit un assembleur et jamais vu sts.l pr, @-r15 ? ). Son adresse initiale est celle du tas puis elle s'étend vers les adresses décroissantes, toujours.

On est donc déjà mal barrés, et il y a *plein* de problèmes à résoudre pour ça. Commence par voir ce que tu arrives à faire avec les Str et on verra ensuite si ça permet bien d'exécuter du code, et où le prend, le code en question.

Planète Casio v42 © créé par Neuronix et Muelsaco 2004 - 2020 | Il y a 129 connectés | Nous contacter | Qui sommes-nous ? | Licences et remerciements

Planète Casio est un site communautaire non affilié à Casio. Toute reproduction de Planète Casio, même partielle, est interdite.
Les programmes et autres publications présentes sur Planète Casio restent la propriété de leurs auteurs et peuvent être soumis à des licences ou copyrights.
CASIO est une marque déposée par CASIO Computer Co., Ltd