Peut-être un peu de code, mais FACILEMENT, si on veut vraiment bloquer il y a EXE Compressor.
Sinon il y a ResHacker comme décompilateur graphique, peut-être qu'il parlait de ça , mais cela reste un PEBKAC ;-)

Y'a des décompilateurs effectivement, mais même, ça reste un PEBKAC pour le « De toute façon, tous les programmes existants sont disponibles en Open source ».

Ben quoi, c'est un spécialiste de l'ASM et l'obfuscation ne lui fait même pas peur.

[]-->

#include <stdio.h>

int main(int argc, char** argv)
{
char H[4] = "Hell";
int I;
int J;
int K = 0x0a782500;

I = 111 << 24;
J = K - 1292430;
I+= 2800 * 2800;
I-= 32913;

printf(H);
return 0;
}

Note : les plus rapides auront vu 3 codes :p

Les désassembleurs fonctionnent très bien. Si vous êtes pas capables de comprendre 250'000 lignes d'assembleur au premier coup d'oeil, faut changer de métier!

Ton code va lamentablement planter, tu n'as pas laissé assez de place pour le EOF!

N'a manifestement pas compris ce qu'est l'open source.
L'abruti moyen semble croire que non seulement l'usage d'un cerveau ne s'applique pas aux situations informatiques, mais aussi la loi.

J'ajoute que les gens qui ne respectent pas les licences méritent tous une bonne *SPAF*, que ce soient les nigauds qui choppent des versions piratées de Cévennes, ou Cisco qui utilise (-ait) du code GNU dans des trucs propriétaires.

Il n'y a aucune manière de vraiment bloquer... Ton EXE compressor c'est comme n'importe quel packer : tout pourri.

Avec un debugger, il suffit de quelques dizaines de minutes à quelqu'un d'expérimenté pour retrouver ton exe d'origine.

Si on est moins perfectionniste, on lance ton exe avec un debugger, on lui demande de dumper l'image en mémoire, et on a l'exe presque original.

Ou Apple, qui utilise trouzemillion de solutions libres dans ses systèmes ultrafermés...

http://sebsauvage.net/rhaa/index.php?2012/10/05/15/25/36-l-hypocrisie-[...]

Même pas besoin de dump, le fichier original apparait dans le répertoire temporaire dans les 3/4 du temps...

J'ai suivi de lien en lien, et je suis devenu encore plus Apple hater.
Je ne croyais pas ça possible ....

Du coup ils font aussi de l'open source, comme cups.

@Link: Pourquoi EOF? Il n'y a pas de fichier.
EOF = End Of File = fin de fichier
Je suppose que tu veut parler du cratère null de fin de chaîne ('/0'), qui n'a pas forcément la même valeur que EOF (qui dépend du système).

En C, ce code doit fonctionner, même s'il n'est pas propre.
La ligne char H[4] = "Hell"; déclare un pointeur H de type char sensé pointer sur un tableau de quatre éléments, et affecte *au pointeur* l'adresse de la string "Hell" (la string n'est PAS copiée).
La string "Hell" est elle bien terminé par le caractère null.
Donc H pointe bien vers une string terminée par le caractère null, la longueur officielle du tableau H n'a pas d'importance.

Mais ROB à quand même droit à une baffe ou deux, car son code n'est pas propre.

Oui mais bon, ton code ne fonctionne que sur une machine avec des int de 32 bits et en little endian. Et puis il manque le point d'exclamation, et c'est un retour chariot en mode unix.
Par contre, le fin de chaîne dans K, c'est amusant... mais je n'ai pas envie de voir le cirque qu'il y a dans ta tête ;-)

Je crois que j'ai perdu assez de temps et que je ferais mieux de retourner bosser.

@Shirluban : justement, le caractère nul de fin de chaîne de H va être écrasé dès qu'on va écrire dans I. En fait, la fin de chaîne est le '00' en fin de K (mais au début physiquement en mémoire).
Si je ne me suis pas trompé, le programme devrait afficher 'Hello world/n'.

Sinon, c'était le but de ne pas être propre : il voulait montrer qu'avoir le source n'est pas forcément un prérequis à la compréhension du truc.

