Parameters for the "login" command

[dmhts]

Have you already tried to figure out what parameters are used for the "login" command? Here is a screenshot from Chrome DevTools:

This command is sent by the WhatsApp web application when an already authenticated client reopens a web socket connection (for example after page reloading or browser reopening).

Hint: I noticed that after sending a "login" command, a server "Conn" response no longer contains a "secret" along with other parameters. It confirms that the server implies that the client is already authenticated and has all required credentials (which is a perfectly valid assumption).

[sigalor]

Okay, item 2 and 3 are quite obvious: 2 is the clientToken sent to you in the initial "Conn" response and 3 is the serverToken in the same message. Not sure how to derive item 4 yet...
I also looked at the two cookies ".web.whatsapp.com" stores: "ref" and "tok", but I can't spot any similarities between the known ones and their values...

[dmhts]

Thanks, it seems item 4 is the clientId (you can take a look at the "init" command and notice that the same base64-encoded value is used there). I get back when confirm it. We could update the protocol description then.

[sigalor]

I'm not so sure about that being the actual clientId.

When you look at the original app***.js source file and set a breakpoint at requestSync, it's hit after a page reload:

As you can see, item 2 and 3 really are client and server tokens.

Item 4 though is derived differently, as the id function is called:

This function looks at the local storage of WhatsApp Web (check it out by clicking at the "Application" tab and then "Local Storage" on the left pane), for the value of the key "WABrowserId". I can confirm that this is the actual value of item 4.
As also observable in the source code, if the browser ID does not yet exist, just 16 random bytes are generated, base64-encoded and set as the new browser ID. Of course, this ID obviously just exists for tracking purposes (or does it?). Thus it would be nice to know wheather it's a problem when the browser ID is regenerated for every session takeover...

By the way, I just discovered the local storage contents myself. They seem really interesting and should be examined further...

[dmhts]

Sorry for the delay.
clientId and WABrowserId are different names of the same thing, I just used a term from your description: Generate your own clientId, which needs to be 16 base64-encoded bytes (i.e. 25 characters). This application just uses 16 random bytes, i.e. base64.b64encode(os.urandom(16)) in Python.
I can confirm that a reconnection process works correctly by using the following approach:

1522232358,["admin","init",{WAClientVersion},["Description1","Description2"],"{WABrowserId}",true]
1522232359,["admin","login","{clientToken}","{serverToken}","{WABrowserId}","takeover"]

Yep, there are a lot of interesting things in the local storage to investigate.
btw, is there a way to communicate with you directly?

Thanks,

[sigalor]

Ah, alright, that's good to know. I'm happy that you got it to work.

And yes, I added an email address to my GitHub account: [email protected]