Schlieren On A Stick

August 25, 2020 by Bryan Cockfield 10 Comments

Schlieren imaging is a technique for viewing the density of transparent fluids using a camera and some clever optical setups. Density of a fluid like air might change based on the composition of the air itself with various gasses, or it may vary as a result of a sound or pressure wave. It might sound like you would need a complicated and/or expensive setup in order to view such things, but with a few common things you can have your own Schlieren setup as [elad] demonstrates.

His setup relies on a cell phone, attached to a selfie stick, with a spherical mirror at the other end. The selfie stick makes adjusting the distance from the camera to the mirror easy, as a specific distance from the camera is required as a function of focal length. For cell phone cameras, it’s best to find this distance through experimentation using a small LED as the point source. Once it’s calibrated and working, a circular field of view is displayed on the phone which allows the viewer to see any change in density in front of the mirror.

The only downside of this build that [elad] notes is that the selfie stick isn’t stiff enough to prevent the image from shaking around a little bit, but all things considered this is an excellent project that shows a neat and useful trick in the photography/instrumentation world that could be useful for a lot of other projects. We’ve only seen Schlieren imaging once before and it used a slightly different method of viewing the changing densities.

Continue reading “Schlieren On A Stick” →

This Week In Security: Bluetooth Hacking, NEC Phones, And Malicious Tor Nodes

August 21, 2020 by Jonathan Bennett 4 Comments

One of the fun things about vulnerability research is that there are so many places for bugs to hide. Modern devices have multiple processors, bits of radio hardware, and millions of lines of code. When [Veronica Kovah] of Dark Mentor LLC decided to start vulnerability research on the Bluetooth Low Energy protocol, she opted to target the link layer itself, rather than the code stack running as part of the main OS. What’s interesting is that the link layer has to process data before any authentication is performed, so if a vulnerability is found here, it’s guaranteed to be pre-authentication. Also of interest, many different devices are likely to share the same BLE chipset, meaning these vulnerabilities will show up on many different devices. [Veronica] shares some great info on how to get started, as well as the details on the vulnerabilities she found, in the PDF whitepaper. (Just a quick note, this link isn’t to the raw PDF, but pulls up a GitHub PDF viewer.) There is also a video presentation of the findings, if that’s more your speed.

The first vuln we’ll look at is CVE-2019-15948, which affects a handful of Texas Instruments BT/BLE chips. The problem is in how BLE advertisement packets are handled. An advertisement packet should always contain a data length of at least six bytes, which is reserved for the sending device address. Part of the packet parsing process is to subtract six from the packet length and do a memcpy using that value as the length. A malicious packet can have a length of less than six, and the result is that the copy length integer underflows, becoming a large value, and overwriting the current stack. To actually turn this into an exploit, a pair of data packets are sent repeatedly, to put malicious code in the place where program execution will jump to.

The second vulnerability of note, CVE-2020-15531 targets a Silicon Labs BLE chip, and uses malformed extended advertisement packets to trigger a buffer overflow. Specifically, the sent message is longer than the specification says it should be. Rather than drop this malformed message, the chip’s firmware processes it, which triggers a buffer overflow. Going a step further, this chip has non-volatile firmware, and it’s possible to modify that firmware permanently. [Veronica] points out that even embedded chips like these should have some sort of secure boot implementation, to prevent these sort of persistent attacks.
Continue reading “This Week In Security: Bluetooth Hacking, NEC Phones, And Malicious Tor Nodes” →

Broken Smartphones: Laptops In Disguise

July 28, 2020 by Bryan Cockfield 22 Comments

Modern smartphones are a dizzying treatise on planned obsolescence. Whether it’s batteries that can’t be removed without four hours and an array of tiny specialized tools, screens that shatter with the lightest shock, or (worst of all) software that gets borked purposefully to make the phone seem older and slower than it really is, around every corner is some excuse to go buy a new device. The truly tragic thing is that there’s often a lot of life left in these old, sometimes slightly broken, devices.

This video shows us how to turn an old smartphone into a perfectly usable laptop. The build starts with a screen and control board that has USB-C inputs, which most phones can use to output video. It’s built into a custom aluminum case with some hinges, and then attached to a battery bank and keyboard in the base of the laptop. From there, a keyboard is installed and then the old phone is fixed to the back of the screen so that the aluminum body doesn’t interfere with the WiFi signal.

If all you need is internet browsing, messaging, and basic word processing, most phones are actually capable enough to do all of this once they are free of their limited mobile UI. The genius of this build is that since the phone isn’t entombed in the laptop body, this build could easily be used to expand the capabilities of a modern, working phone as well. That’s not the only way to get a functioning laptop with parts from the junk drawer, either, if you’d prefer to swap out the phone for something else like a Raspberry Pi.

Thanks to [NoxiousPluK] for the tip!

Continue reading “Broken Smartphones: Laptops In Disguise” →

A Tin Can Modem, Just For Fun

July 18, 2020 by Dan Maloney 9 Comments

