I try to read and write the MAC white-list of a wireless Hotspot.
I try to be able to configure such a wireless access point (and multiple devices) with a command line or a batch file without logging into the web interface of every single hotspot.
I am writing my tool in Java using SNMP4J.
My testing device is a Funkwerk bintec w2002 (Teldata GmbH).
Does anyone know where I can get the OID of the MAC white-list.
You'll need to find the appropriate MIB file(s) for the hotspot. The MIB files specify which objects can be polled, and what their OIDs are. If the vendor publishes the MIB files on their web site, you're in luck. Otherwise, try the customer support.
If you can't find the MIB files, you can try doing an SNMP walk of the hotspot. That will give you all the data, but you won't know what the OIDs mean (unless it's a standard MIB which you or your tools are familiar with). Anyway, a MAC address is pretty distinctive so you should be able to spot it.
A suitable command-line tool for doing the SNMP walk would be the net-snmp cli suite, with the "snmpwalk" command. Their web site (http://www.net-snmp.org/) can also give you some prods in the right direction when it comes to a system administrator's use of SNMP.
If you're really lucky, the MIB objects are writable so you could set them using the snmpset command.
Related
I am writing a small apllication that will tell list of attached devices to my linux laptop.There is one utility that is udev that can be used for hot plugging but is their some other way where i can write simple c program where it will tell that these devices are attached to your laptop.or it will pop up message when new devices will be attached and removed.please provide some basic stuff so that i can start my project.thanx in advance.
As far as I can see, there are two parts to your question. I will answer them separately.
Get a list of current devices
Your source of information would be /sys/ and proc and their sub directories. You can get most information by simply reading the appropriate file from here. For example, trying running utilities such as lsusb using strace and see what files they access - you will see it reads /sys/devices. Also look at lshw and it's source code.
Notification of hardware events
This is where udev comes in. Here are couple of articles I came across they may be helpful:
http://www.signal11.us/oss/udev/
http://www.reactivated.net/writing_udev_rules.html
How would you retrieve the BSOD text from a virtualbox vm??
As the BSOD is text, it should be stored in the VM's memory space somewhere and probably somewhere well defined.
I have several VMs that have been configured to stop on blue screens rather than rebooting, and code is in place to take screen shots at regular intervals.
At this point my plan is to difference two images, if there are no differences ( i.e. there have been no changes on the screen) and the pixels in the 4 corners are all blue ( and the right blue) then we attempt extraction of the BSOD text, search the text for the "* STOP:" sequence to confirm it as a BSOD.
I originally planed on a quick and dirty OCR solution to extract text from the image itself, however if we can relatively easily extract it from memory we would remove the possibility of OCR errors.
I've perused the manual and API reference and haven't seen anything that seems to immediately apply.
Is it possible to access the guests memory from the Virtual Box host and retrieve the BSOD text directly from memory?
UPDATE
Just to clarify, I've considered 4 different options at this time
1) Reverse engineering the windows debug protocol and building at least a basic debugger to listen on the vm's serial port
Requires reverse engineering serial protocol, suspect this would present a fair amount of difficulty
2) Reverse engineering the Virtualbox saved state file and extracting the text from the VESA memory area that I suspect is stored in that file after saving the VM on the BSOD
I haven't been able to find documentation on this file format outside the source code itself.
3) Running OCR on the output image retrieved using the API
This may be the best way to go, requires building or setting up and training an ocr solution of some kind, outside my experience. May be relatively simple to do, constant width font/ clean image, only two colours to deal with
4) Access the guests memory directly using either an API call or by creating an extension to access/expose it in some manner
As pointed out by Warren, there doesn't seem to be an API to access the memory, may be able to write an extension to expose the vm's memory in some manner, but would require understanding of Virtualbox internals.
This is running on Solaris hosts, and some may only have one Windows vm available that may or may not boot. This VM could be any relatively recent version of windows (XP, 2003, 2003 R2, 2008,Vista, 2008 R2). I can spawn an arbitrary number of Linux based VM's, however I cannot spawn additional windows VM's due to licensing concerns. My thought to this point has been that retrieving it directly from the guests memory would be the easiest to implement, perhaps I'm mistaken in that and one of the above methods, or one I haven't thought of, would be easier to implement
If you are trying to just get the information why not just enable kernel debugging and expose it over one of the virtual serial ports? I believe you should be able to use either Debugging Tools for Windows (WinDbg) or Kernel Debugger (KD) over an I/O port. The only unique requirement because this is a VM is that the virtual serial port should be mapped to a named pipe on the host, and then the debugger on the host (or other VM since your host isn't Windows) should be configured to communicate over that pipe. Your commands would look something like this:
windbg -k com:port=\\.\pipe\<pipe_name>,pipe
kd -k com:port=\\.\pipe\<pipe_name>,pipe
There is a great blog post by the legendary Mark Russinovich that describes how he used the debugger to alter the colors of the BSOD screen. Hopefully that will provide you some additional insight into using the tools as well as narrowing down the field and getting you to the right area to extract the info you are looking for.
Here are some references to help get you started:
KB Article 151981: How to set up a remote debug session using a null modem cable
http://support.microsoft.com/kb/151981
A Bluescreen By Any Other Color
http://blogs.technet.com/b/markrussinovich/archive/2010/12/14/3374820.aspx
Debugging Tools for Windows
http://msdn.microsoft.com/en-us/windows/hardware/gg463009
It is possible to extract the guest (virtual) physical memory using VBoxManage and a debugger.
VBoxManage debugvm TestVm dumpguestcore --filename guest.dump
gdb --core guest.dump
# dump memory [phys-mem-file] 0x0 [size vm-memory]
Afterwards one can search the memory dump for string content.
See also: http://www.halfdog.net/Misc/TipsAndTricks/VirtualBox.html#ExtractGuestPhysicalMemory
The function midiOutGetDevCaps returns a structure MIDIOUTCAPS.
I'd need more specific information when querying a usb midi device on windows xp, in particular I'd need the information displayed under "Location" when opening the respective device using the Device Manager.
I need this information in order to programmatically distinguish between several MIDI Interfaces connected to a computer. Using midiOutGetDevCaps, I uniformly get "USB Audio Device" for every midi usb interface connected to the computer, so distinguishing between the interfaces is impossible.
To make matters worse, this string is localized, so e.g. on a German Windows you'll get "USB Audiogerät" instead of "USB Audio Device".
I guess it depends on how desperate you are. I've had my own run in with USB devices. In my case I needed to enumerate certain USB COM port related devices . . . regardless if they are currently attached to the system or not.
It is all company proprietary code, sorry I cannot post it, but the search for all information regarding USB related devices starts here (Perl):
$hostnamePrefix = "//$hostname/";
my $baseKey = "${hostnamePrefix}HKEY_LOCAL_MACHINE/System/CurrentControlSet/";
my $regVidList = Win32::TieRegistry->new("${baseKey}Enum/USB/", $optionsRef);
If memory serves me it is a reasonably straight forward structure. I believe you actually have to loop through two separate sections of the registry to get everything you need . . . if you are desperate enough to attempt this, I'm happy to answer questions where I can, but posting code would required approval from our legal department. (Not impossible, but it would take weeks to obtain.)
Also, while this will work on XP . . . I have no idea how it will work on Win7. (I don't know either way, nobody has tried it yet that I am aware of.)
Coding this was not that bad (resulting Perl Script is around 1000 lines of code which is almost 50% comments), but working out all the relationships between the keys and the special cases took several days.
i wanna know how can i create a new customize MIB file ?
i wanna create a MIB file and use it in LINUX that with this mib i wanna monitor an application
please help me
thanks
MIB files are created in a simple text editor (following the rules for SMIv2). Then you'll need to turn it into code, modify the code to suit your data, compile it into an agent and run the agent. Then you can use a management application to request the data from the agent.
Net-SNMP is the most popular linux stack for linux, so you might start with it's tutorials at http://www.net-snmp.org/tutorial/
We have an auto update for our software that is installed via USB key (with the auto run). If I wanted to ensure that only authorized USB Keys were used, what's the best way?
Our installer is already signed, and it won't run otherwise. But I'm more wanting to inspect the USB Key for a signed installer, and if it's not there, just ignore, or even "Eject" the USB device.
And I should be able to tell the difference (in code) between a usb storage device, and say a camera, or keyboard.
I'm only wanting to disable non-authorized storage devices.
Thank you for your ideas.
non-authorized storage devices? This depends on how secure you want it to be. For the most secure level, it would consist of:
special firmware written to the flash drive to get extra "meta info" (read: expensive custom manufacturing of flash drives)
special windows driver to read that meta info from the flash drive
your program talking to that device driver to confirm it's authorized.
Or to the least secure level you have these options:
using a hidden file and a special key(possibly hashed time of last filesystem modification or something?) (dd breakable)
dropping below the filesystem level and recreating your own very simple filesystem.. (more security through obscurity though and dd could break that)
Also, for the "most secure" option, you really need a more secure way of running the program than auto-run and a device driver(which could be half-baked to make anything appear authorized). Why do you want it to only update from an authorized flash drive anyway?
You might be able to read the USB drive's serial number (assuming you get USB drives that have serial numbers; not all do). Then your application could call home to get the latest list of authorized serial numbers, and check to see if there is a match.
Earlz response is good, though I don't think you'd need custom manufacturing of flash drives... you would just need flash drives with some sort of unique firmware encrypted identifier. Perhaps something in the Kingston Data Traveler Line might do the trick. (I've never actually used one of these encrypted usb sticks, so I'm a bit foggy on the actual implementation details).