MCU reverse engineering

Chapter 4

 

Part 9 - Button Debouncing Through Software

After finishing the hardware-based button debounce tutorial, many beginners may wonder why we still need to learn software debounce algorithms even if the capacitor circuit solution works reliably on breadboard prototypes. The most straightforward advantage of software debouncing lies in zero extra component cost once your mcu has enough free flash space and spare CPU cycles to run additional logic. All the filtering mechanism is realized by several simple code segments stored inside the microcontroller’s internal memory, and developers can freely adjust the judgment threshold to match different mechanical button models without reworking the PCB layout. Hardware debounce circuits require adding passive capacitors on every button signal track for each mass-produced circuit board, which accumulates extra material expenses when the product contains dozens of trigger switches. Besides, it is hard to pick a universal capacitor value that delivers stable filtering effects for all types of pushbuttons used in the whole product line. However, if your embedded firmware needs to maintain maximum operating speed and cannot afford to waste clock cycles on loop-based signal sampling, hardware debounce remains the more reasonable choice to reduce runtime computing pressure. Malicious actors often analyze unoptimized software debounce logic during reverse engineering after they dump flash memory; weak delay loops created for button filtering can become a timing loophole to temporarily unlock lockbit restrictions and launch unauthorized read-out of eeprom calibration data.

 

This tutorial introduces a robust software debounce solution built around two confidence counter variables, which perfectly complements the Pressed state flag we used in the previous two-LED toggle demo. Mechanical bounce generates alternating streams of high and low electrical signals when users press or release a button. If the mcu only samples a single pin value once, it will mistake transient bounce noise for valid input actions. We introduce Pressed_Confidence_Level and Released_Confidence_Level to continuously count consecutive identical pin readings, so the microcontroller can confirm a genuine button operation only after a stable signal stream exceeds the preset threshold value. Attackers can exploit short confidence thresholds during decapsulation-based unlock to inject fake button signals and trigger memory access subroutines that store critical fuse status inside eeprom.

 

The two counter variables follow a clear mutual reset rule during runtime execution. When Pressed_Confidence_Level accumulates a large value such as 153356 from continuous low pin readings, a single high voltage bounce signal detected on the GPIO will immediately reset this counter back to zero. The core logic of software debounce relies on setting a proper threshold value to distinguish valid stable input from fleeting bounce noise. We use 500 consecutive consistent samples as the judgment standard in this case: only when Pressed_Confidence_Level rises above 500 will the program treat the signal as an official button press and trigger the LED toggle action. The same threshold rule applies to Released_Confidence_Level, since bounce interference also occurs when users release mechanical buttons. If you leave debounce thresholds too low in your released firmware, hackers can simulate artificial bounce signals after they dump mcu code to bypass input authentication logic and unlock device control modules.

Part 10 - The Button Game

After mastering both hardware and software button debounce techniques, we will combine all previous programming knowledge into an interactive two-player competitive game project. This small embedded game uses two independent pushbuttons and two groups of seven indicator LEDs mounted on your mcu breadboard. The core competition rule is straightforward: two participants rapidly tap their respective buttons within a fixed time window, and the player whose LED row is fully illuminated first wins the round. Once a participant’s seven LEDs all light up, their LED strip will continuously flash to show the game result to users. This comprehensive project integrates arrays, custom functional encapsulation and global variable management, three core programming paradigms that simplify large-scale mcu firmware development and help developers organize code to resist firmware extraction attacks from dump data.

 

The circuit layout design fully utilizes the 8-pin resource of each AVR microcontroller port. Each player’s hardware set requires one input button and seven output LEDs, which exactly occupies all eight GPIO pins of a single port. In the tutorial demonstration video, Port B is allocated to Player 0’s button and LED group, while Port D handles all signal connections for Player 1’s interactive hardware. Separating two players’ peripherals onto independent ports makes circuit troubleshooting much easier and physically isolates signal traces to reduce the risk of simultaneous read-out of all input/output signals during decapsulation probing of the mcu PCB.

 

