6.8 KiB
Reuters WNE Packet Format
Format is little endian.
Common bytes:
- Byte 0: always 0x00
- Byte 1: "Packet family", always 0x01, 0x03 or 0xff
- Bytes 2-3: Packet length
- Bytes 4-7: Session ID. This changes for every news story.
This format looks suspciously like it's TLV based, but I couldn't figure out how exactly the T's and L's are laid out. (Perhaps they use 2 bytes?) All multi-byte integers are little endian.
About byte 1
Byte 1 determines what kind of packet we're dealing with.
| Byte 1 | Packet Type |
|---|---|
| 0x01 | Object transfer |
| 0x03 | Object announcement |
| 0xfe | Unknown, but seems to be related to ECC |
| 0xff | Object end marker |
Packet familly 0x01 (Object transfer)
A packet of this type contains a single block of data.
| Byte Index | Description |
|---|---|
| 0 | always 0x00 |
| 1 | always 0x01 |
| 2-3 | Packet length |
| 4-7 | Session ID |
| 8-11 | dependent on value of 12-15 |
| 12-13 | Payload description |
| 14-15 | Payload description argument |
| 16-end | Payload |
- When bytes 12-15 are all zeroes, the payload is raw data. In this case bytes 8-11 are the Block ID. To reconstruct the object, concatenate all bytes of Block ID 0, then Block ID 1, and so on...
- When byte 12 is 0x05, and byte 14 is 0x09, then the payload is prefixed with an additional 16-byte header. It's purpose is not yet known. The actual payload starts at byte 32 then.
- When the payload description argument equals the total packet length minus 15, then the payload is another encapsulated WNE packet. Start reading from byte 16 all over again. If this is the case, the following ECC rules apply:
ECC rules
| Byte Index | Description |
|---|---|
| 8 | ECC group ID |
| 9 | ? |
| 10 | always 0x00 ? |
| 11 | ECC block counter, incremented by one each packet. If this is 0x07, the ECC group is finished, and the group ID will be incremented by one during the next packet. |
| 12 | When an ECC group is finished with byte 11 being 0x07, this contains the number of blocks that are supposed to be in this just finished ECC group. |
| 13 | usually 0x00, sometimes 0x20, purpose not known |
| 14-15 | If byte 12 is 0, then Packet length minus 15, If byte 12 is 0x07, then ? |
| 16-end | If ecc flags is 0x07, then this is an ECC payload, if ECC flags is 0x00, continue reading. |
Packet family 0x03 (Object announcement)
A packet of this type contains information about the file/object which is about to be transferred, or is transferred at this time in 0x01 packets.
| Byte Index | Description |
|---|---|
| 0 | always 0x00 |
| 1 | always 0x03 |
| 2-3 | Packet length |
| 4-7 | Session ID |
| 8-11 | Packet length - 8 |
| 12-15 | Packet length - 12 |
| 16-19 | always seems to be 0x00000000 |
| 20-23 | always seems to be 0x10000000 |
| 24-27 | always seems to be 0x02000070 |
| 28-31 | always seems to be 0x00000000 |
| 32-35 | always seems to be 0x97120a00 |
| 36-39 | always seems to be 0x00000000 |
| 40 | specifies a subformat. Observed values here are 0x02 and 0x09 |
When byte 40 is 0x09
This indicates that the following object transfer does not contain a file, but a series of further encapsulated WNE packets. Those can be read using the same technique/structure.
When byte 40 is 0x02
This indicates that the following object transfer contains a file.
| Byte Index | Description |
|---|---|
| 44-45 | Packet length - 44 |
| 46-55 | unknown |
| 55-56 | size of each block (usually 1408, but may differ) |
| 57-63 | unknown |
| 64-67 | number of blocks in this object |
| 68-71 | unknown |
| 72-75 | also number of blocks in this object |
| 76-84 | unknown |
| 85-n | UTF-8 null terminated source file name |
| n+0 - n+54 | unknown |
| n+55 - n+59 | file length in bytes |
| n+60 - n+71 | unknown |
| n+72 - m | UTF-8 null terminated destination file name |
| m - end | unknown |
Packet family 0xff (Object end marker)
When a packet of this type is encountered, the object transfer is complete, and the packets can be assembled. These packets may appear multiple times, Sometimes these packets are stuffed with multiple 0x00 bytes.