Tables de chaînes (non protégées /!\ )

[Ollivier]

J'en fais profiter tout le monde.
/!\ Attention : les chaînes ne sont pas protégées dans l'exécutable, même avec une opération simple XOR. Préférez un fichier crypté de données.

[Kwai chang caine]

Marche nickel, merci du partage
Et ça sert à quoi exactement

[Ollivier]

Salut Kcc, j'espère que ça va. Cette astuce écourte un peu l'écriture d'un string data.

Au lieu d'écrire ceci

Code : Tout sélectionner

Global Dim Cool.S(1, 2)
Cool(0, 0) = "Rouge"
Cool(0, 1) = "Vert"
Cool(0, 2) = "Bleu"
Cool(1, 0) = "Magenta"
Cool(1, 1) = "Cyan"
Cool(1, 2) = "Jaune"

tu écris cela

Code : Tout sélectionner

Table+
   "Rouge", "Magenta",
   "Vert",  "Cyan",
   "Bleu",  "Jaune"
EndTable(Cool)

Ça dimensionne automatiquement un tableau 2D, et ça stocke les chaînes dedans.

[Ollivier]

Attention à deux contraintes :
- ne pas passer de lignes pour le comptage de la hauteur du tableau;
- bien rajouter une virgule en fin de ligne sauf pour la dernière ligne

[Ollivier]

Allo?

[Marc56]

Je rejoins KCC: C'est beau, mais à quoi cela (nous) sert-il ? mis à part pour la démonstration ?
Cela va-t-il plus vite que l'affectation directe des variables ?
De ce que j'ai toujours lu, un CPU et compilateur ne "pense pas" comme un humain, il est toujours basé sur la machine de Turing (je crois): il préfère une successions d'opérations bêtes plutôt qu'un calcul itératif (ex: plein de IF vont plus vite qu'un Select). Mais mes connaissances théoriques sont lointaines (j'avais lu ça à l'époque dans le manuel de Turbo C++ v3 dans les années 90').
L'IDE de PB ainsi que Notepad++ et bien d'autres dupliquent la ligne en cours (ou le bloc sélectionné) par un simple CTRL+D, on va ensuite très vite à modifier les variables. Pour une masse de données, un simple 'Read' bien segmenté fait le job.

Quid

[G-Rom]

Marc, je ne sais pas de quoi tu parles, mais Ollivier fait état , d'une chose à savoir quand on programme et que l'on utilise des chaines de caractères
par exemple ce pseudo code :

IP_DU_SERVEUR.s = "98.456.456.456"
LOGIN.s = = "Admin"
PASSWORD.s = "Mot@De-PasS3{}"
...

Quand tu compiles dans un exécutable , bah, tout ca, c'est en clair dans ton programme, tu peu même le lire avec notepad et en faisant une recherche.

[Marc56]

Oui, ça je connais. Tu peux même voir encore plus vite toutes les chaines contenues dans un exe en utilisant la commande strings
(natif sous unix et présent sur Windows avec tous les compilateurs C)
On s'en sert en batch pour identifier les versions de programmes, couplé avec grep ou findstr

[Ollivier]

@Marc56

je pense que tu parle de la machine de Turing pour les limites possibles du cryptage. Mais la chance qu'on a c'est que le compilateur est maîtrisable, à peu de chose près de la même manière sur toutes les plateformes.

En gros, déjà
1) simplifier encore plus l'acquisition (l'équivalent de Data.S "une", "une autre", etc...) des chaînes
2) séparer exécutable et chaînes acquises
3) crypter le fichier de chaînes (le client/utilisateur saisit forcément un mot de passe.)

Le tout en open source, puisque mon but n'est pas de fournir un ZIP, un EXE ou une DLL, mais juste une explication applicative (code source).

La perte pure de temps réside dans l'équivalent d'un temps de compilation, ce qui n'est pas énorme du tout, voire négligeable. Cette perte peut être annulée :
1) par un outil de pré-compilation
2) par un éditeur qui possède ce type d'outil

[Ollivier]

Je profite de vos connaissances pour vous demandez ce que vous pensez de ce gabarit :

Code : Tout sélectionner

CompilerIf 0
; Rouge ; Cyan
; Vert  ; Magenta
; Bleu  ; Jaune
CompilerEndIf

La 1ère colonne de point-virgules c'est pour empêcher l'éditeur de surligner et tabuler tout et n'importe quoi.

[G-Rom]

Je profite de vos connaissances pour vous demandez ce que vous pensez de ce gabarit :

Code : Tout sélectionner

CompilerIf 0
; Rouge ; Cyan
; Vert  ; Magenta
; Bleu  ; Jaune
CompilerEndIf

La 1ère colonne de point-virgules c'est pour empêcher l'éditeur de surligner et tabuler tout et n'importe quoi.

C'est quoi ton objectif ? compiler des commentaires ? ca ne marche pas.

[Ollivier]

Exactement. Ça doit être crypté avant compilation.

Puis, une fois crypté (et enregistré soit en fichier, soit en buffer récupérable avec CarchMemory), alors on procède à l'adaptation des occurences de chaînes pour qu'elles décryptent au besoin statique (ces chaînes sont des constantes à la compilation).

Enfin, on met en requête de compilation (autonome ou non).

Il faut ajouter d'exclure les équivalents de caractères 219 à 223, voire d'autres (matrices 2×4 en Unicode) pour le pixel art noir & blanc.

Nota : l'Unicode n'est pas accessible à une carte PQ. Mais il reste accessible de manière paginée (256 caractères par page).

[G-Rom]

Le plus simple, tu te fait un tool qui crypte tout les strings que tu veut, il te sort une chaine crypté que tu utilise dans ton programme final
et un include dans ton programme qui lui de décrypte en runtime ton string crypté , pas besoin de faire de la précompilation.

[Ollivier]

Je ne sais pas si le RunTime est sécurisé, et, "surtout", je ne sais pas son domaine d'action.

Quitte à avoir un include et/ou un outil en pre-process, le domaine d'action sur le code source est total. Et, il me semble que, non seulement le RunTime "surcharge" un peu le code source, mais j'ignore son comportement fonctionnel sur des DLLs.

@Marc56

Toi, qui m'indique que les compilateurs "préfèrent" la sauce itérative, je te réponds, certes, mais ça, c'est dans le fonctionnement du compilateur.

Concernant l'environnement du compilateur, à l'encontre de l'itératif, il peut être récursif.

[G-Rom]

Quand je te parles du runtime, je ne fait pas référence aux commande interne de PB , mais d'un code perso qui "décrypte" ton string au lancement du programme ( je parlais d'un include d'ailleurs ).
Le runtime , ce n'est pas quelque chose de propre à PB, mais un programme qui s'exécute de manière générale.