True Random Number Generator For A True Hacker

June 29, 2015 by Voja Antonic 103 Comments

How can you generate random bits? Some people think it’s not easy, others will tell you that it’s pretty damn hard, and then there are those who wonder if it is possible at all. Of course, it is easy to create a very long pseudorandom sequence in software, but even the best PRNG (Pseudorandom Number Generator) needs a good random seed, as we don’t want to get the same sequence each time we switch on the unit, do we? That’s why we need a TRNG (True Random Number Generator), but that requires special hardware.

Some high-end microprocessors are equipped with an internal hardware TRNG, but it is, unfortunately, not true for most low-cost microcontrollers. There are a couple of tricks hackers use to compensate. They usually start the internal free running counter and fetch its contents when some external event occurs (user presses a button, or so). This works, but not without disadvantages. First, there is the danger of “locking” those two events, as a timer period may be some derivative of input scan routine timing. Second, the free running time (between switching on and the moment the unit requests a random number) is often too short, resulting in the seed being too close to the sequence start, and thus predictable. In some cases even, there is no external input before the unit needs a random seed!

Despite what has already been discussed, microcontrollers do have a source of true randomness inside them. While it might not be good enough for crypto applications, it still generates high enough entropy for amusement games, simulations, art gadgets, etc.

Continue reading “True Random Number Generator For A True Hacker” →

Fail Of The Week: Re-addressing Your RAM DIMM

April 5, 2015 by Mike Szczys 14 Comments

It doesn’t work and we’re not surprised considering the can of worms that comes with RAM addressing. Right off the bat we assume timing problems due to variance in the trace lengths and EM issues. But you have to hand it to [cyandyedeyecandy] for even trying. The self-proclaimed upgrade seeks to readjust how the DIMM works without changing the edge pinout.

The stick shown here is a 512 MB module that, because of the computer using it (unspecified in the post), is only allowing access to 256 MB. The added chips and free-form circuit make up an AND for the chip-select line, and flip-flop for the bank address.

The post is a gorgeous cry for help. We already weighed in from the peanut gallery at the top (seriously, that’s somewhat baseless guessing) so step up to the computer-engineering plate and let us know what needs to be done to make this most-awesome-of-non-working hacks actually work.

Once you’ve figured this out, here’s another one to scratch at your brain with.

Reprogramming Super Mario World From Inside The Game

January 22, 2015 by Rick Osgood 72 Comments

[SethBling] recently set a world record speed run of the classic Super Nintendo game Super Mario World on the original SNES hardware. He managed to beat the game in five minutes and 59.6 seconds. How is this possible? He actually reprogrammed the game by moving specific objects to very specific places and then executing a glitch. This method of beating the game was originally discovered by Twitch user [Jeffw356] but it was performed on an emulator. [SethBling] was able to prove that this “credits warp” glitch works on the original hardware.

If you watch the video below, you’ll see [SethBling] visit one of the first available levels in the game. He then proceeds to move certain objects in the game to very specific places. What he’s doing here is manipulating the game’s X coordinate table for the sprites. By moving objects to specific places, he’s manipulating a section of the game’s memory to hold specific values and a specific order. It’s a meticulous process that likely took a lot of practice to get right.

Once the table was setup properly, [SethBling] needed a way to get the SNES to execute the X table as CPU instructions. In Super Mario World, there are special items that Mario can obtain that act as a power up. For example, the mushroom will make him grow in size. Each sprite in the game has a flag to tell the SNES that the item is able to act as a power up. Mario can either collect the power up by himself, or he can use his friendly dinosaur Yoshi to eat the power up, which will also apply the item’s effects to Mario.

The next part of the speed run involves something called the item swap glitch. In the game, Mario can collect coins himself, or Yoshi can also collect them by eating them. A glitch exists where Yoshi can start eating a coin, but Mario jumps off of Yoshi and collects the coin himself simultaneously. The result is that the game knows there is something inside of Yoshi’s mouth but it doesn’t know what. So he ends up holding an empty sprite with no properties. The game just knows that it’s whatever sprite is in sprite slot X.

Now comes the actual item swap. There is an enemy in the game called Chargin’ Chuck. This sprite happens to have the flag set as though it’s a power up. Normally this doesn’t matter because it also has a set flag to tell the game that it cannot be eaten by Yoshi. Also, Chuck is an enemy so it actually hurts Mario rather than act as a power up. So under normal circumstances, this sprite will never actually act as a power up. The developers never programmed the game to properly handle this scenario, because it was supposed to be impossible.

If the coin glitch is performed in a specific location within the level, a Chargin’ Chuck will spawn just after the coin is collected. When the Chuck spawns, it will take that empty sprite slot and suddenly the game believes that Yoshi is holding the Chuck in his mouth. This triggers the power up condition, which as we already know was never programmed into the game. The code ends up jumping to an area of memory that doesn’t contain normal game instructions.

The result of all of this manipulation and glitching is that all of the values in the sprite X coordinate table are executed as CPU instructions. [SethBling] setup this table to hold values that tell the game to jump to the end credits. The console executes them and does as commanded, and the game is over just a few minutes after it began. The video below shows the speed run but doesn’t get too far into the technical details, but you can read more about it here.

This isn’t the first time we’ve seen this type of hack. Speed runs have been performed on Pokemon with very similar techniques. Another hacker managed to program and execute a version of single player pong all from within Pokemon Blue. We can’t wait to see what these game hackers come up with next. Continue reading “Reprogramming Super Mario World From Inside The Game” →

