Add FortiOS rootfs.gz decrypt functionality

[JSCU-CNI]

This PR adds rudimentary support for decrypting rootfs.gz files on FortiOS 7.4.1 and up.

[codecov]

Codecov Report

Attention: 89 lines in your changes are missing coverage. Please review.

Comparison is base (72774a2) 73.64% compared to head (9c64916) 73.45%.

Files	Patch %	Lines
...issect/target/plugins/os/unix/linux/fortios/_os.py	11.90%	74 Missing ⚠️
...ect/target/plugins/os/unix/linux/fortios/locale.py	23.07%	10 Missing ⚠️
...ct/target/plugins/os/unix/linux/fortios/generic.py	0.00%	5 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #510      +/-   ##
==========================================
- Coverage   73.64%   73.45%   -0.20%     
==========================================
  Files         275      275              
  Lines       22872    22943      +71     
==========================================
+ Hits        16845    16853       +8     
- Misses       6027     6090      +63     

Flag	Coverage Δ
unittests	73.45% <12.74%> (-0.20%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[Schamper]

I've fixed the decryption to work with the existing pycryptodome dependency. It seems to all work alright on my end, but if you could give it a quick test-spin, this should be good to go!

Would be cool if we could dynamically extract the encryption key. I was working on some Ivanti appliances with the loop-AES encryption, which also have hardcoded keys in the kernel. I haven't looked at the FortiOS kernel yet, but the Ivanti's have a symbol pointing to the key, making recovery of it fairly trivial. Perhaps it's similar for FortiOS, or a pattern match could suffice.

Way too much work for relatively little gain, though. But perhaps fun to explore some day 😄

[pyrco]

Would it be an idea to split this PR in 3 not-to-be-squashed commits, 1 for the robustness improvements in locale.py, 1 for the additional file locations in generic.py and 1 with the actual decrypt functionality in _os.py?

[Schamper]

Would it be an idea to split this PR in 3 not-to-be-squashed commits, 1 for the robustness improvements in locale.py, 1 for the additional file locations in generic.py and 1 with the actual decrypt functionality in _os.py?

Split it over 4 to also separate the FortiManager out.