UDS Bootloader: The Backbone of Secure ECU

Software Updates

As Software-Defined Vehicles (SDVs) continue to evolve, firmware updates have become critical for
feature enhancements, cybersecurity patches, and bug fixes. But how do we ensure that ECUs
receive updates securely and reliably without bricking the system?
Introducing the UDS Bootloader—a robust mechanism enabling safe, authenticated, and fail-safe
ECU firmware flashing.
Let’s explore in detail:
✅ Bootloader Architecture
✅ UDS-based Firmware Update Flow
 ✅ Security & Cyber Threat Mitigation

✅ Fail-safe Recovery Strategies

✅ Best Practices for Automotive Firmware Updates.

1. What is a Bootloader?
A bootloader is the first software executed when an ECU powers on.
It is responsible for:
✅ System Initialization –
Setting up hardware (CAN, Ethernet, UART) and configuring peripherals.
✅ Firmware Validation –
Checking if the installed software is intact.
✅ Firmware Update Handling –
Managing software updates via UDS protocol.
Here’s a flowchart showing the Bootloader Execution Process:
Bootloader Process Flowchart – Detailed Explanation
A bootloader is the first piece of software executed when an ECU (Electronic Control Unit) starts up.
It plays a crucial role in initializing the system, verifying firmware integrity, and handling updates.
Below is a step-by-step breakdown of the Bootloader Process Flowchart:
1️⃣ Power-On Event:
When the ECU receives power (via ignition ON or a wake-up event), the system initiates the boot
sequence.
✅ Voltage Regulation Check: Ensures stable power supply before execution.
✅ Watchdog Timer Activation: Prevents software hang-ups by resetting the ECU if needed.

✅ Clock and Peripherals Initialization: Configures CAN, Ethernet, UART, and flash memory
access.
Next Step: The bootloader starts executing from the predefined memory location.
2️⃣ Bootloader Initialization:
Once powered on, the bootloader performs system initialization, preparing the ECU for either a
normal boot or a firmware update.
✅ Memory Mapping: Configures RAM, Flash, and external storage.

2
 ✅ Peripherals Setup: Initializes communication interfaces (CAN, LIN, Ethernet, UART).

✅ Secure Boot Mechanism: If implemented, verifies the bootloader’s authenticity.

Next Step: Firmware Validation Check.
3️⃣ Firmware Validation Check:
At this stage, the bootloader verifies whether the currently installed firmware is valid before allowing
execution.
Validation Methods:
✅ Checksum Verification (CRC, MD5, SHA-256): Ensures firmware integrity.

✅ Digital Signature Authentication: Confirms firmware authenticity to prevent hacking.

✅ A/B Partition Check: Determines which firmware partition is functional in case of a failed
update.
Decision Flow:
✅ If Firmware is Valid: Jump to the user application.

❌ If Firmware is Corrupted or Unauthorized: Execute the contingency plan.

Next Step: Firmware Update Handling (If Needed)
4️⃣ Firmware Update Handling Logic
If a new firmware update request is detected, the bootloader initiates the update process using the
UDS (Unified Diagnostic Services) protocol.
Process Flow:
1️⃣ Detect Update Request: ECU receives a firmware update trigger via CAN, Ethernet, or
OTA.
2️⃣ Request Firmware Blocks: Bootloader communicates with the update source.
3️⃣ Validate Each Block: Each firmware block is checked before writing.

4️⃣ Flash Firmware into Memory: Securely stores the new firmware.

5️⃣ Final Integrity Check: Ensures update success before rebooting.

Decision Flow:
✅ If Update is Successful: Jump to the new application.

❌ If Update Fails: Execute the contingency plan.

Final Step: Jump to User Application or Trigger a Safe Recovery Process.

3
2. Bootloader Architecture:
A modern automotive bootloader consists of three main parts:
• Primary Bootloader (ROM)
Embedded by the chip manufacturer. Performs basic hardware checks and loads the
secondary bootloader.
• Secondary Bootloader (Flash)
Manages firmware validation and updates. Implements UDS communication and security
mechanisms.
• User Application (Flash)
Contains the main ECU software (Partition A & Partition B). Supports failover mechanisms if
an update fails.
Bootloader Architecture in Automotive ECUs:
The bootloader architecture in an automotive ECU (Electronic Control Unit) is designed to ensure
secure and reliable firmware execution and updates. It consists of multiple components,
The bootloader architecture follows a layered approach, ensuring:
✔️ Secure Boot Process – Only verified firmware is executed.

