Le 03/10/2015 à 09h 44

Drepanocytose a écrit :

L’acronyme OIV n’est pas bien expliqué dans le texte, c’est dommage. Tous les autres ont leur version littérale écrite avec juste derrière l’acronyme entre parenthèses…
Question de forme, rien de bien méchant.


Un OIV est un Opérateur d’Importance Vitale. La liste n’est pas connue publiquement, elle a été publiée par décrvet “secret”. Cependant, on sait qu’elle contient tous les organismes et entreprises nécessaires au bon fonctionnement du pays en cas de problèmes. On peut donc estimer qu’elle contient les FAI, les fournisseurs d’électricité, d’eau, les transporteurs (SNCF & co), etc.

Le 02/10/2015 à 20h 17

eliumnick a écrit :

Il te faut les 2.
Avec le reverse, tu ne peux étudier que les comportements observés. Mais qui te dit que par exemple ton application n’a pas un comportement néfaste qui ne s’exécute qu’au bout de 10 ans d’uptime ? (cas à la con, mais c’est pour l’exemple).


Bah non… Le reverse engineering te permet de reverser l’intégralité de l’application, même les chemins non exécutés dans tes scenarii de tests.
 
Quand je parle de reverse engineering ici, je me réfère bien évidemment au “disassembling” et non au “black boxx testing”. Dans le second cas, ton commentaire ferait sens. Mais cependant, on tire plus d’informations grâce au premier qu’au second, d’où le fait qu’il faille privilégier le disassembling pour analyser une application (ou un OS :-)).

Le 01/10/2015 à 21h 05

eliumnick a écrit :

Le reverse a des limites. Tu peux trouver comment fonctionne 99,9% du logiciel, mais tu ne pourras jamais être certain de le connaitre à 100% sans lire le code.


Sans vouloir rentrer dans un débat stérile où beaucoup s’expriment sans bien comprendre de quoi il retourne, techniquement, le reverse engineering fournit une meilleure connaissance de l’application finale (sous réserve de comprendre ce que l’on fait) pour la simple et unique raison que l’on observe ce qui va réellement être exécuté sur la machine (à quelques exceptions près).
 
 

En effet, entre le code source et le binaire, il y a eu le compilateur. Rien n’empêche que le compilateur n’ajoute des backdoors dans le code. Et rien n’empêche que des optimisations du compilateur lui-même conduisent à des failles de sécurité (la preuve par l’exemple avec Brad Spender & GCC :https://grsecurity.net/~spender/exploits/exploit2.txt). Bref, mieux vaut éventuellement avoir le code source pour se faire une idée de ce que fait le logiciel (vaguement) et vraiment avoir le binaire pour l’analyser en profondeur et définir précisément ce qu’il fait.
 

 Donc, tu peux le connaître à 100% sans même avoir lu une seule ligne de son code (après tout, grâce au reverse engineering, tu peux le réécrire toi-même le code). Ne pas avoir le WRK (dans le cas de Windows) n’empêche pas son audit, donc (loin de là !).

Le 30/05/2014 à 12h 00

Dr.Wily a écrit :

…ou alors un rachat de la part de MS comme ça été le cas avec sysinternal il y a quelques années. Le scénario était a peu prêt le même. Disparition des outils sans donner une seule explication.


Les outils sont toujours disponibles :http://technet.microsoft.com/en-US/sysinternals
Ne serait-ce que parce qu’ils sont abondamment utilisés dans les livres Windows Internals…

Le 05/05/2014 à 12h 45

EMegamanu a écrit :

Les timestamp sont des entiers signés ? :o


Sous Linux, non, en tout cas. Il s’effectuera donc bien un retour en 1970.
Le bug de 2038 n’affecte que ceux qui stockent ça sur un signed 32 bits. Ceux qui sont sur un unsigned 32 bits ont (un peu) plus de marge !