C-U0007 firmware 012.010.00032 dongles does not accept encrypted keyframes about logitech-unifying-device

[skito]

Do they reject everything or just the keyboard keys? What about mouse keyframes?

[bilogic]

@skito

Only the keyboard frames which are encrypted. Mouse frames, which are unencrypted, works flawlessly.

If you have an ESP8266 and NRF24L01+, I can guide you through. Given that it all works for an earlier dongle firmware, I'm confident my AES encryption code is correct.

[skito]

I was thinking to mount the NRF24L01 to Atmega328 CH340, which can be directly connected to PC via USB cable. Would you think that will work or it has to be ESP8266?

[bilogic]

Are you planning to do something with the USB? The atmega should work, I'm just not sure of its computation power. Arduino IDE supports both atmega and ESP8266, but my code is based on VSCode, PlatformIO.

[skito]

@bilogic My idea is just to have plug & play device to work on. How do you connect ESP8266 to the computer? HDM, USB or you connect it to something else? Sorry for for the dump questions, software engineering is my stronger side.

[bilogic]

@skito the ESP8266 has development modules that connect via USB such as the Wemos D1 mini. Which timezone are you in? I'm on the move, can't provide useful links at the moment.

[skito]

@bilogic I'm in EET. Whenever you had time I'll appreciate some Amazon or eBay links to get start with the necessary hardware. Otherwise the Software guidelines are pretty straight forward. Seems that you've done great job so far.

[bilogic]

Do you mean Eastern GMT-4/5?

[skito]

GMT +2

[bilogic]

1. ESP8266 https://www.ebay.com/itm/NodeMCU-Lua-ESP-12-WeMos-D1-Mini-WIFI-4M-Bytes-Development-Board-Module-ESP8266-/321989574625
2. NRF24L01+ https://www.ebay.com/itm/For-Arduino-NRF24L01-Wireless-Wifi-Transceiver-2-4GHz-Antenna-Module-200M/192931634959
3. NRF24L01+ power board https://www.ebay.com/itm/NRF24L01-Wireless-Adapter-Module-5V-Socket-Adapter-Plate-Board-for-6Pin-51/265033361916

This is what I'm using, feel free to find cheaper alternatives :)
While waiting, you can familiarize yourself with VSCode + PlatformIO to compile the firmware first.

China is going into Chinese New Year, so expect 1-2 weeks of additional shipping.

[bilogic]

You might also want to check out this thread first
RoganDawes/LOGITacker#55 (comment)

Basically, have 2 x Logitech C-U0007 dongles flashed to the following firmware:

1. 012.001.00019 - ESP8266 can move the mouse and send keystrokes
2. 012.001.00032 - ESP8266 can only move the mouse, nothing happens when keystrokes are sent

This led me to try and reverse engineer the dongle firmware 012.001.00032, but I could not get far due to a lack of skill. See my updates here https://www.reddit.com/r/LiveOverflow/comments/g8ajed/reverse_engineering_of_logitech_unifying_firmware/

The dongle firmware is basically an Intel 8051 binary, I was hoping to figure out what has changed in 32 since 19.

[skito]

Encryption method perhaps? You mentioned AES, maybe they changed from 128 to 256 or vice versa...will check as far as I get the hardware. I'm familiar with VS.Code, but new to PlatformIO. However I guess is nothing different from other frameworks.

[bilogic]

Hmm, I'm working based on inference logic here:

1. Logitech K270 keyboard's encrypted keystrokes works with 012.001.0019
2. Logitech K270 keyboard's encrypted keystrokes works with 012.001.0032
3. Firmware in the K270 keyboard remains unchanged, so...

Anyway, I shall not comment further on my opinions, I welcome your fresh perspective on this to hopefully get this resolved. :)

The AES is also quite unlike the typical AES implemented in more serious encryption. I can't remember the details off hand now, but do ask if you have trouble reading my code.

[skito]

@bilogic

1. ESP8266 https://www.ebay.com/itm/NodeMCU-Lua-ESP-12-WeMos-D1-Mini-WIFI-4M-Bytes-Development-Board-Module-ESP8266-/321989574625
2. NRF24L01+ https://www.ebay.com/itm/For-Arduino-NRF24L01-Wireless-Wifi-Transceiver-2-4GHz-Antenna-Module-200M/192931634959
3. NRF24L01+ power board https://www.ebay.com/itm/NRF24L01-Wireless-Adapter-Module-5V-Socket-Adapter-Plate-Board-for-6Pin-51/265033361916

