Profiles

[RicYaben]

Alongside the regular functionality, we could have a --profile flag that configures the honeypot to resemble a PACS server or DICOM workstation/viewer. Since there are many of those, I will keep this issue open to keep implementing each one as it goes.

[shagunpandeydev26-alt]

Hi @RicYaben, I've been looking into the --profile flag requirement and noticed the previous PR was closed. I’d love to take a fresh shot at this.

My idea is to move the profile details of OsiriX into a separate profiles.json file. This way, we don't have to hardcode everything in the main script, and adding a new medical device profile later would be as simple as adding a new entry in the JSON.

I'm planning to focus on making sure the ImplementationClassUID and AE Title are mapped correctly for a more authentic emulation. Let me know if this modular approach works for you, and I can start working on a fresh PR.

[RicYaben]

@shagunpandeydev26-alt sorry but what you are proposing is rather trivial at this stage, and would not add much more value than copy pasting into the terminal the desired values.

[shagunpandeydev26-alt]

@shagunpandeydev26-alt sorry but what you are proposing is rather trivial at this stage, and would not add much more value than copy pasting into the terminal the desired values.

Thank you for the feedback. I understand the concern. My goal with this initial structure was to establish a base for a Dynamic Personality Engine.

Beyond just loading values, I am planning to implement:

1.Automated Profile Discovery: A way for the honeypot to rotate identities automatically to avoid fingerprinting.

2.Advanced Emulation: Matching specific DICOM responses and not just AE Titles based on the selected profile.

3.Remote Configuration: Allowing the profiles to be updated via an API or environment variables without restarting the server.

I'd like to hear your thoughts on which of these directions would add the most value to DICOMHawk's modernization. I will be really grateful, if i will get a chance to make contribution.

[RicYaben]

@shagunpandeydev26-alt Im sorry but I dont think what you are proposing would help the honeypot except the emulation, which is a given (??). If you have any doubt about it I would recommend reading the literature on deception systems 👍

[shagunpandeydev26-alt]

@shagunpandeydev26-alt Im sorry but I dont think what you are proposing would help the honeypot except the emulation, which is a given (??). If you have any doubt about it I would recommend reading the literature on deception systems 👍

Thank you so much sir for pointing me towards the literature on deception systems. Now I can finally see your point that simply changing the AE Title is 'identity masking,' not true 'behavioral emulation.'

To add real value to DICOMHawk, I am pivoting the proposal toward High-Fidelity Personality Emulation. My goal is to implement a layer that handles which will include:

1. Protocol-Level Fingerprinting: Beyond the Application Entity, I want to emulate how specific vendors like OsiriX respond to unsupported Abstract Syntaxes or malformed PDUs. Different implementations have unique 'error signatures' that sophisticated scanners use to fingerprint honeypots.

2. Synthetic Latency & Jitter: Implementing vendor-specific response timings. A legacy DICOM workstation and a modern PACS server don't respond with the same speed; mimicking this 'timing signature' is crucial for deception.

3. Adaptive Negotiation: Adjusting the Maximum PDU Length and Asynchronous Operations support during the Association Request phase to match the profile of the emulated device.

I believe this moves the project from a 'trivial' configuration change to a robust 'Deception Engine' that can actually frustrate advanced reconnaissance. I'd appreciate your thoughts on this more granular approach.

[RicYaben]

@shagunpandeydev26-alt stand down please. This is not for you.