Project Logs

Collapse

• INFORMED HEX DUMP

  Gabriel • 04/21/2020 at 00:03 • 1 comment

  66 03 60 4D F5 
  66 03 C0 SOH DE 1D 40 E5 #62 E7 41 EE 70 48 4F 52 50 43 35 33 32 34 37 36 19 06 22 06 22 SOH10 46 30 46 19 SOH42 70 40 40 40 40 40 40 30 30 31 38 30 33 35 33 32 34 37 36 4B 08 08 DC C1 C1 32 DC C1 C1 32 42 B4 42 B4 02 SOH02 02 02 02 02 3C SOH6D 92 86 80 1A D6 89 62 E7 41 EE C5 CE 41 6C 31 74 42 33 3F 80 3F 80 14 29 
  66 03 26 FC 11 46 A9 
  66 03 22 90 E5 26 30 07 90 40 18 03 53 24 76 38 BD 95 
  66 03 26 BE 1C 27 78 
  66 03 38 16 SOH 2C 65 36 EA 0A SOH09 70 48 4F 52 50 43 35 33 32 34 37 36 13 ~

  66 03 60 4D F5 
  66 03 C0 SOH AE 94 40 E5 # 5F D3 41 EE 70 48 4F 52 50 43 35 33 32 34 37 36 19 06 22 06 22 SOH 10 46 30 46 19 SOH 42 70 40 40 40 40 40 40 30 30 31 38 30 33 35 33 32 34 37 36 4B 08 08 33 C6 C1 2D 33 C6 C1 2D 42 B4 42 B4 02 SOH 02 02 02 02 02 3C SOH 6D 8D E3 80 1A BF 89 5F D3 41 EE BF A6 41 6C 2F EA 42 33 3F 80 3F 80 9E 77 
  66 03 26 FC 11 46 A9 
  66 03 22 90 E6 26 30 07 90 40 18 03 53 24 76 38 09 95 
  66 03 26 BE 1C 27 78 
  66 03 38 16 SOH 2C 65 36 EA 0A SOH 09 70 48 4F 52 50 43 35 33 32 34 37 36 13 ~

  66 03 60 4D F5 
  66 03 C0 SOH AE 94 40 E5 # 5F D3 41 EE 'p' 'H' 'O' 'R' 'P' 'C' '5' '3' '2' '4' '7' '6' 19 06 22 06 22 SOH 10 46 30 46 19 SOH 42 70 40 40 40 40 40 40 '0' '0' '1' '8' '0' '3' '5' '3' '2' '4' '7' '6' 4B 08 08 33 C6 C1 2D 33 C6 C1 2D 42 B4 42 B4 02 SOH 02 02 02 02 02 3C SOH 6D 8D E3 80 1A BF 89 5F D3 41 EE BF A6 41 6C 2F EA 42 33 3F 80 3F 80 9E 77 
  66 03 26 FC 11 46 A9 
  66 03 22 90 E6 26 30 07 90 40 [18 03 53 24 76] 38 09 95 
  66 03 26 BE 1C 27 78 
  66 03 38 16 SOH 2C 65 36 EA 0A SOH 09 'p' 'H' 'O' 'R' 'P' 'C' '5' '3' '2' '4' '7' '6' 13 ~

  So Above you can see more or less what the BUS looks like in HEX. there are 3 instances/bursts of the communications. 

  The last instance Ive modified a bit more for your ease.

  all bursts share many of these mods, but start with the last one.

  Ive "processed" this a bit as follows. 

  1) All the NULLs have been removed.

  2) Ive at Character 0x7E ive added an \r\n and printed the char in ascii (~). i did this because it felt logical - just go with me on this one.

  3) Ive replaced all the 0x01 with the "word" SOH - Start of header. these might not be placed correctly because my capture script blindly swaps the byte for the symbol. so if you see one that looks wierd or out of place. just swap it with a 0x01

  4) char 0x04 has been replaced by the character '#'. i did this to clearly mark 2 known float values. The PH and Temperature Data are the 4 bytes directly before '#' and directly after, hi byte and low byte are swapped. they check out with the device screen reading.

  5) in the last comunication burst ive replaced what i KNOW to be Ascii with well.. ascii. I know these are correct because well, they match with the device lable and include the last 6 digits of the serial number

  6) ive marked 5 bytes between "[ ]" brackets. if you notice (look at the project pics) its the serial number of the gateway.  i dont know why in one part of the exchange they send it in ascii and in another in hex coded decimal...

  7) ive added a \r\n before each 0x66 Byte - It seemed logical, ive been looking at this for too long and maybe im finding patterns that dont exist.

  Anyways thats what i have for now.

