Jefferson, 
01 de junho de 2017, 
Me bateu vontade de fazer meu próprio servidor para o ClipSync, por isso me armei com o Wireshark e um pouco de paciência e cheguei ao protocolo a seguir, que já usei com sucesso em meu programa. Por sorte o autor não tentou usar nenhum tipo de obfuscação, nem tentou dar “segurança” à comunicação. Qualquer das duas iria inviabilizar minha tarefa.
O servidor usa três portas:
- TCP 22983 – Comunicação bidirecional
- UDP 22984 – Localização. Direção: Windows -> Android
- UDP 22985 – Localização. Direção: Android -> Windows
Quase todas as transmissões precisam ter prefixos e sufixos adicionados que são ligeiramente diferentes entre protocolos. Não sei dizer o motivo da diferença:
- Prefixo UDP: $$898|@'(
- Prefixo TCP: $$898|@*[
- Sufixo UDP: $$898|@’)
- Sufixo TCP: $$898|@*]
A busca de servidores
Se você precisa de uma introdução sobre como uma localização UDP funciona, leia meu texto no Automalabs.
A app envia repetidamente um Broadcast UDP local (para x.x.x.255), porta 22985, com o texto:
CLIPSYNC SERVER! WHERE ARE YOU!?
O servidor responde uma vez para cada broadcast que recebe com um broadcast UDP para 255.255.255.255, porta 22984 com:
$$898|@'(nome_da_maquina$$898|@’)
nome_da_maquina é o nome Windows da máquina e é o que vai aparecer na lista da app, mas pode ser qualquer texto. A app identifica o servidor pelo IP de quem enviou a resposta.
Eu não sei se há um motivo específico para a app fazer um broadcast restrito (x.x.x.255) e o servidor responder com um broadcast irrestrito (255.255.255.255). É bem possível que seja apenas um diferença entre os frameworks usados pelo programador no Android e no Windows.
Conexão com o servidor
Quando você seleciona o servidor na app, esta envia para a porta TCP 22983 do servidor:
|
1 2 3 4 |
0000 00 31 24 24 38 39 38 7c 40 2a 5b 43 61 6e 20 79 .1$$898|@*[Can y 0010 6f 75 20 61 64 64 20 6d 65 20 74 6f 20 79 6f 75 ou add me to you 0020 72 20 63 6c 69 65 6e 74 73 3f 24 24 38 39 38 7c r clients?$$898| 0030 40 2a 5d @*] |
Os primeiros dois bytes (00, 31) são o tamanho do resto da mensagem. O resto é puro texto:
|
1 |
$$898|@*[Can you add me to your clients?$$898|@*] |
E a resposta do servidor é:
|
1 2 3 |
0000 24 24 38 39 38 7c 40 2a 5b 49 20 63 61 6e 20 61 $$898|@*[I can a 0010 64 64 20 79 6f 75 20 74 6f 20 6d 79 20 63 6c 69 dd you to my cli 0020 65 6e 74 73 2e 24 24 38 39 38 7c 40 2a 5d ents.$$898|@*] |
Em puro texto:
|
1 |
$$898|@*[I can add you to my clients.$$898|@*] |
Depois de receber essa resposta a app avisa que está conectada ao servidor selecionado.
Envio do texto da área de transferência do Android para o servidor
É importante observar que isso só ocorre se a app detectar que o conteúdo da área de transferência no Android mudou. Se você copiar o mesmo texto repetidas vezes, ClipSync não vai transmitir nada.
Digamos que ClipSync transmita “00142348”. O texto é transmitido na porta TCP 22983 e os dois primeiros bytes (00, 1A) tem o tamanho da mensagem:
|
1 2 |
0000 00 1a 24 24 38 39 38 7c 40 27 28 30 30 31 34 32 ..$$898|@'(00142 0010 33 34 38 24 24 38 39 38 7c 40 27 29 348$$898|@') |
A resposta é uma exata cópia da transmissão, menos os dois bytes de tamanho da mensagem
|
1 2 |
0000 24 24 38 39 38 7c 40 27 28 30 30 31 34 32 33 34 $$898|@'(0014234 0010 38 24 24 38 39 38 7c 40 27 29 8$$898|@') |
Envio do texto da área de transferência do Windows para a app
A determinar
Depois que comecei a trabalhar no meu servidor, usando as strings que eu obtive no wireshark eu fiz uma pesquisa no Google e encontrei outra pessoa que decidiu fazer seu próprio servidor, em Python.
O programa Python não funciona no Windows do jeito que está. É preciso fazer as seguintes mudanças:
Em vez de instalar o módulo GTK+ instale o Pyperclip
Troque
import gtk
por
import pyperclip
Comente ou remova a linha:
accept_sock.setblocking(0)
Troque
cb = gtk.clipboard_get()
cb.set_text(str(clip))
cb.store()
por
print ”
pyperclip.copy(str(clip))