screen saver

2 Articles

A Year-Long Experiment In OLED Burn-In

April 23, 2019 by 26 Comments

If you need to add a small display to your project, you’re not going to do much better than a tiny OLED display. These tiny display are black and white, usually found in resolutions of 128×64 or some other divisible-by-two value, they’re driven over I2C, the libraries are readily available, and they’re cheap. You can’t do much better for displaying a few numbers and text than an I2C OLED. There’s a problem, though: OLEDs burn out, or burn in, depending on how you define it. What’s the lifetime of these OLEDs? That’s exactly what [Electronics In Focus] is testing (YouTube, in Russian, so click the closed captioning button).

The experimental setup for this is eleven OLED displays with 128×64 pixels with an SSD1306 controller, all driven by an STM32 over I2C. Everything’s on a breadboard, and the actual display is sixteen blocks, each lit one after another with a one-second display in between. This is to test gradually increasing levels of burnout, and from a surface-level analysis, this is a pretty good way to see if OLED pixels burn out.

After 378 days of testing, this test was stopped after there were no failed displays. This comes with a caveat: after a year of endurance testing, there were a few burnt out pixels. correlating with how often these pixels were on. The solution to this problem would be to occasionally ‘jiggle’ the displayed text around the screen, turn the display off when no one is looking at it, or alternatively write a screen saver for OLEDs. That last bit has already been done, and here are the flying toasters to prove it. This is an interesting experiment, and although that weird project you’re working on probably won’t ping an OLED for a year of continuous operation, it’s still something to think about. Video below.

Continue reading “A Year-Long Experiment In OLED Burn-In” →

Screensaver Hack

Bypassing The Windows Lock Screen

February 28, 2015 by 87 Comments

Most of us know that we should lock our computers when we step away from them. This will prevent any unauthorized users from gaining access to our files. Most companies have some sort of policy in regards to this, and many even automatically lock the screen after a set amount of time with no activity. In some cases, the computers are configured to lock and display a screen saver. In these cases, it may be possible for a local attacker to bypass the lock screen.

[Adrian] explains that the screen saver is configured via a registry key. The key contains the path to a .scr file, which will be played by the Adobe Flash Player when the screen saver is activated. When the victim locks their screen and steps away from the computer, an attacker can swoop in and defeat the lock screen with a few mouse clicks.

First the attacker will right-click anywhere on the screen. This opens a small menu. The attacker can then choose the “Global settings” menu option. From there, the attacker will click on “Advanced – Trusted Location Settings – Add – Add File”. This opens up the standard windows “Open” dialog that allows you to choose a file. All that is required at this point is to right-click on any folder and choose “Open in a new window”. This causes the folder to be opened in a normal Windows Explorer window, and from there it’s game over. This window can be used to open files and execute programs, all while the screen is still locked.

[Adrian] explains that the only remediation method he knows of is to modify the code in the .swf file to disable the right-click menu. The only other option is to completely disable the flash screen saver. This may be the safest option since the screen saver is most likely unnecessary.

Update: Thanks [Ryan] for pointing out some mistakes in our post. This exploit specifically targets screensavers that are flash-based, compiled into a .exe file, and then renamed with the .scr extension. The OP mentions these are most often used in corporate environments. The exploit doesn’t exist in the stock screensaver.