In 2018, curiosity struck after purchasing an OBD2 scanner to diagnose my car. The device, a VXDAS AM3011 OBD2 Scanner, intrigued me not just for its diagnostic capabilities, specifically its ability to clear Vehicle Control System (VCS) codes (often referred to as Diagnostic Trouble Codes or DTCs), but also for the technology within. I wanted to understand what made it tick. Many users wonder, “Does The Nexpeak Nx301 Enhanced Obd2 Scanner Clear Vcs Code?” and my exploration into similar devices sheds light on this very question by examining the underlying technology and functionality of these tools.
The VXDAS AM3011 OBD2 Scanner, much like the Nexpeak NX301 and other enhanced OBD2 scanners available on the market, featured a USB Mini port, several interface buttons, and the crucial OBD2 connector. Opening the device unveiled the core components responsible for its operation, including its ability to read and potentially clear those all-important VCS codes.
Inside, I identified a STM32F103 SoC, an SPI SOIC8 Flash memory, voltage regulation components to step down the car’s 12V to 5V and 3.3V, USB data lines, a small buzzer, a screen connector, LEDs, and a ribbon cable for the button interface. While seemingly simple, this hardware configuration represents the foundation for an OBD2 scanner’s functionality, including the capability to interact with a vehicle’s computer and manage VCS codes.
My initial goal shifted from simply using the scanner to understanding its inner workings. Could I extract the firmware to analyze its operation and potentially reverse engineer it? Unfortunately, direct firmware extraction proved challenging at that time. Discussions with colleagues, including @Iskuri, led to the idea of bypassing the original firmware altogether – erasing it and writing my own. This opened up exciting possibilities for customizing the scanner’s functions, potentially even enhancing or altering its VCS code clearing capabilities.
To proceed, a detailed pinout was necessary. Tracing the PCB and identifying pin functions became the next step.
Leveraging the STM32F103 datasheet pinout, I successfully loaded a new program onto the device. This custom firmware allowed the scanner to act as a Mass Storage Device (MSD) when connected to a computer, proving the feasibility of reprogramming the unit and taking control of its functions, including potentially how it handles VCS codes. However, in my eagerness, I inadvertently disabled the SWD functionality, effectively bricking the device – a valuable lesson in the experimentation process.
Reflecting on the project’s direction and considering the time investment versus potential return, I focused on the core hardware: the STM32F103 SoC, buttons, LCD screen, and SPI Flash. Further research revealed that the VXDAS AM3011, like many OBD2 scanners including models similar to the Nexpeak NX301, is often a rebranded device manufactured by JDiag. This realization led me to explore other similar scanners, hoping to find one with less restrictive security features and potentially gain a deeper understanding of their common architecture and VCS code clearing mechanisms.
My search for alternative devices led me to the IsYoung NL100.
The IsYoung NL100 initially appeared promising.
The silk screen printing on the PCB provided valuable debugging and screen pinout information, alongside details about the OBD2 cable connections. This level of detail is crucial for anyone attempting to understand or modify these devices, regardless of whether their primary interest is in hardware hacking or simply verifying if a scanner like the Nexpeak NX301 effectively clears VCS codes.
The IsYoung NL100 utilized an NXP LPC 1754 MCU, similar in development ease to the STM32. My attempt to extract the SPI flash for analysis resulted in damaging the chip, temporarily halting progress with this device. However, the intention remained to replace the SPI chip and develop custom firmware, extending the exploration to different microcontrollers beyond STM32, and broadening the understanding of OBD2 scanner design principles relevant to VCS code management.
Simultaneously, an ANCEL AD410 scanner was on order, promising enhanced features like a color screen and more buttons.
Reaching out to @iskuri again, we discussed the idea of parallel exploration – both investigating different OBD2 scanners and sharing findings. This collaborative approach proved fruitful.
Chris, my collaborator, focused on the ANCEL AD410 and successfully repurposed it into a USB NFC attack tool, showcasing the versatility of these devices beyond their intended diagnostic functions. His work is documented in his blog post: https://www.pentestpartners.com/security-blog/turning-an-obd-ii-reader-into-a-usb-nfc-attack-tool/
The ANCEL AD410 OBD2/CAN Diagnostic Tool, upon inspection, revealed a more complex internal design compared to previous devices.
The pinout for the LCD screen, in particular, was significantly more extensive. Like the VXDAS AM3011, the ANCEL AD410 also utilized a GD32F103 series SoC, closely related to STM32, suggesting a common underlying architecture across different OBD2 scanner brands and models, which is relevant to understanding their general capabilities, including VCS code clearing.
Interestingly, the silkscreen indicated “Autophix OM126_V2.0,” further reinforcing the trend of white-labeled OBD2 scanners. Firmware for the Autophix OM126, potentially similar to firmware in other rebranded scanners and possibly sharing functionalities with the Nexpeak NX301, was found online: http://www.autophix.com/en/supports/download.html?ref=noobiedog.com. Initial inspection suggested the firmware was encrypted, posing a further challenge for analysis. The color screen and its numerous pins presented a new area of investigation. Contacting ForWorld LCD (fwlcd.com), the screen manufacturer, and Autophix directly yielded limited information regarding screen specifications and availability.
Finally, the JDiag JD-101 arrived. Manufactured by the same company as the initial VXDAS AM3011, it offered a familiar platform for exploration.
Despite using a GD32 MCU (STM32 clone), the JDiag JD-101, like many basic OBD2 scanners, likely shares core functionalities with devices like the Nexpeak NX301 in terms of reading and clearing VCS codes, albeit with potentially different hardware implementations. This unit featured a 128×64 non-color LCD screen, four buttons, 128Mb Flash storage, a CAN Transceiver, and USB capability.
The immediate step was to map the PCB traces, particularly to understand the screen interface.
The screen interface appeared straightforward. Noticing the JDiag JD-101 and IsYoung NL100 screens had identical 10-pin and 2 LED pin configurations, I successfully swapped the screens, confirming the pinout compatibility derived from the IsYoung NL100’s silkscreen.
With a better understanding of the hardware, the next phase focused on establishing a connection via SWD.
Using an ST-LinkV2 debugger and STM32CubeProgrammer, a connection was established. The JDiag JD-101, like the initial VXDAS AM3011, had CRP enabled, requiring a full chip erase to enable custom firmware loading.
With the ability to load custom firmware, the possibilities expanded. While humorous ideas like Tetris were considered, the focus shifted towards more practical applications such as USB HID emulation, attack tools, or CAN bus fuzzing. These explorations, while not directly answering “does the Nexpeak NX301 enhanced OBD2 scanner clear VCS code?”, provide crucial insights into the underlying technology that enables such functions in OBD2 scanners generally. By understanding the hardware and firmware, we gain a deeper appreciation for how these devices interact with vehicle systems to read and clear diagnostic codes.
The subsequent steps involve developing custom firmware to leverage the scanner’s hardware – buttons, screen, SPI flash, and CAN transceiver. This will require further investigation into the electronics and software aspects of these devices.
Stay tuned for Part 2, where we delve into writing custom firmware for OBD2 scanners and further explore their capabilities.
p.s. For wire tracing, I’m currently using PAINT. Suggestions for better Windows-based tools are welcome!