✔️ Reliable Firmware Updates – Using UDS (ISO 14229-1) for diagnostics and updates.

✔️ Fail-Safe Mechanisms – Ensuring rollback in case of a failed update.

Below is a detailed breakdown of the architecture and its functions.
1. Primary Bootloader (ROM)
2. Secondary Bootloader (Flash)
3. User Application (Partition A / Partition B)
Let’s go into the details of each!
Primary Bootloader (ROM):
✅ Location: Embedded in Read-Only Memory (ROM) (Cannot be modified).

✅ Purpose: Responsible for the first-stage boot process and loading the secondary
bootloader.
Key Functions of the Primary Bootloader-
✔️ Initial Power-On Execution – This is the first piece of code that runs after an ECU reset.

4
 ✔️ Hardware Initialization – Configures clock settings, watchdog timers, and memory
mappings.
✔️ Secure Boot Verification – Validates the secondary bootloader before execution.
✔️ Failsafe Execution Path – Ensures the ECU always has a trusted bootloader that cannot
be erased.
Next Step: If the secondary bootloader is valid, control is transferred to it.
Secondary Bootloader (Flash):
✅ Location: Stored in the Flash Memory of the ECU.

✅ Purpose: Manages firmware updates, application verification, and execution switching.

Key Functions of the Secondary Bootloader-
✔️ Firmware Validation: Checks for valid user application firmware (using CRC, SHA-256, or
Digital Signatures).If the firmware is corrupt or unauthorized, it prevents execution.
✔️ Firmware Update Handling: Receives updates via CAN, Ethernet, USB, SD card, or OTA
(Over-the-Air). Implements UDS (ISO 14229-1) and XCP protocols for firmware flashing.
Supports A/B partitioning for fail-safe updates.
✔️ Contingency Plan Execution: If an update fails, it rolls back to the previous firmware (if
partitioning is used). Logs errors and prevents ECU bricking.
Next Step: If firmware validation passes, the secondary bootloader loads the user application.
User Application (Partition A / Partition B):
✅ Location: Stored in separate flash partitions (A and B) to ensure fail-safe updates.

✅ Purpose: Contains the actual ECU firmware that runs vehicle functions.
Partitioning Mechanism (A/B Switch)-
To ensure a fail-safe firmware update, automotive ECUs often use two application partitions:
• Partition A - (Active firmware)
• Partition B - (Inactive firmware, used for updates)
A/B Partitioning Workflow
1. The bootloader boots from Partition A (current valid firmware).
2. If a firmware update is triggered, it is written to Partition B.
3. After the update, the bootloader validates Partition B:
4. If successful, the bootloader switches execution to Partition B.

5
 5. If unsuccessful, it continues using Partition A (rollback).
6. In the next update cycle, Partition A is used for new firmware.
This mechanism prevents bricking by ensuring that at least one valid firmware copy is always
available.
Next Step: Once the user application starts, the bootloader exits, and the ECU runs its normal
software.

6
3. UDS-Based Firmware Update Process:
The UDS Bootloader follows a step-by-step process for safe ECU firmware updates:
Step 1: Bootloader Activation
• ECU powers on, and the bootloader starts executing.
• It determines whether an update is required.
Step 2: Firmware Validation
• The bootloader checks if the existing firmware is authentic (checksum/digital signature).
• If valid → Jumps to the user application.
• If invalid → Triggers the contingency plan.
Step 3: Secure Firmware Update
• Receives firmware block-by-block using UDS protocol.
• Each block is validated before writing into flash memory.
• The entire update undergoes a final integrity check before rebooting.
UDS Firmware Update Flowchart :
In modern automotive ECUs, firmware updates are managed using the Unified Diagnostic Services
(UDS) protocol (ISO 14229-1). The UDS firmware update process ensures that updates are secure,
reliable, and fail-safe, using mechanisms like block-wise data transfer, integrity validation, and
rollback strategies.
Key Stages of UDS Firmware Update-
A UDS firmware update follows three major phases:
1. Update Request Detection
2. Firmware Block Transfer via UDS (ISO 14229-1)
3. Validation & Final Flashing Process
Let’s go through each step in detail.
Update Request Detection:
✅ Purpose: Detect when an external tool (e.g., OEM software, dealer tool, or OTA system)
requests a firmware update.
How the Update Request is Received-
Diagnostic Tester (DTC) or OEM Server sends an update request via CAN, Ethernet, or DoIP
(Diagnostics over IP). The ECU must enter programming mode before receiving a new firmware.

