simavr is a software simulator for the AVR line of microcontrollers. You might be asking why anyone would write this sort of thing considering the simulator provided with AVR Studio is a wonderful tool? Well, a lot of folks don’t run Windows and don’t wish to use that development environment even if Wine or Virtualbox could make it happen.
We haven’t tried it out ourselves yet. There is a discussion thread going that reports some positive results of using simavr with GDB and AVR Eclipse. It’s a new package, but so far it seems to have put its best foot forward. Currently there is support for ATtiny25/45/85, ATtiny13, ATmega48/88/168, andATmega164/324/644 chips. Several of the common on-chip peripherals are already supported with the others on the way.
Have you tried it out? Let us know what you think in the comments.
Have you always wished that you could develop games for the Super Nintendo but couldn’t because you were only 4 years old when it was released in 1990? Here’s a second chance. [Max] and his team have created a SNES developer’s cartridge that allows you to load your own code, run it on the SNES, and debug as needed. At its core is an Atmel AVR ATmega644 that is running a boot loader, allowing for firmware updates via USB. Once the system is powered on, ROM code is sent over USB to the 16 megabits of onboard SRAM. A debug terminal can be connected with an RS232 converter, providing status information and allowing some register manipulation.
We can believe there are a few hardcore SNES fans out there who will take the time to write custom code. We could also see this being used for the purposes of SNES sythesized music. But is there a wide demand for this type of hardware? If you’ve ever looked into developing for the SNES, let us know in the comments.
Our own [Anthony Lineberry] has written up his experience participating in the 2008 Malware Challenge as part of his work for Flexilis. The contest involved taking a piece of provided malware, doing a thorough analysis of its behavior, and reporting the results. This wasn’t just to test the chops of the researchers, but also to demonstrate to network/system administrators how they could get into malware analysis themselves.
[Anthony] gives a good overview of how he created his entry (a more detailed PDF is here). First, he unpacked the malware using Ollydbg. Packers are used to obfuscate the actual malware code so that it’s harder for antivirus to pick it up. After taking a good look at the assembly, he executed the code. He used Wireshark to monitor the network traffic and determine what URL the malware was trying to reach. He changed the hostname to point at an IRC server he controlled. Eventually he would be able to issue botnet control commands directly to the malware. We look forward to seeing what next year’s contest will bring.
UPDATE: New firmware with JTAG and more
We’re always excited to get a new chip or SIM card to interface, but our enthusiasm is often dampened by the prototyping process. Interfacing any chip usually means breadboarding a circuit, writing code, and hauling out the programmer; maybe even a prototyping PCB.
A few years ago we built the first ‘Bus Pirate’, a universal bus interface that talks to most chips from a PC serial terminal. Several standard serial protocols are supported at 3.3-5volts, including I2C, SPI, and asynchronous serial. Additional ‘raw’ 2- and 3- wire libraries can interface almost any proprietary serial protocols. Since this has been such a useful tool for us, we cleaned up the code, documented the design, and released it here with specs, schematic, and source code.
Continue reading “How-to: The Bus Pirate, universal serial interface”
[Barry] needed some way to get serial output to help debug his efforts to port Linux to the HTC TytnII (Windows mobile Pocket PC phone). He wrote some code to send serial output via one of the LEDs on the phone and rigged up an AVR to pic up the output and provide a USB interface to the computer. It runs at about 200bps – perfect for the quick debug session.