16 more Win 7 "God" modes

[deadrats]

http://www.tomshardware.com/news/GodMode-Windows-7-Secret-Shortcuts,9373.html

call me paranoid but i don't like this one bit, first there were numerous confirmed reports that the NSA help microsoft with Win 7's security, now we find out about the existence of numerous "God" modes built into Win 7, one of which is somehow connected to a "location sensor", another for "install from network" and one for "firewall", i have to wonder just what else is hidden in Win 7 that we aren't being told about.

when you consider that it has long been suspected that microsoft built back doors into NT based OSes for law enforcement uses, when you consider the revelations concerning the NSA and now these special modes, i personally can't see switching to Win 7, especially when you consider that a knowledgeable hacker/virus writer could exploit these features for less than honest purposes.

i can probably talk myself into switching to 64 bit Vista (which so far doesn't seem to have any of these "God" modes) just so i can use DX Compute and DX11, but i can assure you that everything security wise would be left to non-MS, preferably open source apps, like an open source firewall and truecrypt for encryption.

edit: just discovered a sh*tload more "God" modes:

http://msdn.microsoft.com/en-us/library/ee330741%28VS.85%29.aspx

double sh*t: after reading through the list it looks like Vista has it's share of "God" modes as well, i think i'll be sticking with XP 64 for a long time, the hell with DX Compute and DX11.

[guns1inger]

What a load of paranoid drivel. Do you wear a tin foil hat so the government can't read your thoughts as well ?

All these are is a different way of presenting all the features that are already present via control panel. There is nothing new or secret about this. It is not a back door into your system. How secret is some you "discovered" by reading publicly published technical information from the vendor's site ?

If you are so mis-trusting of Microsoft, why do you use any version of Windows at all ? Or even a computer ? Certainly everything you do on the internet can be traced. Chances are, if you keep exposing all these "secrets", pretty so a black ops team will be dispatched to erase your existence.

[JohnnyMalaria]

Bravo, guns1inger.

Before I'd got half way through the opening post, I had already decided my response, namely:

There's nothing else "hidden" - all the god modes simply provide convenient access to publically declared API functions (i.e, on MSDN). I'm sure if MS didn't make it easier to access these control panel items then the OP would declare a conspiracy by MS against the poor suffering masses via deliberate obfuscation.

[deadrats]

What a load of paranoid drivel. Do you wear a tin foil hat so the government can't read your thoughts as well ?

All these are is a different way of presenting all the features that are already present via control panel. There is nothing new or secret about this. It is not a back door into your system. How secret is some you "discovered" by reading publicly published technical information from the vendor's site ?

If you are so mis-trusting of Microsoft, why do you use any version of Windows at all ? Or even a computer ? Certainly everything you do on the internet can be traced. Chances are, if you keep exposing all these "secrets", pretty so a black ops team will be dispatched to erase your existence.

to address your, let's be generous and call them "points":

1) it's not paranoia if they really are out to get you.

2) i use XP 64 because of my hobby which involves video and audio editing and the truth of the matter is that windows is the best platform for the hobbyist (note that i didn't say professional, i don't know which platform is the best for pros).

3) as for why i use a computer, in addition to the above i also use it for the more common tasks, such as email, transcontinental calls, documents, all sorts of tasks. your statements, besides being extremely, i'll be nice and call them "idiotic", are also a prime example of fallacious reasoning, a new twist of the old "she was asking for it" arguments used to dismiss a claim of impropriety, your argument amounts to "well, if you don't want your computer hacked, don't use a computer", which is stupid on a level rarely seen.

since you have shown that you are not much of an intellectual "guns1inger", i'll explain to you why this is a big deal:

it removes several layers of abstraction that a virus needs to go through in order to perform a malicious act, i don't know if you have any programming experience, i'm assuming you don't based on your obviously poorly informed statements, but the purpose of these "God" modes is, taken straight from microsoft's site:

As of Windows Vista, each Control Panel item is given a canonical name for use in programatically launching that item. This topic lists each Control Panel item, its canonical name, and its GUID.

i'm going to assume that you don't understand what you just read, the purpose of these modes is to allow a programmer to easily launch the feature associated with each mode, in other words a virus writer, instead of having to go through the hoops he needs to go through under xp to shutdown the firewall or install something over a network, can now simply invoke this shortcut from within his virus and it gives him access to that feature.

now do you see why it's such a big deal? using these modes a guy like me can take complete control of your system with about 30 lines of C code, that is a big security risk.

[deadrats]

Bravo, guns1inger.

Before I'd got half way through the opening post, I had already decided my response, namely:

There's nothing else "hidden" - all the god modes simply provide convenient access to publically declared API functions (i.e, on MSDN). I'm sure if MS didn't make it easier to access these control panel items then the OP would declare a conspiracy by MS against the poor suffering masses via deliberate obfuscation.

