If I want to realize a profiler using byte code instrumentation, should I write a native agent using JVMTI or should I write a java agent using the java.lang.instrument package?
If I want to use libraries like ASM - which seems to be mandatory if you want to create a serious profiler - I have to use a java agent. Which confuses me, since I thought a native agent can do everything what a java agent can do and more. But to me, it seems easier writing a java agent.
Are there alternatives? Should one use java agent and native agent combined anyway?
Nearly everyone writes a java agent (with ASM or BCEL) as they don't want to have to write a C/C++ bytecode instrumentor from scratch as there are none publicly available.
What you won't be able to do is instrument and profile/monitor the primordial JVM, and accessing native functions requires JNI calls. There are also several JVMTI calls that may be unavailable to you (if memory serves).
I wrote my own instrumentor in C several years ago, and I'm in the process of writing a new one which I hope to open source ( depending on my evil overlords :-) )
How about a half way house, a separate pre-started JVM that your native agent sends bytecode to. In that JVM your easy-peasy to write ASM based instrumentor does the hard work and sends the resulting bytecode back to the native agent over the wire. Yeah it seems a bit over-complicated but it's easier that writing your own BCI library.
Related
I have developed a tool that loads in an configuration file at runtime. Some of the values are encrypted with an AES key.
The tool will be scheduled to run on a regular basis from a remote machine. What is an acceptable way to provide the decryption key to the program. It has a command line interface which I can pass it through. I can currently see three options
Provide the full key via CLI, meaning the key is available in the clear at OS config level (i.e. CronJob)
Hardcode the key into the binary via source code. Not a good idea for a number of reasons. (Decompiling and less portable)
Use a combination of 1 and 2 i.e. Have a base key in exe and then accept partial key via CLI. This way I can use the same build for multiple machines, but it doesn't solve the problem of decompiling the exe.
It is worth noting that I am not too worried about decompiling the exe to get key. If i'm sure there are ways I could address via obfuscation etc.
Ultimately if I was really conscious I wouldn't be storing the password anywhere.
I'd like to hear what is considered best practice. Thanks.
I have added the Go tag because the tool is written in Go, just in case there is a magical Go package that might help, other than that, this question is not specific to a technology really.
UPDATE:: I am trying to protect the key from external attackers. Not the regular physical user of the machine.
Best practice for this kind of system is one of two things:
A sysadmin authenticates during startup, providing a password at the console. This is often extremely inconvenient, but is pretty easy to implement.
A hardware device is used to hold the credential. The most common and effective are called HSMs (Hardware Security Modules). They come in all kinds of formats, from USB keys to plug-in boards to external rack-mounted devices. HSMs come with their own API that you would need to interface with. The main feature of an HSM is that it never divulges its key, and it has physical safeguards to protect against it being extracted. Your app sends it some data and it signs the data and returns it. That proves that that the hardware module was connected to this machine.
For specific OSes, you can make use of the local secure credential storage, which can provide some reasonable protection. Windows and OS X in particular have these, generally keyed to some credential the admin is required to type at startup. I'm not aware of a particularly effective one for Linux, and in general this is pretty inconvenient in a server setting (because of manual sysadmin intervention).
In every case that I've worked on, an HSM was the best solution in the end. For simple uses (like starting an application), you can get them for a few hundred bucks. For a little more "roll-your-own," I've seen them as cheap as $50. (I'm not reviewing these particularly. I've mostly worked with a bit more expensive ones, but the basic idea is the same.)
I have developed a Client/Server application for IM with Qt. So far messages are sent and displayed at the client side, but when the program is closed the messages are no longer available since a proper storage is missing.
I would like to keep the messages on the client devices and avoid to store everything on the server. I don't want to use a DB either since it needs to be installed and I would like to keep everything quite easy.
Therefore I was thinking of simply storing everything in an encrypted file, but I couldn't think of a proper format to do that.
Has anyone experience with that or any suggestions how to save the messages from different clients?
You do have a concern with data integrity in face of unplanned termination of your software, due to bugs in your code, transient hardware errors, power outages, etc. That's the problem that everyone using "plain files" usually ignores, as it's a hard problem to solve and requires extensive testing and know-how.
That's why you should use an embedded database. It will solve that, and many other problems as well. SQLite is a de-facto standard for applications such as yours. You can add any encryption you wish, as SQLite provides hooks that let you implement writing and reading of the pages. You'd do the encryption there.
One little-appreciated aspect of SQLite specifically is the amount of testing it gets during development. The test harness, most of it non-public, is probably worth way more than the published SQLite code (>1M USD). SQLite is used in aerospace applications, e.g. IIRC in code classified as DAL-B under DO-178B.
what's the proper way to capture biometric information (pressure, speed...) by signing with a stylus on a canvas developed in a JSP web Page
Alright, since no one else has attempted to answer this question, I shall elaborate on my comment and opefully it will serve as an answer to others as well.
First, Java Server Pages (JSP) is a server-side language. It is meant to run on the web-server and not on the user's browser. The same goes for other server-side languages like PHP and ASP.
So a server-side language is not able to directly interact with devices (keyboard, scanners, cameras, etc). Only when the data is submitted by the browser or client program, the server receives it for processing.
For a device to receive input, there are two key pieces of software needed.
The device driver: which must be installed on the user's machine
The application program to capture inputs and do any processing.
If either one is missing, the device cannot function. And then there's another issues. Depending on the device, there's various feedback from the driver/API that should go back to the application that reads it. For example, if a fingerprint scan was not very successful for some reason, the scanner should tell this to the user. So again, there's the need for interactivity between the device and the user's application.
Thus, using any server-side language is out of the question for such applicatoins.
Now, in order to make this possible, you may use a client-side program. Here are some options.
A native application in VB, C/C++, Pascal or other language. If this is an option, the user must install this application on their computer.
A browser-based program. This can be a program created using JAVA (not Javascript or JSP), or ActiveX component. ActiveX is largely OS/browser dependent. And the TRUTH is that even Java is not truly platform independent when it comes to different operating systems. There are some technical differences that you'll need to look into. But for the most part of interactivity and high-level operations, yes, Java is more platform-independent than the others. But on a personal note, Java is my worst language. I try not to use it anywhere anymore. That's a different story.
In both options above, every client machine must have their own proprietory drivers and often some sort of API for browser integration.
A year or so ago, I had to program a Bio-Mini fingerprint scanner using VB. It was all sweet in the beginning. Then due to the restrictions of networkability and concurrent usage, the drivers/SDK could not take the load and things were going wrong. By the way, the drivers/SDK were meant for MS-Access. Knowing that the DB was the problem, I started to port this to MySQL. And it was a severe climb from there. I had to do a near-rewrite of the SDK for capturing and comparing data using arrays in VB. And to make things worst, the device was changed and things went wrong again. But do note that the new device was from the same manufacturer.
So keep in mind that even a simple change like that can cause a problem.
I have hermesJMS setup and soapUI. I'd like a small script that can go in either via hermesJMS or another way to retrieve the queue depth of a particular queue.
Is there a way to do this easily?
Thanks
The JMS specification does not provide an API for object inquiry, however IBM provides one using native Java classes and the C API using Programmable Command Formats, or PCF for short. The PCF reference docs are here.
If you have installed the WMQ client code (free download with registration) you will have the sample programs on your laptop. By default, these reside in C:\Program Files (x86)\IBM\WebSphere MQ\tools\pcf\samples for Windows or in /opt/mqm/samp/ for UNIX/Linux. Take a look at PCF_ListQueueNames.java for a starting point. If you were to substitute MQCMD_INQUIRE_Q for MQCMD_INQUIRE_Q_NAMES in that program you'd be very close to what you require.
Alternatively since you requested alternatives, you might look at SupportPac MO72. This SupportPac can be used as a client version of runmqsc so that you can, from a central server, write scripts that query your entire WMQ network. Of course, it also works in local bindings mode. Among the other features that make MO72 great for scripting is an option to format output to one line per object. This lets you grep out the line of interest, then strip out the value of interest.
I was looking on how the twisted and node.js frameworks work and I am
trying to understand exactly how the operating system supports I/O
operations using callbacks.
I understand it's good because we need less threads because we don't
need to have blocked threads waiting for I/O operations. But something
has to call the callback once the I/O is finished.
How is this implemented by the operating system?
One approach is to have the OS attach information about anyone waiting for a callback to the relevant data structure, such as the in-kernel equivalent of the file descriptor you're waiting for read notification about. When something happens to that file descriptor, the OS scans the waiters to see if any should be notified. If they should, then it does so. You can read about one implementation of this in Lemon's paper introducing FreeBSD's kqueue mechanism. See in particular section 6, "Implementation", subsections 3 and 4, "Activity on Event Source" and "Delivery".
This is solved in OS by using "I/O event notification facilities/interfaces", e.g epoll, poll, kqueue or select.
Take a look at deft, and especially its' io/event loop for a concrete example how the "notification systems" mentioned above are used. (java.nio.channels.Selector is the java nio way to provide an abstraction for this.)
disclaimer: im a deft committer