Open Source Signal #129 / Сигнал відкритих джерел

Editorial frame

What this is: A weekly tool radar for public-interest OSINT. This week focuses on reproducibility: candidate generation, capture, parsing and validation are useful when the analyst can retain the source, intermediate steps, tool version and uncertainty.

What this is not: Doxxing, stalking, private-person deanonymization, credential hunting, unauthorised access, live targeting, automated truth verdicts, or treating a tool score, cryptographic credential, change highlight or geolocation candidate as a final factual conclusion.

Rubric map

🧭 Tool of the Week

🧾 Evidence Capture

🔐 Content Provenance

🧪 Forensic Inspection

🧱 Tool Supply Chain

🛰️ Change Detection

🧭Tool of the WeekІнструмент тижня

#01

geo-sleuth makes an agent show the evidence chain behind an image-geolocation claim

Source: geo-sleuth / GitHub · Repository checked 10 October 2026; pushed 10 October 2026

What happened

geo-sleuth is an Agent Skill for Claude Code, Codex, Cursor, Gemini CLI, OpenCode and GitHub Copilot that searches for where a photo was taken using OpenStreetMap geometry, elevation skylines, satellite tiles, street-level imagery and other ranked evidence. Its current method requires conclusions to point to the clue used, the command run and the file produced. The project separates scripted search and ranking from model judgment, and returns coordinates with an error radius, camera heading, evidence image and graded confidence.

Why it matters

Agentic geolocation becomes much easier to audit when the model cannot quietly replace a weak clue with intuition. The important design choice is traceability: another investigator can inspect what was observed, which candidate set was searched, what files were produced and where uncertainty remained.

How to use it

Treat the returned location as a candidate until independent map, terrain, street-level or dated-imagery checks confirm it. Preserve the clue list, commands, candidate-board state, generated evidence files and reported error radius with the case record.

Limits

The project does not yet publish an end-to-end blind-test accuracy number, and coverage quality varies by data source and place. Its own responsible-use rule says to analyse your own photos or images you have permission to analyse, not to find people who have not agreed to be found.

geo-sleuth змушує агента показувати доказовий ланцюг за твердженням про геолокацію зображення

Джерело: geo-sleuth / GitHub · Репозиторій перевірено 10 жовтня 2026; оновлено 10 жовтня 2026

Що сталося

geo-sleuth — Agent Skill для Claude Code, Codex, Cursor, Gemini CLI, OpenCode та GitHub Copilot, який шукає місце зйомки фото через геометрію OpenStreetMap, профілі рельєфу, satellite tiles, street-level imagery та інші ранжовані докази. Поточна методика вимагає, щоб висновок посилався на використану ознаку, виконану команду та створений файл. Проєкт розділяє scripted search і ranking від модельного judgment та повертає координати з радіусом похибки, напрямком камери, evidence image і graded confidence.

Чому це важливо

Агентну геолокацію значно легше аудіювати, коли модель не може непомітно замінити слабку ознаку інтуїцією. Ключова риса тут — traceability: інший дослідник може перевірити, що саме було помічено, який набір кандидатів перевірявся, які файли створено і де залишилася невизначеність.

Як це застосувати

Сприймайте повернуту локацію як кандидата, доки її незалежно не підтвердять карти, рельєф, street-level imagery або датовані знімки. Зберігайте список ознак, команди, стан candidate board, створені evidence files і заявлений радіус похибки разом із матеріалами кейсу.

Обмеження

Проєкт поки не публікує наскрізний показник точності на blind-test наборі, а якість покриття залежить від джерела даних і місця. Власне responsible-use правило проєкту радить аналізувати свої фото або зображення, на аналіз яких є дозвіл, а не шукати людей, які не погоджувалися бути знайденими.

tool-of-weekgeo-sleuthgeolocationagent-skillsopenstreetmapevidence-tracereproducibility

🧾Evidence CaptureФіксація доказів

#02

Birdbrain turns a captured web page into a locally verifiable evidence package

Source: Birdbrain / GitHub · Repository checked 10 October 2026; pushed 10 October 2026

What happened

Birdbrain is a local-first open-source desktop app with a Chromium extension for investigators and journalists. A capture stores MHTML, a full-page screenshot and extracted page text in a local case folder. The app hashes stored bytes with SHA-256, appends a signed entry to a hash-chained manifest and requests an RFC 3161 timestamp token for the content hash. Exported packages include a VERIFY.md procedure using standard command-line tools so the recipient does not need Birdbrain installed.

