Obfuscateur

[vances1]

Plutôt que de virer tout ce qui sert à l’exécution du programme, pourquoi au contraire ne pas rajouter ce qui sert à l’exécution de TOUT les autres ?

Il pourrait y avoir une histoire de sélecteur plus loin si le langage du moment reste indéfini.

Ps je ne code/programme pas.

EDIT

Il faudrait que le script/programme puisse se déclencher à partir d'un double click de manière autonome, ce qui implique qu'il possède en lui-même tous ce qui lui est nécessaire.

Il pourrait y avoir une escalade dans le cryptage (séquentiel) et un langage pourrait repasser la main à un autre sous couvert de cryptage.

[Daisy]

Pour l'indentation du python, il faut voir ou revoir vos éxigences, si vous souhaiter pouvoir le lancer tel quel, cela ne me semble pas possible,en revanche, fait un petit soft qui analyse les while, if, etc... et pourrais recreer l'indentation, me semble possible. il faut juste le faire ^^"
mais en restant avec quelque chose d'éxucutable sans opération inverse, je pense pas qu'on puisse y grand chose...

Bah déjà, faire un algo qui transforme les niveaux d'indentations des blocs en mixant tab/space pour rendre les blocs en apparence indentés à l'inverse ça broulle sacrément les pistes

Mais je suis d'accord que la suppression de l'indentation est à oublier...

@afranck64: ouais hein, ça m'a piqué aussi ^^

Ça serait assez marrant aussi de jouer avec les exec, prendre des bouts de la ligne mise en string, les coller dans des variables super obscures un peu partout et jouer avec les specifiers (%) un peu comme ils font dans la version de 99 bottles dans le lien mais en les étalant bien, because déjà que c'est pas facile à lire quand c'est codé propre, ça risque de faire saigner des yeux

'fin voilà, ça vaut ce que ça vaut, vous en faites ce que vous voulez

[fred]

Merci pour les pistes, voilà comment je voyais les choses.

1) Les indentations peuvent être enregistrées dans une case mémoire, c'est l'astuce (seulement les codes avec des tabs sont à proscrire, voir la PEP8)

2) Supprimer toutes les lignes vides pour simplifier le traitement du 1.

Ceci fait un code sans indentation et sans lignes vides.

3) J'aurais proposé une table de transposition assez complexe.

Voilà bref, pas évident, surtout avec le taf actuel, mais bon, faudra bien que je m'y mette.

@Daisy

Mais je suis d'accord que la suppression de l'indentation est à oublier...

C'est pas une évidence...

Non optimisé, fait en 30 secondes, donc me tapez pas dessus...

def compter(line):
    space = 0
    for char in line:
        if char != ' ':
            break
        elif char is ' ':
            space += 1
        elif char != '\n':
            break
    return space

indentation = [] # représente la mémoire où se trouve le nombre 
with open('setup.py', 'r') as f:
    for line in iter(f):
        indentation.append(compter(line))

print indentation # [0, 0, 0, 0, 0, 4, 4, 0]

à partir de ça on peut le pickler et le réutiliser pour réindenter le code, bref, c'est possible.

@vances

Plutôt que de virer tout ce qui sert à l’exécution du programme, pourquoi au contraire ne pas rajouter ce qui sert à l’exécution de TOUT les autres ?

Il pourrait y avoir une histoire de sélecteur plus loin si le langage du moment reste indéfini.

Je ne comprend pas, un exemple? Piste possible, mais je vois pas...

En programmation le plus difficile n'est pas de savoir si c'est possible (tout est possible), mais si on sait faire

[afranck64]

@Fred, j'avais pensé à mettre ces "indentations" en début de ligne. (Pour ne pas avoir à le mettre ailleurs)

00def compter(line):
01space = 0
01for char in line:
02if char != ' ':
03break
02elif char is ' ':
03space += 1
02elif char != '\n':
03break
01return space

.

[vances1]

Je ne comprend pas, un exemple? Piste possible, mais je vois pas...

En programmation le plus difficile n'est pas de savoir si c'est possible (tout est possible), mais si on sait faire

Je me disais justement qu'une idée farfelue de quelqu'un qui ne codais pas devrais brouiller pas mal les pistes ^^

Explication à ma manière donc

L'Os interagie différemment selon l'executable puisqu'il appel les fonctions adéquate pour chaque type d’exécutable (langage approprié).

Un script/programme utilise les routines, syntaxe qui lui sont propre (en corrélation avec son extension) pour débuter sont exécution.

Y à-t-il moyen pour commencer d'utiliser la fonction double click/lancement d'un os sur un fichier sans extension pour lancer son exécution? je ne sais pas par exemple le faite qu'on nous demande avec quoi l'ouvrir ...

Quand je disait "Plutôt que de virer tout ce qui sert à l’exécution du programme, pourquoi au contraire ne pas rajouter ce qui sert à l’exécution de TOUT les autres ?" je parlais d'ajouter le début du script/programme en chaque langue de programmation qui puisse exister ... une espèce de roulette ruse aléatoire qui lancerais l'executable de X manière aléatoirement et irais se perdre sous plusieurs couche de cryptage successive.

Le script pourrait commencer en Python puis passer le premier cryptage et passer la main au Perl ou ainsi de suite. Le facteur intéressant serais deja de ne pas savoir quelle langage lance la machine et que ce sois aléatoire.

Tu parle d’écrire dans un "tampon". On sais que les debuggeurs et consort analyse la ram, y-a-t-il moyen de le faire via le disque dur ^^ ?

Ce que je dit doit être assez space j'imagine et peut être même irréalisable mais j'aime le coté "vicieux" de la chose