This is what I'm using, feel free to find cheaper alternatives :)
While waiting, you can familiarize yourself with VSCode + PlatformIO to compile the firmware first.

China is going into Chinese New Year, so expect 1-2 weeks of additional shipping.

On these how to properly connect both PCB - should I connect only 5v (VCC power supply rail) and Ground?

[bilogic]

Yes, use the 5v for VCC, I have updated the readme.md

WEMOS D1 mini D3 <-> power board CS
WEMOS D1 mini D4 <-> power board CE
WEMOS D1 mini D5 <-> power board SCK
WEMOS D1 mini D6 <-> power board MISO
WEMOS D1 mini D7 <-> power board MOSI
WEMOS D1 mini 5V <-> power board VCC
WEMOS D1 mini GND <-> power board GND

[skito]

Perfect! Thanks!

[bilogic]

@skito just curious, do you plan to disassemble the dongle firmware?

[skito]

@bilogic I think to give a try to the latest one - ...00032. Will connect with mouse movements first, to be sure that everything is connected properly and then will check up the keys encryption to try improve it. Do you know how to downgrade to ...00019 if I need it?

[bilogic]

@skito no idea how to downgrade it. I have 2 dongles myself, one 00019 and the other 00032.
I'm re-visiting old notes to see if I might have missed anything simple. I supposed the worst case is to manually flash in the downgrade.

[skito]

Well the goal here is to have it working with the latest so...I'll got the parts upcoming week.

[bilogic]

I wonder what is the "magic key sequence" here https://www.youtube.com/watch?v=EksyCO0DzYs

[skito]

@bilogic Are there any additional steps for connecting the D1 Mini ESP8266? PlatformIO can recognize the device.

[skito]

Nevermind, I needed to install additional CH34x driver. Now everything runs correctly and I'm able to send mouse movements to the receiver. So far so good. I'll let you know if any progress.

[bilogic]

Great, are you able to send encrypted keystrokes for dongle version 012.001.0019?

[skito]

My version is 024.001.00023 and yes - I'm able to send the encrypted keystrokes without any modification of your code.

[bilogic]

I think 024.001.00023 is meant for another hardware dongle, not C-U0007.
In any case, is 024.001.00023 the latest in your series?

[skito]

Yes - it's the latest one.

This is the dongle:

This is how it finds the device as keyboard.

[bilogic]

Interesting, I take that when you select the Unifying Receiver, Update Firmware ends with 024.001.00023.
All I can say is mine still does not work with 012.001.00032

[skito]

Strange indeed.
I bought mine from here:
https://amzn.to/3pyggbp

You can try get one as well.

[bilogic]

Well, I'm certain buying from your link will work.

My interest is in, what did Logitech do in 012.001.00032 that was able to thwart packets being sent out from our devices.
Until we figure that out, this hack remains "incomplete". :)

[bilogic]

Whatever they did in 012.001.00032, they could well do the same in the next update to 024.001.00023.

[mgottschlag]

I have some code at https://github.com/BerndGottschlag/goboard/blob/unifying/firmware/main/src/unifying.c based on your code, LOGITacker and mjackit that seems to work just fine with a stick that is reported as RQR12.03_B0025 as well as RQR12.10_B0032. I do not see any immediate differences to your code, but you might want to take a look. I increase the counter on every packet sent, whereas LOGITacker just increases the counter when it receives an ACK, but that should only make a difference when there is substantial packet loss.

[bilogic]

@mgottschlag

Was your goboard able to send encrypted keystrokes through a RQR12.10_B0032?
"stick" to me seems to imply a mouse.

[mgottschlag]

yes, it was, I mean the normal unifying receiver USB stick

[bilogic]

yes, it was, I mean the normal unifying receiver USB stick

@mgottschlag

Wait, what?

Hmm which microprocessor does your code run on? It was not obvious to me at first glance.

Looks like you are also familiar with PCB design (Something which I'm not)
Ok, let's not get ahead of myself yet until this RQR12.10_B0032 is fixed. :)

[mgottschlag]

My code is currently running on an NRF52840 board (Adafruit Feather NRF52840 Express), and it is able to communicate encrypted keystrokes to the usual unifying receivers with those two versions (in my experience, everything that is plugged into USB without any cable attached is called an "USB stick", which is probably what caused confusion).

[bilogic]

@mgottschlag

Ok cool. From what I recall, my code increments with every packet.

Does your code perform all the extra initialization packets?

Those were not very well documented in the other projects and I kind of aggregated them here

logitech-unifying-device/src/ludevice.cpp

Line 790 in 32b286e

bool ludevice::register_device()

I'm going to check your codes in a minute. Thank you.

[mgottschlag]

No, I have not implemented reconnecting at all yet - I have not even implemented storing pairing info in a persistent way yet. At the moment, this is just a proof of concept so that I know that it will work later on. Currently it just polls one GPIO and sends a single keycode.

[bilogic]

I see, hmm.

So you extracted the AES keys via sniffing or something, and constructed encrypted keystrokes packets which are accepted by the unifying dongle?

[mgottschlag]

No, I did not. I do exactly what you do in your pairing code - I construct an AES key from the dongle's nonce/wpid, the address specified by the dongle and my device's serial number and nonce.

EDIT: This corresponds to luedevice::pair() - ludevice::reconnect() is, after all, only required when you are already paired to the dongle and want to reconnect.

[bilogic]

Ok thanks let me find some time to scrutinize this. Thank you.

[skito]

@bilogic On a more detailed test I can only do mouse movements and media keys. Mouse clicks and other keyboard keys doesn't work...

[bilogic]

1. @skito Good to know we are on the same page.
2. @mgottschlag Can you confirm your code can send A-Z?
3. We should examine https://github.com/BerndGottschlag/goboard/blob/unifying/firmware/main/src/unifying.c closely if it is able to send A-Z to RQR12.10_B0032

[skito]

Just figure out the mouse clicks. The mouse_payload was wrong.
Should be 0x02 and 0x03 for right and left clicks in ludevice.cpp:865

[bilogic]

Ok will fix. Can re-verify the other earlier firmware and see if A-Z works?

[bilogic]

@skito

1. I went through the mouse code, it doesn't make sense that left click is 0x3, such button detection usually use bits as on/off.

0x2 = B10    // 2nd bit is on
0x3 = B11    // both bits are on, don't make sense

2. I checked here too https://github.com/ronangaillard/logitech-mouse/blob/f29452d2ca9783224597d9dee1050bd4a14cfda5/logitech-mouse.cpp#L194
3. Just to be absolutely sure, I tested against https://www.onlinemictest.com/mouse-test/ and my conclusion remains that left click is 0x1.
4. Also, your code won't be able to detect both left and right clicks together, you have to | the 2nd part.

   if (leftClick)
        mouse_payload[2] = 1;

    if (rightClick)
        mouse_payload[2] |= 2;

[bilogic]

@mgottschlag

I went through both our codes, and updated mine with parts of yours, still no luck with A-Z on RQR12.10_B0032.

@skito

Any luck?

[skito]

@bilogic Yes

0x01 - Left click
0x02 - Right click
0x04 - Middle click

https://gist.github.com/kkusch/245bb80ec4e7ab4d8cdc6b7eeb3f330f
https://docs.microsoft.com/en-us/windows/win32/inputdev/virtual-key-codes

The current payloads seems to be working as well, however the problem with the function is far more deeper.

Firstly - the overload method of move, taking the mouse clicks is wrong.

Line ludevice.cpp:845 should be move(x_move, y_move, 0, 0, leftClick, rightClick);

Then the mouse_payload at ludevice.cpp:866 and 869 aren't working every time for my receiver - but only the first time after pairing. After some experimenting with the payload I figure out the if you send a click command you then must send empty payload in order to apply the click.

That works every time for me now. Next week I can make a new branch and commit some improvements to see if they will work for you as well.

[bilogic]

oh, yes, low level code requires you to fire click and unclick. Same goes for the keystrokes, press and release.
I will fix the double false, that is definitely a bug, but I don't think I wrote it... only copied from logitech-mouse 🤣🤣🤣

I was more focused on getting keystrokes as my aim is to have a Logitech compatible keyboard.

[skito]

Well you can always have a touchpad on your keyboard :D Now when the mouse is working properly, I can take a look at the keystrokes.

[bilogic]

Haha, ok we will see. I made some commits, see if you wanna pull them. Thanks!

[bilogic]

@mgottschlag can confirm your repo is able to send A-Z keystrokes that are accepted by RQR12.10_B0032? Thank you.

[mgottschlag]

Sorry, I wanted to do that yesterday, but did not find the time. I will have access to the prototype again on wednesday, I'll try to test again then.

I do not see why the test would fail, though - during the last test, the dongle accepted multiple key strokes, and I do not know why the dongle should reject other packet content.

[mgottschlag]

@bilogic ist this what you meant? https://github.com/BerndGottschlag/goboard/blob/firmware/firmware/main/src/unifying.c#L492

That code indeed works with RQR12.03_B0025 and RQR12.10_B0032.

[bilogic]

@mgottschlag

I can't seem to find the definitions for KEY_RETURN and KEY_A to understand your line of code confidently.
I assume it is going from A to Z until it this KEY_RETURN, so this causes A-Z to show on your host?

Hmm, ok, I will dig at my code harder to find out what is the issue. Thanks!

[bilogic]

@mgottschlag would you be able to show me the counter in byte form?

i.e. suppose the counter is 0x12345678, next value would be 0x12345679, is this how you encode it?

encrypted_report[] 07 08 09 10 11 12 13
             value xx xx xx 12 34 56 79

I always have trouble with endian-ness. Appreciate your inputs. Thank you!

[mgottschlag]

KEY_A-KEY_RETURN are the HID key codes (src/keycodes.h), so yes, it cycles through a-z0-9

Currently, the initial counter is always 0xdeadc0de. Here are some example key packets - the counter is encrypted as big endian:

<info> app:  00 D3 C3 2E F5 67 ED 80|.....g..
<info> app:  05 F4 DE AD C1 4C 00 00|.....L..
<info> app:  00 00 00 00 00 E2      |......  
...
<info> app:  00 D3 D5 86 C5 25 B8 A7|.....%..
<info> app:  7B 56 DE AD C1 4D 00 00|{V...M..
<info> app:  00 00 00 00 00 1F      |......  
...
<info> app:  00 D3 DF 76 27 91 07 AD|...v'...
<info> app:  83 96 DE AD C1 4E 00 00|.....N..
<info> app:  00 00 00 00 00 B9      |......  
...
<info> app:  00 D3 23 95 13 26 24 3F|..#..&$?
<info> app:  7C A8 DE AD C1 4F 00 00||....O..
<info> app:  00 00 00 00 00 1A      |......  

[bilogic]

@mgottschlag thanks! @skito did you manage to make any progress?

[skito]

@bilogic No, not yet. Didn't had much time to work on it.

[skito]

@bilogic So far I can tell that mouse payloads don't work neither with firmware 012.009.00030. Only pairing works so far.

[bilogic]

@skito Does mouse actions work with RQR12.10_B0032 for you?

[skito]

@bilogic I don't have RQR12.10_B0032 - only two dongles - 024.001.00023 and new one with 012.009.00030. The new one however works with the latest commit of yours. More specifically line 54 of ludevice.h

When the value is 0xe it works with both dongles. However drag&drop operations times out - when you start drag operation with left or right button it's been interrupted after 1 second.

With value of (1 << 14) drag&drop operations works perfectly, but only on firmware 024.001.00023. Firmware 012.009.00030 doesn't accept mouse movements at all.

[skito]

So the actual solution here is to keep the mouse down button alive by sending payload every 10 milliseconds. Otherwise the newer firmware of Logitech receiver count it as button release (mouse up). I know that your focus is the keyboard, but this is just FYI. Someone else may have that struggle as well.

[bilogic]

@skito feel free to submit PRs if it will make the code better. Thank you.

[bilogic]

@mgottschlag can help check if your implementation works with RQR12.10_B0032 when all 6 keys are filled? e.g. abcdef

[rmbirle]

Not sure if this helps you guys in any way, but have you seen these files?
https://lekensteyn.nl/files/logitech/

[bilogic]

@rmbirle yes I have, thank you.

[Tiebe]

@bilogic any updates?

[bilogic]

@Tiebe not really

[mrfibreoptic]

Hi @bilogic any updates? i'm very interested in this project

[bilogic]

@mrfibreoptic

Actually, the code works, they just added some logic to reject frames with 6 keys that pop out of nowhere.

What do you want out of this project? Logitech introduced a new standard called bolt, I think it's meant to supercede unifying, although being able to make any device work with a unifying dongle still feels/looks cool on many levels.

[mrfibreoptic]

@mrfibreoptic

Actually, the code works, they just added some logic to reject frames with 6 keys that pop out of nowhere.

What do you want out of this project? Logitech introduced a new standard called bolt, I think it's meant to supercede unifying, although being able to make any device work with a unifying dongle still feels/looks cool on many levels.

Dude it’s so cool!! I’ve got a bunch of logi unifying dongles (u-c0007) I’m wanting to create a custom keyboard for my Xbox. I’ve been looking at using a SparkFun Pro nRF52840 Mini - Bluetooth Development Board https://www.sparkfun.com/products/15025. I’ve read rf has the lowest latency & reliability, although as it’s getting on as an old tech it’s hard to fine much code examples to connect node to node. I’d be stoked to get it working in harmony with a unifying receiver or something like this nRF52840 USB Key with TinyUF2 Bootloader https://www.adafruit.com/product/5199. Can’t beat the form factor of the unifying receiver tho.

[decrazyo]

@bilogic
I recently found your project while implementing the Unifying protocol based on some research i did a few years ago.
Your encryption method looks more or less correct to me but i think you have some timing issues.
Sending an encrypted keystroke packet implicitly sets the timeout/keep-alive to the default (20ms) that was specified during pairing and it looks like your code isn't doing that.
I've also found that Unifying devices behaves more reliably by making all packets adhere to strict timing like you've already done with keep-alive packets.
Check out my repo and demo for more details.
https://github.com/decrazyo/unifying
https://youtu.be/10lE96BBOF8?t=2026

[bilogic]

@decrazyo thanks, where can I find out more about this 20ms that you speak of? Thank you!

[decrazyo]

It's not well documented.
Marc Newlin briefly mentions it on one of his slides in his Defcon 24 MouseJack presentation.
https://youtu.be/00A36VABIA4?t=1237
He was talking about mouse movement packets but the same thing applies to keystroke packets.

This behavior can be observed by capturing the traffic between a device and a receiver.
Here's an annotated packet capture that i did of my Logitech K330 which demonstrates this behavior.
https://pastebin.com/cbwWaYjM

[bilogic]

@decrazyo

Ok, thanks I know what you are referring to now.

Actually, the encryption code is good, it is more about what Logitech did to mitigate the vunerability, I recall Marc saying somewhere he wasn't completely satisfied. Were you able to send through a full buffer (one with 6 keystrokes) packet reliably?

Since then, Logitech has released Bolt, have you play around with it?

And 84 mechanical keyboards are dirt cheap these days, except I can't find one with a volume knob/media buttons on the left hand side. But of course, one with strong encryption will certainly bring more assurance.

How far are you into your project? I more or less stopped when I realized that QMK will probably never run on ESP32.

[decrazyo]

@bilogic

I tested sending 6 keystrokes at once and ran into the same problem that you did. The receiver rejected the packet.
It works fine if you send one packet for each additional key.
i.e. send a packet with 'A' pressed. Then a packet with 'A' and 'B' pressed. Then a packet with 'A', 'B', and 'C' pressed. etc...

I haven't tested Bolt at all. I've read that it's built on top of Bluetooth LE and that kind of made me lose interest in it.

I've only implemented pairing, encrypted keystrokes, and keep alive so far.
I'm currently working on writing documentation for what i have and refactoring the code a little.
Adding unencrypted multimedia keystrokes and mouse movement/clicks should be easy.
Adding wakeup/reconnect and HID++ functionality might be a little harder but still doable.

I'm still hopeful that i can get my code added to TMK, QMK, ZMK, etc... some day.
I've tried to write my library to be a portable as possible.
It should run on just about any microcontroller and can use either an integrated RF radio or an external one like the nRF24L01+

[bilogic]

@decrazyo

Yea, so Logitech just did some behavior mitigation, basically jacking is still possible.

Personally, I'm neutral about radio transmission type as long as they don't pose usability issues.

Bluetooth has the benefit of not requiring any special dongles but earlier versions of keyboards had persistent disconnections lasting several seconds, basically unacceptable.

I'm not sure if BLE still poses the same problems, but what is your concern with it?

Well, I'm happy about your project, especially if it makes it through to QMK. At least one of us got there. :)

[decrazyo]

@bilogic

I think Logitech may have mitigated jacking by verifying that the AES counter is always greater than it was in the previous packet although i haven't tested that.
If so, then there may still be an edge case that allows jacking to be possible but it's not of much concern to me.

I'm not too worried about Unifying's weak encryption keys either.
I think it's unlikely that anyone will actually try to capture and decrypt my keyboard packets (outside of security conventions).
If i really get paranoid about it then i can just generate a completely random AES key for my keyboard and manually inject it into a Unifying receiver.

My problems with Bluetooth just boil down to connection issues that I've experienced.
Random disconnects, slow/failed reconnects, and on rare occasions Windows will refuse to let a device connect or pair.
The Windows issue is particularly annoying because it requires some obscure utility to fix it.

I don't know too much about Bluetooth LE to be honest.
I know that some BLE keyboards use HID over GATT and that just seems unnecessarily complex to me.
https://www.bluetooth.com/specifications/specs/hid-over-gatt-profile-1-0/
That was one of the motivating factors that made me start hacking Unifying in the first place.

I don't know if Bolt uses HID over GATT or not.