Lair Of The Multimedia Guru

For plain LCG the problem is trivial and an implementation shown in my last post. PCG falls in 2 categories, the PCG-XSL-RR which is based on an LCG, this was solved in the Paper by Bouillaguet, Martinez and Sauvage.
The remaining PCG generators are different and simpler, they are based on an truncated LCG. The problem of finding an increment and seed is marginally harder as it is for the corresponding truncated LCG. It can be done using Lattice reduction (even some half bastardized version seems to work). The problem and the surprise for me really is that the solution in general is not unique. I guess it was a surprise after reading in the original PCG paper how additional random streams can be created by changing the increment. This is really not true. Changing the increment does not really produce “different” random data, it just offsets it.

Let me first show an example with a plain LCG (using the multiplier 6364136223846793005 from PCG with 64bit state)

This is not a odd exception, no, for every choosen LCG and choosen offset (here it is +1) theres a seed and increment that will produce a offset sequence of random numbers.
You can use lcg-breach to find them by just asking it to find parameters for a modified sequence.
Now thats LCGs, What about truncated LCGs ? its worse because they discard the low bits. You get sequences that can be exactly equal for MANY values even with different increment and seed. And that is what the problem is in determining the increment for truncated LCGs and the corresponding PCGs. For PCG-XSL-RR the low LCG bits are XORed in so there remains a effect on the output and its possible to determine the increment but for 128/64 and 64/32 PCG-XSH-RR the low bits of the state do not affect the output as long as their effect stays limited to these low 27bit (for 64/32 bit) in future states they cannot be computed from the output. Or in other words the output from 2 PCG-XSH-RR with differing increments can be identical for a long time.

On top of that, there is also a set of seed,increment pairs that produce constant output.
consider this:

LCG         : out[i+1] = out[i] * m + a mod n
what we want: C        = C      * m + a mod n

just solve it:

C - C * m = a mod n

choose the constant C you want and this will tell you the increment a that will keep the generator at that constant when its started on it.

and how do we now create a offseted LCG ?
simply add it with the constant above

out[i+1]     =  out[i]      * m + A     mod n
           C =           C  * m +     a mod n
out[i+1] + C = (out[i] + C) * m + A + a mod n

And yes LCGs of the same multipler and modulo seem to form an abelian group with addition.

Just for fun, heres a program to generate random numbers using a Linear Congruential Generator from a specified multiplier, increment, seed and number of bits.
And a second one that will tell you the multiplier, increment, seed for a given 3 output numbers from above.

Have fun encrypting important messages


./lcg 64 6364136223846793005 1442695040888963407 314159 5
1758213515780721042
8369501526408240633
14286244372924288276
12908628925188209107
17643264774698309734

$ ./lcg-breach 64 1758213515780721042 8369501526408240633 14286244372924288276
Seed: 314159 0x000000000004CB2F
Multiplier: 6364136223846793005 0x5851F42D4C957F2D
Increment: 1442695040888963407 0x14057B7EF767814F


How did this start ? Someone found a bug or 2 in the libavutil/eval.c random(), so i proposed a patch replacing it by Marsaglias 64-bit KISS PRNG. Nicklas Haas then ask me why iam not using PCG yesterday. And i didnt know really what PCG is :) so i looked found the paper found a wegpage that was down the exact day i tried to look at it (yeah its up again now). And a wikipedia page taking about “It has been shown that it is practically possible (with a large computation) to recover the seed of the pseudo-random generator given 512 consecutive output bytes.”. That triggered me a bit ;)

The paper about PCG is 58 Pages so reading that is not an option. But we skim it and look at the pretty pictures, theres one that marks several PCG variants as insecure. Luckily the one listed at wikipedia (PCG-XSH-RR is not marked as insecure) In fact there are 2 PCG-XSH-RR, one with 64bit state and 32bit output and one with 128bit state and 64bit output. So i tried them. Theres also a paper about breaking PCG-XSL-RR which differs by some shifts it seems from XSH. That paper talks about also recovering the increment and that for that it needs “512 bytes of challenge input;in the worst case, the process takes 20 000 CPU hours” ugh, i dont have that. Luckily we know the increment as its not a variable in the implementation and with that, the paper tells us “breaking XSL-RR needs 23 core minutes”. But we took XSH-RR because it was on wikipedia :) and the original paper also recommends it

