AETERNAE AI RESEARCH LLC INDEPENDENT RESEARCH
ÆAETERNAERESEARCH
Sign inRequest access
Æ / PUBLIC MALWARE INTELLIGENCE

Follow the evidence.

Published file metadata, source observations, indicators, and research history in one bounded catalog.

2,400+Reachable catalog records
32 / 100Current catalog page
24Maximum records per page
0Samples downloaded by this page

Feed collection status

Sources represented on this page. Publication and observation dates describe the content; successful batch dates describe local collection. A recent batch does not certify complete coverage or current provider availability.

3 sources: 0 stale, 0 needing attention, 0 paused, 0 unverified.

Review source update dates and status
  • intelligence_src_ac91c8b543dd711de1Recent successful batchLast successful batch: Last attempt:
  • intelligence_src_ad89769b9e64591ab5Recent successful batchLast successful batch: Last attempt:
  • intelligence_src_ae9b2b6332b3346bf0Recent successful batchLast successful batch: Last attempt:

Stale means older than twice the recorded collection interval, with a minimum of one hour; without an interval, the threshold is 24 hours. Cached content remains available while a feed is stale, paused, or unverified.

Clear filters
2,400+ MATCHING RECORDSMETADATA ONLY / SOURCE ATTRIBUTION PRESERVED
REPORT1 SOURCE

v0.76.2

Release 0.76.2

First reported Apr 08, 2026 13:11 UTCCatalog metadata updated Oct 14, 2026 02:06 UTCOpen evidence record
REPORT1 SOURCE

Release 0.76.7

This is a back ported release for 0.76 branch to address some of the CVEs published in the 0.77.2 release cycle.

First reported Aug 10, 2026 11:16 UTCCatalog metadata updated Oct 14, 2026 02:06 UTCOpen evidence record
REPORT1 SOURCE

Release 0.77.3

