Slashdot Mirror

While not wishing to fan these flames further, there are some (IMHO) good utilities from sysinternals which allow you to do this for free.

filemon will report file update/access and regmon will report registry update/access.

I haven't tried your examples, but I have found that even if the output from these is rather verbose, given some judicious regular expressions the output can be cut down to manageable size.

We NT folk have FileMon, RegMon, and Sysdiff/SMS Packager at our disposal.

It's not often there exists something in the NT world that doesn't have a parallel in *nix land, but this is one of 'em
---
nuclear presidential echelon assassination encryption virulent strain

We NT folk have FileMon, RegMon, and Sysdiff/SMS Packager at our disposal.

It's not often there exists something in the NT world that doesn't have a parallel in *nix land, but this is one of 'em
---
nuclear presidential echelon assassination encryption virulent strain

Microsoft has been allowing some small access to source code for years. A little less than halfway down this page, there's a summary of a discussion called "Do you need source?" The discussion took place in 1997, and indicates that quite a few academic institutions had access to NT source code back then.

So how does "shared source" change Microsoft's policy about source code? That has never been clear from Mundie's verbiage.

The discussion summary includes this little gem:

The conclusion was that Vogels's group used source code only as documentation (there is no other documentation for NT), examples, and to understand the behavior of NT. It turned out to be useful for debugging, and it led to the discovery of interesting APIs that are not documented or available in Win32.

Microsoft has been allowing some small access to source code for years. A little less than halfway down this page, there's a summary of a discussion called "Do you need source?" The discussion took place in 1997, and indicates that quite a few academic institutions had access to NT source code back then.

So how does "shared source" change Microsoft's policy about source code? That has never been clear from Mundie's verbiage.

The discussion summary includes this little gem:

The conclusion was that Vogels's group used source code only as documentation (there is no other documentation for NT), examples, and to understand the behavior of NT. It turned out to be useful for debugging, and it led to the discovery of interesting APIs that are not documented or available in Win32.

The free version is read-only, they also offer a read-write version for purchase.

On Windows NT, try this:

ctrl2cap from SysInternals

I install this on every NT machine I have to use. It's wonderful! Works great. Patches things at the kernel level so you never have to worry about that pesky control key being in the wrong place, or capslock wrecking your code.

mmmm. It's an amazing piece of 'ware. :)

I did this one last year.

I was working at a large company in their web development group. They had a small server farm that the web group used for testing new stuff and for new development. I was not really in charge of the farm, but people would always come and bug me when they needed help with it. The servers were almost entirely NT.

SysInternals has this really spiffy NT screensaver that looks like the WinNT BSOD, along with a fake reboot, which will then go into a fake disk check, which finds fake errors, and repeats. So, the night before, I wrote a little script that made the BSOD screensaver the default on all of the servers.

The next morning, people kept coming to my cube and...

PERSON: All the servers crashed!!!!
ME: Really? (clickity clickity) I can still ping them. Are you sure they're dead?
PERSON: They look dead. I'll go look again.
Minutes later...
PERSON: Really! All of them! BSOD!
ME: ROFL

I caught 3 different people that morning.

These utilities sound very useful. Could you please post links to their websites?

I'm not the original poster, but...

SysInternals has the goods...

Si

In case you can't figure out what registry entries it's reading, you can use this. http://www.sysinternals.com/ntw2k/source/regmon.sh tml

Check out the BlueScreen Screen Saver by Sysinternals. It will display a realistic BSOD based on your real system config (memory size, processor, build, etc.), reboot, and display the appropriate splash screen for your OS. On NT, it even does a simulated CHKDSK with errors.
Decieve your friends and scare your enemies!


--
Mike Hollinger

A standard to me implies some kind of documented specification that is complete enough to create/recreate from that specification. Some examples are POSIX, X.509, HTTPD/HTML, PKCS#11, etc. To me, Microsoft has not declared themselves a standard, but rather a convention. They obfuscate system calls, continuously change their document formats (so even older products by M$ cannot read them), etc, etc.

This is not yet another M$ bash per say, but a plea to Microsoft that if they want to become a standard, please publish that standard.

