Le topic de la programmation: Et envoyez des sioux!

[Dross]

Le contexte consiste à chiffrer en C# des logs applicative qui peuvent parfois contenir des données sensibles et qui sont sauvegardées sur Azure (cette contrainte n'est pas modifiable). Ce n'est pas une application critique, mais si on peut avoir une bonne base pour une utilisation plus poussé, cela sera intéressant. On a déjà pensé à éviter de loguer ces fameuses données sensible, mais le type de données pourra être amené à évoluer régulièrement, cela va rapidement devenir inmaintenable.

Tu peux aussi utiliser du chiffrement symétrique et asymétrique : tu génère aléatoirement (dans un SecureString pour éviter les dump mémoire) une string que tu encryptera avec de l'asymétrique et placera dans la première ligne de ton fichier. Cette string aléatoire deviens ta clé d'encryption symétrique et tu l'utilise pour chiffrer tes logs dans la suite du fichier.

L'intérêt c'est qu'il n'y a pas ta clé maitresse dans le binaire (C# = .NET = opensource ou pas loin (les obfuscateurs sont tous pété sauf un ou deux)) et que tu garde de bonnes performances pour la décryptions.

J'ai du code C# qui fait ça, si ça t'intéresse je pourrai te filer 2-3 samples.

ps: si tu chiffre appel par appel et pas un fichier complet que tu envois sur Azure en cas de soucis il faudra adapter.

[Møgluglu]

Par exemple, la solution mise en avant sur ce post me semble pas mal. Vous confirmez mes impressions ?

Oui, si tu ne réinventes pas la roue, que tu fais du block chaining avec un peu de sel comme dans l'exemple, et que tu génères une clé symétrique différente pour chaque log avec un générateur aléatoire sûr (en chiffrant la clé avec un algo asymétrique comme propose Dross, et/ou en la gardant à un endroit inaccessible du serveur Azure et du reste du monde), ça devrait aller.

[deathdigger]

C'est cool, j'avais besoin d'un truc comme ça (pour stocker des mots de passe d'accès bdd et autres dans des fichiers de config), et je ne savais pas trop comment rendre le truc propre

[Taro]

J'ai une question également, plutôt concernant un tuto/livre.

Si c'est un tuto gratos c'est aussi bien, mais ça ne me dérange pas de me payer un livre s'il est bien conçu, j'ai l'habitude d'en acheter si nécessaire. Par contre payer pour un tuto online, je passe mon tour.
Ca c'est concernant le support.
Concernant la langue, j'veux ça en français (cas exceptionnel, je m'explique ci-après).

