Read Memory By Address (0x23) Service in UDS Protocol

Leave a Comment / Protocols / By piembsystech

://piembsystech.com/uds-protocol/" target="_blank" rel="noreferrer noopener">UDS (Unified Diagnostic Services) protocol: Read Memory By Address (0x23). This service allows diagnostic tools to directly access specific memory locations in the ECU. It’s widely used for reading calibration data, software versions, and system states. Understanding this service is crucial for vehicle diagnostics, flashing, and validation. In this post, I’ll explain how it works, what parameters it uses, and how to implement it. By the end, you’ll have a clear understanding of how to use service 0x23 effectively. Let’s dive into the memory map!

Introduction to Read Memory By Address (0x23) Service in UDS Protocol

Welcome to this deep dive into one of the core services of the UDS (Unified Diagnostic Services) protocol – Read Memory By Address (0x23). This service is used to read data from specific memory locations within an Electronic Control Unit (ECU). It plays a vital role in diagnostics, allowing testers and tools to retrieve critical information like calibration data, firmware details, and system status. Whether you’re working on ECU validation, diagnostics, or flash programming, understanding how 0x23 works is essential. In this article, we’ll explore its purpose, structure, and practical use cases with examples to help you grasp it clearly.

What is Read Memory By Address (0x23) Service in UDS Protocol?

The Read Memory By Address service is defined in the UDS (Unified Diagnostic Services) protocol under Service ID 0x23. It allows a diagnostic tester (like a scan tool or diagnostic software) to read raw data directly from a specific memory address in an ECU (Electronic Control Unit).

• This is crucial for:
  • Reading internal data during development, production, or after-sales service.
  • Debugging and validating ECU behavior.
  • Retrieving software or calibration values.
  • Performing memory integrity checks.

Note:

There are no sub-function parameters used by this service.

Why do we need Read Memory By Address (0x23) Service in UDS Protocol?

The ReadMemoryByAddress (0x23) service plays a crucial role in automotive diagnostics and ECU development. Here’s why it’s important:

1. Direct Access to ECU Memory

The ReadMemoryByAddress (0x23) service allows direct access to specific memory addresses in the ECU. Unlike other services that retrieve predefined data, this service enables testers to read raw data directly from RAM, ROM, EEPROM, or Flash. This is especially useful when developers need access to low-level memory content not mapped to any standard identifier (DID). It gives maximum flexibility when testing or validating internal states of the ECU. Engineers can define both the start address and the size of memory to read.

2. Advanced Debugging and Testing

During ECU software development, developers often need to analyze real-time data or monitor variable values stored in memory. The 0x23 service enables precise reading of those internal variables without needing additional code changes. This is extremely helpful in debugging runtime issues, identifying misbehaving modules, or monitoring buffers and task states. By using 0x23, testers can observe internal behaviors and verify correctness under various test scenarios. It provides deep visibility into the ECU’s internal processing.

3. Flexible Access Based on Session and Security

Unlike other diagnostic services with fixed formats, 0x23 allows dynamic access to any address and size, which increases its usefulness. However, due to its power, access is usually limited based on diagnostic session (like extendedSession or programmingSession) and security level (via SecurityAccess service 0x27). This ensures sensitive memory areas are not exposed to unauthorized users. OEMs can configure memory access rules to protect critical areas like bootloaders or calibration zones. This balance between flexibility and security is a key feature of UDS.

4. Used for Reading Calibrations and Internal States

The ReadMemoryByAddress service is widely used in calibration workflows where engineers need to read tuning parameters stored in memory. These parameters may include fuel maps, timing tables, or sensor configurations. Since these values are often located at specific memory addresses, the 0x23 service becomes essential for accessing them during calibration or re-flashing. Additionally, it helps technicians read current software states or monitor system responses under different operating conditions. This access plays a vital role in performance tuning and diagnostics.

5. Essential for Custom Tools and Flashing Utilities

