Whilst some impressive hacks (and especially convincing university staff to lend you their Expensive Toys), my understanding is that the really tricky bit is going from die scans to netlist/circuit diagram, and thence simulation/code extraction.
The Visual6502[1] folks are probably the best example of how well it can be done (assuming you can't afford to pay ChipWorks or FlyLogic to do it for you), but if you're working with a standardish MCU core and some masked ROM, a lower tech solution like the Dangerous Prototypes "rompar"[2] might work.
Probably requires quite a few dies, or plenty of experience in extracting them before you succeed though.
For actually reverse engineering the flash contents, I think it'd be easier to sniff the bus traffic as you probe it, or make a read/write capable emulator that logs what's going on. With the hacked phone-side control library, you could probably build a mostly automated harness to exercise the various settings and see what gets stored in flash.
From the Wikipedia article: "Furbies were banned from the National Security Agency of the United States due to concerns that they may be used to record and repeat classified information."
It's projects like this that spark me to always go out and try to learn new things. I forget how much of our surrounded world is hackable sometimes, and it really is sad to think I get so caught up I don't think of these projects near as often as I used to. Hopefully this guy gets somewhere :) these writeups are inspiring, interesting, and educational all wrapped into one nice little package.
This class of devices is often made at a ridiculously huge volume and the cheapest way possible, so they're very likely to contain one-time-programmable devices with no test / debug lines.
Yet there are labeled(!) test points visible for the I2C lines on the board, and a number of other labels... so the question is, why doing the epoxy stuff while leaving the labeling on the PCB?
Epoxy blobs tend to be more about cheap mass-production than anti-reverse-engineering. If you're getting a custom chip manufactured, it's often easier to just stick the die straight on the board than it would be to have it put in a package, then put on the board.
Epoxy enhances reliability by keeping the chips hermetically sealed. So when your kid barfs on his favorite Furby it still has a chance of working, or gets thrown by the family dog against the wall.
They are fun to play with from a hardware poking perspective.
This article says that the Furby communicates in the same way. It would be interesting if the Furby was a vector for spreading messages via this virus. Very, very interesting.
I doubt this (Furbys are kiddy toys, after all); but this article proves that audio is indeed a viable data communication channel for bypassing air-gaps.
If anything, data over audio would be easier in an anechoic chamber since you don't have to worry about reverb or background noise.
US Military guidelines do require acoustic isolation of all SCIFs (Secure Compartmentalized Information Facilities). You just need isolation, though; deadening the rooms is not really necessary.
The Visual6502[1] folks are probably the best example of how well it can be done (assuming you can't afford to pay ChipWorks or FlyLogic to do it for you), but if you're working with a standardish MCU core and some masked ROM, a lower tech solution like the Dangerous Prototypes "rompar"[2] might work.
Probably requires quite a few dies, or plenty of experience in extracting them before you succeed though.
For actually reverse engineering the flash contents, I think it'd be easier to sniff the bus traffic as you probe it, or make a read/write capable emulator that logs what's going on. With the hacked phone-side control library, you could probably build a mostly automated harness to exercise the various settings and see what gets stored in flash.
[1] http://visual6502.org/
[2] http://adamsblog.aperturelabs.com/2013/01/fun-with-masked-ro...