Building on my earlier posts about CTIgor, I’ve implemented a new MCP server and framework that can interact with the OpenCTI Threat Intelligence Platform. Capabilities exposed through the MCP server help to allow the agent to yield more insights about CTI findings through retrieval augmented generation (RAG), using an OpenCTI database as a RAG source. There are a lot of considerations that need to be addressed in the design: Simply exposing raw server JSON responses to the agent doesn’t suffice for many reasons. I will discuss these issues and explain my mitigations along the way.

The Model Context Protocol is an API standard that has been making the rounds in the GenAI community recently. It is an open standard that is being promoted and maintained by Anthropic for the benefit of the braoder community. In a nutshell, it can be used to expose an API for GenAI use as well as provide AI-discoverable inventory of tools utilizing a specification similar to the Functions/Tools I demonstrated in my earlier two blog posts (CTIgor: An Agentic CTI Assistant, Porting CTIgor to AutoGen). In this entry, I will demonstrate porting those tools over to a new, separate, MCP server, which can make them available to more agents without having them hard-coded.

In my earlier blog “CTIgor: An Agentic CTI Assistant“, I demonstrated building a basic agent for consuming CTI reporting and generating summaries of it. The Semantic Kernel framework was used in that case. However, Microsoft R&D also maintains another framework named AutoGen which is centered around rapid development of agents and multi-agent systems. This framework also supports a broad set of tool extensions. In this post, I will discuss my experience porting the earlier project over to AutoGen, and compare and contrast the experience.

Continuing down the road of my ongoing experimentation with Generative AI, one of these experiments manifested into a Cyber Threat Intelligence assistant to help facilitate the threat post/report consumption process. This post will follow the steps of gradually building this out, as an educational exercise.

A couple weeks ago, news about a new large-language model (LLM), named DeepSeek-R1, came out. The publisher, DeepSeek, is a Chinese company that was founded in 2023 and focuses on AI research and development. In response to this, I decided to undertake a small project to try to implement LLM and RAG in a simple context-aware code-completion utility.

On December 22 2023, the Ghidra project released version 11 of the Ghidra Software Reverse Engineering platform. After reading through the Release Notes, a “major new feature“ caught my eye: BSim, which promises to offer a scalable system for static software comparative analysis within Ghidra. This intersects nicely with my own graduate research at University of Cincinnati, so I decided to give it a whirl over the break.

On November 17-19 2023, I had the pleasure of attending as well as presenting at Queen City Con here in Downtown Cincinnati. The conference was great, and the organizing team pulled off a successful effort. As a Cincinnatian, and former organizer at BSidesCincinnati, I was gratified to see a local group pick up this effort and deliver.

UEFI provides a standard interface to the GPU hardware, which can set the video modes & allocate a framebuffer, to provide uniform (albeit rudimentary) baseline access to graphical output. Generally speaking, it’s a successor to VGA and VESA BIOS standards that were commonplace on older systems. UEFI calls this the Graphics Output Protocol. In this post, we’ll walk through the steps to add a simple framebuffer graphics interface to the UEFI loader, in a manner that will produce a module that may be reused for the kernel, in the future. As well, this installment will work through the steps of finding and setting a graphics mode using UEFI, so that it is available when the kernel gets booted.

This is a continuation of the series on writing a simply hobby OS project in Rust. The first part of the series is here: OS Experiment in Rust (part 1): Creating a UEFI Loader. This portion of the exercise will cover some details helpful in bootstrapping the (eventual) kernel that will be written. This includes: interrogating UEFI and ACPI for initial details necessary for understanding the hardware configuration that is being booted from, as well as performing some initial framebuffer configuration to provide the booted kernel with standardized display capability immediately on boot.

Long ago, in the mid-late 1990’s, I got interested in the low-level operations of my PC and was determined to write a somewhat simple hobby OS in order to teach myself how the system worked under the hood. At the time, I wrote it all in assembly on my 486, and the goal was to make something that would bootstrap to 32-bit protected mode and also interact with the core hardware components on the system: VESA, IDE, 8042 keyboard controller, the Floppy Disk Controller, etc. Recently, I became interested again in exploring this space, but “PC” hardware has come a long way - both in terms of features as well as standards. So (if I stick to it), I’ll put together a series of intermittently-written blog articles that document my experience revisiting this hobby on modern systems, targeting a minimum set of system hardware requirements that are commonplace on pretty much every PC designed in the past 5 years.