Re: Dump analysis
- From: Ben <benoit.allard@xxxxxx>
- To: samuel-thurston@xxxxxxxxx
- Date: Thu, 19 Jun 2014 21:27:34 +0200
On Thu, Jun 19, 2014 at 6:22 PM, Samuel Thurston
<samuel-thurston@xxxxxxxxx> wrote:
>
> On 06/19/2014 10:39 AM, Benoît Allard wrote:
>>
>> Hi Samuel !
>
>
> Hello Ben!
>
>>
>>> On 18 Jun 2014, at 19:26, Samuel Thurston <samuel-thurston@xxxxxxxxx>
>>> wrote:
>>
>> However, that is about the previous version of the dumps, the
>> "unencrypted" one. Newer firmware/trackers are not using it any more. For
>> the rest, beside the wiki and the code, everything is there. Feel free to
>> update the wiki with informations from other sources, that's why it's a wiki
>> !
>
> Now, I am a little unclear on this. The zip tracker appears to still be
> unencrypted. Also if I understand right the other models are unencrypted
> "out-of-the-box" until you do a firmware update. Is this a correct
> understanding?
Could well be, I don't really know about the Zip. I know that the One
at first behaved the same as the Zip, but that newer Ones are now
delivered with newer firmware, and thus deliver "encrypted" dumps. I
believe that the Flex and the Force always generated "encrypted"
dumps.
>
> Has anyone managed to successfully capture the firmware or extract a key
> for the encrypted versions? Is any part of the communications other than the
> dumps themselves encrypted?
You probably noticed the '"' around the "encrypted" in my previous
sentence. So far, no one proved that it was encrypted (as opposed to
"obfuscated"). "Encryption" if such, is most probably a symmetric one.
All the common symmetric encryptions are of block cipher type, which
would mean that the encrypted part is always of length multiple of the
block length (same as the key size in most cases).
As part of my work toward implementing a "pairing" mode, I intend to
get the "firmware" one further as well (they look very much the same
on a technical point of vue), which would allow us to download
firmware as will (as long as you persuade the server that you need an
update). unfortunately, it looks like the server only sends diff of
firmware ... (to be confirmed).
>
>>> Also, how certain are you about the device identifiers? I have a Zip
>>> that (I believe) is reporting as 0x28.
>>>
>> The values there have been read from dumps, so they are quite accurate,
>> however, it could be that the first byte of the dump is not meaning what we
>> believe it means ! Which would discard their meaning.
>
> I didn't realize until after I sent this that I was looking at the dumps
> from my office-neighbor's flex tracker. For some reason even though my zip
> was closer it wasn't saving dumps/being synced.
The Zip needs to be 'excited' to be visible on the bluetooth level,
they try to save energy as much as they can by switching off the
bluetooth as soon as it stays immobile on that model.
...
>>
>> Keep us informed about your progresses !
>
> I will contribute what I can. My short-term goal is to create a means of
> communicating directly with the trackers, bypassing the server sync. I'm
> only just getting started on this, I still have much to learn. Is
> "analysedump.py" meant to be stand-alone or are there plans to incorporate
> analysis into the dump output in future releases?
>
That is an interesting goal, and you (we) still have a long way to go.
The other difficulty (beside parsing the dump content) is to generate
an answer that the tracker will accept, and upon which he will erase
the part of the dump that is just dumped. Without that part, the dump
inside the tracker will only grow and grow, until ... some limit are
reach ? The first version of their tracker (Fitbit Ultra) had a one
week buffer, and only saved daily stats above that limit.
I'm open to suggestion about further inclusion of the dump analyse in
the synchronisation process. Feel free to express your ideas !
Best Regards,
Ben.
Other related posts:
