zCamClassifier: IoT Camera Identifier

• zCamClassifier is a supervised classification component that identifies known IoT cameras using 62 generic, flow-based features derived from network traffic.
• The system converts raw packet captures into flow vectors and applies feature reduction with Extra Trees, achieving high accuracy (up to 99.8%) using models like XGB.
• In computer vision, the term also refers to a failure mode where classifiers capture camera-specific artifacts rather than semantic content, highlighting domain-dependent interpretation.

zCamClassifier is the supervised classification component of zCamInspector, a system for identifying known IoT cameras from passively observed network traffic using only flow-based features rather than IP addresses, ports, or decryption. In the reported design, raw packet captures are converted into flows by CICFlowmeter, each flow is represented by 62 generic features, and supervised models are trained to distinguish specific IoT cameras from other traffic; the complementary zCamDetector module addresses zero-day cameras with one-class models (Chaudhary et al., 10 Sep 2025). In a separate computer-vision usage, “zCamClassifier” can also denote the failure mode in which a classifier learns camera-specific artifacts instead of semantic content, so the term has a domain-dependent meaning (Jackson et al., 2020).

1. System role within zCamInspector

Within zCamInspector, zCamClassifier is the module for identifying known IoT cameras, whereas zCamDetector is responsible for detecting zero-day cameras. The deployment scenario is passive: network traces are collected at a router or switch, flows are assembled from packet traces, 62 flow-based features are extracted, and the resulting feature vectors are passed to supervised classifiers that output device labels and alerts for IoT camera presence (Chaudhary et al., 10 Sep 2025).

The formulation is explicitly feature-centric rather than payload-centric. The classification stage is described generically as

$\hat{y} = f(\mathbf{x}; \theta),$

where $\mathbf{x}$ is the input feature vector and $\theta$ denotes classifier parameters. This abstraction is instantiated with seven supervised models: Extra Trees (ET), Decision Tree (DT), Random Forest (RF), K-Nearest Neighbors (KNN), Extreme Gradient Boosting Tree (XGB), Linear Kernel SVM (LKSVM), and Gaussian Naive Bayes (GNB). The stated motivation is comparative: trees, ensembles, boosting, SVM, KNN, and probabilistic classification are all evaluated in the same multi-class flow-identification setting.

A central architectural property is agnosticism to application-layer visibility. The system is described as IP/port agnostic, requiring no DPI and no decryption, and is intended for environments such as smart homes, where encrypted and NATted traffic are common.

2. Flow representation and feature selection

