Many a hacker has dug an old flash drive out of the bottom of a backpack, and peeled apart the damaged plastic case to look inside. More often then not, you’d expect to see some SMD chips on a PCB along with a few passives, an LED and a USB port. [Gough] found something else entirely, and documented it for the interested public.

Inside the Comsol 8GB USB stick, [Gough] found an entire microSD card. One might be led to think this is a card reader and microSD masquerading as a normal flash drive, but the reality is far different. Instead, the drive contains a Flash memory controller which addresses the microSD card as raw NAND, through test points normally covered up on consumer-grade cards. The drive appears to be manufactured from factory second microSD cards that don’t pass the normal tests to be onsold to the public.

Armed with software obtained through spurious channels, [Gough] is able to dive deeper into the guts of the flash drive. The engineering tools allow the card to be optimised for capacity or speed, and different levels of error correction. It’s even possible to have the flash drive emulate a U3 CD ROM drive for OS installs and other purposes.

It’s a great dive into how USB drives work on a low level, and how the firmware and hardware work together. We’ve seen other flash drive hacks before too – like this simple recovery trick!

source https://hackaday.com/2020/07/17/usb-flash-drive-reveals-strange-sd-card-heart/

When it comes to cleaning your hands, [Arnov Sharma] is not messing around. He built an automatic soap dispenser using ultrasonic sensors, a stepper motor for activating the pump, and 3D printed components for housing a bottle of soap – a spectacular display of over-engineering. At least he won’t be needing to stand in line at the supermarket for motion detection soap dispensers anytime soon.

Initially, he had the idea to build the dispenser using a common servo motor-based method.  This would involve activating motors to push down on the plunger for the soap bottle to dispense soap. Instead, he for a different approach that ended up being fairly straightforward in theory, although the execution is pretty involved.

He started off by 3D printing the compartment where the soap bottle would sit and the structural support for the Z-axis rail that would be pushing down on the soap bottle. It’s similar to the type of linear actuator you might find in a 3D printer or PCB mill, where a motor controls a rotating screw that moves the carriage across a belt. (We presume the linear rail came first, and the ultrasonic soap dispenser second.)

In this build, there are two additional rods added to help support the lever pressing down on the soap dispenser.

 

The setup is controlled by an Arduino, which triggers the movement from the linear actuator if it receives a signal from an ultrasonic sensor. He’s added the model files and Arduino code for other makers curious about building a similar project. Check out his video for the soap dispenser in action – the stepper motor definitely makes for a much more powerful plunge than you might expect.

source https://hackaday.com/2020/07/17/this-soap-dispenser-will-crush-your-germs/

Hackaday editors Elliot Williams and Mike Szczys are enamored by this week’s fabrication hacks. There’s a PCB mill that isolates traces by scratching rather than cutting. You won’t believe how awesome this angle-cutter jig is at creating tapered augers for injection molding/extruding plastic. And you may not need an interactive way to cut foam, but the art from the cut pieces is more than a mere shadow of excellence. Plus we gab about a clever rotary encoder circuit, which IDE is the least frustrating, and the go-to tools for hard drive recovery.

Take a look at the links below if you want to follow along, and as always, tell us what you think about this episode in the comments!

Direct download (~65 MB)

Places to follow Hackaday podcasts:

• Google Play
• iTunes
• Soundcloud
• Spotify
• Stitcher
• RSS

Episode 076 Show Notes:

New This Week:

• Roboticist Grant Imahara Of Mythbusters Fame Dies Of Aneurysm At Age 49
• Don’t Wait, You Need To See Comet NEOWISE Right Now
  • Stellarium Web Online Star Map
• Dream Team Members Announced For The 2020 Hackaday Prize

Interesting Hacks of the Week:

• Making PCBs The Easy Way
  • Ironclad Tips For Copper-Clad Prototyping
  • Build An Everlasting Continuity Tester
• Learn The Secrets Of Matching Bottle Cap Threads To One Another
  • threadlib: thread library for OpenSCAD
• Making Smalltalk On A Raspberry Pi
  • Project Oberon
  • Reviving a computer system of 25 years ago
  • Hjalfi makes smalltalk (in Javascript)
• Interactive CNC Foam Cutter Churns Out Abstract Art
  • We Didn’t Know The Sun Could Do Digital
  • CNC Hot-Wire Cutter Gives Form To Foam
• Open-Source Grinder Makes Compression Screws For Plastic Extruders Easy
• Spoofing An Analog Rotary Knob With An ATtiny, And Vampiric Power
  • LS7183 quadrature converter datasheet

Quick Hacks:

• Elliot’s Picks:
  • Home Automation Covers Everything
  • An Easier Way To Roll Your Own LED Ball
  • High-End Ham Radio Gives Up Its Firmware Secrets
• Mike’s Picks:
  • 1975 Circuit Board Was A Masterpiece Hidden On Your Wrist
  • Printed TS100 Case Beats The Heat With A Bearing
  • Video: Bil Herds Looks At Mitosis

Can’t-Miss Articles:

• Tales From The Sysadmin: Impending Hard Drive Doom
• Surgery On The Arduino IDE Makes Bigger Serial Buffers

source https://hackaday.com/2020/07/17/hackaday-podcast-076-grinding-compression-screws-scratching-pcbs-and-melting-foam/

There was a time when building realistic simulations of vehicles was the stuff of NASA and big corporations. Today, many people have sophisticated virtual cockpits or race cars that they use with high-resolution screens or even virtual reality gear. If you think about it, a virtual car isn’t that hard to pull off. All you really need is a steering wheel, a few pedals, and a gear shifter. Sure, you can build fans to simulate the wind and put haptics in your seat, but really the input devices alone get you most of the way there. [Oli] decided he wanted a quick and easy USB gear shifter so he took a trip to the hardware store, picked up an arcade joystick, and tied it all together with an Arduino Leonardo. The finished product that you can see in the video below cost about $30 and took less than six hours to build.

The Leonardo, of course, has the ability to act like a USB human interface device (HID) so it can emulate a mouse or a keyboard or a joystick. That comes in handy for this project, as you would expect. The computer simply has to read the four joystick buttons and then decide which gear matches which buttons. For example up and to the left is first gear, while 4th gear is only the down button depressed. A custom-cut wooden shifter plate gives you the typical H pattern you expect from a stick shift.

Of course, the joystick doesn’t have a long handle like a true stick shift, so [Oli] added some extensions. In addition, a real shifter doesn’t require you to hold it in position as a joystick would. To rectify this, the shifter plate has magnets that grab the stick and hold it. They aren’t strong enough that you can’t move the stick, but they are strong enough to keep it from moving on its own.

We noticed that the design doesn’t allow for a clutch, so it isn’t quite the same as driving a real stick. However, [Oli] mentions several upgrades he has in mind and a clutch is one of them. Some haptics would be a cool addition so could feel the gears grind if you didn’t do the shift correctly.

The last shifter we saw like this was 3D printed. It is getting harder to find a car in the US with a manual transmission, but [Kristina Panos] is definitely a fan.

source https://hackaday.com/2020/07/17/four-on-the-floor-for-your-virtual-race-car/

Twitter just had their biggest security breach in years. Mike warned us about it on Wednesday, but it’s worth revisiting a few of the details. The story is still developing, but it appears that malicious actors used social engineering to access an internal Twitter dashboard. This dashboard, among other interesting things, allows directly changing the email address associated with an account. Once the address is changed to the attacker’s, it’s simple to do a password reset and gain access.

The bitcoin address used in the crypto scam ended up receiving nearly $120,000 USD worth of bitcoin, all of which has been shuffled off into different accounts. It’s an old and simple scam, but was apparently rather believable because the messages were posted by verified Twitter accounts.

A series of screenshots have been posted, claiming to be the internal Twitter dashboard used in the attack. More than a few eyebrows have been raised, as a result of that dashboard. First off, the fact that Twitter employees can directly change an account’s email address is asking for trouble. Even more interesting are the tags that can be added to an account. “Trends Blacklist” and “Search Blacklist” do call to mind the rumors of shadow-banning, but at this point it’s impossible to know the details. Motherboard is reporting that Twitter is removing that screenshot across the board when it’s posted, and even suspending accounts that post it. Of course, they’d do that if it were faked as well, so who knows?

We detected what we believe to be a coordinated social engineering attack by people who successfully targeted some of our employees with access to internal systems and tools.

— Twitter Support (@TwitterSupport) July 16, 2020

SIGRed

CVE-2020-1350 was just announced and fixed as a part of Microsoft’s patch Tuesday push. If you run a Windows Server machine, especially if it has a DNS resolver running, make sure to go patch right away. Yet another CVE scoring a perfect 10, this one is particularly bad as it appears to be a wormable exploit.

Some of the vulnerability details are already available — enough to get an idea of what’s going on. The flaw is in how the DNS daemon handles DNS SIG responses. The code that allocates a buffer for the sig response uses a 16 bit int for the allocation size. It maxes out at 64k characters. As UDP DNS responses have an enforced size limit of 4096 bytes, this seems safe. As you might guess, there’s a catch.

Certain legitimate DNS responses do in fact require more than 4096 bytes, so the spec includes the truncation flag, which means that there is more to this message that didn’t fit in the UDP packet. The proper response is to initiate a TCP connection and make the request again. Once the DNS request is happening over TCP, that message can be up to 64k in length. Still not long enough to trigger the bug. Enter DNS pointer compression. DNS responses can contain a simple type of data compression, usually used to squeeze a message into a single UDP packet. If this compression is used on a TCP DNS query, the final decompressed message size can exceed 64k.

Once the message is decompressed, a buffer is allocated, based on the message size, but because it’s a 16-bit int, if the size is over 64k, that value wraps back around to 0. So a small buffer is allocated, and then 64+ kB of data is copied to it, overwriting the end of the buffer. Because of the security features built into modern versions of Windows Server, there are more steps to a full compromise, but based on the response to this vulnerability, it seems that a sophisticated attacker won’t have too much trouble developing it into a full exploit.

SAP RECON

The third major event of this week is the RECON vulnerability in SAP devices, accompanied by a not very helpful PDF. CVE-2020-6287 scored a severity of 10, as it’s exploitable from the network with no authentication, and easily leads to a full takeover of the system. The flaw is twofold, first is yet another path transversal attack. The “../” operator isn’t properly stripped out of incoming requests. The other half of the vulnerability is the fact that certain URL endpoints on a vulnerable device are accessible without authentication.

A Proof of Concept has been posted to Github, though without the RCE elements. It’s likely that the specifics needed to fully compromise the device will be figured out in short order, so best to get your devices updated right away.

Apple Security Bypass

MacOS has a built in app sandboxing system, known as TCC. The aim of this particular component is to keep an app from accessing the rest of the filesystem without user permission. [Jeff Johnson] discovered a way to bypass that protection, and reported it to Apple, who have yet to fix it. After waiting six months, double the standard disclosure time, he’s published his findings for all to see.

Android Security Updates

The July security updates for Android have been released, and there are a couple of interesting vulns in there, namely CVE-2020-0224 and CVE-2020-0225.

0224 seems to be related to the processing of regular expressions. Based on the limited bug writeup, it’s unclear how this vulnerability would be triggered remotely. This bug is a bit of an older one, first discovered in the Chromium project. Because of the code sharing between projects, it was present in both, and only now getting patched in Android.

0225 is a Bluetooth issue, related to audio over Bluetooth. The details are scarce, but it appears that a 0-length packet can trigger a null pointer access.

The 4 Hour Unc0ver Uncovering

And lastly for this week, [Brandon Azad] at Google’s Project Zero steps us through the story of taking apart the unc0ver jailbreak, designing a PoC, and sending the issue over to Apple. In the case of a big release like that one, there’s something of a race to see who can reverse engineer it first. Brandon couldn’t make heads or tails out of the heavily obfuscated exploit binary, but he had a clever trick up his sleeve. Start the exploit, but kill that app before the install finished. The system was left in an unstable state, crashed, and he was able to trace the crash back to the vulnerability. The full write-up is worth checking out.

source https://hackaday.com/2020/07/17/this-week-in-security-twitter-windows-dns-sap-recon/

Twitter just had their biggest security breach in years. Mike warned us about it on Wednesday, but it’s worth revisiting a few of the details. The story is still developing, but it appears that malicious actors used social engineering to access an internal Twitter dashboard. This dashboard, among other interesting things, allows directly changing the email address associated with an account. Once the address is changed to the attacker’s, it’s simple to do a password reset and gain access.

The bitcoin address used in the crypto scam ended up receiving nearly $120,000 USD worth of bitcoin, all of which has been shuffled off into different accounts. It’s an old and simple scam, but was apparently rather believable because the messages were posted by verified Twitter accounts.

A series of screenshots have been posted, claiming to be the internal Twitter dashboard used in the attack. More than a few eyebrows have been raised, as a result of that dashboard. First off, the fact that Twitter employees can directly change an account’s email address is asking for trouble. Even more interesting are the tags that can be added to an account. “Trends Blacklist” and “Search Blacklist” do call to mind the rumors of shadow-banning, but at this point it’s impossible to know the details. Motherboard is reporting that Twitter is removing that screenshot across the board when it’s posted, and even suspending accounts that post it. Of course, they’d do that if it were faked as well, so who knows?

We detected what we believe to be a coordinated social engineering attack by people who successfully targeted some of our employees with access to internal systems and tools.