6.3.1 32-bit Output, 64-bit State: PCG-XSH-RR
Here the design goal is to be a good all-purpose random number generator. The intent
is to balance speed with statistical performance and reasonable security, charting a
middle-of-the-road path. (It’s the generator that I recommend for most users.)”

So we are not totally wasting our time but we can have fun exercising breaking a “not insecure” PRNG with “reasonable security”.

A few hours later, am i lucky ? am i smart ? or is the PCG-XSH-RR a insecure generator, i dont know, I think i maybe picked the easier one but still. These following need 3-4 output values from the PCG-XSH-RR to find and verify its state, from which all future and past output can be computed.
For the 64/32bit variant we compute all tables at runtime, for the 128/64 variant we hardcode the 152 entry table needed as it needs a few minutes to be computed. But the table doesnt depend on the seed nor on the increment, just a new multiplier would need a new table.
The actual execution for both including loading the program, generating the random numbers finding the seed again and printing it all together takes less than 100ms
Code is here


time ./pcg-xsh-rr-64-32-breach $((0x1234578ACDEF11))
INV 0xC097EF87329E28A5 0x1 gcd=0x1
Seed = 0x1234578ACDEF11
PCG output 0 = 0x90DA0D79
PCG output 1 = 0xCF0EAEE6
PCG output 2 = 0x423D36BE
PCG output 3 = 0xAE152565
PCG output 4 = 0x2C48B4D4
PCG output 5 = 0x9EE6CC50
PCG output 6 = 0x903FC56A
PCG output 7 = 0xC85B3AED
PCG output 8 = 0x87B29579
PCG output 9 = 0xA486F671
Table 0 0x00000000000000005851F42D4C957F2D 0x0000000000000001
Table 1 0x000000000000000008F5DC87E5C07D87 0x0000000000000003
Table 2 0x00000000000000000148A921ACEF6819 0x000000000000001D
Table 3 0x00000000000000000006C363D4CB5B28 0x00000000000000C8
Table 4 0x00000000000000000002BCFA0DFD0A8F 0x000000000000262B
Table 5 0x00000000000000000001738A552BC485 0x00000000000071B9
Table 6 0x000000000000000000002A1A9C5A7E7B 0x000000000000BD47
Table 7 0x0000000000000000000007652A02ADCE 0x00000000000635C6
Table 8 0x0000000000000000000002445FB59459 0x000000000024855D
Table 9 0x0000000000000000000001AC54D3A396 0x00000000008BDFAE
Table 10 0x00000000000000000000011449F1B2D3 0x0000000000F339FF
Table 11 0x00000000000000000000007C3F0FC210 0x00000000015A9450
Table 12 0x000000000000000000000060733D935D 0x00000000031C82F1
Table 13 0x000000000000000000000044A76B64AA 0x0000000004DE7192
Table 14 0x000000000000000000000028DB9935F7 0x0000000006A06033
Breaching spin:.........................................................................................................................................................................................................................................................................................................................
Candidate 0x48EAFC5649EE9492 for 90DA0D79 CF0EAEE6 423D36BE
found Seed = 0x1234578ACDEF11

And the PCG-XSH-RR-128/64 one:

time ./pcg-xsh-rr-128-64-breach $((0x1234578ACDEF11))
INV 0x98ABC8B0716EAC8D 0x1 gcd=0x1
Seed = 0x1234578ACDEF11
PCG output 0 = 0xE49F66304A892198
PCG output 1 = 0x58C80AA8C2F10A26
PCG output 2 = 0xD2B380859B808368
PCG output 3 = 0x60715FDB8EE68956
PCG output 4 = 0xB0D0AAF3073F2EDA
PCG output 5 = 0xC5876DE56C99EDB3
PCG output 6 = 0x68371CCDC061F3D
PCG output 7 = 0x7118EC9199028ED5
PCG output 8 = 0xAC0DAAF55D9A009C
PCG output 9 = 0x709AD75080EDE32E

real 0m0.089s
user 0m0.069s
sys 0m0.020s


Maybe its a great PRNG, i dont know i did not look at that aspect, but its not secure if i can break it after a few hours work :)

I was looking for a way to securely manage my passwords, anything storing my passwords with a 3rd party or all accessible to my computer fail IMHO. Also it had to be practical, something limited to 5 passwords is not. Be convenient, something where one would have to search for a password in a list by hand fails that. And it needed to have a screen so one knew what one approved. A simple one button USB stick does not qualify either as one does ultimately not know what one actually approved. The only device i could find was the mooltipass. So i bought one. It is a cute little thing storing all passwords both securely and also conveniently. And being a nerdy geeky person, i of course had to play with and analyze it. The first thing that sprang out to me was its random number generator

Can we exploit it ?

So i looked at its random number generator until i found something. It uses the 2 LSB of each of the 3 axis of an LIS2HH12 accelerometer. This generator was tested with the DIEHARDER battery of tests by its creator before me. I was at first not able to run the DIEHARDER tests because they needed more random data than the device could generate quickly. I tried various tests, simple things like simply trying to compress the data showed no anomalies. The first anomaly i found, i believe was through looking at the frequency spectrum in audacity. To my eye it looked like there was a bias between high and low frequencies. The next step was checking the correlation of various bits. And indeed when one looked at 2 bits and the previous 2 bits from the same channel They where equal 3% more often than they should be. I guess i could have stoped here, but i didn’t :) So i looked at the distribution of matching bits, (3% of these shouldn’t be there and we dont know which of 100 are the 3 bad ones). These 3 could be randomly distributed of course. But by now i had enough data to run some of DIEHARDER and while most tests passed, some of its tests failed for me. I have to say though little things in the command line of DIEHARDER can lead to unexpected results.

The original findings on the 3% anomaly

I simply counted the number of times each 2bit matches the previous
2bits of the same channel and this occurs about 3% more often than it should.

With 1 mb of data:
Channel 0 [1.026829 : 1.980986 : 0.992185]
Channel 1 [1.031329 : 1.978283 : 0.990388]
Channel 2 [1.039171 : 1.974176 : 0.986653]
Average   [1.032443 : 1.977815 : 0.989742]
All 3     [0.968019 1.010415 1.052310 1.111489]

