Reverse Engineering Hanwha Security Camera Firmware File Decryption with Ida Pro

I recently took a look at a commercial-grade IoT security camera made by Hanwha: the WiseNet XNF-8010RW. I wanted to perform a security audit of this device just like I would do during an IoT pentest.

WiseNet XNF-8010R by Hanwha

The first thing I did was to disassemble the device and trace the UART console on an unpopulated ribbon cable connector.

Next, I dumped the device firmware by desoldering the BGA nand flash chip.

The Encrypted Firmware File #

Even though I had the firmware of my device, I thought it would be interesting to see if firmware was available on the company’s website. I was in luck!

WiseNet XNF-8010R Firmware Download Page

I downloaded the XNF-8010R_2.10.04_20230328_R640.zip file and unzipped it. This resulted in the file XNF-8010R_2.10.04_20230328_R640.img.

By running the file command on this firmware file, I could determine right away that it is encrypted via openssl.

How does the file command know this is encrypted with openssl? It’s all in the file header:

That Salted__ string at the beginning is a dead giveaway.

Now the million dollar question is: What’s the encryption password?

The Chicken and Egg Problem #

We are presented with a dilemma. The password to decrypt the firmware file is contained somewhere inside the firmware itself.

But let’s think about that… The decryption password needs to be somewhere on the running device in order to decrypt the firmware file and apply the upgrade.

Luckily we already performed the beginning steps to break out of our chicken and egg-style dilemma. We’ve already dumped the firmware from the physical device! Let’s dig into the firmware dump.

Firmware Analysis #

We performed a chip-off firmware extraction of a BGA Nand flash chip on the camera. If you watched the video embedded above, you will remember that our Nand flash chip contained spare area. We dumped the firmware twice: once including and once excluding that spare area from the firmware dump file. For our analysis, we are going to use the version without the spare area include. We will name this file wisenet-nospare.bin.

The first thing we want to do with this firmware file is to split it up into the various partitions that exist. You may recall that we saw the partition table addresses nicely printed out in the UART logs:

Partition Table Obtained via UART

We can then use dd to split the single files into all of the partitions with the following bash script:

Next, we want to find where in the firmware the decryption is likely occurring. The only lead we currently have is the openssl is being used, but this actually tells us a lot. Our current hypothesis is that the openssl enc command is being used. Let’s start with strings!

“openssl” String Analysis #

Here there are a couple of interesting strings. These are the ones we should focus on:

openssl rsautl -decrypt -inkey %s -in %s -out %s openssl enc -aes-256-cbc -d -k

Both of those strings are performing decryption of a file with openssl. The first one is using a keyfile and the second is using a password. We expect a password so let’s look at what strings are before and after that string.

First we ID the partition that has the openssl enc -aes-256-cbc -d -k string:

then we look at the adjacent strings:

Well look at that! We see mentions of fwupgrader all around the openssl string.

“decryption” String Analysis #

We also find some interesting strings when looking for the term “decryption”:

When we use strings wisenet-nospare.bin | less and search around the area, we see “MODELINFO_MODEL_DECRYPTIONKEY” referenced. We find more interesting strings in a similar structure:

modelinfo_XNF-8010R 0,MODELINFO_FEATURE_NUM,MF_CXF,MODEL_FEATURE 1,MODELINFO_AUX_COUNT,0,int 2,MODELINFO_BACKEND_VA,BACKEND_MD | BACKEND_TD | BACKEND_DF | BACKEND_DA,BACKND_VA_MASK_E 3,MODELINFO_CONFIG_BACKUP_KEY,dCTjgwaXvsPzQ0QRlweM7IP7T0ytT7G25rEM4g+17cQ=,const char* ... 119,MODELINFO_MAX_VIDEO_PACKET_SIZE,4587520,int 120,MODELINFO_SNMP_MODEL_OID,404,int 121,MODELINFO_NO_SUPPORT_EXTERNAL_DN,0,int 122,MODELINFO_MODEL_DECRYPTIONKEY,ZK5EA1tGT4AHOUCUU5tUMuQCfA2fbjnSEgOiLR104eI=,const char* 123,MODELINFO_DEFAULT_SMARTCODEC_LEVEL,1,int

We seem to have stumbled onto some sort of database. Let’s gather up all of those keys for later:

Carving ELF Binaries with Binwalk #

We know that our openssl call occurs within partition 8. Let’s use binwalk to carve only ELF binaries out of that partition binary file:

This results in the following binary files:

Next, it’s a simple process to determine which binary has our string:

Binary Reverse Engineering via IDA Pro #

Now we can load part8.bin_21510144_elf.raw into Ida Pro for analysis. It recognizes it as a ARM Little-endian binary. We keep all the default analysis options enabled and select “OK” to start.

Loading Binary into IDA Pro

The analysis takes a few minutes to complete. Then the first thing we want to do is look for our string that led us to this binary initially.

Navigation: View -> Open subviews -> Strings

We found our string and navigated to its address.

IDA Strings Subview

String Address

Navigation: Right Click on “aOpensslEncAes2_2” -> List cross references to…