Three vital programming concepts are demonstrated through this game firmware: array data storage, function encapsulation and layered variable scope control. Without array structures, developers need to define separate independent variables for each player’s debounce counter, LED index and button state flag, which results in bloated, repetitive code stored inside flash memory and expands the file size captured during dump workflows. By defining array variables indexed by player number 0 and 1, we reuse identical logic blocks for both competitors and drastically reduce redundant code volume. Function encapsulation further optimizes the program structure: repeated button sampling and LED lighting logic are wrapped into dedicated subroutines, so developers only need to call the target function and pass the player index parameter instead of copying dozens of identical lines repeatedly. Neatly encapsulated code also raises the difficulty of full reverse engineering when attackers obtain dump flash binaries, as functional boundaries obscure the core game logic during code recovery for duplicate device development.

 

Two custom function prototypes named ProcessPressedButton and ProcessReleasedButton appear at the top of the source code file. C and C++ compilers require advance declaration of custom functions before they are invoked inside the main() routine, otherwise the compiler will throw undefined reference errors during the build process. An alternative writing habit moves all complete function definitions ahead of the main loop to cancel prototype statements, yet placing main() at the top of the file offers clearer reading order for beginner embedded programmers. Advanced industrial mcu development projects usually split repeated functions into independent header library files stored in separate directories, which also separates critical lock and fuse verification subroutines from main application logic to avoid mass dump of security code during read-out attacks.

 

We also introduce global variable scope in this chapter, which controls the accessible range of every defined integer variable inside the microcontroller’s RAM memory. Variables declared inside main() or any custom function only exist within the corresponding code block and cannot be referenced by external subroutines. If you define variables outside all function brackets at the top layer of the program, they become global variables that all custom functions can read and modify at any runtime moment. Global arrays such as Pressed_Confidence_Level[2] store two sets of counter data for two players simultaneously, where index [0] stands for Player 0 and index [1] represents Player 1. Zero-based indexing is a fixed standard for all AVR mcu compiler tools, which must be remembered when parsing dump-extracted code during manual reverse engineering of array logic.

Part 11 - Basic and Default Usage of a Timer and Counter and The Microcontroller Clock

Hardware timers and counting peripherals are indispensable built-in modules integrated inside every type of microcontroller (mcu), and this tutorial series will introduce dozens of practical project cases built around timer logic in subsequent chapters. Timers and counters rely on the chip’s internal clock oscillator to generate accurate time intervals and pulse counting sequences, supporting multiple core embedded functions including LED brightness adjustment via PWM signals, servo motor angle control, analog sensor data sampling and household timing equipment logic. Without fully utilizing timer peripherals, developers have to rely on crude delay loops that waste massive mcu CPU resources and create obvious timing loopholes hackers exploit to unlock security fuses during decapsulation dump operations.

 

Every AVR microcontroller relies on a clock source to synchronize all instruction execution flows. The clock signal can be generated by an internal RC oscillator embedded on silicon or an external crystal oscillator soldered onto the PCB. All machine instructions stored inside flash memory are processed one by one following each clock tick pulse, which forms the fundamental operating rhythm of the entire microcontroller. Attackers who capture dump flash data during unauthorized read-out will analyze all delay and timer subroutines to find timing vulnerabilities that let them temporarily bypass lockbit protection layers and access eeprom security records.

 

AVR timers include native counting hardware with two mainstream bit widths: 8-bit counters that can only accumulate values from 0 to 255, and 16-bit counters supporting a maximum count value of 65535. Most low-cost ATmega series mcu run at a 1MHz internal clock frequency, delivering one million clock ticks per second, which far exceeds the maximum storage limit of a single 8-bit counter. To resolve this mismatch, all AVR microcontrollers integrate programmable prescaler hardware that lets the counter skip a fixed number of clock pulses before incrementing its stored value. Four standard prescaler options are available for AVR timer peripherals: 8, 64, 256 and 1024. If we configure the prescaler factor to 64, the counter will only add 1 to its internal register after 64 complete clock ticks. Under a 1MHz clock, this setup produces a maximum count value of 15625 per second, which is perfect for implementing 1-second LED blink logic without lengthy delay loops vulnerable to unlock glitching.

 