/dev/random
Channel 0 [1.000765 : 1.998530 : 1.000705]
Channel 1 [0.997429 : 2.001644 : 1.000927]
Channel 2 [0.997357 : 2.003375 : 0.999268]
Average   [0.998517 : 2.001183 : 1.000300]
All 3     [1.001617 0.999233 0.997958 0.995425

This allows relatively reliably distingishing the mooltipass random numbers from /dev/random with 10kb of data

Periodic anomalies

Looking again at the randomdata. The 3% extra repeats within a channel occur 32 samples apart (that is 24 bytes in the stream or 192 bits). These locations sometimes shift around but preferably occur at indexes 31,63 and 95 of the 96 sample block. When such a run of anomalies breaks from teh same index, the new index tends to be the next in the set {95,63,31}. With these patterns it is possible to reliably distinguish as little as 100-200 bytes from random data. That said, the randomness of this is still plenty for a password and the average human would be way worse generating random data. Care though may need to be applied if this is used for other purposes than passwords. For example DSA signatures are notorious for being sensitive to biases in the used random number generator. I reported the anomalies in the RNG in January of 2023. It was fixed on Apr 18th 2023 with 49359dfc52cdfe743000ac512092085328d5f15b. Software to detect the specific pattern reliably as well as 2 small test samples is availble at randomtests

The original findings on perodic anomalies

Heres how this compares to /dev/random
dd if=/dev/random of=/dev/stdout count=1 bs=1000 status=none | ./mooltitestwalker
mooltiness:     0.89 expected: < 1 in 68% cases, < 2 in 95%, < 3 in 99.7%

dd if=/dev/random of=/dev/stdout count=1 bs=10000 status=none | ./mooltitestwalker
mooltiness:     0.25 expected: < 1 in 68% cases, < 2 in 95%, < 3 in 99.7%

dd if=/dev/random of=/dev/stdout count=1 bs=100000 status=none | ./mooltitestwalker
mooltiness:     0.04 expected: < 1 in 68% cases, < 2 in 95%, < 3 in 99.7%

dd if=/dev/random of=/dev/stdout count=1 bs=1000000 status=none | ./mooltitestwalker
mooltiness:     2.99 expected: < 1 in 68% cases, < 2 in 95%, < 3 in 99.7%

dd if=/dev/random of=/dev/stdout count=1 bs=10000000 status=none | ./mooltitestwalker
mooltiness:     0.08 expected: < 1 in 68% cases, < 2 in 95%, < 3 in 99.7%

and now the random data from mooltipass

dd if=~/mooltirandom.bin-copy of=/dev/stdout count=1 bs=1000 status=none | ./mooltitestwalker
mooltiness:     3.16 expected: < 1 in 68% cases, < 2 in 95%, < 3 in 99.7%

dd if=~/mooltirandom.bin-copy of=/dev/stdout count=1 bs=10000 status=none | ./mooltitestwalker
mooltiness:     4.21 expected: < 1 in 68% cases, < 2 in 95%, < 3 in 99.7%

dd if=~/mooltirandom.bin-copy of=/dev/stdout count=1 bs=100000 status=none | ./mooltitestwalker
mooltiness:    12.91 expected: < 1 in 68% cases, < 2 in 95%, < 3 in 99.7%

dd if=~/mooltirandom.bin-copy of=/dev/stdout count=1 bs=1000000 status=none | ./mooltitestwalker
mooltiness:    37.46 expected: < 1 in 68% cases, < 2 in 95%, < 3 in 99.7

dd if=~/mooltirandom.bin-copy5 of=/dev/stdout count=1 bs=10000000 status=none | ./mooltitestwalker
mooltiness:   115.95 expected: < 1 in 68% cases, < 2 in 95%, < 3 in 99.7%

As you can see with just 1000 bytes we are already more than
3 standard deviations away from random data. And after that it very quickly
becomes something that a random number generator would not generate in the lifetime of
the universe not even if you fill the whole universe with random number generators should
you see this sort of statistics once

Heres the test results for 100,200,300,400,500 bytes with mooltitestcycler

for i in `seq 100 100 500` ; do dd if=~/mooltirandom.bin-copy of=/dev/stdout bs=$i count=1 status=none | ./mooltitestcycler ; done
moolticycles:     3.00, this or larger is expected 0.27 % of the time in random data.
moolticycles:     4.58, this or larger is expected 0.00046 % of the time in random data.
moolticycles:     6.00, this or larger is expected 2E-07 % of the time in random data.
moolticycles:     6.93, this or larger is expected 4.3E-10 % of the time in random data.
moolticycles:     7.75, this or larger is expected 9.5E-13 % of the time in random data.

Same but with another testsample to make sure this is not a one off

for i in `seq 100 100 500` ; do dd if=~/mooltirandom2.bin of=/dev/stdout bs=$i count=1 status=none | ./mooltitestcycler ; done
moolticycles:     3.00, this or larger is expected 0.27 % of the time in random data.
moolticycles:     4.58, this or larger is expected 0.00046 % of the time in random data.
moolticycles:     6.00, this or larger is expected 2E-07 % of the time in random data.
moolticycles:     6.93, this or larger is expected 4.3E-10 % of the time in random data.
moolticycles:     7.75, this or larger is expected 9.5E-13 % of the time in random data.

In fact i notice now the results are exactly the same, interresting
cmp  ~/mooltirandom2.bin ~/mooltirandom.bin-copy
/home/michael/mooltirandom2.bin /home/michael/mooltirandom.bin-copy differ: byte 1, line 1


heres the control test with /dev/random
for i in `seq 100 100 500` ; do dd if=/dev/random  of=/dev/stdout bs=$i count=1 status=none | ./mooltitestcycler ; done
moolticycles:     0.00, this or larger is expected 1E+02 % of the time in random data.
moolticycles:     0.31, this or larger is expected 76 % of the time in random data.
moolticycles:     0.58, this or larger is expected 56 % of the time in random data.
moolticycles:     0.44, this or larger is expected 66 % of the time in random data.
moolticycles:     0.77, this or larger is expected 44 % of the time in random data.

and a bigger sample to show the runs:

dd if=~/mooltirandom.bin-copy5 of=/dev/stdout bs=2000000 count=1 status=none | ./mooltitestcycler
Run 1731 at phase 31
Run 7496 at phase 95
Run 3323 at phase 63
Run  196 at phase 31
Run  195 at phase 95
Run 3540 at phase 63
Run 2459 at phase 31
Run  777 at phase 95
Run  775 at phase 63
Run  195 at phase 31
Run  583 at phase 95
Run  778 at phase 63
Run 1585 at phase 31
Run 1126 at phase 95
Run  971 at phase 63
Run 5047 at phase 31
Run 7141 at phase 95
Run 1741 at phase 63
Run 4643 at phase 31
Run  197 at phase 95
Run  577 at phase 63
Run  197 at phase 31
Run 2907 at phase 95
Run 4040 at phase 63
Run 1572 at phase 31
Run  196 at phase 95
Run 2903 at phase 63
Run 1355 at phase 31
Run  195 at phase 95
Run  196 at phase 63
Run  584 at phase 31
Run  143 at phase 95
Run   51 at phase 63
Run  195 at phase 31
Run 3099 at phase 95
Run  196 at phase 63
Run 1164 at phase 31
Run 2445 at phase 95
Run 2589 at phase 63
Run 4553 at phase 31
Run 7145 at phase 95
moolticycles:   499.67, this or larger is expected 0 % of the time in random data.

Shaken not Stirred

A 2nd issue i found and reported on 7th feb 2023 is that when the device is violently shaken, the accelerometer saturates and clips at 2g, this makes the 2 LSB of the affected channel(s) be 00 or 11 more often than expected in a random stream of data. So please dont use the mooltipass while doing high G maneuvers in a fighter jet or any other activity that subjects it to high g forces. Also with some effort one can shake a 3 axis accelerometer so that all 3 axis clip at the same time. There also may be a delay between the generation and use of random data. Ideally when the full 16bit sample clips it should be discarded and not used. While discarding one kind of sample that was equally frequent, introduces a bias, the clipping cases are not equally frequent. They either do not occur at all in a still environment or occur disproportionally frequent.

Random now?

Except these, i found no further flaws in the random data. Personally i would recommend to use some sort of hash or other cryptography to mix up the accelerometer bits. Heating or cooling (in my freezer with long USB cable) the device did not introduce measurable bias and also feeding ~60 mega byte stream of data into the PRNG NIST-Statistical-Test-Suite did not show any anomalies after the fix. Of course one can only find flaws in such data streams, never proof the absence of flaws. Also it must be said that i could not find any reference by the manufacturer of the chip to randomness of the LSBs. So while AFAIK many devices use accelerometer data as source of random data, there seems no guarantee that a future revision of that chip doesn't produce less random bits. What i can say, is thus just about the device i looked at and for that, the random data is much better than what a person would generate by "randomly" pressing keys. People are very biased in what characters they use in passwords even when they try to be random. Also passwords are generally too short for this anomaly to allow distinguishing 1 password from another with a unbiased RNG. A password that one believed contained n*192 bits of entropy really only contained n*190 before the fix. All this assumes the device is not violently shaken while used.

Audacity spectra

Took me a bit to find and restore the original spectrum i saw. While doing that i also noticed that using signed 8bit results in a spectrum biased the other way. The original ones are unsigned 8bit.

mooltipass pre fix spectrum	/dev/random control spectrum	mooltipass post fix spectrum

Audacity spectra with more data and in signed 8bit ints

recreated mooltipass pre fix spectrum	/dev/random spectrum	mooltipass post fix spectrum

Dieharder testsuite

Ill write a separate article about dieharder later, the thing is finicky and this is already quite complex

Updated this article multiple times (last on 2023-05-24) to include more details, pictures and minor corrections
Full disclosure, i was offered a reward for finding and reporting the bug.

Today i learned a new feature of the EU Schuko plug.
I moved some stuff to a different apartment, plugged it in and slowly build the feeling something wasn’t quite right. Some electronics behaved a bit odd, somehow grounded things didn’t feel quite grounded.
So i connected a DMM between the grounds of 2 plugs

and

and between we have

ehm, 126 Volts
On closer inspection we can see the ground lead on the wall outlet has been painted over. Sure thats a rare exception, lets look at the other lead

sure its not the 2nd plug too that our green wire eventually was connected to

sure its not all plugs on that wall

whatever, cleaning that off and retesting


Problem solved, lets pretend we didnt notice this EU population control feature ;)
Having the ground leads exposed so that morons can paint over them and then anything pluged in simply has no ground connection. Bad design, simply bad design.

