Hello Every one
I'm currently working on a project that takes data from patients monitors and send them to another system that we built (Not the central station -which display all monitors- which is already working but it is closed source.).
The monitor is supplied with an Ethernet card and it sends data over the UDP protocol. But when we need to read real data which is in the application layer we understand nothing.
Here is a small frame we get from the traffic when the monitor talks to the central station.
0000 ff ff ff ff ff ff 66 76 84 00 18 73 08 00 45 00
0010 00 2e 00 00 40 00 40 11 7a 03 c0 a8 00 14 ff ff
0020 ff ff a4 10 1f 42 00 1a 04 45 ff d0 00 02 00 fe
0030 00 0a 32 01 02 03 04 05 0b 32 33 50
When I but it on wireshark it analyze until the UDP protocol and stop, it doesn't understand the application layer data.
Here is a sample application layer data.
ff d0 00 02 00 fe 00 0a 32 01 02 03 04 05 0b 32 33 50
Another one:
ff da 7f f1 00 04 00 0c 02 18 0d 0f 60 0c 04 0b 0b 10 00 00
Are there any standard protocols that used in medical field to transport data like ECG, respiration, etc.? And is there a protocol that is compatible with the form above?
Please stop there!
Get the specification or documentation from the vendor and do not reverse engineer the protocol. If you are unable to do so, leave this thing alone.
If you get it wrong you are endangering patients. Doctor may rely on your information which you are guessing as it seems.
Even if it something well documented like HL7 oder DICOM read the documentation and talk with the vendor.
Depending on jurisdiction there may be a myriad of legal problems ahead.
It may be transmitting in HL7
http://www.hl7.org/index.cfm
Related
It's currently 04:40 AM and I am stuck on something I simply do not understand. I am trying to look up a domain's nameservers directly by using the DNS protocol. If I send a host -t ns google.com 1.1.1.1 and monitor it with Wireshark, I can see the full query of the DNS query. However, I cannot figure out, why some ASCII characters are used one time, but not another time. Here is an example:
0000 70 4d 7b 94 dd e0 00 d8 61 a9 c5 ec 08 00 45 00 pM{.....a.....E.
0010 00 38 d6 ff 00 00 80 11 9f 50 c0 a8 01 bb 01 01 .8.......P......
0020 01 01 e8 40 00 35 00 24 a0 19 9e f7 01 00 00 01 ...#.5.$........
0030 00 00 00 00 00 00 06 67 6f 6f 67 6c 65 03 63 6f .......google.co
0040 6d 00 00 02 00 01 m.....
In this DNS query, I am looking up the nameservers for google.com. The actual query starts at 06 07.
06 in ASCII is ACK/Acknowledgment.
Now, if we take a look at gmail.com instead:
0000 70 4d 7b 94 dd e0 00 d8 61 a9 c5 ec 08 00 45 00 pM{.....a.....E.
0010 00 37 d7 00 00 00 80 11 9f 50 c0 a8 01 bb 01 01 .7.......P......
0020 01 01 e8 58 00 35 00 23 8f cc 6f e2 01 00 00 01 ...X.5.#..o.....
0030 00 00 00 00 00 00 05 67 6d 61 69 6c 03 63 6f 6d .......gmail.com
0040 00 00 02 00 01 .....
the query starts at 05 67 instead.
05 is ENQ/Enquiry.
Why are they different? If I try to send 06 instead of 05 the DNS server gives me no response but Wireshark tells me:
Unknown extended label
I've seen 05, 06, and 09 so far. 09 is my biggest "wat" of all time, because it's a HT/Horizontal Tab.
Anyone with a lot of DNS knowledge who can help me here? I'm not looking for "just use dig/nslookup/host command". I'm currently trying to research a bit on the DNS protocol, and this is a thing I do not understand.
Good read where I got a lot of help: http://dev.lab427.net/dns-query-wth-netcat.html
For a binary protocols like this, you can't assume each byte corresponds to the matching ASCII character.
Take a look at section 4.1.2 of the DNS RFC (https://www.ietf.org/rfc/rfc1035.txt).
The domain name in a DNS request is broken up into "labels". For each label, the first byte is the length of the label, then the bytes for the string are written.
For your Google.com example, the labels are "google" and "com". The 06 is the number of bytes in the first label. This is followed by the bytes for "google". Then the 03 is the number of bytes in the "com" label. After the "com" bytes, the 00 byte is the NULL label to mark the end.
I am trying to take part in a CTF challenge. I have a pcap file of a jpg file transfer. I know that the jpg starts with FF D8 FF and ends with FF D9.
The problem is that I have no idea how to extract the file itself.
The file is in here:
00000226 67 0d 0a 0d 0a ff d8 ff e0 00 10 4a 46 49 46 00 g....... ...JFIF.
00000236 01 01 00 00 01 00 01 00 00 ff db 00 43 00 03 02 ........ ....C...
..
00015617 d2 51 95 15 f7 e1 c0 d8 e9 6d 58 c8 07 71 c7 40 .Q...... .mX..q.#
00015627 3a 79 53 19 33 54 00 05 b4 92 07 33 5e af 54 2d :yS.3T.. ...3^.T-
00015637 1f ff d9 ...
As you can see it's mixed with 67 0d 0a 0d and the other information. I tried to copy the relevant parts and cut out the offset and ascii (?) section left and right with python and then imported the hexdump to this site to create a jpg of the hex dump.
Unfortunately that didn't work. The resulting image is extremely distorted and I can't read anything on it.
Does anyone have an advice? Not a full solution, just a tip so I can wrap my head around it myself.
Thanks.
This question is unlikely to help any future visitors; it is only relevant to a small geographic area, a specific moment in time, or an extraordinarily narrow situation that is not generally applicable to the worldwide audience of the internet. For help making this question more broadly applicable, visit the help center.
Closed 9 years ago.
I've recorded some network traffic in my home that only appear up while running BitTorrent or uTorrent.
I've been reading the bittorrent protocol descriptions, but I am stuck trying to figure out a particular network flow.
Can someone help me identify what the following bittorrent network traffic is exactly?
It lasts quite a long time, even after stopping downloads.
All packets are in one direction - from my local machine running Bittorrent to a remote machine.
Here is data payload of one packet (copied from Wireshark):
00000000 60 00 00 00 00 00 3b 15 20 01 00 00 9d 38 6a b8 `.....;. ....8j.
00000010 04 b9 18 bf 9c 90 d8 81 20 01 00 00 9d 38 6a b8 ........ ....8j.
00000020 20 5a 01 45 bd 13 b1 65 01 04 44 4a e7 d5 04 04 Z.E...e ..DJ....
00000030 01 00 00 00 05 02 ea cf ........
All the packets in the network flow are similar, here are two more:
00000038 60 00 00 00 00 00 3b 15 20 01 00 00 9d 38 6a b8 `.....;. ....8j.
00000048 04 b9 18 bf 9c 90 d8 81 20 01 00 00 9d 38 6a b8 ........ ....8j.
00000058 20 5a 01 45 bd 13 b1 65 01 04 08 8e 35 9f 04 04 Z.E...e ....5...
00000068 01 00 00 00 05 02 ea cf ........
00000070 60 00 00 00 00 00 3b 15 20 01 00 00 9d 38 6a b8 `.....;. ....8j.
00000080 04 b9 18 bf 9c 90 d8 81 20 01 00 00 9d 38 6a b8 ........ ....8j.
00000090 20 5a 01 45 bd 13 b1 65 01 04 12 3e ba 6c 04 04 Z.E...e ...>.l..
000000A0 01 00 00 00 05 02 ea cf ........
These bittorrent packets are typically several seconds apart, and this flow seems to go on indefinitely. Which one of the bittorrent protocols describes this network flow?
I just sent a response to you on our mailing list, but I'm gonna post here too in case anyone else stumbles across it and finds it useful.
They're Teredo packets (with no payload). Wireshark can decode these
but it doesn't do so without coercion.
http://en.wikipedia.org/wiki/IPv6_packet
http://en.wikipedia.org/wiki/Teredo_tunneling
One of your packets dissected:
IP Version: 6
Traffic Class: 0 0
Flow Label: 0 00 00
Payload Length: 00 00
Next Header: 3b (indicates that there is no payload present)
Hop Limit: 15
Source: 20 01 00 00 9d 38 6a b8 04 b9 18 bf 9c 90 d8 81
Destination: 20 01 00 00 9d 38 6a b8 20 5a 01 45 bd 13 b1 65
The source and destination also encode the source and destination
public ipv4 addresses and ports.
The hop-by-hop options header (in type-length-value format) follows in
this case. The possible types can be found here:
http://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xml
So we have this:
01 04: c3 ae 60 38 ("PadN", random bytes)
04 04: 01 00 00 00 ("Tunnel Encapsulation Limit")
05 02: ea cf ("Router Alert")
No clue what the value of the router alert field is here. I would
expect it to be listed here:
http://www.iana.org/assignments/ipv6-routeralert-values/ipv6-routeralert-values.xml
But it looks like either that's out of date or the Teredo
implementation you're using is doing something non-standard (or
there's something I've missed).
Anyways, these are clearly keep-alive packets. We're not directly
triggering them in the client as far as I know. I believe they're sent
by your Teredo driver to keep your tunnels open.
I need to sort out something about the IPv4 header. For example the following frame with an Ethernet-II frame with an IPv4 packet starting at the fifteenth byte.
0000: 08 00 20 7c 94 1c 00 00 - 39 51 90 37 08 00 45 00
0010: 00 3e 36 00 00 00 80 11 - da 4f 82 eb 12 7f 82 eb
0020: 12 0a 04 01 00 35 00 2a - ee 6a 00 01 01 00 00 01
0030: 00 00 00 00 00 00 06 67 - 65 6d 69 6e 69 03 6c 64
0040: 63 02 6c 75 02 73 65 00 - 00 01 00 01
I need to sort somethings out:
What does the 0000 & 0010 & 0020 & 0030 on the left stands for?
I just cant sort it out is 1 pair for example the first one 08 two bits or?
And if the IPv4 starts at fifteenth byte(1 byte = 8 bits) where does it start then, have problems to understand this because i dont get number 2.
Thank you for your time.
”45” in your first line of hexdump is the 1st byte of the ip header (15th byte of the ethernet frame). Each line is 16 bytes.
Also, in the beginning of each line has an offset like e.g. ”0010: ” (in hex) means the starting offset from the start of the whole dump.
Your first line would be, (total 16 bytes),
dmac(6)+smac(6)+etype(2)+ first2byte_of_ip(2)
and your first byte of ip is hex ”45”, you can lookup the detail ip header field in wikipedia.
It would be nice if you can read wireshark user's guide on your own. Anyway, to answer your question,
1) What does the 0000 & 0010 & 0020 & 0030 on the left stands for?
It stands for hexdump offset. You can refer to this page.
2) I just cant sort it out is 1 pair for example the first one 08 two bits or?
It is (part of ) destination MAC address. Entire MAC address should be 08 00 20 7c 94 1c.
3) since Q2 is now answered, this should not be problem for you.
I started a thread in the NI support forums about my project, but my current problem is more broad than just driver writing in labview. I have an anemometer that uses a USB UART bridge
to interface with the computer. I asked Extech for any kind of documentation for and received only the communication protocol below.
Serial Communication Protocol
I encountered several problems working with this, so I took the software included with the anemometer and used portmon to sniff the commands going to and from, and here's where it gets worse. To simplify matters as best as I could, I only took ambient temperature readings. The following was what portmon captured when I used the manufacture's software to connect to the instument:
(This is the 'upload protocol' on the above protocol documentation)
AA 61 64 6A 67 08 40 00 40 00 01 00 00 C6 41 00 00 00 00 00 3C 1C C6 9A 19 99 42 00 3C 1C C6 00 00
AA 61 64 6A 67 08 40 10 40 00 01 7D 0C C6 41 00 00 00 00 00 3C 1C C6 39 1F 99 42 00 3C 1C C6 00 00
AA 61 64 6A 67 08 40 10 40 00 01 00 00 C6 41 00 00 00 00 00 3C 1C C6 9A 19 99 42 00 3C 1C C6 00 00
AA 61 64 6A 67 08 40 10 40 00 01 83 F3 C5 41 00 00 00 00 00 3C 1C C6 FB 13 99 42 00 3C 1C C6 00 00
This is slightly truncated, but the important parts should be there. The ambient temperature read about 76.5F at the time. So according to the documentation, this should be in the 10-13th bits, so I believe:
0000c641
7d0cc641
0000c641
83f3c541
To be the recorded ambient temperatures, but I have no idea how to read this. I see no reason why a conversion from Kelvin or Celsius would be necessary as there seems to be a bit for that in F1. Also of note is the fact that I get values completely different than anything documented for several fields, so either I'm reading something wrong or the documentation is just wrong. I haven't been able to get any more answers from the manufacturer about the protocol, so I have no idea why my data only half resembles what is expected.
41C60000 converts to 24.75 as an IEEE754 standard 32-bit single precision float. This looks like a Celsius value which would map to 76.55 F.
For the rest of the data you would have :
41C60000 = 24.7500000000000000000
41C60C7D = 24.7560977935791015625
41C5F383 = 24.7439022064208984375
I think that sorts out the endianness and formatting for you.