According to the advice from Vir Gnarus, it seems like my approach was in the reverse direction i.e. repair and then understand. I am looking forward to progress over time ^_^
I don't think there is a
wrong or
reverse approach. In a perfect world, yes I do agree it's important to understand what you're doing before you do it. However, in my world especially, I am the type of person who learns the most from doing it himself. I can sit and read Windows Internals ten different times, but unless I am actually putting that information to actual use in my own debugging on a day to day basis, I won't retain the information very much at all.
As an example, when I started learning debugging way back in very early 2012, I had
no idea Assembly was even a thing. In fact, I don't think I even really started doing any sort of debugging that required knowledge of even the most basic Assembly until about middle/late 2013 (right around the time I was learning to debug 0x101's). When I started debugging, there was
very few of us (mainly the people you see here now, with 1/2 from SF that no longer post on forums), so information was essentially you learning things on your own with occasional private conversations with debuggers. I consider it a blessing to see how many debuggers we have today that have structured information to learn from, references, etc. That's what we here at Sysnative aim to help with, and I feel that definitely helps the starting learning process not seem so 'lonely' and daunting.
To expand, as a beginner debugger, you've probably pasted this a hundred or so times to someone to explain what crash they had:
DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
This indicates that a kernel-mode driver attempted to access pageable memory at a process IRQL that was too high.
In the beginning, I had absolutely no idea what this actually meant, I just saw WinDbg told me it was the bug check that happened, so that's what I told the user. Eventually after pasting this and debugging this bug check a thousand different times, you start saying to yourself 'I want to learn more about this so I get better at it'.
- You learn what kernel-mode is. When you learn what kernel-mode is, you learn what user-mode is, you learn about the HAL, drivers (and their limits), API, etc.
- You learn what pageable memory is. I'd imagine when you learn what pageable memory is, you learn what pagefaults are (also soft/hard), virtual memory, the different types of pagefaults (access violation, etc).
- You learn what IRQL is. When you learn what IRQL is, you learn what spinlocks are, what a lock is (and why it's bad), what DPCs/APCs are, what I/O is, how drivers interact and work with the different IRQLs, what interrupts are, clock ticks, it's endless.
Congratulations, you understand a portion of Windows Internals! Eventually you learn this for 50 other bug checks you've seen a thousand times or more and you have a pretty solid understanding of Windows Internals. I've been doing this for almost three years and I still learn something new every day, especially regarding reverse engineering.
What VG said here is a perfect statement:
So debugging and forensic troubleshooting are really a bunch of disciplines all wrapped up in a big package.
You're learning entire languages (C++, Assembly), the entire science behind an OS, and then debugging itself. All of this takes a lot of time, and a lot of practice. So with that said, learn at your own favored pace and let everything come naturally and comfortably. One of the best things about debugging is you're not pigeonholing yourself into one thing, as if you truly understand debugging (especially at a kernel-level), you understand a
lot of Windows Internals, programming, etc.
Regards,
Patrick
so someone if willing to teach me the hard stuff, I am all up for it.
