I'm deciphering some hexcode that I've determined are dates.
I've determined that:
50 C0 01 00 => 2014-05-21
52 C0 01 00 => 2014-05-23
59 C0 01 00 => 2014-05-30
The last byte of 00 seems to be superfluous padding.
I tried applying the packing scheme that MySQL uses for dates, but that doesn't appear to work here.
Do you guys have any insight on how these dates are being packed into binary/hexcode?
Just a wild guess, but maybe it's going to be useful.
If you interpret the numbers as a little-endian 32-bit integer, then:
0x0001c050 = 114768
in decimal. Also notice how a difference of one in the numbers means one day of difference. So one in the date means one day. Just out of curiosity, I've divided this 114768 by 365.25 (the average number of days in a year). That's 314.217659, which is 314 years and 79 or 80 days.
If you count back 314 years and 80 days from 21/05/2014, then you get to 1 March, 1700. That's the fundamental date of the Gregorian system.
So I suppose this date format is just the number of days elapsed since the Gregorian epoch.
Related
I want to write an app that can control my smart bulb. I've captured the bluetooth dump that the bulb's official app is sending.
I found that the data is encrypted, i sent the same command several times and the output was always different, of course the bulb did the same thing each time.
There are some examples below for reference. First 3 bytes are not important (they just increment), the remaining 17 bytes are my struggle.
080000 e6 12 f2 2c 8e 11 56 f2 4e 68 92 ad 2b 40 bd 0c d5
0a0000 e2 72 9d ec 04 aa 27 1b c6 91 4b c2 a1 a1 1d 58 c5
0c0000 06 ce 72 cf f5 c3 d7 03 e5 10 2f b3 f0 34 03 b8 53
Question 1: What kind of encrypting technique does this:
one input at sender side => several different outputs
the reciever calculates one specific result from several different inputs.
Note that the reciever in this case is a smart bulb with a probably not too sophisticated chip.
Question 2: Could it be that the input is encrypted using the actual time? The time is sent in each packet, so maybe that's how the values are always different, but still the other side can figure out the original values using the recieved time?
Typically encryption adds a random element that is sent with the message so each message is different in order to prevent replay attacks, such as you are interested in.
Given that the encrypted message is 20 bytes my guess might be CTR mode. Potential algorithms might range from AES to XTEA. But knowing the encryption methods will nit help if the bulb company did their cryptography correctly.
Nota Bene: Cryptographic security relies solely on the key being secret, not the method.
Help,
I have recently located a Hex long/lat value in the registry for the IM line.
I am trying to confirm it is the users location and not the IM provider.
I have seen conversion methods suggest on previous questions but the hex value is shorter.
Does anybody know how to convert
Lat: 51 6B 9A 77 9C 32 4A 40
Long: 49 2E FF 21 FD F6 F8 BF
Thanks
Need some help to determine how is this date/time being encoded.
I've tried different methods, unixtime, little endian, big endian, can't figure it out.
Here are some examples (known date only):
20 94 9D 21 = 29-12-2016
C7 91 9E 21 = 30-12-2016
AD 6A 72 22 ~ around 24-03-2017
Thank you.
It would be very helpful to have a midpoint time (do you have any more examples?), but it appears to be approximately a half-second per integer value there.
Sample 1: 0x219d9420 -> 563,975,200 (decimal)
Sample 2: 0x219e91c7 -> 564,040,135 (decimal)
Sample 3: 0x22726aad -> 577,923,757 (decimal)
Timestamp 1: 29-12-2016 -> 1482969600 (unixtime)
Timestamp 2: 30-12-2016 -> 1483056000 (unixtime)
Timestamp 3: 24-03-2017 -> 1490313600 (unixtime)
The difference between sample 3 and sample 1/2 definitely increases somewhat proportionally to the distance between timestamp 3 and timestamps 1/2, but because 1/2 are so close together (and uncertain), it's really difficult to say for certain.
Overall, you end up with 7,344,000 seconds passed while 13,948,557 mystery timestamps passed, which is pretty close (given the uncertainty in the given dates) to 2 mystery-timestamps per second. This would put a start time about 9.4 years before the first timestamp, around Aug 2, 2007.
I have two columns in excel, one is date (X) and another one is some text (Y). May I know how can I create the scatter plot in MS Excel with these data? Thanks.
Date (X) Category (Y)
01/04/2012 00 Middleware
01/10/2012 09 End User
01/11/2012 02 End User
01/11/2012 15 Middleware
01/26/2012 03 End User
02/15/2012 09 End User
02/16/2012 07 End User
02/20/2012 10 Middleware
03/17/2012 01 OS
03/20/2012 01 Middleware
03/23/2012 11 Middleware
04/09/2012 07 Middleware
04/26/2012 06 Middleware
You need to plot numerical values in a chart. Are you just showing a timeline with markers at a particular height for a particular category? In this case, insert a column with arbitrary numerical values for the category (e.g., 1=OS, 2=Middleware, 3=End User). Plot this as the Y against the times for X. Use text boxes cover the 1, 2, 3 on the Y axis with Labels showing the categories.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
I was practicing questions for this topic and I came across this question:
Look at the 40byte dump of an IP packet containing a TCP segment below (in hexadecimal).
45 20 03 c5 78 06 00 00 34 06 ca 1f d1 55 ad 71 c0 a8 01 7e
00 50 9a 03 3e 64 e5 58 df d0 08 b3 80 18 00 de 00 02 00 00
Identify all the fields of the IP and TCP header.
Source: Q1 of http://www.eng.utah.edu/~cs5480/homeworks/hw3_soln.pdf
Now I do have the datagram format layout of IPv4 in front of me. The thing I don't understand is that in the solution it says that header length is 20bytes but according to the format the bits 4-7 correspond to header length which is 0x03c5 = 965 bytes. However, in the solution 965bytes is the total datagram length.
Can someone explain this?
have a look at this to dump your headers
https://metacpan.org/pod/distribution/Data-HexDump-Range/scripts/hdr_examples.pod#IPV4-header
digits != bits.
Assuming zero-based counting, 0x03c5 is hex digits 4-7 in your data.
Bits 4-7 would be the hex 5 appearing earlier. This header value represents the number of 32-bit words in the header, so you have to multiply by 4 to get 20 as the number of bytes.
According to the linked PDF document:
IP header: IP version 4, Header Length: 20 bytes, ToS = 20, Total Length = 0x03c5 =
965 bytes, ...
Seems pretty clear to me - 20 bytes header length, 965 bytes total length
(which matches Wikipedia on IPv4 headers quite nicely).