Comment interpréter un fichier de données binaire hérité sans documentation?

Question

Les

données sont souvent stockées dans des fichiers binaires spécifiques au programme pour lesquels il existe peu ou pas de documentation. Un exemple typique dans notre domaine concerne les données provenant d’un instrument, mais je soupçonne que le problème est général. Quelles sont les méthodes pour essayer de comprendre et d’interpréter les données?

Pour définir certaines limites. Les fichiers ne sont pas cryptés et il n'y a pas de DRM. Le type et le format du fichier sont spécifiques à l'auteur du programme (c'est-à-dire qu'il ne s'agit pas d'un "fichier standard" - tel que * .tar - dont l'identité a été perdue). Il n’ya (probablement) pas d’obscurcissement volontaire, mais il se peut que des efforts particuliers soient déployés pour gagner de la place. Nous pouvons supposer que nous avons une connaissance générale de la nature des données et que nous pouvons reconnaître certains, mais probablement pas tous, des champs et des tableaux.

Supposons que la majorité des données sont numériques, avec des scalaires et des tableaux (probablement à 1 ou 2 dimensions et parfois irrégulières ou triangulaires). Il y aura aussi des chaînes de caractères, probablement des noms de personnes, des sites, des dates et peut-être des mots-clés. Il y aura du code dans le programme qui lit le fichier binaire, mais nous n'avons pas accès à la source ou à l'assembleur. Par exemple, il peut avoir été écrit par un programme VAX Fortran ou par un ancien Unix ou par Windows sous forme d’objets OLE. Les chiffres peuvent être gros ou petits (ce qui n’est pas connu au début), mais c’est probablement cohérent. nous peuvent avoir différentes versions sur différentes machines (par exemple, Cray).

Nous pouvons supposer que nous avons un corpus de fichiers assez volumineux - quelques centaines, disons.

Nous pouvons supposer deux scénarios:

1. Nous pouvons relancer le programme avec différentes entrées pour pouvoir effectuer des expériences.
2. Nous ne pouvons pas réexécuter le programme. Nous avons un ensemble de documents fixe. Cela ressemble légèrement au décodage de documents historiques dans une langue inconnue (par exemple, Linear B).

Une solution partielle peut être acceptable - c’est-à-dire qu’il peut y avoir des champs qu’aucune personne vivante ne comprend maintenant, mais la plupart des autres sont interprétables.

Je ne m'intéresse qu'aux approches Open Source.

UPDATE Il existe une question SO ( Comment procéder au reverse engineering de formats de fichiers binaires à des fins de compatibilité ), mais l’accent est quelque peu différent. UPDATE : suggestion intelligente de @brianegge de s’adresser à (1). Utilisez truss (ou éventuellement strace sous Linux) pour vider tous les appels write () et similaires du programme. Cela devrait au moins permettre la collecte des enregistrements écrits sur le disque.

Answer 1

C’est une question intéressante. Je pense que la réponse est que l’ingénierie inverse des formats binaires est une compétence acquise, mais il existe des outils qui peuvent aider.

L'un de ces outils est WinOLS , conçu pour interpréter et éditer des images binaires de l’ordinateur de gestion du moteur du véhicule (principalement des données numériques dans leurs tables de recherche). Il prend en charge divers formats Endian (mais pas PDP, je pense) et permet d'afficher des données de différentes largeurs et décalages, de définir des zones de matrice (cartes) et de les visualiser en 2D ou 3D avec toutes sortes d'options de mise à l'échelle et de décalage. Il possède également un outil de recherche automatique de cartes heuristique / statistique, qui pourrait fonctionner pour vous.

C’est un outil commercial, mais la démo gratuite vous permettra de tout faire, sauf d’enregistrer les modifications apportées au fichier binaire et d’utiliser les fonctionnalités de gestion du moteur dont vous n’avez pas besoin. Vous avez indiqué que vous ne vous intéressiez qu'aux solutions open source, mais il s'agit de Stackoverflow et que quelqu'un d'autre ne serait peut-être pas aussi difficile.

Answer 2

tous les fichiers ont un en-tête. Commencez par là, voyez quelles sont les similitudes entre 2 fichiers, éliminez les "signatures" communes. et travailler avec les différences. Ils doivent indiquer le nombre d’enregistrements, la date d’exportation et des éléments similaires.

Les parties communes entre les deux en-têtes peuvent simplement être considérées comme des signatures générales et je suppose que vous pouvez les ignorer

Answer 3

Si vous utilisez un système offrant ferme , regardez simplement vos appels système pour écrire et vous aurez probablement une bonne idée. Il est également possible que le programme mappe un fichier et le copie directement à partir de la mémoire, mais cela est moins courant.

$ truss -t write echo foo
foowrite(1, " f o o", 3)                                = 3
write(1, "\n", 1)                               = 1

Il peut également être judicieux de jeter un coup d’œil au binaire. Sur les systèmes Unix, vous pouvez utiliser objdump pour afficher la présentation du fichier binaire. Cela pointera vers les sections de code et de données. Vous pouvez ensuite ouvrir le binaire est un éditeur hexadécimal et aller aux décalages spécifiques. Vous pouvez être intéressé par mes astuces sur les fichiers binaires Solaris .

Answer 4

• Diff 2 ou plusieurs fichiers pour rechercher des similitudes. Cela vous aide souvent à identifier les blocs d'en-tête et les différentes sections du fichier.

• L'endianisme est généralement assez facile à calculer - les octets les plus significatifs tendent à être zéro beaucoup plus souvent que les octets les moins significatifs, donc si vous voyez un motif du type "00 78" ou " 78 00 " vous pouvez bien deviner à quel octet correspond le msb. Cependant, ceci n’est utile que lorsque vous avez déterminé (approximativement) la nature des données précédentes, afin de savoir comment les données sont alignées.

• Recherchez des données facilement identifiables - les chaînes sont le premier point de départ car vous pouvez les repérer facilement. Celles-ci vous donnent souvent des indices, car elles sont généralement incorporées à proximité de données apparentées, utilisées comme éléments stanadard dans les en-têtes, etc. Si les chaînes sont unicodes, vous verrez généralement les lettres du texte séparées par zéro octets, ce qui vous aidera à identifier le caractère final. et l'alignement des données à cet endroit des données.

• Une approche de format courante (comme IFF) consiste à stocker des morceaux de données, chacun avec un petit en-tête (par exemple, un identifiant de 2 ou 4 octets, puis une taille de 2 ou 4 octets pour le bloc, puis les données de le bloc). En général, les gens utilisent des identifiants de morceaux significatifs (pour eux), de sorte qu'ils puissent être facilement repérés - Si vous trouvez ce qui ressemble à une balise, vérifiez les données suivantes pour voir si elles ressemblent à une longueur (regardez autant d'octets dans les données) pour voir si cela ressemble à un autre en-tête). Si vous pouvez identifier un tel format, vous coupez le fichier "un fichier volumineux". problème en un " beaucoup de petits fichiers " problème qui le rend beaucoup plus facile. (Cependant, de nombreuses données de périphérique ont tendance à être "optimisées" pour les rendre compactes, auquel cas les programmeurs jettent souvent les formats extensibles et encombrants dans leur ensemble, compressant ainsi des bits et rendant généralement les choses beaucoup plus difficiles pour vous)

