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
Labels: #IDT, #MalwareAnalysis, #SSDT, #Turla, #Uroboros
