Reverse Engineering ISE with OpenCode

Back in the old days, when I was still a TAC engineer, we had access to pretty much any kind of info we could wish for: PRD, Functional Spec, Software spec, even the IOS source code when needed. Little by little, we have sadly lost that kind of access. Granted, events like our crown jewels being stolen by Huawei (correcting the record) have likely not helped, and the “need to know” security principle has been strictly enforced.

I have been leading an effort trying to get that access back, but it’s worse than fighting windmills!

In the end, I gave up and took a completely different approach. In the age of AI, new possibilities arise!

Reverse Engineering Democratized

#

Reverse engineering might sound pretty scary…it almost sounds like this is reserved for an elite of deeply technical guys. Well, not anymore. :-)

Once you get familiar with agentic AI, this is one of those use cases where AI can really empower you. And at the end of the day, it is very simple!

The Setup

#

I don’t think it was strictly needed, but I decided to rely on RADKit…Cisco’s Remote Access Diagnostics toolkit that provides secure access to customer lab environments. It’s always useful to have access to my lab when not connected to the VPN. I picked one of the flavors of MCP server you can find internally.

ISE is built on top of Linux. My goal was to give the AI agent access to the root prompt for autonomous exploration.

This is something that is prevented by default, but one of the benefits of working for Cisco is that you can still benefit from some level of access. The SWIMS (Software Identity Management System) token server, typically used by TAC, generates temporary one-time tokens that grant root access for troubleshooting.

If you’re not at Cisco, this isn’t completely impossible…you only need to find a PSIRT vulnerability describing a privilege escalation. For example, there is this one that has been released not so long ago. I believe the CVSS for that one is too low. I am not aware of any PoC available, but if you search properly, maybe you’ll find one. Who knows, Mythos might even give you a hand when available! Not that I’m encouraging exploitation, obviously.

All that was left to do was to vibe-code some changes to the RADKit MCP server so that it could handle SWIMS token authentication and negotiate root access automatically.

How It Actually Works

#

Once the setup is complete, the workflow is beautifully simple:

1. Connect to ISE via RADKit - The MCP server establishes a secure tunnel to the lab ISE node
2. SWIMS token exchange - The MCP server automatically requests and applies the root access token
3. AI agent gets root shell - The agent can now execute commands, explore filesystems, read logs, inspect processes
4. Autonomous exploration - The AI follows leads, connects dots, and builds understanding

You just have to ask your agent to go hunt for answers. It doesn’t even have to be one of the latest models. I have got good results with Sonnet 4.5.

Here’s what the conversation looks like:

The agent autonomously explores the system, following leads and connecting dots. No manual grep commands. No hours of SSH sessions. Just natural conversation with an AI that has root access and the ability to reason about what it finds.

Real-World Impact: Bug Root Cause Analysis

#

Here’s a concrete example: CSCwt81251…a bug in ISE 3.5 where cluster replication broke after applying no ipv6 enable globally on the Primary PAN.

A colleague warned me about a customer facing this issue. Since my lab was running ISE 3.5 P3 (the vulnerable version), I decided to investigate.

The Investigation

#

I gave the AI agent access to the ISE root shell via RADKit and described the symptoms: “Replication stopped after disabling IPv6 globally and rebooting the PPAN.”

Within minutes, the agent discovered the problem:

Expected firewall state (2-node deployment):

Chain ISE_FW_JGRP_CHAIN (1 references)
 223K   26M ACCEPT     tcp  --  *  *  node1-ip   0.0.0.0/0  tcp dpt:12001
 318K  117M ACCEPT     tcp  --  *  *  node2-ip   0.0.0.0/0  tcp dpt:12001
    0     0 DROP       tcp  --  *  *  0.0.0.0/0  0.0.0.0/0  tcp dpt:12001

Actual state (broken):

Chain ISE_FW_JGRP_CHAIN (1 references)
  863  42K DROP       tcp  --  *  *  0.0.0.0/0  0.0.0.0/0  tcp dpt:12001

The ACCEPT rules for cluster members were gone…only the DROP rule remained.

The agent then explored system logs, compared firewall behavior across other ISE services, and identified why this specific chain broke while others remained intact. Based on this analysis, I provided Cisco Engineering with detailed reproduction steps and root cause findings.

Result: The bug was resolved in ISE 3.5 P4. Investigation time: ~30 minutes.

Workaround (from the public Release Notes): Apply no ipv6 enable at the interface level rather than globally.

This is the power of AI-assisted troubleshooting: autonomous exploration, pattern recognition across services, and connecting symptoms to root causes without manually tracing through thousands of log lines.

Undocumented Features: Multi-Interface Mystery

#

Another area where this technique has been super useful is understanding features that are very poorly documented.

ISE v1.0 only supported a single network interface. Over time, support for up to 6 interfaces has been added. However, the documentation has barely been updated to explain the changes. How the product behaves when multiple interfaces are configured is still pretty much a mystery for many, both internally and externally.

I built a server in my lab with multiple interfaces, provided access through RADKit, and let the AI agent explore. Everything became crystal clear, findings that would be impossible to discover through documentation alone.

I’m planning to write a series of follow-up posts documenting what we discovered about ISE’s multi-interface behavior. Stay tuned!

The Bigger Picture

#

This approach has fundamentally changed how I approach undocumented behavior. Instead of waiting days to get an answer on internal chat, or spending hours manually tracing through our intranet, I can get answers in minutes.

Is this reverse engineering? Maybe. But when official documentation is incomplete or outdated, sometimes you have to get creative. And in 2026, “creative” means letting AI do the heavy lifting while you focus on asking the right questions.

The best part? This isn’t limited to ISE or Cisco products. Any system you have legitimate access to can be explored this way. The combination of:

• Agentic AI (autonomous reasoning and exploration)
• Root access (via legitimate means like SWIMS tokens)
• MCP servers (bridging AI and infrastructure)

…creates a powerful troubleshooting and learning environment that was simply not possible before.

Notes & Disclaimers

#

For Cisco employees: This post describes techniques using authorized internal Cisco access via SWIMS tokens. The RADKit MCP server modifications are available in my internal GitHub repos.

For external readers: You would need legitimate root access through documented methods or responsible vulnerability disclosure. The PSIRT reference is theoretical…always follow ethical hacking principles and responsible disclosure.

Coming soon: Detailed posts about ISE multi-interface behavior, routing mysteries, and other discoveries made possible by AI-assisted reverse engineering.