• Some kind of Progress

  Gabriel • 04/20/2020 at 12:53 • 0 comments

  So, one thing that kept messing with me was that the packet length was never the same, which i though was pretty wierd. After many data dumps, and start, stop bit combinations, baud changes etc, i finally ended up reaching the conclusion that this was 8N1 at 19200 baud. I decided to try several older encoding/protocols like VT100, VT52, and the likes.

  FINALLY some insight. There are ALOT of blank spaces, or dummy bytes, most likely for timing/sync purposes. Im still unclear if the blank chars are NULL or 0x20 (ascii space).

  There are escape characters, but these do not seem to match with any known (by me atleast) protocol, yet some characters do seem to be standard escape chars like SOH (0x01).. the data contains binary data and Ascii, but i cant seem to figure out the escape sequence for when Ascii starts and ends. ASCII 85 Maybe? 

  This explains the unequal packet lenghts. Some packets need to include more or less escape chars, and thus pretty much no single hex dump was the same length.

  At some point i figured out where the "data" was in the packet, in the form of 2 float (4 bytes) variables ph and temp. I wrote a small script to ignore the blank spaces and print a text representation of all the usual escape characters, basically ascii 0x00 to 0x14....  basically on my terminal i got a bunch of hex but when the byte was a 0x00 it printed the word NULL... 

  This worked and i managed to evesdrop on the data bus and get PH and Temperature.... for a bit... a lot of data loss or wrong values. This was before i figured out that there are a lot of escape characters mixed in even with the data... which makes sense when you realize that a 4 byte float might contain a byte with the same value as an escape char or something along those lines.

  So... next up, do a plain Hex Dump of the bus, and write a new script that purifies the incoming data. If i manage to get a sustained output of PH and temp i will know im on the right path.

  I still cant figure out how the SC200 requests data or when the sensor response begins.

• Super Important details

  Gabriel • 03/20/2019 at 11:26 • 0 comments

  The device im trying to hack is the "Digital Gateway" used to attach sensors to a "Hach SC200". On the main PCB of the SC200 I found 2 RS485 chips ADM3483ARZ which confirms my initial thoughts on the physical layer.

  I have no futher info on the actual gateway as its a solid epoxy block and these devices are NOT CHEAP so destructive hacking is not an option.

  The through the gateway we get temperature and PH/ORP readings among other setup config testing infos. There is a complete modbus map available for the gateway/sensor which a normal user would use while talking to it THROUGH the SC200 which has an additional Optional modbus card (which i have).

  https://www.hach.com/digital-3-4-inch-combination-ph-orp-sensor-convertible-style-ryton-body-material-general-purpose-glass-ph-electrode-type-temperature-compensation-none/product-downloads?id=7640010699

  The manual is on the link above and it includes the modbus register map.

  Now to be clear: the gateway does not speak in modbus to the sc200.

  Im trying to AVOID using the SC200 and talk to the gateway directly.

• What its not

  Gabriel • 03/11/2019 at 21:57 • 0 comments

  As clearly seen by the log, the pattern repeats, changing only where the "Data" should be. there are 2 parameters being logged by this sensor.

  I thought this was straight modbus since the device already supports modbus, and the physical layer seems to be 485, but its not.

  I thought it might be CAN over 485, but its not.

  I thought it could be Profibus but you guessed it... its not.

View all 4 project logs