Also, remember how strongly Microsoft objected to the read-write version of NTFSDOS, because it "violated security" by reading and writing NT file systems from DOS. (The original read/write version was pulled under pressure from Microsoft. There's now a freeware read/write version, years later, but it's a different program. Microsoft didn't like those guys; they wrote NTCRASH, which found dozens of security holes in NT by generating random system calls.) So it's suprising to see something like file system defragmentation farmed out.

Also, remember how strongly Microsoft objected to the read-write version of NTFSDOS, because it "violated security" by reading and writing NT file systems from DOS. (The original read/write version was pulled under pressure from Microsoft. There's now a freeware read/write version, years later, but it's a different program. Microsoft didn't like those guys; they wrote NTCRASH, which found dozens of security holes in NT by generating random system calls.) So it's suprising to see something like file system defragmentation farmed out.

rm -rf /* is a poor deletion technique anyways. There are several undocumented 'unrm' utilities out there (I've seen one myself) that are basically fancy implementations of 'dd' that can easily recover data from a UFS or ext2 filesystem.

If you really want to wipe your data clean you should use sdelete (Windows) or secure delete (Unix).

Well ext2 doesn't add any physical security either. I can get ext2 drivers for Windows here and get access to my Linux partition. So much for security.

As far FAT32 support, it has been available from third parties for a long time.

SysInternals offers NTFS for DOS and Windows 9x. So you can access NTFS drives without NT currently. This also bypasses security -- but as has been noted before, if you have physical access to the machine, you can do anything you want, pretty much, so no biggie.

___________________________

SysInternals's File Monitor, Registry Monitor, VXD Monitor, and TDI Monitor could be useful for detecting and removing Napster's invasive tags.

SysInternals's File Monitor, Registry Monitor, VXD Monitor, and TDI Monitor could be useful for detecting and removing Napster's invasive tags.

SysInternals's File Monitor, Registry Monitor, VXD Monitor, and TDI Monitor could be useful for detecting and removing Napster's invasive tags.

SysInternals's File Monitor, Registry Monitor, VXD Monitor, and TDI Monitor could be useful for detecting and removing Napster's invasive tags.

If your hard drive crashed and you bought another, you'd have to call them again for another install password.

There is one falacy to this. There is a dos program that will allow you to change the Volume ID on your HD (Works great for stupid companies that have their serial # based on your HD Vol ID! can you say Aldon!). So if this situation came up, just have a pre-created boot disk with this dos program on it and change the Volume ID on your HD to the One you previously had (make sure you make note of it when you install the first time!) and Whola! you don't have to call M$ ever again! The program is called VolumeID You can get it by clicking on the "VolumeID" Link Provided! :^).

There is ALWAYS a way around companies blatenly being stupid!

Remember: "There is no such thing as a stupid question, Just a stupid person!"

Get ERD Commander from SysInternals to fix that NT4 box. Command console doesn't exist on NT4, only Win2k.

SysInternals is a cool company - they seem to like Open Source too. See this page for all the source code freely available. Remember that tree in "A Charlie Brown Christmas"? Maybe NT only needs a little love to grow. Nahh.

Get ERD Commander from SysInternals to fix that NT4 box. Command console doesn't exist on NT4, only Win2k.

SysInternals is a cool company - they seem to like Open Source too. See this page for all the source code freely available. Remember that tree in "A Charlie Brown Christmas"? Maybe NT only needs a little love to grow. Nahh.

In NT, as with most time-sharing operating systems, threads run in turns called quantums. Normally, a thread executes until its quantum runs out. The next time it is scheduled it starts with a full quantum. However, in NT a thread also gets its quantum refreshed every time its thread or process priority is set. This means that a thread can reset its quantum by calling SetThreadPriority (without changing its priority) before its turn runs out. If it continues to do this it will effectively have an infinite quantum. Why does NT do this? Its not clear, but it appears to be a bug.

CFO Magazine articles should be shunned because it't too easy for some industry analyst to make undocumented claims.

Folks, it's obvious that this is "yet another eye-ball catcher, ad revenue generating article" intended to spread FUD and cause IT managers to buy Micro$oft SMS software. After all, we know for a Fact(tm) that M$ does not have back-doors, errors or undocumented features to begin with, and so, by extension, it is Impossible(tm) to make undocumented changes to the OS.

M$ software, such as ISS, does NOT include an undocumented dll file the sole purpose of which is to introduce a back-door, and to mock Netscape coders.

M$ software, such as Excel, does NOT include an undocumented functional flight simulator accessible to those who know the secret key combination.

An IT staffer can NOT go to SysInternals and get a utility to change the size of a swap/working set, or a utility to change the NT timeslice; munge around in the server room and 'forget' to write it down somewhere.

An IT staffer can NOT deploy SP4 to 1500 workstations overnight without anyone's knowledge.

Article Executive Summary: "We're completely safe from the revolting techno-geeks, if we buy Micro$oft software. If we pay M$ $1000/PC for support, we don't have to hire an expensive technical staff - that might some day turn on us - and can get away staffing the server room with MIS interns. "

Yes, it is stupid. You cannot get to the C: drive to fix data corruption with a normal boot disk as with FAT. Especially on print servers where this eems to happen all too often... Ever see the message "Cannot find NTOSKRN.VXD"...

Ever played with the Sysinternals' NTFSDOS Professional? Allows you to, using one floppy, have read/write access to your NTFS partitions. No more reinstalling NT to an alternate directory just to replace one DLL.

Not saying it's the end-all-be-all, but it sure is a slick tool and allows you to keep the benefits of NTFS on your system drive.

SysInternals has a solution for this. One of its products is called BlueSave, which is a utility that will save the text of the BSOD to a file. BlueSave is conveniently packaged along with a companion utility that will cause your PC to crash to the BSOD.

We've provided the source and executable to a program, BSOD, that you can use to intentionally crash your computer in order to test BlueSave. Note that this program uses a device driver component to perform privileged operations and is therefore not exploiting a bug in Windows NT.

SysInternals has a solution for this. One of its products is called BlueSave, which is a utility that will save the text of the BSOD to a file. BlueSave is conveniently packaged along with a companion utility that will cause your PC to crash to the BSOD.

We've provided the source and executable to a program, BSOD, that you can use to intentionally crash your computer in order to test BlueSave. Note that this program uses a device driver component to perform privileged operations and is therefore not exploiting a bug in Windows NT.

Oh, and it's all freeware. =)

--

> It's highly unlikely that Microsoft has a "Secret Win32 API" manual floating around it's headquarters

No, but they do have one for the Native NT calls.

Inside the native NT API

and

Inside Native Applications

> It's highly unlikely that Microsoft has a "Secret Win32 API" manual floating around it's headquarters

No, but they do have one for the Native NT calls.

Inside the native NT API

and

Inside Native Applications

So MS actively publish the fact that APIs are undocumented. In other words MS are certainly aware that these undocumented APIs exist - they just choose to confirm or deny it when it serves their interests to do so. Sysinternals also discusses the almost completely undocumented "Native API" of Windows NT.

Some APIs are obviously deliberately undocumented, the data structures used in the lineSetDevConfig() API being one example. This even appears (gulp) to be for good design reasons - data hiding no less.

Some cases are apparently accidental, but nonetheless unhelpful - SystemIdleTimerReset() is mentioned in the wince (what an appropriate name) docs, but not documented itself. So, we take a wild guess and hope for the best. Typical of win32 programming, and perhaps the most pragmatic reason to write for an OSS OS.

Of course if you run WinNT and it doesn't bluescreen on its own with sufficient frequency, you can always try the BlueScreen Screen Saver from the Sysinternals website.

"Say due to some "bug" in the software, you get locked out of your mission critical system. How do you get back in? "

As others have already pointed out, such a backdoor should only be of any use to someone who has physical access to the machine. The implication of this article is that it is available to remote users which is highly dangerous.

NT already can be unlocked if you've managed to lock yourself out, so long as you have physical access. Go to http://www.sysinternals.com/ and check out their NT utilities page, looking for a thing called 'Locksmith'. This lets you create a boot floppy which will reset the password on the account of your choice.

It caused a stir at the time, but of course if you can boot the machine from a floppy, then you can reset passwords. If the OS on the hard disk can change a password then so can any other OS that can get access to the hard disk. Just like I can come along with a Linux boot disk, mount your hard disk and edit your password file to get root access...

Wow -- thanks man! Sysinternals.com is awesome!

> what makes you think that there are any hidden API's remaining in current MS platforms?

I take it you have never written a NT device driver, but here is the proof:

Inside the Native API

Inside Native Applications

> I would really love to see any kind of proof that they exist

When NT 4 starts up, chkdsk is a native NT app. HOW could it be a win32 app, when win32 hasn't been loaded yet?!

Cheers

> what makes you think that there are any hidden API's remaining in current MS platforms?

I take it you have never written a NT device driver, but here is the proof:

Inside the Native API

Inside Native Applications

> I would really love to see any kind of proof that they exist

When NT 4 starts up, chkdsk is a native NT app. HOW could it be a win32 app, when win32 hasn't been loaded yet?!

Cheers

> Please name some of these undocumented API calls.

Under NT, that is easy:

Inside the Native API

Inside Native Applications

Cheers

> Please name some of these undocumented API calls.

Under NT, that is easy:

Inside the Native API

Inside Native Applications

Cheers

... because they gave the world ctrl2cap. Sure, there might be other ways, but I like the idea of doing it with a kernel mode device driver. Try www.sysinternals.com I'm not sure if they do consulting work, but the site is well worth checking out.

C-2 rated systems require a Secure Attention Key (basically some way to guarentee you have a real-login screen, and not a fake one. Ctrl-Alt-Delete in NT) which I don't think the Open Source unixen have yet.

Ctrl-Alt-Del on NT can be masked simply by filtering keyboard device. See this page for helpfull source code.

And with support program (preferable service) you can create new desktop object and mimic Logon screen :-))).

Conclusion: Anybody with "Install new device" privilege can owercome SAS. In reality this privilege have every Admin.

You could have used a DOS disk with the NTFSDOS program (available here) and gotten the filename too.

Doesn't prove very much though ANY unencrypted filesystem can be compromised in a similar way, even Linux's ext2 filesystem.

Much better to use the excellent free stuff from www.sysinternals.com for all of us who are stuck with at least one Windows machine at work.

The resource kit includes tools to interpret the core dump and regurgitate the BSOD contents (which, BTW, almost always points to a video driver file). If that isn't good enough go over to www.sysinternals.com where there is a utility that saves the screen contents specifically.

Not only do they not know what they're doing with regard to other OSs, they've obviously never even beend round SysInternals - as there's a FAT32 driver right there, for NT...

"If you do not know your administrator account password, you will have to completely reinstall Windows NT" - what crap! Who *doesn't* run their personal NT boxes as an administrative user, who can blank the Administrator account's password any time they like? (OK, apart from those of us who run linux instead all day.. :)
As for using a naff pagefile size - doesn't it grow? Can't users cope with error messages about running low / out of virtual memory? If not, then it's a design fault as much as anything else. But I'd prefer to put it down to typical luser stupidity.

Altogether, more FUD - albeit against microsoft today.

What does this kind of article actually achieve?
Those of us "in the know" dismiss these things as crap spouted by someone with keyboard diarrhoea, those who don't know what they're doing won't understand a word of it anyway. Seems pretty pointless to me!

A utillity to generate new SIDs (called NewSID, strangely enough) is available from http://www.sysinternals.com under NT utilities. It's certainly easier to clone a machine and run this utility than to use NTs automated install.

Each NT system not only has a a unique computer name, it also has a SID (Security ID), which is generated in much the same way as a GUID. If the network has several systems that share the same security ID, there are problems, and *that's* why it's unsupported.

Systems Internals has had an app that allows you set up a new ID for a long time. Take a look at it here.

He indicated that it worked by basically replacing the WIN32 subsystems of NT by separate code that was built on the NT HAL (Hardware Abstraction Layer) not Win32.

Are you certain he said that it was built on the HAL? The impression I had is that it's built on the native NT system-call API, just as, say, subsystems such as the Win32 subsystem are, and just as the core API libraries (e.g., kernel32.dll) are, and just as some executable images that come with NT are. See, for example, Softway's "The INTERIX Solution" white paper, which has a diagram labeled "The Interix architecture" showing the Interix and Win32 subsystems running atop the NT kernel (although that diagram doesn't note that some Win32 APIs are apparently built directly atop the kernel, in the sense that some routines in, say, kernel32.dll directly make system calls; I think one of the editions of Inside Windows NT says that ReadFile() and WriteFile() don't pass through the Win32 subsystem process - perhaps some of the Interix library routines implementing the UNIX API do the same).

Building it purely atop the HAL would mean it couldn't access files on the file systems available to Win32 applications, say, as the file system and device driver code inside the kernel isn't part of the HAL.

If the kernel is the OS, then I'd appreciate it if you start referring to the "Win32 OS" from now on.

Win32 isn't actually implemented by the NT kernel - the NT kernel implements its own programming interface, which is used by the libraries and Win32 subsystem process that implement Win32.

This, arguably, even more strongly emphasizes the point that the OS isn't ipso facto the kernel, if the kernel of some system doesn't directly implement any of its API, unlike UNIX-flavored systems where at least some of the API tends to be direct system calls, even though a lot of it isn't.