Je vois bien que je n'avance pas sur mon bouquin sur le reverse engineering. La raison c'est avant tout que je suis trop dépassé en assembleur (j'en ai fait, mais manifestement bien trop peu et il y a trop longtemps), et ensuite que c'est plus difficile de passer outre cette limitation en me disant que j'apprendrai sur le tas quand tout le contenu est en anglais. Attention, je n'ai pas de problème avec l'anglais, anglais technique y compris, mais c'est vrai que des fois quand tu dois te frotter à un algo un peu goulu lire une explication dans la langue maternelle ça aide, n'étant pas non plus 100% bilingue en ce qui me concerne.
Du coup, est-ce que vous avez un bon tuto ou bouquin qui :

• propose de se mettre à l'assembleur (x86 je dirais, au pif, je suppose que je peux partir là dessus et ensuite découvrir les spécificités si dans un moment je pars sur du x64, de l'ARM...)
• Parte au ras des pâquerettes (il me reste quelques notions, mais je préfère partir sur un support qui considère que je n'en ai jamais fait, pour être sûr de repartir sur les bases)
• Qui soit, donc, en français

?

Merci par avance pour vos conseils les canetons

[Møgluglu]

Si jamais tu tombes sur une édition du Hennessy-Patterson traduit par Daniel Etiemble d'occasion à un prix raisonnable, fonce. Malheureusement, il semble introuvable de nos jours.

Tu as aussi le Goossens, mais il n'a pas l'air tellement plus facile à trouver.

À défaut, tu peux jeter un œil aux supports de cours des mêmes :
https://www.lri.fr/~de/ArchiL3-1314.htm
http://perso.univ-perp.fr/bernard.go...A/archiav.html
Ou encore https://www.lri.fr/~cecile/ENSEIGNEM...HI/partie1.pdf et https://www.lri.fr/~cecile/ENSEIGNEM...artie2scal.pdf

Mais globalement les ressources sur l'architecture des ordinateurs en français ça ne court pas les rues. Je me rappelle d'une introduction en français à l'archi d'Etiemble aussi dans une revue en français qui avait été citée sur le forum, mais pas moyen de remettre la main dessus.

[Taro]

Merci Mogluglu pour tes idées, je vais regarder si je peux trouver ça... Je vais ptet même d'abord voir leurs cours pour déduire lequel semble le plus coller à ce que je recherche.

Si d'autres canards ont des idées à rajouter, n'hésitez pas !

[Sahnvour]

Mon prof d'IUT a écrit https://www.eyrolles.com/Informatiqu...-9782212116359 , mais vu qu'on avait une version un peu light en cours (touffu mais 1ère année donc ...) je sais pas dans quelle mesure ça rentre dans les détails des archis récentes en particulier. Ça commence à dater aussi, mais de mémoire c'était pas mal et puis c'est en français, la version pdf est pas dure à trouver.

[Taro]

En fait c'est pas tant l'archi qui m'intéresse sur ce coup là, c'est plus de me remettre à l'assembleur en douceur. Revoir à quoi sert chaque instruction, l'ordre et le rôle des paramètres, éventuellement écrit en plusieurs conventions...
Me remettre dans le bain avec les bases quoi, le rôle des différents registres, tout ça. Histoire que je ne mette pas 30 minutes à comprendre, en lisant mon autre bouquin sur le reverse engineering, à quoi correspond ce bout de code ASM de trois lignes.

[Cwningen]

Il n'y a rien de standard dans les notations assembleur, même en restant sur l'x86, les notations GAS et Intel font tout le contraire.

[Møgluglu]

Oui, c'est comme si tu voulais apprendre la programmation en général mais sans faire d'algorithmique.
Le jeu d'instructions, il est décrit dans la doc de ton processeur (quand il en a une, je ne regarde pas du tout vers Nvidia). Mais pour comprendre la doc et pourquoi le jeu d'instructions est comme ça, c'est l'archi qu'il faut connaître. Ou simplement pour la culture générale de programmeur.

Sinon c'est normal d'avoir besoin de la doc ouverte à côté pour lire un code assembleur, si tu n'es pas un gourou qui lit du code machine binaire dans le texte depuis tout petit. Je fais toujours comme ça, y compris (voire surtout) quand c'est du x86.

[Max_well]

[semi-troll]
http://store.steampowered.com/app/370360/TIS100/
http://store.steampowered.com/app/504210/SHENZHEN_IO/
[/semi-troll]

[Patate]

[semi-troll]
http://store.steampowered.com/app/370360/TIS100/
http://store.steampowered.com/app/504210/SHENZHEN_IO/
[/semi-troll]

Ca reste accessible si on a jamais fait d'assembleur ce genre de jeu ?

[GrandFather]

Totalement.

[Møgluglu]

Grave. Sinon le marché serait réduit aux 3 barbus qui ont programmé sur grilles de Transputer.
Les connaissances acquises n'aident pas, c'est entièrement à base d'astuces spécifiques à trouver au cas par cas (ce qui est d'ailleurs tout ce qui me frustre dans ces jeux, chaque fois que tu penses avoir trouvé une méthode générale elle ne marche plus à l'énigme d'après )

