Join Us!

Is it possible to c...
 
Notifications
Clear all

Is it possible to change a directory entry record in exFAT?  

  RSS
Skywalker
(@skywalker)
Active Member

Hi everybody,

I'm studying a case in which it is possible a directory entry has been modified (manipulated). I know there is a checksum in every directory entry, could it be possible to manipulate the checksum too? How could I prove the register was manipulated?

Thanks and regards.

Quote
Posted : 05/09/2019 2:28 am
Passmark
(@passmark)
Active Member

Every time you create a file, or modify a file, the directory entry gets modified.
So yes it is possible, the file system wouldn't work if it wasn't.

But I am guessing you are suggesting it was modified by a hex editor (or similar). In which case anything is possible. The possibility of detecting this depends on how good the tool was (or how much knowledge the person had) and how good your own knowledge is. But to be honest not many people have the knowledge to directly edit the file system in hex.

I haven't checked but I would have thought chkdsk would pick up a bad checksum.

ReplyQuote
Posted : 05/09/2019 3:09 am
athulin
(@athulin)
Community Legend

I'm studying a case in which it is possible a directory entry has been modified (manipulated).

A reasonably quick TLDR can be found here https://community.spiceworks.com/topic/497931-and-in-this-corner-we-have-dave-funny-cartoon . Only 'human error' applies everywhere for you the user of the exFAT volume, to whoever reverse-engineered exFAT for the information you seem to rely on, and to yourself and other analysts working on it. Then think about how you use the word 'prove'.

Long version

Please define/describe 'manipulation', why some form of manipulation is the only explanation to what you have found, and perhaps more details as to what exactly the manipulation is thought to have been done, and what resources would be required to do them successfully. Getting those details down helps in avoiding investigation drift, as well as weeding out blatant absurdities.

Modification happens all the time, both in the course of normal user access, normal program access, and unusual but correct access. And as you have a software environment, changes can also be due to unusual circumstances that are not adequately handled by that or other software … that is, bugs. You can get some pretty odd results by a fair amount of 'luck' if you pull the power from a system, for example, and if RAM chip fails unexpectedly, you can also get some outlandish results.

With things such as exFAT, intended to be used on external media, you also have to take different implementations into account. Last I heard (though things may have changed) exFAT support was something you had to license from Microsoft. Reverse-engineered implementations will thus run the risk of doing things differently, especially in unusual circumstances, as well as being incomplete for some scenarios, and the effect of those two factors (non-standard implementation, unusual circumstances) may produce effects that can be taken for hostile and intentional.

I know there is a checksum in every directory entry, could it be possible to manipulate the checksum too?

This is why you need an idea of how the modification/manipulation was performed. I believe you could easily use a hex editor such as HxD or Winhex or … that allows you to edit every single bit on the media that the platform allows you to see. I have used HxD to 'tweak' timestamps in NTFS images; I don't expect it to be much more difficult to tweak bytes in an exFAT image. All I think I needed was very good knowledge of the file system, local admin privileges to access to raw 'disk', the hex editor, and sufficient amounts of good luck or backup to ensure that any mistake I made would not cause a total failure. (external volumes are somewhat easier in that last respect).

Also … as exFAT specifications are proprietary and licensed (?), you may also consider if your knowledge about exFAT is reliable. You are not basing your ideas about manipulation on reverse-engineered information from outdated versions or incompletely done analysis, are you? (Me … I would stay away from trying too hard interpret file systems artifacts if the file system does not have up-to-date public specification – which means that anything involving FAT, last defined in 2000 I believe is one of those areas where the term 'as far as I know' would feature very prominently. And if you have to use that phrase, 'proof' is probably not the correct term for what you are doing.)

