SessionKey handshake for V1-initial S7-1200 PLCs#724
Open
gijzelaerr wants to merge 34 commits into
Open
Conversation
V1-initial S7-1200 PLCs (e.g. FW v4.2.x) only return ServerSessionVersion when the client introduces itself with a fuller CreateObject attribute set. A minimal request (ClientRID only) gets an incomplete session and every subsequent CommPlus op fails with ERROR2 (0x05A9). Match TIA Portal's attribute set so the PLC fills in ServerSessionVersion, then echo it back verbatim in a V2 SetMultiVariables. ServerSessionVersion is a Struct(314) on real hardware, not a UDInt; capture it verbatim and echo unchanged. Session-setup write uses V2 framing, transport flags 0x34, and no IntegrityId regardless of what the PLC negotiated on initial connect (matches thomas-v2 SetSessionSetupData). Also fixes the broken STRUCT case in _skip_typed_value (4-byte ID + key/value pairs + 0x00 terminator, not VLQ count + element list). Sync client only for now — async will mirror once verified against real hardware. Refs #710, #712. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The CreateObject response header is 10 bytes long with no SessionId field; the actual session IDs are returned as a list of UInt32 VLQ values in the ResponseSet body (after ReturnValue + ObjectIdCount). Our code was reading 14 bytes as if a regular response header, picking up garbage as the session ID. The wrong InObjectId then caused the V2 SetMultiVariables session-setup to be rejected by real PLCs (TCP RST). Refs #710 #712. Reference: thomas-v2/S7CommPlusDriver CreateObjectResponse.Deserialize. Also updates the test emulator to emit responses in the same format real PLCs use (10-byte header, ObjectIds list), so the unit tests stay representative. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The V1-initial S7-1200 drops the V2 SetMultiVariables session-setup connection if we write its own device identity (element 319 of the ServerSessionVersion struct, e.g. "1;6ES7 215-1BG40-0XB0 ;V4.2") back to it verbatim. TIA Portal handles this by stripping element 319 to an empty WString before echoing — replicating that here. The rest of the captured Struct(314) value is echoed unchanged. Refs #710 #712. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Frame-by-frame comparison of TIA Portal V19's pcap (against an S7-1200
FW 4.2.2, V1-initial firmware) versus our previous SetMultiVariables
shows TIA writes *two* items in the session-setup frame:
1. address 1830 (SESSION_SETUP_LEGITIMATION) — a Struct(1800) with
four nested fields plus a 180-byte Blob. The blob carries the
PLC's 8-byte OMS session UUID at offset 32 (little-endian); the
remaining bytes look like opaque identity/integrity material.
2. address 306 (SERVER_SESSION_VERSION) — the existing PAOM-stripped
echo.
Without the address-1830 item the V1-initial PLC silently closes the
TCP connection right after the setup write — the symptom @xBiggs
reports on #710 / #713.
We capture the OMS UUID from the CreateObject response's
ObjectVariableTypeName attribute (id 233, "01:HEX" WString) and patch
it into the blob; everything else is replayed verbatim from the TIA
reference capture as a first-pass experiment. If the PLC validates
other byte ranges, we'll have to reverse those next.
The two-item form is gated on having an OMS UUID. The C# driver's
existing one-item form (SERVER_SESSION_VERSION only) still runs on
PLCs that don't surface an OMS UUID, matching the C# reference exactly.
Reference: thomas-v2/S7CommPlusDriver SetMultiVariablesRequest.cs;
TIAPortalV19AccessibleDevices.pcapng frame 31 (#710 / #713).
Refs #710 #712 #713
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
After 0c9af7c the parser kept scanning past the SERVER_SESSION_VERSION attribute (so it could also grab ObjectVariableTypeName for the V2 legitimation), which made the trailing "ServerSessionVersion not found" debug fire on every successful capture. Gate it on the captured fields so it only fires when we actually didn't find it. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Wireshark's s7comm-plus dissector reveals that the value at address 1830 is a Struct(1800) named ``StructSecurityKey`` carrying a ``SessionKey`` — specifically a 180-byte ``SecurityKeyEncryptedKey`` blob with the layout: 0-3 uint32 LE magic = 0xFEE1DEAD 4-7 uint32 LE blobsize (0xB4) 16-23 uint64 LE symmetric_key_checksum 32-39 uint64 LE public_key_checksum (what attribute 233 carries) 48-N encrypted_random_seed (RSA-encrypted) N.. 16 bytes AES-CBC IV N+16..56 bytes encrypted_challenge So generating this requires Siemens' RSA public key (identified by the 8-byte fingerprint in attribute 233's "01:HEX" string) plus the KDF that turns the seed into the AES-CBC key. We don't have either, so the TIA-replay we shipped in a2111e7 was always going to fail against any new session — the PLC cannot decrypt a static blob. Roll back the address-1830 send. Keep the public-key checksum extraction as a diagnostic capture (renamed from `_oms_session_uuid` to `_public_key_checksum` to match the dissector's terminology); a future commit can use it to dispatch to a key-aware handshake once we have the keys, or to clearly log "this firmware needs a SessionKey we can't generate" when we don't. Net effect on V1-initial S7-1200 (FW < 4.5): same as before this PR — SetupSession still fails, the unified client falls back to legacy PUT/GET, db_read works, browse() requires CommPlus and so still raises. PR #713 stays a draft pending the key situation. Refs #710 #712 #713 Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
First slice of the S7CommPlus session-key handshake (refs #717). Adds a fingerprint parser and an in-memory public-key lookup for the three PLC families HarpoS7 1.1.0 supports: S7-1500 (family 0), S7-1200 (family 1) and PlcSim (family 3). Key bytes are vendored verbatim from bonk-dev/HarpoS7's MIT-licensed binaries. @xBiggs's PLC fingerprint `01:BD426B091F08731A` is in the bundle, so once the rest of the handshake (AES, SHA-256, the proprietary monolith transforms, and the auth orchestration) lands we'll be able to generate a valid SecurityKeyEncryptedKey for that PLC. This commit alone changes no runtime behaviour — the new module is not yet wired into `_setup_session`. That happens in a later slice once the handshake produces verified output. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Second slice of the HarpoS7 port (refs #717). Adds the small SHA-256 fingerprinting function that computes the symmetric/public key id fields embedded in the SecurityKeyEncryptedKey blob. The function is just `SHA-256(key[:24] + b"DERIVE")[:8]` — well-defined in HarpoS7's `KeyExtensions.DeriveKeyId`. We verify byte-correctness in two ways: 1. The three test vectors HarpoS7 ships in `KeyExtensionsTests.cs` (a 64-byte PlcSim key plus two repeating-byte cases). 2. A self-consistency check: every bundled public key, when run through `derive_key_id`, must produce the LE byte-reversal of the BE-display hex it's keyed on. This catches both algorithm bugs and key-byte transcription errors in #b44792d. @xBiggs's PLC fingerprint `01:BD426B091F08731A` round-trips correctly, so once the next slices land we can compute exactly the publickeychecksum / symmetrickeychecksum the PLC expects to see. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Third slice of the HarpoS7 port (refs #717). Produces the leading 48 bytes of the 180/216-byte SessionKey blob — magic, length, key fingerprints, and per-family flags — matching the layout the Wireshark s7comm-plus dissector decodes. The headline regression test compares our output against TIA Portal V19's actual wire bytes from @xBiggs's pcap (frame 31 of TIAPortalV19AccessibleDevices.pcapng), modulo the per-session symmetric_key_id slot (which TIA randomises). Every other byte in the 48-byte header matches verbatim. Ported from HarpoS7's `BlobMetadataWriter.WriteMetadata` plus the per-family `Get{Public,Symmetric}KeyFlags` and `GetBlobLength` helpers. The PlcSim path is preserved for completeness, though the seed handling on that family differs and isn't exercised yet. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Fourth slice of the HarpoS7 port (refs #717). Adds three pure-SHA-256 KDFs the handshake uses to spin off the various AES keys: - derive_challenge_encryption_key — 16-byte AES-128 key for encrypting the PLC challenge - derive_seed_encryption_key_and_iv — 32-byte AES-256 key + 16-byte IV for encrypting the random seed (counter-mode SHA-256 chain over reverse(a2) || a3 || counter_byte) - derive_legitimation_challenge_key — 24-byte key for encrypting the legitimation challenge after session establishment All three verified byte-for-byte against the test vectors HarpoS7 ships in `KeyUtilitiesTests.cs`. The fourth helper from upstream — `derive_session_key` — is intentionally left out of this slice: it depends on `HarpoFingerprint.FingerprintChallenge`, which lives in the Family-0 "monolith" transforms and lands in a later slice. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
…ash_block) Fifth slice of the HarpoS7 port (refs #717). Adds the proprietary 128-bit transform that powers HarpoAesCtr's integrity-MAC computation and the encrypted-seed generation in the SessionKey blob. Three primitives — all pure-Python, all verified byte-for-byte against HarpoS7's vector tests: - lut1: one round of the transform, 16 → 16 bytes - generate_lookup_table: 16-byte key → 4 KB working table - hash_block: 16-byte input → 16-byte output, using the working table The full 4096-byte expected output of generate_lookup_table is pinned verbatim from HarpoHashTests.cs as a regression vector — covers both sub-loops in the C# implementation (the lut1 cascade and the xor-and-replicate fill phase). The 512-byte LUT_SEED constant doubles as HarpoHashSeed (upstream stores it twice for ergonomic byte vs ushort access; we just reslice when needed). This unblocks the next slice: HarpoAes / HarpoAesCtr. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Sixth slice of the HarpoS7 port (refs #717). Thin wrapper around the ``cryptography`` library's AES-128-ECB primitive, matching HarpoS7's ``HarpoAes`` API. Used as a building block by ``HarpoAesCtr`` for counter encryption and integrity-MAC checksum derivation. Tests verify the canonical NIST FIPS-197 §C.1 vector plus basic construction invariants. Skipped when the optional ``cryptography`` package is unavailable, matching the existing ``test_s7_v2.py`` pattern for code under the ``s7commplus`` extra. Also includes a one-time `ruff format` cleanup of the slice-4 KDF tests — collapsing a few short multi-line hex literals onto one line each. No behaviour change. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Seventh slice of the HarpoS7 port (refs #717). Ports the Init and EncryptCtr halves of HarpoAesCtr — the custom AES-CTR-with-MAC primitive that encrypts the seed and challenge inside the SecurityKeyEncryptedKey blob. Init derives a 4 KB working table from `AES-ECB(key, 0)` and folds the IV into a 16-byte counter through HarpoHash rounds. EncryptCtr increments the counter, AES-encrypts it for keystream, XORs against plaintext, and feeds ciphertext into a running HarpoHash accumulator. The two end-to-end vectors from HarpoAesCtrTests pass byte-for-byte: - TestInit: counter state after Init(0xCC * 16) matches the expected 16 bytes. - TestEncrypt2Times: encrypting 16 bytes then 24 bytes back-to-back produces the expected ciphertexts — exercises the partial-block carryover code path. CalculateChecksum is intentionally deferred to a follow-up slice; it needs the full mock-state plumbing the upstream test uses, plus the 4096-byte mockChecksumLut as a vendored test asset. The 12-byte-IV and unaligned-tail paths are left as NotImplementedError — same as upstream — since the SessionKey handshake never hits them. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Eighth slice of the HarpoS7 port (refs #717). Completes HarpoAesCtr by porting the CalculateChecksum finaliser. Folds the bit-lengths of encrypted regions into the running MAC, runs one final HarpoHash round, AES-encrypts the original IV extension, and XORs the two for the output checksum bytes. Verified against HarpoS7's CalculateChecksumTest vector via direct field injection (Python equivalent of the C# reflection-based mocking). The 4096-byte mockChecksumLut from the upstream test is vendored as `tests/fixtures/harpo_aes_ctr_mock_checksum_lut.bin`. This finishes "bucket 1" of the port — every standard primitive (SHA-256 KDFs, AES-128-ECB, HarpoHash, HarpoAesCtr) now passes byte-for-byte against HarpoS7's own ground-truth test vectors. What remains is the Family-0 monolith transforms (the proprietary block cipher) and the auth orchestration layer. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Ninth slice of the HarpoS7 port (refs #717). Adds a mechanical C#-to- Python transpiler in tools/ and runs it against HarpoS7's Family-0 Monoliths 1-8 and 11 — straight-line bitwise transforms that compute intermediate state for the SecurityKeyEncryptedKey blob. Each generated monolith passes byte-for-byte against HarpoS7's own test vectors (vendored as `tests/fixtures/family0/monoliths/*.bin`). Total ~8.5k transpiled statements verified, no manual edits to the generated code. Strategy notes: - Each MonolithN.Execute is a stream of `;`-terminated statements: variable declarations (discardable), `uVar = expr` assignments, `dst_dwords[i] = expr` writes, and a single optional `return`. No internal control flow. The transpiler treats the body as flat text: splits on `;`, normalises src/dst aliases, masks every assignment to uint32 (Python ints don't wrap), and emits a Python function with src/dst-dword views. - Monoliths 9 and 10 are orchestrators that call into Nine/Part1..11 and Ten/Part1..3 — those use a different signature taking a shared `locals` array. They're not yet ported and arrive in a follow-up slice that extends the transpiler's signature handling. The Transforms layer (the public API into Family-0) and the auth orchestration come after; this slice is pure infrastructure. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
…rators Tenth slice of the HarpoS7 port (refs #717). Extends the transpiler to handle Family-0 Part subprograms (which take a shared `locals` uint array in addition to or instead of source/destination buffers), runs it on all 14 Parts (Nine/Part1..11 + Ten/Part1..3), and adds hand-written Monolith9/Monolith10 orchestrators that chain them. The transpiler now detects the C# `Execute` parameter list and emits the matching Python signature: `Execute(source, locals)`, `Execute(locals)`, and `Execute(destination, locals)` are all supported. `locals` is renamed `locals_` to avoid the Python builtin. Mechanical translation: ~17k more transpiled statements across the 14 Parts. All compile and run, no exceptions. Vector status: - Monolith9 / Monolith10 produce non-byte-exact output against the upstream blob fixtures (xfail-marked, refs #717). Monolith10 matches for the first ~219 bytes then diverges, suggesting the bug is in a specific Part rather than the orchestrator structure. Investigation deferred — not on the critical path for the SessionKey handshake, which uses the simpler Monoliths and the Transforms layer (next slice). - The `test_monolith9_and_10_at_least_run` smoke test catches regressions in transpiler signature handling. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Eleventh slice of the HarpoS7 port (refs #717). Manual port of ``HarpoS7.Family0.BitOperations.BigIntOperations`` — short, idiomatic helpers for packing/unpacking 192-bit integers between the wire format and the proprietary 30-bits-per-limb representation the SessionKey curve operations use internally. Five operations: prepare (6→5 uints), finalize (5→6 uints), prepare_finalize (in-place fusion), rotate_right_30, rotate_left_31. All exact-byte verified against HarpoS7's vector fixtures. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Twelfth slice of the HarpoS7 port (refs #717). Manual port of the four ``BigInt*`` Transform classes plus the BigIntegerCompressor helper. Python's built-in ``int`` is arbitrary-precision, so we don't need a separate BigInteger library — just careful use of ``int.to_bytes`` and ``int.from_bytes`` with the right signedness. Operations: - big_int_addition (8 fixtures, 2 sub-cases) - big_int_subtraction (11 fixtures, 4 sub-cases incl. all the negative-result corner cases that need the upstream's signed sign-extension dance) - big_int_multiplication (9 fixtures, 3 sub-cases) - big_int_square (10 fixtures, 2 sub-cases) All 11 vector tests pass byte-for-byte against the upstream blob fixtures. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Thirteenth slice of the HarpoS7 port (refs #717). Manual port of the two GHASH-style transforms — both vector-verified against HarpoS7's fixtures. LutGenerator builds a 4 KB table of 256 UInt128 values from a 16-byte seed by iterated GF(2¹²⁸) doubling under the AES-GCM-style reduction polynomial x¹²⁸ + x⁷ + x² + x + 1. ChecksumTransform consumes that table plus a 16-byte key to produce a 16-byte integrity tag, walking key bytes MSB→LSB and rotating the work buffer one byte after every 4-byte block. Neither depends on the still-broken Monolith9/10 path. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Root cause of part of the Monolith9/10 divergence: C#'s uint << N truncates the result to 32 bits, but Python's int << N doesn't. When the overflow bits get picked up by a subsequent ~ (negative int) & operation, the high bits differ from C#. Same for * 2. Fix: add & 0xFFFFFFFF after every << and * 2 in the transpiled output. Since << has higher precedence than & in Python, the mask applies to the shift result before any surrounding operator sees it. Result: Ten/Part1 is now byte-perfect (0 diffs vs C#). Ten/Part2 still has 57 diffs from a different root cause (under investigation — need more C# binary-search checkpoints). Monoliths 1-8/11 continue to pass. Diagnosed using dotnet test against HarpoS7 with intermediate locals[] dumps compared to Python output. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Root causes diagnosed using .NET-side intermediate locals[] dumps compared statement-by-statement against the Python port: 1. Left-shift overflow (Part1): C# uint << N truncates to 32 bits; Python int << N doesn't. When overflow bits get picked up by a subsequent ~ (negative) & operation, the result diverges. Fix: mask << results with & 0xFFFFFFFF in subexpressions. 2. Right-shift on identifiers (Part2/3): `ident >> N` wasn't wrapped in _shr() for uint32 masking. Only `) >> N` was handled. 3. ~(expr) >> N paren matching (Part3): the _fix_right_shifts walker found `) >> N`, walked back to the matching `(`, but stripped the leading `~` — making `~(X) >> N` into `_shr(X, N)` instead of `_shr(~(X), N)`. Fix: include any leading `~` chain as part of the operand. All 11 monoliths + both orchestrators now pass byte-for-byte. Removed the xfail markers. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Port remaining transforms and orchestration for pre-TLS V1 session-key handshake, verified byte-identical against HarpoS7 C# test vectors for both S7-1500 and S7-1200 key families. New modules: - transform7: core ECC scalar multiplication (monolith wrappers + Transform12 dispatch + BigInt operations) - seed_transform: generates encrypted seed via Transform7 + Monolith1/2/8/11 + Transform13 - pre_seed_transform, key_derivation_transform, transform13: Monolith9/10-based key preparation transforms - monolith_wrappers: WithCopy wrappers for Monoliths 3-7 - fingerprint: HarpoFingerprint challenge fingerprinting with vendored data tables (ContextMutator + FingerprintConsts) - authenticator: RealPlcAuthenticator blob builder (metadata + seed + AES-ECB encrypted challenge + GHASH checksum) - legacy_auth: top-level entry point (authenticate_real_plc) - key_derivation.derive_session_key: HMAC-SHA256 session key via fingerprint Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Includes vendored binary data (transform1_data, transform7_data, transform7_indexes) that were already referenced by code but not staged, plus test fixtures and vector tests for PreSeedTransform, KeyDerivationTransform, and Transform13. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Inline small constant tables as documented Python literals in data/_constants.py — hex ints for opaque values, named tuples for structured data (ECC coordinates, dispatch tables, mutation operations). The 4 large tables (transform12 metadata 244K, big-int aux 18K, fingerprint data1/data2 67K) stay as .bin. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
When the CreateObject response contains a public key fingerprint and a 20-byte session challenge, and we have a matching Siemens public key in our vendored key store, _setup_session() now generates the 180-byte SecurityKeyEncryptedKey blob and includes it as a second item (address 1830) in the SetMultiVariables request. This is the pre-TLS authentication mechanism needed for V1-initial S7-1200 PLCs (FW < 4.5) where browse() currently fails. Changes: - Capture session challenge from CreateObject response (any 20-byte BLOB attribute in the PObject tree) - Store public key fingerprint string for key lookup - _try_session_key_auth(): look up public key, call authenticate_real_plc() to generate blob + session key - _encode_security_key_struct(): build the Struct(1800) PObject wrapping the blob with key descriptors - _setup_session(): conditionally include SecurityKey as Item 1 alongside ServerSessionVersion as Item 2 - Add SecurityKey struct IDs to protocol.py Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
This was referenced May 10, 2026
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
Ruff format applied to all new files, f-string lint fixes in transform13.py, and .bin files excluded from trailing-whitespace and end-of-file-fixer hooks (they corrupt binary test fixtures). Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
|
The PLC sends the 20-byte challenge as a USINT array (flags=0x10, type=0x02) at attribute 303, not as a BLOB. Confirmed from xBiggs's S7-1200 FW v4.2.2 debug logs. The previous heuristic looking for a BLOB never matched. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Owner
Author
|
@xBiggs Thanks for the logs! Found the issue — the challenge is at attribute 303 as a USINT array, not a BLOB. Fixed in f80dab3. Your key
Can you pull and test again? ```bash |
|
Inside S7CommPlus Structs, attributes are encoded as VLQ(absolute_id) without the 0xA3 PObject tag prefix. We were emitting 0xA3 + relative IDs (9, 10, ...) but the PLC expects VLQ-encoded absolute IDs (1801, 1802, ...). Also fix SecurityLevel type: USINT not UINT. Diagnosed from xBiggs's error 71171969 — the PLC couldn't parse our malformed struct.
Owner
Author
|
@xBiggs Found the bug — the SecurityKey struct was using PObject-style attribute encoding (0xA3 tag + relative IDs) but inside a Struct the protocol expects VLQ(absolute_id) without any tag prefix. Fixed in bbcaf6f. Can you test once more? Same install command: pip install --force-reinstall git+https://github.com/gijzelaerr/python-snap7.git@research/harpo-port-incomplete |
|
Two remaining byte-level mismatches vs the HarpoS7 PoC template: 1. BLOB inside Struct has an extra 0x00 before the VLQ length 2. Symmetric key flags in the SetMulti struct use flags | 0x10000 (e.g. 0x10101 for S7-1200, not 0x101)
Owner
Author
|
Looks like the connection setup completes now, but |
Owner
Author
|
The SessionKey handshake works! The empty Thanks for the patience testing all these iterations! |
After the SessionKey handshake succeeds, all data operations must use V3 framing with a 32-byte HMAC-SHA256 digest prefix. Without this, the PLC sends V254 non-responses and may RST the connection. V3 frame format: 72 03 [data_len] [0x20] [32-byte HMAC] [standard payload] trailer: 72 03 00 00 The HMAC is computed as HMAC-SHA256(session_key[:24], payload). Confirmed from TIA Portal v19 pcaps captured by xBiggs. Also handle V3 response frames by stripping the HMAC prefix before parsing the standard response header.
Owner
Author
|
@xBiggs ac84da7 adds V3 HMAC integrity framing. After the SessionKey handshake, all data ops now use V3 frames with a 32-byte HMAC-SHA256 prefix (computed from the session key), matching what TIA Portal does in your ProgramBlocks pcap. Can you test again? pip install --force-reinstall git+https://github.com/gijzelaerr/python-snap7.git@research/harpo-port-incompleteThis should fix the V254 responses — the PLC was rejecting our unsigned V1 requests after auth. |
|
Owner
Author
|
V3 HMAC framing works — the PLC accepted the signed EXPLORE request (no RST). But the V254 response is actually the PLC's native format for EXPLORE on V1-initial firmware. Looking at your TIA Portal ProgramBlocks pcap, TIA doesn't use EXPLORE at all — it uses GET_VAR_SUBSTREAMED (0x0586) for browsing. So the connection and framing are fully working now. The remaining For the immediate fix: can you test import logging
logging.basicConfig(level=logging.DEBUG)
from s7 import Client
client = Client()
client.connect("192.168.0.1", 0, 1)
print("protocol:", client.protocol)
data = client.db_read(7, 0, 2)
print("db7[0:2]:", data)
client.disconnect() |
V1-initial PLCs expect a 4-byte big-endian InObjectId in the EXPLORE payload instead of a VLQ-encoded explore_id. Match the format observed in TIA Portal v19 pcaps: InObjectId + fixed params + sequence byte. Default explore target is 0x38 (system object for PLC program tree), matching what TIA Portal sends.
Owner
Author
|
@xBiggs ef9aee0 fixes the EXPLORE payload format. Our code was sending a VLQ-encoded explore_id, but V1-initial PLCs expect a 4-byte big-endian InObjectId (like TIA Portal sends). Also targets object 0x38 (system PLC program tree) instead of root. pip install --force-reinstall git+https://github.com/gijzelaerr/python-snap7.git@research/harpo-port-incompleteTry both import logging
logging.basicConfig(level=logging.DEBUG)
from s7 import Client
client = Client()
client.connect("192.168.0.1", 0, 1)
print("explore:", client.explore())
print("browse:", client.browse())
client.disconnect() |
|
The first explore() call worked with V3 format, but list_datablocks() and browse() still used the old VLQ-based _build_explore_request. Route all EXPLORE calls through _build_explore_payload_v3 when a session key is present.
Owner
Author
|
@xBiggs Great news — the first EXPLORE returned real data ( pip install --force-reinstall git+https://github.com/gijzelaerr/python-snap7.git@research/harpo-port-incomplete |
|
Owner
Author
|
Good progress. The EXPLORE to 0x38 works and returns the program tree ( The program tree doesn't contain individual DBs — those need a deeper explore. TIA Portal uses The auth handshake and V3 HMAC framing are fully working now — this is purely a browse-level issue. I'll track the remaining browse work separately. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Complete port of the HarpoS7 Family-0 session-key authentication chain, enabling
browse()and other S7CommPlus data operations on V1-initial S7-1200 PLCs (FW < 4.5) that currently drop the connection after session setup._setup_session(): when the PLC's CreateObject response contains a known public key fingerprint and a session challenge, the 180-byte SecurityKeyEncryptedKey blob is automatically generated and included at address 1830What this fixes
V1-initial S7-1200 PLCs (FW v4.0–v4.4) require a
SessionKeyblob in the session-setup SetMultiVariables write. Without it, the PLC drops the connection. This PR generates that blob using the same crypto as TIA Portal, ported from HarpoS7 (MIT).Test plan
browse().New dependency
cryptography(for AES-ECB in the authenticator)Closes #710, closes #717
🤖 Generated with Claude Code