This PR adds Linux support to artemis. So far the following artifacts have been added:

• filelisting
• processes
• chromium and firefox
• cron
• shellhistory

The GitHub actions files have been updated to include Linux runners.
In addition, changie files have been added to track major changes.

Completes #1

What new feature do you think would be cool to add to artemis? Right now artemis only supports Windows and macOS. Linux is a popular OS/kernel and adding support for Linux would allow users and analysts to use artemis for reviewing forensic artifacts on Linux

Describe the solution you'd like Include support for Linux

Minimum Requirements

• [x] Compile under Linux
• [x] Support parsing TOML collection format
• [x] Port filelisting artifact
• [x] Port systeminfo artifact
• [x] Port processes artifact

What new feature do you think would be cool to add to artemis? Currently artemis uses the deno_runtime crate (https://crates.io/crates/deno_runtime) to embed Deno in artemis. It works great, but it brings in the whole runtime. Even things that we probably wont ever use like deno_http, deno_kv, deno_ffi, etc.

I think we can remove deno_runtime and just import the modules we want.

Describe the solution you'd like Remove deno_runtime and just import the modules we want.

Additional context The biggest disadvantage of removing deno_runtime is that it will probably prevent usage of third-party Deno modules. Since those modules may expect a function from a module we have removed. Ex: A web framework module probably expects deno_http to be available.

In addition, removing modules will make it a little more difficult for new users to start scripting. Right now since we import the deno_runtime most/all of the Deno documentation can be referenced when scripting.

But if we remove modules, we have to make sure we state what parts of the Deno documentation should be read.

The advantage is: fewer dependencies and hopefully smaller binary size. For context, Deno currently makes the artemis binary size ~10 times bigger

Modules imported by deno_runtime

pub use deno_broadcast_channel;
pub use deno_cache;
pub use deno_console;
pub use deno_core;
pub use deno_crypto;
pub use deno_fetch;
pub use deno_ffi;
pub use deno_fs;
pub use deno_http;
pub use deno_io;
pub use deno_kv;
pub use deno_napi;
pub use deno_net;
pub use deno_node;
pub use deno_tls;
pub use deno_url;
pub use deno_web;
pub use deno_webidl;
pub use deno_websocket;
pub use deno_webstorage;

What new feature do you think would be cool to add to artemis? Cross compiling using Rust is difficult. Trying to accomplish it on GitHub actions is even more difficult. Currently aarch64-apple-darwin (ARM) builds on GitHub actions are failing. I am not 100% sure why, but it might be related to cross compiling Deno.

Artemis compiles natively on macOS ARM fine.

Describe the solution you'd like Figure out how to get cross compiling working on GitHub actions

Additional context This may be related to https://crates.io/crates/deno_ffi based on the runner error.
See #22

What new feature do you think would be cool to add to artemis? It would be cool if artemis could support parsing the Windows WMI database files. WMI can be used as a form of persistence on Windows.

Describe the solution you'd like Support parsing WMI database files

Additional context The format looks pretty complex. Quick overview: https://netsecninja.github.io/dfir-notes/wmi-forensics/ libyal: https://github.com/libyal/dtformats/blob/main/documentation/WMI%20repository%20file%20format.asciidoc

What new feature do you think would be cool to add to artemis? One of the current limitations of the forensics parsers in artemis is that they are compiled into the actual binary. So anytime we need to update one, we have to recompile and update the whole binary. Which kind of stinks 😕.

The Deno runtime currently can help us with this a little bit with plaintext artifacts (technically Deno can also read binary files, but parsing them is challenging). The benefit however is instead of coding a parser in Rust we can code a parser in TypeScript using the Deno platform. This allows us to make dynamic parsers (TypeScript/JavaScript) that we can update much easier and do not need to recompile artemis.

However, complex plaintext artifacts and binary artifacts might benefit from exposing parts of nom to Deno.

Describe the solution you'd like Expose parts of nom to the Deno runtime so users can create parsers in TypeScript

Additional context Nom is a huge project with lots of functions, we are not going to expose them all immediately. A prerequisite for this feature will likely be a paged/stream binary reader. See #5

This will help ensure that we do not read too much binary data from the TypeScript caller. Also V8 seems to have a raw byte size limit, if too many bytes are read it will crash. (Though it seems to handle really large strings fine, ex: if you base64 encoding the large raw bytes, V8 is ok)

A good starting point could be:

• [ ] Expose a paged/stream binary reader to Deno (requires #5 )
• [ ] Expose 3 nom functions: take, take_while, take_until
• [ ] Expose nom_helper functions

What new feature do you think would be cool to add to artemis? Currently artemis just labels files that are compressed with the builtin NTFS compression types. It would be cool if it could decompress the data.
This is primarily useful when hashing files and reporting file sizes.

Describe the solution you'd like Support decompressing NTFS compressed files. Might be dependent/solvable by #6

Additional context NTFS compressed files are kind of finicky to deal with. For example, if explorer.exe is compressed with the builtin NTFS compression and we want to answer the question "How big is the file?". Do we want the compressed size or decompressed size? But if someone copies the file to a different location/drive, Windows decompresses the file and now the size is different.

NTFS: https://en.wikipedia.org/wiki/NTFS (File Compression) libyal: https://github.com/libyal/libfsntfs/blob/main/documentation/New%20Technologies%20File%20System%20(NTFS).asciidoc#9-compression

What new feature do you think would be cool to add to artemis? Currently artemis supports decompressing Windows Overlay Filter (WOF) compressed data smaler than 2GBs.
WOF actually supports four (4) compression types.
Artemis supports all of them except the lzx compression type.

Describe the solution you'd like Support the lzx compression on WOF data. Might be dependent/solved by #6

Additional context Quick review of WOF: https://github.com/wbenny/woftool NTFS with WOF: https://en.wikipedia.org/wiki/NTFS (System compression) Microsoft blog: https://devblogs.microsoft.com/oldnewthing/20190618-00/?p=102597