I've decided to move to WordPress instead of blogger, because it seems to be faster, no Google+ integration is required (only reason I have a Google+ account is for Blogger) and inline LaTeX code seems to work. I also prefer the themes available on WordPress to Blogger too.
I've transferred all my posts, links and comments to WordPress. This is actually the second move for this blog, where it originated as a basic HTML website with a poor hosting provider. I then had to rewrite all my webpages for that website onto blogger. Thankfully, an Import/Export feature is supported between Blogger and WordPress!
WordPress URL - https://bsodtutorials.wordpress.com/
I thought I would create a list of Maths topics which were relevant for those who are wishing to study Computer Science. I've seen most people on online communities referring to topics which have very little relevance or completely pointless in relation to Computer Science. This list is based upon my experiences and a friend who studies Computer Science at University. I've listed the most popular Computer Science fields and their Maths topics below.
General Computer Science:
These are the topics which you will typically study in your first year, and therefore will have to do.
- Graph Theory
- Linear Algebra (Matrices and Vectors)
- Calculus I and maybe some Calculus II
- Analytical Geometry
- Set Theory
- Big O Notation
- Radicals, Logarithms and Polynomials
- Logic
Computer Graphics:
I'm not too sure about Graphics, but these are the subjects which do have some relevance.
- Fractal Geometry
- Linear Algebra
- Analytical Geometry
- Differentiable Geometry
- Hyperbolic Geometry
- Differential Equations
- Functional Analysis
Information Theory:
- Differential Equations
- Real and Complex Analysis - Fourier Series
- Calculus II and Calculus III - Taylor Series
- Probability Theory
Algorithms and Data Structures:
Most algorithms are used to solve mathematical problems, rather than the algorithms you see in commercial programs.
- Graph Theory
- Number Theory
- Combinatorics
- Probability Theory
- Big O Notation
- Set Theory
Cryptography and Computational Number Theory:
Computability Theory, Computational Complexity Theory and Automata Theory:
- Logic
- Set Theory
- Calculus I
- Recursion
- Proof Writing Techniques
- Number Theory
- Big O Notation
- Probability Theory
In general, it's best to study Discrete Mathematics rather than Continuous Mathematics. There's some fields like Abstract Algebra which are used in Algebraic Coding Theory. Furthermore, Discrete Geometry has its applications too. Continuous Mathematics encompasses areas like Calculus/Analysis and Topology etc.
I've created a comprehensive and complete WinDbg cheat sheet of the most general and useful extensions/commands which you'll be using regularly. I've added a few data structures to the list too. The list is organised by category, according to the different areas of debugging such as Memory or I/O.
Download Link (OneDrive) - https://onedrive.live.com/?cid=7101A9E8FE03DB78&id=7101A9E8FE03DB78!105
If there are any suggestions or corrections to be made, then please leave a comment in the comments section. Additionally, I've been attempting to convert my blog posts into a .DOC format which can be printed, unfortunately I haven't added any images to conserve space and ink. However, I have tried to construct the blog posts so you know which row or column to check; dd commands with the IAT/EAT post for example.
Computers are increasingly being used to solve mathematical problems, and are becoming more prominent in solving problems in Number Theory and Graph Theory, as well as, fields of Physics and Biology. However, computers have been used to create seemingly random numbers for either games or security purposes; these seemingly random numbers are called Pseudo-Random. They may seem random but in fact they aren't random at all.
To illustrate the difference between a true random number and a pseudo random number, look a look at the two images I've taken from Bo Allen's blog:
 |
| True Random Number |
 |
