logo Homepage
+  NewbieContest
Username:
Password:
  Voir les messages
Pages: [1]
1  Challenges / Aide Crackme / Re : Crackme - BoFMe le: 01 Février 2012 à 11:20:58
Bonjour à tous,

Je ne sais pas s'il y a encore de l'activité parmi les personnes qui peuvent m'aider.
Je repassais juste ces derniers jours pour m'amuser un peu et je prends les rares crackme que je peux tenter (wine powered).

Pas spécialement de difficultés pour faire celui-ci, mais bien sûr le serial ne valide pas sur le site. Je n'ai à peu près aucune idée des versions des dll système émulées par wine. Si quelqu'un a la gentillesse de vérifier en PM ma solution et de me donner l'offset pour XP qui apparemment était la cible, je prends..

Sinon il n'y aura pas mort d'homme.

Edit: Ame charitable trouvée, merci harvey :]
2  Programmation / Langages compilés / Re : [Résolu] [C] Problème avec une matrice en paramètre le: 17 Août 2008 à 18:41:56
A vrai dire, non, puisque par définition les tableaux et les pointeurs sont équivalents au passage vers une fonction. Ainsi, void func(int * vals)

Je me cite bien "au passage vers une fonction" et je ne pense pas avoir été ambigu à ce niveau là.
D'ailleurs le point de départ que tu réfutais était (int argc, char ** argv) ou (int argc, char * argv[]), qui sont bien des paramètres formels de fonction et donc équivalents.

Après je suis d'accord que dire ça pourrait faire penser à des débutants qu'il en est de même tout le temps, ce qui est effectivement faux dès qu'on sort du contexte de passage d'arguments à une fonction, mais bon ça je pense que c'est du ressort de la distinction de base entre pointeurs et tableaux..


Allez le HS n'a que trop duré je pense qu'on peut proclamer le EOT


S3cur3D
3  Programmation / Langages compilés / Re : [Résolu] [C] Problème avec une matrice en paramètre le: 17 Août 2008 à 18:19:22
Citation
mais il doit bien y avoir des cas tordus dans lequel un compilo râlera sur l'une des formes et pas sur l'autres

A vrai dire, non, puisque par définition les tableaux et les pointeurs sont équivalents au passage vers une fonction. Ainsi, void func(int * vals) est équivalent à void func(int vals[]) et même à void func(int vals[5]).

Pour t'en convaincre, tu peux tout simplement coder 4 fonctions, l'une prenant en paramètre un tableau, l'autre un pointeur, une autre prenant un pointeur de tableau et une dernière un pointeur de pointeur. Ensuite on créé un tableau lambda et on le passe aux deux premières fonctions et son adresse aux deux autres. Un petit coup d'oeil au code assembleur généré montrera que le passage d'argument entre les fonctions 1 et 2 (resp. 3 et 4) se font exactement de la même façon.
La notation [] peut permettre de faciliter la compréhension mais est selon moi trompeuse effectivement.

Enfin bon, j'imagine que ce ne sont pas des considérations qui vont intéresser mogg au final ^^

S3cur3D
4  Programmation / Langages compilés / Re : [C] Problème avec une matrice en paramètre le: 17 Août 2008 à 15:02:07
Rebonjour mogg,

Donc tu veux manipuler si j'ai bien compris des tableaux à deux dimensions de taille a priori inconnue à la compilation. Ca ne te rappelle rien ?
Si on prends le passage d'arguments du shell au point d'entrée main, c'est bien (int argc, char ** argv) ou (int argc, char * argv[]) qui sont des notations équivalentes.
argv est un tableau de pointeurs vers des tableaux de caractères, ce qui construit finalement une matrice de caractères dont on connait la dimension maximale grâce à argc.
Donc dans ton cas un tableau de pointeurs vers des tableaux d'entiers devrait le faire, à savoir int ** matrice ou int * matrice[] pour les amoureux des crochets, reste donc à passer également en paramètre les deux dimensions pour ne pas aller regarer au-delà des tableaux.


Edit : Désolé au passage du déterrage, mais vu que ce n'était pas poinçonné "Résolu" et que je connais pas mal de gens qui ont mal intégré ce genre de notions en C..

S3cur3D
5  Programmation / Langages compilés / Re : [C++] Problème avec l'élement 0 d'un tableau. le: 17 Août 2008 à 02:41:04
Salut,

Si je ne me trompe pas, tu devrais avoir quelquechose du style "expects int* but type is int".
Donc, c'est un warning et non pas une erreur (ce qui permet à la compilation de continuer son cours).
Comme d'habitude, les messages sont assez explicites. Les fonctions de la famille scanf attendent toujours un pointeur en argument afin de ranger la valeur obtenue à l'adresse pointée. Dans ton cas, tu donnes RAM[0] qui référence directement l'entier se trouvant à l'offset 0. Par conséquent, mettre simplement RAM (qui référence l'adresse de début du tableau) comme dit dans le dernier message devrait supprimer ce message d'avertissement.
Même si tu ne l'as pas vu, le même warning doit sortir pour RAM[1]. Dans ce cas, il faudrait mettre RAM+1 pour supprimer le message, c'est à dire l'adresse du tableau + 1(*sizeof(type du tableau)).
Voilà pour ce message d'avertissement.

Sinon, une remarque générale. Les quotes que tu sors là c'est 100% du C. Pourquoi le compiler en tant que C++ ???
Honnêtement, C et C++ sont deux langages différents, ayant des philosophies différentes et des buts différents.
Le C++ est construit autour de la POO. Ainsi, il existe des classes pour gérer les fichiers (ifstream, ofstream, fstream)  ou encore des objets permettant l'accès direct aux flux standards (cin, cout, ...) ainsi que des opérateurs de manipulation de ces flux. Bref, rien de ce que je vois ici en 3 lignes et que je verrais dans un code C++ ayant le même but.
Ce n'est pas une mauvaise critique (personnellement je préfère beaucoup le C au C++), mais ce code n'est pas du C++, donc compilons-le en C. Ou si du C++ est utilisé ailleurs, faisons tout le code en C++.

Ensuite, pour la question de départ, C++ vient directement du C et, à part quelques anciennes notations excentriques du C, tout ce qui existait en C a perduré en C++, donc les concepts de base comme le départ des tableaux sont identiques. Par contre j'ai en tête plusieurs exemples de codes en C compilant mal en C++ (même si ça n'a rien à voir ici), donc gardons chaque langage et chaque compilateur associé où il se doit ;-)

Voilà j'espère ne pas avoir été trop brouillon et confus dans la réponse comme mon état de fatigue et l'heure le permettraient...

S3cur3D

Edit: Désolé de me faire echo de toi, sirk390, j'étais parti faire autre chose au milieu de l'écriture de ma réponse..
Pages: [1]