i was under the impression that you saw yourself as a computer programmer, i'm a bit, just a bit, surprised that you don't see the implications of these "features", perhaps you should have taken a few minutes to read through the links i provided before you decided to throw your 2 cents in:

http://msdn.microsoft.com/en-us/library/ee330741(VS.85).aspx

As of Windows Vista, each Control Panel item is given a canonical name for use in programatically launching that item. This topic lists each Control Panel item, its canonical name, and its GUID.

[ocgw]

What a load of paranoid drivel. Do you wear a tin foil hat so the government can't read your thoughts as well ?

All these are is a different way of presenting all the features that are already present via control panel. There is nothing new or secret about this. It is not a back door into your system. How secret is some you "discovered" by reading publicly published technical information from the vendor's site ?

If you are so mis-trusting of Microsoft, why do you use any version of Windows at all ? Or even a computer ? Certainly everything you do on the internet can be traced. Chances are, if you keep exposing all these "secrets", pretty so a black ops team will be dispatched to erase your existence.

to address your, let's be generous and call them "points":

1) it's not paranoia if they really are out to get you.

2) i use XP 64 because of my hobby which involves video and audio editing and the truth of the matter is that windows is the best platform for the hobbyist (note that i didn't say professional, i don't know which platform is the best for pros).

3) as for why i use a computer, in addition to the above i also use it for the more common tasks, such as email, transcontinental calls, documents, all sorts of tasks. your statements, besides being extremely, i'll be nice and call them "idiotic", are also a prime example of fallacious reasoning, a new twist of the old "she was asking for it" arguments used to dismiss a claim of impropriety, your argument amounts to "well, if you don't want your computer hacked, don't use a computer", which is stupid on a level rarely seen.

since you have shown that you are not much of an intellectual "guns1inger", i'll explain to you why this is a big deal:

it removes several layers of abstraction that a virus needs to go through in order to perform a malicious act, i don't know if you have any programming experience, i'm assuming you don't based on your obviously poorly informed statements, but the purpose of these "God" modes is, taken straight from microsoft's site:

As of Windows Vista, each Control Panel item is given a canonical name for use in programatically launching that item. This topic lists each Control Panel item, its canonical name, and its GUID.

i'm going to assume that you don't understand what you just read, the purpose of these modes is to allow a programmer to easily launch the feature associated with each mode, in other words a virus writer, instead of having to go through the hoops he needs to go through under xp to shutdown the firewall or install something over a network, can now simply invoke this shortcut from within his virus and it gives him access to that feature.

now do you see why it's such a big deal? using these modes a guy like me can take complete control of your system with about 30 lines of C code, that is a big security risk.

hmmmmmmm.................I think I would like a "guy like you" to take complete control of my system "with about 30 lines of C code", me thinks that would be a quite tasty lil' treat

mmmm, mmmm, good

yum, yummy

yeah, scrump-deli-icious

ocgw

peace

[JohnnyMalaria]

Yes, I am a programmer - specifically using Microsoft technologies that they document through MSDN. It is because of my familiarity of programming Windows that I recognize the usefulness of these apparently hidden secrets. Your commentary about security is, frankly, nonsense. The "God Mode" simply presents a dialog window with a large number of shortcuts to things that are accessible via the Windows UI anyway. Whether the links do anything still depends on the privilege level of the calling process (i.e., that of the user).

The reason that the various control panel dialogs can be opened programmatically is so that programmers like me can write software that allows users to access control panel without me having to write shed loads of code to create my own dialog. The very text you emphasize shows that you misunderstand. It is about programmatically launching a dialog box - nothing to do with performing any of the actions that the dialog shows. e.g., my software may make your life easier by being able to display the printer control panel item. Windows has done this in some form or other since 3.1.

So chill - it isn't a sinister plot (and I say that as a lefthander myself).

[fritzi93]

So chill - it isn't a sinister plot (and I say that as a lefthander myself).

I wonder how many out there will get that joke. I bet you took Latin in high school. :P

[The village idiot]

Man you would $#!+ yourself if you starting looking into all the API calls and other stuff that can be made on a Windows server 2003 or newer box. They were "prototyping" all this stuff back then. What they did makes life way easier when you have to administer the machine.

[El Heggunte]

So chill - it isn't a sinister plot (and I say that as a lefthander myself).

I wonder how many out there will get that joke. I bet you took Latin in high school. :P

Well, I did understand the joke --- which doesn't mean I found it funny, BTW.
As for he learning Latin in high school... nah, probably he learned Latin
before getting into elementary school. Seriously, I don't think he's ever been
the kind of person who expects someone else to decide what he can learn and
when he should learn.

[JohnnyMalaria]

Yup - I did take Latin but I had no choice and someone else decided I should take it.

[Safesurfer]

Yup - I did take Latin but I had no choice and someone else decided I should take it.

Amo, amas, amat.

[p_l]

Si hoc signum legere potes, operis boni in rebus Latinis alacribus et fructuosis potiri potes!