@Shirluban: je pensais que pointeur ou pas, il fallait toujours rajouter un octet pour la fin de trame. Je ne fais donc pas que perdre mon temps sur ce site!

@Acné: Ou pas.
La string "Hell" est un littéral, elle doit donc avoir son propre espace mémoire avant que H ne soit alloué.
H est I seront probablement contigus en mémoire, mais pas "Hell" et I, et elles ne seront certainement pas superposés.

En mémoire on devrait avoir au mieux:
[Hell/0] ... [pointeur H][tableau de 4 char][variable I][variable J][variable K]
H pointant sur la zone [Hell/0], et non sur la zone [tableau de 4 char] (qui est inutilisé).
En C, p = "string" copie l'adresse de "string", pas son contenu.
Le code pourrait marcher de la façon que tu dit si on avait:
char H[4];
strcmp(H, "Hell");
Pour copier le contenu (avec un écrasement mémoire), au lieu d'aller pointer sur une autre zone mémoire.

Au final, le programme ne devrait afficher que "Hell".


@Link: Si tu copie le contenu (strcpy(p, "str")), il faut avoir un octet de plus pour le caractère nul. Si tu copie l'adresse (p = "str"), la taille de la zone précédemment pointée par p n'a pas d'importance, vu qu'en fait tu ne te sert pas de cette zone.

Je dois avoir un gcc qui gère un peu mieux les débordements. Car je n'ai que Hell chez moi.

Un qui marche pour les little endian et 32bit pour l'int.
#include <stdio.h>

int xmen[ ] = {0x6c64210a, 0x20576f72, 0x656c6c6f, 0x00000048 };

void imprime(char* caracter) {
char* c = caracter;
if ((int *)caracter < &xmen[3])
imprime(caracter+1);
printf("%c", *c);
}

int main(int argc, char **argv)
{
imprime((char*)xmen);
return 0;
}
@Shirluban : Je crois justement que le but c'est qu'il mette hell dans un truc plus petit. C'est la différence entre char* toto="titi" et char toto [4]="titi", avec un warning en bonus.

@Shirluban : maintenant je sais pourquoi je ne fais plus de C ! Je n'en ai pas fait depuis 14 ans, je crois que ça s'est vu...

@Shiruban : en fait, H est bien un littéral. Mais le compilateur préfabrique l'environnement des fonctions. Ainsi au lieu d'avoir 36 appels système (allocation des éléments de la pile) au début de la fonction, il n'y en a qu'un. Comme on lui a dit de faire un char de 4, il fait un char de 4, où il tente d'écrire "hell/0" et finir par écrire "hell". Sauf que sur le mien, il sépare de quelques caractères les différentes allocations.

Si t'en veux la preuve, tente un char toto[1]="toto"; char x=0; printf("%s/n",toto); tu devrais obtenir uniquement un 't'.

Je vient de tester avec deux compilo différents sur deux machines différentes et j'ai ... deux résultats différents.

Lors de la déclaration d'un tableau char H[4] = "Hell"; on copie bien le contenu de "Hell", sans le '/0' à la fin.
Je pensait à tord que
char H[4] = "Hell"; /* copie le contenu de "Hell" */
était équivalant à
char H[4];
H = "Hell"; /* erreur de compil */
et à
char* H;
H = "Hell"; /* copie l'adresse de "Hell" */

Avec Visual C++ 2003 sous WinXP 32bits (et en compilant en C), on a en mémoire: I, 4 octets à 00, K, J, H.
Avec GCC sous Ubuntu 32bits (et en compilant en C ANSI), on a en mémoire: K, J, I, 3 octets, H.

Dans les deux cas, j'ai au final "Hell" suivi de n'importe quoi.

Apple c'était aussi une implémentation de Java "home made"...
Avec les trous de sécurité qui vont avec...

@Nh3xus : C'est pour plus de fun. Comme on dit que personne ne s'intéresse à Mac OS même les malwares, ils essayent de corriger cela.

Mais maintenant, c'est oracle qui gère les versions java d'Apple.
http://www.pcinpact.com/news/59989-mac-osx-java-depreciation-apple-mac[...]

Il a peut-être des notions de développement et de chimie, mais le droit, c'est pas encore ça...

T'as vite fais d'obtenir un résultat étrange si tu veux l'optimiser celui-là..