Anyone old enough to fondly recall the “bleep-burp-rattle” sequence of sounds of a modem negotiating a connection over a phone line probably also remembers the simple “tin-can telephone” experiment, where a taut string transmits sound vibrations from the bottom of one tin can to another. This tin can modem experiment puts both of those experiences together in a single project.

As [Mike Kohn] notes, this project was harder than it would seem that it should be. He actually had a much harder time getting the tin can phone part of the project optimized than getting the electronics sorted out, resulting in multiple tries with everything from the canonical tin cans to paper coffee cups before eventually settling on a pair of cardboard nut cans, the kinds with the metal bottoms. Linked together with a length of kite string — dental floss didn’t work — [Mike] added a transmitter on one end and a receiver on the other.

The transmitter used an ATtiny 2313 and everyone’s favorite audio amplifier, the LM386, while the receiver sported an electret mike preamp board, an LM566 tone decoder, and an MSP430 microcontroller. The modulation scheme was as simple as possible — a 400 Hz tone whose length varies whether it’s a one or a zero, or a stop or start bit. Connected to a pair of terminal programs, [Mike] was able to send his name over the ~~wire~~ string at what he calculates to be six or seven baud.

This project has all the hallmarks of lockdown boredom, but we don’t care because it’s good fun and a great learning opportunity, particularly for the young ones. There’s plenty of room for optimization, too — maybe it could even get fast enough for the Hackaday Retro 300-baud challenge.

Continue reading “A Tin Can Modem, Just For Fun” →

GitHub On The Go

March 18, 2020 by Al Williams 4 Comments

It is hard to find anyone that does any kind of software development that doesn’t have some interaction with GitHub. Even if you don’t host your own projects there, there are so many things to study and borrow on the site, that it is nearly ubiquitous. However, when you’ve needed GitHub on the run, you’ve probably had to turn to your phone browser and had a reduced experience. GitHub for Mobile is now out of beta and promises a more fluid phone-based GitHub experience.

In addition to working with tasks and issues, you can also review and merge pull requests. The app sends your phone notifications, too, which can be handy. As you might expect, you can get the app for Android or iPhone in the respective stores.

Continue reading “GitHub On The Go” →

A Vintage Phone In 2020

January 14, 2020 by Jenny List 72 Comments

When we make a telephone call in 2020 it is most likely to be made using a smartphone over a cellular or IP-based connection rather than a traditional instrument on a pair of copper wires to an exchange. As we move inexorably towards a wireless world in which the telephone line serves only as a vehicle for broadband Internet, it’s easy to forget the last hundred years or more of telephone technology that led up to the present.

The iconic British telephone of the 1960s and 1970s, the GPO model 746. Mine is from 1971. (That isn’t my phone number)

In a manner of speaking though, your telephone wall socket hasn’t forgotten. If you like old phones, you can still have one, and picture yourself in a 1950s movie as you twirl the handset cord round your finger while you speak. Continue reading “A Vintage Phone In 2020” →

Possible Spyware On Samsung Phones

January 9, 2020 by Bryan Cockfield 118 Comments

[Editor’s note: There’s an ongoing back-and-forth about this “spyware” right now. We haven’t personally looked into it on any phones, and decoded Wireshark caps of what the cleaner software sends home seem to be lacking — it could be innocuous. We’re leaving our original text as-run below, but you might want to take this with a grain of salt until further evidence comes out. Or keep us all up to date in the comments. But be wary of jumping to quick conclusions.]

Samsung may have the highest-end options for hardware if you want an Android smartphone, but that hasn’t stopped them from making some questionable decisions on the software they sometimes load on it. Often these phones come with “default” apps that can’t be removed through ordinary means, or can’t even be disabled, and the latest discovery related to pre-loaded software on Samsung phones seems to be of a pretty major security vulnerability.

This software in question is a “storage cleaner” in the “Device Care” section of the phone, which is supposed to handle file optimization and deletion. This particular application is made by a Chinese company called Qihoo 360 and can’t be removed from the phone without using ADB or having root. The company is known for exceptionally bad practices concerning virus scanning, and the software has been accused of sending all information about files on the phone to servers in China, which could then turn all of the data it has over to the Chinese government. This was all discovered through the use of packet capture and osint, which are discussed in the post.

These revelations came about recently on Reddit from [kchaxcer] who made the original claims. It seems to be fairly legitimate at this point as well, and another user named [GeorgePB] was able to provide a temporary solution/workaround in the comments on the original post. It’s an interesting problem that probably shouldn’t exist on any phone, let alone a flagship phone competing with various iPhones, but it does highlight some security concerns we should all have with our daily use devices when we can’t control the software on the hardware that we supposedly own. There are some alternatives though if you are interested in open-source phones.

Thanks to [kickaxe] for the tip!

Photo from Pang Kakit [CC BY-SA 3.0 DE (https://creativecommons.org/licenses/by-sa/3.0/de/deed.en)]