7
Key UDS Services Used in Update Request-
✔️ 0x10 – Diagnostic Session Control - Switches the ECU to Programming Mode.

✔️ 0x27 – Security Access - Authenticates the diagnostic tool to prevent unauthorized

updates.
✔️ 0x34 – Request Download - Informs the ECU that a new firmware update is about to be
transferred.
Next Step: If authentication is successful, the ECU prepares for data transfer.
Firmware Block Transfer via UDS (ISO 14229-1):
✅ Purpose: Transfer the firmware to the ECU block by block and ensure it is stored correctly
in memory.
UDS Services Used for Block Transfer
✔️ 0x36 – Transfer Data
The firmware is sent in multiple blocks (each with a CRC check for data integrity).
✔️ 0x37 – Request Transfer Exit
Signals the end of the firmware transfer process.
Key Steps in Firmware Block Transfer-
1. Start Firmware Download: The ECU signals readiness.
2. Block-by-Block Data Transmission: The update tool sends firmware data blocks. Each
block is verified with CRC (Cyclic Redundancy Check) before writing.
3. Error Handling & Retransmission: If a block fails validation, a retransmission request is
triggered.
4. Transfer Completion: The tool sends a final completion signal to confirm all data is sent.
Next Step: Once all blocks are received, final validation and flashing begin.
Validation & Final Flashing Process:
✅ Purpose: Ensure the received firmware is valid, secure, and correctly stored before
execution.
Key UDS Services Used for Final Validation-
✔️ 0x31 – Routine Control
Used to trigger checksum verification or digital signature validation.
✔️ 0x11 – ECU Reset

8
 After a successful update, the ECU is restarted to apply the new firmware.
Final Steps in Flashing Process-
1. Checksum & Digital Signature Verification: Ensures that firmware is not corrupted and
authentic.
2. Fail-Safe Measures: If validation fails, the ECU rolls back to the previous firmware (if A/B
partitions are used).
3. ECU Reset & Boot: The ECU reboots and executes the new firmware.
Final Step: If the new firmware is validated, the bootloader jumps to the new application, and
the ECU operates normally.

9
4. UDS Services for Bootloader Flashing (ISO 14229-1)
The UDS protocol defines specific services for ECU reprogramming:
Key UDS Services for Flashing
0x10 – Diagnostic Session Control → Switches ECU to Programming Mode.
0x27 – Security Access → Implements authentication.
0x34 – Request Download → Begins firmware update process.
0x36 – Transfer Data → Sends firmware blocks to ECU.
0x37 – Request Transfer Exit → Completes the flashing process.
0x31 – Routine Control → Performs checksum validation.
UDS Communication Sequence :
The UDS (Unified Diagnostic Services) protocol (ISO 14229-1) enables secure firmware updates in
automotive ECUs. The UDS communication follows a request-response mechanism where an OEM
Diagnostic Tool (or OTA server) communicates with the ECU over CAN, Ethernet, or DoIP
(Diagnostics over IP).
Key Elements in the UDS Communication Sequence-
1. OEM Diagnostic Tool → ECU Communication
2. UDS Request-Response Exchange
3. Firmware Update Over CAN, Ethernet, or OTA
Each step is explained in detail below.
OEM Diagnostic Tool → ECU Communication:
✅ Purpose: The OEM tool (or OTA server) establishes a secure connection with the ECU
for firmware updates.
Communication Interface Options-
• CAN (Controller Area Network) – Used in traditional in-vehicle diagnostics and updates.
• Ethernet (DoIP – Diagnostics over IP) – Faster data transfer, used for ADAS and SDVs
(Software-Defined Vehicles).
• OTA (Over-the-Air) – Cloud-based update delivery in connected vehicles.
Key Steps in Connection Setup-
✔️ Tester (OEM tool) sends a connection request to the ECU.
✔️ ECU responds by switching to programming mode (if authorized).
✔️ Security Authentication is performed before allowing firmware updates.

