|
Title: Security disclosure: OP_RETURN embedding of Malware signatures into Blockchain Post by: wrapperband0lite on September 17, 2025, 10:17:23 AM cc. Bitcoin Forum.
Hi Bitcoin Core security team, Summary: A regtest reproduction shows that AV-signature-like bytes (canonical EICAR test string) can be embedded in an OP_RETURN output, mined into a block, and persist in chain data. The EICAR payload is detectable when extracted (opreturn.bin), but on my test system ClamAV did not flag the full block file (block.bin) even with relaxed scan limits. This demonstrates an operational risk if OP_RETURN capacity is increased: malware-signature bytes (or larger payloads) could be permanently embedded in blocks and cause inconsistent AV alerts or quarantines. Recommendations Reconsider increasing OP_RETURN size without addressing these operational impacts Environment: - Bitcoin Core: v30.0rc1 (regtest) - ClamAV: 1.4.3 (daily/main/bytecode current at test time) - Platform: Kubuntu VM Steps to reproduce (regtest, safe; EICAR used as test pattern) 1. Create/fund wallet and mine (regtest): bitcoin-cli -regtest createwallet test ADDR=$(bitcoin-cli -regtest -rpcwallet=test getnewaddress) bitcoin-cli -regtest generatetoaddress 101 "$ADDR" 2. Create a tx whose only output is OP_RETURN containing EICAR: EICAR='X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*' EICAR_HEX=$(printf '%s' "$EICAR" | xxd -p -c200) RAW=$(bitcoin-cli -regtest createrawtransaction '[]' \ '[{"data":"'"$EICAR_HEX"'"}]') FUND=$(bitcoin-cli -regtest -rpcwallet=test fundrawtransaction "$RAW" | jq -r .hex) SIGNED=$(bitcoin-cli -regtest -rpcwallet=test signrawtransactionwithwallet "$FUND" | jq -r .hex) TXID=$(bitcoin-cli -regtest sendrawtransaction "$SIGNED") 3. Mine it into a block and export the block: bitcoin-cli -regtest generatetoaddress 1 "$(bitcoin-cli -regtest getnewaddress)" BHASH=$(bitcoin-cli -regtest getbestblockhash) bitcoin-cli -regtest getblock "$BHASH" 0 > block.hex xxd -r -p block.hex block.bin Evidence OP_RETURN payload extraction is detected: clamscan --infected --no-summary opreturn.bin # => opreturn.bin: FOUND The EICAR text exists verbatim in the block: strings -a block.bin | grep -F 'EICAR-STANDARD-ANTIVIRUS-TEST-FILE' # => FjDX...EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H* Observed EICAR (canonical AV test string) successfully embedded in block and extractable. ClamAV flags the extracted payload but did not flag the full block.bin. Detection behaviour varies by AV engine/config — some will flag embedded signatures, others only whole-file matches. Impact Increasing OP_RETURN capacity enables embedding of malware-signature-like strings (and potentially larger payloads) into immutable chain data. Routine AV scans of blocks/, backups, or archives may produce false positives (or fail inconsistently), causing: quarantine deletion operational incident response. This is a risk for node operators, exchanges, and custodians who store blockchain data. Recommendations Reconsider increasing OP_RETURN size without addressing these operational impacts Consider tooling/policy checks to warn if suspicious arbitrary data (e.g. known signatures) are present in OP_RETURN before propagation. Title: Re: Security disclosure: OP_RETURN embedding of Malware signatures into Blockchain Post by: BattleDog on September 17, 2025, 12:17:11 PM Nice repro and write-up.
Couple of points for context: Arbitrary bytes in blocks aren't new. OP_RETURN is one route (and already big enough for EICAR), but far larger payloads ride today in witness/script data (think inscriptions). So even if OP_RETURN stayed tiny, the "AV signature in the chain" genie is long out of the bottle. The AV behaviour you saw is expected, some engines only flag after extraction/decoding; others might quarantine whole containers. But a block file is just inert bytes--if an AV nukes it, you re-download; no code runs from blocks/*.dat. Protocol-level filtering/blacklists won't scale (easy to evade with tiny mutations, fragmented across inputs, or stuffed in witness), and it drifts into brittle censorship + extra DoS surface in relay. Regarding practical ops: Treat the datadir as untrusted data, not software. Put it on a volume mounted noexec/nosuid/nodev; add AV exclusions for blocks/ and chainstate/. Don't back up blocks, back up wallets/descriptors; blocks can be re-synced. If an AV quarantines a blk file, just reindex/re-download. For enterprises, document the exclusion in your hardening guide and monitor for quarantine events so you don't "mysteriously" stall a node. Title: Re: Security disclosure: OP_RETURN embedding of Malware signatures into Blockchain Post by: wrapperband0lite on September 17, 2025, 12:51:12 PM Thanks for that reply.
Node operators aren't always enterprise and that extra work / knowledge puts friction on running nodes. Bypassing AV tests may have un-foreseen consequences, if a work around is devised e.g. extracting and running malware. I am working on a "test script" to embed a zip version of the malware signature. Many AV soft wares look for zip files in Binaries, so I may be able to get ClamAV to detect the blockchain. Cheers again. Title: Re: Security disclosure: OP_RETURN embedding of Malware signatures into Blockchain Post by: Ferib on September 17, 2025, 03:38:25 PM Very nice to see im not the only one that has been thinking of this. My thoughts were also roaming towards known YARA rules and other byte sequences that could be used to flag malicious files. Initially I was thinking this in regards of Video Game Cheats, as anti-cheat tends to scan the device and test again known Array of Bytes (AoB).
However, Bitcoin blockchain is saved on disk? its not executable at any point in time? For windows, I know most anti-cheat/anti-malware only scan specific set of files, e.g. files with the .exe, file's that are freshly updated and have PE headers. Or even dynamically when e.g. NtMapViewOfFileEx/AllocVirtualEx+WriteProcessMemory (in windows NT) are being used However, I don't see how arbitrary data in the Bitcoin Blockchain can affect such systems in a meaningful way, as I know most detection systems are heavily optimizing which files the scan exactly. clamscan --infected --no-summary opreturn.bin In your case, you force the AV to scan your specific file Consider tooling/policy checks to warn if suspicious arbitrary data (e.g. known signatures) are present in OP_RETURN before propagation. This is simply unrealistic. Now imagine you do somehow manage to sync a full .db of all known "bad" data chunks, but now -- by your logic -- your blacklist.db gets flagged by AV as that file contains a list of all signatures 🤡 Title: Re: Security disclosure: OP_RETURN embedding of Malware signatures into Blockchain Post by: achow101 on September 17, 2025, 05:25:46 PM This is neither new nor unique to OP_RETURN.
It has been possible to embed virus signatures into the blockchain for a very long time. I'm pretty sure the Eicar string is already in the blockchain, and has been in it, for well over a decade. Here's a reddit thread from 12 years ago talking about how there are viruses and virus signatures embedded in the blockchain: https://www.reddit.com/r/Bitcoin/comments/25otbt/someone_put_a_virus_signature_in_the_bitcoin/ UTXO set obfuscataion exists because of virus signatures in outputs since AVs were quarantining the database files. This was implemented over a decade ago. Blocks obfuscation was recently added as well, for similar reasons, although block files typically were not being quarantined because they are too big. Title: Re: Security disclosure: OP_RETURN embedding of Malware signatures into Blockchain Post by: wrapperband0lite on September 17, 2025, 07:09:37 PM Thanks everyone for the interesting replies.
This isn’t about “malware execution.” It’s about AVs quarantining raw block files due to embedded, recognizable payloads. I’ve shown it’s trivially reproducible today; making OP_RETURN bigger makes it easier and more frequent. Proceeding after disclosure means owning that operational risk. I have created a script that anyone can run to reproduce the findings. In this script a ZIP of the signature is included, because AV engines often carve and scan ZIPs found inside larger binaries. Here are the results: Code: Block hash: 7dc4f17afe7911f302829af0d6c30e66be73c1b7e8c207b6a76ca8a1af5c064a For clarity I will post the script in a separate post. Reply to #2 (context + “just exclude blocks/”) I agree arbitrary bytes in chain data aren’t new and exist outside OP_RETURN (witness/script paths, inscriptions, etc.). The point of my PoC is narrower: a mainstream AV quarantined the raw block file itself when a ZIP’ed signature was embedded in OP_RETURN. No manual extraction step; ClamAV carved the archive and flagged the block. That’s concrete operator disruption. “Just exclude blocks/” shifts the blast radius onto every non-enterprise operator (and their backup/restore tools). Many nodes run on consumer OS defaults or managed EDR with on-access/scheduled scans and network share scanning. Quarantine → node stalls or repeated re-downloads → downtime and tickets. That’s friction and centralizing pressure. I’m not proposing protocol blacklists or censorship. I’m documenting a reproducible operational effect that becomes easier/more frequent if OP_RETURN capacity is raised. If you widen the vector after this is known, you’re assuming the ops risk. Reply to #4 (Ferib: “not executable / scanners optimize; you forced the scan; blacklists unrealistic”) Two clarifications: Executability is irrelevant to AV quarantine. My PoC shows ClamAV flags the block file because it carves a ZIP and matches a signature inside. Lots of AV/EDR products do container carving inside arbitrary binaries; on-access, scheduled, backup, or NAS scans are enough to trip it. I didn’t need to run code — just store bytes and let the scanner do its job. I didn’t “force” anything unusual. clamscan is a stand-in for the many default/scheduled/on-access scans people actually run. Enterprises often scan large binaries and archives by policy; home users have Defender/others doing scheduled passes. One engine firing is all it takes to break someone’s node or backup chain. Re: blacklists — agree, a consensus-level blacklist is brittle and out of scope. I’m not asking Core to curate signatures. My post is a proof that embedding is trivial and block-level quarantine happens. That’s it. Reply to #5 (achow101: “not new; EICAR in chain for a decade; obfuscation exists”) Appreciate the history. I’m not claiming novelty of “bytes in chain data.” What I’m adding is a current, reproducible artifact on v30.0rc1 where a stock AV quarantines the raw block file due to an OP_RETURN that’s a valid ZIP with a known signature. Obfuscation of chainstate helps with past incidents, but blk*.dat remains plaintext and a scan target. Quarantine of a blk file still means node stalls/re-index/re-download and backup headaches. If OP_RETURN capacity is lifted, the ease/frequency of dropping AV-bait increases (especially with recognizable containers that carving engines tend to scan). That’s the only point I’m making here. What this is • A reproducible regtest proof that an AV can quarantine a raw Bitcoin block when signature-bearing bytes are embedded in OP_RETURN. • The payload is a ZIP containing the standard EICAR test file. No real malware. No code execution. • Confirms at least one mainstream AV (ClamAV) flags the block file itself. • This is not a protocol bug; it’s an operational disruption vector that becomes easier and more frequent if OP_RETURN capacity is increased. Code: # How to run (Linux) Code: #!/usr/bin/env bash Title: Re: Security disclosure: OP_RETURN embedding of Malware signatures into Blockchain Post by: NotATether on September 17, 2025, 07:51:26 PM Maybe the vulnerability is reproducible on a Windows system.
That's what over 90% of cyberattacks target. Perhaps advanced endpoint AV software would be able to flag the EICAR string itself and then lock down access to the file to just Bitcoin Core. But personally I think the outcome will be the same as ClamAV for consumer AV programs. It's more of a DoS risk though. Imagine taking down a bunch of nodes just by embedding a problematic string inside a transaction. Core is fuzz-tested a lot though, so hopefully it can handle such exceptions gracefully. Title: Re: Security disclosure: OP_RETURN embedding of Malware signatures into Blockchain Post by: wrapperband0lite on September 17, 2025, 09:26:30 PM Thanks — quick clarifications:
• This isn’t a Core crash or fuzzing case. It’s an operational DoS via quarantine: the AV/EDR sees signature-bearing bytes (here, a ZIP with EICAR) inside the raw block file and quarantines or locks it. Core then hits IO/missing-file and the node stalls until re-download/reindex. • OS-agnostic. The PoC works because many AVs carve/scan archives found inside larger binaries. That behavior exists on Linux (proved with ClamAV) and also on Windows/macOS in various engines. It’s about how scanners treat containers embedded in arbitrary files, not about executing anything. • “Advanced endpoint software will only allow Bitcoin Core to access blk files” — some products can be tuned that way, but default/scheduled/on-access scans, backup scanners, or NAS-side scanners still quarantine. That’s downtime and operator friction, especially for non-enterprise node runners. • The risk scales with ease/frequency. If OP_RETURN capacity is raised, it becomes easier to drop recognizable payloads (like ZIPs) that many engines scan by default. That’s the whole point of the repro: block-level quarantine happens. TL;DR: Not a protocol vulnerability; a repeatable ops disruption. I’ve posted a regtest script so anyone can verify on their setup. Windows test script : Windows batch (.bat) test script that mirrors the Linux PoC. put it all in a file named BTC-test-win.bat, edit the AV configuration at the top, then double-click or run from cmd. it will: start a regtest node in a temp datadir (does not touch mainnet/testnet) create a ZIP with the EICAR test file (safe) embed that ZIP in OP_RETURN, mine 1 block export the raw block and verify OP_RETURN is a real ZIP scan the block file and the payload ZIP using your AV command Code: :: ============================ BTC-test-win.bat ============================ notes Edit the AV config at the top: ClamAV example (as prefilled): AV_CMD=C:\Program Files\ClamAV\clamscan.exe AV_ARGS=--infected --no-summary --scan-archive=yes %FILE% Windows Defender example: AV_CMD=C:\Program Files\Windows Defender\MpCmdRun.exe AV_ARGS=-Scan -ScanType 3 -File %FILE% Requires Bitcoin Core (30.0rc) for Windows (bitcoind.exe, bitcoin-cli.exe) in PATH or adjust the BITCOIND / BITCOINCLI variables to full paths. Uses PowerShell to write EICAR, create ZIP, and handle hex/binary conversion and JSON parsing. It runs only on regtest and writes everything under a timestamped btc-av-opreturn-... folder in your current directory. I only have Linux so can't test it myself. TL;DR — Don’t increase OP_RETURN This isn’t about code execution. It’s about AV/EDR quarantining raw blk*.dat when malware signature-like bytes are embedded in transactions. That creates an operational DoS for node runners, backups, and restores. We’ve shown it’s trivially reproducible today. Why this matters
Real-world precedent when software is flagged as “malware”
Point Increasing OP_RETURN capacity widens the on-chain delivery path for recognisable payloads (ZIPs, signatures) that mainstream AVs already carve and scan inside large files. More capacity = more incidents. If you push this change after disclosure, you own the ops risk. I’ve shown with the tests, which you can easily reproduce with the scripts I have uploaded, AV detectors will detect malware signature embedded in the op_return. Update sent to Bitcoin Core Security Summary (updated): AV software identified malware signature in blockchain. By enclosing the canonical EICAR test string inside a ZIP and embedding that ZIP in an OP_RETURN output, AV/EDR engines can and do detect “malware” in the raw block file (blk*.dat). In my regtest runs (Core v30.0rc1), ClamAV flagged the exported block file itself (and the extracted payload). This creates an operational DoS risk for node operators: quarantine or lock leads to I/O errors, reindex or re-download, and downtime. Backups are also impacted when archive or NAS scanners hit the same bytes. Why this matters
Context and precedent When software is flagged as “malware” (false positive or real compromise), the fallout is real. Examples often cited: CCleaner (2017), SolarWinds (2020), HandBrake (2017). Here we show a repeatable on-chain trigger for similar quarantine behaviour. Ask Please do not increase OP_RETURN capacity without explicitly considering this operational risk. Increasing capacity widens the on-chain delivery path for recognizable containers (ZIPs) that engines already carve and scan inside large files. Repro scripts and discussion • Linux regtest scripts to reproduce the ZIP-in-OP_RETURN detection: • Bitcointalk link to this discusion Ha Ha Ha Ha Ha!!!!! I was unable to send security the test script in the email because : Code: Sorry, we were unable to deliver your message to the following address. Title: Re: Security disclosure: OP_RETURN embedding of Malware signatures into Blockchain Post by: DaveF on September 18, 2025, 11:16:40 AM Wouldn't most live AV software stop the block from ever being downloaded? I know I have had some issues with false positives coming in and the EDR stopping it before it even got written to the disk.
And since EICAR is 68 bytes you can already fit it in OP_RETURN and nobody cares. Which IMO they should not. -Dave Title: Re: Security disclosure: OP_RETURN embedding of Malware signatures into Blockchain Post by: wrapperband0lite on September 18, 2025, 11:49:28 AM Thanks, Dave.
On EICAR size: A valid ZIP of EICAR is well over 80 bytes, so the ZIP example needs larger capacity or other data paths. The point stands: the block file can be quarantined when engines carve embedded archives and see a known signature. Many engines explicitly look for ZIPs inside large binaries; they are less likely to act on a short partial signature. That is why a larger OP_RETURN increases risk. Agreed, the 68-byte EICAR string already fits in today’s OP_RETURN. My PoC is not “we need a bigger OP_RETURN to embed EICAR”. It is “engines that carve containers from arbitrary binaries will flag the block file itself when a ZIP with a known signature is embedded”. Increasing OP_RETURN does not enable the idea; it increases the ease, size, and frequency (for example larger or nested archives, multiple signatures), which means more engines flag and more nodes get disrupted. On the live-AV point: Whether an engine blocks pre-write (stream/on-write) or post-write (on-access or scheduled or backup or NAS), the node still hits I/O failure and stalls until re-download and reindex. From the operator’s perspective, it is the same operational DoS. What is actually new here: Not “bytes can be put on chain” — that is known. The new part is a current, reproducible artifact where a mainstream AV flags the raw block file due to a ZIP-in-OP_RETURN on v30 regtest, with paste-ready proof. Bottom line: Block-level quarantine is real and reproducible today. Making OP_RETURN bigger would make incidents more common and would enable larger malware signatures, not just the test string. That is the risk I am documenting. Title: Re: Security disclosure: OP_RETURN embedding of Malware signatures into Blockchain Post by: 1440000bytes on September 18, 2025, 02:27:51 PM I was unable to send security the test script in the email because : Code: Sorry, we were unable to deliver your message to the following address. Can you scan it on https://www.virustotal.com/gui/home/upload and share the results link? Title: Re: Security disclosure: OP_RETURN embedding of Malware signatures into Blockchain Post by: wrapperband0lite on September 18, 2025, 03:02:30 PM Cheers for the idea 1440000bytes :
Code: Can you scan it on https://www.virustotal.com/gui/home/upload and share the results link? The point of having the script text is that someone can just copy it into a file and run it, so anyone else can run the test easily. What I did was : point them to this discussion thread - in the version of the email without the script, where they can just copy and paste it. However, I didn't think of a screenshot, it's a good idea and I should have done that as well. Wrapper Title: Re: Security disclosure: OP_RETURN embedding of Malware signatures into Blockchain Post by: NotATether on September 19, 2025, 12:53:17 PM • OS-agnostic. The PoC works because many AVs carve/scan archives found inside larger binaries. That behavior exists on Linux (proved with ClamAV) and also on Windows/macOS in various engines. It’s about how scanners treat containers embedded in arbitrary files, not about executing anything. I think the only reason why we haven't seen such as DoS happen in action is because most people are running their nodes on Linux with no AVs. Maybe a couple of folks use Red Hat or CentOS which contains SELinux, but I think SELinux might be different from AVs in that it doesn't quarantine anything and it's more of an exploit-buster. I was unable to send security the test script in the email because : Code: Sorry, we were unable to deliver your message to the following address. That's a bit ironic. Maybe you should try putting it inside a Pastebin. Title: Re: Security disclosure: OP_RETURN embedding of Malware signatures into Blockchain Post by: wrapperband0lite on September 19, 2025, 01:36:20 PM Good points, NotATether — and thanks for the merit.
Linux without AV Many home node runners don’t run AV on Linux, agreed. But plenty of environments do have scanners/EDR on Linux (CrowdStrike, SentinelOne, Defender for Endpoint for Linux, Sophos, etc.). More importantly, backup/NAS scanners and email/CI gateways scan artifacts regardless of the OS on the node. That’s why this shows up as an operational issue even if the node host itself has no AV. Gateways prove the point My security email bounced because the gateway scanner detected “malware” in the attachment. That’s exactly the class of disruption I’m documenting: the same bytes that land in blk*.dat trigger quarantine or blocking in downstream systems (mail, backups, artifact repos), not just on-access AV. SELinux vs AV Right — SELinux is policy confinement, not signature quarantine. It won’t quarantine blk*.dat; AV/EDR and content-security gateways do. The DoS here comes from quarantine/lock or delete of files the node or ops pipeline expects to exist. Why OP_RETURN size matters anyway EICAR raw (68 bytes) already fits today, but a valid ZIP with the test string does not fit in 80 bytes. Engines commonly carve/scan ZIPs inside large binaries; they are much more likely to act on a recognizable container than a tiny substring. Increasing OP_RETURN makes it trivial to drop ZIPs/nested archives/multiple signatures that more engines detect by default — leading to more incidents. FWIW, to share the repro without tripping mail filters: the scripts generate the test string at runtime from split/encoded pieces (no literal signature in the email/forum body). And the full Linux/Windows regtest scripts plus paste-ready proof are in the thread: Security disclosure: OP_RETURN embedding of Malware signatures into Blockchain (https://bitcointalk.org/index.php?topic=5559355.0) Title: Re: Security disclosure: OP_RETURN embedding of Malware signatures into Blockchain Post by: NotATether on September 20, 2025, 08:45:17 AM Linux without AV Many home node runners don’t run AV on Linux, agreed. But plenty of environments do have scanners/EDR on Linux (CrowdStrike, SentinelOne, Defender for Endpoint for Linux, Sophos, etc.). More importantly, backup/NAS scanners and email/CI gateways scan artifacts regardless of the OS on the node. That’s why this shows up as an operational issue even if the node host itself has no AV. I was going to ask you yesterday - I feel like this problem can be mitigated by using a watchdog process to detect missing blocks or chain state and then use an RPC command, or even use the ZMQ channel to request for the specific block to be downloaded again. Such a program is not currently written, to my understanding. Title: Re: Security disclosure: OP_RETURN embedding of Malware signatures into Blockchain Post by: wrapperband0lite on September 20, 2025, 09:12:27 AM Thanks, NotATether - that’s a constructive idea.
A watchdog could help detect stalls faster. But this raises a bigger point: Bitcoin Core developers and random node operators are not liable to design, fund, and maintain new monitoring to offset a policy change. If a watchdog is the mitigation, a few questions need clear answers first: • Ownership: Who specifies it, writes it, audits it, and maintains it across Linux/Windows/macOS and different deployments? • Funding: Who pays for ongoing maintenance, support, and incident response when it breaks? • Integration: Is it shipped with Core, as a separate daemon, or left to each operator? How is it configured safely by default? • Blast radius: Who is responsible if it false-positives, misses an event, or triggers a bad reindex and causes downtime or data loss? • Supportability: Who provides docs, SLAs, and fixes when enterprise EDR, NAS scanners, or gateways behave differently? Until there is a concrete, owned mitigation plan with accountable parties and funding, asking thousands of operators to bolt on a watchdog just externalises the risk. My position remains simple: do not increase OP_RETURN without first owning the operational consequences and the mitigation. Title: Re: Security disclosure: OP_RETURN embedding of Malware signatures into Blockchain Post by: NotATether on September 20, 2025, 09:20:31 AM Good points.
I don't think Bitcoin Core will ever build this to be honest. It's something that would have to be maintained by a 3rd party and then maybe they can sell commercial support for it so that people don't have manually debug their watchdog configuration. Title: Re: Security disclosure: OP_RETURN embedding of Malware signatures into Blockchain Post by: wrapperband0lite on September 20, 2025, 09:39:38 AM Emergency: please acknowledge test-fail in Bitcoin Core v30.0rc1 (AV quarantine of blk*.dat via ZIP-in-OP_RETURN)
I have: • sent an email to the dev lists and security contacts, • tried to open a GitHub issue (rejected), and • posted a detailed thread here on Bitcointalk. Why is a bug affecting the next release not being acknowledged? Silence is not resolution, and ignoring the issue will not make it go away. Summary This is not code execution. On v30.0rc1 (regtest), enclosing the canonical EICAR test string inside a ZIP and embedding that ZIP in OP_RETURN results in mainstream AV/EDR quarantining the raw block file (blk*.dat). This has been reproduced with public scripts. Impact • Node stall: quarantine or lock leads to I/O errors and reindex or re-download. • Backups: archive or NAS scanners nuke snapshots even if the live datadir is excluded. • Risk increases if OP_RETURN capacity is raised, since recognizable containers are easier to embed. Repro (safe, regtest) • Bitcoin Core: v30.0rc1 • Results: ClamAV flags the exported block file and the extracted payload • Scripts: Linux and Windows batch provided in my thread Thread with scripts and paste-ready proof Security disclosure: OP_RETURN embedding of Malware signatures into Blockchain (https://bitcointalk.org/index.php?topic=5559355.0) Ask • Please confirm receipt and open a tracking reference for v30.0rc1. • Consider the operational risk in any OP_RETURN changes before release. Title: Re: Security disclosure: OP_RETURN embedding of Malware signatures into Blockchain Post by: ABCbits on September 21, 2025, 08:22:34 AM UTXO set obfuscataion exists because of virus signatures in outputs since AVs were quarantining the database files. This was implemented over a decade ago. Blocks obfuscation was recently added as well, for similar reasons, although block files typically were not being quarantined because they are too big. Reply to #5 (achow101: “not new; EICAR in chain for a decade; obfuscation exists”) Appreciate the history. I’m not claiming novelty of “bytes in chain data.” What I’m adding is a current, reproducible artifact on v30.0rc1 where a stock AV quarantines the raw block file due to an OP_RETURN that’s a valid ZIP with a known signature. Obfuscation of chainstate helps with past incidents, but blk*.dat remains plaintext and a scan target. Quarantine of a blk file still means node stalls/re-index/re-download and backup headaches. If OP_RETURN capacity is lifted, the ease/frequency of dropping AV-bait increases (especially with recognizable containers that carving engines tend to scan). That’s the only point I’m making here. @achow101 specifically mentioned block obfuscation feature is exist. But your reply state blk*dat remains plaintext, which isn't true since Bitcoin Core 28.0. Although it seems XOR only applied for new fresh IBD/sync. Block files are now XOR'd by default with a key stored in the blocksdir. Previous releases of Bitcoin Core or previous external software will not be able to read the blocksdir with a non-zero XOR-key. Refer to the -blocksxor help for more details. (#28052) If you were running a bitcoin node before upgrading to v28.0, your raw block data files will remain in plain text. So existing and new block data will not be obfuscated moving forward. Title: Re: Security disclosure: OP_RETURN embedding of Malware signatures into Blockchain Post by: wrapperband0lite on September 21, 2025, 12:34:44 PM Headline: Block XOR does not cure the risk from increasing OP_RETURN size.
Even with v28+ XOR on blk*.dat, the quarantine problem remains. The moment block bytes are handled in plaintext anywhere in the workflow, AV/EDR can still flag them. ABCbits - thanks for the correction and the links, appreciated. You are right: since Core v28.0, new IBD stores blk*.dat XOR-obfuscated by default ( Code: -blocksxor Why XOR does not remove the risk: • Plaintext appears in normal ops. The PoC scans a plaintext export created by Code: getblock ... 0 Code: block-with-zip.bin • Per-node only. Each node has its own XOR key. XOR is local at rest, not a network protection. The same bytes become plaintext when exported, backed up, or shared. • Validation needs plaintext. Core de-XORs to process and serve data. Filters that hook reads can act on plaintext at that point. • Mixed or non-XOR datasets exist. Nodes upgraded from pre-28 keep older blk files unobfuscated. Some deployments disable XOR or use non-Core tooling that writes plaintext copies. • External scanners act outside Core. Backup or NAS scanners, email or CI gateways, and artifact repos scan plaintext copies and streams regardless of on-disk XOR. Restating the test and impact: • Test: embed a ZIP with a known signature via OP_RETURN on v30.0rc1 (regtest). • Result: AV quarantines the raw block content when seen in plaintext (exported block and extracted payload). • Impact: I/O errors, stalled nodes, reindex or re-download, broken backups and NAS scans. • Risk scaling: increasing OP_RETURN makes recognizable containers easier and more frequent, which increases incident frequency. I am extremely concerned about the effect of increasing OP_RETURN, particularly after it failed my test immediately. This puts Bitcoin users at risk because the danger is no longer theoretical. I am alarmed at the lack of acknowledgement; this is concerning. Question: can someone point to where this specific operational risk was discussed in the development process, for example on GitHub issues, PR reviews, or the mailing list? Title: Re: Security disclosure: OP_RETURN embedding of Malware signatures into Blockchain Post by: gmaxwell on September 21, 2025, 02:05:07 PM Please spare us the AI histrionics.
As pointed out, none of this is new, there is even malware embedded in the chain back in 2011 or 2012. Nor is 'I can run some obscure RPC manual export commands and _then_ run it through a separate tool (three-- in fact-- jq, sed, and xxd) to decode hex to binary and write it to a file and anger my dumb AV' new -- no one would do this, but if they would, it's a personal problem and an already existing one. "Doctor, doctor! I bleed when I shoot myself in the head!". Large op_returns from an attack perspective *cannot be prevented* (without a consensus change which no one has proposed) because the attacker can just use nicehash and rent hashpower, also because major miners *already eliminated the limit*, and one need only directly hand the transaction to their nodes. The same data, as others have pointed out here can also just be stuffed elsewhere (which is why no one proposes a consensus change). If there were going to be problems it's very likely they'd already be seen. If ones crop up later, they'll get fixed. AV scanning at *worst* trips up a small number of nodes primarily on windows-- we know this because we've seen it before. That's why some data on disk has been xored for many years-- incrementally where we saw problems, so there is experience on dealing with it. The system has to be robust against bad data, if it isn't-- that's a bug that needs to be fixed. Experience suggests that it is already robust, nothing your AI is saying is countering that so far. Perhaps there are other areas for improvement, if so that's fine but it's not related to any recent changes. Because, repeating, to whatever extent there is a problem it already exists-- and we already know what AV impacts look like when there is a problem and it's a nuisance rather than anything of grave concern. Otherwise, this is why we have things like P2P encryption which your AI seems to be dumbly unaware of, so for example enterprise firewalls that nuke connections that have 'bad content' or the GFW with "Tiananmen Square massacre" won't isolate nodes... so just give it a break. I am so tired of inactive aged (and probably purchased) accounts spewing AI nonsense trying to create a false narrative to undermine bitcoin. You were instantly reported on your first new posts and I should have just nuked you then on the reports. The only people you're fooling are weak minded and irrelevant. But hey, I should thank you in one respect: Every time someone like this shows up arguing these points and people like Luke-jr and his sycophants at ocean mining stay silent at the manipulative falsehoods being uttered on their behalf when they would be best positioned to calm them down it further shows them to be either incompetent or corrupt persons without integrity or care for the health of Bitcoin. Title: Re: Security disclosure: OP_RETURN embedding of Malware signatures into Blockchain Post by: shinohai on September 21, 2025, 02:48:39 PM Please spare us the AI histrionics. As pointed out, none of this is new, there is even malware embedded in the chain back in 2011 or 2012. Nor is 'I can run some obscure RPC manual export commands and _then_ run it through a separate tool (three-- in fact-- jq, sed, and xxd) to decode hex to binary and write it to a file and anger my dumb AV' new -- no one would do this, but if they would, it's a personal problem and an already existing one. "Doctor, doctor! I bleed when I shoot myself in the head!". Large op_returns from an attack perspective *cannot be prevented* (without a consensus change which no one has proposed) because the attacker can just use nicehash and rent hashpower, also because major miners *already eliminated the limit*, and one need only directly hand the transaction to their nodes. The same data, as others have pointed out here can also just be stuffed elsewhere (which is why no one proposes a consensus change). If there were going to be problems it's very likely they'd already be seen. If ones crop up later, they'll get fixed. AV scanning at *worst* trips up a small number of nodes primarily on windows-- we know this because we've seen it before. That's why some data on disk has been xored for many years-- incrementally where we saw problems, so there is experience on dealing with it. The system has to be robust against bad data, if it isn't-- that's a bug that needs to be fixed. Experience suggests that it is already robust, nothing your AI is saying is countering that so far. Perhaps there are other areas for improvement, if so that's fine but it's not related to any recent changes. Because, repeating, to whatever extent there is a problem it already exists-- and we already know what AV impacts look like when there is a problem and it's a nuisance rather than anything of grave concern. Otherwise, this is why we have things like P2P encryption which your AI seems to be dumbly unaware of, so for example enterprise firewalls that nuke connections that have 'bad content' or the GFW with "Tiananmen Square massacre" won't isolate nodes... so just give it a break. I am so tired of inactive aged (and probably purchased) accounts spewing AI nonsense trying to create a false narrative to undermine bitcoin. You were instantly reported on your first new posts and I should have just nuked you then on the reports. The only people you're fooling are weak minded and irrelevant. But hey, I should thank you in one respect: Every time someone like this shows up arguing these points and people like Luke-jr and his sycophants at ocean mining stay silent at the manipulative falsehoods being uttered on their behalf when they would be best positioned to calm them down it further shows them to be either incompetent or corrupt persons without integrity or care for the health of Bitcoin. This is the finest reply I have read in this thread. The op_return whataboutisms and pearl clutching are getting so tiresome. Title: Re: Security disclosure: OP_RETURN embedding of Malware signatures into Blockchain Post by: wrapperband0lite on September 21, 2025, 05:17:57 PM Thanks, gmaxwell, and thanks, shinohai, for jumping in.
What I hear you saying (in simple terms): • This is not new. People have put malware or signatures in the chain for years. • Exporting blocks and poking them until an AV trips is not a real-world workflow. If someone does that, it is their problem. • Bigger OP_RETURN cannot be stopped without a consensus change, and data can go in other places anyway. • If this were going to cause trouble, we would have seen it already. At worst a few Windows nodes get annoyed, and XOR on disk helps. • P2P encryption keeps dumb firewalls from killing connections. • You are skeptical of AI-flavored posts trying to make Bitcoin look bad. My reply: • Agree on history. Bytes in the chain are old news. My point is narrower: on v30.0rc1 a common AV flags the block file itself when a ZIP’d signature is embedded via OP_RETURN. That is a specific, repeatable result with scripts anyone can run. • Exports and plaintext copies are real. Teams export blocks for debugging, research, support, and backup. NAS and backup scanners, CI and email gateways create and scan plaintext copies. I even had a security email bounce because the gateway flagged the artifact. This does not require exotic steps. • XOR helps at rest, not end to end. Fresh v28+ IBD uses XOR on disk. It does not help when you export, back up, or share data, or when Core reads data to serve it. Many nodes have mixed or non-XOR data. • Other data paths exist, yes. That does not change this point: making OP_RETURN larger makes it easier and more frequent to drop content AVs already search for (ZIPs, nested archives, multiple signatures). Easier and more frequent means more incidents for operators. • Not a consensus ask. I am not proposing a consensus rule. I am asking that this operational risk be acknowledged while discussing OP_RETURN policy, because it affects real nodes and backups. • P2P encryption is unrelated. The repro is about files and exports being scanned at rest or in transit on backup and mail systems, not about in-flight P2P filtering. Concrete ask If this exact operational risk was already considered and accepted, please point to the issue, PR, or mailing list discussion. If not, a short acknowledgement and a tracking reference for v30.0rc1 would close the loop. I am happy for others to run the scripts and post their results. Thread with scripts and proof (regtest, safe malware test string): Security disclosure: OP_RETURN embedding of Malware signatures into Blockchain (https://bitcointalk.org/index.php?topic=5559355.0) |