FILETIME & conversion issues.

I am attempting to ascertain the shutdown time of a system. So, I pulled the value from ShutdownTime from \SYSTEM\ControlSet001\Control\Windows and the value is c4 fc 00 07 4d 8c c4 01.

I converted this to decimal using http//easycalculation.com/hex-converter.php which resulted in 1975618586296337.

Hm … the number you converted is even … and you get an odd number out of it? Does the script really work as it should? Have you tested it – I mean serious testing, with your black hat on? (Try any filetime-to-UTC converting tool on the value 0 – convert to little-endian or big-endian as appropriate. If the tool says something about illegal date, it's wrong, unless its documentation explains why in a way you accept as correct .)

Welcome to the world of computer forensic tools. The most useful thing they do is teach users about misplaced trust.

Or did you perhaps forget that the timestamp is in small-endian form, with the least significant byte first?

Any advice?

It's always your own head on the block.

But if you do use a Windows system, you may want to look at DCode. The version I have fails the '0' test, unfortunately, but at least it tells you about different representations you may run into.

Off the top of my head I think its a Windows 64 bit time stored as Little Endian.

Try

http//www.digital-detective.co.uk/downloads.asp

Program called DCode.exe

Hi Sam,

Something seems to have gone wrong in your conversion and I'm guessing it maybe somewhere along the lines of you not accounting for the conversion having to be read little endian? Anyway, an easy tool to remember in future is DCode by Digital Detective, you can enter the Hex and convert with a click of the mouse. You can find the tool here http//www.digital-detective.co.uk/freetools/decode.asp. Your date converts to Fri, 27 August 2004 154633 UTC.

Although this looks slightly historic to be correct (unless its an old machine or they never shut it down!) and you might want to check that you are looking at the correct ControlSet. Look under the \LocalMachine\System\Select\Current key to see what ControlSet is active. Then convert that LastShutdown value.
For info http//support.microsoft.com/kb/100010

Hopefully I've not made any errors as it's late and I've been imaging all day so I'm going a little stir crazy….

Shep

Alright… so, let me see if I can get this straight

I forgot about big and little endian. I thought everything was in little endian in the registry, for whatever reason.

That DCode is a great tool, and I just confirmed that everything matches up with the reversed hex…

What I am not clear on is, if the original hex, c4 fc 00 07 4d 8c c4 01 is provided to me in little endian, why do I need to reverse it to big endian in order to obtain the correct FILETIME result?

Thank you everyone for chiming in!

What I am not clear on is, if the original hex, c4 fc 00 07 4d 8c c4 01 is provided to me in little endian, why do I need to reverse it to big endian in order to obtain the correct FILETIME result?

That depends on the tool you are using.

DCode, for example, accepts both big-endian and little-endian byte sequences, and makes the necessary adjustments itself. If the tool you are using needs the value (not how it has been stored), you need to do the conversion from bytes to value in some other way.

The value is what is important. The big-endian/little-endian stuff is how that value happens to be stored in some particular place. In order to get at the value, you need to know how it has been represented.

Thank you for the explanation – I still don't understand why the value would need any reversing at all. If the value is originally little-endian, under what circumstances would any tool require it in big-endian? And, what would be any advantage of programming it that way?

This quote sums it up better than I could 'an argument for little-endian order is that as you increase a numeric value, you may need to add digits to the left (a higher non-exponential number has more digits). Thus, an addition of two numbers often requires moving all the digits of a big-endian ordered number in storage, moving everything to the right. In a number stored in little-endian fashion, the least significant bytes can stay where they are and new digits can be added to the right at a higher address. This means that some computer operations may be simpler and faster to perform'.

Remember 'very' generally Intel - Little Endian, Motorola - Big Endian.

Shamless plug alert!

Someone in our unit created a lovely little tool which allows you to test a single hex string against a series of known filetimes - just in case you aren't sure. It is called "Stampede", and can be found here

FF download page

(end shameless plug)

Thank you for the explanation – I still don't understand why the value would need any reversing at all. If the value is originally little-endian, under what circumstances would any tool require it in big-endian? And, what would be any advantage of programming it that way?

The endianness is basically built into the CPU. When it reads or writes a large value from memory to a CPU register, or vice versa, it does so in a certain way. Big-endian CPUs write the most significant group of bits in the first byte, the next group in the following byte, etc. A little-endian CPU writes the least-significant group of bits in the first byte, etc. (There are exceptions, but they're irrelevant here.)

The CPU is not endian – it operates on values. It's when that value is stored in memory that endianness is applied.

The value of storing data using the same endianness as the CPU is that reads and writes are trivial you use the standard CPU instruction. If you want the reverse endianness, you need to reverse the bit groups of the value before it is written, or after it has been read from the medium it is stored on. SOme CPUs has support for swapping bytes in a word or words in a doubleword – in others you have to do manual bit extractions and shifting 'by hand', as it were. That's messy. The best way to appreciate this, by the way, is probably using assembly language and a machine code debugger this is a very fundamental hardware property, and can be difficult to appreciate 'in abstract'.

In short you don't want to fight the CPU arcitecture. If you're on an Intel system, you do litlle-endian; I don't know if there are any Motorola processors anymore, but at one time they were the main big-endian CPUs, and were used in all Apple computers.

So … if you are trying to make sense of *any* value that needs more than 8 bites to store, you must known about endianness to know which of the bytes contain what part of the value. The second script you mentioned obviously expected to get a value, not a sequence of bytes, to make to time stamp conversion. Then your job is to convert the byte sequence into that value – so you have to know exactly how it is stored. (That requirement extends to *any* value stored in memory or on disk it's fundamental knowledge for any forensic examiner. )

DCode, on the other hand, accepts a byte sequence – it does the value reassembly itself, as long as you say what endianness is being used.

Usually it's the split between the value on the on hand and the split-up of that value into bytes when it is stored somewhere in memory that can be difficult to understand.