10
 Next Step: UDS request-response exchange begins.
UDS Request-Response Exchange:
✅ Purpose: The ECU and the diagnostic tool exchange UDS messages to manage the
firmware update.
Key UDS Services Used-
UDS Service ID (Hex) Purpose
Switch ECU to
Diagnostic Session control 0x10
programmable mode
Authentication the tester to
Security Access 0x27 prevent unauthorized
updates
Prepare ECU for receiving
Request Download 0x34
firmware
Block wise firmware data
Transfer Data 0x36
transfer
Complete the firmware
Request Transfer exit 0x37
transfer
Routine Control 0x31 Verify firmware integrity
Restart ECU with the new
ECU Reset 0x11
firmware

Sequence Flow-
1. Session Activation (UDS 0x10 – Diagnostic Session Control) - The ECU enters
Programming Mode.
2. Security Access Authentication (UDS 0x27) - The tester provides a security key to unlock
ECU flashing.
3. Firmware Transfer Initiation (UDS 0x34) - The ECU prepares for firmware download.
4. Block-by-Block Data Transfer (UDS 0x36) - Firmware is sent in small blocks for integrity
validation.
5. Firmware Transfer Completion (UDS 0x37) - The update tool signals that all data is sent.

11
 6. Validation & Final Check (UDS 0x31) - ECU performs checksum validation and digital
signature verification.
7. ECU Reset & Reboot (UDS 0x11) - If validation is successful, the ECU restarts with the
new firmware.
Next Step: Firmware update process over CAN, Ethernet, or OTA.
Firmware Update Over CAN, Ethernet, or OTA:
✅ Purpose: Ensure a reliable and fail-safe firmware update over different communication
channels.
Data Transfer Mechanism-
✔️ CAN (ISO 15765-2 Transport Protocol) – Transfers firmware in small packets due to
limited bandwidth.
✔️ Ethernet (DoIP – Diagnostics over IP) – Transfers firmware at higher speeds (used for
large updates).
✔️ OTA (Over-the-Air Updates) – Uses cloud-to-vehicle communication, requiring secure
encryption.
Key Security Measures in Firmware Update-
🔒 Secure Boot Mechanism – Ensures firmware authenticity before execution.
🔒 End-to-End Encryption – Protects firmware data from tampering.

🔒 Rollback Mechanism – If an update fails, ECU reverts to previous firmware.

12
5. Security Measures in UDS Bootloader
Cyber threats in automotive systems are increasing. A secure bootloader must implement:
Secure Boot – Ensures that only OEM-signed firmware runs.
Firmware Encryption – Prevents unauthorized modification.
ISO 21434 Compliance – Aligns with automotive cybersecurity standards.
Access Control (UDS Security Access - 0x27) – Prevents unauthorized flashing.
Rollback Prevention – Blocks downgrades to vulnerable firmware versions.
Secure Boot & Cybersecurity in Automotive ECUs:
As vehicles become more connected, cybersecurity in automotive ECUs is critical to protect against
unauthorized access and malicious firmware modifications. The Secure Boot process ensures that
only trusted firmware is executed, while digital signature verification and secure firmware
transmission prevent unauthorized software from running in the vehicle.
Key Elements in Secure Boot & Cybersecurity-
• Secure Boot Process
• Digital Signature Verification
• Secure Firmware Transmission
Each of these steps is explained in detail below.
Secure Boot Process:
✅ Purpose: Ensure that only authentic and unmodified firmware is executed on the ECU.
What is Secure Boot?
Secure Boot is a cryptographic security mechanism that checks the integrity and authenticity of
firmware before execution. It prevents:
🔒 Unauthorized Code Execution – Blocks malware or tampered firmware.
🔒 Firmware Manipulation – Ensures only OEM-approved updates are installed.
🔒 ECU Bricking Prevention – If verification fails, the ECU won’t boot unsafe firmware.
Secure Boot Workflow-
1. Power-On & Bootloader Execution - When the ECU starts, the Primary Bootloader (stored in
ROM) runs first.
2. Bootloader Validates Secondary Bootloader - Uses cryptographic hashing (SHA-256) and
digital signature verification.

13
 3. Secondary Bootloader Verifies Application Firmware - Compares stored firmware hashes with
expected values.
4. Secure Boot Decision
✅ If firmware is valid, execution continues.

