As part of our Quick Check tests, we have repeatedly looked at gadgets and solutions in the past that were rather in the low-price segment and thus also suggested rather small security budgets. As expected, we often found what we were looking for when it came to identifying sometimes serious security vulnerabilities. In the future, we plan to test more in this area again, so that we do not lose sight of the supposedly “darker” side of the Internet of Things in contrast to the high-security products examined in our certification tests and thus retain a more representative impression of the overall situation.

As one of the first candidates, we chose the Nooie Cam 360 from the Chinese manufacturer Shenzhen Apeman Innovation Science & Technology – a popular, frequently sold IP camera with a comparatively low price and wide distribution. Whether it confirmed our expectations in a negative way or even surprised us in a positive way is clarified in the following test report.

© Nooie


In terms of features, the Nooie Cam 360 offers everything you can expect in this category and at the suggested price of under 50€: The video recording happens in 1080P and this with the help of the built-in 940nm infrared LEDs even in complete darkness up to 10m away. In addition, the camera has 2-way audio, motion and noise detection and can be rotated or tilted almost completely by 355° horizontally and 94° vertically. As usual, the camera is set up, managed and controlled via a mobile app for Android and iOS (“Nooie”; com.nooie.home). In addition, the status light, which indicates an active recording, can optionally be turned off (why you would want to do that remains to be seen).

Mobile applications

The applications belonging to the device (tested versions 2.2.1 for Android and 2.3.0 for iOS) were, as usual in our tests, sent through a static analysis in the first step and did not show any serious problems at first. As expected for the camera’s range of functions, the Android application requests all permissions (37 in total) that are necessary for localization, audio, Bluetooth, etc. – but also permissions to change system settings or download additional functions without notifying the user. That alone already suggests a quite extensive data collection independent from the functionality actually provided. We will come back to this point later.

All 37 requested permissions on Android; Some of them are at least suspicious (access to the Ad-ID, download without notification and localization via all available methods are rather uncommon and in no case necessary for the pure functionality of the camera system)

Another indication for a possible vulnerability regarding unsecured storage of personal data locally is the authorization to access the external storage, i.e. the SD card. If data is actually stored there, it can also be accessed by all other apps installed on the smartphone. However, no real threat could be identified here. The app does store the screenshots taken from the camera stream on the SD card, but Android’s screenshot function would not solve this differently. Critical data, such as account data, keys or similar, could only be found in the protected app area, to which only the Nooie app itself has exclusive access – at least on non-rooted smartphones.

The analysis of the Android manifest basically only shows standard problems: A large number of services, receivers and activities are potentially vulnerable to being accessible to other apps as well, which could lead to unintentional data leakage. In addition, the application is configured to allow unencrypted communications by default – not a sure proof of a security problem, but at least an indication already.

In addition, several trackers and analysis modules can be identified in the app code. Among them are Google Firebase, Firebase Analytics, Firebase Data Transport and Google Mobile Services. Thus, a quite extensive collection and analysis of data is possible in any case.

Identified tracker with entry in Exodus Privacy database; more can still be found manually

The situation is quite similar for the iOS application, albeit due to the more restrictive nature of iOS with fewer permissions and without data collection via Google services of course. However, a configuration that allows unencrypted communication via the Internet is especially noticeable here also.

Local and online communication

As mentioned in the previous section, the static analysis pointed out some potential weaknesses in this area. This was further investigated through the practical analysis of the concrete, observable communication of the device and mobile application.

Basically, the communication here is structured as in many other representatives of the product category as well: Authentication and account management are carried out via a TLS connection in order to then run control and camera stream via connectionless UDP. Basically, there is no conceptual problem with this, as long as the TLS connection is adequately implemented and secured, and the payload, i.e. the actual transmitted image and audio data of the UDP stream, is additionally encrypted. The UDP protocol does not offer this option by default, so here the manufacturer has to add an encryption layer himself. As said, no problem with this implementation, if these points are taken into account – In the case of the Nooie Cam 360, however, a “if” with a question mark.