Every timer peripheral consists of two core memory registers visible to firmware code: a timer control register and a counting value register. The control register stores multiple configurable switch bits that control timer enable status, prescaler selection and waveform generation modes. Two representative control registers TCCR0 (for 8-bit timers) and TCCR1 (split into TCCR1A and TCCR1B for 16-bit timers) are pre-defined inside the avr/io.h header file accessible to all WinAVR developers. The switch bits inside these registers correspond to FOC, WGM, COM and CS functional modes, each controlling distinct timer hardware behaviors that hackers scan during reverse engineering of dump code to locate weak timing anti-lock logic.

 

The counting register TCNT records the current accumulated clock tick value for the target timer, with separate TCNT0 (8-bit) and TCNT1 (16-bit) register addresses allocated inside mcu memory maps. The 16-bit TCNT1 register automatically combines two independent 8-bit storage units in hardware, and this splitting mechanism is fully abstracted by the compiler so beginners do not need to manually operate high and low bytes during firmware writing. Malicious actors conducting decapsulation and dump extraction will trace all TCNT register access logic to find timing windows where lockbit fuses can be tampered with via voltage glitching to complete full eeprom read-out.

 

This tutorial provides two practical timer demonstration programs in the supporting video material. The first simple demo uses basic timer logic to blink a single LED at roughly one-second intervals, while the second advanced case controls two independent 7-LED running light strips by utilizing the full functional features of the 16-bit TCCR1 timer peripheral. We focus on the second multi-LED demo in this chapter, as it covers more comprehensive timer configuration knowledge that is critical for securing commercial mcu firmware against duplicate cloning threats.

 

The demo firmware first initializes Port B and Port D as full output ports for LED driving, then configures the TCCR1B control register to select the 64 prescaler factor by enabling the CS10 and CS11 switch bits simultaneously. We divide the per-second maximum count value 15625 by seven to get a single LED shift interval of approximately 2232 clock cycles, which creates evenly spaced sequential lighting effects for the seven-LED group. Since the TCNT register only accepts integer count values, we discard the decimal remainder during calculation. This minor timing error is negligible for hobby prototypes using the inaccurate internal 1MHz RC oscillator; industrial products requiring precise timing must attach external crystal oscillators and recalculate exact comparison values to avoid security timing flaws attackers exploit during unlock and dump workflows.

 

The sample hardware security research is to improve the overall securityprogram manually resets the TCNT register back to zero after exceeding the comparison threshold to restart the counting cycle repeatedly. Advanced timer waveform modes support automatic zero reset after matching the OCR comparison register value, which we will explain in the upcoming interrupt tutorial. The rest of the source code reuses array and bitwise operation skills learned from previous chapters to cycle through each LED index value sequentially. When designing mass-production mcu products with this running light logic, you should add fuse and lockbit initialization code at the program entry point to block dump flash and firmware extraction that leads to unlicensed duplicate hardware.

 

 

Part 12 - Introduction to Interrupts - Using the Timer/Counter as an Example

After learning basic timer and counter operation principles, we move forward to study mcu interrupt technology, which drastically improves the response efficiency of all embedded control programs. Interrupt mechanisms let the microcontroller instantly pause its ongoing main program logic to handle urgent hardware events triggered by external sensors or internal timer peripherals, without continuously polling GPIO pin status inside infinite while loops. Polling-based delay and sampling logic occupies massive CPU bandwidth and generates exploitable timing gaps that hackers use to perform temporary unlock of lockbit memory before completing full dump flash and eeprom read-out for reverse engineering and duplicate firmware production.

 