• Recherchez les valeurs connues. Si votre appareil affiche " température: 40 " alors il est possible que vous trouviez cette valeur directement stockée dans le fichier. (Il est également courant d’utiliser des facteurs d’échelle ou des valeurs à virgule fixe, de sorte que 40 peut être représenté par (par exemple) 40 * 10 = 400 ou 40 * 256 = 10240)

• Si vous maîtrisez suffisamment le périphérique: créez des fichiers simples. Ce que vous essayez d’obtenir, ce sont les fichiers les plus petits que vous puissiez extraire de l’appareil afin de minimiser les données à examiner. Ensuite, effectuez une modification sur le périphérique qui entraîne la modification du fichier - essayez de réduire le nombre de modifications - et récupérez le fichier à nouveau. Si le format de fichier est " ouvert " (non compressé ni chiffré), vous devriez pouvoir identifier les octets modifiés.

• Si vous pouvez & charger; charger " fichiers sur le périphérique, vous pouvez également créer vos propres fichiers, en modifiant simplement une valeur pour voir si vous pouvez remarquer un changement de comportement sur le périphérique. Si vous parvenez à atteindre des valeurs simples, cela peut fonctionner correctement, mais vous risquez souvent de perdre le format de fichier et que l'appareil ne puisse plus lire les données.

Answer 5

J'espérais qu'il y avait un utilitaire magique capable de résoudre des problèmes, d'essayer différentes endianités, etc. Mais cela ne semble pas être le cas!