❌ If tampered, the bootloader halts execution or switches to a backup partition.

Next Step: Digital Signature Verification.
Digital Signature Verification;
✅ Purpose: Authenticate firmware using cryptographic digital signatures to prevent
unauthorized modifications.
How Digital Signatures Work in Secure Boot?
1. OEM Signs the Firmware: The original firmware is signed using an RSA or ECC private key.
2. ECU Verifies the Firmware Signature: The ECU has a pre-installed public key from the OEM.
It checks if the firmware’s signature matches the expected one.
3. Validation Outcome:
✅ Valid Signature → Firmware execution continues.

❌ Invalid Signature → The ECU rejects the firmware and prevents execution.
Security Features Used in Digital Signature Verification-
🔑 Public Key Infrastructure (PKI): Ensures firmware authenticity.

🔑 Elliptic Curve Cryptography (ECC): Reduces computational overhead while maintaining

security.
🔑 Hardware Security Module (HSM): Securely stores keys and handles cryptographic
operations inside the ECU.
Next Step: Secure Firmware Transmission.
Secure Firmware Transmission:
✅ Purpose: Ensure the firmware update process is protected from cyber threats such as
man-in-the-middle (MITM) attacks, unauthorized modifications, and data corruption.
Secure Transmission Techniques-
✔️ TLS (Transport Layer Security) Encryption: Used for OTA (Over-the-Air) firmware updates
to prevent interception.

14
 ✔️ AES-256 Encrypted Firmware Packages: The firmware is encrypted before transmission,
making it unreadable to attackers.
✔️ Message Authentication Codes (MACs) : Used to detect any unauthorized modifications
in transit.
✔️ Firmware Rollback Prevention: Prevents attackers from reinstalling older, vulnerable
firmware versions.
Workflow of Secure Firmware Transmission
• OEM Encrypts and Signs the Firmware.
• Encrypted Firmware is Sent Over a Secure Channel (TLS, VPN, Secure CAN).
• ECU Receives and Decrypts the Firmware.
• Firmware is Verified Using Digital Signatures.
• If Valid, Secure Boot Loads the New Firmware.

15
6. Fail-Safe Mechanisms for Update Failures
What happens if an update fails? A robust bootloader must prevent ECU bricking.
A/B Partition Switching-
• ECU maintains Partition A & Partition B.
• If a new update fails, it boots from the backup partition.
Watchdog Timer (WDT) Recovery-
If an update hangs, the watchdog timer resets the ECU.
Error Logging & Recovery-
Logs errors in non-volatile memory for debugging.
A/B Partitioning Fail-Safe Mechanism:
Why A/B Partitioning?
In modern automotive ECUs, firmware updates must be fail-safe to prevent ECU bricking due to
update failures. A/B partitioning provides a redundant firmware storage mechanism, allowing the
ECU to roll back to a working firmware version if an update fails.
This strategy is widely used in Software-Defined Vehicles (SDVs), Over-the-Air (OTA) updates, and
critical ECUs like ADAS, BMS, and powertrain controllers.
Key Elements in A/B Partitioning-
• Partition A & Partition B Failover Strategy
• Rollback Prevention Mechanism
Each step is explained below in detail.
Partition A & Partition B Failover Strategy:
✅ Purpose: Ensure that if a firmware update fails, the ECU can still boot using a stable
version.
How A/B Partitioning Works
The ECU has two separate partitions:
Partition A (Active Firmware)
Partition B (Backup Firmware)
During a firmware update:
The new firmware is written to the inactive partition (e.g., B if A is active).
Once validated, the ECU switches to the new partition.
Failover Scenarios:

16
 If New Firmware is valid: then ECU boots from the newly updated partition.
Firmware update fails: ECU Falls back to the last working partition.
Update corrupt/Power loss: Then the Bootloader detects corruption and prevents
switching.
Next Step: Rollback Prevention Mechanism.
Rollback Prevention Mechanism:
✅ Purpose: Prevent attackers from installing outdated firmware with known security
vulnerabilities.
Security Risks Without Rollback Prevention-
🔒 Attackers can install an older, insecure firmware version.

🔒 An exploited firmware could be reinstalled, bypassing security patches.

