Get MAC address
in [Win32 Kernel]
|
Prev: Win64 , InterlockedCompareExchange128 and early AMDs
Next: Retrieving the filesystem name of each partition not mounted
From: Anton Bassov on 12 Feb 2007 17:06 Arkady, > I don't think that it's a problem for MSFT to decline that already in > DeviceIoControl() in user mode or > before extract/send OID in kernel mode *THEORETICALLY* doing things this way is feasible. However, look at the whole thing in practical terms. Both user-mode DeviceIoControl() and actual kernel-mode implementation of ZwDeviceIoControlFile() are meant to be used for sending*ANY* IOCTL to *ANY* device that registers a symbolic link. I hope you can imagine what it is like to watch and block some certain IOCTLs that get sent to some certain (unknown at compile-time) devices that get sent by callers that don't meet some certain criteria...... The best thing to do here is just to make NdisMRegisterDevice() ignore the symbolic name string argument - if they do it this way, only kernel-mode components will be able to send IOCTLs to miniports. However, I am not sure they want to do it either - probably, some MSFT-written stuff (netstat, Wisock,etc) sends IOCTLs to miniports from the user mode.... Anton Bassov "Arkady Frenkel" wrote: > Anton! > > "Anton Bassov" <AntonBassov(a)discussions.microsoft.com> wrote in message > news:79D44CFC-A70F-4349-9F8C-F5A916380E39(a)microsoft.com... > > Arkady, > > > >> Obviously that should work even on Vista, but MSFT for years warning > >> about > >> near deprecation of IOCTL_NDIS_QUERY_GLOBAL_STATS for security > >> reasons. > > > > Well, taking into consideration the fact that it is miniport driver and > > not > > TCPIP.SYS who handles this request (which is optional anyway), as well as > > the > > one that this IOCTL gets submitted to the standalone device that is not on > > any stack, there is not that much that they can do about it, apart from > > removing NdisMRegisterDevice(), i.e. dropping the support for standalone > > devices. I don't think they want to go that far.... > > > I don't think that it's a problem for MSFT to decline that already in > DeviceIoControl() in user mode or > before extract/send OID in kernel mode > Arkady > > >> OTOH that give option to check MAC on local host only ( in addition to > >> GetIfTable()/GetIfEntry and GetAdaptersInfo )and that no what OP mean if > >> I > >> understood him correctly. > > > > The way I understood it, the OP was asking about the local host. Maybe I > > just got it wrong..... > > > > Anton Bassov > > > > > > "Arkady Frenkel" wrote: > > > >> Obviously that should work even on Vista, but MSFT for years warning > >> about > >> near deprecation of IOCTL_NDIS_QUERY_GLOBAL_STATS for security > >> reasons. > >> OTOH that give option to check MAC on local host only ( in addition to > >> GetIfTable()/GetIfEntry and GetAdaptersInfo )and that no what OP mean if > >> I > >> understood him correctly. > >> In that case in addition to Netbios ( may not work if it disabled ) and > >> SendARP() possible to use WMI's MACAddress property of > >> Win32_NetworkAdapter > >> interface . > >> > >> Arkady > >> > >> "Anton Bassov" <AntonBassov(a)discussions.microsoft.com> wrote in message > >> news:634A9F45-589A-410B-A3B2-A0651F90A19E(a)microsoft.com... > >> >I would rather open a handle to the target adapter with CreateFile(), > >> >and > >> >then > >> > send OID_XXX_PERMANENT_ADDRESS request to it with > >> > IOCTL_NDIS_QUERY_GLOBAL_STATS ..... > >> > > >> > Names of all adapters TCPIP is bound to (i.e. the ones that can be > >> > passed > >> > to > >> > CreateFile() call) can be found under > >> > HKLM \\SYSTEM\\CurrentControlSet\\Services\\Tcpip\\Parameters\\Adapters > >> > key in the registry. First I would send OID_GEN_SUPPORTED_LIST request > >> > in > >> > order to find all OIDs that adapter supports, and locate > >> > OID_XXX_PERMANENT_ADDRESS > >> > ( OID!= OID_GEN_SUPPORTED_LIST && OID&0xffffff== > >> > OID_GEN_SUPPORTED_LIST). > >> > At this point I would be able to send OID_XXX_PERMANENT_ADDRESS, and > >> > obtain > >> > the sought info.... > >> > > >> > Anton Bassov > >> > > >> > "Andrew Chalk" wrote: > >> > > >> >> Is there a SDK or Platform API call that will return the MAC > >> >> address(es) > >> >> in > >> >> a host? > >> >> > >> >> Many thanks. > >> >> > >> >> > >> >> > >> > >> > >> > > >
From: Arkady Frenkel on 13 Feb 2007 03:26 Anton! "Anton Bassov" <AntonBassov(a)discussions.microsoft.com> wrote in message news:11D2755D-6CB3-4FE3-9D41-993CB084CBBF(a)microsoft.com... > Arkady, > >> I don't think that it's a problem for MSFT to decline that already in >> DeviceIoControl() in user mode or >> before extract/send OID in kernel mode > > *THEORETICALLY* doing things this way is feasible. However, look at the > whole thing in practical terms. Both user-mode DeviceIoControl() and > actual > kernel-mode implementation of ZwDeviceIoControlFile() are meant to be used > for sending*ANY* IOCTL to *ANY* device that registers a symbolic link. I > hope > you can imagine what it is like to watch and block some certain IOCTLs > that > get sent to some certain > (unknown at compile-time) devices that get sent by callers that don't meet > some certain criteria...... > Not exactly, hee we talk about specific IOCTL without any connection to device at all , OTOH any case DACL of user checked in anycase to allow/deny access to device. So there is no problem where to check that. > > > The best thing to do here is just to make NdisMRegisterDevice() ignore the > symbolic name string argument - if they do it this way, only kernel-mode > components will be able to send IOCTLs to miniports. However, I am not > sure > they want to do it either - probably, some MSFT-written stuff (netstat, > Wisock,etc) sends IOCTLs to miniports from the user mode.... > No, the idea that user have to use WMI which have it's own kernel driver to send OIDs to NDIS when it receive IOCTLs from user part of WMI. AFAIK nor netstat ( due to Russinoch's netstatp already disappeared when site moved to Msft :( ), not winsock send IOCTLs directly to miniport, but winsock talk ( with IOCTL ) through LSP, WSH to tcpip.sys for info, not for data interchange , that use msafd.dll/afd.sys/tdi.sys path before tcpip.sys. Arkady > Anton Bassov > > "Arkady Frenkel" wrote: > >> Anton! >> >> "Anton Bassov" <AntonBassov(a)discussions.microsoft.com> wrote in message >> news:79D44CFC-A70F-4349-9F8C-F5A916380E39(a)microsoft.com... >> > Arkady, >> > >> >> Obviously that should work even on Vista, but MSFT for years warning >> >> about >> >> near deprecation of IOCTL_NDIS_QUERY_GLOBAL_STATS for security >> >> reasons. >> > >> > Well, taking into consideration the fact that it is miniport driver and >> > not >> > TCPIP.SYS who handles this request (which is optional anyway), as well >> > as >> > the >> > one that this IOCTL gets submitted to the standalone device that is not >> > on >> > any stack, there is not that much that they can do about it, apart from >> > removing NdisMRegisterDevice(), i.e. dropping the support for >> > standalone >> > devices. I don't think they want to go that far.... >> > >> I don't think that it's a problem for MSFT to decline that already in >> DeviceIoControl() in user mode or >> before extract/send OID in kernel mode >> Arkady >> >> >> OTOH that give option to check MAC on local host only ( in addition to >> >> GetIfTable()/GetIfEntry and GetAdaptersInfo )and that no what OP mean >> >> if >> >> I >> >> understood him correctly. >> > >> > The way I understood it, the OP was asking about the local host. Maybe >> > I >> > just got it wrong..... >> > >> > Anton Bassov >> > >> > >> > "Arkady Frenkel" wrote: >> > >> >> Obviously that should work even on Vista, but MSFT for years warning >> >> about >> >> near deprecation of IOCTL_NDIS_QUERY_GLOBAL_STATS for security >> >> reasons. >> >> OTOH that give option to check MAC on local host only ( in addition to >> >> GetIfTable()/GetIfEntry and GetAdaptersInfo )and that no what OP mean >> >> if >> >> I >> >> understood him correctly. >> >> In that case in addition to Netbios ( may not work if it disabled ) >> >> and >> >> SendARP() possible to use WMI's MACAddress property of >> >> Win32_NetworkAdapter >> >> interface . >> >> >> >> Arkady >> >> >> >> "Anton Bassov" <AntonBassov(a)discussions.microsoft.com> wrote in >> >> message >> >> news:634A9F45-589A-410B-A3B2-A0651F90A19E(a)microsoft.com... >> >> >I would rather open a handle to the target adapter with CreateFile(), >> >> >and >> >> >then >> >> > send OID_XXX_PERMANENT_ADDRESS request to it with >> >> > IOCTL_NDIS_QUERY_GLOBAL_STATS ..... >> >> > >> >> > Names of all adapters TCPIP is bound to (i.e. the ones that can be >> >> > passed >> >> > to >> >> > CreateFile() call) can be found under >> >> > HKLM >> >> > \\SYSTEM\\CurrentControlSet\\Services\\Tcpip\\Parameters\\Adapters >> >> > key in the registry. First I would send OID_GEN_SUPPORTED_LIST >> >> > request >> >> > in >> >> > order to find all OIDs that adapter supports, and locate >> >> > OID_XXX_PERMANENT_ADDRESS >> >> > ( OID!= OID_GEN_SUPPORTED_LIST && OID&0xffffff== >> >> > OID_GEN_SUPPORTED_LIST). >> >> > At this point I would be able to send OID_XXX_PERMANENT_ADDRESS, and >> >> > obtain >> >> > the sought info.... >> >> > >> >> > Anton Bassov >> >> > >> >> > "Andrew Chalk" wrote: >> >> > >> >> >> Is there a SDK or Platform API call that will return the MAC >> >> >> address(es) >> >> >> in >> >> >> a host? >> >> >> >> >> >> Many thanks. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >>
From: Anton Bassov on 13 Feb 2007 04:35 Arkady, > Not exactly, hee we talk about specific IOCTL without any connection to > device at all.... IOCTL in itself is nothing more than just a DWORD value. What if some totally unrelated driver,particularly third-party one, accepts IOCTL that is numerically equal to IOCTL_NDIS_QUERY_GLOBAL_STATS??? Are we going to block it as well??? Therefore, no matter how you look at it, you have to relate IOCTLs to their target devices > OTOH any case DACL of user checked in anycase to allow/deny > access to device. So there is no problem where to check that. Well, DACL check is done when you open a handle - once you have it, no more access checks are made. In any case, as far as admin accounts are concerned, DACL check is not a solution - after all, they can easily adjust it. > No, the idea that user have to use WMI which have it's own kernel driver to > send OIDs to NDIS when it receive IOCTLs from > user part of WMI. This is already a bit different story - this thing can be done pretty easily. However, as long as the possibility of sending IOCTLs to standalone devices exists, this is not a solution. The only thing they can do is to disable IOCTL_NDIS_QUERY_GLOBAL_STATS for user-mode WMI clients plus make NdisMRegisterDevice() ignore the symbolic link. If they do it this way, the whole thing will work. > AFAIK nor netstat ( due to Russinoch's netstatp already disappeared when > site moved to Msft :( ), not winsock send IOCTLs directly to miniport, but > winsock talk ( with IOCTL ) through LSP, WSH to tcpip.sys for info, not for > data interchange , that use msafd.dll/afd.sys/tdi.sys path before tcpip.sys. If it works this way and they are sure that their user-mode components will never ever need to talk directly to miniports, probably, they can disable user-mode access to devices, created by NdisMRegisterDevice(). After all, their components can submit private IOCTLs to afd.sys, and, at this point, afd.sys has two ways to reach miniport drivers (i.e. directly via standalone device or via TCPIP.SYS that does everything via NdisRequest()) Anton Bassov "Arkady Frenkel" wrote: > Anton! > "Anton Bassov" <AntonBassov(a)discussions.microsoft.com> wrote in message > news:11D2755D-6CB3-4FE3-9D41-993CB084CBBF(a)microsoft.com... > > Arkady, > > > >> I don't think that it's a problem for MSFT to decline that already in > >> DeviceIoControl() in user mode or > >> before extract/send OID in kernel mode > > > > *THEORETICALLY* doing things this way is feasible. However, look at the > > whole thing in practical terms. Both user-mode DeviceIoControl() and > > actual > > kernel-mode implementation of ZwDeviceIoControlFile() are meant to be used > > for sending*ANY* IOCTL to *ANY* device that registers a symbolic link. I > > hope > > you can imagine what it is like to watch and block some certain IOCTLs > > that > > get sent to some certain > > (unknown at compile-time) devices that get sent by callers that don't meet > > some certain criteria...... > > > Not exactly, hee we talk about specific IOCTL without any connection to > device at all , OTOH any case DACL of user checked in anycase to allow/deny > access to device. So there is no problem where to check that. > > > > > > The best thing to do here is just to make NdisMRegisterDevice() ignore the > > symbolic name string argument - if they do it this way, only kernel-mode > > components will be able to send IOCTLs to miniports. However, I am not > > sure > > they want to do it either - probably, some MSFT-written stuff (netstat, > > Wisock,etc) sends IOCTLs to miniports from the user mode.... > > > > No, the idea that user have to use WMI which have it's own kernel driver to > send OIDs to NDIS when it receive IOCTLs from > user part of WMI. > AFAIK nor netstat ( due to Russinoch's netstatp already disappeared when > site moved to Msft :( ), not winsock send IOCTLs directly to miniport, but > winsock talk ( with IOCTL ) through LSP, WSH to tcpip.sys for info, not for > data interchange , that use msafd.dll/afd.sys/tdi.sys path before tcpip.sys. > > Arkady > > > Anton Bassov > > > > "Arkady Frenkel" wrote: > > > >> Anton! > >> > >> "Anton Bassov" <AntonBassov(a)discussions.microsoft.com> wrote in message > >> news:79D44CFC-A70F-4349-9F8C-F5A916380E39(a)microsoft.com... > >> > Arkady, > >> > > >> >> Obviously that should work even on Vista, but MSFT for years warning > >> >> about > >> >> near deprecation of IOCTL_NDIS_QUERY_GLOBAL_STATS for security > >> >> reasons. > >> > > >> > Well, taking into consideration the fact that it is miniport driver and > >> > not > >> > TCPIP.SYS who handles this request (which is optional anyway), as well > >> > as > >> > the > >> > one that this IOCTL gets submitted to the standalone device that is not > >> > on > >> > any stack, there is not that much that they can do about it, apart from > >> > removing NdisMRegisterDevice(), i.e. dropping the support for > >> > standalone > >> > devices. I don't think they want to go that far.... > >> > > >> I don't think that it's a problem for MSFT to decline that already in > >> DeviceIoControl() in user mode or > >> before extract/send OID in kernel mode > >> Arkady > >> > >> >> OTOH that give option to check MAC on local host only ( in addition to > >> >> GetIfTable()/GetIfEntry and GetAdaptersInfo )and that no what OP mean > >> >> if > >> >> I > >> >> understood him correctly. > >> > > >> > The way I understood it, the OP was asking about the local host. Maybe > >> > I > >> > just got it wrong..... > >> > > >> > Anton Bassov > >> > > >> > > >> > "Arkady Frenkel" wrote: > >> > > >> >> Obviously that should work even on Vista, but MSFT for years warning > >> >> about > >> >> near deprecation of IOCTL_NDIS_QUERY_GLOBAL_STATS for security > >> >> reasons. > >> >> OTOH that give option to check MAC on local host only ( in addition to > >> >> GetIfTable()/GetIfEntry and GetAdaptersInfo )and that no what OP mean > >> >> if > >> >> I > >> >> understood him correctly. > >> >> In that case in addition to Netbios ( may not work if it disabled ) > >> >> and > >> >> SendARP() possible to use WMI's MACAddress property of > >> >> Win32_NetworkAdapter > >> >> interface . > >> >> > >> >> Arkady > >> >> > >> >> "Anton Bassov" <AntonBassov(a)discussions.microsoft.com> wrote in > >> >> message > >> >> news:634A9F45-589A-410B-A3B2-A0651F90A19E(a)microsoft.com... > >> >> >I would rather open a handle to the target adapter with CreateFile(), > >> >> >and > >> >> >then > >> >> > send OID_XXX_PERMANENT_ADDRESS request to it with > >> >> > IOCTL_NDIS_QUERY_GLOBAL_STATS ..... > >> >> > > >> >> > Names of all adapters TCPIP is bound to (i.e. the ones that can be > >> >> > passed > >> >> > to > >> >> > CreateFile() call) can be found under > >> >> > HKLM > >> >> > \\SYSTEM\\CurrentControlSet\\Services\\Tcpip\\Parameters\\Adapters > >> >> > key in the registry. First I would send OID_GEN_SUPPORTED_LIST > >> >> > request > >> >> > in > >> >> > order to find all OIDs that adapter supports, and locate > >> >> > OID_XXX_PERMANENT_ADDRESS > >> >> > ( OID!= OID_GEN_SUPPORTED_LIST && OID&0xffffff== > >> >> > OID_GEN_SUPPORTED_LIST). > >> >> > At this point I would be able to send OID_XXX_PERMANENT_ADDRESS, and > >> >> > obtain > >> >> > the sought info.... > >> >> > > >> >> > Anton Bassov > >> >> > > >> >> > "Andrew Chalk" wrote: > >> >> > > >> >> >> Is there a SDK or Platform API call that will return the MAC > >> >> >> address(es) > >> >> >> in > >> >> >> a host? > >> >> >> > >> >> >> Many thanks. > >> >> >> > >> >> >> > >> >> >> > >> >> > >> >> > >> >> > >> > >> > >> > > >
From: Arkady Frenkel on 13 Feb 2007 06:34 Anton! The rules of creating IOCTLs are very strict in windows ( the same in Unix decades before windows ) and obviously possible to stand that write will be translated as read for the device, is it not the same as absence of traffic rules on the road :) ? BTW Windows 9x/Me do not support IOCTL_NDIS_QUERY_GLOBAL_STATS at all from the beginning and nothing terrible happen Arkady "Anton Bassov" <AntonBassov(a)discussions.microsoft.com> wrote in message news:E881CAE5-8CAD-421D-8B48-15BC959FF97A(a)microsoft.com... > Arkady, > >> Not exactly, hee we talk about specific IOCTL without any connection to >> device at all.... > > IOCTL in itself is nothing more than just a DWORD value. What if some > totally unrelated driver,particularly third-party one, accepts IOCTL that > is > numerically equal to IOCTL_NDIS_QUERY_GLOBAL_STATS??? Are we going to > block > it as well??? > Therefore, no matter how you look at it, you have to relate IOCTLs to > their > target devices > >> OTOH any case DACL of user checked in anycase to allow/deny >> access to device. So there is no problem where to check that. > > Well, DACL check is done when you open a handle - once you have it, no > more > access checks are made. In any case, as far as admin accounts are > concerned, > DACL check is not a solution - after all, they can easily adjust it. > >> No, the idea that user have to use WMI which have it's own kernel driver >> to >> send OIDs to NDIS when it receive IOCTLs from >> user part of WMI. > > This is already a bit different story - this thing can be done pretty > easily. However, as long as the possibility of sending IOCTLs to > standalone > devices exists, this is not a solution. The only thing they can do is to > disable IOCTL_NDIS_QUERY_GLOBAL_STATS for user-mode WMI clients plus make > NdisMRegisterDevice() ignore the symbolic link. If they do it this way, > the > whole thing will work. > >> AFAIK nor netstat ( due to Russinoch's netstatp already disappeared when >> site moved to Msft :( ), not winsock send IOCTLs directly to miniport, >> but >> winsock talk ( with IOCTL ) through LSP, WSH to tcpip.sys for info, not >> for >> data interchange , that use msafd.dll/afd.sys/tdi.sys path before >> tcpip.sys. > > If it works this way and they are sure that their user-mode components > will > never ever need to talk directly to miniports, probably, they can disable > user-mode access to devices, created by NdisMRegisterDevice(). After all, > their components can submit private IOCTLs to afd.sys, and, at this point, > afd.sys has two ways to reach miniport drivers (i.e. directly via > standalone > device or via TCPIP.SYS that does everything via NdisRequest()) > > > Anton Bassov > > > "Arkady Frenkel" wrote: > >> Anton! >> "Anton Bassov" <AntonBassov(a)discussions.microsoft.com> wrote in message >> news:11D2755D-6CB3-4FE3-9D41-993CB084CBBF(a)microsoft.com... >> > Arkady, >> > >> >> I don't think that it's a problem for MSFT to decline that already in >> >> DeviceIoControl() in user mode or >> >> before extract/send OID in kernel mode >> > >> > *THEORETICALLY* doing things this way is feasible. However, look at the >> > whole thing in practical terms. Both user-mode DeviceIoControl() and >> > actual >> > kernel-mode implementation of ZwDeviceIoControlFile() are meant to be >> > used >> > for sending*ANY* IOCTL to *ANY* device that registers a symbolic link. >> > I >> > hope >> > you can imagine what it is like to watch and block some certain IOCTLs >> > that >> > get sent to some certain >> > (unknown at compile-time) devices that get sent by callers that don't >> > meet >> > some certain criteria...... >> > >> Not exactly, hee we talk about specific IOCTL without any connection to >> device at all , OTOH any case DACL of user checked in anycase to >> allow/deny >> access to device. So there is no problem where to check that. >> > >> > >> > The best thing to do here is just to make NdisMRegisterDevice() ignore >> > the >> > symbolic name string argument - if they do it this way, only >> > kernel-mode >> > components will be able to send IOCTLs to miniports. However, I am not >> > sure >> > they want to do it either - probably, some MSFT-written stuff (netstat, >> > Wisock,etc) sends IOCTLs to miniports from the user mode.... >> > >> >> No, the idea that user have to use WMI which have it's own kernel driver >> to >> send OIDs to NDIS when it receive IOCTLs from >> user part of WMI. >> AFAIK nor netstat ( due to Russinoch's netstatp already disappeared when >> site moved to Msft :( ), not winsock send IOCTLs directly to miniport, >> but >> winsock talk ( with IOCTL ) through LSP, WSH to tcpip.sys for info, not >> for >> data interchange , that use msafd.dll/afd.sys/tdi.sys path before >> tcpip.sys. >> >> Arkady >> >> > Anton Bassov >> > >> > "Arkady Frenkel" wrote: >> > >> >> Anton! >> >> >> >> "Anton Bassov" <AntonBassov(a)discussions.microsoft.com> wrote in >> >> message >> >> news:79D44CFC-A70F-4349-9F8C-F5A916380E39(a)microsoft.com... >> >> > Arkady, >> >> > >> >> >> Obviously that should work even on Vista, but MSFT for years >> >> >> warning >> >> >> about >> >> >> near deprecation of IOCTL_NDIS_QUERY_GLOBAL_STATS for security >> >> >> reasons. >> >> > >> >> > Well, taking into consideration the fact that it is miniport driver >> >> > and >> >> > not >> >> > TCPIP.SYS who handles this request (which is optional anyway), as >> >> > well >> >> > as >> >> > the >> >> > one that this IOCTL gets submitted to the standalone device that is >> >> > not >> >> > on >> >> > any stack, there is not that much that they can do about it, apart >> >> > from >> >> > removing NdisMRegisterDevice(), i.e. dropping the support for >> >> > standalone >> >> > devices. I don't think they want to go that far.... >> >> > >> >> I don't think that it's a problem for MSFT to decline that already in >> >> DeviceIoControl() in user mode or >> >> before extract/send OID in kernel mode >> >> Arkady >> >> >> >> >> OTOH that give option to check MAC on local host only ( in addition >> >> >> to >> >> >> GetIfTable()/GetIfEntry and GetAdaptersInfo )and that no what OP >> >> >> mean >> >> >> if >> >> >> I >> >> >> understood him correctly. >> >> > >> >> > The way I understood it, the OP was asking about the local host. >> >> > Maybe >> >> > I >> >> > just got it wrong..... >> >> > >> >> > Anton Bassov >> >> > >> >> > >> >> > "Arkady Frenkel" wrote: >> >> > >> >> >> Obviously that should work even on Vista, but MSFT for years >> >> >> warning >> >> >> about >> >> >> near deprecation of IOCTL_NDIS_QUERY_GLOBAL_STATS for security >> >> >> reasons. >> >> >> OTOH that give option to check MAC on local host only ( in addition >> >> >> to >> >> >> GetIfTable()/GetIfEntry and GetAdaptersInfo )and that no what OP >> >> >> mean >> >> >> if >> >> >> I >> >> >> understood him correctly. >> >> >> In that case in addition to Netbios ( may not work if it disabled ) >> >> >> and >> >> >> SendARP() possible to use WMI's MACAddress property of >> >> >> Win32_NetworkAdapter >> >> >> interface . >> >> >> >> >> >> Arkady >> >> >> >> >> >> "Anton Bassov" <AntonBassov(a)discussions.microsoft.com> wrote in >> >> >> message >> >> >> news:634A9F45-589A-410B-A3B2-A0651F90A19E(a)microsoft.com... >> >> >> >I would rather open a handle to the target adapter with >> >> >> >CreateFile(), >> >> >> >and >> >> >> >then >> >> >> > send OID_XXX_PERMANENT_ADDRESS request to it with >> >> >> > IOCTL_NDIS_QUERY_GLOBAL_STATS ..... >> >> >> > >> >> >> > Names of all adapters TCPIP is bound to (i.e. the ones that can >> >> >> > be >> >> >> > passed >> >> >> > to >> >> >> > CreateFile() call) can be found under >> >> >> > HKLM >> >> >> > \\SYSTEM\\CurrentControlSet\\Services\\Tcpip\\Parameters\\Adapters >> >> >> > key in the registry. First I would send OID_GEN_SUPPORTED_LIST >> >> >> > request >> >> >> > in >> >> >> > order to find all OIDs that adapter supports, and locate >> >> >> > OID_XXX_PERMANENT_ADDRESS >> >> >> > ( OID!= OID_GEN_SUPPORTED_LIST && OID&0xffffff== >> >> >> > OID_GEN_SUPPORTED_LIST). >> >> >> > At this point I would be able to send OID_XXX_PERMANENT_ADDRESS, >> >> >> > and >> >> >> > obtain >> >> >> > the sought info.... >> >> >> > >> >> >> > Anton Bassov >> >> >> > >> >> >> > "Andrew Chalk" wrote: >> >> >> > >> >> >> >> Is there a SDK or Platform API call that will return the MAC >> >> >> >> address(es) >> >> >> >> in >> >> >> >> a host? >> >> >> >> >> >> >> >> Many thanks. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >>
From: Anton Bassov on 15 Feb 2007 02:19
Arkady, The rules of creating IOCTLs are very strict in windows..... Not really.... What really matters are TransferType and RequiredAccess fields (just 4 bits out of 32), because IO Manager's actions depend on it. However, when it comes to DeviceType and FunctionCode, no one seems to check them I see what you mean - if some other driver accepts IOCTL_NDIS_QUERY_GLOBAL_STATS, then blocking the request may be excused, because they may say that this driver does not follow the rules. However, the fact that DeviceType and FunctionCode don't get checked indirectly supports my statement that MSFT is quite unlikely to solve the problem this way.... Anton Bassov "Arkady Frenkel" wrote: > Anton! The rules of creating IOCTLs are very strict in windows ( the same in > Unix decades before windows ) and obviously possible to stand that write > will be translated as read for the device, is it not the same as absence of > traffic rules on the road :) ? > BTW Windows 9x/Me do not support IOCTL_NDIS_QUERY_GLOBAL_STATS at all from > the beginning and nothing terrible happen > > Arkady > > "Anton Bassov" <AntonBassov(a)discussions.microsoft.com> wrote in message > news:E881CAE5-8CAD-421D-8B48-15BC959FF97A(a)microsoft.com... > > Arkady, > > > >> Not exactly, hee we talk about specific IOCTL without any connection to > >> device at all.... > > > > IOCTL in itself is nothing more than just a DWORD value. What if some > > totally unrelated driver,particularly third-party one, accepts IOCTL that > > is > > numerically equal to IOCTL_NDIS_QUERY_GLOBAL_STATS??? Are we going to > > block > > it as well??? > > Therefore, no matter how you look at it, you have to relate IOCTLs to > > their > > target devices > > > >> OTOH any case DACL of user checked in anycase to allow/deny > >> access to device. So there is no problem where to check that. > > > > Well, DACL check is done when you open a handle - once you have it, no > > more > > access checks are made. In any case, as far as admin accounts are > > concerned, > > DACL check is not a solution - after all, they can easily adjust it. > > > >> No, the idea that user have to use WMI which have it's own kernel driver > >> to > >> send OIDs to NDIS when it receive IOCTLs from > >> user part of WMI. > > > > This is already a bit different story - this thing can be done pretty > > easily. However, as long as the possibility of sending IOCTLs to > > standalone > > devices exists, this is not a solution. The only thing they can do is to > > disable IOCTL_NDIS_QUERY_GLOBAL_STATS for user-mode WMI clients plus make > > NdisMRegisterDevice() ignore the symbolic link. If they do it this way, > > the > > whole thing will work. > > > >> AFAIK nor netstat ( due to Russinoch's netstatp already disappeared when > >> site moved to Msft :( ), not winsock send IOCTLs directly to miniport, > >> but > >> winsock talk ( with IOCTL ) through LSP, WSH to tcpip.sys for info, not > >> for > >> data interchange , that use msafd.dll/afd.sys/tdi.sys path before > >> tcpip.sys. > > > > If it works this way and they are sure that their user-mode components > > will > > never ever need to talk directly to miniports, probably, they can disable > > user-mode access to devices, created by NdisMRegisterDevice(). After all, > > their components can submit private IOCTLs to afd.sys, and, at this point, > > afd.sys has two ways to reach miniport drivers (i.e. directly via > > standalone > > device or via TCPIP.SYS that does everything via NdisRequest()) > > > > > > Anton Bassov > > > > > > "Arkady Frenkel" wrote: > > > >> Anton! > >> "Anton Bassov" <AntonBassov(a)discussions.microsoft.com> wrote in message > >> news:11D2755D-6CB3-4FE3-9D41-993CB084CBBF(a)microsoft.com... > >> > Arkady, > >> > > >> >> I don't think that it's a problem for MSFT to decline that already in > >> >> DeviceIoControl() in user mode or > >> >> before extract/send OID in kernel mode > >> > > >> > *THEORETICALLY* doing things this way is feasible. However, look at the > >> > whole thing in practical terms. Both user-mode DeviceIoControl() and > >> > actual > >> > kernel-mode implementation of ZwDeviceIoControlFile() are meant to be > >> > used > >> > for sending*ANY* IOCTL to *ANY* device that registers a symbolic link. > >> > I > >> > hope > >> > you can imagine what it is like to watch and block some certain IOCTLs > >> > that > >> > get sent to some certain > >> > (unknown at compile-time) devices that get sent by callers that don't > >> > meet > >> > some certain criteria...... > >> > > >> Not exactly, hee we talk about specific IOCTL without any connection to > >> device at all , OTOH any case DACL of user checked in anycase to > >> allow/deny > >> access to device. So there is no problem where to check that. > >> > > >> > > >> > The best thing to do here is just to make NdisMRegisterDevice() ignore > >> > the > >> > symbolic name string argument - if they do it this way, only > >> > kernel-mode > >> > components will be able to send IOCTLs to miniports. However, I am not > >> > sure > >> > they want to do it either - probably, some MSFT-written stuff (netstat, > >> > Wisock,etc) sends IOCTLs to miniports from the user mode.... > >> > > >> > >> No, the idea that user have to use WMI which have it's own kernel driver > >> to > >> send OIDs to NDIS when it receive IOCTLs from > >> user part of WMI. > >> AFAIK nor netstat ( due to Russinoch's netstatp already disappeared when > >> site moved to Msft :( ), not winsock send IOCTLs directly to miniport, > >> but > >> winsock talk ( with IOCTL ) through LSP, WSH to tcpip.sys for info, not > >> for > >> data interchange , that use msafd.dll/afd.sys/tdi.sys path before > >> tcpip.sys. > >> > >> Arkady > >> > >> > Anton Bassov > >> > > >> > "Arkady Frenkel" wrote: > >> > > >> >> Anton! > >> >> > >> >> "Anton Bassov" <AntonBassov(a)discussions.microsoft.com> wrote in > >> >> message > >> >> news:79D44CFC-A70F-4349-9F8C-F5A916380E39(a)microsoft.com... > >> >> > Arkady, > >> >> > > >> >> >> Obviously that should work even on Vista, but MSFT for years > >> >> >> warning > >> >> >> about > >> >> >> near deprecation of IOCTL_NDIS_QUERY_GLOBAL_STATS for security > >> >> >> reasons. > >> >> > > >> >> > Well, taking into consideration the fact that it is miniport driver > >> >> > and > >> >> > not > >> >> > TCPIP.SYS who handles this request (which is optional anyway), as > >> >> > well > >> >> > as > >> >> > the > >> >> > one that this IOCTL gets submitted to the standalone device that is > >> >> > not > >> >> > on > >> >> > any stack, there is not that much that they can do about it, apart > >> >> > from > >> >> > removing NdisMRegisterDevice(), i.e. dropping the support for > >> >> > standalone > >> >> > devices. I don't think they want to go that far.... > >> >> > > >> >> I don't think that it's a problem for MSFT to decline that already in > >> >> DeviceIoControl() in user mode or > >> >> before extract/send OID in kernel mode > >> >> Arkady > >> >> > >> >> >> OTOH that give option to check MAC on local host only ( in addition > >> >> >> to > >> >> >> GetIfTable()/GetIfEntry and GetAdaptersInfo )and that no what OP > >> >> >> mean > >> >> >> if > >> >> >> I > >> >> >> understood him correctly. > >> >> > > >> >> > The way I understood it, the OP was asking about the local host. > >> >> > Maybe > >> >> > I > >> >> > just got it wrong..... > >> >> > > >> >> > Anton Bassov > >> >> > > >> >> > > >> >> > "Arkady Frenkel" wrote: > >> >> > > >> >> >> Obviously that should work even on Vista, but MSFT for years > >> >> >> warning > >> >> >> about > >> >> >> near deprecation of IOCTL_NDIS_QUERY_GLOBAL_STATS for security > >> >> >> reasons. > >> >> >> OTOH that give option to check MAC on local host only ( in addition > >> >> >> to > >> >> >> GetIfTable()/GetIfEntry and GetAdaptersInfo )and that no what OP > >> >> >> mean > >> >> >> if > >> >> >> I > >> >> >> understood him correctly. > >> >> >> In that case in addition to Netbios ( may not work if it disabled ) > >> >> >> and > >> >> >> SendARP() possible to use WMI's MACAddress property of > >> >> >> Win32_NetworkAdapter > >> >> >> interface . > >> >> >> > >> >> >> Arkady > >> >> >> > >> >> >> "Anton Bassov" <AntonBassov(a)discussions.microsoft.com> wrote in > >> >> >> message > >> >> >> news:634A9F45-589A-410B-A3B2-A0651F90A19E(a)microsoft.com... > >> >> >> >I would rather open a handle to the target adapter with > >> >> >> >CreateFile(), > >> >> >> >and > >> >> >> >then > >> >> >> > send OID_XXX_PERMANENT_ADDRESS request to it with > >> >> >> > IOCTL_NDIS_QUERY_GLOBAL_STATS ..... > >> >> >> > > >> >> >> > Names of all adapters TCPIP is bound to (i.e. the ones that can > >> >> >> > be > >> >> >> > passed > >> >> >> > to > >> >> >> > CreateFile() call) can be found under > >> >> >> > HKLM > >> >> >> > \\SYSTEM\\CurrentControlSet\\Services\\Tcpip\\Parameters\\Adapters > >> >> >> > key in the registry. First I would send OID_GEN_SUPPORTED_LIST > >> >> >> > request > >> >> >> > in > >> >> >> > order to find all OIDs that adapter supports, and locate > >> >> >> > OID_XXX_PERMANENT_ADDRESS > >> >> >> > ( OID!= OID_GEN_SUPPORTED_LIST && OID&0xffffff== > >> >> >> > OID_GEN_SUPPORTED_LIST). > >> >> >> > At this point I would be able to send OID_XXX_PERMANENT_ADDRESS, > >> >> >> > and > >> >> >> > obtain > >> >> >> > the sought info.... > >> >> >> > > >> >> >> > Anton Bassov > >> >> >> > > >> >> >> > "Andrew Chalk" wrote: > >> >> >> > > >> >> >> >> Is there a SDK or Platform API call that will return the MAC > >> >> >> >> address(es) > >> >> >> >> in > >> >> >> >> a host? > >> >> >> >> > >> >> >> >> Many thanks. > >> >> >> >> > >> >> >> >> > >> >> >> >> > >> >> >> > >> >> >> > >> >> >> > >> >> > >> >> > >> >> > >> > >> > >> > > > |