[fred]

@afranck64
Le problème c'est que l'utilisateur peut se rendre compte de ce à quoi correspond ces nombres. En picklant il me semble que c'est illisible dans un fichier. Maintenant, tout dépendra surtout de ce qui se passe "après", c'est à dire la transposition des caractères. Si elle est suffisamment complexe, on pourrait laisser les nombres d'indentation dans le fichier. Enfin là je suis un peu dans le flou artistique car j'ai jamais fais ça...

@vances

L'Os interagie différemment selon l'executable puisqu'il appel les fonctions adéquate pour chaque type d’exécutable (langage approprié).

Un script/programme utilise les routines, syntaxe qui lui sont propre (en corrélation avec son extension) pour débuter sont exécution.

Y à-t-il moyen pour commencer d'utiliser la fonction double click/lancement d'un os sur un fichier sans extension pour lancer son exécution? je ne sais pas par exemple le faite qu'on nous demande avec quoi l'ouvrir ...

Quand je disait "Plutôt que de virer tout ce qui sert à l’exécution du programme, pourquoi au contraire ne pas rajouter ce qui sert à l’exécution de TOUT les autres ?" je parlais d'ajouter le début du script/programme en chaque langue de programmation qui puisse exister ... une espèce de roulette ruse aléatoire qui lancerais l'executable de X manière aléatoirement et irais se perdre sous plusieurs couche de cryptage successive.

Le script pourrait commencer en Python puis passer le premier cryptage et passer la main au Perl ou ainsi de suite. Le facteur intéressant serais deja de ne pas savoir quelle langage lance la machine et que ce sois aléatoire.

Tu parle d’écrire dans un "tampon". On sais que les debuggeurs et consort analyse la ram, y-a-t-il moyen de le faire via le disque dur ^^ ?

Ce que je dit doit être assez space j'imagine et peut être même irréalisable mais j'aime le coté "vicieux" de la chose

Malgré le pavé je comprend toujours pas, mais quand tu dis RAM, couches, etc... ça rentre plus trop dans les attributions python

[SAKAROV]

Je vois que fred est sur une bonne piste. N'oublie pas l'option "bourrage" de code inutile, ça va dans la pack

Sinon, il faut bien sûr apprendre à obfusquer chaque langage. S'il y a une manière générale (j'en doute fort), c'est bien, sinon... chacun son tour.

Au final donc, en faire une petite app embarquée en PHP et proposer ce tool d'obfuscation en sous-domaine de l'hackademy

(en n'oubliant pas que la personne rentrera une clé de cryptage qu'il devra garder (près de son coeur ) pour pouvoir décrypter le code, après avoir choisi le langage, toujours sur le sous-domaine donc)

[vances1]

............|1CRYPTAGE.....|2 CRYPTAGE.|
Python...|S..................|..................|
---------|E ----------->|..................|
Perl........|L..................|..................|
---------|E..................|..................|
c++........|C.................|..................|
---------|T..................|----------->|
.............|E..................|.................|
bash.......|U..................|.................|
---------|R...................|.................|-------->>
.............|....................|.................|

Quelque chose dans le style, bon j’arrête de vous distraire ^^

[afranck64]

@Fred, la valeur des indentation pourra être en hexa-alphabétique, sur 2 lettres, ou autre ...
et puis, concernant l'exécution, le décodeur peut être ajouté dans le fichier, le fichier "obfusqué" y est comme string. Une possibilité serait de créer un fichier temporaire contenant le code "décodé" et de l'exécuter. Ou tout simplement le charger en mémoire et le faire

[fred]

@afranck64

Une liste picklée, ressemble à ça

煝⠀ోՋो⹥ --> devine la longueur de ma liste et ses valeurs

C'est super pickle, non?

Pour le fichier temporaire c'est une bonne idée, je vais essayé d'y réfléchir.

[afranck64]

@fred Oulaaaaaaaaaaaaaaaaaaaaaa, je viens d'essayer... python3. La dernière fois que j'ai eu en m'en servir sous Python26 ca donnait un truc genre:

{
2323
{2
{we
{23
{22
{hello
{world

alors cela me surprenait un peu que tu veuilles t'en servir.
La question que je me pose c'est si tu as déjà trouvé un moyen avec pour que le fichier obfusqué [s'auto-]exécute normalement.

[fred]

La question que je me pose c'est si tu as déjà trouvé un moyen avec pour que le fichier obfusqué [s'auto-]exécute normalement.

Eh bien non justement, d'où la création possible du fichier temporaire (supprimer en utilisant atexit)

Mais je ne sais pas encore que ça va donner

[vances1]

Bon vous en êtes ou les gars ?

Ce serais vraiment au poil si ça pouvait être intégrer à la BT5 custom

[SAKAROV]

héhéhé, clair, ça serait bien Faudrait trouver un dév Perl en +...

En fait, le hic, c'est que les dévs Python (hormis Fred) sont déjà tous pas mal occupés ici... et ils ne peuvent être partout à la fois. Et le projet sur lequel ils travaillent prime sur celui-ci (très nettement).

Il faudrait faire une petite "chasse" sur le net, pour voir qui a déjà tâtonné le terrain, etc. Là on est un peu bloqué. Parce-que Fred dév bien en Python, mais apparemment c'est un peu la lutte pour exécuter (interpréter plutôt ) du crypté :/ Pour le bash, on ne sait pas encore trop trop. Et pour le Perl, no idea...

[vances1]

Question de priorité, c'est certain, si quelqu'un tatte suffisamment le perl qu'il se manifeste (ou se taise à jamais ^^) bonne chance alors pour l'autre projet ^^