Du moins pour TIS-100. Shenzhen I/O ou les autres Zachtronics j'ai pas joué, mais ça semble du même tonneau.

[Patate]

Ok merci, ils me font de l’œil depuis quelques mois, mais à regarder les vidéos c'est un peu

[Taro]

Il n'y a rien de standard dans les notations assembleur, même en restant sur l'x86, les notations GAS et Intel font tout le contraire.

Oui, c'est comme si tu voulais apprendre la programmation en général mais sans faire d'algorithmique.
Le jeu d'instructions, il est décrit dans la doc de ton processeur (quand il en a une, je ne regarde pas du tout vers Nvidia). Mais pour comprendre la doc et pourquoi le jeu d'instructions est comme ça, c'est l'archi qu'il faut connaître. Ou simplement pour la culture générale de programmeur.

Sinon c'est normal d'avoir besoin de la doc ouverte à côté pour lire un code assembleur, si tu n'es pas un gourou qui lit du code machine binaire dans le texte depuis tout petit. Je fais toujours comme ça, y compris (voire surtout) quand c'est du x86.

Je comprends, merci pour les précisions

Mais les instructions "classiques" ça doit bien exister ? Genre le MOV doit bien se retrouver un peu partout avec généralement deux paramètres, non ?

[Cwningen]

