fox-it
Not detecting windows when applying tar loader
I've encountered an issue where windows OS plugin wouldn't load when loading from tar. Following my investigation I have found the issue is resulting of confusion between the loader and windows os plugin:
https://github.com/fox-it/dissect.target/blob/aab863c3cdc7de9878d91721edbc59b10d4c564f/dissect/target/plugins/os/windows/_os.py#L39-L42
The windows here is lower case, contrasting the real folder name, which is Windows.
In tar loader, when the tar is not from acquire the filesystem will load with case_sensitive=True flag:
https://github.com/fox-it/dissect.target/blob/aab863c3cdc7de9878d91721edbc59b10d4c564f/dissect/target/loaders/tar.py#L53-L59 Therefore, there is a contradiction between those.
I would love to open a PR to fix that, but I'm not sure if any change will break other loaders that rely on that condition.
Hello @AlonHaviv1 thanks for bringing this issue to us.
I have looked into it, and think that changing the default to case_sensitive=False inside the tar loader wouldn't be the best solution as it would also impact those tar files that need to be case sensitive. E.g. information that was on a unix like filesystem.
The reason we use lower case for most windows systems, is because their filesystems are usually case insensitive.
I couldn't quickly identify another workaround within the dissect tooling, so this will be taken up when time allows.
You could however untar it, move everything under a fs/sysvol directory and tar it again. If you do that, the target-* tooling should pick it up.
If you have another suggestion or question please feel free to share.
Could you give an example where changing the detection of windows to "Windows" would break loaders?
Could you give an example where changing the detection of windows to "Windows" would break loaders?
I interpreted your change as a change in the case sensitive nature of the loader. However, it seems you mean a change in the os plugin, right?
I am afraid the change in the os plugin wouldn't end at only changing the windows to Windows. In your case, every path inside your tar file would be interpreted in a case sensitive manner. So none of the plugins will function as intended for windows systems as it expects case insensitive paths for windows filesystems.
as an example, the TasksPlugin wouldn't work as all of its paths are in lowercase, so while trying to find, for example sysvol/windows/system32, it wouldn't be able to find that path inside your tar due to the case_sensitive=True that gets set inside the TarLoader.
@AlonHaviv1 maybe https://github.com/fox-it/dissect.target/pull/1076 will have fixed this, are you able to confirm with your data?
Hey @Schamper , I tested it against my data, there is an edge case where there is a symlink as the same name as a directory, so the symlink overwrites the folder in the virtual filesystem. That happens for example in windows server 2022, where there is "Default user" symlink that points into the "Default user" Folder and overwrites it. After that. when a file is being mapped into the VFS and is under the "Default user" folder, the file can't be mapped and crashes the loader process.
Is it possible for you to provide a test tar file that we can use to reproduce this behavior? Thanks!