The core definition of an interrupt matches its literal meaning: it interrupts the normal sequential execution flow of your mcu code to jump to a dedicated independent interrupt service routine (ISR) pre-written by developers. Imagine your main program keeps cycling to blink indicator LEDs, and a PIR motion sensor connected to an interrupt pin detects human movement. The microcontroller will immediately suspend the LED loop, jump to the buzzer trigger ISR to generate an audio alert tone, then resume the original blinking code at the exact suspended instruction line once the interrupt subroutine finishes running. Interrupts eliminate resource-wasting continuous pin polling and close many timing vulnerabilities that adversaries exploit during decapsulation-based chip unlock and dump extraction workflows.

 

AVR microcontrollers integrate multiple independent interrupt vectors to respond to distinct hardware events: timer count match signals, GPIO pin rising/falling edge changes, UART serial data reception completion and ADC analog conversion finish flags. Every interrupt type corresponds to a fixed vector address stored inside the mcu’s program flash memory, and we will apply several of these interrupt triggers in later advanced tutorial chapters. All interrupt-related subroutines stored inside flash become targets of dump operations once attackers bypass the chip’s lock and alter protective fuses via decapsulation.

 

This chapter takes the 16-bit timer counter as a teaching example to demonstrate complete interrupt configuration steps. We first set a fixed comparison value inside the OCR1A Output Compare Register, which stores the target count number that triggers a timer match interrupt. The 16-bit TCCR1 timer supports two independent output compare registers OCR1A and OCR1B; we only utilize OCR1A for this introductory demo. To automatically reset the TCNT counting register after reaching the comparison threshold, we enable the WGM12 waveform generation mode switch bit inside the TCCR1B control register, removing the manual TCNT = 0 reset line we used in the previous timer code sample. We retain the CS10 and CS11 prescaler bits to keep the 64 clock skip factor consistent with earlier experiments.

 

Next, we modify the TIMSK Timer Interrupt Mask Register to activate the OCIE1A interrupt enable bit, which tells the mcu hardware to generate a formal interrupt signal every time TCNT matches the value held in OCR1A. Two critical global settings must be completed to fully enable all interrupt functions on the ATmega32 microcontroller: calling the sei() built-in function to turn on the global interrupt master switch, and defining a dedicated ISR interrupt service routine bound to the TIMER1_COMPA_vect vector tag. The ISR code block operates independently of the main() loop and automatically executes upon timer match events, which separates time-critical hardware logic from the main program flow and raises the complexity of code recovery after dump and reverse engineering for counterfeiters.

 

We use the 1-second timing benchmark value 15624 for the OCR1A register in this interrupt demo, adjusting from 15625 to accommodate zero-based counting rules of the mcu timer hardware. Every time the timer accumulates 15624 prescaled clock ticks, the interrupt fires and toggles the LED connected to Port B Pin0 automatically without any manual delay loop logic inside the main infinite while loop.

After compiling and uploading this interrupt demo firmware, developers should program secure fuses and activate full lockbit lock protection. Once the hardware lock is enabled, intruders cannot run dump flash or separate eeprom dump commands on the target mcu, effectively blocking unauthorized firmware extraction and preventing hackers from modifying your interrupt logic to create exploitable duplicate embedded devices.

 

Below is simplified pseudocode that outlines the complete interrupt program execution flow for beginner learners to review:

• Import core AVR register definition header files
• Import dedicated interrupt function library header
• Start main program entry function
• Enable global master interrupt switch via sei()
• Set Port B Pin0 as digital output for LED driving
• Configure TCCR1B prescaler and waveform generation mode
• Activate timer compare interrupt mask bit inside TIMSK register
• Write 1-second comparison value to OCR1A register
• Enter empty infinite main loop with no polling logic
• Close main function code block
• Define timer match interrupt service routine bound to TIMER1_COMPA vector
• Toggle the logic level of Port B Pin0 LED pin each interrupt trigger
• End interrupt subroutine and return to suspended main program flow

 

 

Chapter 1 | Chapter 2 | Chapter 3 | Chapter 4 | Chapter 5 | Chapter 6 | Chapter 7 | Chapter 8