I thought I'd have a look at how Huisun have protected their firmware distribution files from prying eyes.
On the face of it, they are .zip files.
But .zip files can have very strong passwords that make a simple brute-force attack impractical, as I confirmed when I set JtR on the IPNC_S2l2.0.1_build201603031830.zip version.
As @klasipca had mentioned, as an implicit challenge, that a certain Russian forum member well known for mentioning his exploits (but not explaining how he did them), had been there already, I thought I'd try some cheating. Or maybe a lateral approach:
So - some of you who are careful to preserve your carefully chosen Mini PTZ V2 camera settings may have noticed that if you export the device configuration you get a file such as "ipnc_config_20160722184151.zip"
This is remarkably like the firmware file, complete with a strong password, holding the file 'package.bin'.
Perhaps Huisun are using the same routines to process these zip files as they use for the firmware files. In which case a bit of study might yield some useful information.
Without boring you with the fine detail, it turns out that it's easy enough to grab copies of the 'work in progress' files when exporting the device configuration, as it gathers the relevant configuration files, zips them up into package.bin, then re-writes the zip file encrypted with a random password. Which it writes into the .zip file in an obfuscated way. The .zip passwords are not stored in the firmware routines, but the way they are created is, it's a random number seeded with an XORed version of the system time, and a bit more obfuscation.
Having grabbed files in plaintext (the configuration files) that have been zipped up into package.bin which has then been zipped up with a password, a 'known plaintext attack' can be made on the ZIP keys.
But that's not much use in itself, as each file will have it's own password, not relevant to the specific firmware file password.
However, it does indicate a possible attack method on the firmware file.
Given some knowledge of how the firmware update process works, again it's easily possible to grab copies of the temporary component files that are extracted from the IPNC_S2l2.0.1_build201603031830.zip file during the firmware update process. These persist for as long as you don't click the 'OK' button to reboot after the update has been applied.
The files inside 'package.bin' are
And although the result gives an unencrypted package.bin file which is directly usable if you wish to explore the firmware, as an academic exercise the plaintext attack on the zip file works easily to extract the keys.
On the face of it, they are .zip files.
But .zip files can have very strong passwords that make a simple brute-force attack impractical, as I confirmed when I set JtR on the IPNC_S2l2.0.1_build201603031830.zip version.
As @klasipca had mentioned, as an implicit challenge, that a certain Russian forum member well known for mentioning his exploits (but not explaining how he did them), had been there already, I thought I'd try some cheating. Or maybe a lateral approach:
You can do lots when you've got a working device and telnet access!
So - some of you who are careful to preserve your carefully chosen Mini PTZ V2 camera settings may have noticed that if you export the device configuration you get a file such as "ipnc_config_20160722184151.zip"
This is remarkably like the firmware file, complete with a strong password, holding the file 'package.bin'.
Perhaps Huisun are using the same routines to process these zip files as they use for the firmware files. In which case a bit of study might yield some useful information.
Without boring you with the fine detail, it turns out that it's easy enough to grab copies of the 'work in progress' files when exporting the device configuration, as it gathers the relevant configuration files, zips them up into package.bin, then re-writes the zip file encrypted with a random password. Which it writes into the .zip file in an obfuscated way. The .zip passwords are not stored in the firmware routines, but the way they are created is, it's a random number seeded with an XORed version of the system time, and a bit more obfuscation.
Having grabbed files in plaintext (the configuration files) that have been zipped up into package.bin which has then been zipped up with a password, a 'known plaintext attack' can be made on the ZIP keys.
But that's not much use in itself, as each file will have it's own password, not relevant to the specific firmware file password.
However, it does indicate a possible attack method on the firmware file.
Given some knowledge of how the firmware update process works, again it's easily possible to grab copies of the temporary component files that are extracted from the IPNC_S2l2.0.1_build201603031830.zip file during the firmware update process. These persist for as long as you don't click the 'OK' button to reboot after the update has been applied.
The files inside 'package.bin' are
Code:
Archive contains:
index.ini
web.tgz
ipnc.tgz
M342_MiniPtz.bin
M342_ZoomCam.bin
STM32F030F4_MiniPtz.bin
S90ipnc
STM32F030F4_PtContrl.bin
Total 8 entries (5499144 bytes)
Last edited by a moderator:
