Add Some Text Fields / Checkboxes

[BrunoFischerGermany]

• Add Textfield "Evidence Number"
• Enlarge the text field "Notice"
• • in there the MacOS Version of Target Device
• Add Copy Path from "Temp Image Location" to "DMG Destination"
• • if "DMG Destination" is empty
• Add Check Box (standard false) "Collect Unified Logs"
• • if Checked, Create an logarchive from Target Device to "DMG Destination"
• Add Checkbox (Standard false) "Collect System Profiler"
• • if Checked, Create an txt-File with the collected data from commandline "system_profiler"

[Lazza]

Hello, thank you for raising these points!

However the PR (as it stands currently) has a few issues, that makes me reluctant to accept it:

• You are sending one PR that includes several different and unrelated modifications, so it's an all or nothing situation.
• For several of those modifications no rationale is provided, e.g.:
  • Why is the macOS version set as a parameter for the acquisition? That is a characteristic of the Mac itself, which can be read from the system files using your favorite analysis suite.
  • Why are unified logs and system profiler added as extra checkboxes instead of a separate acquisition method? They are not currently hashed.
  • Is an extra "evidence number" field necessary? I know some tools like FTK Imager include even 5 different text fields, that nobody uses. I suppose people using an evidence number will add it to the directory name itself (much more readable), or inside the notes if needed.
  • Do we really want to allow the notes to be multiline? Users will feel the urge to write a lot of text in it.
  • Why is the Exit button added? It seems to me that it duplicates the red "Close" button available on macOS.
• There is a typo on line 232: PARAMS.unifieΩdlog

IMHO three is a good number for free-form text fields, and since when I started the project, Fuji is supposed to be an imaging tool. It is not trying to reimplement a forensic analysis tool (like Autopsy) or a malware / intrusion / triage script (like mac_apt).

It is my opinion that the UI should not be cluttered with extra options that 99% of people will never use, otherwise it risks to become the KDE of Digital Forensics. 😇 This is why I originally made the GUI the way it is.

---

Would you consider opening a separate PR for features? Even better if an issue is opened to discuss why we would want to include the proposed features and the PR mentions the issue.

So far I would be inclined to consider only a few things.

First: the automatic filling of the destination if tmp is changed is very nice. 💯 I think it won't be widely used because most people will keep the "Fuji" name for the volume, nevertheless that is a useful little enhancement.

Second: unified logs and system profiler might become a dedicated acquisition method. Although to be honest I would much prefer to perform a sysdiagnose, because we can effortlessly include unified logs, system profiler and a dozen other things.

I still think that this is a bit out of scope, as this is not imaging but it's triage. Nevertheless it can be integrated easily with the rest of the framework (including putting everything in a read-only DMG and computing hashes) and it does not clutter the interface. Thus this is an easily approved feature for me ✅, in the form of a sysdiagnose method (alongside ASR or Rsync).

I already drafted the code for the method, but it's not polished yet. It will also include conversion of the logarchive to txt, in this way analysts not using Macs will be able to read the log files.

Third: you might consider sending a PR that modifies the code currently reading the hardware type from this:

system_profiler SPHardwareDataType

To this:

system_profiler SPSoftwareDataType SPHardwareDataType

That will end up in the report while not adding any extra text to the interface. It seems a win-win situation.

---

Again thank you for taking the time to try the tool and open a discussion about modifications / new features.

[BrunoFischerGermany]

Hello Andrea,

Thank you very much for the detailed answer. I would like to respond to your questions.

Why is the macOS version set as a parameter for the acquisition? That is a characteristic of the Mac itself, which can be read from the system files using your favorite analysis suite.

You are right.

Why are unified logs and system profiler added as extra checkboxes instead of a separate acquisition method? They are not currently hashed.

Yes, i Think that's a better way.

Is an extra "evidence number" field necessary? I know some tools like FTK Imager include even 5 different text fields, that nobody uses. I suppose people using an evidence number will add it to the directory name itself (much more readable), or inside the notes if needed.

I agree with you, but if you have several evidence objects (Macs) in the same place in a procedure, it would be good to have the evidence number on them, I or my colleagues enter such information. of course, the backup path also reflects this number. I think it would be a benefit to have this text field.

Do we really want to allow the notes to be multiline? Users will feel the urge to write a lot of text in it.

Well, it was about the better readability, if you enter text here. whether the user feels forced here, I do not know.

Why is the Exit button added? It seems to me that it duplicates the red "Close" button available on macOS.

Yes, I agree with you, the little red “X” is there, but when I introduced it to my colleagues who are not so MacOS friends, the question of the close button came up. Maybe it would be okay for the UI.

Would you consider opening a separate PR for features? Even better if an issue is opened to discuss why we would want to include the proposed features and the PR mentions the issue.

So I would open issues for discussion and then link the Plull request there?

[Lazza]

Thank you for the feedback!

Feel free to directly open a PR for the first point I mentioned above (updating destination when tmp is set) and the third one (software information in the txt file by modifying the system_profiler command).

Regarding the sysdiagnose, let's see if I can find the time to complete the module I have already started.

For the other points I'd rather discuss those in separate issues (one for each feature). I am honestly not very convinced, especially for the duplication of the close button.