from gurux_dlms.objects import GXDLMSImageTransfer
from gurux_dlms.enums import ImageTransferStatus

def perform_ota_firmware_upgrade(client, reader, firmware_bytes, signature_der):
    it = GXDLMSImageTransfer("0.0.44.0.0.255")
    block_size = 200
    
    # 1. Initiate Transfer (Image Identifier: "V3.2.0")
    print("[*] Initiating Image Transfer...")
    reader.method(it, 1, ("V3.2.0".encode(), len(firmware_bytes)))
    
    # 2. Transfer Blocks (Zero-Indexed: 0 to N-1)
    total_blocks = (len(firmware_bytes) + block_size - 1) // block_size
    for block_num in range(total_blocks):
        chunk = firmware_bytes[block_num*block_size : (block_num+1)*block_size]
        reader.method(it, 2, (block_num, chunk))
        if block_num % 100 == 0:
            print(f"    Transferred block {block_num}/{total_blocks}")
            
    # 3. Verify Signature (ASN.1 DER encoded ECDSA P-256)
    print("[*] Verifying Image Signature...")
    reader.method(it, 3, signature_der)
    
    status = reader.read(it, 6)
    assert status == ImageTransferStatus.VERIFICATION_SUCCESSFUL, f"Verification failed! Status: {status}"
    print("[+] Firmware Image verified successfully! Ready for activation.")

Summary Checklist for Class 18 Image Transfer:

1. Block Indexing: Always start block numbers at 0 (Blue Book Section 4.3.8).
2. Signature Encoding: Confirm whether firmware expects ASN.1 DER (71B) or raw P1363 (64B).
3. Digest Pre-image: Verify if image_identifier is included in SHA-256 digest.
4. Activation Handling: Prepare for immediate TCP connection reset upon Method 4.

00 01 00 01 00 01 00 07 C7 01 C1 00 00

• C7 01: Action-Response-Normal
• C1: Invoke-ID 1
• 00: Result success (verification initiated)

Reading Attribute 6 (image_transfer_status) returns 0x03 (verification_successful).

If cellular NB-IoT or G3-PLC drops blocks 45, 112, and 205:
HES reads Attribute 3 (Bit-String) or Attribute 4 (image_first_not_transferred_block_number), locates the first zero bit, and retransmits ONLY the missing blocks before calling Method 3.

Signature ::= SEQUENCE {
  r  INTEGER (32 bytes with leading 0x00 if MSB is set),
  s  INTEGER (32 bytes with leading 0x00 if MSB is set)
}

Hex encoding:
30 45 02 21 00 [R_32B] 02 20 [S_32B] (Total: 71 bytes).

When passed inside Action-Request for Method 3 (0.0.44.0.0.255), the meter's public key successfully validates the image digest.

Per DLMS Blue Book Section 4.3.8 Method 4:
image_activate takes (activation_time: Octet-String).

If you want immediate activation, what parameter should be passed?

• In DLMS standard, passing an empty date/time (0x09 0x00) or wildcard timestamp (0xFF...) triggers immediate reboot and image activation.
• However, during reboot, the TCP socket will close with a FIN or RST. HES must NOT treat this socket closure as a communication failure.

1. Our HES was transmitting block numbers starting at 1 (1 to 980). The meter's bitmask had bit 0 clear (0x7F...), meaning the firmware considered block 0 missing!
2. Our crypto module was expecting a standard ASN.1 DER signature (71 bytes), but HES transmitted a raw 64-byte $(R \parallel S)$ buffer.

Once we adjusted HES to start block transmission at block_number = 0 and encoded the ECDSA P-256 signature in ASN.1 DER, image_verify took 1.4 seconds and transitioned cleanly to image_transfer_status = 3: verification_successful!

Per DLMS Blue Book Ed. 17 Section 4.3.8 Table 19:

• Attribute 3 is a Bit-String where bit $i = 1$ indicates block $i$ has been received.
• Zero-Based vs One-Based Indexing:
  In DLMS, block numbers in image_block_transfer are 0-indexed (block_number: 0 to block_number: N-1).
  If your HES sent block numbers starting from 1 up to 980, block 0 was never transferred!
  Attribute 4 would report image_first_not_transferred_block_number = 0, causing Method 3 image_verify to fail instantly because the image is incomplete!

Per DLMS Green Book 10th Ed Section 9.2.5.3 (Security Suite 1 & 2 Digital Signatures):
The digital signature is generated over the SHA-256 digest of the unpadded, raw application image, NOT the concatenated transport blocks!

The Two Major Image Hashing Traps:

1. Image Identifier Inclusion: Some meter vendors include image_identifier (Attribute 6, Octet-String) and image_size (Double-Long-Unsigned) in the SHA-256 hash pre-image ($H = \text{SHA256}(\text{ImageIdentifier} \parallel \text{ImageBytes})$);
2. Last Block Padding: If your 980th block was 160 bytes and your HES padded it with zeros to 200 bytes, the hash mismatch occurs immediately.

Per DLMS Blue Book Ed. 17 Section 4.3.8 (Image Transfer) and IEC 62056-62 Section 6.2.16:
Method 3 image_verify takes an integer parameter (typically 0) or an octet-string containing the digital signature depending on the firmware profile.

The Cryptographic Discrepancy:

1. Raw IEEE P1363 Format (64 Bytes): $\text{Signature} = R_{32\text{ bytes}} \parallel S_{32\text{ bytes}}$.
2. ASN.1 DER Format (70-72 Bytes):
   0x30 [len] 0x02 [r_len] [R...] 0x02 [s_len] [S...]

In your Action-Request hex:
You passed a 64-byte raw Octet-String (Tag 0x09 0x40). If the meter firmware uses mbedTLS, OpenSSL, or micro-ecc configured to parse standard ASN.1 DER structures, the DER parser expects tag 0x30 at byte 0. When it sees 0x4A, it fails ASN.1 parsing and flags verification_failed!