The key iam using everyday is really becoming old. OTOH the new key iam using for signing my git commits isnt really good as a general key as it needs to be available on the machiene i work on to sign rebased commits and all that. So its more “my git development box” key than mine.
And i have that cute little ledger that has a gpg plugin. So i thought, thats something i should look into. Yeah, or maybe i shouldnt have done that.
It supports ed25519 and cv25519. So i created one and signing worked, decryption failed with a gpg: public key decryption failed: Card error. So i tried again with default options which generates the encryption key apparently on the host backs it up and uploads. That worked fine, it asked for a password to encrypt the backup, signing worked decryption worked, all was fine, or was it? I had set the ledger to require a button before decryption and it didnt. Hmm, i started to have a odd feeling. I disconnected the ledger and tried again, yes it still decrypted it. Was it caching the key or passphrase ? i killed gpg-agent, it still decrypted it. It took me a moment before i fully believed it but yes there was a unencrypted private key where a stub should have been pointing to the ledger.
More testing showed that the ledger works fine with RSA and NISTP256 keys for decryption and RSA and ED25519 for signing. Though it is not able to generate NISTP256 keys, or at least not when i tried, these need to be copied onto. RSA upto 4096 can be generated on the thing if one has patience. CV25519 seems not to work no matter what i tried even though it seems to be supposed to be supported.
Now, i have setup mine (and the public keys are below if you want to send me something secret) but the whole experience leaves me with afterthoughts about wanting to use this. The way this failed and the thing that the source code sometimes speaks of “ed2559” and sometimes of “ed255519” leaves me with some desire for a different device for storing my key on in the long run. Not that any of this is pointing to any real security issues once one got a working key on it and made sure no plain copies remain.

