File formaat (4 byte waarde) reverse engineeren

Pagina: 1
Acties:

Vraag


Acties:
  • 0 Henk 'm!

  • AlphaRomeo
  • Registratie: Maart 2007
  • Laatst online: 22:33

AlphaRomeo

FP PowerMod
Topicstarter
Mijn vraag
Ik ben bezig een proprietary 3D formaat te reverse engineeren. Het gaat om een (gedateerd) bestandsformaat waarin verschillende 3D elementen ruimtelijk weergegeven kunnen worden zoals lijnen en punten. Ik ben er inmiddels achter dat één ruimtelijk XYZ coördinaat opgeslagen wordt als 12 bytes (4 bytes voor elk element).

Als ik de X waarde aanpas in de editor die ik bij deze software heb dan zie ik 4 bytes veranderen. De getallen hebben een zichtbare precisie van 3 decimalen in de software.

Ik heb niet het vermoeden dat de file geëncrypt is, anders waren er meer bytes gewijzigd, ik zie ook wel een duidelijk patroon in de getallenopbouw, maar voor zover ik kan nagaan voldoen de waardes op geen enkele manier aan een geldende standaard.

Hier zijn wat voorbeeld getallen die ik getest heb:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
00 00 80 BE ==         -1.000
6F 12 83 39 ==          0.001
6F 12 83 3A ==          0.004
00 00 01 3E ==          0.504
00 00 3F 3E ==          0.746
00 00 40 3E ==          0.750
00 00 41 3E ==          0.754
00 00 60 3E ==          0.875
00 00 80 3E ==          1.000
00 00 C0 3E ==          1.500
00 00 01 3F ==          2.016
00 00 02 3F ==          2.031
00 00 80 3F ==          4.000
00 00 C4 3F ==          6.125
00 60 6A 46 ==      60000.000
28 6B 6E 4D == 1000000000.000


Het gedeelte na 0.5 lijkt een voorspelbaar karakter te hebben, de waarde wordt telkens vergroot met 0.004 wat mij doet denken dat er ergens een factor gecodeerd is.

Wat ik geprobeerd heb:
* Little / big endianess
* Nagaan of de waarde misschien een int was met een factor er overheen
* Nagaan of de waarde als single 4-byte float geldig is
* Internet search of er nog andere floating point standaarden zijn

Relevante software en hardware die ik gebruik
HxD gebruikt om de files te lezen en binair te vergelijken waardoor ik de offset van de waarde kan achterhalen.

Als ik eenmaal achterhaald heb hoe ik de waarde om kan zetten heb ik kennis genoeg om er een fatsoenlijke importer / converter voor te maken. Mijn vraag richt zich er nu vooral op wat dit toch voor formaat is.

Beste antwoord (via AlphaRomeo op 12-10-2021 15:56)


  • Vaan Banaan
  • Registratie: Februari 2001
  • Niet online

Vaan Banaan

Heeft ook Apache ontdekt

Dat is het inderdaad en dan de waarde x 4 doen.
De tabel is big little endian zo te zien:
https://babbage.cs.qc.cuny.edu/IEEE-754.old/32bit.html
3983126f: 0.0002500000118743628 * 4 = 0.001
3fc40000: 1.53125 * 4 = 6.125
466a6000: 15000 * 4 = 60000

[ Voor 8% gewijzigd door Vaan Banaan op 12-10-2021 15:55 ]

500 "The server made a boo boo"

Alle reacties


Acties:
  • +2 Henk 'm!

  • GarBaGe
  • Registratie: December 1999
  • Laatst online: 03-10 14:56
Is het niet een IEEE 754 sinle-precision binary floating-point format?
Afbeeldingslocatie: https://tweakers.net/i/8Ny8RQDCKrYUEnINQPfUm1TkM0E=/800x/filters:strip_exif()/f/image/SNoDR18dShk0zHSzobtZspht.png?f=fotoalbum_large

Ryzen9 5900X; 16GB DDR4-3200 ; RTX-4080S ; 7TB SSD


Acties:
  • 0 Henk 'm!

  • AlphaRomeo
  • Registratie: Maart 2007
  • Laatst online: 22:33

AlphaRomeo

FP PowerMod
Topicstarter
Nee, helaas niet IEEE754. HxD heeft de functie om die automatisch om te zetten, ook als ik een online converter probeer, kom ik niet op mijn waardes, zelfs niet in de buurt. Bovendien had ik dan verwacht dat de high bytes bij 60000 een andere waarde zouden hebben.

