2024 update

[Chelsea486MHz]

Major update

I noticed the project was being left abandoned with some features missing. I believe Phorcys to be an extremely powerful tool for forensics and took it upon myself to maintain it so that it could be used on a honeypot I'm setting up in the wild.

This pull request is mainly here to notify that work has been done, but I'm stuck and am no longer making progress due to issues implementing tests in the CI pipeline.

Anyways, here's a short list of the things I changed in my branch:

---

Continuous integration pipeline

• Added a CI pipeline (./github/workflows) running on public Github Ubuntu runners
• Added decoding tests for some formats (NOTE: currently stuck on this part... I need help)
• Added static security analysis of the code with Bandit (ignoring rules: B110, B404, B602
• Added linting with Flake8 (ignoring rules: E501, W504, E731, F403, F405

Python

• Bumped version from Python 3.3 to Python 3.12
• Switched to a newer package build system (setup.py to setup.cfg)
• Reorganized documentation/Mardown files to correct some formatting errors

Runtime

• Started work on a Alpine Docker integration do run deep decoding in a hardened, memory-limited environment to mitigate *zip-based logic bomb attacks
• Also just because I think Phorcys would fit perfectly with a network intrusion detection tool that would feed it suspicious packets for analysis and further alerting through Prometheus or similar systems. I have that use case in mind.

---

This PR is not done, I'll have to fix the tests first. Then work remains to be done regarding Docker, IMO.

[U039b]

Hi!,
Thank you very much! This project would also need a good refactoring because the implementation of many (all?) decoders is pretty 💩.

Some ideas:

• implement an heuristic to escape dead ends/local minima (e.g. backtracking)
• add the support for PCAP(NG), ideally with TLS decryption when the client randoms are provided
• improve the overall performance
• add an option to flatten or limit the size of the output graph (only the leaves contain the decoded data)

Also, I propose to:

• give you the maintainer role
• move Phorcys to PTS organization once this PR is merged

What do you think about this?

[Chelsea486MHz]

I definitely agree, it would benefit from a partial rewrite.

Current decoding techniques did require me to silence Bandit (I don't feel comfortable executing subprocess calls with the extremely non-deterministic behavior arising from compression) so there's definitely some work to be done here. A modular interface with a "plug-and-play" approach (as in, automatically loading .py files from the decoders folder during startup) would be an elegant way to unify decoding, all while lowering the barrier to contributing by allowing the implementation and sharing of extra algorithms without the need to explore the entire source code.

Features like escaping local minima in decoding space are exactly what I had in mind, since malicious payloads could exploit this behaviour to sneak payloads past Phorcys detection (one example I have in mind is Log4shell payloads prefixing the JNDI lookup template by a dummy JSON payload to trick Phorcys into flagging reporting it as OK). This is in line with the limited memory resulting from containerization.

As for implementing PCAP decoding, I had in mind the implementation of the following encoding formats:

• PCAP dumps
• Serialized Java classes
• Base85/32/16 (PDF-based attacks come to mind)

Now for TLS, I will postpone work on that until the rest is done as secret management might become an issue in the case of mobile forensics.

When it comes to performance, Phorcys would obviously tremendously benefit from multi-threading but due to the undeterministic nature of some decompression algorithms it might just pave the road for thread-starvation denial of service and temporary network monitoring outages.

Some tricks come to mind as I'm typing this, like estimating average entropy gained from decoding specific children based on payload structure and prioritizing higher-rewarding children. But those entropy calculations would rely on logarithmic computations that might themselves slow things down on low-power ARM chips or limited virtualized environments. Speed optimization would be the second least prioritized feature, due to the amount of performance testing that would arise.

The tree squashing way of reducing output is actually pretty easy to implement, so I don't have any issues with that. Easier parsing would lower the entry barrier to implementing Phorcys in existing forensics pipelines.

Overall, Phorcys is the kind of tool that ends up in NGO hands, and all the hardening that would emerge from the implementation of those features would cement it as a reliable field forensics tool in line with the PTS.

---

I'm OK with getting the maintainer role, I don't currently have any contract with a client so I can dedicate my free time to open source software. As I'm currently setting up my own PiRogue, I look forward to seeing it integrated in the device!

I'll update the PR when I get the tests + most of the features going.