Here’s a really interesting writeup by [Mike] that has two parts. He shows that not only is it possible to load wooden dice by placing them in a dish of water, but that when using these dice to get an unfair advantage in Settlers of Catan, observation of dice rolls within the game is insufficient to prove that the cheating is taking place.
[Mike] first proves that his pair of loaded dice do indeed result in a higher chance of totals above seven being rolled. He then shows how this knowledge can be exploited by a Settlers of Catan player to gain an average 5-15 additional resource cards in a typical game by taking actions that target the skewed distribution of the loaded dice.
The second part highlights shortcomings and common misunderstandings in current statistical analysis. While it’s possible to prove that the loaded dice do have a skewed distribution by rolling them an arbitrary number of times, as [Mike] and his wife do, it is not possible to detect this cheating in a game. How’s that? There are simply not enough die rolls in a game of Settlers to provide enough significant data to prove that dice distribution is skewed.
Our staff of statistics Ph.D.s would claim that [Mike] overstates his claims about shorcomings in the classical hypothesis testing framework, but the point remains that it’s possible to pass through any given statistical testing process by making the effect just small enough. And we still think it’s neat that he can cheat at Settlers by soaking wooden dice in water overnight.
This isn’t the first time we’ve seen Settlers of Catan at the center of some creative work. There’s this deluxe, hand-crafted reboot, and don’t forget the electroshock-enabled version.
[via Reddit; images from official Catan site]
For the longest time, Zener diode regulators have been one of those circuits that have been widely shared and highly misunderstood. First timers have tried to use it to power up their experiments and wondered why things did not go as planned. [James Lewis] has put up a worth tutorial on the subject titled, “Zener Diode makes for a Lousy Regulator” that clarifies the misconceptions behind using the device.
[James Lewis] does an experiment with a regulator circuit with an ESP8266 after a short introduction to Zener diodes themselves. For the uninitiated, the Zener diode can operate in the reverse bias safely and can do so at a particular voltage. This allows for the voltage across the device to be a fixed value.
This, however, depends on the current flowing through the circuit which in turn relies on the load. The circuit will work as expected for loads the draw a small amount of current. This makes it suitable for generating reference voltages for microcontrollers and such.
To make a Zener into a “proper” voltage regulator, you just need to buffer the output with an amplifier of some kind. A single transistor is the bare minimum, but actually can work pretty well. You might also add a capacitor in parallel with the Zener to smooth out some of its noise.
Zener diodes are wonderful little devices and write-ups like these are indispensable for beginners and should be shared more often like the Zener and Schottky Tutorial and Diodes as a Switch.
Everyone’s favorite packet sniffing tool, Wireshark, has been around for almost two decades now. It’s one of the most popular network analysis tools available, partially due to it being free and open source. Its popularity guaranteed that it would eventually be paired with the ESP32/8266, the rising star of the wireless hardware world, and [spacehuhn] has finally brought these two tools together to sniff WiFi packets.
The library that [spacehuhn] created uses the ESP chip to save Pcap files (the default Wireshark filetype) onto an SD card or send the data over a serial connection. The program runs once every 30 seconds, creating a new Pcap file each time. There are many example scripts for the various hardware you might be using, and since this is written for the ESP platform it’s also Arduino compatible. [spacehuhn] has written this as a proof-of-concept, so there are some rough edges still, but this looks very promising as a network analysis tool.
[spacehuhn] is no stranger to wireless networks, either. His YouTube channel is full of interesting videos of him exploring various exploits and testing other pieces of hardware. He’s also been featured here before for using an ESP8266 as a WiFi jammer.
Continue reading “ESP to Wireshark”
Ever wonder what’s inside a surface-mount inductor? Wonder no more as you watch this SMT inductor teardown video.
“Teardown” isn’t really accurate here, at least by the standard of [electronupdate]’s other component teardowns, like his looks inside LED light bulbs and das blinkenlights. “Rubdown” is more like it here, because what starts out as a rather solid looking SMT component needs to be ground down bit by bit to reveal the inner ferrite and copper goodness. [electronupdate] embedded the R30 SMT inductor in epoxy and hand lapped the whole thing until the windings were visible. Of course, just peeking inside is never enough, so he set upon an analysis of the inductor’s innards. Using a little careful macro photography and some simple image analysis, he verified the component’s data sheet claims; as an aside, is anyone else surprised that a tiny SMT component can handle 30 amps?
Looking for more practical applications for decapping components? How about iPhone brain surgery?
Continue reading “What Lies Within: SMT Inductor Teardown”
Hackaday.io has just turned two today and we couldn’t be more excited about how far we’ve come. What started out as a simple proof-of-concept, inspired by ye-olde idea of a “virtual hackerspace,” has truly evolved into a global playground for some of the best, brightest, and most creative minds you have ever met. It also became a home and the place to spend sleepless nights for many of us on the team, and we’re excited to share a few ideas on where we are headed going forward.
But before we do that, let’s look at some data.
We’re thrilled to report that over the last two years, Hackaday.io has grown from zero to a 121,158-member strong community, who have together created a total of 9,736 projects. To put this in context, it is more than a two-fold growth from last year’s milestone of 51,838 users / 4,365 projects. And it doesn’t seem to be showing any signs of slowing down.
Though these “vanity” metrics sure are a nice validation, the number that gets us the most excited is the fact that the 9,731 projects currently on the site have been created by a total 4,966 different users. What’s even better is the fact that 949 projects are a result of collaboration between two or more people. Altogether, a total of 7,170 different users have participated in the creation of the vast body of engineering knowledge currently residing on Hackaday.io.
Continue reading “Show me the Data: Hackaday.io Year #02”
[Ronnie] recently posted a new chapter in his adventures in malware deconstruction. This time the culprit was an infected Excel spreadsheet file. The .xls file was attached to a phishing email claiming to be related to a tax rebate. With tax season in full swing, this type of phishing message would be likely to be opened by an inexperienced user.
[Ronnie] saved the file to a virtual machine to prevent his real workstation from getting infected. He then opened it up in Excel and noticed that it immediately attempted to run macros. A macro is essentially visual basic scripting that runs inside of the spreadsheet file. You can use it for simple automation, cell formatting, or do even more complicated tasks like reach out to external websites and pull information. This malware focused on the latter.
[Ronnie] used the alt + F11 shortcut to view the macros. Unfortunately the attackers had password protected them. [Ronnie] wouldn’t be able to view the macro code without knowing the password. Luckily, he learned of a surprisingly simple trick to completely bypass the macro password. He opened up the .xls file in Notepad++ and located three keys; CMG, DPB, and G. [Ronnie] then created and saved a new blank .xls document and password protected the macros with his own password. He opened up this new file in Notepad++ as well, and located those same three keys. He copied the keys from the new file into the old one, and saved the old file. This effectively changed the password of the malware file to the new one he had set for his new file. This is a nifty trick that apparently only works on the older .xls formats, not the newer .xlsx format.
After loading the macros, [Ronnie] quickly noticed that most of the code was obfuscated to make it difficult to analyze. There were, however, three named modules that reference possible sandbox evasion techniques. The malware first invokes these functions to detect the presence of a virtual machine or other type of sandbox. If it detects nothing, then the rest of the malware program is decoded and executed. [Ronnie] removed these checks and then executed the macro to verify that his change had worked.
The next step was to try to view the decoded instructions. The decoded gibberish was saved to a variable. The simplest way for [Ronnie] to view the contents of the variable was to have the program create a pop-up box that displayed the contents of that variable. After making this change and running the program again, he was able to see exactly what the malware was doing. The code actually invoked Powershell, downloaded a file from the Internet, and then extracted and executed that file. In the full write-up, [Ronnie] goes even further by downloading and analyzing the executable.
[Ronnie] recently posted about his adventures in decoding malware. One of his users reported a phishy email, which did indeed turn out to contain a nasty attachment. The process that [Ronnie] followed in order to figure out what this malware was trying to do is quite fascinating and worth the full read.
[Ronnie] started out by downloading the .doc attachment in a virtual machine. This would isolate any potential damage to a junk system that could be restored easily. When he tried to open the .doc file, he was presented with an error stating that he did not have either enough memory or disk space to proceed. With 45GB of free space and 2GB of RAM, this should not have been an issue. Something was definitely wrong.
The next step was to open the .doc file in Notepad++ for analysis. [Ronnie] quickly noticed that the file was actually a .rtf disguised as a .doc. [Ronnie] scanned through large chunks of data in an attempt to guess what the malware was trying to do. He noticed that one data chunk ended with the bytes “FF” and D9″, which are also found as the ending two bytes of .gif files.
[Ronnie] copied this data into a new document and removed all new line and return characters. He then converted the hex to ASCII, revealing some more signs that this was actually image data. He saved this file as a .gif and opened it up for viewing. It was a 79KB image of a 3D rendered house. He also found another chunk of data that was the same picture, but 3MB in size. Strange to say the least.
After finding a few other weird bits of data, [Ronnie] finally started to see more interesting sections. First he noticed some strings with mixed up capital and lowercase letters, a tactic sometimes used to avoid antivirus signatures. A bit lower he found a section of data that was about the size of typical shellcode. He decoded this data and found what he was looking for. The shellcode contained a readable URL. The URL pointed to a malicious .exe file that happened to still be available online.
Of course [Ronnie] downloaded the .exe and monitored it to see how it acted. He found that it set a run key in the registry to ensure that it would persist later on. The malware installed itself to the user’s appdata folder and also reached out repeatedly to an IP address known to be affiliated with ZeuS malware. It was a lot of obfuscation, but it was still no match for an experienced malware detective.