Here we can see that the reference to this string is in a function called decrypt_imageFile! We are on the right track.

String Cross-References

After navigating to the decrypt_imageFile and running the decompiler we can see that a function get_modelStr is passed two arguments. The first argument is 122 and the second is a buffer.

get_modelStr() Decompilation

That number 122 looks familiar…

Remember this:

122,MODELINFO_MODEL_DECRYPTIONKEY,ZK5EA1tGT4AHOUCUU5tUMuQCfA2fbjnSEgOiLR104eI=,const char*

It clearly seems like it’s referencing that MODELINFO_MODEL_DECRYPTIONKEY! Let’s try to decrypt! We will try all of the MODELINFO_MODEL_DECRYPTIONKEY and MODELINFO_CONFIG_BACKUP_KEY values we found to be sure.

That didn’t work. All of those passwords and digest method combinations give us the same error:

We Need to Go Deeper #

So clearly something else is at play. Let’s look at one of those MODELINFO_MODEL_DECRYPTIONKEY values:

$ echo ZK5ECtTH+jkYs87uEEUrwyZ9+wsFkWpk3AbtnTEY3gs= | base64 -d | xxd 00000000: 64ae 440a d4c7 fa39 18b3 ceee 1045 2bc3 d.D....9.....E+. 00000010: 267d fb0b 0591 6a64 dc06 ed9d 3118 de0b &}....jd....1...

Every “decryption key” value is 32 bytes when base64 decoded and seemingly random (high entropy). It’s possible the decryption keys are themselves encrypted.

Let’s follow get_modelStr() down a chain of wrapper functions.

UtilityWrapper::get_modelStr() -> Sysinfo::get_modelStr() -> SysinfoManager::get_featureData()

We are led to the get_featureData function which makes reference to a global variable unk_B6B250.

get_featureData() Decompilation

Looking at the cross-references to this unk_B6B250 global variable, we find that its used by three functions:

• get_featureData()
• set_featureData()
• replace_featureData()

unk_B6B250 Cross-References

The replace_featureData function looks interesting. Why would we ever want to replace that data? Let’s find out.

Looking at the cross-references to replace_featureData, we find exactly what we are looking for: a function named decrypt_modelfeature.

replace_featureData() Cross-References

decrypt_modelfeature() Function #

This function is clearly the place that those encrypted + base64-encoded strings will be decrypted. Let’s walk through the major parts of this function.

First, we see the string “zeppelin” be constructed into a string. Let’s call this buffer zeppelin_buff for now. This seems like the making of a hardcoded password…

Hardcoded "zeppelin" String

Then we see the HashedKeyCipher(out_buffer,1,6,zeppelin_buff) constructor called. So we are hashing the “zeppelin” string but with what function? We’ll dig into that later.

Next we call Utility::Security::HashedKeyCipher::get_decryptor on that object that was returned from the last call. So those arguments have a lot of weight in determining how things get decrypted.

HashedKeyCipher() Constuctor #

Down inside the constructor we eventually see a call like this in the decompiler:

Stepping into the create_hash() function we get the following decompilation:

First problem solved! The hash function used to hash the key is Sha256.

Next we see a line like this:

A bit up in the code we notice that the *(_DWORD *)(a1 + 52) is loaded with the 3rd argument of the HashedKeyCipher constructor which was 6.

Here is the start of the create_decryptor function:

So now we can identify that the AES-256-CFB8 cipher is being used.

Decrypting the Encryption Passphrase #

Now we have all of the moving pieces we need to begin. The following bash script will perform the following actions:

• perform a sha256 hash of the string “zeppelin” to obtain the AES key
• loop over all ciphertext (encrypted passphrases) we found in the firmware blob
• set the IV to all zeros
• attempt to decrypt using the AES-256-CFB8 cipher

This successfully outputs the following:

Decrypting the Firmware File #

Now we have a few possible passphrases to decrypted the firmware file with. Let’s update our script from before:

Note that we are also looping over a bunch of different digest functions because we don’t know what the default digest function the openssl version on the camera is.

Here is the result of running file on all of our attempts:

We did it! Note that try2 corresponds to the passphrase “HTWXNF-8010R”.

Let’s unpack our freshly decrypted firmware:

Predictable Passphrases #

So I mentioned at the beginning that the camera model I performed the firmware extraction on is XNF-8010RW and we observe that the firmware decryption password was HTWXNF-8010R. We can see that the firmware encryption passphrase is basically just the model number of the device!

Let’s test this hypothesis on another firmware file that we don’t have a physical device for.

For this test I selected the WiseNet TNO-L4040TR device which has a firmware image file called TNO-L4040TR_2.21.11_20240923_R81.img.

Using the same patterns as we saw in the other device, we guessed that the passphrase is HTWTNO-L4040TR.

This passphrase was found to be correct:

Conclusion #

This was a fun mental exercise and hopefully a good demonstration of how a persistent attacker is going to reverse-engineer your hardcoded password/encryption scheme. It is not a matter of “IF”; it’s a matter of “WHEN”.

Need an IoT pentest performed on your products?

Check out Brown Fine Security’s IoT Penetration Testing services!