This release is a bug fix release and addresses the CVEs published in the 0.77.3 release cycle. Detailed change log below (AI generated). Artifact changes Added Azure.Monitor.Upload, which uploads server-side artifact results to an Azure Monitor Log Analytics workspace. Takes a table name, a Data Collection Rule id, and either a client secret or a managed identity. (#4974, 2026-09-04) Server.Utils.BackupDirectory, Server.Utils.BackupGCS and Server.Utils.BackupS3 now emit only ClientId, FlowId and the fields derived from them, rather than all columns. Downstream consumers reading a column that is no longer emitted will need updating. (#4999, 2026-09-04) Windows.Forensics.Prefetch reads VolumeSerialNumber at offset 16 rather than 12. (#5000, 2026-09-09) Windows.Registry.EnableUnsafeClientMailRules reads the target user's NTUser path rather than the collector's OSPath. (#5016, 2026-09-17) Bug fixes The registry accessor parses MULTI_SZ values correctly. (#4972, 2026-08-12) Flow completion now waits for the final FlowStats write. (#4982, 2026-08-25) ArtifactName is read from the cell environment rather than passed as a parameter. (#4990, 2026-08-25) Pool clients report the correct hostname in compressed responses. (#5003, 2026-09-08) Filestore StatFile() reports the uncompressed file size. (#5024, 2026-09-18) The events view in the GUI no longer breaks on artifacts whose name contains a slash, such as Server.Monitor.Health/Prometheus. (#5001, 2026-09-15) A user's notebook view now lists notebooks shared with them, in line with the global notebook view. (#5001, 2026-09-15) enrollments_per_second: -1 disables enrollment instead of being ignored. (#5042, 2026-09-27) Globs with unbalanced alternatives, such as /bin/{ls, now report an error. (#5044, 2026-09-27) Internal Replaced the gRPC connection pool with a direct connection to the frontend. (#5022, 2026-09-18) Closed the gRPC channel from the returned closure. (#5014, 2026-09-14) Moved the client info manager's lock into the record locking system. (#5015, 2026-09-15) Serialised creation of the global eBPF manager. (#5031, 2026-09-20) Refactored the event queues, and split flow storage deletion into its own manager. (#5035, 2026-09-24, #5037, 2026-09-25) Added client event artifacts to the artifact verifier. (#5043, 2026-09-27)

First reported Oct 05, 2026 12:30 UTCCatalog metadata updated Oct 14, 2026 02:06 UTCOpen evidence record
REPORT1 SOURCE

Release 0.77.2

This is a release to address the CVEs published in the 0.77.2 release cycle.

First reported Sep 25, 2026 21:44 UTCCatalog metadata updated Oct 14, 2026 02:06 UTCOpen evidence record
REPORT1 SOURCE

Release 0.77.1

I am very excited to announce that the latest Velociraptor release 0.77.1 is now available. The full release notes are found here If you find any issues please file an issue on GitHub or chat with us on our discord server.

First reported Jun 23, 2026 00:01 UTCCatalog metadata updated Oct 14, 2026 02:06 UTCOpen evidence record
REPORT1 SOURCE

Analysis of an advanced malicious Chrome extension

Two weeks ago I published an article on 63 malicious Chrome extensions. In most cases I could only identify the extensions as malicious. With large parts of their logic being downloaded from some web servers, it wasn’t possible to analyze their functionality in detail. However, for the Download Manager Integration Checklist extension I have all parts of the puzzle now. This article is a technical discussion of its functionality that somebody tried very hard to hide. I was also able to identify a number of related extensions that were missing from my previous article. Update (2025-02-04): An update to Download Manager Integration Checklist extension has been released a day before I published this article, clearly prompted by me asking adindex about this. The update removes the malicious functionality and clears extension storage. Luckily, I’ve saved both the previous version and its storage contents. Contents The problematic extensions “Remote configuration” functionality The code being executed The “session” handling Who is behind these extensions? The problematic extensions Since my previous article I found a bunch more extensions with malicious functionality that is almost identical to Download Manager Integration Checklist. The extension Auto Resolution Quality for YouTube™ does not seem to be malicious (yet?) but shares many remarkable oddities with the other extensions. Name Weekly active users Extension ID Featured Freemybrowser 10,000 bibmocmlcdhadgblaekimealfcnafgfn ✓ AutoHD for Twitch™ 195 didbenpmfaidkhohcliedfmgbepkakam Free simple Adult Blocker with password 1,000 fgfoepffhjiinifbddlalpiamnfkdnim Convert PDF to JPEG/PNG 20,000 fkbmahbmakfabmbbjepgldgodbphahgc Download Manager Integration Checklist 70,000 ghkcpcihdonjljjddkmjccibagkjohpi ✓ Auto Resolution Quality for YouTube™ 223 hdangknebhddccoocjodjkbgbbedeaam Adblock.mx - Adblock for Chrome 1,000 hmaeodbfmgikoddffcfoedogkkiifhfe ✓ Auto Quality for YouTube™ 100,000 iaddfgegjgjelgkanamleadckkpnjpjc Anti phising safer browsing for chrome 7,000 jkokgpghakemlglpcdajghjjgliaamgc ✓ Darktheme for google translate 40,000 nmcamjpjiefpjagnjmkedchjkmedadhc ✓ Additional IOCs: adblock[.]mx adultblocker[.]org autohd[.]org autoresolutionquality[.]com browserguard[.]net freemybrowser[.]com freepdfconversion[.]com internetdownloadmanager[.]top megaxt[.]com darkmode[.]site “Remote configuration” functionality The Download Manager Integration Checklist extension was an odd one on the list in my previous article. It has very minimal functionality: it’s merely supposed to display a set of instructions. This is a task that doesn’t require any permissions at all, yet the extension requests access to all websites and declarativeNetRequest permission. Apparently, nobody noticed this inconsistency so far. Looking at the extension code, there is another oddity. The checklist displayed by the extension is downloaded from Firebase, Google’s online database. Yet there is also a download from https://help.internetdownloadmanager.top/checklist, with the response being handled by this function: async function u(l) { await chrome.storage.local.set({ checklist: l }); await chrome.declarativeNetRequest.updateDynamicRules({ addRules: l.list.add, removeRuleIds: l.list.rm, }); } This is what I flagged as mali

First reported Feb 03, 2025 14:05 UTCCatalog metadata updated Oct 14, 2026 02:04 UTCOpen evidence record
REPORT1 SOURCE

Analysis of PPPP “encryption”

My first article on the PPPP protocol already said everything there was to say about PPPP “encryption”: Keys are static and usually trivial to extract from the app. No matter how long the original key, it is mapped to an effective key that’s merely four bytes long. The “encryption” is extremely susceptible to known-plaintext attacks, usually allowing reconstruction of the effective key from a single encrypted packet. So this thing is completely broken, why look any further? There is at least one situation where you don’t know the app being used so you cannot extract the key and you don’t have any traffic to analyze either. It’s when you are trying to scan your local network for potential hidden cameras. This script will currently only work for cameras using plaintext communication. Other cameras expect a properly encrypted “LAN search” packet and will ignore everything else. How can this be solved without listing all possible keys in the script? By sending all possible ciphertexts of course! TL;DR: What would be completely ridiculous with any reasonable protocol turned out to be quite possible with PPPP. There are at most 157,092 ways in which a “LAN search” packet can be encrypted. I’ve opened a pull request to have the PPPP device detection script adjusted. Note: Cryptanalysis isn’t my topic, I am by no means an expert here. These issues are simply too obvious. Contents Mapping keys to effective keys Redundancies within the effective key ASCII to the rescue How large is n? How many ciphertexts is that? Understanding the response Mapping keys to effective keys The key which is specified as part of the app’s “init string” is not being used for encryption directly. Nor is it being fed into any of the established key stretching algorithms. Instead, a key represented by the byte sequence b1,b2,…,bnb_1, b_2, \ldots, b_n is mapped to four bytes k1,k2,k3,k4k_1, k_2, k_3, k_4 that become the effective key. These bytes are calculated as follows (⌊x⌋\lfloor x \rfloor means rounding down, ⊗\otimes stands for the bitwise XOR operation): k1=(b1+b2+…+bn)mod  256k2=(−b1+−b2+…+−bn)mod  256k3=(⌊b1÷3⌋+⌊b2÷3⌋+…+⌊bn÷3⌋)mod  256k4=b1⊗b2⊗…⊗bn \begin{aligned} k_1 &= (b_1 + b_2 + \ldots + b_n) \mod 256\\ k_2 &= (-b_1 + -b_2 + \ldots + -b_n) \mod 256\\ k_3 &= (\lfloor b_1 \div 3 \rfloor + \lfloor b_2 \div 3 \rfloor + \ldots + \lfloor b_n \div 3 \rfloor) \mod 256\\ k_4 &= b_1 \otimes b_2 \otimes \ldots \otimes b_n \end{aligned} In theory, a 4 byte long effective key means 2564=4,294,967,296256^4 = 4{,}294{,}967{,}296 possible values. But that would only be the case if these bytes were independent of each other. Redundancies within the effective key Of course the bytes of the effective key are not independent. This is most obvious with k2k_2 which is completely determined by k1k_1: k2=(−b1+−b2+…+−bn)mod  256=−(b1+b2+…+bn)mod  256=−k1mod  256 \begin{aligned} k_2 &= (-b_1 + -b_2 + \ldots + -b_n) \mod 256\\ &= -(b_1 + b_2 + \ldots + b_n) \mod 256\\ &= -k_1 \mod 256 \end{aligned} This means that we can ignore k2k_2, bringing the number of possible effective keys down to 2563=16,777,216256^3 = 16{,}777{,}216. Now let’s have a look at the relationship between k1k_1 and k4k_4. Addition and bitwise XOR operations are very similar, the latter merely ignores carry. This difference affects all the bits of the result but the lowest one, no carry to be considered here. This means that the lowest bits of k1k_1 and k4k_4 are always identical. So k4k_4 has only 128 possible values for any value of k1k_1, bringing the total number of effective keys down to 256⋅256⋅128=8,388,608256 \cdot 256 \cdot 128 = 8{,}388{,}608. And that’s how far we can get considering only redundancies. It can be shown that a key can be constructed resulting in any combination of k1k_1 a

First reported Jan 05, 2026 15:50 UTCCatalog metadata updated Oct 14, 2026 02:04 UTCOpen evidence record
REPORT1 SOURCE

A look at a P2P camera (LookCam app)

I’ve got my hands on an internet-connected camera and decided to take a closer look, having already read about security issues with similar cameras. What I found far exceeded my expectations: fake access controls, bogus protocol encryption, completely unprotected cloud uploads and firmware riddled with security flaws. One could even say that these cameras are Murphy’s Law turned solid: everything that could be done wrong has been done wrong here. While there is considerable prior research on these and similar cameras that outlines some of the flaws, I felt that the combination of severe flaws is reason enough to publish an article of my own. My findings should apply to any camera that can be managed via the LookCam app. This includes cameras meant to be used with less popular apps of the same developer: tcam, CloudWayCam, VDP, AIBoxcam, IP System. Note that the LookCamPro app, while visually very similar, is technically quite different. It also uses the PPPP protocol for low-level communication but otherwise doesn’t seem to be related, and the corresponding devices are unlikely to suffer from the same flaws. There seems to be little chance that things will improve with these cameras. I have no way of contacting either the hardware vendors or the developers behind the LookCam app. In fact, it looks like masking their identity was done on purpose here. But even if I could contact them, the cameras lack an update mechanism for their firmware. So fixing the devices already sold is impossible. I have no way of knowing how many of these cameras exist. The LookCam app is currently listed with almost 1.5 million downloads on Google Play however. An iPhone and a Windows version of the app are also available but no public statistics exist here. Contents The highlights The hardware The LookCam app The PPPP protocol The basics The “encryption” The threat model The firmware The cloud How safe are device IDs? Recommendations Further reading The highlights The camera cannot be easily isolated from unauthorized access. It can either function as a WiFi access point, but setting a WiFi password isn’t possible. Or it can connect to an existing network, and then it will insist on being connected to the internet. If internet access is removed the camera will go into a reboot loop. So you have the choice of letting anybody in the vicinity access this camera or allowing it to be accessed from the internet. The communication of this camera is largely unencrypted. The underlying PPPP protocol supports “encryption” which is better described as obfuscation, but the LookCam app almost never makes use of it. Not that it would be of much help, the proprietary encryption algorithms being developed without any understanding of cryptography. These rely on static encryption keys which are trivially extracted from the app but should be easy enough to deduce even from merely observing some traffic. The camera firmware is riddled with buffer overflow issues which should be trivial to turn into arbitrary code execution. Protection mechanisms like DEP or ASLR might have been a hurdle but these are disabled. And while the app allows you to set an access password, the firmware doesn’t really enforce it. So access without knowing the password can be accomplished simply by modifying the app to skip the password checks. The only thing preventing complete compromise of any camera is the “secret” device ID which has to be known in order to establish a connection. And by “secret” I mean that device IDs can generally be enumerated but they are “secured” with a five letter verification code. Unlike with some similar cameras, the algorithm used to generate the verification code isn’t public knowledge yet. So somebody wishing to compromise as many cameras as possible would need to either guess the algorithm or guess the verification codes by trying ou

First reported Sep 08, 2025 13:00 UTCCatalog metadata updated Oct 14, 2026 02:04 UTCOpen evidence record
REPORT1 SOURCE

An overview of the PPPP protocol for IoT cameras

My previous article on IoT “P2P” cameras couldn’t go into much detail on the PPPP protocol. However, there is already lots of security research on and around that protocol, and I have a feeling that there is way more to come. There are pieces of information on the protocol scattered throughout the web, yet every one approaching from a very specific narrow angle. This is my attempt at creating an overview so that other people don’t need to start from scratch. While the protocol can in principle be used by any kind of device, it is mostly being used for network-connected cameras. It isn’t really peer-to-peer as advertised but rather relies on central servers, yet the protocol allows to transfer the bulk of data via a direct connection between the client and the device. It’s hard to tell how many users there are but there are lots of apps, I’m sure that I haven’t found all of them. There are other protocols with similar approaches being used for the same goal. One is used by ThroughTek’s Kalay Platform which has the interesting string “Charlie is the designer of P2P!!” in its codebase (32 bytes long, seems to be used as “encryption” key for some non-critical functionality). I recognize both the name and the “handwriting,” it looks like PPPP protocol designer found a new home here. Yet PPPP seems to be still more popular than the competition, thanks to it being the protocol of choice for cheap low-end cameras. Disclaimer: Most of the information below has been acquired by analyzing public information as well as reverse engineering applications and firmware, not by observing live systems. Consequently, there can be misinterpretations. Contents The general design The network ports The device IDs The protocol variants CS2 Network Yi Technology AJCloud iLnk HLP2P “Encryption” “Secret” messages Applications Changelog The general design The protocol’s goal is to serve as a drop-in replacement for TCP. Rather than establish a connection to a known IP address (or a name to be resolved via DNS), clients connect to a device identifier. The abstraction is supposed to hide away how the device is located (via a server that keeps track of its IP address), how a direct communication channel is established (via UDP hole punching) or when one of multiple possible fallback scenarios is being used because direct communication is not possible. The protocol is meant to be resilient, so there are usually three redundant servers handling each network. When a device or client needs to contact a server, it sends the same message to all of them and doesn’t care which one will reply. Note: In this article “network” generally means a PPPP network, i.e. a set of servers and the devices connecting to them. While client applications typically support multiple networks, devices are always associated with a specific one determined by their device prefix. For what is meant to be a transport layer protocol, PPPP has some serious complexity issues. It encompasses device discovery on the LAN via UDP broadcasts, UDP communication between device/client and the server and a number of (not exactly trivial) fallback solutions. It also features multiple “encryption” algorithms which are more correctly described as obfuscators and network management functionality. Paul Marrapese’s Wireshark Dissector provides an overview of the messages used by the protocol. While it isn’t quite complete, a look into the pppp.fdesc file shows roughly 70 different message types. It’s hard to tell how all these messages play together as the protocol has not been designed as a state machine. The protocol implementation uses its previous actions as context to interpret incoming messages, but it has little indication as to which messages are expected when. Observing a running system is essential to understanding this protocol. The compl

First reported Nov 05, 2025 15:11 UTCCatalog metadata updated Oct 14, 2026 02:04 UTCOpen evidence record
REPORT1 SOURCE

Supporting Wayland’s XDG activation protocol with Gtk/Glib

One of the biggest sore points with Wayland is its focus stealing protection. The idea is good: an application should not be able to bring itself into focus at an unexpected time, only when the currently active application allows it. Support is still lacking however, which might also be due to Gtk/Glib implementing the required XDG activation protocol but not really documenting it. It took me a bit of time to figure this out without any public information, this article will hopefully make things easier for other people. Contents How the XDG activation protocol works State of implementation in Gtk/Glib Starting applications via Gio.AppInfo Starting applications by other means How the XDG activation protocol works The main idea behind the XDG activation protocol is that focus transfer from one application to another requires consent. With X11 a file manager could just launch the browser for an HTML file and the browser would immediately take focus, even if that browser was already running. With Wayland the file manager has to indicate that the browser is allowed to take focus. It does that by giving the browser its XDG activation token, typically via XDG_ACTIVATION_TOKEN environment variable. The browser can then use that activation token to prove consent and take focus. For this to work the protocol has to be supported on both ends: the file manager must know how to retrieve an activation token and pass it on via XDG_ACTIVATION_TOKEN environment variable, and the browser has to know how to use that token. State of implementation in Gtk/Glib The receiving side has been implemented in Gtk with merge request 7118 and is available starting with Gtk 4.14.6 and 4.15.1. This is the unproblematic part: it is handled automatically and doesn’t require the application developer to change anything. The sending side has been implemented in Gtk with merge request 3502 and Glib with merge request 3090, so it is available starting with Gtk 4.10.0 and Glib 2.75.1. This is the part which might require some changes to the application – changes that I couldn’t find documented anywhere. Starting applications via Gio.AppInfo When a Gtk-based file manager wants to open an HTML file, this usually involves Gio.AppInfo and g_app_info_launch or similar: GAppInfo* app_info = g_app_info_get_default_for_type("text/html", TRUE); GList *list = NULL; list = g_list_append(list, "https://example.com/"); GdkDisplay *display = gdk_display_get_default(); GdkAppLaunchContext* context = (display ? gdk_display_get_app_launch_context(display) : NULL); g_app_info_launch_uris(app_info, list, G_APP_LAUNCH_CONTEXT(context), NULL); g_list_free(list); This should normally transfer focus to the browser automatically. That app launch context parameter is important however, you cannot omit it. Also, this will only work if the desktop file corresponding to the AppInfo has the StartupNotify key set – the Gtk developers decided to merge the handling of X11 startup notifications and XDG activations. Starting applications by other means But what if you are using something like execve function to start applications? You can still set XDG_ACTIVATION_TOKEN environment variable manually. It’s important to know however that the token has to be retrieved via g_app_launch_context_get_startup_notify_id (please pardon my C): char** extend_env(char** env, char* value) { int env_size = 0; while (env[env_size]) env_size++; char **new_env = malloc((env_size + 2) * sizeof(char*)); memcpy(new_env, env, env_size * sizeof(char*)); new_env[env_size++] = value; new_env[env_size++] = NULL; return new_env; } char *argv[] = {"/usr/bin/firefox", "https://example.com/", NULL}; char *default_env[] = {NULL}; char **env = default_env; bool should_free_env = FALSE; GdkDisplay *display = gdk_display_get_default(); if (display) { GdkAppLaunchContext* context = gdk_display_get_app_launch_context(display); env

First reported Feb 03, 2026 10:55 UTCCatalog metadata updated Oct 14, 2026 02:04 UTCOpen evidence record
REPORT1 SOURCE

Malicious extensions circumvent Google’s remote code ban

As noted last week I consider it highly problematic that Google for a long time allowed extensions to run code they downloaded from some web server, an approach that Mozilla prohibited long before Google even introduced extensions to their browser. For years this has been an easy way for malicious extensions to hide their functionality. When Google finally changed their mind, it wasn’t in form of a policy but rather a technical change introduced with Manifest V3. As with most things about Manifest V3, these changes are meant for well-behaving extensions where they in fact improve security. As readers of this blog probably know, those who want to find loopholes will find them: I’ve already written about the Honey extension bundling its own JavaScript interpreter and malicious extensions essentially creating their own programming language. This article looks into more approaches I found used by malicious extensions in Chrome Web Store. And maybe Google will decide to prohibit remote code as a policy after all. Update (2025-01-20): Added two extensions to the bonus section. Also indicated in the tables which extensions are currently featured in Chrome Web Store. Update (2025-01-21): Got a sample of the malicious configurations for Phoenix Invicta extensions. Added a section describing it and removed “But what do these configurations actually do” section. Also added a bunch more domains to the IOCs section. Update (2025-01-28): Corrected the “Netflix Party” section, Flipshope extension isn’t malicious after all. Also removed the attribution subsection here. Contents Summary of the findings Phoenix Invicta Injecting HTML code into web pages Abusing declarativeNetRequest API Opening new tabs The scheme summarized The payload Who is behind these extensions? The affected extensions Netflix Party Spying on the users The bogus rule processing The affected extensions Sweet VPN Anti-debugging protection Guessing further functionality The affected extensions Bonus section: more malicious extensions The affected extensions IOCs Summary of the findings This article originally started as an investigation into Phoenix Invicta Inc. Consequently, this is the best researched part of it. While I could attribute only 14 extensions with rather meager user numbers to Phoenix Invicta, that’s likely because they’ve only started recently. I could find a large number of domain names, most of which aren’t currently being used by any extensions. A few are associated with extensions that have been removed from Chrome Web Store but most seem to be reserved for future use. It can be assumed that these extensions are meant to inject ads into web pages, yet Phoenix Invicta clearly put some thought into plausible deniability. They can always claim their execution of remote code to be a bug in their otherwise perfectly legitimate extension functionality. So it will be interesting to see how Google will deal with these extensions, lacking (to my knowledge) any policies that apply here. The malicious intent is a bit more obvious with Netflix Party and related extensions. This shouldn’t really come as a surprise to Google: the most popular extension of the group was a topic on this blog back in 2023, and a year before that McAfee already flagged two extensions of the group as malicious. Yet here we are, and these extensions are still capable of spying, affiliate fraud and cookie stuffing as described by McAfee. If anything, their potential to do damage has only increased. Finally, the group of extensions around Sweet VPN is the most obviously malicious one. To be fair, what these extensions do is probably best described as obfuscation rather than remote code execution. Still, they download extensive instructions from th

First reported Jan 20, 2025 13:32 UTCCatalog metadata updated Oct 14, 2026 02:04 UTCOpen evidence record
REPORT1 SOURCE

Unpacking VStarcam firmware for fun and profit

One important player in the PPPP protocol business is VStarcam. At the very least they’ve already accumulated an impressive portfolio of security issues. Like exposing system configuration including access password unprotected in the Web UI (discovered by multiple people independently from the look of it). Or the open telnet port accepting hardcoded credentials (definitely discovered by lots of people independently). In fact, these cameras have been seen used as part of a botnet, likely thanks to some documented vulnerabilities in their user interface. Is that a thing of the past? Are there updates fixing these issues? Which devices can be updated? These questions are surprisingly hard to answer. I found zero information on VStarcam firmware versions, available updates or security fixes. In fact, it doesn’t look like they ever even acknowledged learning about the existence of these vulnerabilities. No way around downloading these firmware updates and having a look for myself. With surprising results. First of all: there are lots of firmware updates. It seems that VStarcam accumulated a huge number of firmware branches. And even though not all of them even have an active or downloadable update, the number of currently available updates goes into hundreds. And the other aspect: the variety of update formats is staggering, and often enough standard tools like binwalk aren’t too useful. It took some time figuring out how to unpack some of the more obscure variants, so I’m documenting it all here. Warning: Lots of quick-and-dirty Python code ahead. Minimal error checking, use at your own risk! Contents ZIP-packed incremental updates VStarcam pack system VeePai updates Ingenic updates LZO-compressed partitions Ingenic’s jzlzma compression Exotic Ingenic update But what about these security issues? ZIP-packed incremental updates These incremental updates don’t contain an image of the entire system, only the files that need updating. They always contain the main application however, which is what matters. Recognizing this format is easy, the files start with the 32 bytes www.object-camera.com.by.hongzx. or www.veepai.com/design.rock-peng. (the old and the new variant respectively). The files end with the same string in reverse order. Everything in between is a sequence of ZIP files, with each file packed in its own ZIP file. Each ZIP file is preceded by a 140 byte header: 64 byte directory name, 64 byte file name, 4 byte ZIP file size, 4 byte timestamp of some kind and 4 zero bytes. While binwalk can handle this format, having each file extracted into a separate directory structure isn’t optimal. A simple Python script can do better: #!/usr/bin/env python3 import datetime import io import struct import os import sys import zipfile def unpack_zip_stream(input: io.BytesIO, targetdir: str) -> None: targetdir = os.path.normpath(targetdir) while True: header = input.read(0x8c) if len(header) < 0x8c: break _, _, size, _, _ = struct.unpack('<64s64sLLL', header) data = input.read(size) with zipfile.ZipFile(io.BytesIO(data)) as archive: for member in archive.infolist(): path = os.path.normpath( os.path.join(targetdir, member.filename) ) if os.path.commonprefix((path, targetdir)) != targetdir: raise Exception('Invalid target path', path) try: os.makedirs(os.path.dirname(path)) except FileExistsError: pass with archive.open(member) as member_input: data = member_input.read() with open(path, 'wb') as output: output.write(data) time = datetime.datetime(*member.date_time).timestamp() os.ut

First reported Dec 15, 2025 14:19 UTCCatalog metadata updated Oct 14, 2026 02:04 UTCOpen evidence record
REPORT1 SOURCE

Chrome Web Store is a mess

Let’s make one thing clear first: I’m not singling out Google’s handling of problematic and malicious browser extensions because it is worse than Microsoft’s for example. No, Microsoft is probably even worse but I never bothered finding out. That’s because Microsoft Edge doesn’t matter, its market share is too small. Google Chrome on the other hand is used by around 90% of the users world-wide, and one would expect Google to take their responsibility to protect its users very seriously, right? After all, browser extensions are one selling point of Google Chrome, so certainly Google would make sure they are safe? Unfortunately, my experience reporting numerous malicious or otherwise problematic browser extensions speaks otherwise. Google appears to take the “least effort required” approach towards moderating Chrome Web Store. Their attempts to automate all things moderation do little to deter malicious actors, all while creating considerable issues for authors of legitimate add-ons. Even when reports reach Google’s human moderation team, the actions taken are inconsistent, and Google generally shies away from taking decisive actions against established businesses. As a result, for a decade my recommendation for Chrome users has been to stay away from Chrome Web Store if possible. Whenever extensions are absolutely necessary, it should be known who is developing them, why, and how the development is being funded. Just installing some extension from Chrome Web Store, including those recommended by Google or “featured,” is very likely to result in your browsing data being sold or worse. Google employees will certainly disagree with me. Sadly, much of it is organizational blindness. I am certain that you meant it well and that you did many innovative things to make it work. But looking at it from the outside, it’s the result that matters. And for the end users the result is a huge (and rather dangerous) mess. Contents Some recent examples The reporting process Chrome Web Store and their spam issue Can extension reviews be trusted? The “featured” extensions How did Google get into this mess? What could Google do? Some recent examples Five years ago I discovered that Avast browser extensions were spying on their users. Mozilla and Opera disabled the extension listings immediately after I reported it to them. Google on the other hand took two weeks where they supposedly discussed their policies internally. The result of that discussion was eventually their “no surprises” policy: Building and maintaining user trust in the Chrome Web Store is paramount, which means we set a high bar for developer transparency. All functionalities of extensions should be clearly disclosed to the user, with no surprises. This means we will remove extensions which appear to deceive or mislead users, enable dishonest behavior, or utilize clickbaity functionality to artificially grow their distribution. So when dishonest behavior from extensions is reported today, Google should act immediately and decisively, right? Let’s take a look at two examples that came up in the past few months. In October I wrote about the refoorest extension deceiving its users. I could conclusively prove that Colibri Hero, the company behind refoorest, deceives their users on the number of trees they supposedly plant, incentivizing users into installing with empty promises. In fact, there is strong indication that the company never even donated for planting trees beyond a rather modest one-time donation. Google got my report and dealt with it. What kind of action did they take? That’s a very good question that Google won’t answer. But refoorest is still available from Chrome Web Store, it is still “featured” and it still advertises the very same completely made up numbers of trees they supposedly planted. Google even advertises for the extension, listing it in the “Editors’ Picks extensions

First reported Jan 13, 2025 13:12 UTCCatalog metadata updated Oct 14, 2026 02:04 UTCOpen evidence record
REPORT1 SOURCE

BIScience: Collecting browsing history under false pretenses

This is a guest post by a researcher who wants to remain anonymous. You can contact the author via email. Recently, John Tuckner of Secure Annex and Wladimir Palant published great research about how BIScience and its various brands collect user data. This inspired us to publish part of our ongoing research to help the extension ecosystem be safer from bad actors. This post details what BIScience does with the collected data and how their public disclosures are inconsistent with actual practices, based on evidence compiled over several years. Screenshot of claims on the BIScience website Contents Who is BIScience? BIScience collects data from millions of users BIScience buys data from partner third-party extensions BIScience receives raw data, not anonymized data Misleading CWS policies compliance BIScience extensions exception claims Partner extensions exception claims, guided by BIScience BIScience SDK Unnecessary features Misleading privacy policy disclosures Misleading user consent Our hope for the future Related reading IOCs Who is BIScience? BIScience is a long-established data broker that owns multiple extensions in the Chrome Web Store (CWS) that collect clickstream data under false pretenses. They also provide a software development kit (SDK) to partner third-party extension developers to collect and sell clickstream data from users, again under false pretenses. This SDK will send data to sclpfybn.com and other endpoints controlled by BIScience. “Clickstream data” is an analytics industry term for “browsing history”. It consists of every URL users visit as they browse the web. According to their website, BIScience “provides the deepest digital & behavioral data intelligence to market research companies, brands, publishers & investment firms”. They sell clickstream data through their Clickstream OS product and sell derived data under other product names. BIScience owns AdClarity. They provide “advertising intelligence” for companies to monitor competitors. In other words, they have a large database of ads observed across the web. They use data collected from services operated by BIScience and third parties they partner with. BIScience also owns Urban Cyber Security. They provide VPN, ad blocking, and safe browsing services under various names: Urban VPN, 1ClickVPN, Urban Browser Guard, Urban Safe Browsing, and Urban Ad Blocker. Urban collects user browsing history from these services, which is then sold by BIScience to third parties through Clickstream OS, AdClarity, and other products. BIScience also owned GeoSurf, a residential proxy service that shut down in December 2023. BIScience collects data from millions of users BIScience is a huge player in the browser extension ecosystem, based on their own claims and our observed activity. They also collect data from other sources, including Windows apps and Android apps that spy on other running apps. The websites of BIScience and AdClarity make the following claims: They collect data from 25 million users, over 250 million user events per day, 400 million unique domains They process 4.5 petabytes of data every month They are the “largest human panel based ad intelligence platform” These numbers are the most recent figures from all pages on their websites, not only the home pages. They have consistently risen over the years based on archived website data, so it’s safe to say any lower figures on their website are outdated. BIScience buys data from partner third-party extensions BIScience proactively contacts extension developers to buy clickstream data. They claim to buy this data in anonymized form, and in a manner compliant with Chrome Web Store policies. Both claims are demonstrably false. Several third-part

First reported Jan 13, 2025 12:57 UTCCatalog metadata updated Oct 14, 2026 02:04 UTCOpen evidence record
REPORT1 SOURCE

Backdoors in VStarcam cameras

VStarcam is an important brand of cameras based on the PPPP protocol. Unlike the LookCam cameras I looked into earlier, these are often being positioned as security cameras. And they in fact do a few things better like… well, like having a mostly working authentication mechanism. In order to access the camera one has to know its administrator password. So much for the theory. When I looked into the firmware of the cameras I discovered a surprising development: over the past years this protection has been systematically undermined. Various mechanisms have been added that leak the access password, and in several cases these cannot be explained as accidents. The overall tendency is clear: for some reason VStarcam really wants to have access to their customer’s passwords. A reminder: “P2P” functionality based on the PPPP protocol means that these cameras will always communicate with and be accessible from the internet, even when located on a home network behind NAT. Short of installing a custom firmware this can only addressed by configuring the network firewall to deny internet access. Contents How to recognize affected cameras Downloading the firmware Caveats of this survey VStarcam’s authentication approach Endpoint protection Unauthenticated log access Explicit password leaking via logs Log uploading Password-leaking backdoor Establishing a timeline The impact Coordinated disclosure attempt Recommendations How to recognize affected cameras Not every VStarcam camera has “VStarcam” printed on the side. I have seen reports of VStarcam cameras being sold under the brand names Besder, MVPower, AOMG, OUSKI, and there are probably more. Most cameras should be recognizable by the app used to manage them. Any camera managed by one of these apps should be a VStarcam camera: Eye4, EyeCloud, FEC Smart Home, HOTKam, O-KAM Pro, PnPCam, VeePai, VeeRecon, Veesky, VKAM, VsCam, VStarcam Ultra. Downloading the firmware VStarcam cameras have a mechanism to deliver firmware updates (LookCam cameras prove that this shouldn’t be taken for granted). The app managing the camera will request update information from an address like http://api4.eye4.cn:808/firmware/1.2.3.4/EN where 1.2.3.4 is the firmware version. If a firmware update is available the response will contain a download server and a download path. The app sends these to the device which then downloads and installs the updated firmware. Both requests are performed over plain HTTP and this is already the first issue. If an attacker can produce a manipulated response either on the network that the app or the device are connected to they will be able to install a malicious update on the camera. The former is particularly problematic, as the camera owner may connect to an open WiFi or similarly untrusted networks while being out. The last part of a firmware version is a build number which is ignored for the update requests. The first part is a vendor ID where only a few options seem relevant (I checked 10, 48 and 66). The rest of the version number can be easily enumerated. Many firmware branches don’t have an active update, and when they do some updates won’t download because the servers in question appear no longer operational. Still, I found 380 updates this way. I managed to unpack all but one of these updates. Firmware version 10.1.110.2 wasn’t for a camera but rather some device with an HDMI connector and without any P2P functionality – probably a Network Video Recorder (NVR). Firmware version 10.121.160.42 wasn’t using PPPP but something called NHEP2P and an entirely different application-level protocol. Ten updates weren’t updating the camera application but only the base system. This left 367 firmware versions for this investigation. Caveats of this survey I do not own any VStarcam hardware, nor would it be feasible to investigate hundreds of different firmware versions with real hardware. The

First reported Jan 07, 2026 13:01 UTCCatalog metadata updated Oct 14, 2026 02:04 UTCOpen evidence record
REPORT1 SOURCE

Data embassies and sovereign dispersion

Sovereign dispersion offers IT leaders an early look at how the residency-versus-resilience trade-off could be resolved at scale, before they're forced to make the same call with their own data

First reported Sep 22, 2026 07:00 UTCCatalog metadata updated Oct 14, 2026 02:02 UTCOpen evidence record

The public shared-host view reaches the newest 2,400 matching records. Narrow the filters or search an exact MD5, SHA-1, or SHA-256 value to reach a specific record.

A filename, label, or report mention alone does not establish maliciousness. Observation dates describe cited sources; collection dates describe this local metadata catalog. No malware samples are stored, fetched, or executed by these pages.