Different consideration of letter case for windows output folders by the acquire plugins

[Bitbee0]

When using acquire on a Linux distbution (in my case Ubuntu 22.04.3 LTS) to collect data from a Windows image (in my case in EWF format), different plugins seem to use different letter case for the output folders. Some plugins working case-sensitiv and some case-insensitiv. Unfortunately, this leads, for example, to two folders with the name Windows being created in the output directory on my Linux system, one in upper and lower case and one only in lower case. This probably depends on the plugin to which folder the output is written. This also not only affects folders under fs/sysvol but also subfolders. For example, two System32 folders are also created - one system32 and one system32 Here is an example of my output (i worked with the full profile):

/fs/sysvol $ tree -L 3 -d .
.
├── $Extend
├── $Recycle.bin
├── $Recycle.Bin
├── ProgramData
│   └── Microsoft
│       ├── Network
│       ├── Search
│       ├── Windows
│       └── Windows Defender
├── Users
├── windows
│   ├── appcompat
│   │   ├── appraiser
│   │   ├── Programs
│   │   └── UA
│   ├── inf
│   ├── prefetch
│   ├── system32
│   │   ├── config
│   │   ├── drivers
│   │   ├── sru
│   │   ├── tasks
│   │   ├── wbem
│   │   └── winevt
│   └── tasks
└── Windows
    ├── Logs
    │   ├── CBS
    │   └── WindowsUpdate
    ├── ServiceProfiles
    │   ├── LocalService
    │   └── NetworkService
    ├── system32
    │   └── config
    ├── System32
    │   ├── WDI
    │   └── winevt
    └── Temp

It would be nice if the plugins all used the same upper and lower case for the respective output folders. Preferably the Windows standard, i.e. what was found on the Windows image.

[Schamper]

Thanks for reporting this. This is indeed something that could be improved. Note that this will not cause any problems when investigating with dissect.target (target-query etc) since it will recognize and normalize everything to a case-insensitive virtual filesystem. But I can imagine this being very annoying when trying to use other tools on the output of acquire!

We've been touching on the output path normalization lately, so maybe we can work this in there, but I'm unsure on how much effort this will actually be.