Skip to content

fix(liteclient): write both magics in auth-complete payload (#463) - #501

Open
chiliec wants to merge 1 commit into
tonkeeper:masterfrom
chiliec:fix/auth-complete-magic-overwrite
Open

fix(liteclient): write both magics in auth-complete payload (#463)#501
chiliec wants to merge 1 commit into
tonkeeper:masterfrom
chiliec:fix/auth-complete-magic-overwrite

Conversation

@chiliec

@chiliec chiliec commented Aug 17, 2026

Copy link
Copy Markdown

What

Closes #463.

sendAuthComplete (liteclient/connection.go) built the tcp.authentificationComplete payload like this:

payload := make([]byte, 4)
binary.LittleEndian.PutUint32(payload, magicTcpAuthentificationComplete)
binary.LittleEndian.PutUint32(payload, magicPubKey)

Both PutUint32 calls write to offset 0 of the same 4-byte buffer, so the second write (magicPubKey) immediately overwrites the first (magicTcpAuthentificationComplete). The auth-complete message is therefore sent with the wrong type prefix and is 4 bytes short.

Cause

The TL schema is:

tcp.authentificationComplete key:PublicKey signature:bytes = tcp.Message
pub.ed25519 key:int256 = PublicKey

so the serialized layout must be two distinct magics — the message-type magic followed by the PublicKey constructor magic — then the 32-byte key and the length-prefixed signature. The buffer needs 8 bytes for the two magics, not 4.

Fix

Write the two magics into distinct 4-byte slots, and extract the payload construction into a pure buildAuthCompletePayload(pubKey, signature) helper so the byte layout is unit-testable without a live connection:

payload := make([]byte, 8)
binary.LittleEndian.PutUint32(payload[:4], magicTcpAuthentificationComplete)
binary.LittleEndian.PutUint32(payload[4:8], magicPubKey)

Tests

Added liteclient/auth_complete_test.go, which asserts the exact byte layout: message magic at [0:4], pubkey magic at [4:8], the public key at offset 8, the length-prefixed signature after it, and 4-byte alignment.

Verified genuine RED→GREEN: with the original construction restored, the test fails with message magic: got 0x4813b4c6, want 0xf7ad9ea6 — i.e. it catches the exact overwrite; with the fix it passes.

Validation (real results, Go 1.24.5)

  • go test ./liteclient/ -run TestBuildAuthCompletePayloadLayout: PASS
  • go build ./...: success
  • gofmt -l and go vet ./liteclient/: clean

Note: the package's client_test.go tests (e.g. TestGeneratedMethod3) connect to a live lite server and fail in a sandbox without outbound network — I confirmed they fail identically on a clean master checkout, so that is unrelated to this change.

First-time contributor here — happy to adjust the helper's name/placement or the test if you'd prefer a different approach.

sendAuthComplete built the tcp.authentificationComplete payload with a
4-byte buffer and two PutUint32 calls that both wrote to offset 0, so the
message-type magic (magicTcpAuthentificationComplete) was immediately
overwritten by the PublicKey constructor magic (magicPubKey). The message
was sent with the wrong type prefix and was 4 bytes short.

Write the two magics into distinct 4-byte slots. Extract the payload
construction into buildAuthCompletePayload so the byte layout can be
unit-tested without a live connection.

Closes tonkeeper#463.

Signed-off-by: Vladimir Babin <vovababin@gmail.com>
@mr-tron

mr-tron commented Aug 18, 2026

Copy link
Copy Markdown
Contributor

lgtm

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.

authentication magic constant overwritten

2 participants