I want to get hardware address of network interface on AIX using ioctl.
Like in Linux we get it through:
ioctl(sockFd, SIOCGIFADDR, ifr_p);
I didn't find SIOCGIFADDR flag in /usr/include/sys/ioctl.h on AIX to get hardware address information.
Is there any way to get it from ioctl? or any file in system from where I can get this information like in linux this information is stored in '/sys/class/net/'
There are plenty of example codes available, see here or here. Basically, you'll have to call getkerninfo with the KINFO_NDD argument and then read the address from the ndd_addr field of the kinfo_ndd struct filled by that call.
You can easily detect a needed include file using something like grep -w SIOCGIFADDR /usr/include. This could give not the recommended header file but a deeper one, but at least this will be a clue.
In general, BSD style says the proper header is <net/if.h>. I doubt AIX is changed to make it not work. Also, a convenient wrapper getifaddrs() should be available.
Related
I am going to check loading and memory path of process to find malicious processes. for example if csrss.exe is executed from other path than Windows\System32 would be considered malicious. But the result of Volatility for common process such as csrss.exe is as follows:
loading path : \??\C:\WINDOWS\system32\csrss.exe
mapped path : \WINDOWS\system32\csrss.exe
or for smss.exe I have
loading path : \SystemRoot\System32\smss.exe
mapped path : \WINDOWS\system32\smss.exe
So are these two paths equal in these two examples or not ? I.e. is \??\C:\WINDOWS == \WINDOWS
or \SystemRoot\System32 == \WINDOWS\system32
No, a ??\C:\... without the leading \ is not valid, to the best of my knowledge. Perhaps some libraries will accept this as input, however, and convert it appropriately. Or perhaps you missed some bits from the paths you copied and pasted?
Either way we'll stick to the (NT flavored) Windows behavior.
However, \??\C:\... definitely is. You can find a comprehensive discussion here and the official documentation here. Some of the aspects we need to know are also explained here.
Some implementation details
Quoting from the Google Project Zero page above:
There are 7 types of path that the Win32 API distinguishes between,
and potentially does different things with. NTDLL has a function,
RtlDetermineDosPathNameType_U, which, given a Unicode string will
return you the path type. We’ll go through each one of these types in
the next section. The following prototype can be used to call this
function:
enum RTL_PATH_TYPE {
RtlPathTypeUnknown,
RtlPathTypeUncAbsolute,
RtlPathTypeDriveAbsolute,
RtlPathTypeDriveRelative,
RtlPathTypeRooted,
RtlPathTypeRelative,
RtlPathTypeLocalDevice,
RtlPathTypeRootLocalDevice
};
RTL_PATH_TYPE NTAPI RtlDetermineDosPathNameType_U(_In_ PCWSTR Path);
To follow along, download WinObj from Sysinternals/Microsoft and start it elevated (right-click + "Run as Administrator").
Potentially valid paths you may see
You have a number of path representations (as discussed in-depth in the linked articles). Let's consider the path C:\Windows\System32\csrss.exe you gave:
Win32 path: C:\Windows\System32\csrss.exe (\Windows\System32\csrss.exe would be a variation that depends on the current directory at the time the path is processed, if it is somewhere on C: they should be identical)
NT native path:
\??\C:\Windows\System32\csrss.exe
\GLOBAL??\C:\Windows\System32\csrss.exe
\SystemRoot\System32\csrss.exe
Local device path: \\.\C:\Windows\System32\csrss.exe
Root local device path: \\?\C:\Windows\System32\csrss.exe
DOS paths: this is relevant for all paths whose individual path segments are longer than the classic 8.3 DOS path name segments. If configured, a 8.3 DOS name will be generated (usually something in the form of C:\LongPathName -> C:\LONGPA~1) ... this may be important for forensic purposes (you quote volatility), but is mostly legacy behavior.
UNC paths also exist and in fact a local device path (\\.\...) looks like a UNC path with server name . which could even be a thing, considering . is the current directory further down in paths, so why not the current machine up top? Either way, go read the articles if you want to know about those in more detail.
Starting at the top, drilling down
C:\Windows\System32\csrss.exe when passed to an API like CreateFile will be converted to \??\C:\Windows\System32\csrss.exe which the object manager then takes in for processing.
If a relative path was given, there will be additionally processing to convert to a full path, basically.
\\.\C:\Windows\System32\csrss.exe when passed to an API like CreateFile will be "converted" to \??\C:\Windows\System32\csrss.exe after some processing. Just like without the \\.\ prefix some additional processing happens before this path is passed down to the object manager.
\\?\C:\Windows\System32\csrss.exe when passed to an API like CreateFile will be "converted" to \??\C:\Windows\System32\csrss.exe. No further processing happens at the Win32 level. This is basically an escape route straight to the object manager (and in the Fun facts section I'll share a related fun fact).
The object manager view
Receiving a path like \??\C:\Windows\System32\csrss.exe the object manager attempts to find \?? first.
\?? used to be an actual item, these days it is a "view" of \GLOBAL?? overlaid with your session-specific DosDevices.
An example of session-specific DosDevices would be mapped network shares.
For a drive letter F: mapped to \\fileserver\Share
Under the hood you will have a session-specific DosDevices object directory like \Sessions\0\DosDevices\00000000-00261e8a which would contain a symbolic link named F:, pointing to \Device\LanmanRedirector\;F:0000000000261e8a\fileserver\Share ... or similar.
So in essence when looking up names in \?? the object manager will look in your session specific DosDevices, followed by \GLOBAL?? (or was it the other way around? 🤔)
Another example would be VeraCrypt mounted volumes. For example your drive letter T: may map to \Device\VeraCryptVolumeT
Having figured out that C: is \GLOBAL??\C: in our case, the object manager checks what C: is. On my Windows 10 it figures out that this is a symbolic link pointing to \Device\HarddiskVolume3.
Having found the device (and implicitly the driver associated with it) the object manager now will pass the remainder of the path (\Windows\System32\csrss.exe) to the device \Device\HarddiskVolume3, whose driver will hopefully do the right thing, create a file object and so on ...
And now that you know this you can follow along on your system for arbitrary paths.
What about \SystemRoot?
Well, on modern Windows versions the behavior differs a little from how it used to be, but \SystemRoot is a symbolic link resolving to the Windows directory on all NT-based Windows versions I am aware of. The Win32 subsystem parrots this in the %SystemRoot% environment variable (albeit in Win32 path notation).
On my Windows 10 \SystemRoot is a symbolic link to \Device\BootDevice\windows and so the path to a driver (which is the typical use case in the registry) can be expressed much more easily for early boot drivers (less processing needed by the object manager).
As a side note: on my system - as you'd expect - \Device\BootDevice maps to \Device\HarddiskVolume3.
Fun facts
The DosDevices object directory cited in the Google Project Zero article is no longer a thing. These days it's a symbolic link to \?? (not \GLOBAL??).
The subst command line utility allows you to create symbolic links inside your session-specific DosDevices object directory to map some directory path to a drive letter (under the hood uses DefineDosDevice()).
Files are unnamed objects, that is they have no name that could be directly processed by the NT object manager. Instead the remainder of a file name - after reparsing etc - will be passed to the driver responsible for the device object representing the file system volume (i.e. partition). That driver then takes care of making sense of the name.
\REGISTRY\MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem (while this doesn't name a file, it is a perfectly valid native path to what you would see as HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem
That escape routes named \??\ and \\?\
I mentioned before that the prefix \??\ is an escape route. Consider a file/folder path with a trailing dot, something you will not be able to create or access ordinarily from the Win32 subsystem. Similarly the reserved DOS device names (e.g. NUL, COM1 etc.) cannot be created or manipulated ordinarily.
Little experiment ...
start cmd.exe (Win+R)
go to your desktop folder: cd /d "%USERPROFILE%\Desktop"
Now create a new file test.txt. (note the trailing dot): echo . > \??\%CD%\test.txt. (the %CD% refers to the current directory)
Use Windows Explorer to navigate to your desktop folder. Try to open the file test.txt. by double-clicking. Pick Notepad when it asks you what program to use to open it.
You should see:
... please note the path (without trailing dot).
Now try to delete the file from Windows Explorer. It won't work.
NB: Some alternative file managers like Far or Speed Commander won't have trouble with this!
Now switch back to the command line window and use del /f \\?\%CD%\test.txt.
Did you notice something? I sneakily changed from \??\ to \\?\ because apparently the implementation of del doesn't like the former.
Depending on the implementation of your specific program it can vary whether \??\ or \\?\ is successful.
Another experiment would be to create reserved names like NUL or COM1 or tinker with WSL2's per-directory case-sensitivity.
Note
Win32 may sound outdated, but the Win32 subsystem and the respective "Windows personality" implemented through csrss.exe and its subsystem DLLs (kernel32.dll and friends) was called just that. Besides, if you're picky it may bother you particularly to find out that all the native 64-bit binaries on a modern x64 Windows reside in %SystemRoot%\System32 (<- yes, that's a 32 right there 😁). Enjoy!
Further reading
In addition to the articles from the top, I can recommend these books:
Obviously the Windows Internals book series.
Windows System Programming by Pavel Yosifovich also has some details
First, appreciate you giving this a look. I have an ancient piece of software that writes old Linear PCMCIA cards. In my case, I want to use it in a specialized piece of gear called a Tech2. The software in question is called Memory Card Explorer. Now, I know for a fact it works in Windows XP with Native PCMCIA slots. However, I have a slot that is built on a Dual Systems adapter (basically an Expresscard to PCMCIA adapter).
The issue arises when following the instructions on installation issues, the program refuses to locate the Dual Adapter. Here's the example given in the manual:
"Use a similar address to the PCMCIA adapter. That address can be found using msinfo32.exe.
Eg: if the PCMCIA socket has a memory resource of F8000000 then use a MCE window command of F80D0000 using command line option of WF80D0."
So I get my adapter address which is F7FFF000 but have no idea where to add the "d" to the resource address then change it to a command. I've tried WF7FD0. Am I missing something simple in how these addresses are truncated for command line? Is there a calculator that does the conversion for you somewhere?
Thanks.
It looks like the pattern is to add 0x000D0000 to the address, take the five high nibbles of the address (which makes sense, since these sorts of addresses are typically page-aligned the bottom 3 nibbles will always be 0 on a system with 4KiB pages), and prepend 'W'. Try WF80CF.
I have just started on libusbdotnet. I have downloaded the sample code from http://libusbdotnet.sourceforge.net/V2/Index.html.
I am using a JetFlash 4GB Flash drive (a libusb-win32 filter driver was added for this drive).
The ShowInfo code works perfectly, and I can see my device info with two endpoints. Following is the device info from pastebin
http://pastebin.com/2Jdph6bY
However, the ReadOnly sample code does not work.
http://pastebin.com/hNZaEt8N
My code is almost same as that from the libsubdotnet website. I have only changed the endpoint that UsbEndpointReader uses. I have changed it from Ep01 to Ep02, because I read that the first endpoint is a control endpoint used for configuration, access control and similar stuff.
UsbEndpointReader reader = MyUsbDevice.OpenEndpointReader(ReadEndpointID.Ep02);
I always get the message "No more bytes!".
I thought that this is because of the absence of data, so I used the ReadWrite sample code.
http://pastebin.com/NiN5w9Jt
But here I also get "No more bytes!" message.
Interestly, the line
ec = writer.Write(Encoding.Default.GetBytes(cmdLine), 2000, out bytesWritten);
executes without errors.
Can pen drives be used for read write operations? Or is something wrong with the code?
A USB thumb drive implements the USB mass storage device class, which is a subset of SCSI. The specification is here.
You're not going to get anything sensible by just reading from an endpoint - you have to send the appropriate commands to get any response.
You have not chosen an easy device class to begin your exploration of USB - you may be better starting with something easier - a HID class device, perhaps (Mouse/Keyboard) though Windows does have enhanced security around mice and keyboards which may prevent you installing a filter.
If you meddle with the filesystem on the USB stick while it's mounted as a drive by Windows, you'll almost certainly run into cache-consistency problems, unless you're extremely careful about what kind of access you allow Windows to do.
Within VB.NET, trying to find an easy way to in a sense check the check-box "Use Windows to configure my Wireless Network Settings". This is an option that forces windows to use your wireless over third-party programs that may try to steal control. I am aware this requires to have WZC enabled within services and that's something that can be easily accomplished one way or another.
I doubt or rather cannot find a proper registry value or API call to check or initiate such a task.
I would use a registry-recorder to record the changes when manually changing the value, then its a piece of cake to implement the register change in code.
There are plenty programs that can be used to see what changes has been done in the registry, here are one free: http://www.kephyr.com/systemsherlocklite/index.phtml, but google may find more or better variants out there.
With this tool, create a registry dump:
systemsherlock.exe -dump d1.dat -regdirs HKEY_ROOT
Do the change in the wireless network settings
Do a new dump of the registry:
systemsherlock.exe -dump d2.dat -regdirs HKEY_ROOT
And last, compare them and see what has changed:
systemsherlock.exe -compare d1.dat d2.dat
I'm trying to talk to a USB device using libusb, but I feel like I'm tripping up on the first leg of the race. I know precisely what endpoints I need to talk to, etc., but I can't even get that far. I have, in essence:
usb_device *dev = ...; // opened from get_busses()
usb_set_configuration(dev, dev->config[0].bConfigurationValue); // bConfigVal = 1
Now, I can look at the device information in debug mode and I know that the current configuration is 0 (uninitialized / just after restart), and there's exactly 1 valid configuration, which has a configuration number of 1. But when I set the config to 1, I get a return value of -22, which (passed through the stringifier) translates to "windows api error: bad parameter.
I haven't been able to find other people having a similar problem, and it seems like such a simple thing to do -- I can't even claim the interface, or set the alt-interface, or anything like that, because I have to set the configuration first. What am I missing? (if it matters: this is on WinXP)
Looking at libusb-win32\src\driver\set_configuration.c, there seem to be a bunch of different reasons for returning STATUS_INVALID_PARAMETER.
Use libusb_set_debug (from your user mode application) to set verbose debug level, then run Sysinternals DebugView to see the driver's error messages. Hopefully you'd see a clue as to why your set_configuration call fails.