Skip to content

Decode Hex and Base64 from a copy when the source overlaps the destination [patch] - #167

Merged
matt-edmondson merged 1 commit into
mainfrom
fix/166-decode-overlapping-buffers
Oct 30, 2026
Merged

matt-edmondson merged 1 commit into
mainfrom
fix/166-decode-overlapping-buffers

Conversation

@matt-edmondson

Copy link
Copy Markdown
Contributor

Fixes #166

Problem

#138 made TryEncode/TryObfuscate safe for overlapping buffers, but TryDecode was not. The problem appears when the destination starts after the source in the same buffer:

  • Hex overwrote encoded pairs before reading them.
  • Base64 called Base64.DecodeFromUtf8 directly, which does not support overlapping buffers.

In most cases both returned true with corrupted output. The Hex and Base64 obfuscators' TryDeobfuscate forward to these decoders, so they were affected too.

Change

HexEncodingProvider.TryDecode and Base64EncodingProvider.TryDecode now do what TryEncode already does. When encodedData.Overlaps(destination), they decode from an ArrayPool copy and clear the copy before returning it to the pool. Each class's remarks now say that both directions copy on overlap.

Tests

  • EncodingProviderTests.Decoding_OverlappingBuffers_MatchesOutOfPlace covers every IEncodingProvider, next to the existing encode overlap test.
  • ObfuscationProviderTests.Deobfuscation_OverlappingBuffers_MatchesOutOfPlace covers every IObfuscationProvider, next to the existing obfuscate overlap test.
  • Both tests use source/destination offsets (0,0), (0,3) and (3,0), as the acceptance criteria ask.
  • Before the fix, exactly four cases failed: Hex and Base64 for both encoding and obfuscation. After it, all 18 overlap cases pass.
  • Full suite (net10.0): 1346 tests, 1345 passed, 1 skipped, 0 failed.

Generated by Claude Code

…ation [patch]

TryEncode copies an overlapping source to a pooled buffer first (#138),
but TryDecode did not. With the destination starting after the source in
the same buffer, Hex overwrote encoded pairs before reading them and
Base64.DecodeFromUtf8, which does not support overlap, corrupted or
rejected valid input. Both returned true with corrupted output in most
cases, and the Hex and Base64 obfuscators' TryDeobfuscate forward to
these decoders.

TryDecode now does what TryEncode does: when the spans overlap, it
decodes from a pooled copy and clears the copy before returning it.
Decode-direction overlap tests sit next to the encode ones and cover
every IEncodingProvider and IObfuscationProvider at offsets (0,0), (0,3)
and (3,0).

Fixes #166

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017vfJW6XNeWiDxG4BVzYTra
@sonarqubecloud

Copy link
Copy Markdown

@matt-edmondson
matt-edmondson merged commit dc3bd3f into main Oct 30, 2026
10 checks passed
@matt-edmondson
matt-edmondson deleted the fix/166-decode-overlapping-buffers branch October 30, 2026 02:46
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Hex and Base64 TryDecode return true with corrupted output when the destination starts after the source in the same buffer

2 participants