Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why does trying to break into the NT 3.1 kernel reboot my 486DX4 machine?

retrocomputing.stackexchange.com

Post reply on HN
Print view View original

21–30 of 111 posts

Re: Why does trying to break into the NT 3.1 kernel reboot my 486DX4 machine?

#21

Post by pjgalbraith »

H8crilA wrote: post #17
fulafel wrote: post #8

"The fix is obvious" indeed.

Well, once the bug is identified, yes. I wonder how do you find a bug like that, I guess you keep reading the disassembly of the trapping code until you find the problem. I don't think he could have used QEMU or some other form of debugging.

He does mention a bit more in a hidden comment:

"NTOSKRNL.EXE + debug symbols + IDA helped me understand how the remote break-in is supposed to work. I knew that something in the remote break-in code path before the first debug packet is sent is going to reboot my machine. So I patched "JMP SHORT $" instructions into the relevant code-path. If I placed it before the crash point, the machine hangs. If I placed it after the crash point, the machine reboots. This allowed me to "bisect" where the crash is happening."

-----

Here is a Chat-GPT breakdown of the comment:

NTOSKRNL.EXE: This is the kernel of the Windows NT operating system. When people refer to the "Windows kernel," they're typically talking about this executable.

debug symbols: These are additional pieces of data that describe the internal structures and functions within a binary (like an EXE or DLL). They make it much easier to understand what's going on when analyzing or debugging the binary.

IDA: IDA (Interactive DisAssembler) is a popular disassembler and debugger used by security researchers and reverse engineers to analyze binaries.

how the remote break-in is supposed to work: It sounds like the commenter is trying to understand how a specific feature or vulnerability related to remote debugging (or "remote break-in") operates.

something in the remote break-in code path before the first debug packet is sent: There's a sequence of events or a code path in the kernel related to the remote debugging feature. The problem seems to manifest before the first debug packet is sent over the network.

JMP SHORT $: This is an assembly instruction. The JMP instruction is used to jump to another part of the code. SHORT refers to a short jump, meaning the jump target is relatively close. The $ symbol refers to the current address of the instruction, so "JMP SHORT $" will cause the program to jump to itself, effectively causing an infinite loop.

patched "JMP SHORT $" instructions into the relevant code-path: By inserting this instruction at various points in the code, the commenter created intentional hangs in the system. This helped isolate where the crash occurs.

bisect: This term comes from the world of debugging and means to divide the code into smaller parts to determine where a problem is. In this context, the commenter is using the hang (from the JMP instruction) as an indicator. If they inserted the JMP instruction and the system hangs, it means the crash hasn't occurred yet. If they inserted the JMP instruction and the system reboots, it means the crash already happened. By moving the JMP instruction around, they can get closer to the exact point of the crash.

In essence, the commenter used a mix of reverse engineering tools and clever debugging tricks to narrow down where a crash was occurring in the Windows NT 3.1 kernel when using a remote debugging feature.

Re: Why does trying to break into the NT 3.1 kernel reboot my 486DX4 machine?

#22

Post by cm2187 »

H8crilA wrote: post #19
tzahifadida wrote: post #5

I build a port check way back to determine if services are up. It crashed half the company by simply opening a few tcp ports to the machines. Ridiculous days :)

Remember when Win95 could be crashed or even rooted just by pinging it the right way? We really have come a long way. https://en.wikipedia.org/wiki/Ping_of_death I also remember SMB vulnerabilities that stayed unpatched for years on some machines. That was already when Metasploit existed, so you could inject VNC into most Windows hosts on local network with just a few commands. These days at least the patching is sup…

I remember those days.

Even into the late 90s early 2000, modems (including ADSL) didn't come with a router, you had to establish a PPPoE connection from your computer, which also means your home machine was directly on the WAN with no firewall protection.

I can't remember which version of windows but it must have been 98 or ME, you had to rush to download and install a patch when you connected it first to the internet before one of these exploits would make it crash.

