Reprogramming toy-drone flight controllers which are based on readily recognizable microcontrollers is definitely "a thing", heavily benefiting from a few open source projects, one of the most popular being "Silverware" which has now become a whole family of repositories on github and years-long history of threads in places like rcgroups.

While in theory this could be done for the E-flight/Blade flight controllers (there exist open source firmwares for ATmega processors less powerful than the related XMega E-flight uses), in practice they tend not to be targets, because they are fairly expensive and relatively usable in stock configuration. Rather, efforts concentrate on the very low-end ultra-micros, where a flight controller or whole aircraft tends to cost $8-25, as that minimizes risk, and maximizes the reward in getting serious capabilities out of a "cheap toy". So you see a lot more of this going on with the inductrix-like "tinywhoop" platforms, than with the actual Induxtrix. The low price also typically means someone pioneering a new port of an open source control software can keep one board with stock firmware for reference while iterating experimental code on another.

Sometimes the target is simply the toy's flight controller board and not its airframe at all, eg, people having taken FC's intended to drive brushed pager motors, and after replacing the firmware wired them to the control signals of brushless ESC's on slightly larger aircraft, though typically still in the micro class.

Some of the key facts and techniques that make this possible include:

• Weight and budget concerns prompt almost universal use of 2-layer circuit boards which are easy to visually trace under moderate magnification.

• The past and not entirely extinct tendency to use readily recognized and reprogrammable microcontrollers, especially the STM32 series and its work-alikes from GigaDevices. These have a 2-wire "SWD" programming interface which can typically be found on pads on a board, and even where not, with care it's possible to solder fine wires even to the side metalizations of a QFN package. It also doesn't hurt that some of the STM32's turn out to actually have twice as much flash memory as they are supposed to. Or that in most cases one of the SWD pins can be re-purposed as a serial UART, allowing experimental code to create debug output (channelling debug messages through SWD is also an option). Some of these MCUs also have flash security bugs which permit the original firmware to be backed up and restored; but decompilation is not really of any interest or benefit. That said, MCU's unkown in the west are starting to show up in toys, and especially where they integrate the radio this does limit reverse engineering and firmware replacement.

• $10 logic analyzers based on the CY7C68013A chip are excellent tools for examining SPI or I2C communication between a processor and a yet-unidentified radio or sensor chip. I2C busses in particular are readily recognized by the pair of surface mount pull-up resistors, which make a great place to solder debug leads.

• 2.4 GHz radio chips are limited in number and mostly known by the community. There are a few unique designs (eg, the Cypress stuff DSM uses) and the A7105 and then a lot of various clones and semi-compatibles of the nRF24L01+, of which the "backwards bit order" XN297 is probably the most famous. These can typically be visually recognized, and there's already widespread knowledge of how to operate them from a replacement firmware. While entirely possible by studying logic analyzer captures, often it's not necessary (or even desirable) to re-implement the toy's original air protocol, but rather preferable to implement one supported by the modifier's available hobby-grade transmitter - not infrequently, being able to use a hobby TX is a main point of putting a custom firmware on it.

• MEMS Gryo/Accelerometer chips are also limited in number. While toys tend to feature chips with markings which which "don't exist" in the public catalog of the well-known makers, in practice examination of I2C bus traces tends to indicate that they are minor variations of parts with public data sheets. Worst case, a re-implementor just sends the same setup sequences, and then performs the same repeating data query. Tilting and twisting the drone with the logic analyzer hooked up and watching the live data display readily distinguishes which bitfields of the response encode which motion parameter. PID tuning tends to be manually iterative, so there's no real need to put any actual "numbers" on the anything, just to distinguish the three acceleration and rotation axis and their format and sign.

• Motor drivers are dead simple - FETs are readily recognized (and sometimes replaced with higher-spec versions). A few drones with inverted flight capability have more complex H-bridge drive, but again this is not hard to figure out. One cheap tiny platform had an odd set of connections running from the switched motor lead through a resistive divder to MCU ADC pins; it turned out that these were back-EMF monitors to detect spinning vs. blocked propellers during the PWM off time.