[El Heggunte]

Yup - I did take Latin but I had no choice and someone else decided I should take it.

That sucks, man! Je le regrette beaucoup.

[fritzi93]

Well, I did understand the joke --- which doesn't mean I found it funny, BTW.

Maybe you liked the "sexy boots" joke/pun better. Remember that one?

Forgive me if I tell it wrong:

I have five bootable drives, so I guess you could say I pentaboot. One more and I'll put on my sexy boots.

The pun mixes Greek *and* Latin that time. But pentaboot sounds better than quinquiboot.

Which reminds me of a favorite quote from "Master and Commander": "He who would pun would pick a pocket." :P

[hunter99]

Looks like MS can't keep a secret.

[deadrats]

Yes, I am a programmer - specifically using Microsoft technologies that they document through MSDN. It is because of my familiarity of programming Windows that I recognize the usefulness of these apparently hidden secrets. Your commentary about security is, frankly, nonsense. The "God Mode" simply presents a dialog window with a large number of shortcuts to things that are accessible via the Windows UI anyway. Whether the links do anything still depends on the privilege level of the calling process (i.e., that of the user).

The reason that the various control panel dialogs can be opened programmatically is so that programmers like me can write software that allows users to access control panel without me having to write shed loads of code to create my own dialog. The very text you emphasize shows that you misunderstand. It is about programmatically launching a dialog box - nothing to do with performing any of the actions that the dialog shows. e.g., my software may make your life easier by being able to display the printer control panel item. Windows has done this in some form or other since 3.1.

So chill - it isn't a sinister plot (and I say that as a lefthander myself).

i may need to chill, but i think you need to look a bit deeper into the workings of the Win 7 api:

http://msdn.microsoft.com/en-us/library/dd562324%28VS.85%29.aspx

New APIs in the Windows 7 Shell

This document lists reference topics that have been added for the Windows 7 release. These documents are entirely new. Some older material not listed here also contains new Windows 7-specific content, such as new enumeration, constant, and flag values.

and pay close attention to "IExecuteCommand", i'll let you look into the details for yourself, but i trust you will conclude it allows a programmer to do quite a bit more than "just launch a dialog box", you could do that with VB, no need to build this functionality into the windows shell.

in so far as the commentary about privilege levels, the truth of the matter is that almost all windows based pc's run with admin privileges, how many people actually run a windows box in a restricted user mode?

seriously, read through the new additions to the win 7 api and honestly tell me you can't see yourself writing a short program that can shut down the built in firewall and remote install software without the user's knowledge.

[JohnnyMalaria]

i may need to chill, but i think you need to look a bit deeper into the workings of the Win 7 api:

http://msdn.microsoft.com/en-us/library/dd562324%28VS.85%29.aspx

New APIs in the Windows 7 Shell

This document lists reference topics that have been added for the Windows 7 release. These documents are entirely new. Some older material not listed here also contains new Windows 7-specific content, such as new enumeration, constant, and flag values.

and pay close attention to "IExecuteCommand", i'll let you look into the details for yourself, but i trust you will conclude it allows a programmer to do quite a bit more than "just launch a dialog box", you could do that with VB, no need to build this functionality into the windows shell.

in so far as the commentary about privilege levels, the truth of the matter is that almost all windows based pc's run with admin privileges, how many people actually run a windows box in a restricted user mode?

seriously, read through the new additions to the win 7 api and honestly tell me you can't see yourself writing a short program that can shut down the built in firewall and remote install software without the user's knowledge.

Geez, Louise. This is a COM interface that provides an application with a callback mechanism to respond to user input. A simple example would be a button. Conventionally, the WIN32 API is used and requires manual programming of an event (message) loop. The IExecuteCommand fires an event to the host using COM. This makes it much easier to program and makes the code much more portable. Security-wise, it is absolutely no different than the traditional WIN32 message loop. All it is is a means for Windows to say to a program "hey, the user clicked something". And, for the record, having admin rights doesn't grant full privileges. There are some that only the system can have.

[lordsmurf]

"God mode" --- what a ridiculous name --- clearly a term created by somebody who plays far too many video games. oh no, the big scary "God mode" --- oooo .. boogey boogey!

[ZQX]

"God mode" --- what a ridiculous name --- clearly a term created by somebody who plays far too many video games. oh no, the big scary "God mode" --- oooo .. boogey boogey!

Geez you crack me up sometimes Lordsmurf

[deadrats]

Geez, Louise. This is a COM interface that provides an application with a callback mechanism to respond to user input. A simple example would be a button. Conventionally, the WIN32 API is used and requires manual programming of an event (message) loop. The IExecuteCommand fires an event to the host using COM. This makes it much easier to program and makes the code much more portable. Security-wise, it is absolutely no different than the traditional WIN32 message loop. All it is is a means for Windows to say to a program "hey, the user clicked something". And, for the record, having admin rights doesn't grant full privileges. There are some that only the system can have.

