From SSDT to IDT: A Personal Walkthrough of Kernel-Mode Intrigue (Uroboros Echoes)

 

From SSDT to IDT: A Personal Walkthrough of Kernel-Mode Intrigue (Uroboros Echoes)

 

 

“To understand the immeasurable, the mind must be extraordinarily quiet, still.”
— Jiddu Krishnamurti

 

By Seeker(李标明) China

Independent Malware Analyst & Researcher

Download the Full Report (PDF)

---

Prologue: The Temple and the Kernel

Recently, I climbed a mountain and visited the temple before sitting down at my machine. The mountain I walked around and stood at a place to watch the trees, flowers, and feel the air flowing, which, by the way, let me get close to nature to clear my mind. And all the things running in my brain to think of the kernel-mode security, I sucked them and shifted from user mode to kernel mode. What is it? How doesn’t it work? What’s the difference between the user mode and kernel mode? And so on, I strongly felt that everything was moving forward slowly and subtly. It seems that something rebuilt my whole mindset, and it took too much energy from my body; I felt very tired. That’s why I came there and found a place to close my eyes, sit, and listen to my heart and pulse beating, and all the things became silent and body-like music, and the birds were singing the song very beautifully. Yeah, I become quieted again. And the habit I changed it to was coming back from the temple and taking a hot shower and drinking green tea or making a cup of coffee and then jumping into the water of kernel mode.

---

Sample choice: Uroboros

In order to put my research into practice, I began to learn from the history of rootkits. At the beginning, I first chose WinRing0.sys to study a kernel-mode sample without malicious but powerful code. A little bit moving, I picked Uroboros as my object of research, which is from the nation-state group APT called Turla.

 

Yeah, I have to say that Turla's ability should be respected, and the strong feeling I got from research later, even honestly, took my tears at a certain moment. I felt it was not only technique but spirit; it means a lot, and I suddenly realized the knowledge I mastered was the surface skill, but I did quickly turn to keep moving and seeking…

 

Sample md5: ed785bbd156b61553aaf78b6f71fb37b                          

---

Initial Assumptions: The Classic Hook Trap

Like many analysts, I began by assuming the most likely culprit: an SSDT (System Service Descriptor Table) hook. But the NtQuerySystemInformation function did not behave as expected. Something was off. When I disassembled it, I saw

Fig.1 suspicious sign

 

I suddenly become aware of the suspicious sign, the branching to the "?? ::NNGAKEGL::`string'" region. The control flow conditionally jumps from NtQuerySystemInformation to this ?? ::NNGAKEGL::\string'+0x3edd0`:This is not normal for a clean NtQuerySystemInformation. Comparing with the original design in ntoskrnl.exe, I had found nothing.

Fig.2 comparing to the original design

 

The symbol ?? ::NNGAKEGL::'string can be especially misleading — it looks strange, almost like obfuscation or injected garbage at first glance.

 

At first glance, my analysis of NtQuerySystemInformation hinted at something darker. The control flow appeared altered. There were signs — unexpected strings like ?? ::NNGAKEGL:: string, jumps that seemed to bypass logic.

 

I thought, is this a malicious code here?. But something told me not to jump to conclusions.

---

Shifting Perspective: uf and the Real Path

I continued to disassemble it. I saw further and found the real implementation under my nose:

Fig.3 disassemble with NtQuerySystemInformation

 

This led me to ExpQuerySystemInformation.

Fig.4 disassemble with ExpQuerySystemInformation.

 

Inside ExpQuerySystemInformation, I found these:

1. nt!_security_cookie

2. Call NT!ProbeForWrite

3. nt! MmUserProbeAddress

4. nt!_imp_CiInitialize <PERF>

 

This wasn’t malicious. It was secure. The syscall validated its parameters and guarded memory boundaries.

 

Until now, I haven’t found anything. I did temporarily pause and went to the mountain and did running sports. I did not know how to do the next step and just checked many kernel APIs and watched.

---

 

IDT Hooking: BSOD And int 0C3h

 

I continued to list modules with the command “lm” and found the unloaded modules, including Uroboros.sys, so I asked myself, “Am I wrong? What’s happened?” Naturally, I wanted to know and check if the Uroboros was still running, so I entered “g” in Windbg as follows.

Fig.5 lm and g

 

But suddenly I triggered a BSOD, and I was thinking, What's happening?" Many seconds later, it surprised me that the OS still rebooted normally and the service already existed.

Fig.6 BSOD And Persistence Service

 

This thing startled me; from user mode to kernel mode, it’s a whole different realm. And then it seems that it warned me of another thing: malware knows me, debugs, and does anti-memory forensics and anti-analysis strategies at a low level? So I tried to find which kernel API can be hooked. I checked, nt!IoCreateDevice as follows.

Fig.7 IDT hooking

 

It startled me again; the key finding, the presence of int 0C3h inside IoCreateDevice, is absolutely not normal behavior. And then, in order to check it out, I compared the source code and the standard API. 100%, I was sure. Yeah, as you know, asking AI, what’s this technique?

 

It told me IDT Hooking: Interrupt Descriptor Table (IDT) is used by the processor to manage interrupt handling. When you see an interrupt like int 0C3h, it typically means that a custom interrupt handler has been placed at that entry in the IDT.

 

I was very excited for this discovery! And I want to know more inside. I continued to ask and enter “!idt –a” to look for the address IDT.

Fig.8 the address IDT

 

It was a custom interrupt — and not a standard one. Absolutely a custom IDT hook shellcode, it did. Hooking the int 0C3h interrupt vector in the IDT (Interrupt Descriptor Table)

Fig.9 a custom IDT hook shellcode

 

It's a textbook stealth IDT shellcode behavior. It looks handcrafted and highly suspicious — likely part of a rootkit's custom communication or hook mechanism.

 

Yeah, but here I had to pause. The night has fallen, and my body tells me about my thirst for food. But I wanted to talk to you silently: "I dreamed of chasing a snake during my lunch break."

---

Beyond the SSDT: Calculating Truth

I went further and began examining KiServiceTable:

dq nt! KiServiceTable L20

 

The entries were cryptic. I misread the format at first, believing the addresses were direct. I paused. Then recalculated based on the syscall base offset logic. I used the wrong formula to calculate the address in 64-bit Win7 but tried many times and finally found the right way. Kernel-mode security research needs very clear and real deep understanding.

Fig.10 the entry calculation formula

---

Inner Realization: The Path is Not Always Obvious

This wasn’t just a reverse engineering task. It was a meditation. I saw how my early assumptions clouded my vision. I rushed to find hooks, like chasing shadows in the fog.

 

Only when I slowed down, let go of judgment, and followed the flow calmly did I see the truth.

 

That let me remember about 12 years ago, I did research on the vision of Jiddu Krishnamurti, He often said, Go with your heart and mindset. Seeing without judgment.

---

Epilogue: What the Kernel Taught Me

I went back to the mountain and the temple again and again; the habit, the vision, and the mindset rebuilt as time passed.

What the important things I learned were

1.     Unknown is the known, I need to do it with curiosity and courage.

2.     Kernel-mode Security is not quick wins; it’s a whole different realm — one of architectural thinking and clarity. Keep learning, being silent, and embracing the slow pace. it is not surface-level tricks.

3.     Being fully present and lonely is real.

 

The most important thing is a pause, not an end but a journey. To be honest with yourself.

“Do or do not, there is no try.”
— Master Yoda

End of Report