| Pseudo Random Number |
The difference is very obvious and thus highlights the key differences between a true random generator and a pseudo random number generator. A pseudo random number generator uses a mathematical algorithm, which is able to produce seemingly random numbers. A true random number generator uses methods which can't be predicted, and therefore are truly random. The randomness of numbers is important for encryption purposes and cryptography.
The true random number generators are hardware based, and most use the physics of Quantum Mechanics and it's probabilistic nature, like the quantization of electromagnetism which lead to discovery of photons and the Photoelectric effect. A pseudo random generator uses a software based mathematical algorithm to generate these random numbers.
A list of random number generators can be found here.
Artificial Intelligence is both a topic of Computer Science and Philosophy, and begins to ask what really makes us human and if we are just a complex biological machine? Alan Turing first asked the question in his 1950 paper named Computing Machinery and Intelligence. The paper is much more accessible in comparison to his paper about Computability Theory and computable numbers, which are real numbers that can be calculated with a terminating algorithm, the computable numbers are also considered countable (number of axioms for this).
This blog post won't be long, and I'll probably conclude with a link to my OneDrive account which has a copy of Alan Turing's paper. I'm going to be mostly be talking about the philosophy of Artificial Intelligence.
There is one concept which has been of great interest to philosophers since the beginning of civilization, and that is the concept of consciousness, which is the ability to be able to be aware of our own existence. This concept of consciousness is what separates us from being a very complex biological machine. In essence, our behavior is typically determined through learning and our own past experiences. Yes, we can incorporate this concept of learning into machines and measure how well it performs when learning, but a machine will never be aware of it's own existence naturally like a human, unless we find some method of enabling the machine to be aware of it's own existence, however, that would be cheating since it is still relying on predetermined behaviors created by us.
A machine is usually regarded as being intelligent if it is able to imitate a human successfully (it able to play the imitation game in Turing's paper); that is to say that a human is unable to distinguish a machine from another person. Turing outlines in his paper the similarities between a person and a computer. However, can a machine think? What is thinking? Computer programs are based upon a defined set of rules which can't be broken, unless the rules weren't correctly defined to begin with, and therefore is the machine thinking about a problem or just going based upon a defined set of rules?
Behaviorists will suggest that all thoughts are based on defined set of rules, and these rules give the false impression of free will and thought. This doesn't explain the idea of consciousness and what exactly creates consciousness. I believe machines will be able to solve mathematical problems and think, but they won't ever possess the strange and rather beautiful consciousness. Most robots aren't able to intelligently move around objects yet.
At the moment, most machines can only given Boolean valued answers to decision problems, they aren't able to think about the another answer, just give a simple "Yes" or "No" based upon some algorithm. There are learning algorithms, though I don't believe you can consider that as true thought. There is a popular idea of that a machine can only do what it is told to do, and this seems to very much true for almost all machines as of now.
I would suggest reading the paper Computing Machinery and Intelligence, which is available here.
It would be nice to hear some of my readers thoughts on the concept, and any ideas they may have about Machine Learning.
Instead of allowing my blog to completely go 'dead', I've decided to write a short post regarding my hiatus which is going to be used to improve of knowledge mathematics related to physics and computer science. The reason being is because I plan to finally go to University this September/October and study for a degree in Computer Science, and then eventually a Ph.D since I would like to research into the theory of Quantum Computing. To make things easier for myself and to give me an advantage when I do hopefully go to University, I feel it's better to learn the Mathematics beforehand since they are so crucial for a real understanding of the concepts in Theoretical Computer Science and Physics; Theoretical Physics is very mathematically orientated.
At the moment, I'm doing Business at college which isn't exactly my intended career path, but I only chose the subject since the Mathematics courses and Computing courses (more like Microsoft Office) didn't teach anything relevant to what I needed to learn. For example, at my Sixth Form (I did one year before going to college), the Maths was very statistics orientated and didn't teach much else apart from that. The physics courses were only classical mechanics and split across two campuses (two different schools were merged into one due to financial and political reasons).
So, that leaves me in the position of learning everything at home, which I've done anyway with the knowledge expressed in this blog. In a few months time I should be posting again and contributing to forums. I'll still be active on Twitter if anyone follows me.
As you largely know and can guess from the title of my blog, this is primarily a BSOD Debugging blog, and this will always be the primary aim of this blog. However, you as you already know I tend to post topics not directly related to debugging, and will post other topics which interest me like Theoretical Computer Science and Security.
I would like to make the following topics more abundant within my blog:
-Theoretical Computer Science
- System Security
- Windows Internals topics will be more tightly focused, which will be areas which you'll mostly need to know for debugging and security purposes.
- Debugging generally, for example looking at some of the common error messages.
I've chosen to write more things about Theoretical Computer Science, since it's something I would like to do as a career, especially the field of Quantum Computing, since it will combine my interest in Computer Science and Quantum Mechanics.
There's some great security tools which I would like to learn how to use more thoroughly, and these tools can reveal some detailed information about the operating system which isn't possible with other tools.
I'm also working on writing the Registry Internals blog posts, but I still need to get through the few papers I have on the subject.
If anyone has any other suggestions to what they would like to see more in my blog, then please say so.
Since learning to debug for the first time can be quite difficult at first, I thought I would write a short blog post as a method of motivation and encouragement for those aspiring to be Windows Debuggers. I've arranged the post in a few simple points.
Point #1 - Prior Knowledge Expectations
Have a clear understanding of computers in general. I'm not asking you to be a expert in a certain field (although it would be extremely helpful), but have a clear understanding of how computers work and how hardware interacts with the operating system at a entry level standard. You should understand the basics of drivers and system security.
Without any clear fundamental understanding of computers and Windows, you will certainly struggle to understand some of the more advanced topics. Some programming in C/C++ would be great benefit.
Point #2 - Knowledge
You don't have to know every single exact detail of how Windows works internally. Yes, you need to have a good understanding of how Windows works and which WinDbg commands and extensions are appropriate for each debugging situation, but I wouldn't expect someone (unless they have been debugging for a very long time at a professional level) to remember every exact tiny detail of the Windows operating system.
Sometimes, I won't remember every tiny detail but I will have a feeling in the back of my mind, that there is a certain register or certain data structure field which has some important information which could help me with debugging the problem. In these circumstances, I tend to check some documentation, ask another person or even check a previous blog post I wrote to see what bit within that Control Register enabled that certain feature.
Point #3 - Teamwork
I feel teamwork is a vital aspect of debugging and programming, and it enables us to overcome problems much more easily than if we chose to overcome the problem on own. Almost every forum I visited or contributed to, had a BSOD debugging team even if there wasn't a clear user title or badge to indicate that the members were part of a team of experts all thriving to accomplish the same goal. Solve the problem and use each others knowledge to teach and support each other.
There are some good examples I could give you. Let's start with one of my other interests which is Mathematics and Quantum Mechanics. All the great 20th Century Theoretical Physicists (much was uncertain about the subatomic world at the time) collaborated together and combined each others research and understanding together to understand how the subatomic world worked. Another example, myself and Patrick at Sysnative Forums always work with each other to solve BSOD problems and to share our knowledge and experiences. Our latest accomplishment was investigating the Stop 0x44 LogMeIn bug which has now been patched, and in process, have helped several users who depended upon the software.
How about Microsoft? Microsoft is a very large and one of the most successful companies in the world. Windows is a huge product, and each developer/debugger has expertise within a few particular areas of the operating system. Everyone works together to share knowledge and experience. Not everyone is going to know every area of the operating system internally.
Point #4 - Learning Takes Time
What is your personal motivation for learning to debug? We all have our reasons for learning how to do something new. Personally, I wanted to learn to debug because of the mystery surrounding BSODs and the small number of people which could solve such problems. I also really enjoy understanding how things work at a fundamental level. I feel debugging and Reverse Engineering combine some important skills, such as: Team Work, Problem Solving, Imagination and Analysis.
I tend to see some newcomers to BSOD Debugging, to give up far too easily and expect too much of themselves in too little time. Your not going to become a expert over night or reading a couple of Windows Internals books. It will take time to understand and learn the fundamental knowledge behind the subject. Remember that in the end, the rewards will be great and there nothing better than knowing that you accomplished something which you wanted to achieve.
Give yourself realistic expectations, speak to others who share the same interests as you, and have a go at looking into some problems yourself. You may be surprised about how much you do actually understand.
Point #5 - Building a Knowledge Repository
I've seen some people argue that you won't find any information on the Internet related directly to BSOD Debugging. I would disagree with that point. I have no I.T. Certificates\Qualifications or any Computer Science degree, and I have to managed to learn everything I know about computer from the Internet (online documentation, blogs, websites and forums) and various books.
The best book you could buy to get you started is the Windows Internals book. It's not too expensive, but you can get a good condition copy of the book used on eBay or Amazon. I managed to get a copy for £7.00 from Amazon with the fastest delivery option, and the book was is in very good condition.
I wouldn't rely on the entire book as your only resource, it's a excellent book and does teach you a great deal, however, even the authors suggest looking into other books and websites, if you wish to learn the exact specifics of how Windows works. This supports my point about the size and complexity of the Windows operating systems.
Build a repository of books, blogs, websites and papers for yourself, and then learn from these resources and use them as a reference point.
Personal Aspirations and Closing Points
I personally aspire to earn a PhD in Computer Science and solve some of the problems associated with the field. One of my personal heroes is Alan Turing due to his pivotal work during the WWII, and his theoretical work towards to the modern development of Computers and the field of Computer Science.
I'm a firm believer in free and open education for everyone, and that everyone can achieve their goals if they have the motivation and determination to get there. One of my other heroes is Arnold Schwarzenegger, and how he overcame everyone's' doubt about the realism of his own aspirations and goals.
Remember that we have our own strengths and weaknesses, and the sum is greater than the individual parts.
This is hopefully going to be the upcoming blog posts for February:
- VTables and Virtual Functions
- Thread Storage Slots
- I/O Completion Ports
- IRP Queues
- PE Header Sections
- Registry Internals
- URBs and USB Internals
I'm also going to explore the I/O Manager more, since I haven't written much about it, and to be honest haven't read anything properly which is related to I/O for a while.
I've resurrected this blog's Twitter account, and will be posting any blog updates on there, along with general security and Windows Internals information. I'll also retweet other blog updates and updates from security researchers and debuggers.
You be able to see which topics will be posted during the month, the general topic list so far is:
- Shadow SSDT Hooking
- Heap Types
- Page Fault Types
- Direct Memory Access
- Memory Barriers
If you have a Twitter account, then please follow @BSODTutorials
Thanks for the continued support!
Well, as we all know, it's the first day of 2014 tomorrow; New Year's Day. I thought I would write a very quick blog post wishing all my readers a Happy New Year, just in case I don't have time tomorrow to write one up.
Happy New Year!
This blog has really grown, especially during this month, it's been late nights after the pub and work and even college, just staying up and trying to write as much information as possible (whilst being concise and to the point), since I have so many ideas and topics I would like to write about.
Anyway, I hope you enjoy reading my blog so far, and I hope it's helped you understand debugging a little more, and turn that at first glance alien language of memory addresses and WinDbg commands into something more understandable.
Thanks for the support, and please keep reading my blog, and leave a comment or two, if I've made a mistake somewhere or you would like to have a certain topic added.
This isn't exactly a tutorial related to debugging, it's more a canned speech which you could provide if you wish for the person your helping to upload any Kernel Memory dumps, which are far more useful than Minidumps. Be aware though, Minidumps are also created when a Kernel Memory dump has been configured.
Step 1: Create a Microsoft account if you don't have one, and then sign into your SkyDrive account.
Step 2: Once signed into your account, enter your Public folder and then use the Upload button to browse to the location of the dump files. It's best to place the dump files into a zipped folder before uploading, to improve upload and download times.
Step 3: Once the file/folder has been successfully uploaded, then simply copy and paste the URL of your Public folder. The Public folder is accessible to anyone who knows the URL.
I think this may be the one example of the a user-mode program, actually being the sole cause of a BSOD. While it's technically impossible for a user-mode program to cause a BSOD directly, it can be possible for a user-mode program to cause a kernel-mode driver to act in a manner which would cause a BSOD. In this case, the a user had downloaded several cracked games (which contained infected files), I even gave a warning that cracked games tend to be malware, and it looked like I was exactly right.
So, lets begin: one of the games had a application error which I opened with Visual Studio, it indicated that a thread attempted to access a virtual address which it didn't have access to. It's most likely kernel address space in my opinion, I may check this later.
As soon as, I noticed this it gave me assumptions that the game(s) are most likely malware, since I already established with the user they were cracked, and they were in full acknowledgment of this too.
Looking at the MBAM Log (Malwarebytes), I found some interesting entries:
C:\Program Files (x86)\Square Enix\Sleeping Dogs\buddha.dll (Malware.Gen.SKR)
Another game indicated this:
D:\Users\USER\Downloads\SAINTS ROW 4 CRACK ONLY-RELOADED.rar (VirTool.Obfuscator)
D:\Users\USER\Downloads\SAINTS ROW 4 CRACK ONLY-RELOADED\Crack\steam_api.dll (VirTool.Obfuscator)
D:\Users\USER\Downloads\Saints Row IV Commander In Chief Edition-FULL UNLOCKED\Saints Row IV\steam_api.dll (VirTool.Obfuscator)
VirTool.Obfuscator is a Windows Virus which hides itself as a certain file, in this case a .DLL for Saints Row IV, to perform malicious actions.
Microsoft should have hopefully updated their symbol servers on Wednesday 16th October, although, some BSOD debuggers are still reporting problems with the symbols. I know, some dump files do have symbol errors occasionally, but if your getting a large amount then I would contact Microsoft.
I've also been very ill for the last few days due to a very contagious stomach bug, so I haven't been presence at all in the online world for the last few days.
Note: This article is my opinion, and isn't intended to offend anyone [Point 3]
Although this blog post, is not exactly a tutorial or a link to a tutorial, I would like to explain why I don't even consider debugging a counterfeit installation and why you shouldn't either.
Effectively, most counterfeit installations take advantage of some exploit or apply some hack to bypass the activation requirements for Windows, this may explain to some of you, how you might notice a OEM_SLP key on a retail motherboard.
I'm assuming you know how to tell the difference between a counterfeit and geniune installation, therefore I'm just going to describe some of my reasons for not considering counterfeit installs to be worth debugging.
Firstly, counterfeit installations have key Windows files altered, in order to make the installation work, although, this can lead to most people having Windows Update difficulties. If the installation is not within it's original state, then it could give very misleading BSODs or crashes. For example, Stop 0x124's are handled by WHEA, part of the operating system, a corrupt driver could be the cause, but instead the cause is given to some hardware component, such as a data read from the Level 2 cache.
Secondly, counterfeit installations have many vulnerabilities and stability issues, the installation could easily be at fault and cause of the all the problems, if it can't handle basic tasks or procedures required by device drivers. The installation is most likely to be infected with some malicious software or code, causing further instability, if you able to resolve instablity at this moment in time, the same problem is very likely to repeat itself in the future.
Thirdly, and this may be slightly discriminatory, but from my experience, the user with the counterfeit installation, is usually very rude, impatient and wants a "quick fix" for their problems. The users I have had, mostly feel they are "smarter" than you, and will discount the installation as being the problem, and will begin to become abusive or impatient.
Most forums will not even accept counterfeit installations. Some users are completely unaware of their counterfeit installation, and will often be thankful for pointing it out to them. If you are victim of a having been sold a counterfeit installation, and can prove you were completely unaware, then I believe Microsoft can help you with it.
Right, I'm been reading some great resources on Windows Debugging, and the internals of the Windows operating system. Remember my 5 learning tips? I still feel it's very important to understand the mechanics of the operating system when debugging, especially when we usually tend to only have Kernel-based dump files to work with.
Okay, so enough of the chatter, and let's get some debugging resources written up for you to enjoy:
MSDN Library (Debugging) - http://msdn.microsoft.com/library/windows/hardware/hh833791
MSDN Library (Drivers) - http://msdn.microsoft.com/library/windows/hardware/gg581061
MSDN Blogs (NT Debugging) - http://blogs.msdn.com/b/ntdebugging/
Mark Russinovich’s Blog - http://blogs.technet.com/b/markrussinovich/
Channel 9 | Defrag Tools (Debugging Videos) - http://channel9.msdn.com/Shows/Defrag-Tools
OSR Online (Drivers/Debugging) - http://www.osronline.com/index.cfm
There's many resources out there, which are free and available to use, so get searching and reading about debugging, driver development and operating system mechanisms.
Okay, most computers will get a BSOD at some point in their lifetime, much like we will almost certainly become ill at some point. A BSOD can be a scary and frustrating predicament for most users who may not have the knowledge of what a BSOD is and how to resolve it.
They will tend to search YouTube or a Google, and here's what really irritates me; the usual advice which is given to them is to clean install Windows and hope that the problem doesn't happen again, that's until they install the program or driver which was causing the problem.
Okay, that's enough of exerting my annoyance with posts like that, in this blog post, I'm going to give you future debuggers some quick learning tips which will help you improve your responses when debugging BSODs, and when attempting to understand the technical concepts of computers.
Tip #1
Grab a programming book on C++ or find a website which offers some good tutorials for learning how to program in C++. The drivers developed for the Windows operating system are primarily written in C++ now, and therefore I feel it's important if you wish to understand what some of the driver function calls do then learning C++ will certainly be an asset.
Here's a good reference -
-http://www.cplusplus.com/doc/tutorial/
Tip #2
You will soon see many parameters of bugchecks giving us some very useful information, to how the BSOD was exactly caused, I feel learning how the Windows operating system works internally, will help you understand what these parameters mean and what steps should be taken when debugging the crash.
Tip #3
I suggest learning how hardware works and how we can test different hardware, many BSODs can be caused by hardware, and having a good background of hardware diagnosis will certainly help you with the debugging process.
Tip #4
Read the Windows Debugger documentation, and learn how to use different extensions and commands to extract more useful information from the dump files. Please note that a Kernel memory dump may be needed for most of the commands.
Tip #5
Sign up and join a forum and start reading different debugging blogs, there is a huge level of knowledge which many users share openly and many will be willing to answer any questions you have about debugging BSODs.
