microsoft excel question

When searching in encase i noticed that encase failed to pick these numbers up even though i could see them in front of me.

tootypegs, haven't Encase answered this for you directly or via the Encase forum?

that was my next step but now its become more of a curiosity question as to how excel stores its data relating to numbers. It is obviously in there some where but i cant find it.

Tootypegs,

Microsoft Excel files use the the OLE format (Object Linking and Embedding) to store their data. You may find some help in the MSDN forums. To view the data in a compound document, I would use Michal Mutl's Structured Storage Viewer.

http//www.mitec.cz/ssv.html

Hope this helps.

that was my next step but now its become more of a curiosity question as to how excel stores its data relating to numbers. It is obviously in there some where but i cant find it.

This really goes back to knowing your tools…

First, how are you looking or searching for the numbers in EnCase? I would assume that if you're searching for, say, the number 65535, then you're going to EnCase and running a search for the ASCII string "65535". Well, most programs don't store numbers that way…they do store strings that way, in ASCII (or Unicode), but not numbers.

Wow, I can't believe that I'm in a forum based on Forensics and having to describe how computers read numbers… D

Anyway, data is stored and read in binary format on a computer, or as bits, 1s and 0s. Since using only two states can give us only two values, we have to string these 1s and 0s together to get bigger numbers.

[skip]

So, all that being said, in order to store the number (NOT the string) 65535, the computer stores it as the hex value FFFF, which consumes 4 bytes, or 32-bits.

So, whichever number you're searching for, translate it to hexidecimal (you can do that with calc.exe on any Windows system), and search every DWORD value (every 4 bytes) for that number.

HTH,

H

..all that being said, in order to store the number (NOT the string) 65535, the computer stores it as the hex value FFFF, which consumes 4 bytes, or 32-bits. …

Just to add to this. I didn't see where the kind of number in question was stated. This adds additional complexity. Non-integers are rounded in the Excel display but the actual value and floating point structure underlying the displayed number can be radically different. One particular example of this is a Date/Time. Excel maintains these as floating point DAYS offset from one of two base times. Furthermore, the displayed value changes with the formatting of the cell, but the underlying number does not.