I am following this Baremetal Programming Series (Low Byte Productions Channel), inorder to learn about ARM microcontrollers, writing drivers (I've a goal to write a driver for a Serial Communication Protocol maybe CAN or Q-SPI, etc.) and learning some C constructs as well which I will then emulate in Renode.

Some notes,

• MACROS{.verbatim} are instructions that asks the C preprocessor to do text replacements.

• Behind the Scenes of libopencm3{.verbatim}

  • The memory mapped address of a pin is calculated in the pre-processing stage itself using macros.

• SYS_TICK{.verbatim} is like a Wall Clock.

• weak functions{.verbatim} are functions whose implementation can be redefined.

For Renode implementation, I just loaded the ELF of program used in the episode as like for the Hello World, Intro to Renode from Interrupt and I did used the same Makefiles and Linker scripts once again. (Those 2 seems to be a huge mess ? Is it ?)

I shouldn't be lazy enough to tinker them in future.

Then Looked the state of Pin A5 (External LED) and I could see that the state toggles. I think I could even log the data or check this working using Robot Framework.

Next, I need to look at Renode docs to discover more functionalities and then continue with Episode 3 on PWM and Timers!

The Secure Boot Case Study

Attackers can break through the Secure Boot process on millions of computers using Intel and ARM processors due to a leaked cryptographic key that many manufacturers used during the startup process. This key, called the Platform Key (PK), is meant to verify the authenticity of a device’s firmware and boot software.

Unfortunately, this key was leaked back in 2018. It seems that some manufacturers used this key in their devices instead of replacing it with a secure one, as was intended. As a result, millions of devices from brands like Lenovo, HP, Asus, and SuperMicro are vulnerable to attacks.

If an attacker has access to this leaked key, they can easily bypass Secure Boot, allowing them to install malicious software that can take control of the device. To fix this problem, manufacturers need to replace the compromised key and update the firmware on affected devices. Some have already started doing this, but it might take time for all devices to be updated, especially those in critical systems.

The problem is serious because the leaked key is like a master key that can unlock many devices. This issue highlights poor cryptographic key management practices, which have been a problem for many years.

What Are “Not Replaced Constants”?

In software, constants are values that are not meant to change during the execution of a program. They are often used to define configuration settings, cryptographic keys, and other critical values.

When these constants are hard-coded into a system and not updated or replaced when necessary, they become a code smell known as “Not Replaced Constants.”

Why Are They a Problem?

When constants are not replaced or updated:

1. Security Risks: Outdated or exposed constants, such as cryptographic keys, can become security vulnerabilities. If these constants are publicly leaked or discovered by attackers, they can be exploited to gain unauthorized access or control over a system.
2. Maintainability Issues: Hard-coded constants can make a codebase less maintainable. Changes to these values require code modifications, which can be error-prone and time-consuming.
3. Flexibility Limitations: Systems with hard-coded constants lack flexibility, making it difficult to adapt to new requirements or configurations without altering the source code.

The Secure Boot Case Study

The recent Secure Boot vulnerability is a perfect example of the dangers posed by “Not Replaced Constants.” Here’s a breakdown of what happened:

The Vulnerability

Researchers discovered that a cryptographic key used in the Secure Boot process of millions of devices was leaked publicly. This key, known as the Platform Key (PK), serves as the root of trust during the Secure Boot process, verifying the authenticity of a device’s firmware and boot software.

What Went Wrong

The leaked PK was originally intended as a test key by American Megatrends International (AMI). However, it was not replaced by some manufacturers when producing devices for the market. As a result, the same compromised key was used across millions of devices, leaving them vulnerable to attacks.

The Consequences

Attackers with access to the leaked key can bypass Secure Boot protections, allowing them to install persistent malware and gain control over affected devices. This vulnerability highlights the critical importance of replacing test keys and securely managing cryptographic constants.

Sample Code:

Wrong

def generate_pk() -> str:
    return "DO NOT TRUST"

# Vendor forgets to replace PK
def use_default_pk() -> str:
    pk = generate_pk()
    return pk  # "DO NOT TRUST" PK used in production

Right

def generate_pk() -> str:
    # The documentation tells vendors to replace this value
    return "DO NOT TRUST"

def use_default_pk() -> str:
    pk = generate_pk()

    if pk == "DO NOT TRUST":
        raise ValueError("Error: PK must be replaced before use.")

    return pk  # Valid PK used in production

Ignoring important security steps, like changing default keys, can create big security holes. This ongoing problem shows how important it is to follow security procedures carefully. Instead of just relying on written instructions, make sure to test everything thoroughly to ensure it works as expected.

Creating a simple alarm clock application can be a fun project to develop programming skills. Here are the steps, input ideas, and additional features you might consider when building your alarm clock

Game Steps

1. Define the Requirements:
   • Determine the basic functionality your alarm clock should have (e.g., set alarm, snooze, dismiss).
2. Choose a Programming Language:
   • Select a language you are comfortable with, such as Python, JavaScript, or Java.
3. Design the User Interface:
   • Decide if you want a graphical user interface (GUI) or a command-line interface (CLI).
4. Implement Core Features:
   • Set Alarm: Allow users to set an alarm for a specific time.
   • Trigger Alarm: Play a sound or display a message when the alarm time is reached.
   • Snooze Functionality: Enable users to snooze the alarm for a set period.
   • Dismiss Alarm: Allow users to turn off the alarm once it’s triggered.
5. Test the Alarm Clock:
   • Ensure that all functions work as expected and fix any bugs.
6. Refine and Enhance:
   • Improve the interface and add additional features based on user feedback.

Input Ideas

• Set Alarm Time:
  • Input format: “HHAM/PM” or 24-hour format “HH”.
• Snooze Duration:
  • Allow users to input a snooze time in minutes.
• Alarm Sound:
  • Let users choose from a list of available alarm sounds.
• Repeat Alarm:
  • Options for repeating alarms (e.g., daily, weekdays, weekends).
• Custom Alarm Message:
  • Input a custom message to display when the alarm goes off.

Additional Features

• Multiple Alarms:
  • Allow users to set multiple alarms for different times and days.
• Customizable Alarm Sounds:
  • Let users upload their own alarm sounds.
• Volume Control:
  • Add an option to control the alarm sound volume.
• Alarm Labels:
  • Enable users to label their alarms (e.g., “Wake Up,” “Meeting Reminder”).
• Weather and Time Display:
  • Show current weather information and time on the main screen.
• Recurring Alarms:
  • Allow users to set recurring alarms on specific days.
• Dark Mode:
  • Implement a dark mode for the UI.
• Integration with Calendars:
  • Sync alarms with calendar events or reminders.
• Voice Control:
  • Add support for voice commands to set, snooze, or dismiss alarms.
• Smart Alarm:
  • Implement a smart alarm feature that wakes the user at an optimal time based on their sleep cycle (e.g., using a sleep tracking app).