I think Rudy Ooms is awesome. I don’t like calling someone “one of the smartest people I’ve ever met” just because they picked up a skill that almost nobody else in the field has, but in Rudy’s case I’ll make the exception, because he sure seems like one of the smartest people I’ve ever met. I read just about every blog the guy writes. I’ll admit I’ve got a short attention span and he gets into the 1000-level technical weeds, which makes some of them longer than I’d prefer, but I still try to read every one start to finish. It amazes me how he can get into individual .dll files, crack them open, and actually read the code inside. He’s constantly surfacing unknown and unannounced Intune features that he stumbles onto along the way. If you don’t follow him, you should. And considering he works for our competition, that’s not an easy thing for me to admit.
I’ve asked Rudy a few times, “how do you do what you do?” I don’t want to think he ignored me, but he never did tell me. 😊
And I really wanted to know. Not so I could go write blogs like his. Not to steal his thunder in any way. I just like to learn, and like I said, he has a skill I’ve never seen anyone else pull off and he’s very good at it. So I did what anyone who wants to know something in 2026 would do: I asked Claude. I handed it links to a bunch of Rudy’s blogs and said, “Go read these and tell me how this guy does what he does.” Claude came back talking about Procmon, Ghidra, DLL libraries, debug symbols, and all the rest. The whole process sounded insanely complex, but that just made me want to learn more, so I kept digging.
The more time I spent on it, the more I realized how cool it would be to do this myself. I’ve literally asked, okay maybe begged, Rudy to work his magic on problems I’ve run into before. But I’m really strapped for time right now, so rather than spending the next few years trying to get a fraction as good at this as Rudy is, I did the obvious 2026 thing again. I said, “Claude, can you build me a skill that automates all of this and spits out the findings as a blog-ready markdown file, with screenshot placeholders and instructions for grabbing each screenshot myself?” After a week or two of trial and error, the skill actually solved a problem I didn’t even realize was Intune related. While I was goofing around testing our new App Store for Intune, I had deployed Cisco Secure Endpoint to one of my test computers and completely forgotten about it. All I knew was that nothing on that machine was working. And I mean nothing, I couldn’t even open Edge. The thing was really busted. The skill figured out that Secure Endpoint was injecting itself into new processes and killing them before they could start, which was blocking half the machine from working. That’s when I decided it was ready to be made free to the public.
Meet the Reverse Engineer Intune skill
I wanted to honor the man the skill was built to mimic. Notice I said mimic, not replicate or replace, because there’s no way it will ever be as good as the man himself. The best tribute I could come up with was the way you start it: you tell Claude to “Go Rudy this:” followed by whatever Intune problem you want investigated.
What it actually does
The best part is you don’t have to know any of the deep technical stuff to use it. You describe the problem in plain English, like “go rudy this last check-in” or “go rudy this app that says failed but is actually installed,” and the skill works out where to look and how deep to go.
It starts by quietly collecting everything a managed device leaves behind: the Intune Management Extension logs, the registry, the MDM certificate, the scheduled tasks, the services, and the management event logs. Then it builds one timeline out of all of it and goes hunting for the gap between what Intune reports and what the device is actually doing. That gap is the whole Rudy move, and it’s usually where the real answer is hiding.
If the logs alone can’t prove what happened, it escalates on its own, the same way a person would:
- It can watch the operation happen live with Procmon instead of guessing from logs after the fact.
- It can crack open the IME’s own .NET code and read the actual logic, the hardcoded timers and handlers that the logs only hint at.
- When it has to, it goes all the way down to the native Windows binaries (the OMA-DM client, the enrollment engine, the CSP handlers) and decompiles them with Ghidra, pulling Microsoft’s own public debug symbols so the functions come back with their real names instead of gibberish.
Most problems never need that fourth level. But it’s there for the ones that do.
When it’s finished, it doesn’t just dump a pile of findings on you. It writes the whole investigation up as a blog-ready markdown post: the setup, the timeline, the mechanism it found, the contradiction, and how to reproduce it, with placeholders marking exactly where each screenshot goes and instructions for grabbing them. (Yes, that means it can pretty much write the blog post for you. No, I’m not worried about it replacing me. Probably.)
If you want to see what that output actually looks like, there are two real examples in the repo. One takes apart why a “Last Check-in” time in the portal can read completely current while the device is quietly failing every policy underneath it. The other is the Cisco Secure Endpoint mess I mentioned earlier, where Intune swore an app had failed because a file was missing when the truth was something else entirely.
So that’s the skill. It’s free, and it lives on GitHub:
Please use it wisely, and if you happen to post any blogs it helps you write, all I ask is that you credit the skill for the assist. Enjoy!