Edit: wel dus, maar met factor 4. Bedankt!

[ Voor 7% gewijzigd door AlphaRomeo op 12-10-2021 16:02 ]


Acties:
  • Beste antwoord
  • +3 Henk 'm!

  • Vaan Banaan
  • Registratie: Februari 2001
  • Niet online

Vaan Banaan

Heeft ook Apache ontdekt

Dat is het inderdaad en dan de waarde x 4 doen.
De tabel is big little endian zo te zien:
https://babbage.cs.qc.cuny.edu/IEEE-754.old/32bit.html
3983126f: 0.0002500000118743628 * 4 = 0.001
3fc40000: 1.53125 * 4 = 6.125
466a6000: 15000 * 4 = 60000

[ Voor 8% gewijzigd door Vaan Banaan op 12-10-2021 15:55 ]

500 "The server made a boo boo"


Acties:
  • 0 Henk 'm!

  • CurlyMo
  • Registratie: Februari 2011
  • Laatst online: 22:15
GarBaGe schreef op dinsdag 12 oktober 2021 @ 15:40:
Is het niet een IEEE 754 sinle-precision binary floating-point format?
Dan zou je toch al een verschil moeten zien in de eerste byte tussen de eerste en de volgende voorbeelden? Of het moet little-endian zijn.

Inderdaad wat @Vaan Banaan schrijft, maar dan dus in little-endian:
Wikipedia: Endianness

[ Voor 18% gewijzigd door CurlyMo op 12-10-2021 15:54 ]

Sinds de 2 dagen regel reageer ik hier niet meer


Acties:
  • 0 Henk 'm!

  • AlphaRomeo
  • Registratie: Maart 2007
  • Laatst online: 22:33

AlphaRomeo

FP PowerMod
Topicstarter
Vaan Banaan schreef op dinsdag 12 oktober 2021 @ 15:49:
Dat is het inderdaad en dan de waarde x 4 doen.
De tabel is big little endian zo te zien:
https://babbage.cs.qc.cuny.edu/IEEE-754.old/32bit.html
3983126f: 0.0002500000118743628 * 4 = 0.001
3fc40000: 1.53125 * 4 = 6.125
466a6000: 15000 * 4 = 60000
Wow! Enorm bedankt voor de snelle hulp.

Acties:
  • +1 Henk 'm!

  • CurlyMo
  • Registratie: Februari 2011
  • Laatst online: 22:15
AlphaRomeo schreef op dinsdag 12 oktober 2021 @ 15:56:
[...]

Wow! Enorm bedankt voor de snelle hulp.
Ik zou dan toch eerlijkheidshalve zeggen dat @GarBaGe als eerste het juiste antwoord had (alleen dan zonder vermelding van de endiannes). Zoiets zie je niet vaak op andere fora _/-\o_

Sinds de 2 dagen regel reageer ik hier niet meer


Acties:
  • 0 Henk 'm!

  • AlphaRomeo
  • Registratie: Maart 2007
  • Laatst online: 22:33

AlphaRomeo

FP PowerMod
Topicstarter
CurlyMo schreef op dinsdag 12 oktober 2021 @ 15:59:
[...]

Ik zou dan toch eerlijkheidshalve zeggen dat @GarBaGe als eerste het juiste antwoord had (alleen dan zonder vermelding van de endiannes). Zoiets zie je niet vaak op andere fora _/-\o_
Inderdaad ook @GarBaGe bedankt, maar vooral de factor 4 maakt het zo ingewikkeld, anders had ik mijn waarde wel eerder herkend in de hex editor.

Edit: is dat een common practice trouwens? Floating point waardes vermenigvuldigen voor opslag?

[ Voor 9% gewijzigd door AlphaRomeo op 12-10-2021 16:01 ]


Acties:
  • +1 Henk 'm!

  • DataGhost
  • Registratie: Augustus 2003
  • Laatst online: 23:11

DataGhost

iPL dev

AlphaRomeo schreef op dinsdag 12 oktober 2021 @ 16:00:
Edit: is dat een common practice trouwens? Floating point waardes vermenigvuldigen voor opslag?
Niet per se. Maar als nauwkeurigheid onder 0.001 niet echt nodig is en een vier keer zo grote range naar boven toe wel, is dat iets wat je kan doen. Dan heb je toch een andere range zonder extra storage voor bijv. een double.
Pagina: 1