You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The file was a non-stripped out linux binary file, which means debugging will be easier since we will be able to see original function names used in the binary.
14
14
15
15
## Strings
16
16
17
17
I ran the file through strings `strings bin` to see if anything stood out:
If we skip through instructions one by one and keep observing how register values change over time and what instructions are executed, we will soon end up at `check_pw+88`:
@@ -82,22 +82,22 @@ Note this from the above screenshot:
82
82
83
83
However, stepping through the instructions further, we can see that the jump is NOT taken - the program continues executing instructions at offset `check_pw+92` - suggesting the first character of the password does NOT start with a **`t`**:
What if we rerun the program and supply it with a password **`b`**`est` this time (replacing the first `t` with `b`, since the binary seemed to be expecting to see in the `dl` register)?
90
90
91
91
Well, this time the `cmp al,dl` sets the `zero` flag to `true` and the jump at `check_pw+90` is taken - suggesting that the first character of the password is indeed a **`b`**:
Going back to the long strings we saw earlier - they were indeed used in the password decryption routine, but going through the algorithm is out of scope for today:
Copy file name to clipboardexpand all lines: miscellaneous-reversing-forensics/windows-kernel-internals/manipulating-activeprocesslinks-to-unlink-processes-in-userland.md
+4-4
Original file line number
Diff line number
Diff line change
@@ -9,13 +9,13 @@ Lab is performed on Windows 10 Professional x64, 1903.
9
9
{% endhint %}
10
10
11
11
**Update 1**\
12
-
****Some replies to my tweet to this post suggested that PatchGuard would normally kick-in and BSOD the OS, which I am sure is the case, although in my lab I experienced no BSODs even though the kernel stayed patched with an unlinked process for 12+ hours.
12
+
Some replies to my tweet to this post suggested that PatchGuard would normally kick-in and BSOD the OS, which I am sure is the case, although in my lab I experienced no BSODs even though the kernel stayed patched with an unlinked process for 12+ hours.
13
13
14
14
**Update 2**\
15
-
****I realized that my Windows VM is running in test mode with no integrity checks, possibly explaining the lack os BSODs - unconfirmed.\
15
+
I realized that my Windows VM is running in test mode with no integrity checks, possibly explaining the lack os BSODs - unconfirmed.\
16
16
\
17
17
**Update 3**\
18
-
****Thanks****[**@**FuzzySec](https://twitter.com/FuzzySec) for clarifying the BSOD/PatchGuard matter!
18
+
Thanks [**@**FuzzySec](https://twitter.com/FuzzySec) for clarifying the BSOD/PatchGuard matter!
19
19
20
20
.png>)
21
21
@@ -142,7 +142,7 @@ Let's do the same for the process referenced by the notepad's BLINK to get the p
142
142
kd>daffffb208`f8b89370-2f0+450
143
143
```
144
144
145
-
.png>)
145
+
.png>)
146
146
147
147
Looks like our notepad EPROCESS is surrounded by two svchost EPROCESS nodes.
Copy file name to clipboardexpand all lines: miscellaneous-reversing-forensics/windows-kernel-internals/pe-file-header-parser-in-c++.md
+21-21
Original file line number
Diff line number
Diff line change
@@ -13,7 +13,7 @@ This lab is going to be light on text as most of the relevant info is shown in t
13
13
14
14
Below is a graphic showing the end result - a program that parses a 32bit cmd.exe executable and spits out various pieces of information from various PE headers as well as DLL imports.
* The code is not able to parse 64bit executables correctly. This will not be fixed.
@@ -25,7 +25,7 @@ Below is a graphic showing the end result - a program that parses a 32bit cmd.ex
25
25
26
26
For the most part of this lab, header parsing was going smoothly, until it was time to parse the DLL imports. The bit below is the final solution that worked for parsing out the DLL names and their functions:
Parsing out imported DLLs and their functions requires a good number of offset calculations that initially may seem confusing and this is the bit I will try to put down in words in these notes.
31
31
@@ -46,11 +46,11 @@ First off, we need to define some terms:
46
46
47
47
If we look at the notepad.exe binary using CFF Explorer (or any other similar program) and inspect the `Data Directories` from under the `Optional Header` , we can see that the Import Table is located at RVA `0x0000A0A0` that according to CFF Explorer happens to live in the `.text` section:
Finally, withthefileoffset0x9aa2, wegettoseeasecond (becausewechosetheoffseta6a2ratherthana690) importedfunctionfor the DLL ADVAPI32.\
185
185
Note that the function name actually starts 2 bytes further into the file, so the file offset 9aa2 becomes 9aa2 + 2 = 9aa4 - currently I'm not sure what the reason for this is:
CrosscheckingtheabovefindingswithCFFExplorer's Imported DLLs parser, we can see that our calculations were correct - note the OFTs column and the values a6a2 and a690 we referred to earlier:
Copy file name to clipboardexpand all lines: miscellaneous-reversing-forensics/windows-kernel-internals/subscribing-to-process-creation-thread-creation-and-image-load-notifications-from-a-kernel-driver.md
Below shows how the routine `sCreateProcessNotifyRoutine` gets executed when a new process hostname.exe (PID 2892) is spawned by powershell (PID 7176). Additionally, it shows that the process 7176 (hostname) terminated:
0 commit comments