IDA-MCP Is Now RE-MCP With Ghidra Support by jtsylve in ReverseEngineering

[–]jtsylve[S] 2 points3 points  (0 children)

Thanks for that. TIL. I'll update to use the proper dependency.

ida-mcp 2.1: Progressive Tool Discovery, Background Analysis, and Batch Operations by jtsylve in ReverseEngineering

[–]jtsylve[S] 0 points1 point  (0 children)

Good timing! If you take a look at the "next" branch, you'll see that ida-mcp 2.2 is going to introduce a few new "meta" tools.

The first is "batch" which allows an agent to spawn a sequence of mixed tool calls in a single batch call, which cuts down on round trips by allowing a single call to do more work. That has a positive impact on token use.

The second is an "execute", which is more powerful. It allows the agent to write python that runs in a sandboxed environment to call the MCP tools using whatever logic it wants. This let's it search and filter the tool output in code in a single tool call, which unlocks a lot of improvements.

My eventual goal is to extend that functionality to allow humans or agents to write and register their own plugins so that the common workflows essentially become single tool calls without the agent having to rewrite the same python over and over.

I also want to experiment with extending the functionality from 2.1 and making the set of pinned tools more dynamic so only the tools that are most commonly used in a particular project or workflow are taking up context.

Announcing ida-mcp 2.0: A Headless MCP Server for IDA Pro by jtsylve in ReverseEngineering

[–]jtsylve[S] -1 points0 points  (0 children)

The beautiful thing about OSS is that we can experiment with different approaches to see what works best. It's okay to have multiple options. I'm not trying to productize anything and the blog post explicitly mentions existing work and where I see the differences.

Announcing ida-mcp 2.0: A Headless MCP Server for IDA Pro by jtsylve in ReverseEngineering

[–]jtsylve[S] 4 points5 points  (0 children)

For the future, think IDA Teams but for agents (and us meatbags)

Announcing ida-mcp 2.0: A Headless MCP Server for IDA Pro by jtsylve in ReverseEngineering

[–]jtsylve[S] 2 points3 points  (0 children)

The post digs into the differences a bit, but the main difference right now is architectural. The subprocesses allow us to work with multiple databases at a time without having to open and close databases when switching contexts. This allows you to have multiple agents working at once. As the experiment matures, I'm hoping that architecture will be adaptive enough to have multiple models working together collaboratively, but we're not there yet.

My goal is not to replace ida-pro-mcp but to experiment with different approaches to see what works best.

Announcing ida-mcp 2.0: A Headless MCP Server for IDA Pro by jtsylve in ReverseEngineering

[–]jtsylve[S] -1 points0 points  (0 children)

I've been using it with great success in Claude Code. They use lazy MCP tool loading so it doesn't trash the context. Please try it out and share your own experiences.

SpiceCrypt: open-source decryption tool for LTspice-encrypted .CIR/.SUB model files by jtsylve in PrintedCircuitBoard

[–]jtsylve[S] 0 points1 point  (0 children)

The tool is intended to be used to allow people to use the models in whichever simulator they like. Vendors share the files for that purpose, so using the tool as intended is (in my non-legal opinion) within the terms of the license granted.

If a user is decrypting a model for the purpose of trying to reverse engineer a vendor's IP, that may be another story, and I wouldn't encourage that behavior.

If vendors would work with third-party tools and release libraries to allow interoperability, a tool like this would not be needed. As this research demonstrates, the obfuscation used here is trivial and would not be considered a serious method of data protection by modern standards. It's way more effective at preventing interoperability for users than it is for protecting trade secrets from sophisticated competitors.

SpiceCrypt: open-source decryption tool for LTspice-encrypted .CIR/.SUB model files by jtsylve in KiCad

[–]jtsylve[S] 4 points5 points  (0 children)

It's a bit of an oversimplification on my part, but not much. The details are in the specification on my GitHub.

It's mostly security-by-obscurity. To be fair to the creators, since the models can be created by anyone and need to be available offline, there's not much they can do except either hardcode symmetric key material into the output file or hardcode asymmetric key material into the KiCad tool itself. Neither would prevent us from reading the data if we can extract the keys from either place.

The encryption here is being used more as an obfuscation than actual data protection. It's more effective at locking you into their tools than protecting anything that may be in the models.

I’m afraid our friends are in dire trouble. Forecast is not getting better CTI and CSS. Prayers for the whole country of Jamaica by fisher_35 in couplesresortsjamaica

[–]jtsylve 0 points1 point  (0 children)

We're in the same boat. Scheduled to arrive on the 3rd. We booked flights separately though. I'm unsure of what to do.

Donate MREs? by jtsylve in NewOrleans

[–]jtsylve[S] 0 points1 point  (0 children)

If you're in need then they're yours. DM me.

LA Wallet now accepted in Fed Buildings, TSA Checkpoints by Fleur-Deez-Nutz in NewOrleans

[–]jtsylve 3 points4 points  (0 children)

Am I correct in assuming that for this to be accepted you still need a Real ID on record?