Autotype doesn't work if target window is VirtualBox instance

[OlegTheCat]

Expected Behavior

Autotype sequence should execute.

Current Behavior

Non-whitespace characters are not typed, while whitespaces (at least tabs and newlines) are inserted.

Steps to Reproduce (for bugs)

1. Install VirtualBox
2. Install Ubuntu 16.04 and guest additions in VirtualBox
3. Focus on guest OS
4. Switch to KeePassXC on host OS
5. Perform auto-type of some entry

Context

I use virtual machine with some specific version of Firefox to log into some website that supports only this specific version. I don't want to perform full setup of KeePassXC (and Dropbox) there, but just use it from host OS.

Debug Info

KeePassXC - Version 2.3.1
Revision: 2fcaeea

Libraries:

• Qt 5.9.3
• libgcrypt 1.8.2

Operating system: macOS High Sierra (10.13)
CPU architecture: x86_64
Kernel: darwin 17.3.0

Enabled extensions:

• Auto-Type
• Browser Integration
• Legacy Browser Integration (KeePassHTTP)
• SSH Agent
• YubiKey

[droidmonkey]

There is absolutely no way around this. VM's capture your keyboard and are necessarily isolated from the host machine. Even if it looks seemless when you use it...

[droidmonkey]

On second read i didn't realize that (some?) whitespace characters are typed. To what extent does that occur? All whitespace, only some, need now info.

[weslly]

I tested it on VMWare but it replaced all characters with a, which makes sense because unlike Linux/XCB, macOS's autotype implementation sends the character with the virtual keycode hardcoded as a (0):

On most apps it really doesn't matter since they usually get the character instead of the keycode so the system's keyboard layout isn't ignored, but VMWare and possibly VirtualBox seem to ignore the layout and send the keycode input directly to the guest OS.

[hifi]

I have worked around with with virt-manager on Linux by focusing the window from the title bar and executing the sequence on the main window rather than having my mouse/focus inside the VM. This works with VNC windows as well.

[Linden-Ryuujin]