(Checksums can be tricky some specification allows them to be explicitly undefined. If exFAT allows that, you better know the exact circumstances. And it's not at all unusual for specifications to get checksum algorithms wrong, or for software to implement them wrong. If you know of any such implementation, such checksums might be indicators that that particular implementation has been used, for example.)

Again, define 'manipulation'. State what actions ('change checksum', 'alter file size', 'remap sectors', …) you believe have been performed, and then look at each of those individually (that is, what does it take technically to make such a change), together, as well as in the context of Real World. If the 'manipulation' requires, say, an hour to perform, but the external medium has not been out of sight for an hour, you clearly have to look for alternative explanations.

To prove manipulation, you probably have to prove user-controlled action, directly or indirectly (i.e. it could not have been a bug, or a glitch, or some other malfunction), as well as intent.

If you have not thought about proving those in a computer environment, it's time to do so now. Me, if I had to ask, I would not even try, unless I had much more than just an exFAT volume. Just about everything I once might have put down to malice aforethought turned out be bugs, uninformed users (who happily did what equally clueless people on the Internet recommended them to do in order to speed up their computers), failed hardware, and people blindly following official instructions that actually were not valid for the particular equipment.

And that's Dave, in different incarnations. See TLDR link above.

ReplyQuote
Posted : 05/09/2019 7:26 am
Skywalker
(@skywalker)
Active Member

I'm studying a case in which it is possible a directory entry has been modified (manipulated).

A reasonably quick TLDR can be found here https://community.spiceworks.com/topic/497931-and-in-this-corner-we-have-dave-funny-cartoon . Only 'human error' applies everywhere for you the user of the exFAT volume, to whoever reverse-engineered exFAT for the information you seem to rely on, and to yourself and other analysts working on it. Then think about how you use the word 'prove'.

Long version

Please define/describe 'manipulation', why some form of manipulation is the only explanation to what you have found, and perhaps more details as to what exactly the manipulation is thought to have been done, and what resources would be required to do them successfully. Getting those details down helps in avoiding investigation drift, as well as weeding out blatant absurdities.

Modification happens all the time, both in the course of normal user access, normal program access, and unusual but correct access. And as you have a software environment, changes can also be due to unusual circumstances that are not adequately handled by that or other software … that is, bugs. You can get some pretty odd results by a fair amount of 'luck' if you pull the power from a system, for example, and if RAM chip fails unexpectedly, you can also get some outlandish results.

With things such as exFAT, intended to be used on external media, you also have to take different implementations into account. Last I heard (though things may have changed) exFAT support was something you had to license from Microsoft. Reverse-engineered implementations will thus run the risk of doing things differently, especially in unusual circumstances, as well as being incomplete for some scenarios, and the effect of those two factors (non-standard implementation, unusual circumstances) may produce effects that can be taken for hostile and intentional.

I know there is a checksum in every directory entry, could it be possible to manipulate the checksum too?

This is why you need an idea of how the modification/manipulation was performed. I believe you could easily use a hex editor such as HxD or Winhex or … that allows you to edit every single bit on the media that the platform allows you to see. I have used HxD to 'tweak' timestamps in NTFS images; I don't expect it to be much more difficult to tweak bytes in an exFAT image. All I think I needed was very good knowledge of the file system, local admin privileges to access to raw 'disk', the hex editor, and sufficient amounts of good luck or backup to ensure that any mistake I made would not cause a total failure. (external volumes are somewhat easier in that last respect).

Also … as exFAT specifications are proprietary and licensed (?), you may also consider if your knowledge about exFAT is reliable. You are not basing your ideas about manipulation on reverse-engineered information from outdated versions or incompletely done analysis, are you? (Me … I would stay away from trying too hard interpret file systems artifacts if the file system does not have up-to-date public specification – which means that anything involving FAT, last defined in 2000 I believe is one of those areas where the term 'as far as I know' would feature very prominently. And if you have to use that phrase, 'proof' is probably not the correct term for what you are doing.)

(Checksums can be tricky some specification allows them to be explicitly undefined. If exFAT allows that, you better know the exact circumstances. And it's not at all unusual for specifications to get checksum algorithms wrong, or for software to implement them wrong. If you know of any such implementation, such checksums might be indicators that that particular implementation has been used, for example.)

Again, define 'manipulation'. State what actions ('change checksum', 'alter file size', 'remap sectors', …) you believe have been performed, and then look at each of those individually (that is, what does it take technically to make such a change), together, as well as in the context of Real World. If the 'manipulation' requires, say, an hour to perform, but the external medium has not been out of sight for an hour, you clearly have to look for alternative explanations.

To prove manipulation, you probably have to prove user-controlled action, directly or indirectly (i.e. it could not have been a bug, or a glitch, or some other malfunction), as well as intent.

If you have not thought about proving those in a computer environment, it's time to do so now. Me, if I had to ask, I would not even try, unless I had much more than just an exFAT volume. Just about everything I once might have put down to malice aforethought turned out be bugs, uninformed users (who happily did what equally clueless people on the Internet recommended them to do in order to speed up their computers), failed hardware, and people blindly following official instructions that actually were not valid for the particular equipment.

And that's Dave, in different incarnations. See TLDR link above.

Hi,

Firstly, thanks you for your wide explanation.

When I say "manipulation", I mean Hex editing. Of course, if the directiry entry checksum/hash function has not been made public by Microsoft, it wouldn't be possible to calculate it unless I could recreate the scenario and check if both checksums match, which is a very, very, very hard work.

Is the checksum algorithm public? If not, is there any tool which checks it?

Thanks!!

ReplyQuote
Posted : 05/09/2019 7:50 pm
Passmark
(@passmark)
Active Member

Microsoft as published the exFAT spec with a view to having it included into Linux.

See,
https://www.phoronix.com/scan.php?page=news_item&px=Microsoft-exFAT-Specification
and
https://www.extremetech.com/computing/297565-microsoft-will-publish-exfat-specification-linux-devs

So the information is public.

ReplyQuote
Posted : 06/09/2019 2:01 am
athulin
(@athulin)
Community Legend

Microsoft as published the exFAT spec with a view to having it included into Linux.

You seem to be right apparently it happened just a couple of weeks ago https://docs.microsoft.com/en-us/windows/win32/fileio/exfat-specification

(I have not read it in detail, so I can't say yet if it is complete. But it's the source to use now.)

I hope someone does compare this specification with whatever reversed engineered attempts exists, and identifies the areas of difference that are of direct forensic interest.

ReplyQuote
Posted : 06/09/2019 6:32 am
Passmark
(@passmark)
Active Member

And here is the checksum code.

UInt16 EntrySetChecksum
(
UCHAR * Entries, // points to an in-memory copy of the directory entry set
UCHAR SecondaryCount
)
{
UInt16 NumberOfBytes = ((UInt16)SecondaryCount + 1) * 32;
UInt16 Checksum = 0;
UInt16 Index;

for (Index = 0; Index < NumberOfBytes; Index++)
{
if ((Index == 2) || (Index == 3))
{
continue;
}
Checksum = ((Checksum&1) ? 0x8000 0) + (Checksum>>1) + (UInt16)Entries[Index];
}

return Checksum;
}

ReplyQuote
Posted : 06/09/2019 7:45 am
jaclaz
(@jaclaz)
Community Legend

Hmmm. ?

Let's say someone alters manually *something* in an exFAT entry.
The exact nature of the *something* may (or may not) affect the checksum.

Now for the sake of the reasoning let's say that this something actually affects the checksum.

What would happen if you run CHKDISK on the volume?

1) the checksum is ignored by CHKDISK
2) the checksum is found incorrect and it contains enough info to revert the *something* to what it was before
3) the checksum is found incorrect but since it doesn't contain enough info to correct the *something* the checksum is simply corrected
4) something else

jaclaz

ReplyQuote
Posted : 06/09/2019 9:35 am
Share: