Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

BadUSB ALTSTRING outputs numbers #1394

Closed
KairuByte opened this issue Jul 13, 2022 · 2 comments · Fixed by #1406
Closed

BadUSB ALTSTRING outputs numbers #1394

KairuByte opened this issue Jul 13, 2022 · 2 comments · Fixed by #1406
Labels

Comments

@KairuByte
Copy link

Describe the bug
ALTSTRING This line was print using Alt+Numpad input method. It works even if non-US keyboard layout is selected outputs the following on latest firmware:

784104105115321081051101013211997115321121141051101163211711510511010332651081164378117109112971003210511011211711632109101116104111100463273116321191111141071153210111810111032105102321101111104585833210710112198111971141003210897121111117116321051153211510110810199116101100

To Reproduce
Simply run the above in a BadUSB script on WIndows 11.

Expected behavior
This string: This line was print using Alt+Numpad input method. It works even if non-US keyboard layout is selected

Target
Windows 11

@KairuByte KairuByte added the Bug label Jul 13, 2022
@djsime1
Copy link
Contributor

djsime1 commented Jul 15, 2022

Looks like those are the raw alt codes for the text. My best guess is that Flipper failed to activate num-lock.
Edit: Might be related to #1330?

@GeorgeBroughton
Copy link

it fails to hold ALT

Numlock is successful, ALT is not
it's typing the numbers fine

Can confirm this issue on a UK keyboard layout if this is relevant.
It could also be to do with timings of keypresses.

Knowing how Windows behaves when making USB keyboard/mouse emulators in the past, windows can do some buggy things if you type fast. Like if you use one to type your password at a windows login screen, winlogon.exe will actually crash.

So if ALT is being pressed too quickly before the numbers are being pressed, it might cause some issues.

Haven't looked at the code for it yet but this is my assumption as to what's wrong.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants