So you’ve built yourself an awesome radar system but it’s not performing as well as you had hoped. You assume this may have something to do with the tin cans you are using for antennas. The obvious next step is to design and build a horn antenna spec’d to work for your radar system. [Henrik] did exactly this as a way to improve upon his frequency modulated continuous wave radar system.
To start out, [Henrik] designed the antenna using CST software, an electromagnetic simulation program intended for this type of work. His final design consists of a horn shape with a 100mm x 85mm aperture and a length of 90mm. The software simulation showed an expected gain of 14.4dB and a beam width of 35 degrees. His old cantennas only had about 6dB with a width of around 100 degrees.
The two-dimensional components of the antenna were all cut from sheet metal. These pieces were then welded together. [Henrik] admits that his precision may be off by as much as 2mm in some cases, which will affect the performance of the antenna. A sheet of metal was also placed between the two horns in order to reduce coupling between the antennas.
[Henrik] tested his new antenna in a local football field. He found that his real life antenna did not perform quite as well as the simulation. He was able to achieve about 10dB gain with a field width of 44 degrees. It’s still a vast improvement over the cantenna design.
If you haven’t given Radar a whirl yet, check out [Greg Charvat’s] words of encouragement and then dive right in!
[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.
[Laxman] is back again with another hack related to Facebook photos. This hack revolves around the Facebook mobile application’s “sync photos” function. This feature automatically uploads every photo taken on your mobile device to your Facebook account. These photos are automatically marked as private so that only the user can see them. The user would have to manually update the privacy settings on each photo later in order to make them available to friends or the public.
[Laxman] wanted to put these privacy restrictions to the test, so he started poking around the Facebook mobile application. He found that the Facebook app would make an HTTP GET request to a specific URL in order to retrieve the synced photos. This request was performed using a top-level access token. The Facebook server checked this token before sending down the private images. It sounds secure, but [Laxman] found a fatal flaw.
The Facebook server only checked the owner of the token. It did not bother to check which Facebook application was making the request. As long as the app had the “user_photos” permission, it was able to pull down the private photos. This permission is required by many applications as it allows the apps to access the user’s public photos. This vulnerability could have allowed an attacker access to the victim’s private photos by building a malicious application and then tricking victims into installing the app.
At least, that could have been the case if Facebook wasn’t so good about fixing their vulnerabilities. [Laxman] disclosed his finding to Facebook. They had patched the vulnerability less than an hour after acknowledging the disclosure. They also found this vulnerability severe enough to warrant a $10,000 bounty payout to [Laxman]. This is in addition to the $12,500 [Laxman] received last month for a different Facebook photo-related vulnerability.
We all know what Computer-Generated Imagery (CGI) is nowadays. It’s almost impossible to get away from it in any television show or movie. It’s gotten so good, that sometimes it can be difficult to tell the difference between the real world and the computer generated world when they are mixed together on-screen. Of course, it wasn’t always like this. This 1982 clip from BBC’s Tomorrow’s World shows what the wonders of CGI were capable of in a simpler time.
In the earliest days of CGI, digital computers weren’t even really a thing. [John Whitney] was an American animator and is widely considered to be the father of computer animation. In the 1940’s, he and his brother [James] started to experiment with what they called “abstract animation”. They pieced together old analog computers and servos to make their own devices that were capable of controlling the motion of lights and lit objects. While this process may be a far cry from the CGI of today, it is still animation performed by a computer. One of [Whitney’s] best known works is the opening title sequence to [Alfred Hitchcock’s] 1958 film, Vertigo.
Later, in 1973, Westworld become the very first feature film to feature CGI. The film was a science fiction western-thriller about amusement park robots that become evil. The studio wanted footage of the robot’s “computer vision” but they would need an expert to get the job done right. They ultimately hired [John Whitney’s] son, [John Whitney Jr] to lead the project. The process first required color separating each frame of the 70mm film because [John Jr] did not have a color scanner. He then used a computer to digitally modify each image to create what we would now recognize as a “pixelated” effect. The computer processing took approximately eight hours for every ten seconds of footage. Continue reading “Retrotechtacular: The Early Days of CGI”
If you want to proclaim to the world that you’re a geek, one good way to go about it is to wear a wristwatch that displays the time in binary. [Jordan] designs embedded systems, and he figured that by building this watch he could not only build up his geek cred but also learn a thing or two about working with PIC microcontrollers for low power applications. It seems he was able to accomplish both of these goals.
The wristwatch runs off of a PIC18F24J11 microcontroller. This chip seemed ideal because it included a built in real-time clock and calendar source. It also included enough pins to drive the LEDs without the need of a shift register. The icing on the cake was a deep sleep mode that would decrease the overall power consumption.
The watch contains three sets of LEDs to display the information. Two green LEDs get toggled back and forth to indicate to the user whether the time or date is being displayed. When the time is being displayed, the green LED toggles on or off each second. The top row of red LEDs displays either the current hour or month. The bottom row of blue LEDs displays the minutes or the day of the month. The PCB silk screen has labels that help the user identify what each LED is for.
The unit is controlled via two push buttons. The three primary modes are time, date, and seconds. “Seconds” mode changes the bottom row of LEDs so they update to show how many seconds have passed in the current minute. [Jordan] went so far as to include a sort of animation in between modes. Whenever the mode is changed, the LED values shift in from the left. Small things like that really take this project a step further than most.
The board includes a header to make it easy to reprogram the PIC. [Jordan] seized an opportunity to make extra use out of this header. By placing the header at the top of the board, and an extra header at the bottom, he was able to use a ribbon cable as the watch band. The cable is not used in normal operation, but it adds that extra bit of geekiness to an already geeky project.
[Jordan] got such a big response from the Internet community about this project that he started selling them online. The only problem is he sold out immediately. Luckily for us, he released all of the source code and schematics on GitHub so we can make our own.
[Bayres’] dad setup a webcam as a surveillance camera for a remote property. The only problem was that the only stable Internet connection they could get at this property was DSL. This meant that the external IP address of the webcam would change somewhat often; the needed a way to keep track of the external IP address whenever it changed. That’s when [Bayres] built a solution using Arduino and an Ethernet shield.
The main function of this device is to monitor the public IP address and report any changes. This is accomplished by first making a request to checkip.dyndns.org. This website simply reports your current public IP address. [Bayres] uses an Arduino library called Textfinder in order to search through the returned string and identify the IP address.
From there, the program compares this current value to the previous one. If there is any change, the program uses the Sendmail() function to reach out to an SMTP server and send an e-mail alert to [Beyres’] dad. The system also includes a small LCD. The Arduino outputs the current IP address to this display, making it easy to check up on the connection. The LCD is driven by 74HC595 shift register in order to conserve pins on the Arduino.
The system is also designed with a pretty slick setup interface. When it is booted, the user can enter a configuration menu via a Serial terminal. This setup menu allows the user to configure options such as SMTP server, email address, etc. These variables are then edited and can be committed to EEPROM as a more permanent storage solution. Whenever the system is booted, these values are read back out of the EEPROM and returned to their appropriate variables. This means you can reconfigure the device on the fly without having to edit the source code and re-upload.
[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.