woah, what's with the profanity? "Geez, Louise"?!? i think the admin's need to put a stop to your potty mouth right now, next thing we know you'll be taking the name of Gandhi in vain, and we just can't have that gosh darn it, all to heck!!!

seriously though, i have to congratulate you on doing a decent job of obfuscating the issue at hand, you actually made me download the win 7 sdk and pour through the documentation and code examples for proof that i am right, so for that give yourself a pat on the back.

are you done? good, now feast your eyes on this:

http://msdn.microsoft.com/en-us/library/aa366431%28VS.85%29.aspx

if you look through the documentation you'll see that microsoft added a slew of new abilities to the win 7 api, and i personally don't think they are a good thing, the "God" modes listed could be viewed as just a nice simple way of presenting to the user a central location where already present tools can easily be accessed, reading through all the documentation, and the example source code available, confirmed my suspicions, the "engine" that drives these "God" modes are additions to the win 7 api that perhaps may have been intentioned as a way for programmers to be able to add a dialog box to their apps in a simple way, but something has to back their simplicity, here is a code snippet that allows a programmer to disable the win 7 firewall using vb script:

*************************************************
Option Explicit

'Set Constants
Const NET_FW_PROFILE_DOMAIN = 0
Const NET_FW_PROFILE_STANDARD = 1

'Declare variables
' Create the firewall manager object.
Dim fwMgr
Set fwMgr = CreateObject("HNetCfg.FwMgr")

' Get the current profile for the local firewall policy.
Dim profile
set profile = fwMgr.LocalPolicy.GetProfileByType(NET_FW_PROFILE_ STANDARD)

profile.IcmpSettings.AllowInboundEchoRequest = TRUE

'Use this line if you want to disable the setting.
'profile.IcmpSettings.AllowInboundEchoRequest = FALSE
*************************************************

here's a complete example of how to do the following in C/C++:

http://msdn.microsoft.com/en-us/library/aa364726%28VS.85%29.aspx

The following code example exercises the Windows Firewall profile; displays the current profile, turns off the firewall, turns on the firewall, and adds an application.

*******************************************
/*
Copyright (c) Microsoft Corporation

SYNOPSIS

Sample code for the Windows Firewall COM interface.
*/

#include <windows.h>
#include <crtdbg.h>
#include <netfw.h>
#include <objbase.h>
#include[list=1]
#include <stdio.h>

#pragma comment( lib, "ole32.lib" )
#pragma comment( lib, "oleaut32.lib" )


HRESULT WindowsFirewallInitialize(OUT INetFwProfile** fwProfile)
{
HRESULT hr = S_OK;
INetFwMgr* fwMgr = NULL;
INetFwPolicy* fwPolicy = NULL;

_ASSERT(fwProfile != NULL);

*fwProfile = NULL;

// Create an instance of the firewall settings manager.
hr = CoCreateInstance(
__uuidof(NetFwMgr),
NULL,
CLSCTX_INPROC_SERVER,
__uuidof(INetFwMgr),
(void**)&fwMgr
);
if (FAILED(hr))
{
printf("CoCreateInstance failed: 0x%08lx\n", hr);
goto error;
}

// Retrieve the local firewall policy.
hr = fwMgr->get_LocalPolicy(&fwPolicy);
if (FAILED(hr))
{
printf("get_LocalPolicy failed: 0x%08lx\n", hr);
goto error;
}

// Retrieve the firewall profile currently in effect.
hr = fwPolicy->get_CurrentProfile(fwProfile);
if (FAILED(hr))
{
printf("get_CurrentProfile failed: 0x%08lx\n", hr);
goto error;
}

error:

// Release the local firewall policy.
if (fwPolicy != NULL)
{
fwPolicy->Release();
}

// Release the firewall settings manager.
if (fwMgr != NULL)
{
fwMgr->Release();
}

return hr;
}


void WindowsFirewallCleanup(IN INetFwProfile* fwProfile)
{
// Release the firewall profile.
if (fwProfile != NULL)
{
fwProfile->Release();
}
}


HRESULT WindowsFirewallIsOn(IN INetFwProfile* fwProfile, OUT BOOL* fwOn)
{
HRESULT hr = S_OK;
VARIANT_BOOL fwEnabled;

_ASSERT(fwProfile != NULL);
_ASSERT(fwOn != NULL);

*fwOn = FALSE;

// Get the current state of the firewall.
hr = fwProfile->get_FirewallEnabled(&fwEnabled);
if (FAILED(hr))
{
printf("get_FirewallEnabled failed: 0x%08lx\n", hr);
goto error;
}

// Check to see if the firewall is on.
if (fwEnabled != VARIANT_FALSE)
{
*fwOn = TRUE;
printf("The firewall is on.\n");
}
else
{
printf("The firewall is off.\n");
}

error:

return hr;
}