Many OEMs and Tier-1 suppliers use custom flashing tools or bootloaders that rely on the 0x23 service to read memory content before and after reprogramming. These tools use ReadMemoryByAddress to verify if firmware updates were correctly written, check CRC values, or read boot flags. It is also useful in field diagnostics where software integrity or configuration must be validated remotely. This service thus becomes an integral part of the software flashing and validation ecosystem.

6. Supports Memory Validation and Integrity Checks

The 0x23 service can be used to validate the integrity of specific memory regions, such as checking version strings, status flags, or magic numbers after boot-up or flashing. Engineers can send a read request to the known address where such identifiers are stored and verify if the ECU is running the correct version or configuration. This is particularly important during factory programming or after OTA (Over-the-Air) updates. It allows automatic verification of memory contents without needing custom diagnostic routines.

7. Useful for Reverse Engineering and Security Analysis

In security research and reverse engineering, ReadMemoryByAddress is often used to analyze how an ECU operates internally. By reading memory regions, researchers can study variable changes, inspect stack traces, or understand internal control logic. While access is typically restricted for security reasons, in controlled environments like test benches or with valid credentials, it provides deep insights into ECU behavior. This helps both in identifying vulnerabilities and improving the robustness of the system.

Syntax of SID (0x23) Request Message Frame Format

Data Byte	Parameter Name	Byte Value
#1	Read Memory By Address Request SID	0x23
#2	Address And Length Format Identifier	0x00 – 0xFF
#3 : #(m-1)+3	Memory Address[] = [                                           byte#1 (MSB)                                                     :                                           byte#m ]	0x00 – 0xFF : 0x00 – 0xFF
n-(k-1) : #n	Memory Size[] = [                                   byte#1 (MSB)                 :                                   byte#k ]	0x00 – 0xFF : 0x00 – 0xFF
C1: The presence of this parameter depends on address length information parameter of the address And Length Format Identifier C2: The presence of this parameter depends on the memory size length information of the address And Length Format Identifier.

addressAndLengthFormatIdentifier

• This parameter is a one-byte value with each nibble encoded separately
  • Bits 7-4: Length (in bytes) of the memorySize parameter
  • Bits 3-0: Length (in bytes) of the memoryAddress parameter

memoryAddress

The memoryAddress parameter specifies the starting address in server memory from which data is retrieved. The number of bytes for this address is indicated by the low nibble (bits 3-0) of the addressAndLengthFormatIdentifier. Byte #m represents the least significant byte, while the most significant byte(s) can be used as a memory identifier. For example, in systems with overlapping memory addresses, an unused byte can identify the desired memory device. This usage should be defined by the vehicle manufacturer or system supplier.

memorySize

The memorySize parameter in the ReadMemoryByAddress request message specifies the number of bytes to be read, starting from the address given by memoryAddress in the server’s memory. The size in bytes is defined by the high nibble (bits 7-4) of the addressAndLengthFormatIdentifier.

Syntax of SID (0x23) Response Message Frame Format

Positive Response:

Data Byte	Parameter Name	Byte Value
#1	Read Memory By Address +Ve Response SID	0x63
#2 : #n	Data Record[] = [                                data#1       :                                data#m ]	0x00 – 0xFF : 0x00 – 0xFF

Response Message Data-Parameter

dataRecord

This parameter is used in the ReadMemoryByAddress positive response message to provide the requested data record values to the client. The content of the dataRecord reflects the requested memory contents and is not defined in this document. Data formatting should be specified by the vehicle manufacturer or system supplier.

Syntax of SID (0x23) Response Message Frame Format

Negative Response:

Data Byte	Parameter Name	Byte Value
#1	Read Memory By Address –Ve Response SID [ byte#1 ]	0x7F
#2	Requested SID [ byte#1 ]	0x23
#3	Negative Response Code [ byte#1 ]	NRC

Supported Negative Response Codes (NRCs) for Read Memory By Address (0x23) Service