-----BEGIN PGP PUBLIC KEY BLOCK-----

mDMEY73h4hYJKwYBBAHaRw8BAQdAsSAAq3LxY0Fcw29nsG39GDF4CMgAoDV8Qb27
aHh2obq0MU1pY2hhZWwgTmllZGVybWF5ZXIgPG1pY2hhZWwta2V5MkBuaWVkZXJt
YXllci5jYz6IlgQTFggAPhYhBFwRfsTnHWQ2HRuoQq1G6+FU56XXBQJjveHiAhsD
BQkDwmcABQsJCAcCBhUKCQgLAgQWAgMBAh4BAheAAAoJEK1G6+FU56XXPyoBAJTK
YelgVZBdkSK0zo4IYqyXR+dUJMjT8SlXvAxsbHVwAP97VsXCcXWxH6oPR/LKGJgA
PDO+X5iy6pDFO6eQNmzgA4hdBBMRCAAdFiEEn/ISixR+9nMLrfEzYR7HhwQLD6sF
AmO96VUACgkQYR7HhwQLD6uDZQCfTc2K/GL0A6wi5BIGuQMM5iYMX2sAnAvxsZfA
bUjviZzbdsuCplgQduG7uFYEY73h4hIIKoZIzj0DAQcCAwS96wJJL1mSdwT94Atc
c2Q0r1O4vIkEIqnGDLGXGu3egxWzStCjojpCg+ELEDjU2rxtu51GzYLQUTazEzWU
Ql+IAwEIB4h4BBgWCAAgFiEEXBF+xOcdZDYdG6hCrUbr4VTnpdcFAmO94eICGwwA
CgkQrUbr4VTnpdflbQD+KCouQqLQ6Gl9bNrPZfXf8055b6qVtfzsQzQF+LOeo4EB
AK+6cxLVHB2jcYyvlIv73R8JWvNHcxE/3mDEYKiP3D0J
=IkKl
-----END PGP PUBLIC KEY BLOCK-----

