I want to decode data (Temperature and %RH) from a BLE device.
I can get data from it. I know (guessed) where the data is (0x0028). But I don't know how to decode it.
Here is what I get when running :
sudo bettercap
ble.enum 60:77:71:60:d1:8f
I then guessed the data is on handles 0x0028.
And here is what I get when I run :
sudo gatttool -b 60:77:71:60:d1:8f -I
connect
char-read-hnd 0x0028
[60:77:71:60:D1:8F][LE]> char-read-hnd 0x0028
Characteristic value/descriptor: 1e 00 8e 41 00 00 00 00 ea 94 3b 42 00 00 00 00 01 01 01 01
[60:77:71:60:D1:8F][LE]> char-read-hnd 0x0028
Characteristic value/descriptor: c6 e4 8d 41 00 00 00 00 30 73 3b 42 00 00 00 00 01 01 01 01
[60:77:71:60:D1:8F][LE]> char-read-hnd 0x0028
Characteristic value/descriptor: c6 e4 8d 41 00 00 00 00 30 73 3b 42 00 00 00 00 01 01 01 01
[60:77:71:60:D1:8F][LE]> char-read-hnd 0x0028
Characteristic value/descriptor: c6 e4 8d 41 00 00 00 00 9a 40 3b 42 00 00 00 00 01 01 01 01
[60:77:71:60:D1:8F][LE]> char-read-hnd 0x0028
Characteristic value/descriptor: 1e 00 8e 41 00 00 00 00 56 2e 3b 42 00 00 00 00 01 01 01 01
[60:77:71:60:D1:8F][LE]> char-read-hnd 0x0028
Characteristic value/descriptor: 1e 00 8e 41 00 00 00 00 42 19 3b 42 00 00 00 00 01 01 01 01
[60:77:71:60:D1:8F][LE]> char-read-hnd 0x0028
Characteristic value/descriptor: c6 e4 8d 41 00 00 00 00 18 23 3b 42 00 00 00 00 01 01 01 01
I think the data (°C and %RH) I'm looking for is in there but I have no idea how to decipher it.
Can somebody help ?
I tried to convert it from hex to dec but I didn't get any conclusive results.
°C should be between 17 and 23 and %HR between 20 and 80.
Before warming up the sensor : 1e 00 8e 41 00 00 00 00 ea 94 3b 42 00 00 00 00 01 01 01 01
After warming up the sensor : c6 e4 8d 41 00 00 00 00 30 73 3b 42 00 00 00 00 01 01 01 01
Related
I'm trying to decode a hex string to a datetime format from a BLE custom UUID. I don't have any information except the decoded value and datetime, that's why I put similar examples in milliseconds and minutes. It will be complicated to see the value of another year.
If you look closely, you will notice there are only 2 values repeated twice in each row (bold and italic). First starts with 0x01 (maybe a flag) and then 2 bytes and second 2 bytes too.
Similar minutes:
01 8E 6C 00 00 8E 6C 00 00 62 25 62 25 00 00 00 00 00 00 00 - 1669024172,5141 (Nov 21 2022 09:49:32,5387632)
01 9C 6C 00 00 9C 6C 00 00 62 49 62 49 00 00 00 00 00 00 00 - 1669024172,68598 (Nov 21 2022 09:49:32,7638451)
01 fd 6c 00 00 fd 6c 00 00 64 0f 64 0f 00 00 00 00 00 00 00 - 1669024174,23293 (Nov 21 2022 09:49:34,3170414)
01 0d 6d 00 00 0d 6d 00 00 6e 2f 6e 2f 00 00 00 00 00 00 00 - 1669024174,5767 (Nov 21 2022 09:49:34,5414078)
01 f0 6d 00 00 f0 6d 00 00 62 21 62 21 00 00 00 00 00 00 00 - 1669024178,01436 (Nov 21 2022 09:49:38,0746688)
01 00 6e 00 00 00 6e 00 00 67 81 67 81 00 00 00 00 00 00 00 - 1669024178,35812 (Nov 21 2022 09:49:38,2775026)
Similar milliseconds:
01 16 1d 00 00 16 1d 00 00 4d f4 4d f4 00 00 00 00 00 00 00 - 1669023854,70251 (Nov 21 2022 09:44:14,7728813)
01 1e 6e 00 00 1e 6e 00 00 67 c5 67 c5 00 00 00 00 00 00 00 - 1669024178,70189 (Nov 21 2022 09:49:38,7714679)
01 e2 6d 00 00 e2 6d 00 00 62 4d 62 4d 00 00 00 00 00 00 00 - 1669024177,84247 (2022-11-21 10:49:37,8263242)
01 5f dd 06 00 5f dd 06 00 cb 46 cb 46 00 00 00 00 00 00 00 - 1669110577,66758 (2022-11-22 10:49:37,8231004)
01 00 6e 00 00 00 6e 00 00 67 81 67 81 00 00 00 00 00 00 00 - 1669024178,35812 (2022-11-21 10:49:38,2775026)
01 7c dd 06 00 7c dd 06 00 c8 0c c8 0c 00 00 00 00 00 00 00 - 1669024178 (2022-11-22 10:49:38,2722736)
It's looks like:
It's not decoded in the unix epoch (JAN 1 1970)
The first value is increasing (0xXX6C, 0xXX6E, 0xXX6E), so maybe it's the int part.
I tried to decode like year, minutes, seconds but it seems it isn't.
Sometimes first value is bigger than 2 bytes (3 bytes):
01 DE 61 04 00 DE 61 04 00 4A C1 4A C1 00 00 00 00 00 00 00 - 1669104436 (Nov 22 2022 09:07:16,1902042)
I tried this solutions:
https://stackoverflow.com/questions/1389046/what-is-the-specification-of-hexadecimal-date-format-in-sql-server Error: System.ArgumentOutOfRangeException (trying one of my hex)
http://erbhavi.blogspot.com/search/label/Converting%20DateTime%20to%20Hex%20in%20C%23 DateTime yourDateTime = new DateTime( ticks1970 + gmt * 10000000L ); //Error CS0019: Operator '*' can't apply to types 'string' y 'long'
I'll update the question if I find more info.
I am struggling to get Windows to load the default WinUSB driver for my device. Please note that I am looking for a solution that is using BOS descriptor (and not the old 0xEE string index).
The device enumerates and Windows tells me that it is installing the device, but the WinUSB driver is not loaded. I have tried everything that I can think of, but still I can't get Windows to load the driver. I even uninstall the device and delete the USB flags in the registry whenever I re-try, but to no avail. Is there anyone who can help me to get this to work?
I don't want WebUSB capabilities or anything additional. This is a non-composite device.
This is my BOS descriptor (as sent over USB):
05 0F 21 00 01 1C 10 05 00 DF 60 DD D8 89
45 C7 4C 9C D2 65 9D 9E 64 8A 9F 00 00 03
06 B2 00 01 00
And this my BOS descriptor set:
0A 00 00 00 00 00 03 06 B2 00 08 00 01 00 ..............
00 00 A8 00 08 00 02 00 00 00 A0 00 14 00 ..............
03 00 57 49 4E 55 53 42 00 00 00 00 00 00 ..WINUSB......
00 00 00 00 84 00 04 00 07 00 2A 00 44 00 ..........*.D.
65 00 76 00 69 00 63 00 65 00 49 00 6E 00 e.v.i.c.e.I.n.
74 00 65 00 72 00 66 00 61 00 63 00 65 00 t.e.r.f.a.c.e.
47 00 55 00 49 00 44 00 73 00 00 00 50 00 G.U.I.D.s...P.
7B 00 46 00 37 00 32 00 46 00 45 00 30 00 {.F.7.2.F.E.0.
44 00 34 00 2D 00 43 00 42 00 43 00 42 00 D.4.-.C.B.C.B.
2D 00 34 00 30 00 37 00 44 00 2D 00 38 00 -.4.0.7.D.-.8.
38 00 31 00 34 00 2D 00 39 00 45 00 44 00 8.1.4.-.9.E.D.
36 00 37 00 33 00 44 00 30 00 44 00 44 00 6.7.3.D.0.D.D.
36 00 42 00 7D 00 00 00 00 00 6.B.}.....
The layout is:
typedef struct _SMSOS20DescriptorSet
{
SDeviceDescSetHeader sDescriptorSetHeader;
SConfigurationSubsetHeader sConfSubsetHeader;
SFunctionSubsetHeader sFuncSubsetHeader;
SDeviceCompatibleIdDescriptor sCompIdDescriptor;
SDeviceRegDescDeviceInterfaceGUID sRegistryDescDevInterfaceGuid;
} SMSOS20DescriptorSet;
I have follewed these guides and doc:
https://learn.microsoft.com/en-us/windows-hardware/drivers/usbcon/automatic-installation-of-winusb#winusb-device-installation-by-using-the-in-box-winusbinf
MS_OS_2_0_desc.docx
https://thewindowsupdate.com/2018/10/12/how-to-install-winusb-sys-without-a-custom-inf/
https://learn.microsoft.com/en-us/windows-hardware/drivers/usbcon/winusb-installation#automatic-installation-of--winusb-without-an-inf-file
UPDATE:
when you have a non-composite device that only has a single a configuration, then you are not use any subset headers (neither 'Configuration subset header' nor 'Function subset header'). So, the correct layout in this case is:
typedef struct _SMSOS20DescriptorSet
{
SDeviceDescSetHeader sDescriptorSetHeader;
SDeviceCompatibleIdDescriptor sCompIdDescriptor;
SDeviceRegDescDeviceInterfaceGUID sRegistryDescDevInterfaceGuid;
} SMSOS20DescriptorSet;
UPDATE: when you have a non-composite device that only has a single a configuration, then you are not use any subset headers (neither 'Configuration subset header' nor 'Function subset header'). So, the correct layout in this case is:
typedef struct _SMSOS20DescriptorSet
{
SDeviceDescSetHeader sDescriptorSetHeader;
SDeviceCompatibleIdDescriptor sCompIdDescriptor;
SDeviceRegDescDeviceInterfaceGUID sRegistryDescDevInterfaceGuid;
} SMSOS20DescriptorSet;
I am trying to return hexadecimal string as response from my AWS Lambda function. When it reaches to the client the data seems to be modified.
Data :
47 49 46 38 39 61 01 00 01 00 80 00 00 00 00 00
ff ff ff 21 f9 04 01 00 00 01 00 2c 00 00 00 00
01 00 01 00 00 08 04 00 03 04 04 00 3b
Hexadecimal Excaped Data ( Sent Data ):
\x47\x49\x46\x38\x39\x61\x01\x00\x01\x00\x80\x00\x00\x00\x00\x00"
"\xff\xff\xff\x21\xf9\x04\x01\x00\x00\x01\x00\x2c\x00\x00\x00\x00"
"\x01\x00\x01\x00\x00\x08\x04\x00\x03\x04\x04\x00\x3b
Received Data
47 49 46 38 39 61 01 00 01 00 c2 80 00 00 00 00
00 c3 bf c3 bf c3 bf 21 c3 b9 04 01 00 00 01 00
2c 00 00 00 00 01 00 01 00 00 08 04 00 03 04 04
00 3b
How to fix this?
Last time I checked it was not very explicit in the doc, but API Gateway is really made for json (or similar) and support for binary is 'on the roadmap' but clearly doesn't seem to be a priority. It converts everything it sends to utf-8.
Comparing precisely your original data with the received one you can see it :
47 49 46 38 39 61 01 00 01 00 80 00 00 00 00 00 ff ff ff 21 f9 04 01 00 00 01 00 2c 00 00 00 00 01 00 01 00 00 08 04 00 03 04 04 00 3b
47 49 46 38 39 61 01 00 01 00 c2 80 00 00 00 00 00 c3 bf c3 bf c3 bf 21 c3 b9 04 01 00 00 01 00 2c 00 00 00 00 01 00 01 00 00 08 04 00 03 04 04 00 3b
Everything under 0x7f is OK because the unicode code point is the same as the encoded byte (U+0047 -> 47), but for 0x80 or more the problem arises : U+0080 -> c2 80, U+00FF -> c3 bf and so on.
We had a similar problem recently : binary data was corrupted and bigger when sent through Gateway than with direct access to our backend. It was because a lot of bytes get replaced by Unicode special 'replacement character' aka 'U+FFFD' aka '0xEF 0xBF 0xBD'.
How to fix ? We just stopped using Gateway but if you can afford your data to be bigger, you can base64 encode it.
In my application I'm using an amalgamated embeded version of SQLite v3.8.4. In the past I had compatibility issues with v3.7 regarding page_size > 32768. Now I'd like to keep backwards compatibility on database files with v3.6.20 (default on RHEL6), but when I try to open my DB file on my RHEL6 machine I see the error:
Error: file is encrypted or is not a database
I can dump the database to an SQL file and then again import it to v3.7. This seems to do the trick to be readable on v3.6.20 but my DB is 3 GB in size and is not feasible for me to wait 2 hours for each dump.
What options can I set on my v3.8 to generate v3.6 compatible databases?
Databases dump
$ hexdump -C works-on-3.6.20.sqlite | head -n 8
00000000 53 51 4c 69 74 65 20 66 6f 72 6d 61 74 20 33 00 |SQLite format 3.|
00000010 04 00 01 01 00 40 20 20 00 00 00 01 00 2d 8c 51 |.....# .....-.Q|
00000020 00 00 00 00 00 00 00 00 00 00 00 12 00 00 00 01 |................|
00000030 00 00 00 00 00 00 00 00 00 00 00 01 00 00 00 00 |................|
00000040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 |................|
00000060 00 2d e2 21 05 00 00 00 02 03 f6 00 00 22 fd 07 |.-.!........."..|
00000070 03 fb 03 f6 01 8f 02 38 00 7c 01 61 81 62 07 07 |.......8.|.a.b..|
$ hexdump -C fails-on-3.6.20.sqlite | head -n 8
00000000 53 51 4c 69 74 65 20 66 6f 72 6d 61 74 20 33 00 |SQLite format 3.|
00000010 80 00 02 02 00 40 20 20 00 00 00 04 00 00 00 2b |.....# .......+|
00000020 00 00 00 00 00 00 00 00 00 00 00 14 00 00 00 01 |................|
00000030 00 00 00 00 00 00 00 00 00 00 00 01 00 00 00 00 |................|
00000040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 04 |................|
00000060 00 2d e6 04 0d 7f fc 00 18 75 a4 00 7f 36 7f c9 |.-.......u...6..|
00000070 7e 6b 7f 0b 7d 8f 7e 38 7c 7e 7d 62 7b ab 7c 47 |~k..}.~8|~}b{.|G|
The non-working database has enabled WAL mode, which was introduced in version 3.7.0. Disable it.
How do I manually [without any extra scripts/programs] see if a Windows executable is 32/64 bit?
I have been looking around and found what should have been my answer.
At 60 bytes in, the numbers below is suppose to appear, as far as I understand.
I386 0x014c
IA64 0x0200
AMD64 0x8664
Edit
After jumping to the PE offset, I still did not see the machine type. I did a Find & did not see any matches [unless its near the bottom for some reason].
64 86 06 00 is not in the list above, so I dont know what I am doing wrong.
Notepad.exe (64bit)
4D 5A 90 00 03 00 00 00 04 00 00 00 FF FF 00 00
B8 00 00 00 00 00 00 00 40 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 E8 00 00 00
0E 1F BA 0E 00 B4 09 CD 21 B8 01 4C CD 21 54 68
69 73 20 70 72 6F 67 72 61 6D 20 63 61 6E 6E 6F
74 20 62 65 20 72 75 6E 20 69 6E 20 44 4F 53 20
6D 6F 64 65 2E 0D 0D 0A 24 00 00 00 00 00 00 00
83 C2 32 29 C7 A3 5C 7A C7 A3 5C 7A C7 A3 5C 7A
CE DB D8 7A C6 A3 5C 7A CE DB C9 7A C5 A3 5C 7A
CE DB CF 7A DA A3 5C 7A C7 A3 5D 7A 33 A3 5C 7A
CE DB DF 7A D3 A3 5C 7A CE DB D5 7A CC A3 5C 7A
CE DB C8 7A C6 A3 5C 7A CE DB CD 7A C6 A3 5C 7A
52 69 63 68 C7 A3 5C 7A 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 50 45 00 00 64 86 06 00 <--
B3 C9 5B 4A 00 00 00 00 00 00 00 00 F0 00 22 00
0B 02 09 00 00 A8 00 00 00 58 02 00 00 00 00 00
70 35 00 00 00 10 00 00 00 00 00 00 01 00 00 00
00 10 00 00 00 02 00 00 06 00 01 00 06 00 01 00
06 00 01 00 00 00 00 00 00 50 03 00 00 06 00 00
49 E7 03 00 02 00 40 81 00 00 08 00 00 00 00 00
00 10 01 00 00 00 00 00 00 00 10 00 00 00 00 00
00 10 00 00 00 00 00 00 00 00 00 00 10 00 00 00
00 00 00 00 00 00 00 00 F8 CF 00 00 2C 01 00 00
00 40 01 00 60 F1 01 00 00 30 01 00 B4 06 00 00
00 00 00 00 00 00 00 00 00 40 03 00 B8 00 00 00
10 B7 00 00 38 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 E0 02 00 00 38 01 00 00
00 C0 00 00 F0 07 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
2E 74 65 78 74 00 00 00 70 A7 00 00 00 10 00 00
00 A8 00 00 00 06 00 00 00 00 00 00 00 00 00 00
What appears 60 bytes in isn't the machine type but the offset of the PE header. (In this case, 0x00000100: 256 bytes.) The PE header begins: 'P', 'E', 00, 00. What comes after that is the machine type.
OMG Figured it out. The code listing AMD64 0x86 64 matches "64 86". I never realized it was flipped.