ntoskrnl.asm in MASM

[Ficko]

Hi!

I am just wondering that is there a MASM version for this somewhere?:
https://github.com/angea/corkami/blob/03adbf6bfc38e13ab8391e604d78bbbb983b5d1e/wip/MakePE/examples/PE/ntoskrnl.asm

Or someone may has managed to compile it as NASM?

I am not able to compile it and it exceeds my NASM knowlage to figure it out why.

Even just the compiled dll would be appreciated.

[hutch--]

Tolerate me here, why the hell would you want to build an incomplete version of NTOSKRNL.EXE ? I understand the guys who build the freeware version of WINE trying to do this but even if you can get it going, what do you expect to do with it ?

I know of no version done in MASM.

[Ficko]

I will try to "tolerate" you Hutch. :P

The first line of the code says it all:

; DLL mimicking basic ntoskrnl functionalities for execution of drivers in user mode

It is possible to debug drivers in usermode.
What you need is to change the "Subsystem" from "Native" to "Windows GUI" and fake the kernel imports.

You can load the "sys" as "exe" into a debugger and step trough the code.

More details here:https://x64dbg.com/blog/2017/06/08/kernel-driver-unpacking.html

[fearless]

Maybe something like the attached would help, its a radasm project library based on https://github.com/mrexodia/driver_unpacking/blob/master/ntoskrnl/ntoskrnl.cpp
Just fakes all calls as public labels
could be converted to a dll to do the same, and similarly with the fltmgr.

[aw27]

It is possible to debug drivers in usermode.

In the same measure that it is possible to fake a football game with a Playstation.
Back to your code. It is not ready to be assembled with MASM. It is easy to make it assemble with MASM, but in my opinion it is a fruitless exercise  for people in this forum.

It is also obvious that the code has nothing to do with the real ntoskrnl code.

[Ficko]

Thanks "Fearless",

it is a good starting point I can go from there. :t

"aw27"

In the same measure that it is possible to fake a football game with a Playstation.

I think you just not seeing the big picture here.

Better metaphore would be:
"It is possible to fake flight with a flightsimulator"

Lots of pilots are thankful for that. ;)

fruitless exercise  for people in this forum

I didn't ask anybody do do anything - reading comprehension ? - merly to share something if already done.

Btw. the only exercise that is fruitless, which you can do without any effort.
In that case you would not bitch about it.

[aw27]

If you ever did device drive development you would know that this is not the way to learn about it, let alone "debug" them as you said.
You can easily debug device drivers in kernel mode and step through the code. All you need is 2 computers and visual studio.
Either way, fruitless or not, it is not also the way to learn Assembly language.

[Ficko]

You have a wild imagination aw27 presuming things from thin air.

I never said to wanna learn device drive development nor assembly language.

I just like to try out different ways to occasionally patch up drivers - mostly SCSI - for old hardware abandoned by the manufacturer to
run on Windows 10.
They usually only need some minor udjustments and a 2 computer setup can be an overkill to do that.
My estimation that with X64dbg - way outperforming Visual Studio with elegance and usabiity especially not having the source code - can get the job done just portion of the time as a full developer setup would allow.
Not to mention that I do not always have a fullfledged VS at hand but X64dbg happily run from an USB drive.
And the driver have to run to be debugged, naturally therefore the host OS can merely be a Windows 2000 where I have to use Olly or dig up SoftIce perhabs.

[felipe]

The Workshop... Any assembler programming topic is welcome...

I never said to wanna learn device drive development nor assembly language.

:(

[aw27]

I just like to try out different ways to occasionally patch up drivers - mostly SCSI - for old hardware abandoned by the manufacturer to
run on Windows 10.

I don't think Windows 10 will run them without a class 3 signature and a WHQL or ELAM certification because it is a boot start driver.

[sinsi]

I just like to try out different ways to occasionally patch up drivers - mostly SCSI - for old hardware abandoned by the manufacturer to
run on Windows 10.

I don't think Windows 10 will run them without a class 3 signature and a WHQL or ELAM certification because it is a boot start driver.

Windows 10 has a startup option "disable driver signature enforcement" for testing (at the moment anyway).
There is also "bcdedit /set testsigning on" (but secure boot will block it).

[Ficko]

Code Select Expand

bcdedit /set TESTSIGNING ON
Exactly!

I am not thinking about massproduction mostly I need to control one piece of old - but expensive - equipment, which is curently have XP or W2000 standalone so security is not a concern.
I already did it several times using the usual 2 PC setup, like I said just looking for something different approach.

felip, what I meant that I do not need to learn this stuff.
I wrote my first assembler program in 1980. (Z80)
And wrote plenty of device drivers in the 90-ies.

Unfortunately - or not - times changed and I had to move along with it where the money went. (C#, C++)
I still programming in assembler occasionally (GAS, MASM, FASM) but I am too old to learn NASM happy to keep up with C# new version coming out every 6 months. ;)

[aw27]

Windows 10 has a startup option "disable driver signature enforcement" for testing (at the moment anyway).
There is also "bcdedit /set testsigning on" (but secure boot will block it).

Sure.
Then you launch msconfig.exe and under Boot/Advanced options, you select Debug port.

but secure boot will block it

It is recommended not to use fancy features on a test machine. 

[Fabioxds]

You can easily debug Windows drivers using just a single machine if you want. I've done some kernel mode debugging on Windows NT 4 and 2000 under Vmware Player and VirtualBox, you just need to configure them right. You can even get updated debugging symbols (if you got service packs and updates installed) for those old OSes by using the microsoft symbol servers and Windbg.
The Windbg version you need is found on the Windows® Server 2003 SP1 Platform SDK or older. What I did was: installed the windbg that comes with that sdk on the virtual machines, then copied the debugger folder to my host and used that copy to connect to the VMs and do the kernel debugging.

Tips:

Windows® Server 2003 SP1 Platform SDK:
https://www.microsoft.com/en-us/download/details.aspx?id=12261

Debugging over a Virtual Serial Port using Vmware software:
https://www.vmware.com/support/ws5/doc/ws_devices_serial_advanced_example_debugging.html

VirtualBox kernel debugging a Windows XP Guest:
https://www.a1logic.com/2011/05/15/virtualbox-kernel-debugging-a-windows-xp-guest/

Use the Microsoft Symbol Server to obtain debug symbol files:
https://support.microsoft.com/en-us/help/311503/use-the-microsoft-symbol-server-to-obtain-debug-symbol-files

Another interesting option, live kernel debugging on a single machine:
https://docs.microsoft.com/en-us/sysinternals/downloads/livekd

And, of course, the same applies to newer Windows versions; you just install updated versions of the development tools.

[aw27]

When we mention 2 machines it includes as well virtual machines counting as a different machine from the host. This works in most cases, except for some hardware drivers.
It is all documented.
However, debugging our own drivers is done best from inside Visual Studio, which actually uses Windbg engine - like all the debuggers we can find - they simply supply the front end.

Another interesting option, live kernel debugging on a single machine:
https://docs.microsoft.com/en-us/sysinternals/downloads/livekd

This is not debugging it is working on a snapshot. It is impossible to debug live the same system.