🔒 Critical ECU updates (ADAS, VCU, BMS) could be downgraded to unsafe versions.
How Rollback Prevention Works-
✔️ Firmware Version Management:
The ECU stores a "firmware version counter" in NVM (Non-Volatile Memory) or TPM (Trusted
Platform Module). The counter only increments forward, preventing reinstallation of older
firmware.
✔️ Digital Signature & Secure Boot Integration:
Each firmware package is signed with a cryptographic hash (SHA-256, ECC, or RSA-2048).
The bootloader verifies the firmware signature and version number before allowing execution.
✔️ Secure Over-the-Air (OTA) Updates:
New firmware is transmitted encrypted (AES-256).
The ECU validates and decrypts the update before writing it.
Rollback Prevention Workflow-
1. Firmware Update Initiated – New firmware is downloaded and written to the inactive
partition.
2. Signature & Integrity Check – Secure Boot verifies the digital signature.
3. Firmware Version Comparison – The ECU checks if the new version is greater than the
current version.
4. Activation & Boot – If validation passes, the ECU boots from the updated partition.
5. Rollback Prevention – Older firmware versions are blocked from reinstallation.

17
7. Sources for Firmware Updates:
A UDS Bootloader supports multiple update sources:
SD Card Updates – Used for offline updates.
USB / Serial Communication – Common for debugging.
ECU-to-ECU Updates – Allows firmware transfer over CAN/Ethernet.
Wireless OTA Updates – Enables remote firmware upgrades.
Firmware Update Sources & Secure Transmission:
Why Secure Firmware Updates Matter?
Automotive ECUs require secure and fail-safe firmware updates to prevent:
🔒 Malware Injection – Hackers installing unauthorized software.

🔒 ECU Bricking – Power failure or corrupted updates rendering the ECU useless.
🔒 Man-in-the-Middle Attacks – Interception and modification of firmware data during
transmission.
To address these risks, firmware can be updated using multiple sources with secure transmission
mechanisms.
Key Elements in Firmware Update Sources
• Different Firmware Update Sources
• Secure Update Transmission Path
Each step is explained in detail below.
Different Firmware Update Sources:
✅ Purpose: Allow ECUs to receive firmware updates from various sources based on network
availability and security policies.
Which Update Source is Best?
✔️ OTA (Over-the-Air) Updates → Used for wireless, large-scale deployment but requires
strong security measures.
✔️ USB & SD Card Updates → Used when internet access is unavailable, but poses security
risks if the source is untrusted.
✔️ Ethernet & CAN-Based Updates → Used for high-speed, controlled updates in workshops.
Next Step: Secure update transmission path.

18
Secure Update Transmission Path:
✅ Purpose: Ensure that firmware updates are not intercepted, modified, or corrupted during
transmission.
Secure Firmware Update Workflow-
1. Firmware Signing & Encryption: The OEM signs the firmware with RSA-2048 or ECC digital
signatures. Firmware is encrypted with AES-256 to prevent tampering.
2. Secure Communication Channel: OTA Updates → Use TLS 1.3 (Transport Layer Security) to
prevent hacking. USB / SD Updates → Check digital signatures before execution. Ethernet &
CAN Updates → Use DoIP (Diagnostics over IP) encryption.
3. Firmware Integrity Check Before Flashing : The ECU verifies the firmware signature before
applying the update. If verification fails, the update is rejected.
4. Rollback Prevention: Prevents downgrade attacks where hackers try to reinstall older
firmware. The ECU maintains a firmware version counter in secure storage (HSM/TPM).
5. ECU Reset & Final Verification : Once the update is successful, the ECU reboots and
performs a self-check.

Summary:
The Unified Diagnostic Services (UDS) Bootloader is a critical component in modern automotive
ECUs, enabling secure firmware updates, diagnostics, and fail-safe mechanisms. It ensures that
vehicles can receive software updates safely and reliably via OTA, USB, CAN, or Ethernet,
preventing ECU failures and cyber threats.

Reference: References include international standards (ISO, SAE), semiconductor manufacturers'

documentation (NXP, Infineon, Renesys), OEM whitepapers (Tesla, VW, BMW), and cryptographic
security research. This ensures that the UDS Bootloader post is based on credible, industry-
recognized sources.

Do Follow on LinkedIn use below URL. Like my post and do repost.

https://www.linkedin.com/in/prashant-rokade-
bb46b5106?utm_source=share&utm_campaign=share_via&utm_content=profile&utm_medium=an
droid_app

19