NRC	Parameter Name	Description
0x13	Incorrect Message Length Or Invalid Format	This Negative Response Code (NRC) shall be sent if the length of the message is incorrect.
0x22	Conditions Not Correct	This Negative Response Code (NRC) shall be sent if the server’s operating conditions do not meet the requirements to perform the requested action.
0x31	Request Out Of Range	This Negative Response Code (NRC) shall be sent if any of the following conditions occur: •Any memory address within the interval [0xMA, (0xMA + 0xMS – 0x1)] is invalid. •Any memory address within the interval [0xMA, (0xMA + 0xMS – 0x1)] is restricted. •The memory Size parameter value in the request message is not supported by the server. •The specified address And Length Format Identifier is not valid. •The memory Size parameter value in the request message is zero.
0x33	Security Access Denied	This Negative Response Code (NRC) shall be sent if any memory address within the interval [0xMA, (0xMA + 0xMS – 0x1)] is secure and the server is locked.

Example of Read Memory By Address (0x23) Service in UDS Protocol

Here are the Examples of Read Memory By Address (0x23) Service in UDS Protocol:

Example #1: Read Memory By Address 4-Byte (32-bit) Addressing

The client reads 259 data bytes from the server’s memory starting at memory address 0x2048 1392.

Read Memory By Address Request Message Flow Example #1

Message Direction	Client → Server
Message Type	Request
Data byte	Description (all values are in hexadecimal)	Byte Value
#1	Read Memory By Address Request SID	0x23
#2	Address And Length Format Identifier	0x24
#3 #4 #5 #6	Memory Address [ byte#1 ] (MSB) Memory Address [ byte#2 ] Memory Address [ byte#3 ] Memory Address [ byte#4 ]	0x20 0x48 0x13 0x92
#7 #8	Memory Size [ byte#1 ] (MSB) Memory Size [ byte#2 ]	0x01 0x03

Read Memory By Address Positive Response Message Flow Example #1

Message Direction	Server → Client
Message Type	Response
Data byte	Description (all values are in hexadecimal)	Byte Value
#1	Read Memory By Address +Ve Response SID	0x63
#2 : #259+1	Data Record [ data#1 ] (memory cell#1)                                    : Data Record [ data#259 ] (memory cell#259)	0x00 : 0x8C

Read Memory By Address Negative Response Message Flow Example #1

Message Direction	Server → Client
Message Type	Response
Data byte	Description (all values are in hexadecimal)	Byte Value
#1	Read Memory By Address –Ve Response SID [ byte#1 ]	0x7F
#2	Requested SID [ byte#1 ]	0x23
#3	Negative Response Code [ byte#1 ]	NRC

Example #2: Read Memory By Address 2-Byte (16-bit) Addressing

The client reads five data bytes from the server’s memory starting at memory address 0x4813.

Read Memory By Address Request Message Flow Example #2

Message Direction	Client → Server
Message Type	Request
Data byte	Description (all values are in hexadecimal)	Byte Value
#1	Read Memory By Address Request SID	0x23
#2	Address And Length Format Identifier	0x12
#3 #4	Memory Address [ byte#1 (MSB) ] Memory Address [ byte#2 (LSB) ]	0x48 0x13
#5	Memory Size [ byte#1 ]	0x05

Read Memory By Address Positive Response Message Flow Example #2

Message Direction	Server → Client
Message Type	Response
Data byte	Description (all values are in hexadecimal)	Byte Value
#1	Read Memory By Address +Ve Response SID	0x63
#2 #3 #4 #5 #6	Data Record [ data#1 ] (memory cell#1) Data Record [ data#2 ] (memory cell#2) Data Record [ data#3 ] (memory cell#3) Data Record [ data#4 ] (memory cell#4) Data Record [ data#5 ] (memory cell#5)	0x43 0x2A 0x07 0x2A 0x55

Read Memory By Address Negative Response Message Flow Example #2

Message Direction	Server → Client
Message Type	Response
Data byte	Description (all values are in hexadecimal)	Byte Value
#1	Read Memory By Address –Ve Response SID [ data#1 ]	0x7F
#2	Requested SID [ data#1 ]	0x23
#3	Negative Response Code [ data#1 ]	NRC

Example #3: Read Memory By Address, 3-Byte (24-Bit) Addressing

The client reads three data bytes from the server’s external RAM cells starting at memory address 0x204813.

