What’s Inside a “Made/Make in India” NVR?

Reverse engineering a white-label CCTV recorder and following its firmware trail back to the underlying OEM platform.

I recently got my hands on a CCTV NVR carrying a “Made/Make in India” marking.

Make in india label

At first, there wasn’t anything particularly unusual about it.

It was another inexpensive network video recorder: cameras connected to an NVR, a web interface for management, RTSP for video streaming, and the usual collection of embedded services running somewhere underneath.

But as someone who spends too much time looking at firmware, I had a simple question:

What is actually running inside this thing?

So I opened it.

What started as a hardware investigation eventually turned into a firmware-reversing exercise involving UART, bootloaders, Ghidra, filesystem extraction, network services and, eventually, some surprisingly specific Chinese-market configuration data.

This isn’t an investigation into whether the device was legally or illegally labelled.

It’s a technical investigation into what the firmware reveals about the platform underneath the branding.

The device

The first step was identifying the hardware.

The board was marked: NBD88X16S-KL-V3

NBD880XXS-XE-V1

The main SoC identified itself as: XM8536E

That was my first major clue.

I connected to the board’s UART interface and captured the boot process.

The bootloader printed:

XM8536E Spl Boot
DDR Init OK
U-Boot 2014.04
CPU: XM8536E

At this point, the investigation became much more interesting.

The UART output wasn’t simply telling me that the device was an ARM-based embedded system.

It was giving me an identifiable platform.

XM8536E.

And that led me toward the Xiongmai/XM ecosystem.

Looking inside the firmware

The next step was obtaining and extracting the firmware.

One of the firmware images I analyzed/Downloaded was named:

YK_HZXM_NBD88X16S-KL-V3_V4.03.R11.Nat.dss.OnvifC.20240617.bin

There are several interesting clues hiding in that filename.

Most notably:There are several interesting clues hiding in that filename.

Most notably:

HZXM

and:

NBD88X16S-KL-V3

The firmware naming strongly suggested that I wasn’t looking at a completely independent software platform developed specifically for the brand on the front of the NVR.

It looked much more like an existing OEM/reference platform.

I extracted the firmware after dumping with Binwalk:

Firmware dumping

binwalk -e xm8536e_dump.bin

After extraction, the filesystem contained familiar embedded Linux components and binaries.

Among them were XM-prefixed libraries and applications such as:

libXMcrypto.so
dvrHelper
netinit

The more I looked, the more the firmware started to tell its own story.

Then I found something much more interesting

Finding an OEM chipset is one thing.

Finding an OEM firmware tree is another.

But the most interesting evidence wasn’t the XM prefix.

It was hidden inside the factory-default configuration code.

I loaded the relevant binary into Ghidra and started following the configuration initialization routines.

One function immediately became interesting:

FUN_003707d0

This function contained a large collection of default configuration values.

And some of those values were very specific.

A Chinese DDNS provider hiding in the defaults

Among the default configuration values were:

local_68 = "CN99"; local_68 = "your.3322.org";

These aren’t generic placeholders like:

example.com

They are recognizable Chinese-market DDNS configuration values.

That raised a question:

Why would an NVR supposedly configured for the Indian market ship with Chinese-market DDNS defaults?

One occurrence could be dismissed as legacy code.

So I kept digging.

Then came the cellular configuration

Further down the same configuration initialization logic, I found:

local_68 = “ctnet@mycdma.cn”; local_68 = “ChinaNet”;

From Ghidra

Now the picture was becoming harder to dismiss as coincidence.

These values correspond to Chinese telecommunications configuration.

This wasn’t simply a string mentioning China somewhere in a massive firmware image.

These values were being assigned as factory/default configuration data.

That distinction matters.

The firmware wasn’t merely capable of supporting different markets.

It contained predefined values associated with the Chinese market.

GB28181 was another clue

The configuration code also contained fields associated with:

GB28181

including fields such as:

szCsIP
szDeviceNO
szServerNo

For anyone outside the CCTV world, GB28181 may look like just another protocol name.

But it is an important clue when investigating Chinese surveillance equipment.

GB28181 is a Chinese video-surveillance interoperability standard widely used within China’s surveillance ecosystem.

So now I had multiple independent indicators:

XM8536E
       ↓
NBD88X16S-KL-V3
       ↓
HZXM firmware naming
       ↓
XM libraries/components
       ↓
Chinese DDNS defaults
       ↓
Chinese telecom configuration
       ↓
GB28181 configuration

At this point, the firmware was giving me a pretty clear picture of its ancestry.

he OEM trail gets even deeper

While examining the same configuration code, I also encountered:

IPC-JVFENG
JVFENG-IPC

There was also an encrypted configuration blob:

U2FsdGVkX18c+wueAmUBfAfheFN6ntdNoAWnbMDsTrk=

The U2FsdGVkX1... prefix is characteristic of an OpenSSL-style salted encrypted data format.

I haven’t yet established exactly what the blob decrypts to, so I’m not going to pretend that I know.

That’s another important part of reverse engineering:

Not every interesting string is automatically a vulnerability or a complete answer.

Sometimes you find a clue and leave it as a clue until you can prove what it means

What about the network attack surface?

Once I understood that the device was built around this platform, I started looking at the services exposed by the NVR.

A network scan revealed:

80/tcp       HTTP
554/tcp      RTSP
30100/tcp    Unknown/proprietary
34567/tcp    Proprietary NVR service