I'm also seeing this on my ParallelsVMs - although the titlebar work around doesn't appear to help (I'm also getting on all display modes - Coherence, Full Screen, and windowed) .

[jovandeginste]

I see this same behaviour when using NoMachine (a remote desktop client) on Windows, but not when using this client on Linux.

The NoMachine dialogs (password to connect to the desktop server) work as expected, but when entering passwords from the Windows client into remote windows, only tabs and newlines seems to be entered.

I created a test account with spaces in the username and password field for experimenting, and I used a hexdump running in a terminal for verification. I used the right-click+"perform auto-type" method.

On Windows:

$ hexdump -xc
	
0000000    0a09                                                        
0000000  \t  \n                                                        
0000002

On Linux:

$ hexdump -xc
test username	test password
0000000    6574    7473    7520    6573    6e72    6d61    0965    6574
0000000   t   e   s   t       u   s   e   r   n   a   m   e  \t   t   e
0000010    7473    7020    7361    7773    726f    0a64                
0000010   s   t       p   a   s   s   w   o   r   d  \n                
000001c

I also tried adding some extra data to the auto-type sequence, but the result was the same:

{USERNAME}{TAB}ABC{PASSWORD}{ENTER}ABC still gave only \t\n

[droidmonkey]

Cool test, great idea! I wonder if this is a security feature in Windows...

[jovandeginste]

@droidmonkey It does work almost perfectly with KeePass Professional 2; I was trying to migrate to KeePassXC, but some things kept me back. Some are fixed (ssh agent support) some not (yet)

With KeePass 2, some characters don't come through. I type azerty, and the special characters come through as if it were typed on qwerty (@ vs 2 etc). Letters are correct, so no q instead of a.

[AliceOrwell]

I'm also having an issue auto-typing to a virtual machine but my results are a tad different to that others are experiencing.

Using KeePassXC on a Windows host to Auto-Type to a VirtualBox Linux guest results in a jumble of text and cursor interactions which suggests keys are not getting mapped correctly e.g. using an Auto-Type sequence of {PASSWORD} and the test password 1234567890qwerty produces nm,./* b. With additional playing around I found O maps to 1, I maps to 9, R is the Insert key, and W is the F11 key.

Both host and guest are using a QWERTY (UK) keyboard layout so regular, manual typing produces correct results, thus I don't think it's me doing something massively wrong.

KeePassXC 2.3.4
VirtualBox v6.0.4
Host: Windows 10
Guest: Lubuntu 18.04 LTS with VirtualBox's Guest Additions v6.0.4 installed

[Muratthi]

Any solution for this behavior ?

[IDESHAIES]

With KeePass v2.38 it works well over Microsoft RDP but not over VmWare Blast protocol.

[HezV1]

Can confirm the "All a's" issue is still happening on OSX Mojave with KeepassXCv2.5.1 and Fusion 11.1.1.

Will be testing on Catalina set up next.

[parodymshifter]

Also happens on VNC windows.

…

On Dec 16, 2019, at 4:18 PM, conrad-r-hoffman ***@***.***> wrote: Can confirm the "All a's" issue is still happening on OSX Mojave with KeepassXCv2.5.1 and Fusion 11.1.1. Will be testing on Catalina set up next. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[randoogle]

Interesting, I'm running into something that feels related, but most of my keys work. So far the only ones that don't are ()<
Left and right parenthesis don't get typed at all in my VirtualBox VM, but for some reason < gets replaced with \

Running Windows guest with Fedora 31 Silverblue host. KeePassXC is a flatpak from flathub. Confirmed that at least the parenthesis issue is also happening to a coworker running Fedora host and Windows guest (don't know the specifics).

I know it's not exactly the same symptoms, and I just realized that this is exactly like #3320, but #3320 doesn't mention < getting replaced with \, so I thought I'd still post this.

[randoogle]

I'm finding now that this same exact* behavior happens within a VMWare web console and in an RDP session to a Windows server through Remmina. So, it seems to be related to any time an app is trying to capture keystrokes.

*exact, except that < works in VMWare web console instead of getting replaced by \.

[Vskilet]

It seems that issue is the reason why #4149 was closed. So this bug (or maybe it's a feature ^^) is also present on a Windows 10 when I performed my shortcut to auto-type my password in a VcXsrv windows that display a Linux desktop : the password isn't send but there is a carriage return.

I don't known if this remarks are helpful but Auto-type is functional on Keepass 2.45.
I'm currently using KeepassXC 2.5.4.

[chenxiaolong]

I originally posted this in #6566 (comment), but was asked to post here instead. I'll try implementing a fix for the Windows SendInput-based implementation this week. (I won't attempt to address this for other platforms though since I only use Windows and Linux w/Wayland).

At least on Windows, it seems the behavior difference between KeePassXC and KeePass2 is different due to how SendInput is being called. (I can move this to a separate issue if needed since the OP is running Ubuntu and I'm not sure that the reason we're seeing the same issue is from the same code.)

For the password TeSt:

KeePassXC sends (with KEYEVENTF_UNICODE):

• T (84) down
• T (84) up
• e (101) down
• e (101) up
• S (83) down
• S (83) up
• t (116) down
• t (116) up

KeePass2 sends (without KEYEVENTF_UNICODE):

• VK_LSHIFT down
• T (84) down
• T (84) up
• VK_LSHIFT up
• E (69) down
• E (69) up
• VK_LSHIFT down
• S (83) down
• S (83) up
• VK_LSHIFT up
• T (84) down
• T (84) up

Looks like KeePass2's SendInputExt.TrySendCharByKeypresses function tries to split out the modifiers like this using the VkKeyScan API. If that doesn't work, then it uses the same KEYEVENTF_UNICODE method that KeePassXC does. I assume that this difference matters to applications that are able to detect raw key presses (like VM/physical server consoles)?

EDIT: The Supermicro HTML5 IPMI console uses an old version noVNC library, which explicitly lowercases the inputted character if the javascript KeyboardEvent.shiftKey property says that shift is not pressed: https://github.com/novnc/noVNC/blob/e8986fa0692705fa890aed02e08b6844e535eb06/include/keyboard.js#L208-L210.

It would be awesome if KeePassXC could support sending scan-code-based events, though it would primarily be used for working around broken applications and I can definitely see that being a maintenance burden.

[droidmonkey]

So I took a few minutes to look into this on Windows and.... this code works!!

void AutoTypePlatformWin::sendChar(const QChar& ch, bool isKeyDown)
{
    DWORD nativeFlags = KEYEVENTF_SCANCODE;
    if (!isKeyDown) {
        nativeFlags |= KEYEVENTF_KEYUP;
    }

    auto vkey = VkKeyScanExW(ch.unicode(), GetKeyboardLayout(0));
    if (vkey == -1) {
		// VKey not found, send as Unicode character
        nativeFlags = KEYEVENTF_UNICODE;
        if (!isKeyDown) {
            nativeFlags |= KEYEVENTF_KEYUP;
        }

        INPUT in;
        in.type = INPUT_KEYBOARD;
        in.ki.wVk = 0;
        in.ki.wScan = ch.unicode();
        in.ki.dwFlags = nativeFlags;
        in.ki.time = 0;
        in.ki.dwExtraInfo = ::GetMessageExtraInfo();
        ::SendInput(1, &in, sizeof(INPUT));
        return;
    }

	// Hold shift down if VKey indicates it's required
    if (HIBYTE(vkey) & 0x1) {
        sendKey(Qt::Key_Shift, true);
    }

    INPUT in;
    in.type = INPUT_KEYBOARD;
    in.ki.wVk = 0;
    in.ki.wScan = MapVirtualKey(LOBYTE(vkey), MAPVK_VK_TO_VSC);
    in.ki.dwFlags = nativeFlags;
    in.ki.time = 0;
    in.ki.dwExtraInfo = ::GetMessageExtraInfo();

    ::SendInput(1, &in, sizeof(INPUT));

    if (HIBYTE(vkey) & 0x1) {
        sendKey(Qt::Key_Shift, false);
    }
}

This does not send unicode or extended ascii characters to VirtualBox or similar, but that can be worked out later.

[chenxiaolong]

Thanks for the quick implementation! I can scrap what I was working on then😄

I gave it a try and can confirm that it works on the Supermicro IPMI console (Firefox HTML5 using some ancient noVNC JS library). Tested with 724f691 + the change above, using an ASCII-only password (lowercase + uppercase + standard symbols) with Windows 10 configured using a US QWERTY layout. The remote console guest was also using US QWERTY.

[ftoral]

I landed here when searching for Auto-Type not working into VMWare Horizon Client windows.

I found in another similar issue that we could start de the Auto-Type sequence with {MODE=VIRTUAL}.
The PR is relatively recent : #7507
It's documented as "experimental" in the user-guide : Configure Auto-Type Sequences
It worked in my case : VMWare Horizon Client on Windows

Thanks @droidmonkey.

[the-wolfman]

The MODE VIRTUAL option is really saving my day, thanks @droidmonkey and everybody involved for making it happen. Thanks also to @ftoral for mentioning it in a couple places, I would have missed it otherwise

[droidmonkey]

That's awesome to hear! Spent a good amount of time perfecting the implementation but couldn't get it to a state that worked on every single keyboard layout (thus experimental). However, it's good enough to easily solve 95% of use cases out there that need virtual key presses.

[alichaudry]

So I'm running into the same issue; auto-typing into noVNC from Keepass 2.7.1 seems to work fine in Windows, but gives me the AAAAAaaaAAAaaaaaaAA issue from macOS.

Is there an issue that tracks when this will be fixed for macOS? I tried the {MODE=VIRTUAL} command before sending the password but that didn't help (and I didn't need this experimental virtual mode flag for the Windows version of KeePass).

Background info: I set up a machine in Proxmox and set up the whole VM using noVNC + auto-typed passwords (for unlocking the disk + the user password), and I was scratching my head for a while because the passwords weren't working via SSH, but I could log in using noVNC. Turned out when I cleartext typed the passwords that SSH auto-type was sending the correct password, but the LUKS and user password were initially set up incorrectly via noVNC (a mix of uppercase and lowercase A's).

[droidmonkey]

Actually I can make virtual mode available for macos, mind making a new request for this?

[alichaudry]

Sounds good, I can make a new request. Curious, though: how come Windows KeePass works for me without setting the virtual mode flag? Is it even worth it making virtual mode work on macOS when the effort would be better spent on improving the default mechanism so virtual mode isn't used as a crutch? (Or is the default method on macOS a dead-end for now, and virtual mode has to be done, maybe even ultimately replacing the default method of sending keys via auto-type?)

[droidmonkey]

Neither is true. There are two ways to "type" on windows and macOS and they are very similar. One is to send virtual key presses (simulate an actual keyboard) and the other is to just send the target application a unicode symbol and let the app handle it. The latter works exceptionally well EXCEPT when sending to virtual clients. VirtualBox. VNC, and other such apps really only know how to respond to virtual keypresses.

[Nishi]

I solved my issue with logging in into encrypted GNU/Linux guest (inside VirtualBox on win10) using {MODE=VIRTUAL}.
It would be much more discoverable if it was just a checkbox in GUI. I don't understand why this is hidden from usual users.

[droidmonkey]

It's clearly documented in the user guide and you can also use the "Virtual keyboard" typing option from the autotype dialog directly.

[ipanin]

Are there any plans to make support of {MODE=VIRTUAL} for macOS?

[droidmonkey]

#8433

[lyallp]

I have a related problem with Windows Guest in Virtualbox, running KeePassXC 2.7.5

If I use Autotype to a virtual machine in Azure, using Remote Desktop App, the keystrokes are fine, but the SHIFT gets all out of sync.

The shift seems to get stuck. Reliably when using Autotype.

If I run autotype into Notepad in the VirtualBox Windows VM that is running KeePassXC, all things are fine.

When I autotype through Microsoft Remote Desktop (from the App store, the one that requires subscriptions), things break.

It should be noted that if I run KeePassXC in a bare metal Windows and autotype through Microsoft Remote Desktop into an Azure VM, all things work fine.

I have tried slowing down the ramp up to autotype to 1.5 seconds to give things time to settle, I have tried separating each keystroke by 100ms , to no avail. Even 200ms between keystrokes. At the end of the Autotype sequence, all bets are off as to what state the SHIFT key is in.

The worst thing is, this, of course, stuffs up autotype of passwords!

Really, I am unsure if this is a virtualbox problem of a keepassXC problem or a combination.

One final note, if I run KeePassXC in the VirtualBox HOST (in my case Gentoo Linux), and autotype INTO the VirtualBox Windows Guest and through the Remote Desktop app INTO Azure VM, all things work fine.

[droidmonkey]

Since it is just the shift key having problems, are you sure that sticky keys didn't get activated by accident in that VM? You know that thing that pops up when you hit shift 5 times.

[lyallp]

I will give it a go, I tried just before posting this response but the service was unavailable, I will return later.

[lyallp]

Going to Settings in the Virtualbox Guest Windows 10 and turning OFF everything to do with this MUltiI ShiFT setup, worked a TrEaT!

Thanks!