Technical Design Document: LLM Integration via API

1. Context and Challenges of LLM Decompilation

Decompiling binary code into high-level, human-readable source code (like C++) using Large Language Models (LLMs) is a highly resource-intensive task. It requires:

• Massive Context Windows: Analyzing control flow graphs and hundreds of lines of assembly instructions simultaneously.
• High Computational Power: Generating accurate and coherent code outputs quickly.
• Rapid Iteration: Real-time collaboration features in DaiC require the decompilation engine to be fast and responsive.

To address these challenges, the architectural decision was made to integrate the LLM via a Cloud API (such as OpenAI, Anthropic, or an API-compatible endpoint) rather than embedding a strictly local model within the application.

2. Technical Documentation and Architecture

The integration of the LLM via an API relies on a clear separation of concerns between the DaiC C++ client and the language model inference engine.

2.1. Abstraction Layer

Instead of tightly coupling the software to a specific model’s weights or local inference engine (like llama.cpp), DaiC uses an HTTP/REST client implemented in C++. We have designed an abstraction layer (an ILLMProvider interface) that handles payload formatting and network requests asynchronously.

2.2. Asynchronous Processing

When a user requests the decompilation of a function, the C++ engine sends an asynchronous network request to the API. Thanks to this non-blocking architecture, the main UI thread remains completely responsive. Real-time collaboration events (via WebSockets) can still be processed while waiting for the LLM’s response.

3. Justification of Longevity and Sustainability

Relying on an API for the core intelligence of the application ensures exceptional longevity for DaiC:

• Model Agnosticism: The AI landscape evolves at an unprecedented pace. By using an API, DaiC is not tied to a model that will be obsolete in six months. The backend endpoint can be switched (e.g., from GPT-4 to Claude 3, or to a customized enterprise model) simply by updating the API key and URL in the configuration file, without needing to recompile or update the DaiC software itself.
• Compatibility with Local API Servers: For users working on highly sensitive, air-gapped reverse engineering tasks, our standard API integration is compatible with local inference servers (like vLLM or LM Studio) that expose OpenAI-compatible endpoints. This offers the best of both worlds: cloud power by default, and local execution when confidentiality requires it.
• Offloading Hardware Requirements: The software will not become obsolete as AI models grow in size. The heavy lifting is offloaded to the API provider, ensuring DaiC remains lightweight and functional.

4. Accessibility Considerations

While the choice of an API seems purely backend-focused, it has a direct and significant impact on accessibility:

4.1. Maintaining UI Responsiveness for Assistive Tools

Local AI inference can consume 100% of a computer’s CPU and RAM. When a system is under such heavy load, assistive technologies like Screen Readers (which rely on the OS’s accessibility APIs) or voice-command software often lag or crash. By offloading the computation to an external API, DaiC ensures that the local machine’s resources are preserved, guaranteeing a smooth and uninterrupted experience for users relying on accessibility tools.

4.2. Hardware Inclusivity

By not requiring a high-end GPU (Graphics Processing Unit) to run the decompilation models, DaiC becomes accessible to a much wider audience, including students or professionals using standard laptops. This reduces the socio-economic barrier to entry for using advanced reverse-engineering tools.

4.3. Future-proofing for Multimodal Accessibility

Using a top-tier API provider opens the door to future accessibility features with minimal development effort. For example, integrating multimodal API endpoints could soon allow developers with severe motor impairments to control the reverse-engineering process or query the decompiled code using native voice-to-text API integrations.