Hexworkshop Examnia...
 
Notifications
Clear all

Hexworkshop Examniation

bigmantech
(@bigmantech)
New Member

Hi guys i am trying to figure out the size of a file in hexworkshop i refer to the File system analysis book by Brian Carrier its say the file size can be determined by looking at 1c-1f in the hex table has anybody got any experience with hex work shop

Thanks

Quote
Topic starter Posted : 19/01/2013 3:24 am
binarybod
(@binarybod)
Active Member

bigmantech

Your question makes little or no sense.

Few file types provide information about the size of itself, so you are probably not talking about the data within the file.

The fact that you are using Hexworkshop is immaterial, any Hex editor/viewer would give you the same view of the data (unless it was defective in some way). What you need to know is what you are looking at and therein is (I suspect,) the problem.

The big clue is that you are reading Carrier. This is a book principally about file systems, it covers a number of filesystems including FAT, NTFS, Ext(2)(3) and HFS(+) (if memory serves me correctly). You are therefore probably reading a section on a particular filesystem that explains where the indexing record for that particular system stores the file size and it is at offset 1c-1f in the index record. Frankly I could go and look it up and give you the simple answer but I'd rather you learned how to do it yourself (if you are with me on that, then read on…).

Here's what to do -
* Work out what the filesystem is. Choose from FAT12, FAT16, FAT32, NTFS, exFAT, FATX, HFS, HFS+, Ext2, Ext3, Ext4, Btrfs, ZFS, JFS, XFS, ReiserFS - you might guess, there are many, many more…
* Visit Wikipedia or Forensicwiki or some other resource (Google is your friend) and work out what the indexing system for that particular filesystem is.
* Look at the structure, some of them are not easy, balanced B-Trees can be a nightmare, some however, are a piece of cake in comparison (I'm thinking FAT and NTFS but only probably because I know them so well).
* Having worked out where the filesystem you are looking at holds the file size, then you can have a look using Hexworkshop to confirm that this is correct.
* If it is right then you have learned something and you can revisit the Carrier book from the vantage point of prior knowledge. If however it is not correct then welcome to a world of hurt, go back to your starting point and try again.

Digital forensics is hard, it requires lots of research and reading. In the end it is rewarding because you learn so much…

Paul

ReplyQuote
Posted : 19/01/2013 5:05 am
bigmantech
(@bigmantech)
New Member

Thank you for that thank you so much indeed . And the file system im reviewing i FAT12 so i will bow follow ur words and search further ,

Thanks

ReplyQuote
Topic starter Posted : 19/01/2013 2:50 pm
Patrick4n6
(@patrick4n6)
Senior Member

* Look at the structure, some of them are not easy, balanced B-Trees can be a nightmare, some however, are a piece of cake in comparison (I'm thinking FAT and NTFS but only probably because I know them so well).

I hate to be picky, but as a former data structure geek, it bothers me when people get this wrong NTFS and other file systems use B+Trees, not B-Trees. There's a difference between the 2, and it matters when you're parsing them to know the difference. Esp B+Trees have horizontal traversal as well as tree traversal, and they contain redundant data.

ReplyQuote
Posted : 20/01/2013 1:33 am
binarybod
(@binarybod)
Active Member

I hate to be picky, but as a former data structure geek, it bothers me when people get this wrong NTFS and other file systems use B+Trees, not B-Trees.

Picky is good. I don't mind picky at all. In this case it just highlights my bad use of English. I wasn't intending to refer to NTFS or FAT as B-Trees which I heartily agree, neither of them are. There should have been a full stop (or 'period' for those of you from across the pond) after the word 'nightmare'.

It was late at night when I posted…

Paul

ReplyQuote
Posted : 21/01/2013 11:28 pm
Share:
Share to...