I was playing around with a VM remotely. Without much thinking i setup a VPN and hit enter after the connect command.
It worked fine, or rather i suspect it did because it blocked the connection to the router through which i accessed it.

Now I could have gotten in the car and driven over to the thing or just ignored it as it had no real use anyway. But it turns out it was too hard for me to just ignore it. That had to be fixable remotely.
I would have expected virtualbox to have some sort of serial console or something like that. And iam sure it has a host of ways to recover this nicer but what i found first and that worked was this:

vboxmanage  controlvm (name) screenshotpng this.png ; ffplay this.png
vboxmanage  controlvm (name) keyboardputstring "foobar"
vboxmanage  controlvm (name) keyboardputscancode 12 34 56

With these we can look at the screen and we can enter things, thats more than enough to recover it. One thing to keep in mind is that the keyboardputstring commend seems to assume a us keyboard layout.
The 2nd thing to keep in mind if you use this for a similar case, you want to make sure you do not put any passwords into any shell history files. At least not without realizing it and changing the password then

Why Crypto?

With the IPFS support in FFmpeg and the discussions surrounding it. Several people stated their dislike for crypto, for NFTs and stated how its harmful and full of scams.
I disagree, Or rather I think people are seeing the “What” today but are missing the “Why” tomorrow.

Why Crypto?!

For me what i see in crypto is giving power over assets back to the people.
Today, everything is a fight of government vs people. Free speech vs censorship. Privacy vs logging and spying. Self defense vs. outlawing tools to defend oneself. And in the future with advances in gene editing control over ones own body will increasingly also get added. But back today and also with money the people are slowly loosing control to the government. Cash is slowly replaced by fully controllable and logable transactions, money printing and taxes are generally fully controlled by the government already. What you can invest in as a “non accredited” investor also is tightly controlled.
Lets look at money printing alone. That on average causes a 50% loss of value in stable currencies like the USD or EUR every 20 years. That means money literally has a half life time of 20 years in stable western economies. And that doesn’t even account for the recent money printing activities of the last years. You may have noticed inflation recently maybe ? Thats the result not of a war its simply because of all the extra money that was created.
Now with crypto, the government has no control over the inflation anymore. Bitcoin might be worth a lot or a little but is not decaying like USD does. And gold even gold inflates as new gold is mined.
And while with cash, any money you own you can give anyone you choose, as cash disappears and is replaced by government controled digital forms of the USD. You also will loose the ability to do with it what you want. OTOH with crypto you can send it to any wallet. And you can set nearly arbitrary rules with smart contracts. It simply returns the power over wealth and assets back into the peoples hands.

