| Les deux révisions précédentesRévision précédente | |
| back2root:reverse-engineering:future-crew-unreal-reverse-engineering-part-1 [2023/01/07 10:44] – ↷ Page déplacée de back2root:tutoriaux:future-crew-unreal-reverse-engineering-part-1 à back2root:reverse-engineering:future-crew-unreal-reverse-engineering-part-1 frater | back2root:reverse-engineering:future-crew-unreal-reverse-engineering-part-1 [2023/01/07 10:56] (Version actuelle) – ↷ Liens modifiés en raison d'un déplacement. frater |
|---|
| En regardant le code de second reality et en lisant excellente review de Fabien, je me suis dit que unreal devait avoir la même structure. j'ai donc jeté un oeil sur l'exe via un petit utilitaire 'unp.exe' (http://unp.bencastricum.nl/) juste pour voir... et bingo... le fichier exécutable n'est pas de 2 mb, mais plutôt de 25kb il s'agit donc bien d'un loader, voir même d'un DIS (Demo Interrupt Server), comme dans le cas de Second Reality. | En regardant le code de second reality et en lisant excellente review de Fabien, je me suis dit que unreal devait avoir la même structure. j'ai donc jeté un oeil sur l'exe via un petit utilitaire 'unp.exe' (http://unp.bencastricum.nl/) juste pour voir... et bingo... le fichier exécutable n'est pas de 2 mb, mais plutôt de 25kb il s'agit donc bien d'un loader, voir même d'un DIS (Demo Interrupt Server), comme dans le cas de Second Reality. |
| |
| {{ :back2root:unp.png |}} | {{ back2root:reverse-engineering:unp.png |}} |
| |
| Dans Second Reality, les parties et assets ne sont décrit que dans une série d'offset hardcodé dans le loader (c'est ce que nous apprends le code source du loader de second reality) et actuellement, il m'est impossible d'obtenir les sources de "unreal.exe", donc en désespoir de cause, je jettes un petit coup d’œil sur le fichier en mode hexa; nous savons déjà que les 26315 (+le header DOS de 32 bytes) premiers octets contiennent le loader et sans doute également le DIS et sont donc sans intérêt... les données (musiques, graphiques, etc) commencent après l'offset 26315+32, soit 26347, ou 0x66EB en hexa cette valeur va réapparaître comme par miracle plus tard. | Dans Second Reality, les parties et assets ne sont décrit que dans une série d'offset hardcodé dans le loader (c'est ce que nous apprends le code source du loader de second reality) et actuellement, il m'est impossible d'obtenir les sources de "unreal.exe", donc en désespoir de cause, je jettes un petit coup d’œil sur le fichier en mode hexa; nous savons déjà que les 26315 (+le header DOS de 32 bytes) premiers octets contiennent le loader et sans doute également le DIS et sont donc sans intérêt... les données (musiques, graphiques, etc) commencent après l'offset 26315+32, soit 26347, ou 0x66EB en hexa cette valeur va réapparaître comme par miracle plus tard. |
| Tout en parcourant le fichier, j'ai vu des chaînes de caractère, notamment "Scream Tracker V3.0... (offset 0x1430), en parcourant tout le fichier, je suis arrivé à la fin du fichier,et une série de "noms" de fichiers sont apparus, j'en ai compté 97 en tout. On remarque ci-dessous que le fichier contient également des sous exécutables (sans doute les sous-parties de la démo). | Tout en parcourant le fichier, j'ai vu des chaînes de caractère, notamment "Scream Tracker V3.0... (offset 0x1430), en parcourant tout le fichier, je suis arrivé à la fin du fichier,et une série de "noms" de fichiers sont apparus, j'en ai compté 97 en tout. On remarque ci-dessous que le fichier contient également des sous exécutables (sans doute les sous-parties de la démo). |
| |
| {{ :back2root:pattern.png }} | {{ back2root:reverse-engineering:pattern.png }} |
| |
| Il y a aussi une pattern très claire 16 octets pour le nom de fichier, et de 2 mots de 32 bits, soit un "bloc" de 24 octets au total que l'on peut décrire comme ceci: | Il y a aussi une pattern très claire 16 octets pour le nom de fichier, et de 2 mots de 32 bits, soit un "bloc" de 24 octets au total que l'on peut décrire comme ceci: |
| Toutefois, il y a un dernier "unsigned long" à la fin (0x00249911) qui est assez finalement assez simple à déduire; il s'agit d'un pointeur d'offset sur le début de la table de fichier: | Toutefois, il y a un dernier "unsigned long" à la fin (0x00249911) qui est assez finalement assez simple à déduire; il s'agit d'un pointeur d'offset sur le début de la table de fichier: |
| |
| {{ :back2root:directory.png }} | {{ back2root:reverse-engineering:directory.png }} |
| |
| Sauf que à l'offset pointé, il y a 3 unsigned long: | Sauf que à l'offset pointé, il y a 3 unsigned long: |