Read Memory By Address Request Message Flow Example #3

Message Direction	Client → Server
Message Type	Request
Data byte	Description (all values are in hexadecimal)	Byte Value
#1	Read Memory By Address Request SID	0x23
#2	Address And Length Format Identifier	0x23
#3 #4 #5	Memory Address [ byte#1 (MSB) ] Memory Address [ byte#2 ] Memory Address [ byte#3 (LSB) ]	0x20 0x48 0x13
#6 #7	Memory Size [ byte#1 (MSB) ] Memory Size [ byte#2 (LSB) ]	0x00 0x03

Read Memory By Address First Positive Response Message, Example #3

Message Direction	Server → Client
Message Type	Response
Data byte	Description (all values are in hexadecimal)	Byte Value
#1	Read Memory By Address +Ve Response SID	0x63
#2 #3 #4	Data Record [ data#1 ] (memory cell#1) Data Record [ data#2 ] (memory cell#2) Data Record [ data#3 ] (memory cell#3)	0x00 0x01 0x8C

Read Memory By Address First Negative Response Message, Example #3

Message Direction	Server → Client
Message Type	Response
Data byte	Description (all values are in hexadecimal)	Byte Value
#1	Read Memory By Address –Ve Response SID [ data#1 ]	0x7F
#2	Requested SID [ data#1 ]	0x23
#3	Negative Response Code [ data#1 ]	NRC

Example of Request Upload (0x23) SID Request and Positive Response Frame Format

Request Frame Format:

Service ID (SID)	Address and Length format Identifier	Memory Size	Memory Address
0x23	0x22	0x02	0x68	0x72

Positive Response Frame Format:

Response ID	Data Record
0x63	0x55	0x0A	0x8C	0x00

Example of Request Upload (0x23) SID Request and Negative Response Frame Format

Request Frame Format:

Service ID (SID)	Address and Length format Identifier	Memory Size	Memory Address (Wrong Values)
0x23	0x22	0x02	0x74	0x56

Negative Response Frame Format:

Response ID	Request SID	Response
0x7F	0x23	13

Advantages of Read Memory By Address (0x23) Service in UDS Protocol

Following are the Advantages of Read Memory By Address (0x23) Service in UDS Protocol:

1. Direct Access to ECU Memory: This service allows direct access to specific memory locations inside the ECU, such as RAM or flash. It is highly flexible because it doesn’t require predefined data identifiers. Developers can fetch raw memory content for analysis. This is useful when accessing custom data or temporary runtime variables. It gives complete control over what part of memory is read.
2. Useful During Development and Debugging: During ECU software development, engineers often need to monitor variable states or buffers. This service helps by allowing real-time access to memory without halting the ECU. It’s a powerful way to validate software functionality. Debugging becomes easier when developers can read and verify the contents of specific memory areas. This improves development speed and accuracy.
3. Enables Data Verification After Flashing: After programming the ECU with new firmware or calibration data, this service is used to verify that the memory has been updated correctly. For example, developers may check checksum locations or version strings. It ensures that the flashing process completed successfully. This post-flash validation adds reliability to the ECU update workflow.
4. Supports Calibration and Testing Tools: Calibration engineers use tools to adjust and test system parameters in real-time. The 0x23 service helps these tools fetch memory data without needing extra configurations. It allows dynamic monitoring and quick adjustments during calibration. This is crucial in automotive tuning and system performance testing.
5. Allows Flexible Data Reading Without Custom DIDs: Unlike the ReadDataByIdentifier (0x22) service, which requires a specific ID for each data point, the 0x23 service can read from any memory address. This flexibility makes it ideal for temporary debugging tasks. It reduces the effort needed to define and maintain DIDs for each data element. The tester can just specify the address and length of data required.
6. Supports Memory Validation and Integrity Checks: It can be used to verify important memory sections, such as firmware identifiers, CRC values, or boot flags. This adds an extra layer of safety before or after a software update. By reading specific memory content, testers can confirm the ECU’s current status. It’s often used in production lines or validation labs for quick quality assurance.
7. Useful for Reverse Engineering and Security Analysis: Security researchers and advanced test engineers use this service to study ECU behavior. It allows them to examine memory layouts and internal variables. This is helpful in identifying potential vulnerabilities or undocumented features. By observing how memory changes, they can improve system protection and reliability.
8. Compatible with Various ECU Architectures: The 0x23 service is not tied to a particular hardware or software platform. As long as the ECU supports it and the address formats are known, it can work across many systems. This makes it a universal tool for diagnostics. It simplifies integration with generic tools used across different OEMs and Tier-1 suppliers.
9. Enables Real-Time Monitoring of System State: It allows testers to observe changes in memory as the ECU operates, helping them understand how variables change over time. This is crucial during runtime debugging. For example, you can track a buffer or counter variable in real-time. Such insights help optimize performance or catch unusual behaviors early.
10. Enhances Diagnostic Coverage: Using this service, testers can access memory locations that may not be exposed via standard diagnostic identifiers. This gives them deeper insight into ECU behavior. It increases diagnostic coverage beyond what’s normally available. This is especially useful in low-level testing and advanced troubleshooting.

