I Have some questions:
In in my system (es. windows), have many DLL extension agent attached with snmp service
When a request comes to the service snmp "Snmp.exe" it sends the request to all agents or only one?
How do I know which of them can answer the request?
Thanks
The main agent's job is to handle registrations for SNMP and each DLL will register the information it is able to serve. The information in SNMP is registered under a tree-structure represented by OIDs. The agent is smart enough to know which DLL (or subagent) is able to serve up a request based on the incoming OID being asked about.
You might consider reading RFC2741 which describes the "AgentX" protocol. Although this talks about the protocol and not a DLL, the fundamental way it works under the hood should be pretty similar.
#Wes response is OK. Here is just a complement. As discribed in "How to add an SNMP extension agent to the NT registry", you can find the DLL extension in the registry entries pointed by the one in :
Windows Server NT4 to Windows Server 2003 R2 (Workstatio, W2K, XP):
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SNMP\Parameter\ExtensionAgents
Begining Windows 2008 (Vista) :
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SNMP\Parameters\ExtensionAgents
Each DLL expose SnmpExtensionInit function which report the supportedView as an OID.
BOOL WINAPI SnmpExtensionInit (DWORD dwTimeZeroReference,
HANDLE *hPollForTrapEvent,
AsnObjectIdentifier *supportedView);
I write a wrapper program that just load the DLL and call the function just to report the response, you can download and try slxSNMPInfo if you want. Sorry the site is in french, but the strings in the EXE files are in english.
Related
To send a fax internally, we have been using the following Coldfusion code to create the object that handles the fax:
<cfobject type="COM" action="Create" name="objFaxServer"
class="FaxServer.FaxServer.1">
While we are remaining on ColdFusion 8, we are moving our server to Windows Server 2008, which is a 64-bit system. As a result, we are now unable to call COM objects, such as FaxServer, to handle such requests. I'm looking for an internal alternative (no 3rd party like InterFax.net) but I have not been able to find one, nor any advice to handle this situation.
Any suggestions on what to use or how to internally send out faxes via coldfusion?
I would use an email to fax gateway such as efax. This makes the whole process very simple you just send an email with the phone number in the subject field.
I know you said internally, but I think externally is better :)
I have a problem that probably is not unique, but certainly does not seem to be widely reported.
I need a method to ping a windows service that will tell me if it has stalled out, even if windows is reporting that it is running.
I would prefer to use have a Perl solution but would accept any solution that someone can come up with.
Thanks,
Jeremy
What service are you dealing with? I don't think there is any generic solution to your question if the Services control panel doesn't indicate a problem. In order to detect a running-but-no-longer-functioning-properly process, you have to know what "functioning properly" looks like.
You could use the Win32::Service module
use Win32::Service;
GetStatus(hostName, serviceName, status);
From http://metacpan.org/pod/Win32::Service:
Get the status of a service. The third argument must be a hash reference that will be populated with entries corresponding to the SERVICE_STATUS structure of the Win32 API. See the Win32 Platform SDK documentation for details of this structure. You can even grab the service with GetServices(hostName, hashref).
Right now, my application is using the c-ares asynchronous DNS resolver library on Windows below cURL, and I have users complaining that it behaves differently from other windows apps. One particular user said that "other applications are using the Microsoft DNS client" and experiences no problems.
cURL itself has an asynchronous DNS implementation that uses getaddrinfo() in a thread. My guess is that would be equivalent behavior to using the "DNS Client" and its host of functions (e.g. DnsQuery?)
So, dear Lazyweb, I ask if there is a tangible difference between the behavior of getaddrinfo() vs. using the actual Dns* APIs from the Win32 API.
Looking at the sources it seems ares actually implements the dns protocol for querying host names (and doesn't directly call getaddrinfo) - I'd expect that to miss out on things like WINS lookups, and god knows what other kind of stuff windows can do to look up names.
The easiest way to do DNS queries on Windows is to use DNSQuery (and derivated functions, utf8, wbytes, ansi). Unless you need asynchronous resolution, in this case I would recommend to keep using c-ares or other similar API.
I'm not sure about WINS or other windows specific resolution (not part of DNS specs) not being covered by c-ares. It would help if you can give us some examples, maybe we can get them implemented in c-ares as well.
My company is looking at implementing a new VPN solution, but require that the connection be maintained programatically by our software. The VPN solution consists of a background service that seems to manage the physical connection and a command line/GUI utilty that initiates the request to connect/disconnect. I am looking for a way to "spy" on the API calls between the front-end utilty and back-end service so that our software can make the same calls to the service. Are there any recommended software solutions or methods to do this?
Typically, communications between a front-end application and back-end service are done through some form of IPC (sockets, named pipes, etc.) or through custom messages sent through the Service Control Manager. You'll probably need to find out which method this solution uses, and work from there - though if it's encrypted communication over a socket, this could be difficult.
Like Harper Shelby said, it could be very difficult, but you may start with filemon, which can tell you when certain processes create or write to files, regmon, which can do the same for registry writes and reads, and wireshark to monitor the network traffic. This can get you some data, but even with the data, it may be too difficult to interpret in a manner that would allow you to make the same calls.
I don't understand why you want to replace the utility, instead of simply running the utility from your application.
Anyway, you can run "dumpbin /imports whatevertheutilitynameis.exe" to see the static list of API function names to which the utility is linked; this doesn't show the sequence in which they're called, nor the parameter values.
You can then use a system debugger (e.g. Winice or whatever its more modern equivalent might be) to set breakpoints on these API, so that you break into the debugger (and can then inspect parameter values) when the utility invokes these APIs.
You might be able to glean some information using tools such as Spy++ to look at Windows messages. Debugging/tracing tools (Windbg, or etc.) may allow you to see API calls that are in process. The Sysinternals tools can show you system information to some degree of detail of usage.
Although I would recommend against this for the most part -- is it possible to contact the solution provider and get documentation? One reason for that is fragility -- if a vendor is not expecting users to utilize that aspect of the interface, they are more likely to change it without notice.
I have a windows exe app that used to sends packets to a server in the clear. This app (lets call it the client app) is definitely close sourced, but some clever hacker hex-edited the binary, and made it send packets that are scrambled.
Now, obviously, those packets are scrambled in a way that is decipherable (otherwise the server would not be able to understand it), but what I wanted to do is to write an emulator that emulates this binary app, sending the same packets to the server, and being able to unscramble the response (if it is scrambled).
The hex-ed client required an extra dll in order to run, which the old client did not. I am assuming that somehow the hex-ed client managed to load that dll (lets call it client.dll) and the function of that dll is to implement the scrambling/unscrambling, by hooking into some windows api that rerouted all packets sent from the client.exe process.
If there are anyone who can direct me on how to even get started on working out how this all works, and how I can reverse engineer the scrambing, that would be really appreciated.
I have no idea what kind of information to provide, but if there is any lacking, just reply, and I will post with more details, and if anyone wants the binaries, I m happy to provide it.
binary download for any interested parties:
http://dl.getdropbox.com/u/46623/client.dll
http://dl.getdropbox.com/u/46623/newClient.exe
http://dl.getdropbox.com/u/46623/originalClient.exe
These wont run because the resource files are required - they are about 3 gigs, so too big to upload anywhere. Names have been changed to protect the guilty =) , but that probably doesnt protect the name of the dll...
I'm assuming that the person which coded this hook which adds encryption to the packet I/O for the aforementioned program has either hooked the relevant Windows' socket APIs (WSASend, send, etc) or hooked the internal program functions used to send/receive data.
This being said, I'd suggest you use a hook detection program (e.g. RkUnhooker) to find out what is actually being hooked. Once you know what APIs are hooked you should also know where these hooks are going and from there on in you'll have to manually reverse engineer the hook functions.
As for the subject of learning how to do this, I couldn't direct you to just one tutorial to teach you everything but I highly suggest you look at the Tuts4You site, it has a plethora of tutorials which would meet all of your needs.
If possible, upload a copy of the edited client & the hook DLL, if I have the time I'll code you replica encryption & decryption functions.
You need to hook the functions exported by the additional DLL and look into the functions being called and the parameters being passed to them. This is not going to be easy since you do not have type information (e.g. the function signatures for the DLL exports.)
Look here for some information on API hooking. You will also need a good debugger try Windbg from microsoft.
As far as I can see the only option you have here is black box testing ie give known input to both systems and compare the responses against each other to find the differences and similarities.
+--------------+
Input--------->| Original App |--------->Response1
+--------------+
+------------+
Input--------->| Modded App |--------->Response2
+------------+
Now once you figure out how to use the functions from the additional dll you can use it yourself in the same way the original app does.