Thanks for the help so far.
I Tried Bochs and got an error about a missing dll when trying to run the software although every file was in place.
I Tried DOSBox and got the error "This is not a valid -name-of-software-here- application" for most of the executable files of the program. After running almost all exe's in dosbox (
) I found one that lets me access the consumer-data. I cant change the values in the menu but at least I can display a specific consumer and his last purchase.
Change the data in the program and see what changes in the file.
I went the other way around and changed some values inside the binary-file. This is what I got:
hex dez dual
FF junk (random text written over the boundaries of the textbox)
99 junk (random text written over the boundaries of the textbox)
64 junk (random text written over the boundaries of the textbox)
66 junk (random text written over the boundaries of the textbox)
0170 0,00 101110000
0179 0,00 101111001
017A 0,01 101111010
017B 0,02 101111011
017D 0,06 101111101
017E 0,13 101111110
017F 0,25 101111111
0180 0,50 110000000
0181 1,01 110000001
0182 2,02 110000010
0183 4,03 110000011
0184 8,06 110000100
8E79 -0,00 1000111001111001
8E7A -0,01 1000111001111010
8E84 -8,88 1000111010000100
One value is still 4 bytes in size, I just tried low values first!
Looking at the dualnumber representation of the values it looks like there is a pattern. But I realized that I'm not good with numbers at this point^^ Ill investigate this further tomorrow, just want to let this here in case somebody wants to take a look.
I doubt they're floating-point, unless the authors of the software are really incompetent; you don't use floating-point numbers, ever, for financial software. (Floating-point numbers tend to result in rounding errors because they can't precisely represent decimal values.)
I would suspect that there's a ratio you need to divide by in order to get the values you see in the program.
MMh, good point. I tried to multiply/devide by 100 to get rid of the decimalpoint or to readd it but it was no use.EDIT:
I think I'm quite near to find out how it works
By toying around with every byte for the value displayed in the program I found out that an exponent is used to calculate the actual floating point number (see the end of the spoiler). Since I only understood that IEEE754 is using a system of an exponent of 2 and one bit for the algebraic sign I had a look at it again. I still don't get what a mantissa is though ^^. While investigating the IEE754 standard I converted some values from the program and noticed that 3 bytes are identical to the hexadecimal representation of the program.
Example, 46,70 DM (or any other currency, it doesn't matter) is:
Financing Software: CD CC 3A 86
IEEE-Standard: 42 3A CC CD
By seeing this and by changing some values and having a look at the dual number representation I found out that the bitflag for the arithmetic sign is stored somewhere else but in the first bit (it is the 16th bit read from right to left). So the 86 of booth different bytes (86 and 42) is not holding the bit for the arithmetical sign but is still of. How do I get a 42 out of a 86? Just shifting one to the right will not work but is near to the right value (86 shiftright = 43)
Any ideas?EDIT 2:
Fiddled around a bit more. It almost looks like they calculated the exponent from the one different byte by substracting 129(decimal) from it. I try to verify this tomorrow.