Anything related to computer forensics (new section!)
August 10th, 2020, 21:04
New to the forum. I have a file to restore that's fragmented into 36 chunks. I've read a lot of NTFS documentation and I understand it. What I haven't been able to find is the meaning of a zero offset byte when it's the last in the block. Anyone know the meaning?
32 02 04 63 A3 00 32 B8 03 7D 76 FF ...
Decoding this with my limited understanding:
2 length bytes and 3 offset bytes in the first block.
length = 0402 = 516 clusters @ offset 00A363 = (41,827 * sectors_per_cluster) + partition first sector
This is the right location for the first block but decoded this way puts the next block impossibly negative. The 6th byte in the string obviously means something I do not understand. Anyone?
August 11th, 2020, 9:18
Note to self: DOH!
August 11th, 2020, 9:43
run 1. 32 02 04 63 A3 00
Length = 0x0402
Offset = 0x00A363
run 2. 32 B8 03 7D 76 FF
Length = 0x03B8
Offset = 0x10019E0 (0xFF767D relative to 0x00A363)
No? (Been a while)
August 11th, 2020, 11:22
Wait, I see the problem, can you post entire file entry?
August 11th, 2020, 13:06
Did you take update sequence array into account?
August 11th, 2020, 19:16
Nice. I'd still like to see the entire file record. if you get weird values, there's a chance your data run 'uses' last two bytes of first sector of the file record in which case you'll have to look up actual values in the update sequence array. So, in these cases it's good to see the entire record. it must be well over 10 years since I wrote software to recover files from NTFS but I clearly remember that kept me frustrated for days (yeah, I'm not that much of a programmer).
August 13th, 2020, 0:12
Arch. Thanks for the response...s. Yes on the update sequence, last two bytes in the sector. It doesn't pose a problem when I properly promote 3-byte 5-byte 6-byte and 7-byte integers to a uint64_t. Seems like a wasted byte in a data run and hadn't seen it before. I recovered the file this afternoon.
I'm brand new to the C language. I skipped the "Hello World" program and went straight to "Hmm. Let's see if I can completely rebuild a Windows drive that's been formatted". Well, I can. Got it working this afternoon, after 8 months of free time at the keyboard, internet and "C by Example". Have to add some code for sparse and compressed files and clean up the code a bit what the heck, I can finish it without reading anymore.
Thanks again.
The complete datarun
32 02 04 63 A3 00 32 B8 03 7D 76 FF 22 93 03 C5 F8 22 5A 03 A7 ED 22 B8 02 13 33 22 A8 02 D7 09
32 8D 02 BC B6 00 32 82 02 E9 15 FF 22 FC 01 6A 3B 22 97 01 62 F3 22 58 01 21 37 22 3D 01 80 59
32 2F 01 17 46 FF 32 24 01 E2 DA 00 22 F0 00 AB FA 32 AA 00 5C 29 FF 22 A0 00 C7 F7 22 91 00 3B
1F 22 83 00 E7 53 21 79 01 06 21 79 AD 8D 31 63 D9 D0 00 31 4E 3A 42 FF 21 3C C7 E3 31 28 BB EF
00 21 25 1D E5 21 25 55 A2 21 24 F6 68 31 20 64 20 FF 21 13 AD 03 31 0B BA E5 00 21 07 F2 D7 31
01 6A 3A FF 22 62 02 A0 4B 22 9B 01 07 05 22 E9 00 70 12
August 13th, 2020, 14:30
beanpole wrote:I'm brand new to the C language. I skipped the "Hello World" program and went straight to "Hmm. Let's see if I can completely rebuild a Windows drive that's been formatted". Well, I can. Got it working this afternoon, after 8 months of free time at the keyboard, internet and "C by Example". Have to add some code for sparse and compressed files and clean up the code a bit what the heck, I can finish it without reading anymore.
Amazing!
Nice work.
August 13th, 2020, 17:37
... as i thought, a zero there does not mean it is wrong...
But then what did you need to fix from a C program?
pepe
August 14th, 2020, 8:30
Im guessing by the first post it is throwing all the chunks back together.
August 15th, 2020, 19:08
pepe
In my program I needed to take a variable number of bytes (1 to 8 bytes) and use them as a signed offset to the next chunk of data to rebuild the file. Not being familiar with C, I was doing it wrong. I put the first byte into an int64_t variable and shifted it left 8 bits then added the next byte. When all bytes were in the int64_t I NOTed it and added one. It gave me a negative number but not the correct one. I still don't know why it wasn't correct.
What did work was simply to OR the variable with all unused upper bits with 1.
HaQue
Correct
Thanks guys.
August 15th, 2020, 20:03
This sounds like it could be to do with 2's complement, I remember from University years ago but programming since I have never really had to worry about it, the int/float etc declarations are enough for anything I have needed to do as I never pursued software engineering after the degree.
https://www.cs.cornell.edu/~tomf/notes/cps104/twoscomp.html
August 16th, 2020, 0:36
HaQue
Yes 2's compliment stuff.
I didn't know how to correctly take individual bytes and put them into a signed 64-bit integer. I should have posted in a C programming forum but I thought the problem was in my lack of understanding of the data run. Found my answer. Thanks.
August 16th, 2020, 11:54
Update:
That 0x00 does mean something. After doing a bunch of testing with fragmented files, I believe that "If the last byte in the offset is 0x00 AND the next to last byte is greater than 0x7F then you should interpret the offset as a positive rather than a negative value. This project has been quite the challenge for this novice.
August 17th, 2020, 16:24
yeah, of course, coz in that case the sign bit is clear.
good point.
pepe
Powered by phpBB © phpBB Group.