HRESULT WindowsFirewallTurnOn(IN INetFwProfile* fwProfile)
{
HRESULT hr = S_OK;
BOOL fwOn;

_ASSERT(fwProfile != NULL);

// Check to see if the firewall is off.
hr = WindowsFirewallIsOn(fwProfile, &fwOn);
if (FAILED(hr))
{
printf("WindowsFirewallIsOn failed: 0x%08lx\n", hr);
goto error;
}

// If it is, turn it on.
if (!fwOn)
{
// Turn the firewall on.
hr = fwProfile->put_FirewallEnabled(VARIANT_TRUE);
if (FAILED(hr))
{
printf("put_FirewallEnabled failed: 0x%08lx\n", hr);
goto error;
}

printf("The firewall is now on.\n");
}

error:

return hr;
}


HRESULT WindowsFirewallTurnOff(IN INetFwProfile* fwProfile)
{
HRESULT hr = S_OK;
BOOL fwOn;

_ASSERT(fwProfile != NULL);

// Check to see if the firewall is on.
hr = WindowsFirewallIsOn(fwProfile, &fwOn);
if (FAILED(hr))
{
printf("WindowsFirewallIsOn failed: 0x%08lx\n", hr);
goto error;
}

// If it is, turn it off.
if (fwOn)
{
// Turn the firewall off.
hr = fwProfile->put_FirewallEnabled(VARIANT_FALSE);
if (FAILED(hr))
{
printf("put_FirewallEnabled failed: 0x%08lx\n", hr);
goto error;
}

printf("The firewall is now off.\n");
}

error:

return hr;
}


HRESULT WindowsFirewallAppIsEnabled(
IN INetFwProfile* fwProfile,
IN const wchar_t* fwProcessImageFileName,
OUT BOOL* fwAppEnabled
)
{
HRESULT hr = S_OK;
BSTR fwBstrProcessImageFileName = NULL;
VARIANT_BOOL fwEnabled;
INetFwAuthorizedApplication* fwApp = NULL;
INetFwAuthorizedApplications* fwApps = NULL;

_ASSERT(fwProfile != NULL);
_ASSERT(fwProcessImageFileName != NULL);
_ASSERT(fwAppEnabled != NULL);

*fwAppEnabled = FALSE;

// Retrieve the authorized application collection.
hr = fwProfile->get_AuthorizedApplications(&fwApps);
if (FAILED(hr))
{
printf("get_AuthorizedApplications failed: 0x%08lx\n", hr);
goto error;
}

// Allocate a BSTR for the process image file name.
fwBstrProcessImageFileName = SysAllocString(fwProcessImageFileName);
if (fwBstrProcessImageFileName == NULL)
{
hr = E_OUTOFMEMORY;
printf("SysAllocString failed: 0x%08lx\n", hr);
goto error;
}

// Attempt to retrieve the authorized application.
hr = fwApps->Item(fwBstrProcessImageFileName, &fwApp);
if (SUCCEEDED(hr))
{
// Find out if the authorized application is enabled.
hr = fwApp->get_Enabled(&fwEnabled);
if (FAILED(hr))
{
printf("get_Enabled failed: 0x%08lx\n", hr);
goto error;
}

if (fwEnabled != VARIANT_FALSE)
{
// The authorized application is enabled.
*fwAppEnabled = TRUE;

printf(
"Authorized application %lS is enabled in the firewall.\n",
fwProcessImageFileName
);
}
else
{
printf(
"Authorized application %lS is disabled in the firewall.\n",
fwProcessImageFileName
);
}
}
else
{
// The authorized application was not in the collection.
hr = S_OK;

printf(
"Authorized application %lS is disabled in the firewall.\n",
fwProcessImageFileName
);
}

error:

// Free the BSTR.
SysFreeString(fwBstrProcessImageFileName);

// Release the authorized application instance.
if (fwApp != NULL)
{
fwApp->Release();
}

// Release the authorized application collection.
if (fwApps != NULL)
{
fwApps->Release();
}

return hr;
}