Low-Level Computing With Entry-Level Difficulty: DUO Light

September 20, 2014 by Mike Szczys 27 Comments

The hardware can’t get much simpler. The DUO Light uses an ATmega328 (commonly found on Arduino boards) along with an external SRAM chip to provide a low-level computer programming experience that will suit those new to programming and some more experienced tinkerers.

At the time of writing the modest Kickstarter goal of $1100 was just $18 shy of success. We’d wager that this is partly due to the availability of so much support material on [Jack’s] website. (fyi- a lot of the links on that page are zip files)

The SD card slot accepts a FAT16 card with byte code for the programs. The available Psuedo C compiler, and assembler let you pick your poison, or you can simply dig into the byte code directly. We didn’t see a schematic, but the firmware and BOM are both available. You should be able to easily figure out connections from those.

We’ve been a fan of [Jack’s] work for quite some time. His TTL computer and 16-core ATmega-based offerings are sure to delight, even if you remember seeing them go by the first time. This isn’t his first stab at educational models either. Though we still found his logic chip computer a bit daunting.

Dual Port RAM Teaches An Old NES New Tricks

May 6, 2014 by Adam Fabio 11 Comments

nesDPR

[Andrew] is developing a game for the Nintendo Entertainment System (NES). Emulators are great for this, but [Andy] loves running on the real iron. To help, he’s created a dual port RAM interface for his NES. As the name implies, a dual port RAM is a memory with two separate data and address buses. The Cypress Semiconductor CY7C136 [Andy] used also includes arbitration logic to ensure that both ports don’t attempt to access the same memory cell and cause data corruption. In [Andy’s] case the NES was on one side, oblivious to the new hardware. On the other side of the dual port RAM, [Andy] installed an ATmega164 running his own custom firmware.

The new hardware gives [Andy] a live view of what’s going on in the NES’s memory. He added a live memory view/edit screen similar to the FCEUX emulator. The window runs on a PC while the game itself is running on an NES. [Andy] was even able to add rudimentary break and step features by connecting his circuit to the Non Maskable Interrupt (NMI) line of the NES. By holding the NMI asserted, the ATmega can essentially freeze the game in progress.

[Andy] has even used his circuit to teach the NES some new tricks. By reading the timer and score memory locations on Ice Hockey, he was able to create a scoreboard and goal light. Similar techniques were used to give Contra a muzzle flash light which puts Ambilight systems to shame.

We don’t know what [Andy] is planning next, but we hope it’s a source release so we can start hacking some some games ourselves!

Click past the break to see a couple of [Andy’s] Vine videos.

Continue reading “Dual Port RAM Teaches An Old NES New Tricks” →

The Mystery Of Zombie RAM

March 6, 2014 by Brian Benchoff 61 Comments

[Josh] had a little project where he needed to keep a variable in RAM while a microcontroller was disconnected from a power source. Yes, the EEPROM on board would be able to store a variable without power, but that means writing to the EEPROM a lot, killing the lifetime of the chip. He found an ATTiny can keep the RAM alive for a variable amount of time – somewhere between 150ms and 10 minutes. Wanting to understand this variability, he decided to solve the mystery of the zombie RAM.

The first experiment involved writing a little bit of code for an ATTiny4313 that looked for a value in RAM on power up and light up a LED if it saw the right value. The test circuit consisted of a simple switch connected to the power pin. Initial tests were astonishing; the ATTiny could hold a value in RAM for up to 10 minutes without power.

With the experiment a success, [Josh] updated his project to use this new EEPROM-saving technique. Only this time, it didn’t work. The value hidden away in RAM would die in a matter of milliseconds, not minutes. After tearing his hair out looking for something different, [Josh] rigged up an Arduino based test circuit with humidity and temperature sensors to see if that had any effect. It didn’t, and the zombie RAM was still not-undead.

The key insight into how the RAM in an ATtiny could stay alive for so long came when [Josh] noticed his test circuit had a LED, but the actual project didn’t. Apparently this LED was functioning as a very tiny solar cell, generating a tiny bit of current that kept the RAM alive. A dark room with a flashlight confirmed this hypothesis, and once [Josh] gets his uCurrent from Kickstarter he’ll know exactly how much current this LED is supplying.

Expanded Memory For The Teensy++ 2.0

February 17, 2014 by Brian Benchoff 3 Comments

RAM

Sometimes with a microcontroller project you need to do some very RAM-hungry operations, like image and audio processing. The largish AVR chips are certainly fast enough to do these tasks, but the RAM on these chips is limited. [xxxajk] has come up with a library that allows the use of huge RAM expansions with the Teensy++ 2.0 microcontroller, making these RAM-dependant tasks easy on one of our favorite microcontroller board.

[xxajk]’s work is actually a port of XMEM2, an earlier project of his that added RAM expansion and multitasking to the Arduino Mega. Up to 255 banks of memory are available and with the supported hardware, the Teensy can address up to 512kB of RAM.

XMEM2 also features a preemptive multitasking with up to 16 tasks, the ability to pipe messages between tasks, and all the fun of malloc().

The build is fairly hardware independent, able to work with Rugged Circuits QuadRAM and MegaRAM expansions for the Arduino Mega as well as [Andy Brown]’s 512 SRAM expansion. With the right SRAM chip, etching a board at home for XMEM2 is also a possibility.