Lair Of The Multimedia Guru

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.

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

A few days ago i wanted to print a page, nothing special here thats a common thing. But this time was different, my Samsung CLP-365 color laser printer did not print, its main LED red, the 4 toner leds all the same and lighting. On the linux side no error message or anything. Paper was in it, no paper stuck anywhere, power cycling did not help. None of the button combinations i could find that where intended to print debug information did print anything. Searching the wide net lead to a service manual and the tip to look at the display which my printer did not had and some windows software which required a windows machine. A youtube video pointed to the waste toner container but that was not the reason for the failure though it was messy.
What finally helped was connecting the printer to a mac, its printer drivers finally provided a useful error message, namely that the yellow toner cartridge was incompatible. It of course was not a original samsung one because the originals cost as much as a new printer. The other 3 cartridges where still the originals, the yellow one was bought from amazon a bit less than a year ago and it worked fine for a few months. (and this seemed not related to a firmware update)
The final confirmation that this was the issue came today as i received a replacement yellow toner cartridge again non original of course. And putting that in the printer, it came back to life, for now at least.
Iam not sure what i should think about this, but this is uncool. First samsung WTF, why if theres a fatal issue with a toner cartridge why do the LEDs for the toners all light up equally that gives 0 hope to one finding the issue. And iam not commenting about the whole toner original vs compatibility thing except id like the CEOs of all th e printer manufacteurs that make it hard to produce compatible toner cartridges to cleanup all the avoidable waste this creates. Go with a row boat please to the Great Pacific Garbage Patch and pick your incompatible toners and still good but misdiagnosed printers out and recycle them properly.

Thanks

FATE strikes back

The Cubox no longer boots, the Panda boards power supply no longer works, it actually literally fell apparent when i unplugged it

The USB stick in my Panda board failed, huge amounts of bad sectors. Ive had it running with the power supply from the dead cubox and the sdcard as storage device.
That lead to out of disk space issues as fate is not just evil but its also big. So today the panda board has a new usb stick (SanDisk Extreme Go 64GB USB 3.1), which was the cheaptest brand name + fast one i found quickly.
Some benchmarks of the SD card vs the USB stick

sd card configure (-O1 gcc-4.4)
real 0m50.546s
user 0m24.523s
sys 0m11.164s

sd card build -j2
real 24m46.453s
user 38m38.586s
sys 3m14.938s

sd card fate -j2 -k
real 75m42.462s
user 104m30.688s
sys 8m33.727s

usb configure (-O1 gcc-4.4)
real 0m47.655s
user 0m24.719s
sys 0m11.297s

usb build -j2
real 21m25.833s
user 38m32.438s
sys 3m5.820s

usb fate -j2 -k
real 57m29.724s
user 103m6.180s
sys 7m30.867s

My i7-5820K box, which runs several fate client VMs also was showing signs of age, its main disk (Samsung SSD 850 PRO 512GB) showed an accelerating increase in number of reallocated sectors. That being after over 5 years of continuous 24/7 use by multiple FATE VMs, reading and writing. Ive a few days ago replaced it by a Samsung SSD 970 PRO 1TB. That also means theres spare space now for new fate clients if i find the time to setup something …

2 days ago before going to bed i started some tests on my box. When i woke up yesterday, i couldnt login remotely to the box, looking more careful the box was waiting for keyboard input during boot. It had issues previously and i intended to replace it for a long time. That was on hold because the ryzen 3950X isnt available yet which i wanted to use for a new box.
So i helped it boot, restarted the task and a bit later the box fans and disks spun down it rebooted again. My first thought was power supply or mainboard issue. The box after all was used alot and was somewhat old. I had a power supply laying around which was intended for my the future 3950X. So a little unhappy i moved the other machine that blocked access to the failing box away. Next with some dust mask and vacuum cleaner i removed many years of dust. Having removed all dust that failed to hold on. I wanted to check if it still booted, what temperature it reached and if maybe it worked now. The moment i switched it on i was glad i had the dust mask still on, for some reason more dust was blown out by the noctua fans. And it was interesting to see the dust coming out and some of it being sucked into my still running vacuum cleaner. The machine booted and i restarted the task, it didnt fail. So i tried again and then run fate in a loop. It reached 86°C cpu temp IIRC but it didnt fail or reboot again. Now a day later, the machine showed no further anomalies, it seems happy again.
This was the first time I ve had a system apparently failing from nothing but dust.

