Samurize is done, gone. Its website is now just a shell. Files can be access directly over ftp but link to them have been broken on the site.
Samurize is, was “an advanced system monitoring and desktop enhancement engine”. I’ve used it for years but now there is no point as it will not be supported. Community is trying to open source it but libs and code have become cumbersome and compiling errors are to many.
For some reason, there is no interest in keeping such tool alive. Which is a huge surprise to me as I found it extremely useful, and have participated in plugin and theme development.
One of my most popular plugin with last count of over 6229 downloads was KeyLed. It allowed the user to define triggers and to control the status leds on keyboard as VU meter, HDD read/write indicator and much more. The trick is that the trick of controlling your keyboard lights is a very, very old one. Like the 2B2B2B41544829 bug in telephone modems, , the COM1 in zip files or the legendary 2600hz. Sigh…The good old days …. … are coming back 🙂
Those issues are so low level, so embedded in the operation of devices or firmware that some of them have not been solved up to this day as it would require too much investment of time and money to fix them and it is easier to just keep calm and quiet hoping no one notices.
Old issues and exploits are a good starting point when looking at future of IoT security problems. Some of those problems have already surfaced especially with most of current devices being shipped and installed with default or no passwords. What is your bluetooth device password? Is it 0000 ? Now, imagine that you have bluetooth mic or data storage.
The next era is of disposable powerful and cheap interconnected devices that are full of holes and possibly have access to your personal data. What is even more worrisome is that most of those devices will be connected to some device that interacts with its environment. Devices such as garage doors, temperature controllers, wireless lights. I would suggest watching Mr. Robot or at least reading this.
This is on its way, and that train can not and should not be stopped as it represent an evolution of internet. What you need to be is informed so you can ask proper questions and be mindful and critical of producers of IoT gear.
One of the best examples of weak security in embedded systems is described in a document Internet Census 2012 – Port scanning /0 using insecure embedded devices. It describes one person’s quest to do a scan of entire internet for the last time before the change over to IPv6. At one point it contained over 420 Thousand Clients out of which most were embedded machines; Coffee machines, refrigerators, routers and other machines with weak, default or no security. It is one extremely interesting read, I would highly recommend it. I especially liked and enjoyed the joke at the end.
Now imagine if such project had malicious intent and place it some 5 to 10 years in the future where a lot of additional thing will be in IoT. The launch of Stuxnet showed just how much damage a piece of code can do, and not to software which for most people is rather abstract but to physical objects.
Now, back to KeyLed or low level Port 64h. It’s not an exploit per se but a good example of hardware hacking and works only on keyboards connected using PS/2 connector, not USB.
Computer communicates with keyboard on I/O ports 60h which is data port, and with port 64h which is Command/Status port of keyboard. By writing to port 60h we bypass the system and change the LED indicator for eg. Caps Lock to off without changing the Caps Lock status. Caps Lock stays on even if LED is off. This enables us to play with keyboard lights without any worries.
Port 64h is used to detect if keyboard is ready. We do that by waiting that status of port 64h becomes 0. Then we prepare keyboard to change keyboard light by writing EDh to port 60h and then wait port 64h to once again become 0.
The waiting for 64h port to become 0 is a safety measure that can be bypassed but I would recommend against it. You would still be able to change the LED state but by waiting for ready state you remove some unwanted artifacts like missing keystrokes etc.
After we prepare the keyboard we can turn off and on Keyboard lights. By writing to port 60h combinations of
- Caps Lock = 4 or second bit = 1 (00000100)
- Num Lock = 2 or first bit = 1 (00000010)
- Scroll Lock = 1 or zero bit = 1 (00000001)
We can selectively turn on and off lights on the keyboard without changing capslock or numlock status.
Windows XP introduced restrictive methods for accessing hardware ports, most of IoT devices deployed currently around the world that have Over the Air update enabled (OTA) have no security check. This enables an attacker to basically overwrite the embedded devices firmware with his own and do it remotely with little to no risk of detection. An attacker would need to know the target device make and model which is, trust me, not that difficult to find out.
So, to bypass that restriction we need a way to access those hardware ports in Windows. Luckily, there already is a library that can to that for us. In the good old Dos there was Int 9 and direct access to ports but not anymore. Library that I used was Inpout32.dll. It is open source so if you really like it you could incorporate it directly into your applications removing the need for “one additional file to carry around”. After registering the dll functions in your code you can simply do the following:
Procedure presented will take three parameters that can be either true of false; NumLock Status, CapsLock Status and NumLock Status.
This small snippet is all you need to control your Keyboard Lights. Have Fun!!