The camera stream itself looks secure at first. We could also identify parts in plain text here and there, but these were rather uncritical information that could also be secured, but basically did not cause any vulnerability. A limited code analysis as part of the quick check also indicated a quite solid implementation and payload encryption with AES (with the help of the relatively frequently integrated SDK from the Chinese IoT manufacturer Tuya in version 3.34.5).

UDP communication is fully implemented via Tuya native libraries (including AES payload encryption)

The real problem, however, is actually the communication for authentication and administration, which, although encrypted with TLS 1.2, completely undermines the protection of the camera stream due to its implementation. We were able to identify a classic vulnerability in the form of insufficient certificate validation on the application side. A simple man-in-the-middle attack on the connections of the applications thus allows account details, user data and the like to be read and entire accounts to be taken over in this way. The account password itself is then transmitted as MD5 and can therefore also be reconstructed relatively easy, especially if it is a natural language password. Using the mobile application in a public, possibly untrustworthy WLAN would therefore be extremely risky because the WLAN operator could easily break all encrypted connections and access critical information.

Successfull MitM-attack on login; Password as MD5 Hash
Login response with refresh token

Also noticeable from the communication readout is the large amount of data that the camera system collects and transmits about the user and the user’s phone. We will come back to this point in the next section.

Furthermore, as usual, we also subjected the server side of the solution to a quick security scan and did not find any super critical issues. Only a small update of the server configurations would be suggested here – support for the long outdated TLS protocol versions 1.0 and 1.1 leave some theoretical weak points and should be disabled immediately. In the current implementation of the applications, however, this point is almost irrelevant, since connections in the more recent TLS version 1.2 are also vulnerable to a number of attacks here.

Scan of 3 IPs to which communication was observed e.g. for authentication; blue is collected information, orange is medium severity issues

Data protection and privacy

For this test area, as always, we looked at the privacy policy and searched for information on data collection, processing and storage. Of particular interest here are inconsistencies between information given and actual product behavior observed. These inconsistencies can be unmentioned data collection, included trackers, or features with privacy and data protection implications.

The privacy policy (as of April 8, 2021) of the Nooie solution is quite detailed in itself. We were not able to locate a version for German-speaking (or even “non-English-speaking”) users, but apart from that, the level of detail and information provided therein was already quite extensive – if not fully comprehensive.

But first to the most important question: What data is collected? Short answer: All of it. Long answer: In principle, everything that the combination of application and camera can draw from the context of use is collected. This includes all information about the smartphone in use, including model, Unique Device Identifier, International Mobile Device ID (IMEI), localization data via GPS, WiFi and Bluetooth, installed applications, MAC address, phone number etc. In addition, data that can be extracted from the camera recordings themselves is also collected. According to the privacy policy, this includes e.g. room layout at the installation site, information about items and their distribution, people present and pets(!?), information from motion and noise detection, and accordingly also facial and voice information for people present. We did not look at every single communication and the transmitted data during the quick check, but the sheer amount of transmitted data, apart from the actual camera stream, was quite striking.

Excerpt from privacy policy regarding data collection

The sheer amount of collected information is not something that could be criticized, as long as the user is informed about it in detail. What the user decides for himself and his data is up to them. We would still like to mention it because it obviously exceeds what would be necessary for the pure functionality of the camera system in our opinion.

Apart from that, there are still a few classic tracking modules that are not explicitly mentioned by name in the privacy policy, but are included in the application and, according to our observation, are also active during operation. As mentioned before, these are Google’s Firebase modules that are often found nowadays, in this particular case Firebase, Firebase Analytics and Firebase Data Transport.

Firebase Libraries integrated in Android application


The Nooie Cam 360 is quite a usable camera solution. In fact, we had expected worse beforehand. Of course, we also have to note that this was only our quick check – we did not dive into the deepest depths of the solution and thus cannot completely rule out further abysses. What we have seen, however, could be turned into a quite solid security solution with a few manageable updates and fixes. The serious security flaw in online communication and the far from perfect implementation of data protection and privacy do not allow more than 1 out of 3 stars as a rating in the current state – but admittedly 1 star more than we had initially feared.