DLL injection tool to unlock guest VMs | Hacker News Reader

DLL injection tool to unlock guest VMs

secforce.com

17 pointsalter819 comments

Why don't they just edit the password directly in the disk image (like this: http://libguestfs.org/virt-edit.1.html#non-interactive-editi... )?

I wrote a neat little tool called virt-dmesg which reads rather than writes kernel memory in VMs in order to pull out things like the kernel messages (dmesg): http://people.redhat.com/~rjones/virt-dmesg/

Also, since when is "Ubuntu" synonymous with Linux?

I think this is for engagements where they may not want to stop/reboot the virtual machine. This tool claims to patch memory directly, so a running VM would be the target. Perhaps the vm they want to connect to has some existing connections of some sort that they don't want to break, alerting that would happen if it were restarted, or unlocked keys in memory (think ssh agents). One of the first thing virt-edit says is "You must not use virt-edit on live virtual machines."

Remembering the "evil" discussion from not too long ago, these two statements are not compatible:

"This tool is for legal purposes only. The code is released under GPLv3 license."

I beg to differ (IANAL however). "Legal" is a legally defined term. It varies from country to country and may vary within a country and changes from time to time due to legislation and court actions, but it is defined for a given place and a given time.

"Evil" has no legal definition.

I think the point was that the GPL does not allow restrictions on fields of endeavour, and "legal purposes only" is such a restriction. Although GPLv3 restricts DRM.

The copyright holder of a program can legally license their program under the terms of the GPL along with extra terms of their choosing. Of course, the program's overall license may be incompatible with the plain GPL, and the program's adoption may be hindered.

The fields of endeavor stuff is from the Debian Free Software Guidelines and similar documents.

The GPL strictly dictates what kind of "extra terms" are allowed. If the author attempts to add non-allowed terms then the GPL itself is invalidated, according to its own statements.

I think he intended to reply the other comment comparing this to the evil issue. "This tool is for legal purposes" it doesn't restrict the use of the software (any legal use of the software is still legal, illegal uses are now just illegal in more than one way). The purpose of is to indemnify the author against claims when the software is used for illegal purposes. Whether it actually makes any difference (it's implied anyway) is another question.

You've taken the quote out of context, what he actually says is "This tool is for legal purposes only". That's quite clearly intended as a restriction on its use. The problem being that if the user does something illegal in a very minor way then he's opened himself up to a potentially large copyright suit because he's violated the license.

The point of the GPL is to stop the copyright holder from dictating what you can and can't do via the threat of a copyright suit. Extra clauses like this go against both the letter and the spirit of the GPL.

Either his extra clause is nullified by the GPL, in which case he's only created the illusion of legal indemnity for himself, or his extra clause is accepted, and the GPL is rejected, in which case he looses all of the important legal protections such as the warranty disclaimer. Either way his attempt to protect himself has failed.

That depends whether the first statement is meant to be a restriction on use or just a disclaimer about the tool's intended purpose.

I think it's this: "Evil, or why Douglas Crockford is harmful to Free Software". http://news.ycombinator.com/item?id=4762035

IANAL but I think that better wording might be, "This is GPL but we created it for the purpose of legal uses and don't condone other use".

> This tool is for legal purposes only.

This is a given. Every single tool that exists is for legal purposes only. Almost nobody says it because it is a given.

What nonsense. It is not a violation of some sort of "terms of use" equivalent to use a power-drill to open a safe you stole. The drill is for whatever you want to use it for, illegal uses are covered by laws that are actually about those illegal acts themselves.

What I find amusing though is people who get bent out of shape by these sorts of clauses. Certainly "evil" people and criminals wouldn't care about these clauses, the only people that are bothered are people like the Debian project. The license is therefore effectively a license that only gives you permission to use the tool if you don't particularly take the license seriously. It is a license that forbids (rather than commercial use) blowhard use (probably commercial use as well, because of that). Brilliant that.

Reminds me of the excellent "Chicken Dance License".

> illegal uses are covered by laws that are actually about those illegal acts themselves.

My point exactly. Which is why I'm so confused why you think you're disagreeing with me. Maybe you need to reread my post?

Laws against using something in a certain way does not mean that the something is "not for" illegal things. What things are for and what they can be legally used for are normally quite orthogonal.

A "no illegal uses" licensing term is by no means an unstated default; it is in fact a rather unusual concept.

As fair as I can tell your interpretation of the phrasing is that it implies and only means to imply "Illegal things are illegal", which is a senseless tautology. In reality this phrasing says more than that.

I'm not sure why a penetration tester would bother to run this against a VM when they had already obtained a privilege level that allows memory modification of the hypervisor process. That level of access is already the equivalent of physical access.

Surely a tool like this is exactly how you translate that 'physical access' into a useful result within the target VM? If that VM is handling the data you're tasked with stealing, bypassing auth and getting a root-shell equivalent which you can use to exfiltrate is probably just as or more useful than taking a memory image at the hypervisor.

The "It's all over when they have physical access" idea always seemed to me like "Once the thief steals your safe, they can probably get it open eventually", but they still do need to get it open. Yes, you might succeed eventually with just a hand-drill and hacksaw, but a set of grinding tools and cutting torch is going to make it much easier and faster.

I'm not sure that it's as tough as your analogy makes out. I'd say something like "Once the thief notices the safe door is open they can probably take your secrets out of it" :)

However, I agree that there are probably some cases where the secrets are in memory rather than on the disk where this approach would be very useful.

The typical case though is reboot to alternative media or single user mode.

Reply on news.ycombinator.com