Disadvantages of Read Memory By Address (0x23) Service in UDS Protocol

Following are the Disadvantages of Read Memory By Address (0x23) Service in UDS Protocol:

1. Risk of Unauthorized Access: If proper security measures are not implemented, the Read Memory By Address service can be exploited to access sensitive areas of ECU memory. Hackers or unauthorized testers can retrieve calibration data, encryption keys, or proprietary algorithms. These security risks are why most ECUs implement strict session and security checks before allowing access to this service. Without such safeguards, unauthorized access to critical system information can lead to data theft or system manipulation.
2. Complex Address and Size Management: This service requires precise specification of the memory address and the size of the data to be read. A small error in providing the address or size can lead to incorrect or incomplete data retrieval. The tester must fully understand the ECU’s memory layout and structure to avoid mistakes. Unlike identifier-based services like 0x22, which use predefined parameters, this manual configuration increases the chance of human error, requiring deep knowledge of the ECU.
3. Limited Use in Production Vehicles: OEMs typically disable or restrict the Read Memory By Address service in production vehicles due to its potential for abuse. Since it can expose sensitive information, it is usually only accessible during development or under controlled test conditions. In real-world vehicle diagnostics, this service is often unavailable unless the vehicle is in a specific diagnostic or programming session, further limiting its practical use outside testing environments.
4. Requires Security Access Unlocking: To prevent unauthorized access, this service often requires the ECU to go through a security access process. This involves unlocking specific security levels by using a seed-key algorithm, which can be time-consuming. If the security access is not correctly unlocked, the ECU will reject the request. As a result, testers need to handle this extra step in their diagnostic procedures, which can lead to delays, particularly in automated or script-based testing.
5. No Built-In Data Structure or Interpretation: Unlike other UDS services, which provide structured and labeled data (like 0x22), the Read Memory By Address service returns raw bytes from memory. Testers must decode these raw bytes based on their internal knowledge of the ECU’s memory map. Without a proper understanding of how the data is structured, interpreting these raw values can be challenging and prone to errors. This raw data approach makes it harder for testers to quickly make sense of the results.
6. Potential to Crash or Freeze ECU: Improper use of this service can result in system instability. If the tester requests data from invalid or protected memory regions, it can cause the ECU to crash or become unresponsive. In extreme cases, it may even trigger a system reboot. This is a significant risk, especially when performing automated tests that could involve multiple service calls, requiring careful validation of memory ranges to prevent such issues.
7. Limited Diagnostic Tool Compatibility: Many generic diagnostic tools are not fully compatible with the Read Memory By Address service. This service requires testers to input precise address and size information, and not all diagnostic tools offer flexible interfaces for this. Additionally, the service might not be supported on non-OEM tools, limiting its accessibility. Consequently, testers may need to rely on specialized or OEM-specific diagnostic equipment, reducing the service’s broad applicability.
8. Can Expose Intellectual Property: One of the most concerning disadvantages is the potential for exposing sensitive intellectual property (IP). If the Read Memory By Address service is misused, it could reveal proprietary software, algorithms, or calibration data stored in the ECU’s memory. This makes it easier for malicious actors to reverse-engineer the system, potentially leading to IP theft or unauthorized software manipulation. OEMs address this by restricting access to this service, but the risk remains if the service is left unprotected.
9. Not Suitable for All Users: The Read Memory By Address service is highly technical and typically not suitable for average users or general technicians. It requires a thorough understanding of the ECU’s internal memory structure and how data is laid out. Mistakes in addressing, interpreting data, or security unlocking can lead to inaccurate results or system failures. Therefore, it is best used by skilled engineers or those with specialized knowledge in ECU diagnostics and memory architecture.
10. Address Format and Endianness Issues: The memory address format and size may vary depending on the ECU’s configuration and the AddressAndLengthFormatIdentifier (ALFID) specified in the request. Different ECUs may use different byte orders (endianness), which can cause misinterpretation of the data. Testers must ensure that the correct address and format are used to avoid errors, which adds an extra layer of complexity when using the Read Memory By Address service across different ECU types.