zCamClassifier relies on 62 generic flow-based features extracted by CICFlowmeter. Flows are defined by the 6-tuple $$\{\text{FlowID, SrcIP, DstIP, SrcPort, DstPort, Protocol}\}$$, but the tuple itself is not used as features. Instead, the representation uses transport- and flow-statistical descriptors such as Flow Duration, Init Bwd Win Byts, ACK Flag Count, Bwd Header Len, Fwd [IAT](https://www.emergentmind.com/topics/implicit-association-test-iat) Tot, Bwd IAT Tot, and Pkt Len Max/Min (Chaudhary et al., 10 Sep 2025).

This feature choice distinguishes zCamClassifier from methods that are protocol-specific or that directly encode endpoint identity. The paper presents this as a core differentiator: the feature set is generic, usable under encryption, and not dependent on static addressing or ports. A plausible implication is that the method targets behavioral regularities in streaming-camera traffic rather than explicit signatures.

Feature reduction is performed with Extra Trees feature importance. Constant features are discarded, a pre-selection step based on standard deviation is applied, and ET ranking is then used to select the top 10 most relevant features. The paper reports that this significantly reduces dimensionality with negligible accuracy loss and can even improve performance. Features such as Init Bwd Win Byts, ACK Flag Cnt, Flow Duration, Bwd IAT Tot, and Bwd Header Len appear consistently among the top-ranked features, although the exact top-10 varies across datasets.

3. Datasets and evaluation protocol

The reported evaluation spans over 40 GB of traffic across three datasets and includes both camera and non-camera traffic (Chaudhary et al., 10 Sep 2025).

Dataset	Content	Role
Set I (BITSPHC)	6 IoT cameras	Supervised identification
Set II (UNSW)	5 IoT cameras	Supervised identification
Set III (Others)	4 conferencing and 2 video-sharing applications	Non-IoT traffic

Set I contains six commercial IoT cameras. Set II contains five open-source IoT cameras, with ~1.5GB of traffic and mostly handshake packets. Set III contains non-IoT camera traffic, specifically conferencing and video-sharing applications. Across Sets I and II, the study reports 11 distinct IoT cameras.

Training and testing are performed on Set I, Set II, and the Combination setting, yielding 6-class, 5-class, and 11-class classification problems. The datasets were split into training and testing subsets, with details for splits, e.g. 90/10 in various places. Experiments compare performance using all 62 features against performance using the top 10 features selected by ET. The evaluation also explicitly states that no IP or port information was used in training or testing.

This experimental design is meant to test both closed-set camera identification and robustness under broader traffic diversity. Because Set III contains non-camera applications, it also provides the basis for the zero-day and anomaly-detection experiments associated with zCamDetector.

4. Supervised classification performance

The strongest reported supervised results are obtained by XGB, which is the best-performing model on Set I, Set II, and the combined 11-class setting (Chaudhary et al., 10 Sep 2025).

Setting	Best model	Accuracy
Set I (all 62 features)	XGB	99.24%
Set II (all 62 features)	XGB	99.84%
Combined 11-class (all 62 features)	XGB	99.8%

The remaining models also perform strongly in most settings: on Set I, RF reaches 98.12%, DT 97.29%, ET 97.97%, and KNN 95.68%, whereas LKSVM is lower at 89.03% and GNB is much lower at 39.76%. On Set II, RF reaches 99.71%, DT 99.49%, KNN 99.52%, ET 99.78%, LKSVM 97.27%, and GNB 65.27%. In the combined 11-class setting, KNN reaches 99.6%, and the paper states that others are similar except GNB at 53.87%.

Using only the top 10 features, performance remains high: XGB reaches up to 97.5%, RF up to 97%, and DT up to 97.4%. The paper interprets this as evidence that substantial dimensionality reduction is possible without destroying discriminative power.

Additional reported metrics reinforce the same ranking. For XGB, Precision is 97.75%, Recall is ~100%, and F1-score is 97.14%. False negatives are reported as low as 0.3% in the abstract, and the detailed summary gives example misclassification rates of 0.78% for SpyBulb and 1.8% for Canary. For runtime, zCamClassifier has a median training time of 2.4 sec and test time of 0.19 sec, which the paper describes as fast enough for near-real-time analysis. The abstract also notes >95% accuracy for specific devices, such as Spy Clock cameras.

5. Relation to zero-day detection and earlier systems

Although zCamClassifier is the supervised, known-device component, it is presented as part of a larger two-module system. The associated zCamDetector evaluates four one-class models—OCSVM, SGDOCSVM, Isolation Forest, and DeepSVDD—for zero-day IoT camera detection (Chaudhary et al., 10 Sep 2025).

The abstract reports zero-day accuracies of 93.20% for OCSVM, 96.55% for SGDOCSVM, 78.65% for IF, and 92.16% for DeepSVDD. In a different zero-day setting, where the Others set is used for training and all 11 IoT cameras are treated as zero-day, the reported training/testing accuracies are 90.4%/27.2% for OCSVM, 90.6%/19.7% for SGDOCSVM, 90.1%/14.3% for IF, and 99.45%/98.17% for DeepSVDD. The same paper further reports that when all devices were treated as zero-day, DeepSVDD achieved mean training/testing accuracies of 96.03%/74.51%. These results matter for zCamClassifier because they define the system boundary: supervised classification covers known devices, while one-class modeling is required when the device vocabulary is incomplete.

Relative to prior approaches, zCamClassifier is contrasted most directly with iCamInspector, which only used CART and a two-stage classifier. The newer system expands the model set, includes both private and open-source data, and incorporates generalized and zero-day settings. The paper also contrasts its feature regime with methods that are protocol-specific, use DPI, or rely on IP/port information, presenting zCamClassifier as more generalizable and more robust under NAT.

6. Terminological ambiguity, limitations, and broader significance

The term zCamClassifier has a second, conceptually distinct usage in the vision literature. In “Camera Bias in a Fine Grained Classification Task,” the phrase “zCamClassifier effect” is used for the situation in which a CNN becomes a camera-classifier in disguise, exploiting correlations between camera identity and class labels rather than task-relevant semantics (Jackson et al., 2020). In that study, camera classification itself reached very high test accuracy—ResNet34: 99.9%, InceptionV3: 99.8%, VGG16: 97.4%—while, under a Disjoint training regime, the target manufacturer-classification task dropped to approximately random chance ($\approx 50\%$) when camera/label correlations were absent. The implicated cues were high-frequency features, possibly introduced by camera image-processing pipelines, rather than global color statistics, lens deformation, or chromatic aberration.

This separate usage does not refer to the IoT-networking system, but it clarifies a possible misconception: “zCamClassifier” is not inherently a single method family. In network security, it denotes a supervised flow classifier for identifying IoT cameras; in fine-grained vision, it can denote a spurious shortcut based on camera-of-origin artifacts.

For the IoT-networking system itself, the paper acknowledges several limitations. Only 2 spy cameras were evaluated; distinguishing video/non-video streams from multi-service spy IoT devices remains challenging; false positives may require periodic manual inspection in ambiguous cases; and future work may investigate deep models (MLP), improved features, adaptive/online/incremental learning, and large-scale deployment in dynamic IoT environments. These limits indicate that the reported performance is strong within the tested traffic regimes, but that device diversity and service multiplexing remain open problems.