# Almost Secure Wladimir Palant's blog This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Supporting Wayland's XDG activation protocol with Gtk/Glib DevFeed: [Supporting Wayland's XDG activation protocol with Gtk/Glib]() Original publisher: [Read original article]() Author: Wladimir Palant Published: 2026-02-03T10:55:20Z Content type: tutorial Language: en Sources: [Almost Secure]() Topics: [Wayland](), [GTK](), [implementation](), [browser]() Tags: [application](), [browser](), [protocol](), [required](), [using](), [wayland]() ### AI overview This tutorial explains how Wayland's XDG activation protocol transfers focus between applications with consent, and documents its implementation in Gtk/Glib. It covers activation tokens, Gio.AppInfo launch contexts, StartupNotify, and manual environment-variable handling. ### Source excerpt 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 wh ## Backdoors in VStarcam cameras DevFeed: [Backdoors in VStarcam cameras]() Original publisher: [Read original article]() Author: Wladimir Palant Published: 2026-01-07T13:01:48Z Content type: article Language: en Sources: [Almost Secure]() Topics: [Security](), [backdoor](), [passwords](), [P2P](), [Protocol (disambiguation)]() Tags: [backdoor](), [cameras](), [p2p](), [passwords](), [protocol](), [security]() ### AI overview An investigation of VStarcam cameras finds that firmware mechanisms systematically undermine administrator-password protection by leaking passwords and exposing cameras through internet-connected P2P functionality. The article also examines insecure firmware updates delivered over plain HTTP and recommends restricting internet access with a network firewall or using custom firmware. ### Source excerpt 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 (Loo ## Analysis of PPPP "encryption" DevFeed: [Analysis of PPPP "encryption"]() Original publisher: [Read original article]() Author: Wladimir Palant Published: 2026-01-05T15:50:53Z Content type: article Language: en Sources: [Almost Secure]() Topics: [Encryption](), [Cryptography](), [Network](), [Protocol (disambiguation)](), [Algorithms]() Tags: [analysis](), [ascii](), [cryptanalysis](), [encryption](), [lan](), [network](), [pull-request](), [theory]() ### AI overview This analysis examines weaknesses in PPPP "encryption." It explains that app keys are reduced to a four-byte effective key and that the scheme is vulnerable to known-plaintext attacks. For LAN camera discovery when the app and traffic are unknown, the article describes sending all possible encrypted search packets, with at most 157,092 ciphertexts, and notes a pull request to update the device-detection script. ### Source excerpt 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 r ## Unpacking VStarcam Firmware Updates and Examining Their Security Issues DevFeed: [Unpacking VStarcam Firmware Updates and Examining Their Security Issues]() Original publisher: [Read original article]() Author: Wladimir Palant Published: 2025-12-15T14:19:22Z Content type: tutorial Language: en Sources: [Almost Secure]() Topics: [Security](), [Embedded Software Dev](), [Vulnerabilities](), [Compression](), [Zip](), [Python]() Tags: [compression](), [credentials](), [devices](), [firmware](), [hardcoded-credentials](), [python](), [security](), [zip]() ### AI overview This technical article examines VStarcam camera firmware in the context of documented security issues and the lack of clear information about firmware versions, updates, and fixes. It documents multiple firmware branches and update formats, including incremental updates packed as sequences of ZIP files, and describes Python-based methods for unpacking them. ### Source excerpt 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 ## An overview of the PPPP protocol for IoT cameras DevFeed: [An overview of the PPPP protocol for IoT cameras]() Original publisher: [Read original article]() Author: Wladimir Palant Published: 2025-11-05T15:11:36Z Content type: article Language: en Sources: [Almost Secure]() Topics: [Internet of things](), [Protocol (disambiguation)](), [P2P](), [Reverse Engineering](), [Security]() Tags: [cameras](), [firmware](), [iot](), [network](), [p2p](), [protocol](), [reverse-engineering](), [security-research](), [servers](), [tcp]() ### AI overview An overview of the PPPP protocol used primarily by network-connected IoT cameras. The article explains that PPPP relies on central servers while allowing bulk data transfer through direct client-to-device connections, and describes device identifiers, connection establishment, fallback mechanisms, redundant servers, and related protocol research. ### Source excerpt 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 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 ## A look at a P2P camera (LookCam app) DevFeed: [A look at a P2P camera (LookCam app)]() Original publisher: [Read original article]() Author: Wladimir Palant Published: 2025-09-08T13:00:50Z Content type: article Language: en Sources: [Almost Secure]() Topics: [Security](), [Vulnerabilities](), [webcam](), [Encryption](), [P2P](), [Cloud]() Tags: [camera](), [cloud](), [encryption](), [internet](), [p2p](), [security]() ### AI overview A security analysis of internet-connected cameras managed through the LookCam app reports weak access controls, largely unencrypted PPPP communication, exposed cloud uploads, firmware security flaws, and no firmware update mechanism. The findings are presented as applying to LookCam-managed cameras and several related apps, but not LookCamPro devices. ### Source excerpt 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 eas ## Analysis of an advanced malicious Chrome extension DevFeed: [Analysis of an advanced malicious Chrome extension]() Original publisher: [Read original article]() Author: Wladimir Palant Published: 2025-02-03T14:05:37Z Content type: article Language: en Sources: [Almost Secure]() Topics: [Chrome extension](), [Extension](), [Code](), [Authorization]() Tags: [chrome](), [chrome-extension](), [code](), [extension](), [firebase](), [permission](), [permissions](), [run]() ### AI overview A technical analysis examines the Download Manager Integration Checklist Chrome extension and related extensions with malicious functionality. The article describes excessive website access requests, remotely downloaded content, dynamically added rules, and remote code execution through tabs.executeScript. It also reports that an update removed the malicious functionality and cleared extension storage. ### Source excerpt 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 ## Malicious extensions circumvent Google's remote code ban DevFeed: [Malicious extensions circumvent Google's remote code ban]() Original publisher: [Read original article]() Author: Wladimir Palant Published: 2025-01-20T13:32:07Z Content type: opinion Language: en Sources: [Almost Secure]() Topics: [Extension](), [Chrome](), [Security](), [browser](), [API](), [JavaScript]() Tags: [api](), [chrome](), [extensions](), [javascript](), [security](), [web]() ### AI overview The article examines how malicious Chrome extensions circumvent Google's Manifest V3 restrictions on remote code. It discusses techniques including bundled JavaScript interpreters, injected HTML, declarativeNetRequest abuse, new-tab opening, user spying, and anti-debugging protection, with detailed attention to extensions associated with Phoenix Invicta. ### Source excerpt 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 ## The article criticizes Google's moderation of malicious Chrome Web Store extensions DevFeed: [The article criticizes Google's moderation of malicious Chrome Web Store extensions]() Original publisher: [Read original article]() Author: Wladimir Palant Published: 2025-01-13T13:12:43Z Content type: opinion Language: en Sources: [Almost Secure]() Topics: [Google Chrome](), [Browser Extension](), [Google](), [trust]() Tags: [extension](), [google-chrome](), [reports](), [transparency](), [trust]() ### AI overview This opinion article argues that Google's moderation of malicious and problematic Chrome Web Store extensions is ineffective and inconsistent. It describes automated moderation as inadequate, says legitimate add-on authors also face problems, and cites the author's experience reporting harmful extensions. ### Source excerpt 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 ## BIScience: Collecting browsing history under false pretenses DevFeed: [BIScience: Collecting browsing history under false pretenses]() Original publisher: [Read original article]() Author: Anonymous Researcher Published: 2025-01-13T12:57:04Z Content type: article Language: en Sources: [Almost Secure]() Topics: [Browser Extension](), [data](), [SDKs](), [Security]() Tags: [browser](), [data](), [extension](), [most-other-articles-about-add-ons-by-wladimir-palant](), [privacy](), [sdk]() ### AI overview An anonymous researcher examines claims that BIScience and its brands collect users' browsing histories through Chrome extensions, partner extensions, and an SDK, then sell the data through products including Clickstream OS and AdClarity. The article argues that BIScience's public disclosures and privacy practices are inconsistent with its data-collection practices. ### Source excerpt 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. I