Firmware holds the good stuff: logic, bugs, and the occasional hard-coded secrets. In this case, the target device had firmware stored in NAND flash*A type of non-volatile memory, used everywhere (phones, flash drives, SSDs…)within aBGA-packaged MCP*Multiple chips (like NAND and RAM) packed together in one unit (Multi Chip Package), mounted to the PCB with tiny solder balls on the underside of the chip (Ball Grid Array). The chip wasn’t directly supported by my Flash programmer, so I had to improvise by: Flashromon an Arduino makes for a pretty cool Flash programmer. It’s exactly how I got started with Flash dumping. Recently though, My Arduino died, so I switched to the XGecu T48™. To put the T48 to the test, I started dumping firmware off whatever I had lying around: Old routers, BIOS chips… and everything dumped fine! Then, I tried dumping an old flip phone.Bad idea.It turns out, the chip is an unsupportedBGAMCPwhich didn’t fit any of my adapters :( Looking for an easy way to get the phone’s firmware, I checked the usual suspects: But no luck. Nobody seemed to care about this phone (and I don’t blame them). It’s pretty locked down and rocks a Mediatek SoC with a proprietary OS based onMAUI. With no firmware in sight, I switched gears and opened up the phone to inspect the motherboard. I couldn’t see the SoC or any kind of Flash chip but I figured it had to be hidden somewhere under the PCB shielding. Before removing the shielding, I looked at the motherboard again to check if I had missed any obviousdebug interface(JTAG,SWD,UART…). Some manufacturers are nice enough to leave them labeled and exposed as ports or test pads. In my case, labels were missing and I didn’t have datasheets, so I started to poke at random pads to try to find a hidden interface.Not that fun,especially when you know that the interface may not even be routed at all in the first place! Also, there’s no guarantee it’ll even talk back if you manage to find it, as it may be locked :P Anyway, after a bit of unsuccessful probing, I decided to take the PCB shielding off with flush cutters (rotary tool or hot air station works too). Once it was off, two chips were revealed. A quick google search of their markings confirmed they were the SoC and the MCP. Because I wasn’t really familiar with MCPs, I took a look at the datasheet and noticed that it heldboth the phone’s Flash and RAM in a single chip.Nice!The only problem is, it came in a BGA package… Chips come in a lot of different packages (DIP/SOP/BGA…). Here, The MCP came in a BGA package, meaning it has tiny solder balls on the bottom surface, instead of legs. If the chip has legs, it’susuallyeasily dumpable. A soldering iron or hot air station isn’t even needed. Simple clips or probes can be used instead. Here’s an example: The clip is great for chips with legs, but useless when it comes to BGAs which have tiny solder balls on the bottom. Because I couldn’t find any debug interface or software bugs to take advantage of, I decided to go chip-off here. Meaning I have to dump the chip by removing it with hot air and wiring it to a flash programmer. Dumping the chip is usually pretty straightforward if your flash programmer supports the chip and you know how to wire it (you have the datasheet right?) In my case, I easily found the chip’s datasheet online (W71NW11GC1DW) and after a quick read: Although the MCP isn’t directly supported by the T48, the NAND inside itW29N01GWis very similar to another NAND from the same vendor that’s already supported (W29N01HWSINA@TSOP48). Here’s a table comparing the two chips based on their datasheets: As you can see, I found a perfectly matching chip. While a perfect match is nice, It isn’t strictly required because NAND parameters can be adjusted in Xgecu’s software (Vcc, block and page size, ONFI bus width…). Things looked promising, but I still needed to figure out which balls to wire on the MCP. So I looked at the datasheet again and found the MCP’s ball configuration: Because I only care about the NAND, not the RAM, I only need to wire the red balls to the programmer. My NAND uses a 16-bit bus, meaning I have 25 balls to wire (including Vss and Vcc). If this NAND used an 8-bit bus, I’d only need to wire 17.