HRESULT WindowsFirewallAddApp(
IN INetFwProfile* fwProfile,
IN const wchar_t* fwProcessImageFileName,
IN const wchar_t* fwName
)
{
HRESULT hr = S_OK;
BOOL fwAppEnabled;
BSTR fwBstrName = NULL;
BSTR fwBstrProcessImageFileName = NULL;
INetFwAuthorizedApplication* fwApp = NULL;
INetFwAuthorizedApplications* fwApps = NULL;

_ASSERT(fwProfile != NULL);
_ASSERT(fwProcessImageFileName != NULL);
_ASSERT(fwName != NULL);

// First check to see if the application is already authorized.
hr = WindowsFirewallAppIsEnabled(
fwProfile,
fwProcessImageFileName,
&fwAppEnabled
);
if (FAILED(hr))
{
printf("WindowsFirewallAppIsEnabled failed: 0x%08lx\n", hr);
goto error;
}

// Only add the application if it isn't already authorized.
if (!fwAppEnabled)
{
// Retrieve the authorized application collection.
hr = fwProfile->get_AuthorizedApplications(&fwApps);
if (FAILED(hr))
{
printf("get_AuthorizedApplications failed: 0x%08lx\n", hr);
goto error;
}

// Create an instance of an authorized application.
hr = CoCreateInstance(
__uuidof(NetFwAuthorizedApplication),
NULL,
CLSCTX_INPROC_SERVER,
__uuidof(INetFwAuthorizedApplication),
(void**)&fwApp
);
if (FAILED(hr))
{
printf("CoCreateInstance failed: 0x%08lx\n", hr);
goto error;
}

// Allocate a BSTR for the process image file name.
fwBstrProcessImageFileName = SysAllocString(fwProcessImageFileName);
if (fwBstrProcessImageFileName == NULL)
{
hr = E_OUTOFMEMORY;
printf("SysAllocString failed: 0x%08lx\n", hr);
goto error;
}

// Set the process image file name.
hr = fwApp->put_ProcessImageFileName(fwBstrProcessImageFileNa me);
if (FAILED(hr))
{
printf("put_ProcessImageFileName failed: 0x%08lx\n", hr);
goto error;
}

// Allocate a BSTR for the application friendly name.
fwBstrName = SysAllocString(fwName);
if (SysStringLen(fwBstrName) == 0)
{
hr = E_OUTOFMEMORY;
printf("SysAllocString failed: 0x%08lx\n", hr);
goto error;
}

// Set the application friendly name.
hr = fwApp->put_Name(fwBstrName);
if (FAILED(hr))
{
printf("put_Name failed: 0x%08lx\n", hr);
goto error;
}

// Add the application to the collection.
hr = fwApps->Add(fwApp);
if (FAILED(hr))
{
printf("Add failed: 0x%08lx\n", hr);
goto error;
}

printf(
"Authorized application %lS is now enabled in the firewall.\n",
fwProcessImageFileName
);
}

error:

// Free the BSTRs.
SysFreeString(fwBstrName);
SysFreeString(fwBstrProcessImageFileName);

// Release the authorized application instance.
if (fwApp != NULL)
{
fwApp->Release();
}

// Release the authorized application collection.
if (fwApps != NULL)
{
fwApps->Release();
}

return hr;
}


HRESULT WindowsFirewallPortIsEnabled(
IN INetFwProfile* fwProfile,
IN LONG portNumber,
IN NET_FW_IP_PROTOCOL ipProtocol,
OUT BOOL* fwPortEnabled
)
{
HRESULT hr = S_OK;
VARIANT_BOOL fwEnabled;
INetFwOpenPort* fwOpenPort = NULL;
INetFwOpenPorts* fwOpenPorts = NULL;

_ASSERT(fwProfile != NULL);
_ASSERT(fwPortEnabled != NULL);

*fwPortEnabled = FALSE;

// Retrieve the globally open ports collection.
hr = fwProfile->get_GloballyOpenPorts(&fwOpenPorts);
if (FAILED(hr))
{
printf("get_GloballyOpenPorts failed: 0x%08lx\n", hr);
goto error;
}

// Attempt to retrieve the globally open port.
hr = fwOpenPorts->Item(portNumber, ipProtocol, &fwOpenPort);
if (SUCCEEDED(hr))
{
// Find out if the globally open port is enabled.
hr = fwOpenPort->get_Enabled(&fwEnabled);
if (FAILED(hr))
{
printf("get_Enabled failed: 0x%08lx\n", hr);
goto error;
}

if (fwEnabled != VARIANT_FALSE)
{
// The globally open port is enabled.
*fwPortEnabled = TRUE;

printf("Port %ld is open in the firewall.\n", portNumber);
}
else
{
printf("Port %ld is not open in the firewall.\n", portNumber);
}
}
else
{
// The globally open port was not in the collection.
hr = S_OK;

printf("Port %ld is not open in the firewall.\n", portNumber);
}

error:

// Release the globally open port.
if (fwOpenPort != NULL)
{
fwOpenPort->Release();
}

// Release the globally open ports collection.
if (fwOpenPorts != NULL)
{
fwOpenPorts->Release();
}

return hr;
}


