Os arquivos de registro são guardados para ajudar a equipe da TeamViewer em ações onde se é necessário o histórico de identidade, solução de problemas técnicos e localização de bugs no TeamViewer.
Em geral, os arquivos de registro são destinados à equipe de suporte da TeamViewer e não aos seus usuários finais. No entanto, os arquivos de registro também podem ser acessados pelos usuários.
Ao abrir os arquivos de registro, você pode se sentir confuso pois há muitos dados incluídos nele. Dessa forma, para aumentar a transparência e sensação de segurança dos nossos usuários, estabelecemos um guia para ajuda-los a ler os arquivos de registro em um nível básico, mas suficiente para identificar tentativas de conexão de entrada bem-sucedidas e malsucedidas.
Este artigo se aplica a todos os usuários TeamViewer (Classic).
As descrições e informações a seguir são extremamente simplificadas e jamais podem refletir como as sessões do TeamViewer são realmente criadas.
Este artigo pretende disponibilizar alguns conhecimentos básicos e limitados que sejam compreensíveis para todos. Para manter este artigo o mais simples possível, decidimos usar uma parábola como exemplo.
O descrito abaixo acontece em milissegundos e basicamente não é perceptível para os usuários. A passagem no Etapa 3 é uma descrição extremamente simplificada para seguir o gráfico do exemplo e não reflete como a validação de senha do TeamViewer funciona. O TeamViewer não vê ou sabe a senha e jamais a verá. A senha é verificada localmente no cliente.
Lembre-se sempre de que os arquivos de registro foram concebidos para solucionar problemas. Por causa disso, a quantidade de tempo coberta pelos arquivos de registro é limitada. O arquivo de registro tem 1 MB por padrão. Quando ele atingir o tamanho máximo, ele vira um logfile_old e um novo arquivo de log é iniciado. (qualquer logfile_old anterior é excluído quando isso ocorrer).
Este documento não poderá cobrir todos os casos em que ocorre um erro. Por favor, saiba que caso algo inesperado aconteça, você pode não ver essas entradas no registro.
Como as conexões do TeamViewer são negociadas por meio de nossos servidores centrais, é importante lembrar que há muita criptografia e autenticação ocorrendo antes que uma tentativa de conexão de entrada seja bem-sucedida.
Para obter mais informações sobre as sessões TeamViewer, consulte nosso Manual de segurança.
📌Por favor, tenha em mente que: Para poder ler os arquivos de registro do TeamViewer integralmente, é necessário um treinamento especial que apenas os membros da equipe TeamViewer em determinadas posições recebem.
Portanto, para quem não está familiarizado com a análise de arquivos de registro do TeamViewer, é fácil pensar que uma sessão foi estabelecida ao tentar ler os arquivos de registro, mesmo que tenha sido apenas uma tentativa de conexão.
Depois de ler este artigo, você poderá diferenciar entre uma tentativa de conexão e uma conexão bem-sucedida.
Uma conexão bem-sucedida é o resultado de um processo de criptografia e autenticação altamente seguro que resulta na possibilidade de uma pessoa enxergar o dispositivo remoto. Dependendo das configurações dos dispositivos, o acesso remoto total ou limitado é possível. Todas as conexões bem-sucedidas são listadas no registro Connections_incoming.txt, que você pode encontrar na pasta TeamViewer.
Uma tentativa de conexão pode ou não resultar em uma conexão bem-sucedida. Nenhum acesso ao dispositivo remoto é estabelecido e a pessoa tentando se conectar não tem acesso ao dispositivo remoto.
Para explicar as cinco etapas de uma conexão de entrada do TeamViewer, pegamos um exemplo em que João está tentando se conectar ao computador de Maria.
Nesta parábola, usaremos de uma chamada telefônica que está sendo estabelecida com a ajuda de uma telefonista, algo comum em meados do século XX.
📌Lembre-se que: Cada etapa da conexão deve ser bem-sucedido. Uma única falha resulta em uma conexão negada pelo TeamViewer.
Neste exemplo, a tentativa de João de se conectar com o dispositivo de Maria será comparado com João digitando o número de telefone de Maria, e o telefone dela tocar.
Agora suponhamos que assim como no século XX, haja uma telefonista no meio recebendo a solicitação de João:
João liga para a operadora: "Olá, aqui é o João. Queria falar com a Maria".
Telefonista: "Sim - por favor, aguarde".
A telefonista liga para Maria e o telefone dela começa a tocar.
João não está falando diretamente com Maria neste estágio. E com isso, temos um exemplo de tentativa de conexão.
Nenhuma conexão foi estabelecida neste ponto.
👉 Abaixo segue um exemplo de como essa tentativa de conexão é aparenta no arquivo de registro:
CommandHandlerRouting[2]::CreatePassiveSession(): incoming session via AU-SYD-IBM-R008.teamviewer.com, protocol Tcp
📌Lembrete: Aqui você também pode ver quais roteadores foram usados nas tentativas de conexão. O roteador escolhido é selecionado para garantir o melhor desempenho possível, e pode variar dependendo da hora do dia. Todos os roteadores estão em um ambiente com certificação ISO 27001 e todas as conexões são sempre criptografadas de ponta a ponta.
Maria atende o telefone: "Olá - aqui é a Maria"
Telefonista: "Olá, Maria - aqui é a operadora. Estou com João tentando se conectar com você. Você permitiria?"
Maria verifica sua lista de permissões: "Sim - João está na minha lista de permissões. Estou pronta para falar com ele".
Como João foi adicionado à lista de permissões de Maria em algum momento no passado, Maria concorda em continuar o processo da chamada. Ainda assim, João não está falando diretamente com Maria neste estágio. E com isso, ainda temos apenas uma tentativa de conexão.
Nenhuma conexão foi estabelecida neste ponto.
👉Abaixo segue um exemplo de como essa verificação das permissões se parece no arquivo de registro quando positiva:
CLoginServer::CheckIfConnectionIsAllowed() CLoginServer::AuthenticateServer()
Caso João não estivesse na lista de permissões de Maria ou mesmo em sua lista de bloqueio, Maria se recusaria a falar com João e a tentativa de conexão seria interrompida imediatamente.
👉Abaixo segue um exemplo de como essa verificação das permissões se parece no arquivo de registro quando recusada:
CLoginServer::CheckIfConnectionIsAllowed() CLoginServer::CheckIfConnectionIsAllowed: Partner 111111111 (João) not whitelisted CLoginServer::runServer: Conexão não permitida
A telefonista diz a Maria: "Por favor, aguarde" e volta para João.
A telefonista diz: "Oi João, qual é a senha para falar com Maria?"
João diz: "A senha é 'Abre-te Sésamo'."
A telefonista diz: "Obrigada - por favor, aguarde"
A telefonista diz a Maria: "Olá, Maria - João está dizendo que 'Abre-te Sésamo' é a senha."
🚨AVISO LEGAL: Não é assim que a senha do TeamViewer funciona. É uma descrição extremamente simplificada para seguir o enredo da parábola de exemplo. O TeamViewer não vê ou sabe a senha e jamais a verá. A senha é verificada localmente no aplicativo.
Caso Maria confirme a senha, a telefonista conecta as duas linhas e sai da conexão (= conexão bem-sucedida).
👉 Abaixo segue um exemplo de como uma conexão bem-sucedida se parece no arquivo de registro quando aceitada:
AuthenticationPublicKey_Passive::Verify: Sucesso
AuthenticationPasswordLogin_Passive::RunAuthenticationMethod: autenticação com senha fixa foi bem sucedida
Caso Maria diga que a senha está incorreta, o processo volta para o início do Estágio 3. João tem uma nova chance de informar a senha correta. Depois de muitas tentativas malsucedidas, Maria e a operadora recusarão as tentativas de conexão e João será bloqueado por um certo tempo.
👉 Abaixo segue um exemplo de como uma conexão malsucedida se parece no arquivo de registro quando recusada:
LookupPublicKeyV2: Manager {~keyabcd1234} não tem o direito a Acesso Fácil, rejeitar autenticação
AuthenticationPasswordLogin_Passive::RunAuthenticationMethod: a autenticação com senha dinâmica foi negada
Depois que João conseguiu se autenticar com sucesso com o Acesso Fácil ou senha, a conexão é iniciada.
João agora está falando diretamente com Maria. E com isso, temos uma conexão bem-sucedida. Abaixo está um exemplo de como essa conexão bem-sucedida se parece no arquivo de registro:
👉 Abaixo segue um exemplo de como uma conexão bem-sucedida se parece no arquivo de registro:
CPersistentParticipantManager::AddParticipant: [111111111,-123456789] type=3 name=João CPersistentParticipantManager::AddParticipant: [222222222,-987654321] type=6 name=Maria CPersistentParticipantManager::AddParticipant: [111111111,-123456789] type=3 name=João
A qualquer momento, Maria ou João podem encerrar a conexão. Se eles quiserem se falar novamente, eles precisam começar novamente da Etapa 1.
👉 Abaixo segue um exemplo de como o termino da conexão bem-sucedida se parece no arquivo de registro:
SessionManagerDesktop::SessionTerminate: removendo sessão com TVSessionID = -123456789
Caso João nunca seja capaz de se conectar com sucesso através do Acesso Fácil ou senha, ocorrerá uma recusa completa de sua tentativa de conexão.
👉 Abaixo segue um exemplo de como o termino da conexão malsucedida se parece no arquivo de registro:
SessionManagerDesktop::SessionTerminate: nenhuma sessão com ID=123456789, abortando logins
📌Por favor, tenha em mente que: As IDs mostradas no arquivo de registro para a ID e a ID da sessão do TV não são as IDs do TeamViewer, mas sim a ID da sessão individual. Elas não podem ser usadas para identificar ninguém ou nenhum dispositivo, nem para se conectar a ninguém.