There was also something particularly interesting in the firmware:

9530

A debug/Telnet-related service.

Naturally, I tried connecting to it.

nc -nv 192.168.1.201 9530

The result:

I followed that with an Nmap scan:

nmap -Pn -sV -sC -p9530 192.168.1.201

The port was:

9530/tcp closed

So was the debug functionality actually active?

Not on the device I tested.

And this is where static analysis becomes important.

The hidden debug logic

Inside another function:

FUN_0039491c

I found code dealing with account configuration and debug functionality.

The function references configuration files including:

/mnt/mtd/Config/Account1 /mnt/mtd/Config/Account2 /mnt/custom/Account.custom

It also constructs:

telnetctrl

and checks:

/mnt/custom/9530Disable

More importantly, the function contains messages such as:

----- debug mode, dvriver already open port ------
----- auto maintain or empty pwd close debug mode ------
----- debug mode, open 9530 ------

This was a fascinating discovery.

The firmware clearly contains logic for controlling a debug service associated with port 9530.

But there is an important difference between:

“The firmware contains code capable of opening a debug service.”

and:

“The device is remotely vulnerable through that debug service.”

I only had evidence for the first statement.

The live device actually showed port 9530 as closed.

And then I found this

Buried in the same code path was:

Dm8Hxy71

At first glance, the obvious reaction is:

“Hardcoded password!”

But that’s not how I want to report it.

I haven’t established that this is the administrator password.

I haven’t established that it works as a universal credential.

What I can say is that a hardcoded value appears in code associated with the debug/Telnet control mechanism.

So for now, I’m treating:

Dm8Hxy71

as a hardcoded debug/service value, rather than incorrectly calling it an administrator password.

That’s a much more boring statement.

But it’s also a much more defensible one.

So, is the NVR actually vulnerable?

I don’t know yet.

And that’s okay.

The investigation has already produced something interesting without inventing a vulnerability.

At this stage I have confirmed:

Hardware

• XM8536E SoC
• NBD88X16S-KL-V3 platform

Firmware

• Xiongmai/XM-related firmware naming
• XM-related software components
• Chinese-market configuration defaults
• GB28181 configuration
• OEM/reference-design indicators

Network

• HTTP on port 80
• RTSP on 554
• Proprietary services on 30100 and 34567
• Firmware logic associated with debug/Telnet port 9530

Debug functionality

• telnetctrl
• /mnt/custom/9530Disable
• debug-mode logic
• hardcoded value Dm8Hxy71

But I have not established:

• Remote code execution
• Remote authentication bypass
• That Dm8Hxy71 is an administrator password
• That the NVR is affected by another Xiongmai CVE
• That port 9530 can be remotely enabled
• That the device’s physical assembly occurred outside India

Those questions require more testing.

The bigger question isn’t just security

This is where the investigation became more interesting to me.

The device carries a Made in India marking.

The firmware, however, contains very strong evidence of an underlying Chinese OEM/reference platform.

That doesn’t automatically mean the product wasn’t assembled in India.

A device can contain imported SoCs, reference hardware and third-party firmware while still undergoing manufacturing or assembly in another country.

So the technically interesting question isn’t:

“Is it really Indian?”

It’s:

“How much of the underlying product is locally engineered, and how much comes from an existing OEM platform?”

And firmware is one of the best places to investigate that question.

Why this matters for security

White-label IoT isn’t inherently bad.

It’s actually extremely common.

The problem appears when multiple products and brands inherit the same underlying software without independently auditing it.

Imagine this:

OEM firmware
                          │
            ┌─────────────┼─────────────┐
            │             │             │
         Brand A       Brand B       Brand C
            │             │             │
          NVR            NVR           NVR

If all three products ship essentially the same vulnerable component, a vulnerability discovered in the upstream platform can potentially affect all three.

That’s why identifying the underlying OEM isn’t just an attribution exercise.

It’s an attack-surface discovery technique.

The UART port was enough to start the investigation

One of the things I like most about embedded security research is that expensive equipment isn’t always necessary to start asking questions.

A UART connection gave me the first major clue:

UART pins

XM8536E Spl Boot

From there:

UART
 ↓
SoC identification
 ↓
Firmware identification
 ↓
Filesystem extraction
 ↓
Ghidra
 ↓
Configuration analysis
 ↓
OEM identification
 ↓
Network attack surface

A few wires and a serial adapter turned a black-box CCTV recorder into something I could investigate.

What’s next?

The investigation isn’t finished.

The next phase is much more security-focused.

The important question now is:

Can an externally reachable service reach the interesting code paths identified during static analysis?

The primary targets are:

Port 80
   ↓
Web application/API
   ↓
Authentication
   ↓
Request handlers
   ↓
Dangerous sinks

Port 34567
   ↓
Proprietary protocol
   ↓
Packet parser
   ↓
Command handlers

Port 30100
   ↓
Unknown protocol
   ↓
Service identification
   ↓
Input handling

Port 554
   ↓
RTSP
   ↓
Authentication / parser

If I can establish a reproducible security impact, that will become a separate technical write-up.

For now, the firmware has already answered one question.

The label on the outside tells you who is selling the device.

The firmware can tell you where the device came from.

Final note

This research was performed on a device under my control for security research and reverse-engineering purposes.

The observations in this article are limited to the specific hardware and firmware versions I examined. Similarity to other Xiongmai/XM products does not automatically mean that they share the same vulnerabilities.