HRESULT WindowsFirewallPortAdd(
IN INetFwProfile* fwProfile,
IN LONG portNumber,
IN NET_FW_IP_PROTOCOL ipProtocol,
IN const wchar_t* name
)
{
HRESULT hr = S_OK;
BOOL fwPortEnabled;
BSTR fwBstrName = NULL;
INetFwOpenPort* fwOpenPort = NULL;
INetFwOpenPorts* fwOpenPorts = NULL;

_ASSERT(fwProfile != NULL);
_ASSERT(name != NULL);

// First check to see if the port is already added.
hr = WindowsFirewallPortIsEnabled(
fwProfile,
portNumber,
ipProtocol,
&fwPortEnabled
);
if (FAILED(hr))
{
printf("WindowsFirewallPortIsEnabled failed: 0x%08lx\n", hr);
goto error;
}

// Only add the port if it isn't already added.
if (!fwPortEnabled)
{
// Retrieve the collection of globally open ports.
hr = fwProfile->get_GloballyOpenPorts(&fwOpenPorts);
if (FAILED(hr))
{
printf("get_GloballyOpenPorts failed: 0x%08lx\n", hr);
goto error;
}

// Create an instance of an open port.
hr = CoCreateInstance(
__uuidof(NetFwOpenPort),
NULL,
CLSCTX_INPROC_SERVER,
__uuidof(INetFwOpenPort),
(void**)&fwOpenPort
);
if (FAILED(hr))
{
printf("CoCreateInstance failed: 0x%08lx\n", hr);
goto error;
}

// Set the port number.
hr = fwOpenPort->put_Port(portNumber);
if (FAILED(hr))
{
printf("put_Port failed: 0x%08lx\n", hr);
goto error;
}

// Set the IP protocol.
hr = fwOpenPort->put_Protocol(ipProtocol);
if (FAILED(hr))
{
printf("put_Protocol failed: 0x%08lx\n", hr);
goto error;
}

// Allocate a BSTR for the friendly name of the port.
fwBstrName = SysAllocString(name);
if (SysStringLen(fwBstrName) == 0)
{
hr = E_OUTOFMEMORY;
printf("SysAllocString failed: 0x%08lx\n", hr);
goto error;
}

// Set the friendly name of the port.
hr = fwOpenPort->put_Name(fwBstrName);
if (FAILED(hr))
{
printf("put_Name failed: 0x%08lx\n", hr);
goto error;
}

// Opens the port and adds it to the collection.
hr = fwOpenPorts->Add(fwOpenPort);
if (FAILED(hr))
{
printf("Add failed: 0x%08lx\n", hr);
goto error;
}

printf("Port %ld is now open in the firewall.\n", portNumber);
}

error:

// Free the BSTR.
SysFreeString(fwBstrName);

// Release the open port instance.
if (fwOpenPort != NULL)
{
fwOpenPort->Release();
}

// Release the globally open ports collection.
if (fwOpenPorts != NULL)
{
fwOpenPorts->Release();
}

return hr;
}


int __cdecl wmain(int argc, wchar_t* argv[])
{
HRESULT hr = S_OK;
HRESULT comInit = E_FAIL;
INetFwProfile* fwProfile = NULL;

// Initialize COM.
comInit = CoInitializeEx(
0,
COINIT_APARTMENTTHREADED | COINIT_DISABLE_OLE1DDE
);

// Ignore RPC_E_CHANGED_MODE; this just means that COM has already been
// initialized with a different mode. Since we don't care what the mode is,
// we'll just use the existing mode.
if (comInit != RPC_E_CHANGED_MODE)
{
hr = comInit;
if (FAILED(hr))
{
printf("CoInitializeEx failed: 0x%08lx\n", hr);
goto error;
}
}

// Retrieve the firewall profile currently in effect.
hr = WindowsFirewallInitialize(&fwProfile);
if (FAILED(hr))
{
printf("WindowsFirewallInitialize failed: 0x%08lx\n", hr);
goto error;
}

// Turn off the firewall.
hr = WindowsFirewallTurnOff(fwProfile);
if (FAILED(hr))
{
printf("WindowsFirewallTurnOff failed: 0x%08lx\n", hr);
goto error;
}

// Turn on the firewall.
hr = WindowsFirewallTurnOn(fwProfile);
if (FAILED(hr))
{
printf("WindowsFirewallTurnOn failed: 0x%08lx\n", hr);
goto error;
}

// Add Windows Messenger to the authorized application collection.
hr = WindowsFirewallAddApp(
fwProfile,
L"%ProgramFiles%\\Messenger\\msmsgs.exe",
L"Windows Messenger"
);
if (FAILED(hr))
{
printf("WindowsFirewallAddApp failed: 0x%08lx\n", hr);
goto error;
}

// Add TCP::80 to list of globally open ports.
hr = WindowsFirewallPortAdd(fwProfile, 80, NET_FW_IP_PROTOCOL_TCP, L"WWW");
if (FAILED(hr))
{
printf("WindowsFirewallPortAdd failed: 0x%08lx\n", hr);
goto error;
}

error:

// Release the firewall profile.
WindowsFirewallCleanup(fwProfile);

// Uninitialize COM.
if (SUCCEEDED(comInit))
{
CoUninitialize();
}

return 0;
}
*******************************************

now granted it's not the 30 lines of code that i claimed it would take, but i don't see how anyone can't find it alarming that microsoft decided that it would add a feature to the win 7 api that allows a programmer, from within his app, to turn off the built in firewall without authorization of the user.