L'idée du move oui, mais ça change quand même. Déjà l'ordre des opérandes change (destination, source ou source, destination). La mnémotechnique peut changer (mov, move, mov+type ou n'importe quoi). La syntaxe utilisée pour les opérandes peut être importante aussi (valeur immédiate, registre, indirection, déplacement, ...).

Rien que pour l'x86 comme je le disais, tu peux avoir "mov dword ptr [esp+4], 0" (intel) ou "movl $0, 4(%esp)" (GAS/AT&T) pour la même chose (exactitude de la syntaxe non garantie).

Pour certains processeurs, un move générique à deux adresses peut être trop compliqué, donc tu utilises des load/store à la place (par exemple le micro-controlleur de mon clavier qui ne peut transférer des données que vers ou depuis l'accumulateur).

[Taro]

Super, merci pour tes précisions.

Bon, du coup je vais insister sur la lecture du bouquin (reverse engineering), et au pire si je galère vraiment sur un code je viendrai quémander des explications ici

[Møgluglu]

Il n'y a qu'une seule instruction classique qu'on retrouve dans tous les jeux d'instructions. C'est

Spoiler Alert!

le nop

. Le mov est facilement une des instructions les plus compliquées et qui a le plus de variantes et de modes d'adressages à la con.

Pour une vue plus globale, voir les cours/bouquins ci-dessus qui, dans la grande tradition Hennessy-Patterson, en font des tonnes sur la distinction RISC vs. CISC.

[Kesitem]

Je me permets de remonter à plus haut niveau

Je me suis remis au C++, il y a quelques mois (j'avais arrêté avant la publication des normes 2011 et 2014, autant dire que je suis bien rouillé).

J'ai un peu regardé les IDE et j'utilise CodeBlocks. Est-ce un bon choix?
Sachant que j'ai besoin d'un version "portable" et que je travaille avec MinGW, y a t-il des alternatives intéressantes?

[Patate]

J'aime beaucoup codelite.

[Kesitem]

Ah je vois qu'il peut gérer les projets CMake, c'est intéressant.
Je vais l'essayer.

[vectra]

Putain de Foley, Van Dam et al.
Il m'a foutu un bug de signes dans le calcul d'angles entre deux vecteurs
Bien les hotfixs après minuit, heure à laquelle les programmeurs sont censés dormir

[rOut]

Ok merci, ils me font de l’œil depuis quelques mois, mais à regarder les vidéos c'est un peu

Perso j'ai bien aimé, mais bon TIS-100 et Shenzhen I/O c'est quand même vraiment pour les autistes. Si tu aimes construire des cathédrales avec des allumettes ça peut te plaire. SInon les autres Zachtronics sont bien et plus accessibles, notamment Opus Magnum le dernier, et SpaceChem dans le même style mais plus rustre (Infinifactory j'ai pas aimé, trop dur à appréhender en 3D).

Opus Magnum ça se torche en ~15h, et je n'ai pas ressenti le besoin de trop peaufiner les solutions. TIS-100 j'ai passé genre 30h en repassant plusieurs fois sur chaque puzzle pour l'optimiser, et Shenzhen I/O 40h pareil (sans compter la campagne additionnelle ou je galère).

De toute manière les énigmes sont assez bien foutues et c'est assez progressif quand même (et Shenzhen I/O c'est juste TIS-100 en mieux).

- - - Mise à jour - - -

Merci Mogluglu pour tes idées, je vais regarder si je peux trouver ça... Je vais ptet même d'abord voir leurs cours pour déduire lequel semble le plus coller à ce que je recherche.

Si d'autres canards ont des idées à rajouter, n'hésitez pas !

C'est pas à toi que j'avais linké https://gcc.godbolt.org ? Chaque instruction est associée avec sa doc quand tu passes la souris dessus, donc ça peut être pas mal pour comprendre ce que ça fait.

Après, perso j'avais pas du tout accroché aux cours d'assembleur en école d'ingé, donc j'avais pas mal séché, et je suis probablement un peu à la ramasse, mais en reversant des programmes, instructions par instruction j'ai fini par me familiariser un peu... Bon, probablement pas de quoi être capable d'écrire 3 lignes qui tiennent la route en assembleur ou pour le lire couramment, mais suffisamment pour ne plus en avoir peur.

[Max_well]

Oui, Opus Magnum est une excellente introduction à SpaceChem. C'est globalement le même principe, sauf que SpaceChem est limité au niveau de la grille, ce qui implique des noeuds au cerveau.

Shenzhen I/O 40h pareil (sans compter la campagne additionnelle ou je galère).

La deuxième partie une fois parti de Schenzen (auquel cas merci beaucoup, je me sens moins seul), ou y'a encore une autre campagne derrière ?

[rOut]

Oui, Opus Magnum est une excellente introduction à SpaceChem. C'est globalement le même principe, sauf que SpaceChem est limité au niveau de la grille, ce qui implique des noeuds au cerveau.


La deuxième partie une fois parti de Schenzen (auquel cas merci beaucoup, je me sens moins seul), ou y'a encore une autre campagne derrière ?

Ouais Avalon City. J'ai tenté le premier puzzle et j'ai fini par laisser tomber (pour l'instant !).

[William Vaurien]

J'écris pas mal de bash, essentiellement de l'adaptation de vieux shell suite à différents changement - OS, intégration continue, depuis quelques temps.
A force d'écrire des trucs et d'apprendre à utiliser ce langage je commence presque à prendre plaisir.

J'ai même écris des tests unitaires, avec 2 méthodes 'assertEqual' et 'assertEmpty' pour un source contenant toutes les fonctions que j'ai créer pour refactoriser tous les doublons de code dans l'existant

[Nattefrost]

@William Vaurien Je sais pas ce que ça vaut, n'ayant jamais fait de unit test en bash (dieu m'en garde !) mais j'avais trouvé ça à une époque https://github.com/sstephenson/bats
C'est plus maintenu depuis un moment visiblement mais ptetre que ça fait le boulot.

[William Vaurien]

c'est juste un petit jeu de tests pour m'assurer que mes fonctions marchent aussi bien sous bash que sous ksh car j'ai des appels venant des 2 types de scripts et que ce sont des shells très cousins.
Pas besoin d'un truc en plus, c'est finalement assez simple et je ne compare que des strings...

[Møgluglu]

Spoiler pour les programmeurs CUDA : les cooperative groups de CUDA 9, c'est super cool sur le papier, mais c'est pas encore tout à fait sec. Il va falloir attendre CUDA 10 pour en profiter.