smirker
Junior Member
- Oct 2, 2010
- 105
- 36
Hi guys,
As you may be aware, there are (at least) two formats for GCLIDs - short and long. Both are encoded with protobuf and pretty easy to decode. My goal is to try to find the exact timestamp from a GCLID (my actual goal is to try to find the exact timestamp of a click-to-call). Short GCLIDs are easy - the first parameter is the timestamp. Long GCLIDs are a different beast.
Does anyone know ANYTHING about long GCLIDs? e.g. when they are used, why, what it contains, etc? Here's what I know so far:
Format:
1 {
-- 1 {
---- 1: int: timestamp of date only
---- 2: long: no idea, but it usually stays the same across clicks on an account
-- }
-- 2: byte array: A, 36 bytes long
-- 3: byte array or short: B, 2 bytes long
}
16382: int: always seems to have the value of 1
So I can extract the timestamp, but it only contains the date and not the time. What is more interesting to me is byte array A, as it must contain some additional information.
I've analysed byte array A, and found the following:
1. It's not protobuf encoded - I've tried decoding partial subsets as well.
2. It always seems to start with 0x00.
3. After the first 0x00, there are 4 bytes that don't vary much (in my sample of 200 long GCLIDs, there were only two combinations of those 4 bytes).
4. After those four bytes, the following bytes seem completely random. Looking across all samples comparing bytes of the same index, they range from 0-255, average about 128 and std dev of about 75.
My thoughts here is that it's either some sort of random ID, *or* it contains encrypted data, possibly an encrypted embedded protobuf message.
That's everything I know guys. Any further insights would be amazing.
As you may be aware, there are (at least) two formats for GCLIDs - short and long. Both are encoded with protobuf and pretty easy to decode. My goal is to try to find the exact timestamp from a GCLID (my actual goal is to try to find the exact timestamp of a click-to-call). Short GCLIDs are easy - the first parameter is the timestamp. Long GCLIDs are a different beast.
Does anyone know ANYTHING about long GCLIDs? e.g. when they are used, why, what it contains, etc? Here's what I know so far:
Format:
1 {
-- 1 {
---- 1: int: timestamp of date only
---- 2: long: no idea, but it usually stays the same across clicks on an account
-- }
-- 2: byte array: A, 36 bytes long
-- 3: byte array or short: B, 2 bytes long
}
16382: int: always seems to have the value of 1
So I can extract the timestamp, but it only contains the date and not the time. What is more interesting to me is byte array A, as it must contain some additional information.
I've analysed byte array A, and found the following:
1. It's not protobuf encoded - I've tried decoding partial subsets as well.
2. It always seems to start with 0x00.
3. After the first 0x00, there are 4 bytes that don't vary much (in my sample of 200 long GCLIDs, there were only two combinations of those 4 bytes).
4. After those four bytes, the following bytes seem completely random. Looking across all samples comparing bytes of the same index, they range from 0-255, average about 128 and std dev of about 75.
My thoughts here is that it's either some sort of random ID, *or* it contains encrypted data, possibly an encrypted embedded protobuf message.
That's everything I know guys. Any further insights would be amazing.