— Twitter Support (@TwitterSupport) July 16, 2020

SIGRed

CVE-2020-1350 was just announced and fixed as a part of Microsoft’s patch Tuesday push. If you run a Windows Server machine, especially if it has a DNS resolver running, make sure to go patch right away. Yet another CVE scoring a perfect 10, this one is particularly bad as it appears to be a wormable exploit.

Some of the vulnerability details are already available — enough to get an idea of what’s going on. The flaw is in how the DNS daemon handles DNS SIG responses. The code that allocates a buffer for the sig response uses a 16 bit int for the allocation size. It maxes out at 64k characters. As UDP DNS responses have an enforced size limit of 4096 bytes, this seems safe. As you might guess, there’s a catch.

Certain legitimate DNS responses do in fact require more than 4096 bytes, so the spec includes the truncation flag, which means that there is more to this message that didn’t fit in the UDP packet. The proper response is to initiate a TCP connection and make the request again. Once the DNS request is happening over TCP, that message can be up to 64k in length. Still not long enough to trigger the bug. Enter DNS pointer compression. DNS responses can contain a simple type of data compression, usually used to squeeze a message into a single UDP packet. If this compression is used on a TCP DNS query, the final decompressed message size can exceed 64k.

Once the message is decompressed, a buffer is allocated, based on the message size, but because it’s a 16-bit int, if the size is over 64k, that value wraps back around to 0. So a small buffer is allocated, and then 64+ kB of data is copied to it, overwriting the end of the buffer. Because of the security features built into modern versions of Windows Server, there are more steps to a full compromise, but based on the response to this vulnerability, it seems that a sophisticated attacker won’t have too much trouble developing it into a full exploit.

SAP RECON

The third major event of this week is the RECON vulnerability in SAP devices, accompanied by a not very helpful PDF. CVE-2020-6287 scored a severity of 10, as it’s exploitable from the network with no authentication, and easily leads to a full takeover of the system. The flaw is twofold, first is yet another path transversal attack. The “../” operator isn’t properly stripped out of incoming requests. The other half of the vulnerability is the fact that certain URL endpoints on a vulnerable device are accessible without authentication.

A Proof of Concept has been posted to Github, though without the RCE elements. It’s likely that the specifics needed to fully compromise the device will be figured out in short order, so best to get your devices updated right away.

Apple Security Bypass

MacOS has a built in app sandboxing system, known as TCC. The aim of this particular component is to keep an app from accessing the rest of the filesystem without user permission. [Jeff Johnson] discovered a way to bypass that protection, and reported it to Apple, who have yet to fix it. After waiting six months, double the standard disclosure time, he’s published his findings for all to see.

Android Security Updates

The July security updates for Android have been released, and there are a couple of interesting vulns in there, namely CVE-2020-0224 and CVE-2020-0225.

0224 seems to be related to the processing of regular expressions. Based on the limited bug writeup, it’s unclear how this vulnerability would be triggered remotely. This bug is a bit of an older one, first discovered in the Chromium project. Because of the code sharing between projects, it was present in both, and only now getting patched in Android.

0225 is a Bluetooth issue, related to audio over Bluetooth. The details are scarce, but it appears that a 0-length packet can trigger a null pointer access.

The 4 Hour Unc0ver Uncovering

And lastly for this week, [Brandon Azad] at Google’s Project Zero steps us through the story of taking apart the unc0ver jailbreak, designing a PoC, and sending the issue over to Apple. In the case of a big release like that one, there’s something of a race to see who can reverse engineer it first. Brandon couldn’t make heads or tails out of the heavily obfuscated exploit binary, but he had a clever trick up his sleeve. Start the exploit, but kill that app before the install finished. The system was left in an unstable state, crashed, and he was able to trace the crash back to the vulnerability. The full write-up is worth checking out.

source https://hackaday.com/2020/07/17/this-week-in-security-twitter-windows-dns-sap-recon/

Twitter just had their biggest security breach in years. Mike warned us about it on Wednesday, but it’s worth revisiting a few of the details. The story is still developing, but it appears that malicious actors used social engineering to access an internal Twitter dashboard. This dashboard, among other interesting things, allows directly changing the email address associated with an account. Once the address is changed to the attacker’s, it’s simple to do a password reset and gain access.

The bitcoin address used in the crypto scam ended up receiving nearly $120,000 USD worth of bitcoin, all of which has been shuffled off into different accounts. It’s an old and simple scam, but was apparently rather believable because the messages were posted by verified Twitter accounts.