i haven't looked through all the other new features but i for one think this represents a major security risk, especially in light of the revamped UAC.

[p_l]

[deadrats]

@p_l

ROTFLMAO!!!

[ricoman]

Si hoc signum legere potes, operis boni in rebus Latinis alacribus et fructuosis potiri potes!

I inkthay atthay I'm ettinggay a eadachehay! :P

[The village idiot]

I think you need a new aluminum foil beanie, here's a VBscript to disable the firewall for XP, it's been around for some length of time:
http://technet.microsoft.com/en-us/library/ee692641.aspx

Looks like you could do it with about 4 or 5 lines of script. And I'm certain you can find script to download and install an application and do it silently. You can make activeX controls do the same things too.Anything you can do in VBscript can be done in C or assembly, or half a dozen other languages.

[The village idiot]

I was wrong, only three lines:
http://www.kayodeok.co.uk/weblog/200405/09/disable_xp_firewall.html

[TJohns]

... http://technet.microsoft.com/en-us/library/ee692641.aspx ...

Gee, the first line of that article states

This script disables Windows Firewall by setting the FirewallEnabled property to False. This may be necessary if another firewall is already in use on the network.

I take that to mean all this coding can ONLY affect Windows own firewall ... use a third party product and gosh, the Windows firewall if off, but I wasn't using it anyway!

Trev

[deadrats]

I think you need a new aluminum foil beanie, here's a VBscript to disable the firewall for XP, it's been around for some length of time:
http://technet.microsoft.com/en-us/library/ee692641.aspx

Looks like you could do it with about 4 or 5 lines of script. And I'm certain you can find script to download and install an application and do it silently. You can make activeX controls do the same things too.Anything you can do in VBscript can be done in C or assembly, or half a dozen other languages.

are you trying to live up to your screen name or is it just a pleasant by-product of not knowing wtf you are talking about? just curious.

allow me to address the first inaccurate point you made, just because you can do something using vb script doesn't automatically mean that you can do it using C, Assembler, Pascal, Java or even VB, or at the very least it doesn't mean you can do it easily.

the second mistake you made is the use of the two scripts, the script you linked to is used in a very different way than what i linked to, take note of this part:

http://technet.microsoft.com/en-us/library/ee692641.aspx

To use the script, copy the code, paste it into Notepad, and then save the script as FwDisable.vbs. To run the script, open a command prompt window to the directory of the script and type:

cscript fwdisable.vbs

what you linked to is a true script and you can stop vb scripts dead in their tracks on a windows pc:

http://www.sophos.com/support/knowledgebase/article/10359.html

and any vb script, no matter what it's designed to do, won't run.

what microsoft has effectively done is give a programmer the ability to by-pass this security feature, if you look at the 2 scripts, the one you linked to relies on the scripting host for execution and is structured like a batch file, the code i linked to is meant to be used within VB as part of a program not as a stand alone script (i know it's listed under vb script, look at the structure between the 2 code samples, very different uses for each).

furthermore, as i already pointed out, since microsoft has added this functionality to the win 7 api, it is now possible to do the same thing within a C/C++ program, if it appears that i am paranoid and in need of a new tin foil hat it's because i have a pretty solid programming background and understand the implications of the changes made to the win 7 api.

evidently i am the only one participating in this thread that can make that statement.

[deadrats]

I take that to mean all this coding can ONLY affect Windows own firewall ... use a third party product and gosh, the Windows firewall if off, but I wasn't using it anyway!

you are correct, it does only affect the windows firewall but that was used only as an example, basically microsoft has added functionality to the win 7 api that while it may have legit uses also opens up numerous avenues for attack for someone that wants to code malware.

now it true, a knowledgeable person can disable the windows built in firewall and use a third party firewall, but that doesn't do you much good when you can access the remote access service by calling the appropriate dll:

http://msdn.microsoft.com/en-us/library/aa374506%28VS.85%29.aspx

this is just an example, if you look through the links i posted, it's like the other poster said, if you look through the win 7 api it will make you want to sh*t when you see what a programmer can do with the interfaces microsoft built into windows.

[JohnnyMalaria]

now granted it's not the 30 lines of code that i claimed it would take, but i don't see how anyone can't find it alarming that microsoft decided that it would add a feature to the win 7 api that allows a programmer, from within his app, to turn off the built in firewall without authorization of the user.

i haven't looked through all the other new features but i for one think this represents a major security risk, especially in light of the revamped UAC.

Blindly copying and pasting something that you clearly do not comprehend means nothing. I dare to presume you have not written a COM-based WIN32 application in Visual C++. If you read the associated MSDN content (i.e., to put it in context) then you will see that programmatic access to the Windows Firewall API has been around since XP and that "[a]ll users may read the configuration settings. However, Administrator privileges are required to change Windows Firewall configuration settings." If you run with admin privileges then caveat emptor.

The add security risks that you claim are wholly bogus. But then again you cannot reason with fearmongering.