| Les deux révisions précédentes Révision précédente | Prochaine révisionLes deux révisions suivantes |
| back2root:tutoriaux:future-crew-unreal-reverse-engineering-part-1 [2022/07/27 11:23] – frater | back2root:tutoriaux:future-crew-unreal-reverse-engineering-part-1 [2022/07/27 11:29] – [Deep dive dans le fichier] 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:tutoriaux:unp.png?nolink }} | {{ :tutoriaux:unp.png?nolink }} |
| |
| 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. |
| 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:tutoriaux:directory.png?nolink }} | {{ :tutoriaux:directory.png?nolink }} |
| |
| Sauf que à l'offset pointé, il y a 3 unsigned long: | Sauf que à l'offset pointé, il y a 3 unsigned long: |