A few days ago when i wanted to run some benchmarks on my cubox, i run into some odd errors, investigation led to the micro sd card. There where several bad sectors that could not be read anymore.
Thats the first time ive myself seen a sandisk micro sd fail. ive seen transcend (really quickly) and kingston (not so quick) fails but no sandisk or samsung till now.
Another point for FATE, another disk it won against…
But how badly damaged is the sd card? ive run ddrescue on it for a few days:

# ddrescue -r 5 /dev/sdd backups/cubox-2019-01-07 backups/cubox-2019-01-07.log

GNU ddrescue 1.17
Press Ctrl-C to interrupt
Initial status (read from logfile)
rescued: 7947 MB, errsize: 493 kB, errors: 217
Current status
rescued: 7947 MB, errsize: 254 kB, current rate: 0 B/s
ipos: 7389 MB, errors: 48, average rate: 122 B/s
opos: 7389 MB, time since last successful read: 1.5 m
Finished
# ddrescue -r 20 /dev/sdd backups/cubox-2019-01-07 backups/cubox-2019-01-07.log

GNU ddrescue 1.17
Press Ctrl-C to interrupt
Initial status (read from logfile)
rescued: 7947 MB, errsize: 254 kB, errors: 48
Current status
rescued: 7948 MB, errsize: 193 kB, current rate: 0 B/s
ipos: 7389 MB, errors: 37, average rate: 10 B/s
opos: 7389 MB, time since last successful read: 7.2 m
Finished
# ddrescue -r 40 /dev/sdd backups/cubox-2019-01-07 backups/cubox-2019-01-07.log

GNU ddrescue 1.17
Press Ctrl-C to interrupt
Initial status (read from logfile)
rescued: 7948 MB, errsize: 193 kB, errors: 37
Current status
rescued: 7948 MB, errsize: 176 kB, current rate: 0 B/s
ipos: 7389 MB, errors: 36, average rate: 1 B/s
opos: 7389 MB, time since last successful read: 41.4 m
Finished
# ddrescue -r 80 /dev/sdd backups/cubox-2019-01-07 backups/cubox-2019-01-07.log

GNU ddrescue 1.17
Press Ctrl-C to interrupt
Initial status (read from logfile)
rescued: 7948 MB, errsize: 176 kB, errors: 36
Current status
rescued: 7948 MB, errsize: 172 kB, current rate: 0 B/s
ipos: 7389 MB, errors: 35, average rate: 0 B/s
opos: 7389 MB, time since last successful read: 4.7 h
Finished
# ddrescue -r 160 /dev/sdd backups/cubox-2019-01-07 backups/cubox-2019-01-07.log

GNU ddrescue 1.17
Press Ctrl-C to interrupt
Initial status (read from logfile)
rescued: 7948 MB, errsize: 172 kB, errors: 35
Current status
rescued: 7948 MB, errsize: 163 kB, current rate: 0 B/s
ipos: 7389 MB, errors: 33, average rate: 0 B/s
opos: 7389 MB, time since last successful read: 41.7 m
Finished
# time ddrescue -r 320 /dev/sdd backups/cubox-2019-01-07 backups/cubox-2019-01-07.log

GNU ddrescue 1.17
Press Ctrl-C to interrupt
Initial status (read from logfile)
rescued: 7948 MB, errsize: 163 kB, errors: 33
Current status
rescued: 7948 MB, errsize: 151 kB, current rate: 0 B/s
ipos: 7389 MB, errors: 30, average rate: 0 B/s
opos: 7389 MB, time since last successful read: 4.7 h
Finished

real 1119m16.116s
user 0m1.274s
sys 0m3.877s
# time ddrescue -r 640 /dev/sdd backups/cubox-2019-01-07 backups/cubox-2019-01-07.log

GNU ddrescue 1.17
Press Ctrl-C to interrupt
Initial status (read from logfile)
rescued: 7948 MB, errsize: 151 kB, errors: 30
Current status
rescued: 7948 MB, errsize: 147 kB, current rate: 0 B/s
ipos: 4393 MB, errors: 30, average rate: 0 B/s
opos: 4393 MB, time since last successful read: 15.1 h
Retrying bad sectors… Retry 375^C
Interrupted by user

real 1236m21.926s
user 0m1.383s
sys 0m4.204s

Its interesting to note that even after quite some time there are still damaged sectors which can be recovered. It was just myself loosing patience that made me stop it. Also i have a backup somewhere IIRC so this recovery was just out of curiosity. And maybe ill play more with this card in the future to see if theres anything that can be done to improve recovery.

