您将如何对从设备中提取的一组二进制数据进行逆向工程？
我的一个朋友前几天提出了这个问题，他最近购买了一个 Garmin 心率监测设备，可以跟踪他的心率并允许他将一天的心率统计数据上传到他的计算机。
唯一的问题是 Garmin USB 设备没有 Linux 驱动程序，他成功地解释了一些数据，例如型号和用户详细信息，并确定存在一些二进制数据表，我们假设这些数据表代表一系列记录他的心率和记录时间。
当您对结构一无所知时，对数据进行逆向工程时从哪里开始？
A friend of mine brought up this questiont he other day, he's recently bought a garmin heart rate moniter device which keeps track of his heart rate and allows him to upload his heart rate stats for a day to his computer.
The only problem is there are no linux drivers for the garmin USB device, he's managed to interpret some of the data, such as the model number and his user details and has identified that there are some binary datatables essentially which we assume represent a series of recordings of his heart rate and the time the recording was taken.
Where does one start when reverse engineering data when you know nothing about the structure?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（8）
不确定这是否是您正在寻找的，但 Garmin 已经创建了一个可与您的浏览器一起运行的 API。 看来 OSX 以及 Windows 浏览器都受支持...我会从 Google Chromium 尝试一下，看看是否可以使用它来代替这种逆向工程...
http://developer.garmin.com/web-device/garmin-communicator-plugin/
API 功能
Unsure if this is what you're looking for but Garmin has created an API that runs with your browser. It seems OSX is supported, as well as Windows browsers... I would try it from Google Chromium to see if it can be used instead of this reverse engineering...
http://developer.garmin.com/web-device/garmin-communicator-plugin/
API Features
你能用电脑扬声器之类的东西合成心跳吗？ （我不知道这些设备实际上是如何工作的）。 观察二进制结果如何根据不同的输入而变化。
拆开设备并检查里面的内容可能也会有所帮助。
Can you synthesize a heart beat using something like a computer speaker? (I have no idea how such devices actually work). Watch how the binary results change based on different inputs.
Ripping apart the device and checking out what's inside would probably help too.
我遇到了同样的问题，最初在 Google Code 上发现了这个项目，旨在为 Garmin 设备完成跨平台版本的工具......请参阅：http://code.google.com/p/garmintools/。 该项目的首页上有一个指向您所需协议的链接，Garmin 考虑周全，将其公开发布。
这里是 Garmin I/O 规范的直接链接： http://www.garmin .com/support/pdf/IOSDK.zip
I had the same problem and initially found this project at Google Code that aims to complete a cross-platform version of tools for the Garmin devices ... see: http://code.google.com/p/garmintools/. There's a link on the front page of that project to the protocols you need, which Garmin was thoughtful enough to release publically.
And here's a direct link to the Garmin I/O specification: http://www.garmin.com/support/pdf/IOSDK.zip
我首先会查看设备正在发送哪些数据，然后考虑如何表示和打包这些数据。
我会首先捕获许多样本，看看是否存在任何模式，因为心跳是有规律的，这表明它是与心脏本身相关的测量。 我还会寻找单调递增的位字段，因为这会暗示某种时间戳。
在形成了“什么在哪里”的假设后，我会编写一个程序来测试它并绘制结果，看看它是否有意义。 如果确实如此，但不完全如此，那么仔细检查可能会发现您在这里或那里需要一些缩放因子。 我也完全有可能需要先处理数据，然后它看起来像他们的程序显示的那样，即可能需要集成数据点。 如果我得到垃圾，那么它又回到了绘图板:-)
我还会检查制造商的网站，或者可能在他们的二进制文件上运行
strings。 寻找在生物医学工程领域工作的人也会在我的名单上，因为他们可能知道通常使用哪些协议（如果有）。 我还会寻找这些协议，看看是否有任何协议可以应用于我所看到的数据。I would start by seeing what data is being sent by the device, then consider how such data could be represented and packed.
I would first capture many samples, and see if any pattern presents itself, since heart beat is something which is regular and that would suggest it is measurement related to the heart itself. I would also look for bit fields which are monotonically increasing, as that would suggest some sort of time stamp.
Having formed a hypothesis for what is where, I would write a program to test it and graph the results and see if it makes sense. If it does but not quite, then closer inspection would probably reveal you need some scaling factors here or there. It is also entirely possible I need to process the data first before it looks anything like what their program is showing, i.e. might need to integrate the data points. If I get garbage, then it is back to the drawing board :-)
I would also check the manufacturer's website, or maybe run
stringson their binaries. Finding someone who works in the field of biomedical engineering would also be on my list, as they would probably know what protocols are typically used, if any. I would also look for these protocols and see if any could be applied to the data I am seeing.我开始在十六进制编辑器中查看数据，希望是一个知道最常见编码（ASCII、Unicode 等）的好编辑器，然后尝试从您知道它存储的数据中理解它。
I'd start looking at the data in a hexadecimal editor, hopefully a good one which knows the most common encodings (ASCII, Unicode, etc.) and then try to make sense of it out of the data you know it has stored.
正如另一位发帖者提到的，逆向工程可能很棘手，不是在实践中，而是在合法性方面。
话虽这么说，您也许可以通过查看这个项目及其代码来找到与您手头的根本问题相关的所有内容......并且它们也确实处理跑步者的心率/GPS 组合数据
http://www.gpsbabel.org/
As another poster mentioned, reverse engineering can be hairy, not in practice but in legality.
That being said, you may be able to find everything related to your root question at hand by checking out this project and its' code...and they do handle the runner's heart rate/GPS combo data as well
http://www.gpsbabel.org/
我建议您首先检查逆向工程在您所在国家/地区的合法性。 大多数国家/地区对于逆向工程设备和代码的允许和禁止行为都有非常严格的法律。
I'd suggest you start with checking the legality of reverse engineering in your country of origin. Most countries have very strict laws about what is allowed and what isn't regarding reverse engineering devices and code.
我首先创建数据的十六进制转储。 认为它可能被阻塞在一些二次方大小的块中。 开始寻找重复的模式。 想想他们可能发送什么样的数据。 他们要么单独记录每次心跳，要么记录传感器以固定时间间隔发送的任何内容。 如果是单独的节拍，那么将会有时间增量（自最后一个节拍以来）、持续时间以及某种最大或平均强度。 如果它是固定间隔，那么它可能是一个简单的读数向量。 可能会有某种前导码，带有开始时间戳和采样率。 您可以尝试自己解码时间戳，或者您可以尝试简单地将其提供给
ctime()并查看它们是否使用标准绝对时间格式。请记住，许多廉价的 A/D 转换器仅产生 12 位输出，因此您的读数不可能大于 16 位（并且高位 4 位可能用于标志）。 我建议重置设备，使其处于“空白”，转储并存储内容，然后获取一组读数，记录结果（无论设备正常报告什么），然后再次转储内容并尝试关联记录的结果“空白”转储后出现的任何数据。
I'd start by creating a hex dump of the data. Figure it's probably blocked in some power-of-two-sized chunks. Start looking for repeating patterns. Think about what kind of data they're probably sending. Either they're recording each heart beat individually, or they're recording whatever the sensor is sending at fixed intervals. If it's individual beats, then there's going to be a time delta (since the last beat), a duration, and a max or avg strength of some sort. If it's fixed intervals, then it'll probably be a simple vector of readings. There'll probably be a preamble of some sort, with a start timestamp and the sampling rate. You can try decoding the timestamp yourself, or you might try simply feeding it to
ctime()and see if they're using standard absolute time format.Keep in mind that lots of cheap A/D converters only produce 12-bit outputs, so your readings are unlikely to be larger than 16 bits (and the high-order 4 bits may be used for flags). I'd recommend resetting the device so that it's "blank", dumping and storing the contents, then take a set of readings, record the results (whatever the device normally reports), then dump the contents again and try to correlate the recorded results with whatever data appeared after the "blank" dump.