Recognizing computer in masm - macos

How can I retrieve MAC of network card(s) and what can I retrieve to recognise specific computer and how?

Call Win32's GetAdaptersInfo
Just use INVOKE to call it and pass parms.

Related

See what com ports an application is calling?

I have an application in windows, that opens a com port. It attempts to call a comport, then fails and prompts me with an error.
The issue is this is very legacy software that we no longer have the source code for. I'm wondering if anyone knows of a way that can trace, or follow a program calling a com port to find out what com port its attempting to allocate.
Appearantly you can use Process Explorer (as called out in this post) to search for processes using serial ports. It sounds like you should be able to use the same searching concept called out the other post to find what you need.
I actually gave up on this solution and re-wrote the entire program in a week, it had to be done due to binary compatibility issues with the PCI cards.

Ruby: Obtaining a process load address for mach-o?

Does anyone know if there is a library that provides the functionality to obtain a processes base/load address? I would like to programmatically add breakpoints using Ragweed, however I only have the breakpoint offsets exported from IDA. The only thing I could find was:
Getting process base address in Mac OSX
Via Ragweed (https://github.com/tduehr/ragweed)
x = Ragweed::Debuggerosx.new(pid)
x.attach
puts x.region_info(0).base_address

SIOCGIFHWADDR for ioctlsocket in mingw

I am using mingw to compile my cpp program which has to get MAC address. In unix, sys/ioctl.h
provides 'SIOCGIFHWADDR' to read it. But for mingw win32, there is a replacement for ioctl named as ioctlsocket. I am using it but it doesn't have 'SIOCGIFHWADDR' command.
How can I read the hardware MAC address using ioctlsocket?
Thanks in advance.
Following is the function I am using
ioctl(fd, SIOCGIFHWADDR, &ifr); //Unix it works
ioctlsocket(fd, SIOCGIFHWADDR, &ifr); //win32, doesn't work
There are a handful of different Windows APIs that will get the local MAC address for you.
GetAdaptersAddresses should work for you. (Look at the PhysicalAdddress member in the returned set of IP_ADAPTER_ADDRESSES.
You can also use GetIfTable and look at the bPhysAddr member in the returned set of MIB_IFROW structs.

Anti rootkit SSDT

I am working with windows 7 x64. I understand that patchguard is enabled and should prevent write access to the SSDT structure in ntoskrnl.exe. However for learning purposes, I was wondering if my driver can call a function like ZwXxxx directly.
By directly i mean, obtain the kernel base. Lets say the offset to the function is 0xDeadBeef. Can I just create a typedef'd function pointer to that location and call it like that? Without going through the SSDT? I know this is how I would be in user-mode, not sure if its the same case in kernel mode.
Thanks.
As you said patchguard prevents SSDT modification. So, reading is ok. And if you have a function address you can call it. There is no difference how did you manage to obtain the function address: from SSDT, by signature, hardcoded value or else.

How to eject a USB removable disk/volume, similar to the "Eject" function in Windows Explorer?

Do you know what is the API, or sequence of API calls that windows uses to accomplish the "Eject" function which is available on the shell context menu for removable volumes?
So far I've tried two things:
using CM_Request_Device_Eject, I enumerate the removable disks (using the SetupDiXXX APIs), find the one that I'm interested in, walk the device manager hierarchy (using CM_XXX APIs) and finally call CM_Request_Device_Eject on the devInst of the device I'm interesed in. This works in the sense that it does remove the volumes from My Computer and makes the device "safe to remove" (ready to be removed) but it is not the same as the shell context menu "Eject" function. The way I know this is because the device that I'm trying to eject is supposed to do something when it is ejected and that something is not happening when I do the eject using CM_Request_Device_Eject.
using DeviceIoControl with the IOCTL_STORAGE_EJECT_MEDIA control code. The sequence of events is:
obtain a handle to the volume I'm interested in using CreateFile as suggested in the documentation
try to lock the volume with FSCTL_LOCK_VOLUME
try to dismount it using FSCTL_DISMOUNT_VOLUME
disable the prevent storage media removal using IOCTL_STORAGE_MEDIA_REMOVAL
and finally execute the IOCTL_STORAGE_EJECT_MEDIA function.
This doesn't work at all. Each one of the DeviceIoControl calls fails with ERROR_IVALID_FUNCTION (0x00000001). I don't know why the calls fail. I've verified that other calls to DeviceIoControl work fine for the same file handle (such as IOCTL_STORAGE_GET_DEVICE_NUMBER)
Finally, my development machine is running Windows 7 x64, and in order to get the second method to work I've tried running my application with Administrator privileges and that did not change anything.
EDIT
Eventually, I found out where I was making a mistake with approach #2. It turns out that for some reason I was not setting the desired access correctly when opening the handle to the volume using CreateFile. The correct access mode is GENERIC_READ | GENERIC_WRITE and I was passing 0. After correcting my error I was able to successfully eject the device using DeviceIoControl - IOCTL_STORAGE_EJECT_MEDIA, as well as with method #1, using CM_Request_Device_Eject.
And it turns out that method #2 is indeed the method used by the shell context menu's "Eject" function. Using this method the device reacts correctly.
Eventually, I found out where I was making a mistake with approach #2.
It turns out that for some reason I was not setting the desired access correctly when opening the handle to the volume using CreateFile.
The correct access mode is GENERIC_READ | GENERIC_WRITE and I was passing 0. After correcting my error I was able to successfully eject the device using DeviceIoControl - IOCTL_STORAGE_EJECT_MEDIA, as well as with method #1, using CM_Request_Device_Eject.
Finally, it turns out that method #2 is indeed the method used by the shell context menu's "Eject" function. Using this method the device reacts correctly.
I came here accidentally while doing a search on "CM_Request_Device_Eject", and saw that it was similar to a solution I'd recently done by pulling together similar pieces of a solution. Forgive the late answer.
I've summarized the steps I've done for this on my project in this SO answer.

Resources