I receive bytes from an RFID reader when presenting a card, but I'm unable to figure out how to derive the card ID from these bytes.
For example, I have a card that has these numbers printed on it: 0007625328 116,23152. I would expect that this is the ID of that card, right?
For this card, I get the following bytes from the reader (in hexadecimal representation): <42><09><01><74><00><74><5A><70>.
The decimal number 0007625328 translates to 0x00745A70 in hexadecimal representation.
The number 116,23152 is actually a different representation of that same value (0007625328):
116 in decimal is 0x74 in hexadecimal.
23152 in decimal is 0x5A70 in hexadecimal.
Combined, this also gives 0x00745A70.
So the value that you receive (42 09 01 74 00 74 5A 70) seems to be the concatenation of some form of prefix value (0x42090174) and the printed card serial number (0x00745A70).
Related
I am using xiaomi LYWSD03MMC , I have got temperature of this device by BLE characteristics and it shows : 21 0a 17 7e 0b , However I know this is hex value but unfortunately i can't understand what does it mean.I only know the number 17, which is the amount of humidity, which is hex, and when I convert it to decimal it returns 23.
What is the UUID of the characteristic you are reading?
If it is of the format 0000xxxx-0000-1000-8000-00805F9B34FB then it should be documented on https://www.bluetooth.com/
You can find the mapping of Characteristic UUID to name in the 16-bit UUID Numbers Document at:
https://www.bluetooth.com/specifications/assigned-numbers/
The name can then be used to look in GATT Specification Supplement for more detailed description of the fields.
According to this script from github the first two values describe the temperature and need to be converted to little endian. This would result in a hex value of 0a21 which in decimal is 2539. This needs to be divided by 100 to give you a temperature of 25.39 degrees.
As you said, the third value is humidity, the last two values describe the battery voltage. Converted to little endian (0b7e) and decimal (2942), this value needs to be divided by 1000 and gives you a voltage of 2.942
I'm just starting to learn assembly language, and we are working with hex addresses. Below is a question of ours. I'm not sure how it adds up though. I know the answer is 0x202C, but how did we get there? Can you help explain the processes step by step, in the most basic way possible to help me understand? Thank you!!
The following data segment starts at memory address 0x2000 (hexadecimal)
.data
printString BYTE "Assembly is fun",0
moreBytes BYTE 24 DUP(0)
dateIssued DWORD ?
dueDate DWORD ?
What is the hexadecimal address of dueDate?
You have three data definitions to add together:
printString is an ASCII text followed by a zero byte. The string part is 15 bytes long, and with the terminal zero byte that makes 16. So the offset of the next data item is 0x2010 (16 decimal is 0x10 hex). printString starts at 0x2000, and the next one starts after the last byte of printString, so you have to add its length to its offset to get to the next offset.
moreBytes is 24 bytes long, because that's how DUP works. BYTE x DUP (y) means "X bytes of value Y". So the offset of the next data item is 0x2028, as 24 decimal is 0x18 hex.
dateIssued is 4 bytes long, because that's the definition of a DWORD. So the next one is at 0x0x2C, since 8+4=12, and that's 0xC in hex notation.
Alternatively, you could add the three lenghts together, getting 44. 44 in hex would be 0x2C.
I am working with doubles (64-bit) stored in a file by printing the raw bytes from the C# representation. For example the decimal number 0.95238095238095233 is stored as the bytes "9e e7 79 9e e7 79 ee 3f" in hex. Everything works as expected, I can write and read, but I would like to be able to understand this representation of the double myself.
According to the C# documentation https://learn.microsoft.com/en-us/dotnet/api/system.double?view=netframework-4.7.2#explicit-interface-implementations and wikipedia https://en.wikipedia.org/wiki/Double-precision_floating-point_format the first bit is supposedly the sign with 0 for positive and 1 for negative numbers. However, no matter the direction I read my bytes, the first bit is 1. Either 9 = 1001 or f = 1111. I am puzzled since 0.95... is positive.
As a double check, the following python code returns the correct decimal number as well.
unpack('d', binascii.unhexlify("9ee7799ee779ee3f"))
Can anyone explain how a human can read these bytes and get to 0.95238095238095233?
Figured it out, the collection of bytes are read like a 64-bit number (first bit on the left), but each byte is read like a string(first bit on the right). So my bytes should be read "3F" first, 3F reads left to right, so I'm starting with the bits 0011 1111 etc. This gives the IEEE 754 encoding as expected: First bit is the sign, next 11 bits the exponent, and then the fraction.
If we capture a DNS packet with wireshark, we can see among its bytes the domain name, in this case tools.kali.org:
The bytes in hexadecimal are 746f6f6c73046b616c69036f726700 and we can check with an ascii table how 74 corresponds to the character 't', 6f to 'o' and so on. The problem comes when we arrive at the dot character, which should be represented in hexadecimal by 2e and, however, is represented by 04 in the first appearance and 03 in the second appearance.
Why does this happen and how does wireshark know that it has to represent a dot if they are different values?
Dots are not represented. Dots are a textual representation, separating labels, so they don't appear in the packet.
Each label is represented as a one octet length field followed by that
number of octets.
—IETF RFC 1035 DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION
tools has 5 octets (bytes), kali has 4, org has 3. It's just happenstance that they are that sequence.
I downloaded Hex Workshop, and I was told to read a .dbc file.
It should contain 28,315 if you read
offset 0x04 and 0x05
I am unsure how to do this? What does 0x04 mean?
0x04 is hex for 4 (the 0x is just a common prefix convention for base 16 representation of numbers - since many people think in decimal), and that would be the fourth byte (since they are saying offset, they probably count the first byte as byte 0, so offset 0x04 would be the 5th byte).
I guess they are saying that the 4th and 5th byte together would be 28315, but did they say if this is little-endian or big-endian?
28315 (decimal) is 0x6E9B in hexadecimal notation, probably in the file in order 0x9B 0x6E if it's little-endian.
Note: Little-endian and big-endian refer to the order bytes are written. Humans typical write decimal notation and hexadecimal in a big-endian way, so:
256 would be written as 0x0100 (digits on the left are the biggest scale)
But that takes two bytes and little-endian systems will write the low byte first: 0x00 0x01. Big-endian systems will write the high-byte first: 0x01 0x00.
Typically Intel systems are little-endian and other systems vary.
Think of a binary file as a linear array of bytes.
0x04 would be the 5th (in a 0 based array) element in the array, and 0x05 would be the 6th.
The two values in 0x04 and 0x05 can be OR'ed together to create the number 28,315.
Since the value you are reading is 16 bit, you need to bitshift one value over and then OR them together, ie if you were manipulating the file in c#, you would use something like this:
int value = (ByteArray[4] >> 8) | ByteArray[5]);
Hopefully this helps explain how hex addresses work.
It's the 4th and the 5th XX code your viewing...
1 2 3 4 5 6
01 AB 11 7B FF 5A
So, the 0x04 and 0x05 is "7B" and "FF".
Assuming what you're saying, in your case 7BFF should be equal to your desired value.
HTH
0x04 in hex is 4 in decimal. 0x10 in hex is 16 in decimal. calc.exe can convert between hex and decimal for you.
Offset 4 means 4 bytes from the start of the file. Offset 0 is the first byte in the file.
Look at bytes 4 and five they should have the values 0x6E 0x9B (or 0x9B 0x6E) depending on your endianess.
Start here. Once you learn how to read hexadecimal values, you'll be in much better shape to actually solve your problem.