Caleb Davis
A founding member of SolaSec, Caleb leads deep technical assessments across a range of high-impact industries, including medical devices, automotive, industrial control systems, ATMs and financial terminals, aerospace components, and consumer electronics.
Years ago, implementing a PEDICOM exploit proof-of-concept by hand was the kind of task that quietly ate an entire day, and a week to actually fix it. Not because the core idea was impossibly hard, but because everything around it was slow: rebuilding context from memory, re-reading old notes, stitching together protocol handling, fixing environment drift, and then doing the same platform-specific cleanup twice so it worked on both Windows and Linux.
I recently revisited that same class of work with AI, and the contrast was hard to ignore. Something that used to take me several hours was functional, cleaner, and more portable in minutes.
That is the real story here. “Vibehacking” isn’t just faster typing. It has changed the economics of implementing tailored, technical attacks, especially old research, where the hard part is no longer understanding the concept. The hard part used to be all the glue work.
A Quick Shoutout
Also, quick shoutout to DannyDanhammer and v3ga for continuing their DICOM quests. I had a bit of DICOM FOMO watching all the great work they keep doing in this space. People who stay deep in these weird protocol corners tend to see the future a little earlier than everyone else.
The Old Manual Workflow
When I first did this kind of work manually, the process looked roughly like this:
- Reconstruct the issue from old memory and scattered notes
- Rebuild or emulate enough of the DICOM interaction flow to validate behavior
- Hand-roll the packet or parsing logic needed to exercise the condition
- Fight toolchain drift and missing dependencies
- Fix Windows-specific implementation details
- Rework those same assumptions for Linux
- Repeat until the whole thing was stable enough to trust
None of those steps were individually exotic. The time sink came from context switching and friction. A protocol detail would send you into docs. A compiler complaint would send you into portability fixes. A socket or file handling difference would send you into OS-specific cleanup. Then you would circle back and discover the original issue still needed refinement.
This is why older offensive and research workflows often felt slower than the final output made them look. The “exploit” or proof of concept might be short. The path to get there usually was not.
What Changed With AI
This time, I approached it differently. Instead of rebuilding every layer manually, I used AI as a technical copilot for the boring but necessary parts:
- reconstructing the implementation skeleton from a plain-English description
- filling in protocol-adjacent plumbing
- identifying where Windows and Linux would diverge
- tightening the code until it was actually usable instead of just conceptually correct
The important part is that I still supplied the intent. I knew what behavior I wanted, what parts mattered, and what “correct enough” would look like. AI handled a large amount of the translation effort between idea and implementation.
That translation layer used to be most of the work.
Re-Implementing the PEDICOM Exploit
I am intentionally keeping the bug specifics generalized here. The point of this post is not to publish a drop-in PoC. The point is to show how dramatically the workflow changed.
At a high level, the task was to recreate a legacy DICOM-related issue path I had implemented manually years ago, then get it working cleanly across both Windows and Linux. In the old model, that meant:
- rebuilding the protocol handling logic
- validating field formatting and parser expectations
- restoring the appropriate behavior
- then adapting the code for each target OS
With AI, I could iterate much more directly:
- Describe the original behavior and constraints in natural language.
- Ask for a minimal implementation skeleton.
- Review the output for protocol correctness and unsafe assumptions.
- Refine the platform-specific pieces.
- Test, adjust, and tighten.
That loop is brutally efficient compared to the old way.
Windows Implementation Woes
Windows used to be one of the biggest time drains in this kind of work because the concept was rarely the problem. The surrounding system details were.
The implementation needed to account for the usual Windows-specific friction points:
- compiler and header differences
- path handling and file I/O assumptions
- type differences that only show up once you actually build
- minor API mismatches that break otherwise reasonable code
Before AI-assisted tooling, this meant writing the logic, compiling, fixing one issue at a time, and gradually discovering which assumptions came from Linux habits. AI shortened that cycle significantly because it could preempt many of those mismatches before I hit them manually.
That does not eliminate validation. It changes where the human effort goes. Instead of spending most of the session on syntax, scaffolding, and API recall, I could spend it on whether the implementation matched the protocol behavior I actually cared about.
Linux Implementation Details
Linux was historically easier, but it still had its own tax:
- compiler strictness differences
- library expectations
- data type and byte-handling issues
- portability fixes once the code stopped being a one-off test
Again, none of this is glamorous. It is just the work that accumulates when you are taking a concept and forcing it into a usable artifact.
AI made the Linux side faster for the same reason it helped on Windows: it removed a lot of the dead time between “I know what should happen” and “the code now reflects that accurately enough to test.”
Why This Matters More Than One DICOM Example
This PEDICOM reimplementation is just one example, and honestly it is not even the most important one. It is just a good illustration because I had done it the hard way before.
The broader shift is this: a huge amount of technical work used to be consumed by reconstruction, translation, and cleanup. Vibehacking with modern tools compresses those phases so aggressively that old assumptions about effort are now wrong.
If you built your mental model of offensive or defensive research ten years ago, you may still be pricing tasks in hours that can now be pushed to functional quality in minutes.
That has implications well beyond one protocol:
- legacy research can be resurrected faster
- cross-platform proof of concept work is cheaper
- environment recreation is less painful
- analysts can spend more time validating and less time scaffolding
- defenders have less time to assume “that would take effort”
That last point matters. When implementation friction drops, the barrier between an old idea and a modern working artifact drops with it.
The Real Value Is Not Laziness
I do not think the lesson here is that AI replaces technical skill. If anything, this worked because I already understood the shape of the problem and could spot where the assistant was helpful versus where it needed correction.
The value is leverage.
Good operators can now move faster on the parts of the workflow that used to be pure overhead. That means more experiments, faster validation, better cross-platform coverage, and less wasted time hand-stitching code that an assistant can draft in seconds.
The net effect is obvious once you feel it in practice: work that used to require an uninterrupted block of time can now fit inside a short iteration loop.
Defensive Takeaways
If responsible for DICOM-enabled products, imaging workflows, or legacy medical environments, the message is straightforward:
- assume old protocol issues can be recreated faster than before
- assume cross-platform tooling is cheaper to produce
- assume prior “niche” knowledge can be operationalized with less effort
- prioritize validation of legacy parsing and network handling paths
- revisit whether detection and response timelines still make sense
Artificial intelligence is also likely to accelerate both sides of this dynamic. Techniques that once required deep protocol familiarity or extensive manual experimentation can now be explored and reproduced more quickly, lowering the barrier to developing new offensive tooling. At the same time, the same capabilities can improve defensive analysis, enabling faster protocol inspection, anomaly detection, and validation of legacy implementations. Because the technology is evolving rapidly, organizations should treat AI as a factor that changes the pace of both attack development and defensive capability. Continuous evaluation of how these tools influence threat modeling, testing approaches, and monitoring strategies will be important as the ecosystem matures.
This is one reason legacy protocol security debt matters more now, not less. AI did not invent the weakness. It changed the speed at which someone can turn half-forgotten knowledge into working tradecraft.
Conclusion
Re-implementing this PEDICOM exploit with AI made one thing very clear: the biggest gain was not magical code generation. It was the collapse of the slow, annoying, platform-specific glue work that used to dominate the timeline.
Work that once required several hours of manual effort is now functional, and often better, in minutes. And this is likely just the beginning.
The workflow shift is real, and it has defensive implications. What people are calling “vibe hacking,” iterative exploration with AI assistance and rapid tooling, changes the pace at which old protocol issues can be rediscovered. An attacker no longer needs deep DICOM expertise on day one. Partial understanding combined with quick experimentation is often enough to start uncovering edge cases.
Traditional protocol assessments tend to focus on known vulnerability classes or previously disclosed issues. Vibe-driven exploration behaves differently. It probes the protocol surface more freely: malformed messages, mutated metadata fields, unusual transfer syntaxes, and repeated attempts to break parser assumptions. Weaknesses in legacy parsing logic or error handling can surface much faster under that style of exploration.
The defensive takeaway is simple: testing needs to go deeper. Protocol implementations should be stress-tested beyond the checklist of known issues, with careful validation of parsing paths and unexpected inputs.
If a DICOM stack has been carrying the same baggage for seven years, the environment around it has changed. Exploration is faster, tooling is easier to build, and experimentation is cheaper. That is a good reason to revisit the implementation now rather than later.