Why it matters

A screenshot can document what an analyst saw, but it is a weak chain-of-custody object by itself. Birdbrain's useful contribution is to package capture time, multiple representations, hashes, manifest continuity and an external timestamp into a record that can be checked later.

How to use it

Capture important public sources before analysis, keep the original URL and capture metadata, and export the evidence package separately from analytical notes. Verify the manifest and hashes when material moves between investigators or systems.

Limits

Birdbrain is public beta software with one maintainer. Its own documentation is explicit that a verified chain shows the stored record was not changed without the signing key; it does not prove that the captured page itself was genuine or truthful, and the workflow has not been tested by a court.

Birdbrain перетворює зафіксовану вебсторінку на локально перевірюваний evidence package

Джерело: Birdbrain / GitHub · Репозиторій перевірено 10 жовтня 2026; оновлено 10 жовтня 2026

Що сталося

Birdbrain — local-first open-source desktop-застосунок із Chromium extension для дослідників і журналістів. Capture зберігає MHTML, full-page screenshot і витягнутий текст сторінки в локальній папці кейсу. Застосунок рахує SHA-256 для збережених байтів, додає підписаний запис до hash-chained manifest і запитує RFC 3161 timestamp token для content hash. Експортований пакет містить VERIFY.md із перевіркою стандартними CLI-інструментами, тому одержувачу не потрібен встановлений Birdbrain.

Чому це важливо

Screenshot може показати, що саме бачив аналітик, але сам по собі це слабкий chain-of-custody об'єкт. Корисність Birdbrain у тому, що він поєднує час фіксації, кілька представлень сторінки, hashes, цілісність manifest і зовнішній timestamp у запис, який можна перевірити пізніше.

Як це застосувати

Фіксуйте важливі публічні джерела до аналізу, зберігайте оригінальний URL і capture metadata та експортуйте evidence package окремо від аналітичних нотаток. Перевіряйте manifest і hashes, коли матеріал передається між дослідниками або системами.

Обмеження

Birdbrain перебуває у public beta й має одного maintainer. Документація прямо зазначає: verified chain показує, що збережений запис не змінювали без signing key; це не доводить, що сама сторінка була справжньою або правдивою, і workflow не проходив судової перевірки.

evidence-capturebirdbrainweb-archivingsha256rfc3161chain-of-custodylocal-first

🔐Content ProvenanceПоходження контенту

#03

C2PA Conformance Tool exports the verifier state as a reproducible report instead of a green checkmark

Source: Content Authenticity Initiative / GitHub · Repository checked 10 October 2026; updated 9 October 2026

What happened

The Content Authenticity Initiative's C2PA Conformance Tool validates C2PA manifests locally in the browser through a c2pa-rs WebAssembly build. It checks signatures against official and interim trust lists, exposes manifest claims, ingredients, validation status and a provenance tree, supports sidecar .c2pa files, and exports raw crJSON. Each downloaded report includes the exact conformance-tool git commit and build date that produced it.

Why it matters

For reproducible verification, 'Content Credentials present' is not enough. A structured report preserves separate states for cryptographic integrity, certificate trust, assertions, ingredients and the verifier version, making later review possible when trust lists or software change.

How to use it

Save the source media, exported crJSON report and verifier commit together. Record signer claims as attributed provenance evidence, then verify the depicted event, time and location independently.

Limits

A valid C2PA chain does not make the underlying content true, and absence of credentials does not make an asset false. Trust-list status, file integrity, signer claims and factual verification remain separate questions.

C2PA Conformance Tool експортує стан перевірки як відтворюваний report замість зеленої галочки

Джерело: Content Authenticity Initiative / GitHub · Репозиторій перевірено 10 жовтня 2026; оновлено 9 жовтня 2026

Що сталося

C2PA Conformance Tool від Content Authenticity Initiative перевіряє C2PA manifests локально в браузері через WebAssembly-збірку c2pa-rs. Він перевіряє signatures за офіційним та interim trust lists, показує manifest claims, ingredients, validation status і provenance tree, підтримує sidecar-файли .c2pa та експортує raw crJSON. Кожен завантажений report містить точний git commit і build date версії conformance tool, яка його створила.

Чому це важливо

Для відтворюваної верифікації недостатньо повідомлення «Content Credentials present». Структурований report окремо зберігає стани cryptographic integrity, certificate trust, assertions, ingredients і версію verifier, що дозволяє повторну перевірку після зміни trust lists або програмного забезпечення.

Як це застосувати