Future Development and Enhancement of Read Memory By Address (0x23) Service in UDS Protocol

The Read Memory By Address (0x23) service in the UDS Protocol has shown significant utility in automotive diagnostics and system programming. However, as with all technologies, there is always room for improvement and future development. Here’s an exploration of potential enhancements and the future of this service:

1. Improved Security Measures: As security concerns remain a top priority, future versions of the Read Memory By Address service will likely incorporate more advanced encryption and authentication protocols. This will prevent unauthorized access to sensitive ECU memory areas and help protect against malicious attacks.
2. Address Format Standardization: Currently, the Read Memory By Address service can face issues with varying address formats and endianness across different ECUs. The future of the service may see standardization in how memory addresses are represented and formatted. This will help ensure consistency across different vehicles, manufacturers, and diagnostic tools, reducing errors.
3. Enhanced Diagnostic Tool Compatibility: In the future, diagnostic tools and software could become more capable of automatically detecting and interpreting memory data, minimizing the need for manual address and size entry. With more user-friendly interfaces, even non-experts would be able to leverage this service without deep technical knowledge.
4. Increased Automation in Testing: As automotive testing evolves, there will likely be more automation around memory reads, especially during manufacturing or quality control. Automated systems could dynamically choose the correct address, size, and data structure, reducing human error and speeding up diagnostics.
5. Real-Time Memory Monitoring: Future enhancements could include real-time memory access monitoring, allowing testers or diagnostic tools to view the changes in ECU memory as they occur. This would enable immediate identification of issues, like data corruption or faulty memory writes, and assist with faster resolutions.
6. Integration with Cloud-Based Diagnostics: With the increasing adoption of connected vehicles, cloud-based diagnostic solutions will play a more significant role in future automotive services. The Read Memory By Address service could evolve to allow for remote memory access, enabling diagnostic data to be streamed to cloud platforms for analysis.
7. Advanced Error Detection and Validation: To prevent incorrect or incomplete reads, future implementations of the Read Memory By Address service may include more robust error detection and validation mechanisms. This would ensure that memory reads are accurate, especially in critical sections of the ECU’s memory.
8. Integration with Over-the-Air (OTA) Updates: With the rise of over-the-air (OTA) software updates in the automotive industry, future versions of this service may be closely integrated with OTA capabilities. Memory access and diagnostic information could be utilized to ensure the correct installation of updates and patch vulnerabilities remotely.
9. Memory Protection and Access Restrictions: Future enhancements could introduce more granular access control mechanisms for different memory regions. Instead of a broad “read memory” request, ECU memory could be divided into more protected zones, with specific access rights to restrict unauthorized access to critical data.
10. Streamlined User Interfaces for Diagnostics: As UDS protocol and memory management become more complex, future tools may feature advanced graphical user interfaces (GUIs) for the Read Memory By Address service. These interfaces will visually represent the memory layout and provide intuitive controls, simplifying the process for technicians.