Most of the examples provided for sending SNMP traps are simple ones like the one below.
snmptrap -v 1 -c public host TRAP-TEST-MIB::demotraps localhost 6 17 '' \
SNMPv2-MIB::sysLocation.0 s "Just here"
Take any MIB file, they contain many complex object groups, for example, systemGroup contains sysLocation, sysName, etc.
Could someone help in bringing out examples to show the way how to send snmp traps which includes such OBJECT-GROUPS. Adding one more question here, Does SNMPTRAPD support internationalization?
It is really bad practice to define the SNMP notification (trap or inform) the way that it contains the entire OBJECT GROUP or even worse the entire SNMP table. The reason is that you don't really need all these variables anyway. The other reason is that the packet/PDU is limited by MTU size. So it is possible that you'll not be able to send the data within single UDP packet due to its size.
The proper scenario would be to have few varbinds and you could also initiate some polling cycle to find out what happens if you need more details when you receive such trap.
SNMPTRAPD and NET-SNMP library in general do not support internationalization (UNICODE). The library is limited to ASCII charset only.
There are commercial products on the market including NetDecision TrapVision and some other that fully support UTF-8 internationalization.
As read on topic here How to find the unique serial number of a flash device? and especially here How to get manufacturer serial number of an USB flash drive? I know it is possible to get properties of hardware devices (particularly hard drives and usb drives...) using WMI Win32_PhysicalMedia and Win32_DiskDrive, which I'm getting done successfully.
However, I really want to know about the safety of these informations.
PhysicalMedia property SerialNumber returns the actual serial number of the main hard drive, while using other Win32_LogicalDisk and other calls we can map the drive letter of flash storage to actual Win32_DiskDrive device, and from there read properties like Name, Model, FirmwareRevision, SerialNumber, DeviceID, Manufacturer...
Now, DeviceID is generated by Windows / Pc itself, while SerialNumber should be the one that manufacturer added to the physical flash drive.
Manufacturer in most cases returns "Standard" something, Name is also of no use, while SerialNumber actually gets me a something that looks like unique ID, (I've read that in some cases this is not returned, so PNPDeviceID should be used instead? , Model gives the actual model of the flash drive, and FirmwareRevision just a number that could be used to add safety switch to the licensing, but is not vital.
However, the only one of these that seems / should be actually safe to use is SerialNumber, right?
So, the question here goes: Which level is Win32_DiskDrive actually reading this info from? Is it possible to fake that at all (Ok, letalone the actual lowlevel hacking stuff or driver injection etc...(??)), and if so, how hard it is?
If there's a known way / guide / example, I'd be also happy to read it. (not necessary info looking for here though.)
This is not for intention of bypassing some licensing. I'm making licensing for my SW, and am curious, whether it would be safe enough to use USB drive's SerialNumber property, and lock license against the presence of that USB flash, for which the license was bought for? Basically to use it as kind of a dongle, but not like the dongles actually work (using communication with the actual hardware inside the dongle...)
I know it may not seem as a safe solution, as flash drives dies quite often these days, or get lost etc, but this is just to add an option to my licensing from "Per PC" to "Portable - per USB device".
Thanks for any info!!!
EDIT:
I am completely aware that bypassing these kind of safety switches is very possible. Of course, even Windows itself is not licensed in a way that couldn't be hacked, nor Adobe, ProTools etc, (software that is widely used and costs a lot!).
But that wasn't a real question, and also, that's not the case for me -> the software will not be that expensive and not used by that much people, that I'd be afraid to drag interest in someone who will do extensive programming to make a patch/crack for it. Regular debugger use and workaround is pretty unlikely to be used by regular client who would need the software, ( and also, since it is something to be used in business environment, where stability is vital, I doubt they will really play around that...).
Main point here:
It is possible for sure, but: HOW hard is it to do for a regular person? (I know, the answer is: depending on your code.)
Main question of the post: Is it possible to change the ID on the USB itself, OR to make an app that will fake that data to my app? If it is, I'm sure it might be easier than making a crack/patch, that's why I wanted to know, whether WMI reads explicitly from hardware, or could one make an app that would pass fake data to it?
WMI just returns what the hardware tells it. It's as unique as the hardware. Which ultimately depends on the vendor.
But...
If someone has an administrator account to the computer†, then there are very few things that can be done to keep them from just hooking up the kernel debugger to your program and overriding your checks, or recording the raw USB communication session and replaying it on an unauthorized system. The real dongles do some to mitigate this, by having the hardware generate a response to a particular challenge. The challenge/response changes for each request, so it's not as susceptible to replay attacks, but the debugger tricks still work.
This is the real problem with the serial number approach. Uniqueness is not the primary concern for dongled software. The primary concern is unpredictability.
An illustrative example-
Let's say that I'm a bouncer at an exclusive night club. We're so exclusive that you have to answer a question to get in. You really want to get in, but no one will tell you the answer to the question. One night, you hatch a plan. You hang out in the alley and listen to the conversations that I'm having with the patrons trying to enter the club. It doesn't take you long to realize that I'm asking everyone the exact same question, and you're in. (This is the serial number approach)
After a while, I notice that there are a lot of people coming into the club that I've never seen before, and begin to suspect something. The people we really want to allow in are all given a card with a formula‡ on it. Whenever they come to the door of the club, I give them a number and they apply their formula and tell me the result. Since I also know the formula, I can tell if they are really allowed in. Now, even if you hear the entire challenge and response, without the formula, you aren't getting in. (This is one common approach taken by dongles.)
But what about the debugger? The debugger just made herself the club's owner, fired me, and can come and go as she pleases.
†Or has physical access to the machine and a password reset disk.
‡Stop laughing, this could totally happen. :)
Photo credit: Guillaume Paumier, CC-BY. Found on the Wikimedia Commons 7-Oct-15
Edit to address the question edit:
HOW hard is it to do for a regular person? (I know, the answer is: depending on your code.)
The question is how skilled is the 'regular person'? If you're talking about software/electrical engineers, then this is a trivial task. If you're talking about sales/marketing then it's a challenging task.
Is it possible to change the ID on the USB itself, OR to make an app that will fake that data to my app?
It depends and Yes. Changing the ID on the device itself is possible with some devices, and impossible with others. Software to spoof/man-in-the-middle the USB communication, or to create a virtual USB device is possible.
If it is, I'm sure it might be easier than making a crack/patch, that's why I wanted to know, whether WMI reads explicitly from hardware, or could one make an app that would pass fake data to it?
As I led with above, WMI reads from the hardware. This can be intercepted or bypassed.
Some ways to bypass the check:
Make a virtual USB device
Modify the USB MSD device driver to report the same serial number for all devices.
Build hardware using commercially available cheap host controllers that identifies with the same information as the authorized device. ($10 worth of raw components and a little bit of time.)
Redirect the system calls to/from USB to a compromised library.
Note also that:
Some places have restrictions on USB storage devices, ranging from discouraging their use, to outright bans. This would prevent your software from being used in sensitive computing environments processing private data, like credit cards, PII, trade secrets, classified information, etc. (In the US many governmental agencies have outright bans on USB storage devices, and block the install of any MSD.)
The Mass Storage specification doesn't require serial numbers. They are usually there, but they don't have to be, and many low-cost vendors
A USB PKI token costs a little bit more, but would probably do what you want. Here's an example from Safenet (Disclaimer: I am in no way affiliated with Safenet Inc, and you should evaluate all the possible options from all vendors. I suggested this because it was the first thing that came up through CDW, and the price was ~$30)
I am using NET-SNMP (V5.6.1.1) on windows to read my MIB with snmpget & snmpwalk. When I try accessing the MIB I can only see some of the elements. I know the MIB is good since my colleague can extract the same revision of the MIB from the repository and can see all elements within the MIB. We are using the same SNMP command syntax to query the data. I have compared the MIB and snmp.conf files between his machine and mine and they are identical, so can only assume that it is due to a difference in the configuration of our respective PCs. I’ve also checked for any differences in the Environment Variables between our machines, but can see nothing obvious. Is there anything in the machine configuration that might explain why I can only see part of the MIB?
Edit: The MIB is implemented as a single bespoke executable, with the data held in a number of tables, for example:
mibTableA.parameter1
mibTableA.parameter2
mibTableA.parameter3
mibTableB.parameter4
mibTableB.parameter5
mibTableC.parameter6
mibTableC.parameter7
mibTableC.parameter8
None of these tables are dependant upon the availability of system hardware, etc. These tables can also be accesses via an RTA interface using PSQL queries, and using the RTA interface on both my machine and my colleague’s machines, I can see all the tables/parameters. Yet, for instance, accessing the MIB via SNMP I can only see the mibTableA on my machine.
First you need to identify which are the missing ones on your box. Show some examples in your question so that others can guess what can be the cause.
Second, SNMP query result is indeed machine dependent. For example, if your machine has less network adapters than your friend's, then it is reasonable some objects are missing.
I found the problem. There are some scalar fields in the MIB which define the table sizes and these had not been initialised correctly, but instead were picking up old values stored in tables in a C:\Documents and Settings\user\Application Data folder. Hence the difference in behaviour between my machine and my colleagues.
I want to implement SNMP-agent for PowerPC board using net-snmp.
Previously it was implemented using SMASH. SMASH has a parser
which could read MIB and generate C code (blank function imlementation)
How do I get started?
Try to look at mib2c tool from net-snmp. It will generate the snmp agent C code from the MIB. Then you have to only fulfill the return values to SNMP requests. Skeleton of responding to SNMP requests (get, set, get-next) are automatically done by generating.
Do you have a look to Writing a MIB module tutorial.
I took a different approach to this. In order to better integrate with my C++ ecosystem, and to obtain greater flexibility (particularly at scale), I:
Had a pre-build step parse the result of snmptranslate (that is, the MIB tree) into a bunch of C++ maps and other containers for use in code
Borrowed Net-SNMP's transport and PDU building functions
But serviced requests myself upon receipt, using my C++ maps and the data already available to my application
This made notification generation trivial (I just needed some variant types to generate varbinds, a bit of PDU construction and then left the rest to Net-SNMP's transport feature), although for requests I did then have to implement table walking myself (and GetNext/GetBulk/Set are not trivial unless you avoid all tables, or at least avoid composite-index tables).
The result is a fast, robust and scalable SNMP agent with expressive code that's easy to maintain and to extend.
You don't say you're using C++, but this does give an idea of how you can cherry-pick Net-SNMP functionality without necessarily buying into its entire ecosystem.
Do note that I have no idea how SNMPv3 would fit into this model; I cleverly left the company before it became my problem. :)
I know a little about SNMP, but not enough. I need to develop an application that can read standard SNMP MIBs and read/write the various properties. The network end is no problem, but the actual MIBs and exactly what they may contain is something of a black art to me.
I believe I should be able to use LIBSMI to 'parse' the MIBs, but I don't really understand what the output of the 'parser' is going to be, and how best to use it.
All suggestions welcome...
At the risk of throwing you in the deep end, you might want to take a look at net-snmp. The default installation contains a number of standard mibs with their associated implementation. It also contains a utility (mib2c) that will generate boilerplate code from your mib files.
Once you've read your way through a couple of mibs you should have no trouble familiarising yourself with the way that snmp does things.
Most standard MIB documents were defined in corresponding RFCs published at IETF.
http://www.ietf.org/
Please go to this site to find more details.
Muonics Mib Smithy User Guide provides a good overview of how to build a MIB, which can help you understand the necessary elements for parsing.
You should also look at the ASN.1 ITU specification X.690, because that is the language SNMP is defined in. It also helps if you scour the SNMP RFCs for any Bachus-Naur formatting in the SNMP RFCs. I'm going to suggest you start with RFC3642 and RFC2252.