Зберігайте вихідний media-файл, експортований crJSON report і commit verifier разом. Фіксуйте signer claims як атрибутований provenance evidence, а подію, час і місце на зображенні перевіряйте незалежно.

Обмеження

Валідний C2PA chain не робить зміст автоматично правдивим, а відсутність credentials не робить файл фальшивим. Trust-list status, цілісність файлу, signer claims і фактична верифікація залишаються окремими питаннями.

c2pacontent-provenancecontent-credentialscrjsonwasmreproducibilitytrust-lists

🧪Forensic InspectionForensic-аналіз

#04

Crush keeps complex evidence sources read-only and links parsed values back to their bytes

Source: Crush Forensics / GitHub · Repository checked 10 October 2026; pushed 10 October 2026

What happened

Crush is an open-source desktop forensic workbench for archives, mobile backups, disk images, logical evidence containers, databases, structured data, media and documents. It opens many sources without extracting or mounting them first. Integrity mode hashes supported source types on open and gives exports a hash manifest, while its forensic test suite checks source immutability, absence of side-effect files, read-only media handling, known-output references and reproducibility. Hex provenance can map selected SQLite, Protobuf, MMKV or Realm values back to their exact source bytes.

Why it matters

Investigation errors often enter between a raw file and the analyst's interpreted value. Byte-level provenance and reproducibility tests reduce that gap by letting a reviewer inspect both the parsed meaning and where it came from in the original source.

How to use it

Hash the original source first, work from a preserved copy, keep exported artifacts and hash manifests separate, and record the Crush version when a parsed value becomes part of an evidentiary claim.

Limits

Crush is an inspection workbench, not a full disk-forensics suite: the project explicitly excludes functions such as carving, journal analysis, snapshots and RAID/LVM. Its image viewer can expose C2PA or AI-provenance metadata but does not perform C2PA signature validation.

Crush відкриває складні evidence sources у read-only режимі й прив'язує parsed values назад до їхніх байтів

Джерело: Crush Forensics / GitHub · Репозиторій перевірено 10 жовтня 2026; оновлено 10 жовтня 2026

Що сталося

Crush — open-source desktop forensic workbench для archives, mobile backups, disk images, logical evidence containers, databases, structured data, media та документів. Багато джерел він відкриває без попереднього extraction або mounting. Integrity mode хешує підтримувані source types під час відкриття й додає hash manifest до exports, а forensic test suite перевіряє source immutability, відсутність side-effect files, read-only роботу з media, known-output references і reproducibility. Hex provenance дозволяє прив'язати вибрані значення SQLite, Protobuf, MMKV або Realm до точних байтів джерела.

Чому це важливо

Помилки розслідування часто з'являються між raw file та інтерпретованим аналітиком значенням. Byte-level provenance і reproducibility tests зменшують цей розрив: reviewer може перевірити і parsed meaning, і конкретне місце в оригінальному джерелі, звідки воно взялося.

Як це застосувати

Спочатку хешуйте оригінальне джерело, працюйте зі збереженою копією, тримайте exported artifacts і hash manifests окремо та фіксуйте версію Crush, коли parsed value стає частиною доказового твердження.

Обмеження

Crush — inspection workbench, а не повний disk-forensics suite: проєкт прямо не включає carving, journal analysis, snapshots і RAID/LVM. Image viewer може показувати C2PA або AI-provenance metadata, але не виконує C2PA signature validation.

digital-forensicscrushread-onlyhex-provenancehash-manifestreproducibilitysqlite

🧱Tool Supply ChainSupply chain інструментів

#05

BloomRepo adds a passive preflight before unfamiliar GitHub code becomes part of an investigation

Source: BloomRepo / GitHub · Repository checked 10 October 2026; pushed 5 October 2026

What happened

BloomRepo 3.0 is a local-first Rust application for public GitHub discovery, repository-change monitoring and authorized local static analysis. Its security workspace inventories dependencies from common lockfiles, generates CycloneDX 1.5 JSON SBOMs, scrubs detected secrets from output and can query OSV for known vulnerabilities without executing scanned project code. The discovery layer also tracks releases, licences, descriptions and archive-state changes over time.

Why it matters

OSINT investigators routinely install small, unfamiliar repositories. A separate preflight for dependencies, known vulnerabilities, release history and repository-state changes makes the tool itself part of the evidence and risk model rather than an invisible trusted dependency.

How to use it

Use it as a pre-execution checklist: repository state, recent changes, dependency inventory, SBOM, known vulnerabilities, then decide whether to inspect further in a sandbox. Preserve the SBOM and tool version with the investigation environment.

Limits

BloomRepo is a very young project with little adoption evidence. Passive static analysis and OSV matching can reveal known risks but cannot prove that code is safe or free of malicious behaviour.

BloomRepo додає пасивний preflight до того, як незнайомий GitHub-код стане частиною розслідування

Джерело: BloomRepo / GitHub · Репозиторій перевірено 10 жовтня 2026; оновлено 5 жовтня 2026

Що сталося

BloomRepo 3.0 — local-first Rust-застосунок для пошуку публічних GitHub-репозиторіїв, відстеження їхніх змін та authorized local static analysis. Security workspace інвентаризує dependencies із поширених lockfiles, генерує CycloneDX 1.5 JSON SBOM, прибирає знайдені secrets з output і може перевіряти відомі vulnerabilities через OSV без виконання коду сканованого проєкту. Discovery layer також відстежує зміни releases, licences, descriptions і archive state.

Чому це важливо

OSINT-дослідники регулярно встановлюють невеликі незнайомі репозиторії. Окремий preflight для dependencies, відомих vulnerabilities, release history і змін стану репозиторію робить сам інструмент частиною evidence та risk model, а не невидимою довіреною залежністю.

Як це застосувати

Використовуйте його як pre-execution checklist: стан репозиторію, останні зміни, dependency inventory, SBOM, відомі vulnerabilities — і лише потім вирішуйте, чи тестувати код далі в sandbox. Зберігайте SBOM і версію інструмента разом із середовищем розслідування.

Обмеження

BloomRepo — дуже молодий проєкт із мінімальними ознаками реального adoption. Пасивний static analysis і OSV matching можуть показати відомі ризики, але не здатні довести, що код безпечний або не містить шкідливої поведінки.

tool-supply-chainbloomreposbomcyclonedxosvstatic-analysisgithub

🛰️Change DetectionВиявлення змін

#06

Google Earth's Detect change can find candidate changes faster, but the pixels still need an analyst

Source: Google Maps Platform / Google Earth · 23 September 2026 — late pickup

What happened

Google Earth introduced Detect change as an experimental tool for finding where and when visible change occurred across a selected area. Instead of manually toggling historical imagery and scanning a large region pixel by pixel, an analyst can define an area and time span and use the tool to highlight locations with stronger apparent change for closer review.

Why it matters

For construction, destruction, land clearing, infrastructure change and other visually observable processes, change detection can turn a large search area into a smaller set of candidate locations and dates. That reduces search cost without outsourcing the interpretation.

How to use it

Use highlighted areas only as leads. Open the before-and-after source imagery, record the actual capture dates, compare shadows, season, resolution and viewing conditions, and corroborate the change with independent imagery or public records where possible.

Limits

The tool highlights visual difference, not the event or its cause. Imagery date, seasonality, clouds, illumination, sensor differences and resolution can all create or hide apparent change. This item is deliberately included as a late pickup rather than presented as a new release this week.

Detect change у Google Earth швидше знаходить кандидати на зміни, але пікселі все одно має перевірити аналітик

Джерело: Google Maps Platform / Google Earth · 23 вересня 2026 — пізній pickup

Що сталося

Google Earth представив Detect change як експериментальний інструмент для пошуку місць і періодів, де у вибраній зоні видно зміни. Замість ручного перемикання historical imagery і перегляду великої території pixel-by-pixel аналітик може задати area та time span і отримати підсвічені ділянки з сильнішими apparent changes для подальшої перевірки.

Чому це важливо

Для будівництва, руйнувань, розчищення території, змін інфраструктури та інших візуально спостережуваних процесів change detection може звузити велику територію до меншого набору кандидатів за місцем і часом. Це зменшує вартість пошуку, але не передає інструменту саму інтерпретацію.

Як це застосувати

Використовуйте підсвічені ділянки лише як leads. Відкривайте вихідні before/after imagery, фіксуйте реальні capture dates, порівнюйте shadows, сезон, resolution і умови зйомки та за можливості підтверджуйте зміну незалежними знімками або публічними записами.

Обмеження

Інструмент підсвічує візуальну різницю, а не саму подію чи її причину. Дата зйомки, сезонність, хмари, освітлення, різні сенсори й resolution можуть створювати або приховувати apparent change. Цей пункт свідомо включено як late pickup, а не як новий реліз цього тижня.

change-detectiongoogle-earthsatellite-imageryhistorical-imagerycandidate-generationmap-room