A series of screenshots have been posted, claiming to be the internal Twitter dashboard used in the attack. More than a few eyebrows have been raised, as a result of that dashboard. First off, the fact that Twitter employees can directly change an account’s email address is asking for trouble. Even more interesting are the tags that can be added to an account. “Trends Blacklist” and “Search Blacklist” do call to mind the rumors of shadow-banning, but at this point it’s impossible to know the details. Motherboard is reporting that Twitter is removing that screenshot across the board when it’s posted, and even suspending accounts that post it. Of course, they’d do that if it were faked as well, so who knows?

We detected what we believe to be a coordinated social engineering attack by people who successfully targeted some of our employees with access to internal systems and tools.

— Twitter Support (@TwitterSupport) July 16, 2020

SIGRed

CVE-2020-1350 was just announced and fixed as a part of Microsoft’s patch Tuesday push. If you run a Windows Server machine, especially if it has a DNS resolver running, make sure to go patch right away. Yet another CVE scoring a perfect 10, this one is particularly bad as it appears to be a wormable exploit.

Some of the vulnerability details are already available — enough to get an idea of what’s going on. The flaw is in how the DNS daemon handles DNS SIG responses. The code that allocates a buffer for the sig response uses a 16 bit int for the allocation size. It maxes out at 64k characters. As UDP DNS responses have an enforced size limit of 4096 bytes, this seems safe. As you might guess, there’s a catch.

Certain legitimate DNS responses do in fact require more than 4096 bytes, so the spec includes the truncation flag, which means that there is more to this message that didn’t fit in the UDP packet. The proper response is to initiate a TCP connection and make the request again. Once the DNS request is happening over TCP, that message can be up to 64k in length. Still not long enough to trigger the bug. Enter DNS pointer compression. DNS responses can contain a simple type of data compression, usually used to squeeze a message into a single UDP packet. If this compression is used on a TCP DNS query, the final decompressed message size can exceed 64k.

Once the message is decompressed, a buffer is allocated, based on the message size, but because it’s a 16-bit int, if the size is over 64k, that value wraps back around to 0. So a small buffer is allocated, and then 64+ kB of data is copied to it, overwriting the end of the buffer. Because of the security features built into modern versions of Windows Server, there are more steps to a full compromise, but based on the response to this vulnerability, it seems that a sophisticated attacker won’t have too much trouble developing it into a full exploit.

SAP RECON

The third major event of this week is the RECON vulnerability in SAP devices, accompanied by a not very helpful PDF. CVE-2020-6287 scored a severity of 10, as it’s exploitable from the network with no authentication, and easily leads to a full takeover of the system. The flaw is twofold, first is yet another path transversal attack. The “../” operator isn’t properly stripped out of incoming requests. The other half of the vulnerability is the fact that certain URL endpoints on a vulnerable device are accessible without authentication.

A Proof of Concept has been posted to Github, though without the RCE elements. It’s likely that the specifics needed to fully compromise the device will be figured out in short order, so best to get your devices updated right away.

Apple Security Bypass

MacOS has a built in app sandboxing system, known as TCC. The aim of this particular component is to keep an app from accessing the rest of the filesystem without user permission. [Jeff Johnson] discovered a way to bypass that protection, and reported it to Apple, who have yet to fix it. After waiting six months, double the standard disclosure time, he’s published his findings for all to see.

Android Security Updates

The July security updates for Android have been released, and there are a couple of interesting vulns in there, namely CVE-2020-0224 and CVE-2020-0225.

0224 seems to be related to the processing of regular expressions. Based on the limited bug writeup, it’s unclear how this vulnerability would be triggered remotely. This bug is a bit of an older one, first discovered in the Chromium project. Because of the code sharing between projects, it was present in both, and only now getting patched in Android.

0225 is a Bluetooth issue, related to audio over Bluetooth. The details are scarce, but it appears that a 0-length packet can trigger a null pointer access.

The 4 Hour Unc0ver Uncovering

And lastly for this week, [Brandon Azad] at Google’s Project Zero steps us through the story of taking apart the unc0ver jailbreak, designing a PoC, and sending the issue over to Apple. In the case of a big release like that one, there’s something of a race to see who can reverse engineer it first. Brandon couldn’t make heads or tails out of the heavily obfuscated exploit binary, but he had a clever trick up his sleeve. Start the exploit, but kill that app before the install finished. The system was left in an unstable state, crashed, and he was able to trace the crash back to the vulnerability. The full write-up is worth checking out.

source https://hackaday.com/2020/07/17/this-week-in-security-twitter-windows-dns-sap-recon/