Log port not decoded + TLS decode?

[aggedor2]

I noticed when using the Baichuan Wireshark dissector that any messages to the Reolink P2P server log port (57850) don't seem to get decoded. Is that a bug or just not implemented yet? I assume they are XML strings the same as messages to the Reg port.

I also wondered whether its possible to use any of the information that's used to decode the Baichuan messages to decode the TLS streams that are initiated whenever a PIR event occurs and video clips are sent to Reolink's storage on AWS. Is that possible or not?

[QuantumEntangledAndy]

I have never looked into the details of what gets sent to the log port. Do you have any packets I could see with the data? You can usually tell if it is xml because the first few bytes are usually the same being an encoded form of <?xml

I haven't seen anything about TLS in the bc messages. I suspect they are undecodable without the private key that is on their severs.

[QuantumEntangledAndy]

If you really want into the TLS you might have to consider more drastic measures like: setting up a man in the middle/unpacking the firmware find a way to force it not use tls then repacking the firmware and deploying it

[aggedor2]

What's the best way to share? Copy and paste a frame to Log port below, or you need the actual pcap file?

0000 a2 78 17 d5 36 64 2c ab 33 1f d8 c2 08 00 45 00 .x..6d,.3.....E.
0010 01 3a 00 09 00 00 80 11 38 91 c0 a8 02 03 36 d2 .:......8.....6.
0020 07 9c d3 73 e1 fa 01 26 c8 fa 31 cf 87 2a e6 00 ...s...&..1....
0030 00 00 00 00 00 00 ff ff ff ff 00 00 00 00 39 35 ..............95
0040 32 37 30 30 30 31 4e 34 53 46 36 39 35 4f 00 00 270001N4SF695O..
0050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 8c e9 ................
0060 fa 59 77 4c 1f 6f b3 43 09 2c 3f 10 26 04 75 06 .YwL.o.C.,?.&.u.
0070 07 f6 15 26 4b ef b5 92 f8 94 82 d2 46 b6 90 e6 ...&K.......F...
0080 c2 23 7b 00 02 6b e4 12 09 64 77 5a 7e 55 3f 19 .#{..k...dwZ~U?.
0090 1e ec 4e 24 12 b5 ee c7 f6 95 88 ce 05 ea c8 b6 ..N$............
00a0 88 78 25 59 13 23 f9 06 1c 3f 75 19 2b 17 2e 1a .x%Y.#...?u.+...
00b0 01 e7 15 26 4c f4 be 9b a7 c2 8a d1 4d ac d6 a1 ...&L.......M...
00c0 94 7b 2a 5b 13 23 eb 0d 01 64 7b 1f 27 0f 05 56 .{[.#...d{.'..V
00d0 40 b7 74 29 0a b4 87 c5 f2 9c 88 ce 17 f1 c8 ed @.t)............
00e0 ce 64 32 4f 59 76 e0 1a 52 68 7b 1e 22 08 6e 5f .d2OYv..Rh{.".n_
00f0 5e f1 52 69 4b ef b5 92 f8 99 c1 87 4f b2 99 fc ^.RiK.......O...
0100 87 71 75 00 4c 7b fd 0b 52 6a 77 01 76 5c 2a 17 .qu.L{..Rjw.v*.
0110 4f be 49 7b 4b b8 e4 95 a5 9b 99 d5 40 bb 99 fc O.I{K.......@...
0120 90 74 75 00 41 70 fa 41 5c 66 64 42 78 4f 64 5f .tu.Ap.A\fdBxOd_
0130 01 e1 5f 24 0e b2 e4 d8 b6 c6 c0 df 4d ac c7 b2 .._$........M...
0140 86 29 77 13 5d 2d fd 41 .)w.]-.A

[QuantumEntangledAndy]

The pcap would be better perhaps filtered to a few samples

[aggedor2]

Log Sample.pcapng.zip

Here you go

[QuantumEntangledAndy]

Interesting it's not something we have looked into decoding. Is 270001N4SF695O your UID

[QuantumEntangledAndy]

magic	payload size	unknownA	unknownB	unknownC	UID?	unknownD	payload
31CF872A	E6000000	00000000	FFFFFFFF	00000000	39353237 30303031 4E345346 3639354F 00000000 00000000 00000000 00000000	8CE9FA59	230 bytes

I've tried decrypting the payload using unknownB and unknownD as a key but netiher worked. It may just be binary

[aggedor2]

Yes, my UID as shown in the APP is 95270001N4SF695O
Wireshark Baichuan for Reg port shows it as 95270001N4SF695O70N0

[aggedor2]

I noticed a strange issue that's cropped up in Wireshark where the first 2 Baichuan transactions are now being listed as TP-Link Smart Home Protocol. This is a capture that I made a week ago and have been looking at since. The pcap file hasn't changed. How could that happen? I think there was a Wireshark update to version 3.6.0 during the week, that's the only thing I can think of. It's frames 1046 and 1047 in the screenshot. You can see that 1046 is actually to the Reolink P2P server, port 9999. It was decoded correctly all last week. Now it's not. Any ideas?

.

[QuantumEntangledAndy]

Not sure, we use Heurestics to decide if the a packet is bc or not.

neolink/dissector/baichuan.lua

Lines 720 to 745 in 324d14e

	local function heuristic_checker_udp(buffer, pinfo, tree)
	-- guard for length
	local length = buffer:len()
	if length < 4 then return false end
	local potential_magic = buffer(0,4):le_uint()
	if potential_magic ~= 0x2a87cf3a and
	potential_magic ~= 0x2a87cf20 and
	potential_magic ~= 0x2a87cf10 and
	potential_magic ~= 0x2a87cf31 then
	return false
	end
	if added_udp_ports[pinfo.dst_port] == nil then
	table.insert(added_udp_ports, pinfo.dst_port)
	DissectorTable.get("udp.port"):add(pinfo.dst_port, bc_protocol)
	end
	if added_udp_ports[pinfo.src_port] == nil then
	table.insert(added_udp_ports, pinfo.src_port)
	DissectorTable.get("udp.port"):add(pinfo.src_port, bc_protocol)
	end
	bc_protocol.dissector(buffer, pinfo, tree)
	return true
	end

Assuming you haven't changed the lua file. I can think of a few reasons why this might happen. 1. Your update includes updated TPLink packet detection that is overzealous, 2. There is a change in priority over which dissector gets to claim a packet, 3. There is a race condition where if two dissectors match a packet the last/first one to run will win

[aggedor2]

Think it's probably 1. In any case, disabling TP-Link Smart Home in Enabled Protocols gets it out of the way.