[ufox]

Postez ici vos messages.

[matthieu1984]

J'obtiens :

Code:

level01a@wargame:~$ ./bin01a
-bash: ./bin01a : fichier binaire impossible à lancer
level01a@wargame:~$ ./bin01a coucou
-bash: ./bin01a : fichier binaire impossible à lancer
level01a@wargame:~$

ça fait parti de l'épreuve ou il y a un BUG ?

[pixis]

Ce n'est pas le comportement attendu, les admins sont prévenus, ça devrait être corrigé dans la soirée.

J'ai rien fait. Non, c'est pas moi.

[matthieu1984]

Ok, Danke

[ufox]

C'est corrigé. Désolé pour le contretemps.

[ITPPA]

Bon, 8h que je suis dessus, tjr pas d'exploit.
Je vais peut etre commencer par les niveaux plus bas en faire 

[pixis]

Fais la première, puis reviens sur celle-ci.

Dans l'ordre de difficulté, c'est la deuxième à faire, entre "shell" et "bof bof", théoriquement.

Bon courage !

[ITPPA]

merci de cette réponse, ça promet!

Pour info, j'ai créer et compilé deux fichier dans /tmp (bof.c et bof2.c)

Je les ai copies dans un répertoire

Si un su passe par la, vous pouvez supprimer, je bosserais dans mon dossier perso maintenant (plus mieux).
Merci d'avance

[pixis]

Plus mieux, mais pour info, comme tu les avais créés, tu avais tous les droits pour les supprimer !
Mais du coup, je l'ai fait. Bon courage !

[ITPPA]

c'est pas faut. Pourtant il me semble avoir essayé de les supprimer sans succès.

Pour revenir a l'exercice (je lâche pas l'affaire) 

il y a pas une subtilité entre le bin01a.c et le compilé?
dans le code source bin01a.c on trouve:

Code:

strcpy(buffer, password);
strcpy(verif, "Donotcareitisnotusefull");

et au dump de la function check on y trouve:

Code:

.....
0x080484e7 <+19>:    call   0x80483d4 <strcpy@plt>
.....
0x08048503 <+47>:    call   0x80483c4 <memcpy@plt>
.....

Je ne pense pas que ca est une grande importance, mais bon, strcpy != memcpy

Sinon d'après mes calculs, et avec un shellcode de 45 octets, ca ne laisse que 12 NOP dans tout ca, pas évident de pointer l EIP dans ce tout petit espace memoire!
Je me trompe ou je suis a l'ouest complet?

Je continue mes investigation.

[pixis]

Je ne pense pas que ca est une grande importance, mais bon, strcpy != memcpy

Sauf erreur de ma part, memcpy étant plus rapide que srcpy dans ce cas là, le compilateur a fait une optimisation.

Sinon d'après mes calculs, et avec un shellcode de 45 octets, ca ne laisse que 12 NOP dans tout ca, pas évident de pointer l EIP dans ce tout petit espace memoire!

De manière générale, lors de l'exploitation d'un BoF, il n'y a pas besoin de NOP. Ce n'est qu'un confort qui pallie aux erreurs de calculs. Tu devrais être en mesure de connaitre l'adresse exacte.

Je finirai par :
"Avant d'attaquer la porte blindée au chalumeau, vérifie qu'il n'y a pas une fenêtre ouverte"

[ITPPA]

Rebonjour.

Merci pour ces précisions.

/* Modération : De rien, mais on ne donne pas toutes les solutions ici, voyons ! */

ca progresse, merci encore, ton site regorge d'informations qui, j'en suis sur, va me permettre de résoudre ce #&"!*~# de wargame.

[ITPPA]

c'est bon j'ai trouvé.

GAME OVER 

J'en est bavé, mais j'en est appris des tonnes.

[nessman]

Bonjour, avec gdb je modifie la variable flag à '1' et j'ai ca :

-=-=-=-=-=-=-=-=-=-=-=-=-=-
      Access Granted!
-=-=-=-=-=-=-=-=-=-=-=-=-=-
/bin/cat: /home/level01a/.password: Permission denied
[Inferior 1 (process 4301) exited normally]

[pixis]

Salut,

Oui, et heureusement qu'on ne peut pas modifier la mémoire lors de l'exécution d'un process avec le bit SUID tout en gardant les droits du propriétaire du binaire !

Quand tu utilises GDB, tu appelles implicitement ptrace(), et lors de l'appel à ptrace, tu exécutes le binaire sans le bit SUID, pour protéger les informations sensibles. Du coup, comment faire ?