Will it go up

I dont know and I don’t really care. Most of the crypto i have originated from payment for a little FFmpeg work very long ago, ive exchanged some of this in other coins and other crypto stuff but i never took it out of crypto and i have no intend to ever.

NFTs?

Theres 2 things about NFTs, the NOW and the Future
NOW, NFTs are used as a way to raise money, many of the bigger projects are shady. Its expected, the more a project promises the more people want it but also the more its all a lie. I would not be surprised if many of these will go to practically 0 value. Then there are the NFTs from honest people who want to start a business and try to use it for getting initial capital some of these pass 100% of the decisions what to do with the collected money to votes by the NFT holders. There are also art and collectible NFTs and a big overlap between all this. I don’t know what will become of all this. The idea to raise money and then have the investors be 100% in control of the business sounds not fundamentally bad to me. Will this survive regulation? I do not know …
And then theres the FUTURE. NFTs can represent anything, a specific car, a specific house, a specific contract you have with an insurance.
In such a world one could sell, buy, exchange and rent houses, cars, contracts in a 100% secure, 100% undisputed and very simple way. Using the “blockchain” to represent all real world assets is an intriguing future, it has interesting potential. I don’t know if that is something that will ever happen but it surely would be a revolution for alot of things.

For a long time i used cheap wired logitech or microsoft mice and that was ok-ish. But from time to time one needs to buy a new mouse for a new computer, because the old is so dirty its disgusting or the really rare that it stopped working 100% reliable. So for some forgotten reason i bought a new one and my mistake here is that i trusted the amazon ratings (never do that). So i got a “noname == tecknet” mouse, it was cheap had more buttons than the cheap logitech one. It even was the “Amazon choice” for wired mouse. How it got that rating, i can not comprehend. The problem with this mouse is it simply does not work reliable. You turn the scroll wheel one way and it sometimes registers that and sometimes registers the opposite direction.
So as that thing was just annoying, i picked a new mouse again and using my brain slightly more this time, i concluded that any gaming mouse must be reliable as gamers dont like loosing from lost or misread buttons. So i choose based on specs and price a corsair gaming katar pro xt. Nice mouse nice hardware. linux support well, kind of. It works fine out of the box if you like your computer looking like a Christmas tree.

Switching off that LED

My first thought was of course that there must be a tool on linux to turn this off. I failed to find it though.
So the next was screwdriver / soldering iron but that was really not feeling right.
So i spend several hours implementing enough support in ckb_next to adjust the LED for this mouse. This would have been quite trivial with a windows box running the official driver and listening to it but i didnt had a windows machine, so randomly reading and writing things to the mouse was the way to go. This was especially fun as the mouse remembers its settings when disconnected. So if you successfully set something you have an incentive to undo that if you want it working as before. I didnt destroy the mouse no, basically blindfolded stabbing it with random writes allowed me to identify a few more fields of what seems called the bragi protocol. So the protocol header now lists the fields for the hardware DPI values for the 3 modes and also the corresponding colors. the mask of enabled DPI modes, a DPI index (which the hardware does not seem to bound check at least not the way id expect). And the LED brightness for both software and hardware modes. I very interestingly did not find how the LED color itself is set or how the hardware mode animation is controlled. So there are unknown things left to be found. But for my purpose what i wanted (turing the LED off) i found all i wanted.
Code is here, pull request is also send, so it may or may not end in the official ckb-next

Since 15th march, everyone in austria can get 5 free rapid antigen selftests per month. When i first heared of the free self tests i thought, “i wish these where available half a year ago and shiped to everyone, one for every day, that would have safed lives”. One per week is better than nothing of course also now after the vaccines are increasingly available its a bit late.
I dont know if all austriawide are the same but the ones we got are simple lateral flow tests made by JOYSBIO (Tianjin) Biotechnology Co.,Ltd.
They came with 3 leaflets explaining not just how to do the test but also provide details about the tests performance.