Hopefully ill have the cubox with a new sd card up and running fate soon again … (should be quite trivial)

A few days ago i noticed that my panda-board died. This is one of the 2 ARM systems on fate.ffmpeg.org.
Resetting or unplugging and re-plugging did not help. Replacing the power supply with a random 5v supply made it come back to life.
The failed power supply is a HNP-24-050 “HN Power Germany”. This is now probably the 3rd or 4th failed power supply for my panda board. The one its running on currently is a random one from ali-express. I must say iam really disappointed by the trash that some german electronic shops sell. All the failed power supplies where bought from germany, not china. The failed supply still produces 5v but when subjected to the slightest load its output collapses to 0, even 200mA is too much.
Ive read on the net that some digikey supply is recommended but both part numbers i found are marked obsolete.
Anyone has any recommendations ? I am not too positive that the 2€ +free shipping supply its running on currently will last very long.
I know i can just run it off a brand name ATX supply or a bench supply but that is a bit inconvenient.
Also if anyone wants to add more ARM hardware to fate.ffmpeg.org, so we have a bit more redundancy, thats certainly welcome

After running into the row-hammer issue with new DDR3 SO-DIMMS for my notebook, ive tested all my used computers ram. I think i had tested at least some of it previously. These where DDR4 Micron Technology 16ATF1G64AZ-2G1A1 and CML16GX3M4A1600C9 from corsair. Both showed no issues on multiple passes of the row hammer test. Ive also now obtained new SO-DIMMS for my notebook, M471B1G73EB0-YK0 from Samsung and HMT41GS6AFR8A-PB from SK Hynix. Both as well have shown 0 issues in the row hammer test on multiple passes. So it seems that the issue is not as widespread in 2017-11 as looking at a set of 2 modules would have suggested. Ill return the faulty modules …
Iam a bit curious who the manufacturer of the chips on the faulty modules is but there are stickers over them and as i want to return them i dont want to peel these off. And in dmidecode they are just listed as “Corsair”. I guess if Corsair wants to make it hard to find out who made them, they will have to take the blame here.

My notebook has 8gb ram and without swap occasionally that was not enough. So i thought hey trivial put more memory in. And while online resources disagreed on the maximum supported for my Acer Aspire V3-571G. It seems fine with 2 8gb sticks. But …
When running memtest (MemTest86 V7.4 actually, which was the first google pointed me to). It displayed after a while a note, “[Note] RAM may be vulnerable to high frequency row hammer bit flips”. After a short wtf moment, and a bit of research, this is a hardware bug that can be used to flip bits one normally has no access to and exploit an affected machine. I think i did actually read about it years ago but did not immediately connect the note message to it.
But what i find really disturbing is that we have november 2017 many years since its known. And these are newly bought sodimm modules (brand name in fact from corsair, CMSX16GX3M2B1600C9. Both of the 2 modules alone also are affected.
Un-voluntarily that also leads myself to the question, does anyone know of similar sodimm modules (can be slower i dont care) which do not have this issue? Or a way to increase the ram refresh rate on a notebook where this seems not available in BIOS? (I guess i could go read the chipset datasheets but maybe some tool already exists …)

About 3 months ago my cheap/small color laser printer stopped eating. It tried but most of the time it just failed and very soon it completely stopped working, giving a generic paper stuck kind of error so i had to take it apart and fix it as i needed it. I am writing this 3 month after fixing it, as i didnt had time before, but maybe its still useful for someone.
I have the suspicion all printers of this design will fail this way.

Disassembly

The printer is held together with screws and little plastic hooks, below are some pictures of my disassembly of it. The part we need to get to, is a small steel part which is moved by a solenoid.





Below is the part that causes the problem, the sticky foam thing on it has become slightly sticky on the wrong side and is also squished. The device still works if the solenoid is pulsed with sufficient power.

Repair

This is very trivial, remove the decaying black foam thingy and replace it with something that is non sticky on one side and
has dimensions somewhat similar to the original. I used very strong double sided tape to get the thickness and covered in chinese “blue” painters tape from my 3d printer to make it non sticky on one side. If you can, test that the solenoid works before reassembly.

Reassembly

Just undo the disassembly in reverse order, weave all the wires back in as they where before.


3 Months since the repair above, my printer still works and had 0 paper feed failures (unless it run out of paper).
Now (2023-12), 6 years later, i am still using this printer and it still works with no further problems :)