The introduction of NAT changed all of that.

Re: Why does trying to break into the NT 3.1 kernel reboot my 486DX4 machine?

#23

Post by hkwerf »

H8crilA wrote: post #19
tzahifadida wrote: post #5

I build a port check way back to determine if services are up. It crashed half the company by simply opening a few tcp ports to the machines. Ridiculous days :)

Remember when Win95 could be crashed or even rooted just by pinging it the right way? We really have come a long way. https://en.wikipedia.org/wiki/Ping_of_death I also remember SMB vulnerabilities that stayed unpatched for years on some machines. That was already when Metasploit existed, so you could inject VNC into most Windows hosts on local network with just a few commands. These days at least the patching is sup…

Ping of death isn't just something for the old days: https://msrc.microsoft.com/update-guide/vulnerability/CVE-20...

Re: Why does trying to break into the NT 3.1 kernel reboot my 486DX4 machine?

#24

Post by ale42 »

smokel wrote: post #7
CodeWriter23 wrote: post #4

Earlier quoted context omitted.

Troubleshooting was different when we came up. Just your wits and maybe some gurus you could call on a landline as backup. No fancy internet with tons of answers of varying degrees of usefulness.

You might have forgotten them, but there were also books printed on paper.

As long as you had access to a library... When I was 14 or so, I used the MS-DOS DEBUG program to run step-by-step an executable that did something to change blinking to high-intensity background in text mode. After one hour or so I found the magic BIOS call... which of course was documented in the technical manual I found in the library one year later (because new school = new library with more books).

Re: Why does trying to break into the NT 3.1 kernel reboot my 486DX4 machine?

#26

Post by theclansman »

b800h wrote: post #6

This is proper programming. None of this namby-pamby web scripting that passes for development these days.

So many programming jobs feel like busy work with no interesting problems nowadays, I often wonder if it's only gonna get worse with time.

Re: Why does trying to break into the NT 3.1 kernel reboot my 486DX4 machine?

#28

Post by roomey »

cm2187 wrote: post #22
H8crilA wrote: post #19

Earlier quoted context omitted.

Remember when Win95 could be crashed or even rooted just by pinging it the right way? We really have come a long way. https://en.wikipedia.org/wiki/Ping_of_death I also remember SMB vulnerabilities that stayed unpatched for years on some machines. That was already when Metasploit existed, so you could inject VNC into most Windows hosts on local network with just a few commands. These days at least the patching is sup…

I remember those days. Even into the late 90s early 2000, modems (including ADSL) didn't come with a router, you had to establish a PPPoE connection from your computer, which also means your home machine was directly on the WAN with no firewall protection. I can't remember which version of windows but it must have been 98 or ME, you had to rush to download and install a patch when you connected it first to the intern…

Yes. I remember they would send UPS call to reboot your pc, within seconds of going online.

A little popup saying visit such and such site to stop your pc rebooting, and a countdown timer

Re: Why does trying to break into the NT 3.1 kernel reboot my 486DX4 machine?

#29

Post by darkwater »

H8crilA wrote: post #19
tzahifadida wrote: post #5

I build a port check way back to determine if services are up. It crashed half the company by simply opening a few tcp ports to the machines. Ridiculous days :)

Remember when Win95 could be crashed or even rooted just by pinging it the right way? We really have come a long way. https://en.wikipedia.org/wiki/Ping_of_death I also remember SMB vulnerabilities that stayed unpatched for years on some machines. That was already when Metasploit existed, so you could inject VNC into most Windows hosts on local network with just a few commands. These days at least the patching is sup…

Oh I remember those times. There was a guy in high-school 2 years younger that one day shown me that he wrote a C implementation of WinNuke on the school Unix server and he was then crashing Windows PCs in the lab for fun. He was a really smart guy and AFAIK he's been working at Google for a few years now (maybe he's on HN even?)
Post reply on HN