covert_channel improvement

[Mera-balou]

I deployed the covert channel on a CU-12 and it works very well. But if the targeted dongle is not with the LIGHTSPEED firmware (e.g: original C-U0012 not flashed), It takes a few minutes to deploy the covert channel (a few seconds for the powershell terminal then a few minutes for the rest of the hidden code).

During these few minutes, if the targeted user clicks with his mouse on a text zone, the entire payload will not be transmitted to the powershell terminal and the covert channel will not work. To avoid this and increase the chances of success, would it be possible to force the mouse pointer in a corner of the screen (example: upper right corner)?

[RoganDawes]

I’m not sure how that would help?

If the victim switches focus out of the Powershell window, keystrokes will be lost, and the payload corrupted. Similarly, if they press a key on the keyboard, the payload will (most likely) be corrupted.

There is really no way around that, other than minimizing the number of keystrokes required, and consequently the window of opportunity for corruption.

The best approach I have seen is thus a staged one, where a bare minimal “loader” is typed out, just enough to open the raw hid device and receive a more comprehensive payload over a faster, more robust transport, which can do things like error detection and recovery, and that is not susceptible to interference from the victim.

For an example, check out USaBUSe, which only needed to type around 1800 characters, and, depending on implementation, could do that in around 6 seconds total (including waiting for the Powershell window to appear)

On Sat, 18 Jan 2020 at 00:03 Mera-balou notifications@github.com wrote:

I deployed the covert channel on a CU-12 and it works very well. But if the targeted dongle is not with the LIGHTSPEED firmware (e.g: original C-U0012 not flashed), It takes a few minutes to deploy the covert channel (a few seconds for the powershell terminal then a few minutes for the rest of the hidden code).

During these few minutes, if the targeted user clicks with his mouse on a text zone, the entire payload will not be transmitted to the powershell terminal and the covert channel will not work. To avoid this and increase the chances of success, would it be possible to force the mouse pointer in a corner of the screen (example: upper right corner)?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/mame82/LOGITacker/issues/47?email_source=notifications&email_token=AABHBC2UIXNBVTRD3MUDLL3Q6ITM5A5CNFSM4KIOXPL2YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4IHBR7ZA, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABHBC33O2JTODYVZFEDYQTQ6ITM5ANCNFSM4KIOXPLQ .

[mame82]

I totally agree with @RoganDawes.

Anyways, in one of my test systems I inspected weird behavior: Once the payload typing to the hidden powershell Window starts, I'm not able to switch the input focus away (neither with mouse, nor with alt+tab etc).

The first time I observed this was with P4wnP1 HID channel. Same behavior with Lightspeef Logitech receivers. My initial thought was it occurs when stdin if the console is filled faster than characters could be displayed. This doesn't hold true, as the same behavior occured even with slow typing Unifying receivers.

Now all of this is worth nothing, as it 9nly happened on my test system and can't be reproduced (I never investigated the root cause).

But whenever Rogan jumps into discussion like this, I end up with new ideas ... here is mine:

What if we manage to manipulate the input receiving powershell window, not only to be hidden, but to behave like a modal window till typing has finished.

The user wouldn't be able to do anything about it, other than triggering higher priority key combos (ctrl + alt + del, alt + f4 ...).

I have no time to test if this is possible, but I won't say it isn't without trying

[RoganDawes]

Modal is all very well, but will still definitely be susceptible to “rogue” keystrokes from the real keyboard unfortunately.

Ie if the users presses A, it will still be captured in the modal window and corrupt the payload.

[RoganDawes]

But if anyone wants to try it, here is a starting point, for “system modal dialog boxes”: https://en.wikibooks.org/wiki/Windows_Programming/Dialog_Boxes