{"id":84024,"date":"2020-06-04T19:42:32","date_gmt":"2020-06-04T17:42:32","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/ble-pod-mikroskopom-atty-gatty"},"modified":"2020-06-04T19:42:32","modified_gmt":"2020-06-04T17:42:32","slug":"ble-pod-mikroskopom-atty-gatty","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/ble-pod-mikroskopom-atty-gatty","title":{"rendered":"BLE sob o microsc\u00f3pio (ATTs GATTs…)","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"BLE<\/p>\n

BLE sob o microsc\u00f3pio (ATTs GATTs…)<\/h2>\n

Parte 1, vis\u00e3o geral<\/b><\/p>\n

J\u00e1 se passou um bom tempo desde que a primeira especifica\u00e7\u00e3o do Bluetooth 4.0 foi publicada. Embora o tema BLE seja muito interessante, ele ainda afasta muitos desenvolvedores, devido \u00e0 sua complexidade. Em meus artigos anteriores, eu analisei principalmente os n\u00edveis mais baixos: o Link Layer e o Physical Layer. Isso me permitiu evitar conceitos complicados e confusos como o protocolo de atributos (ATT) e o perfil de atributos geral (GATT). No entanto, n\u00e3o h\u00e1 como fugir: sem entend\u00ea-los, \u00e9 imposs\u00edvel desenvolver dispositivos compat\u00edveis. Hoje, gostaria de compartilhar esses conhecimentos com voc\u00eas. Em meu artigo, basearei-me no tutorial<\/a><\/noindex> para iniciantes do site da Nordic. Ent\u00e3o, vamos come\u00e7ar.
\n<\/a><\/noindex><\/p>\n

Por que tudo \u00e9 t\u00e3o complicado?<\/h3>\n

\nNa minha opini\u00e3o, estava claro desde o in\u00edcio que controlar dispositivos atrav\u00e9s de smartphones era um tema muito promissor e de longo prazo. Portanto, decidiu-se estruturar tudo desde o in\u00edcio e da melhor maneira poss\u00edvel. Para que os fabricantes de v\u00e1rios gadgets n\u00e3o criassem seus pr\u00f3prios protocolos, que posteriormente seriam incompat\u00edveis. Da\u00ed vem a complexidade. J\u00e1 na primeira etapa, tentou-se incluir tudo o que fosse poss\u00edvel no protocolo BLE, independentemente de sua real utilidade no futuro. Al\u00e9m disso, foi prevista a possibilidade de ampliar a lista de dispositivos no futuro.<\/p>\n

Vamos dar uma olhada na imagem que mostra o esquema do protocolo BLE. Ele \u00e9 composto por v\u00e1rias camadas. A camada mais baixa, a camada f\u00edsica (PHY), \u00e9 respons\u00e1vel pelo canal de r\u00e1dio do dispositivo. O Link Layer (LL) cont\u00e9m toda a sequ\u00eancia de bytes na mensagem transmitida. Em artigos anteriores, estudamos especificamente essa camada. O Host Controller Interface (HCI) \u00e9 o protocolo de comunica\u00e7\u00e3o entre camadas ou chipsets BLE, caso o Controller e o Host sejam implementados em chips diferentes. O Logical Link Control and Adaptation Protocol (L2CAP) \u00e9 respons\u00e1vel pela forma\u00e7\u00e3o de pacotes, divis\u00e3o em quadros, controle de erros e montagem de pacotes. O Security Manager Protocol (SMP) lida com a criptografia dos pacotes. O perfil de acesso geral (GAP) \u00e9 respons\u00e1vel pela troca inicial de dados entre dispositivos, para determinar \u2018Quem \u00e9 quem\u2019. Isso tamb\u00e9m abrange scanning e advertising. Neste artigo, vou me concentrar nas duas partes restantes do protocolo \u2014 GATT e ATT. O GATT \u00e9 um complemento do ATT, portanto, eles est\u00e3o fortemente entrela\u00e7ados.<\/p>\n

\"BLE
\n
\nPara simplificar a narrativa, gostaria de recorrer a uma analogia. Eu a ouvi em algum lugar e gostaria de apoi\u00e1-la. Imagine um dispositivo BLE como uma estante de livros com v\u00e1rias prateleiras. Cada prateleira representa um tema distinto. Por exemplo, temos prateleiras de fic\u00e7\u00e3o, matem\u00e1tica, enciclop\u00e9dias. Em cada prateleira, h\u00e1 livros sobre o tema indicado. E em alguns livros, h\u00e1 at\u00e9 marcadores de papel com anota\u00e7\u00f5es. Al\u00e9m disso, temos um pequeno cat\u00e1logo em papel de todos os livros. Se voc\u00ea se lembra das bibliotecas escolares \u2014 \u00e9 uma gaveta estreita com cart\u00f5es de papel. Dentro dessa analogia, a estante \u00e9 o perfil do nosso dispositivo. As prateleiras s\u00e3o os servi\u00e7os, os livros s\u00e3o as caracter\u00edsticas e o cat\u00e1logo \u00e9 a tabela de atributos. Os marcadores nos livros s\u00e3o os descritores, sobre os quais falarei mais detalhadamente depois.<\/p>\n

Todos que desenvolveram dispositivos sabem que em muitos projetos existem trechos de c\u00f3digo semelhantes. O fato \u00e9 que muitos dispositivos t\u00eam funcionalidades semelhantes. Por exemplo, se os dispositivos funcionam com baterias, ent\u00e3o o problema de carregamento e controle do n\u00edvel delas ser\u00e1 o mesmo. O mesmo se aplica aos sensores. Na verdade, a abordagem orientada a objetos na programa\u00e7\u00e3o \u201coferece a capacidade de criar objetos que conectam propriedades e comportamentos em uma alian\u00e7a aut\u00f4noma que pode ser reutilizada v\u00e1rias vezes\u201d<\/i>. Na minha opini\u00e3o, no BLE foi feita uma tentativa de abordagem semelhante. Um grupo da Bluetooth Special Interest Group (SIG) desenvolveu perfis. Dispositivos de diferentes fabricantes que t\u00eam perfis iguais devem funcionar sem dificuldades uns com os outros. Os perfis, por sua vez, consistem em servi\u00e7os, e os servi\u00e7os s\u00e3o compostos por caracter\u00edsticas, complementadas por descritores. De forma geral, isso pode ser representado assim:<\/p>\n

\"BLE
\n
\nComo exemplo, consideremos o esquema do perfil monitor de frequ\u00eancia card\u00edaca (pulseira fitness). Ele consiste em dois servi\u00e7os e v\u00e1rias caracter\u00edsticas. A partir disso, a hierarquia do perfil se torna imediatamente clara. A caracter\u00edstica do ponto de controle zera o total de gastos cal\u00f3ricos. <\/p>\n

1. O servi\u00e7o de frequ\u00eancia card\u00edaca inclui tr\u00eas caracter\u00edsticas (0x180D):
\n    a) Caracter\u00edstica obrigat\u00f3ria de frequ\u00eancia card\u00edaca (0x2A37)
\n    b) Caracter\u00edstica opcional de posi\u00e7\u00e3o do sensor corporal (0x2A38)
\n    c) Caracter\u00edstica condicional de ponto de controle de frequ\u00eancia card\u00edaca (0x2A39)
\n2. Servi\u00e7o de gerenciamento de bateria (0x180F):
\n    a) Caracter\u00edstica obrigat\u00f3ria do n\u00edvel de carga da bateria (0x2A19)<\/p>\n

UUID<\/h3>\n

\nPara que possamos nos referir de forma \u00fanica aos elementos do perfil (servi\u00e7os, caracter\u00edsticas e descritores), precisamos numer\u00e1-los de alguma forma. Para isso, \u00e9 introduzido o conceito de Identificador \u00danico Universal (UUID) ou Universally Unique Identifier. O UUID est\u00e1 indicado entre par\u00eanteses em cada linha. E aqui h\u00e1 uma peculiaridade. Para o UUID, foi decidido usar c\u00f3digos de 16 e 128 bits de comprimento. Por que, voc\u00ea pergunta? No protocolo BLE, tudo \u00e9 regido pela economia de energia. Portanto, uma dimens\u00e3o de 16 bits \u00e9 bastante razo\u00e1vel. \u00c9 improv\u00e1vel que no futuro pr\u00f3ximo sejam criados mais de 65 mil servi\u00e7os e caracter\u00edsticas \u00fanicos. At\u00e9 agora, tudo o que pod\u00edamos, j\u00e1 foi contado (lembre-se de onde \u00e9 isso \u2014 \u201cele tamb\u00e9m contou voc\u00ea\u201d :-)) Elementos numerados perfis<\/a><\/noindex>, servi\u00e7os<\/a><\/noindex>, caracter\u00edsticas<\/a><\/noindex> e descritores<\/a><\/noindex> voc\u00ea pode visualizar atrav\u00e9s dos links.<\/p>\n

No entanto, eu acho que todos lembram a hist\u00f3ria dos 4 bytes de endere\u00e7o IP na internet. No come\u00e7o se pensou que seria suficiente, mas agora n\u00e3o conseguimos fazer a transi\u00e7\u00e3o para endere\u00e7os de 6 bytes. Para n\u00e3o repetir esse erro e dar espa\u00e7o a m\u00e3os arteiras, a SIG decidiu imediatamente introduzir tamb\u00e9m UUIDs de 128 bits. Isso me lembra a faixa de 433MHz n\u00e3o licenciada, que foi deixada livre para todos os tipos de inventores de r\u00e1dio. No nosso caso, o identificador de servi\u00e7os e caracter\u00edsticas de 128 bits foi entregue a esta liberdade. Isso significa que podemos usar praticamente qualquer valor de 128 bits para nossos servi\u00e7os e dispositivos. A probabilidade de criar um UUID id\u00eantico tende a zero.<\/p>\n

Na verdade, os UUIDs de 16 bits curtos t\u00eam sua extens\u00e3o para o valor de 128 bits. Na especifica\u00e7\u00e3o, essa extens\u00e3o \u00e9 chamada de Bluetooth Base UUID e tem o valor 00000000-0000-1000-8000-00805F9B34FB. Se, por exemplo, o UUID de atributo de 16 bits tem o valor 0x1234, ent\u00e3o o UUID equivalente de 128 bits ter\u00e1 o valor 00001234-0000-1000-8000-00805F9B34FB. E tamb\u00e9m \u00e9 fornecida a f\u00f3rmula correspondente:<\/p>\n

                                128_bit_value = 16_bit_value * 2^96 + Bluetooth_Base_UUID<\/p>\n

De onde veio esse n\u00famero m\u00e1gico, n\u00e3o sei. Se algu\u00e9m entre os leitores souber \u2014 por favor, escreva nos coment\u00e1rios (Um usu\u00e1rio com o apelido Sinopteek j\u00e1 fez isso. Veja nos coment\u00e1rios). Quanto a criar UUIDs de 128 bits, na verdade, \u00e9 poss\u00edvel utilizar um gerador<\/a><\/noindex>, que far\u00e1 isso por voc\u00ea.<\/p>\n

ATT\u044b GATT\u044b\u2026<\/h3>\n

\n Na verdade, \u00e9 aqui que come\u00e7a a parte mais interessante. Lembro que o ATT se baseia na rela\u00e7\u00e3o cliente-servidor. Agora estamos considerando a estrutura do servidor. Ele cont\u00e9m informa\u00e7\u00f5es como valores de sensores, o estado do interruptor de luz, dados de localiza\u00e7\u00e3o, etc. Agora que todos os \"participantes do nosso desfile\" est\u00e3o numerados, precisamos de alguma forma organiz\u00e1-los na mem\u00f3ria do dispositivo. Para isso, colocamos tudo em uma tabela chamada tabela de atributos. Lembre-se bem disso. Este \u00e9 o cora\u00e7\u00e3o do BLE. \u00c9 isso que iremos considerar a seguir. Agora, cada linha ser\u00e1 chamada de atributo. Esta tabela est\u00e1 no fundo da pilha e, geralmente, n\u00e3o temos acesso direto a ela. N\u00f3s a inicializamos e a acessamos, mas o que acontece internamente \u00e9 um mist\u00e9rio para n\u00f3s. <\/p>\n

Vamos considerar a imagem da especifica\u00e7\u00e3o, mas antes disso, quero chamar a aten\u00e7\u00e3o para a confus\u00e3o frequente nos termos, especialmente em rela\u00e7\u00e3o aos descritores. O papel do descritor \u00e9 complementar a descri\u00e7\u00e3o de uma caracter\u00edstica. Quando \u00e9 necess\u00e1rio expandir suas capacidades, \u00e9 quando se aplicam os descritores. Eles tamb\u00e9m s\u00e3o atributos e, assim como os servi\u00e7os e caracter\u00edsticas, est\u00e3o localizados na tabela de atributos. Vamos detalhar isso na segunda parte do artigo. Entretanto, \u00e0s vezes, os descritores s\u00e3o chamados pelo n\u00famero da linha na tabela de atributos. \u00c9 importante ter isso em mente. Para evitar confus\u00f5es, usaremos o termo \"ponteiro do atributo\" para esses fins.
\n\"BLE
\n
\nEnt\u00e3o, um atributo \u00e9 um valor discreto que possui as seguintes propriedades associadas a ele:
\n1. Ponteiro do atributo (Attribute Handle) \u2014 \u00e9 o \u00edndice na tabela correspondente ao atributo
\n2. Tipo de atributo (Attribute Type) \u2014 \u00e9 o UUID que descreve seu tipo
\n3. Valor do atributo (Attribute Value) \u2014 s\u00e3o os dados indexados pelo ponteiro do atributo
\n4. Permiss\u00f5es de Atributos (Attribute Permissions) \u2014 s\u00e3o uma parte do atributo, permiss\u00f5es que n\u00e3o podem ser lidas ou gravadas usando o protocolo de atributos<\/p>\n

Como entender tudo isso? O ponteiro do atributo \u00e9, por assim dizer, seu n\u00famero em nossa tabela.
\nEle permite que o cliente se refira a um atributo em solicita\u00e7\u00f5es de leitura ou grava\u00e7\u00e3o. Podemos numerar nossas linhas (atributos) de 0x0001 a 0xFFFF. Em nossa associa\u00e7\u00e3o com uma estante de livros, isso se refere ao n\u00famero do cart\u00e3o no cat\u00e1logo f\u00edsico. Assim como em um cat\u00e1logo de biblioteca, os cart\u00f5es s\u00e3o dispostos em ordem crescente de n\u00famero. O n\u00famero de cada linha subsequente deve ser maior que o anterior. Assim como na biblioteca, \u00e0s vezes alguns cart\u00f5es se perdem, e em nossa numera\u00e7\u00e3o de linhas tamb\u00e9m podem haver lacunas. Isso \u00e9 permitido. O importante \u00e9 que eles estejam em ordem crescente.<\/p>\n

O tipo de atributo determina o que esse atributo representa. Assim como na linguagem C,
\nonde existem vari\u00e1veis booleanas, num\u00e9ricas e strings, aqui tamb\u00e9m. Pelo tipo de atributo, podemos entender
\ncom o que estamos lidando e como devemos trabalhar com esse atributo. Abaixo, vamos considerar alguns tipos espec\u00edficos de atributos. Por exemplo, 'declara\u00e7\u00e3o de servi\u00e7o' (0x2800), 'declara\u00e7\u00e3o de caracter\u00edsticas' (0x2803), 'declara\u00e7\u00e3o de descritor' (0x2902).<\/p>\n

O valor do atributo \u00e9, de fato, seu pr\u00f3prio valor, desculpe pela tautologia. Se o tipo do atributo \u00e9 uma string, o valor do atributo pode ser, por exemplo, o slogan 'Hello World !!!'. Se o tipo do atributo \u00e9 'declara\u00e7\u00e3o de servi\u00e7o', ent\u00e3o seu valor \u00e9 o pr\u00f3prio servi\u00e7o. \u00c0s vezes, isso \u00e9 uma informa\u00e7\u00e3o sobre onde encontrar outros atributos e suas propriedades.<\/p>\n

As permiss\u00f5es dos atributos permitem que o servidor entenda se o acesso para leitura ou grava\u00e7\u00e3o est\u00e1 permitido.
\nObserve que essas permiss\u00f5es se aplicam apenas ao valor do atributo, e n\u00e3o ao ponteiro, tipo e ao pr\u00f3prio campo de permiss\u00f5es. Ou seja, se a grava\u00e7\u00e3o do atributo estiver permitida, podemos mudar, por exemplo, a string 'Hello World !!!' para 'Good morning'. Mas n\u00e3o podemos proibir a grava\u00e7\u00e3o de uma nova string ou mudar o tipo do atributo e designar a string como 'declara\u00e7\u00e3o de servi\u00e7o'. Ao se conectar ao servidor, o cliente solicita seus atributos. Isso permite que o cliente saiba o que o servidor pode oferecer. Por\u00e9m, n\u00e3o \u00e9 obrigat\u00f3rio ler e gravar valores.<\/p>\n

Como isso aparece<\/h3>\n

\nA concep\u00e7\u00e3o do GATT \u00e9 agrupar atributos em uma tabela de atributos de maneira muito espec\u00edfica e l\u00f3gica. Vamos examinar mais de perto o perfil de frequ\u00eancia card\u00edaca mostrado abaixo. A coluna mais \u00e0 esquerda desta tabela \u00e9 opcional. Ela simplesmente descreve o que \u00e9 essa linha (atributo). Todas as outras colunas j\u00e1 nos s\u00e3o familiares.<\/p>\n

\"BLE
\n
\nNa parte superior de cada grupo, sempre temos o atributo de declara\u00e7\u00e3o do servi\u00e7o. Seu tipo \u00e9 sempre igual a 0x2800, e o ponteiro depende de quantos atributos j\u00e1 est\u00e3o presentes na tabela. Suas permiss\u00f5es s\u00e3o sempre apenas para leitura, sem qualquer verifica\u00e7\u00e3o de autenticidade ou autoriza\u00e7\u00e3o. Vamos falar sobre esses conceitos mais tarde. O valor \u00e9 mais um UUID, que define qual \u00e9 o servi\u00e7o. Na tabela, o valor \u00e9 igual a 0x180D, que \u00e9 definido pelo Bluetooth SIG como o servi\u00e7o de frequ\u00eancia card\u00edaca. <\/p>\n

Ap\u00f3s a declara\u00e7\u00e3o do servi\u00e7o, segue a declara\u00e7\u00e3o da caracter\u00edstica. Sua forma \u00e9 semelhante \u00e0 declara\u00e7\u00e3o do servi\u00e7o. Seu UUID sempre tem o valor 0x2803, e as permiss\u00f5es tamb\u00e9m est\u00e3o sempre dispon\u00edveis apenas para leitura, sem qualquer verifica\u00e7\u00e3o de autenticidade ou autoriza\u00e7\u00e3o. Vamos olhar o campo Attribute Value, que inclui alguns dados. Ele sempre cont\u00e9m um ponteiro, um UUID e um conjunto de propriedades. Estes tr\u00eas elementos descrevem a subsequente declara\u00e7\u00e3o do valor da caracter\u00edstica. O ponteiro naturalmente indica a localiza\u00e7\u00e3o da declara\u00e7\u00e3o do valor da caracter\u00edstica na tabela de atributos. O UUID descreve que tipo de informa\u00e7\u00e3o ou valor podemos esperar. Por exemplo, um valor de temperatura, o estado de um interruptor de luz ou qualquer outro valor arbitr\u00e1rio. E finalmente, as propriedades que descrevem como interagir com o valor da caracter\u00edstica. <\/p>\n

Aqui nos deparamos com mais uma armadilha. Ela est\u00e1 relacionada \u00e0s permiss\u00f5es dos atributos e \u00e0s propriedades das caracter\u00edsticas. Vamos olhar a imagem das propriedades do campo de bits da especifica\u00e7\u00e3o.<\/p>\n

\"BLE
\n
\nComo podem ver, tamb\u00e9m existem campos que oferecem possibilidades de leitura e grava\u00e7\u00e3o. Voc\u00ea pode se perguntar por que temos permiss\u00f5es de leitura\/grava\u00e7\u00e3o para o atributo e a propriedade.
\nLeitura\/escrita para o valor da caracter\u00edstica? Eles n\u00e3o devem ser sempre iguais? O fato \u00e9 que as propriedades para o valor da caracter\u00edstica s\u00e3o, na verdade, apenas recomenda\u00e7\u00f5es para o cliente, utilizadas nas camadas GATT e aplicadas. S\u00e3o apenas dicas sobre o que o cliente pode esperar do atributo da declara\u00e7\u00e3o de caracter\u00edstica. Vamos explorar isso mais a fundo. Que tipos de permiss\u00f5es existem para o atributo? <\/p>\n

1. Permiss\u00f5es de acesso:
\n     \u2014 leitura
\n     \u2014 escrita
\n     \u2014 leitura e escrita
\n2. Permiss\u00e3o de autentica\u00e7\u00e3o:
\n     \u2014 autentica\u00e7\u00e3o necess\u00e1ria
\n     \u2014 autentica\u00e7\u00e3o n\u00e3o necess\u00e1ria
\n3. Permiss\u00e3o de autoriza\u00e7\u00e3o:
\n     \u2014 autoriza\u00e7\u00e3o necess\u00e1ria
\n     \u2014 autoriza\u00e7\u00e3o n\u00e3o necess\u00e1ria<\/p>\n

A principal diferen\u00e7a entre as permiss\u00f5es dos atributos e as propriedades das caracter\u00edsticas \u00e9 que as primeiras se referem aos servidores, enquanto as segundas se referem aos clientes. Um servidor pode ter permitido a leitura do valor da caracter\u00edstica, mas pode haver uma exig\u00eancia de autentica\u00e7\u00e3o ou autoriza\u00e7\u00e3o. Portanto, ao solicitar as propriedades da caracter\u00edstica pelo cliente, teremos que a leitura \u00e9 permitida. Mas ao tentar a leitura, receberemos um erro. Assim, pode-se afirmar com certeza que as permiss\u00f5es t\u00eam prioridade sobre as propriedades. N\u00f3s, do lado do cliente, n\u00e3o podemos obter informa\u00e7\u00f5es sobre quais permiss\u00f5es o atributo possui.<\/p>\n

Descritor<\/h3>\n

\nVamos voltar \u00e0 nossa tabela. Ap\u00f3s a declara\u00e7\u00e3o do valor da caracter\u00edstica, s\u00e3o poss\u00edveis as seguintes declara\u00e7\u00f5es de atributos:
\n1. Nova declara\u00e7\u00e3o de caracter\u00edstica (pode haver muitas caracter\u00edsticas no servi\u00e7o)
\n2. Nova declara\u00e7\u00e3o de servi\u00e7o (pode haver muitas na tabela)
\n3. Declara\u00e7\u00e3o de descritor <\/p>\n

No caso da caracter\u00edstica de medi\u00e7\u00e3o da frequ\u00eancia card\u00edaca, em nossa tabela, a declara\u00e7\u00e3o do valor da caracter\u00edstica \u00e9 acompanhada pela declara\u00e7\u00e3o do descritor. O descritor \u00e9 um atributo com informa\u00e7\u00f5es adicionais sobre a caracter\u00edstica. Existem v\u00e1rios tipos de descritores. Sobre eles, falaremos em detalhes na segunda parte deste artigo. Agora, vamos nos concentrar apenas no descritor de configura\u00e7\u00e3o de caracter\u00edsticas do cliente (Client Characteristic Configuration Descriptor - CCCD). Ele tem um UUID igual a 0x2902. Com este descritor, o cliente tem a capacidade de ativar a indica\u00e7\u00e3o ou notifica\u00e7\u00e3o no servidor. A diferen\u00e7a entre eles \u00e9 pequena, mas ainda assim existe. A notifica\u00e7\u00e3o n\u00e3o requer confirma\u00e7\u00e3o de recebimento por parte do cliente. A indica\u00e7\u00e3o requer isso, embora aconte\u00e7a no n\u00edvel GATT, sem chegar ao n\u00edvel do aplicativo. Por que isso, voc\u00ea pode perguntar? Infelizmente, isso \u00e9 algo que n\u00e3o sei. Apenas direi que os especialistas da Nordic recomendam o uso da notifica\u00e7\u00e3o. Especialmente porque a verifica\u00e7\u00e3o de integridade do pacote (usando CRC) ocorre em ambos os casos.<\/p>\n

Conclus\u00e3o<\/h3>\n

\nNo final do artigo, eu gostaria de falar sobre o seguinte. A \u00faltima tabela \u00e9 um pouco confusa. Contudo, eu a inclui porque est\u00e1 apresentada em artigo<\/a><\/noindex>, na qual me baseio. Na segunda parte do meu artigo, pretendo me aprofundar nas especifica\u00e7\u00f5es do BlueTooth 4.0. L\u00e1 nos esperam esquemas e diagramas mais precisos. Na terceira parte, quero analisar o log obtido atrav\u00e9s do programa Wireshark de um dos gadgets e ver \"ao vivo\" toda a teoria que estamos estudando.<\/p>\n

Funcion\u00e1rio do Grupo de Empresas \"C\u00e9sar Sat\u00e9lite\"<\/a><\/noindex>
\nVladimir Pechersky
\n
Fonte: habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

BLE \u043f\u043e\u0434 \u043c\u0438\u043a\u0440\u043e\u0441\u043a\u043e\u043f\u043e\u043c (ATT\u044b GATT\u044b…) \u0427\u0430\u0441\u0442\u044c 1, \u043e\u0431\u0437\u043e\u0440\u043d\u0430\u044f \u0423\u0436\u0435 \u043f\u0440\u043e\u0448\u043b\u043e \u0434\u043e\u0432\u043e\u043b\u044c\u043d\u043e \u0431\u043e\u043b\u044c\u0448\u043e\u0435 \u0432\u0440\u0435\u043c\u044f, \u0441 \u0442\u0435\u0445 \u043f\u043e\u0440, \u043a\u043e\u0433\u0434\u0430 \u0432\u044b\u0448\u043b\u0430 \u043f\u0435\u0440\u0432\u0430\u044f \u0441\u043f\u0435\u0446\u0438\u0444\u0438\u043a\u0430\u0446\u0438\u044f \u043d\u0430 Bluetooth 4.0. \u0418, \u0445\u043e\u0442\u044f \u0442\u0435\u043c\u0430 BLE \u043e\u0447\u0435\u043d\u044c \u0438\u043d\u0442\u0435\u0440\u0435\u0441\u043d\u0430, \u043e\u043d\u0430 \u0434\u043e \u0441\u0438\u0445 \u043f\u043e\u0440 \u043e\u0442\u0442\u0430\u043b\u043a\u0438\u0432\u0430\u0435\u0442 \u043c\u043d\u043e\u0433\u0438\u0445 \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0447\u0438\u043a\u043e\u0432, \u0438\u0437-\u0437\u0430 \u0441\u0432\u043e\u0435\u0439 \u0441\u043b\u043e\u0436\u043d\u043e\u0441\u0442\u0438. \u0412 \u0441\u0432\u043e\u0438\u0445 \u043f\u0440\u0435\u0434\u044b\u0434\u0443\u0449\u0438\u0445 \u0441\u0442\u0430\u0442\u044c\u044f\u0445 \u044f \u0440\u0430\u0441\u0441\u043c\u0430\u0442\u0440\u0438\u0432\u0430\u043b \u0432 \u043e\u0441\u043d\u043e\u0432\u043d\u043e\u043c \u0441\u0430\u043c\u044b\u0439 \u043d\u0438\u0436\u043d\u0438\u0439 \u0443\u0440\u043e\u0432\u0435\u043d\u044c Link Layer \u0438 Physical Layer. […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":84025,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-84024","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47BLE sob o microsc\u00f3pio (ATTs GATTs\u2026) | ProHoster","description":"BLE sob o microsc\u00f3pio (ATTs GATTs...) Parte 1.","canonical_url":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/ble-pod-mikroskopom-atty-gatty","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"pt_PT","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47BLE \u043f\u043e\u0434 \u043c\u0438\u043a\u0440\u043e\u0441\u043a\u043e\u043f\u043e\u043c (ATT\u044b GATT\u044b\u2026) | ProHoster","og:description":"BLE \u043f\u043e\u0434 \u043c\u0438\u043a\u0440\u043e\u0441\u043a\u043e\u043f\u043e\u043c (ATT\u044b GATT\u044b...) \u0427\u0430\u0441\u0442\u044c 1.","og:url":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/ble-pod-mikroskopom-atty-gatty","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-06-04T17:42:32+00:00","article:modified_time":"2020-06-04T17:42:32+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"84024","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 15:06:38","updated":"2022-09-28 11:11:59","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/posts\/84024","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/comments?post=84024"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/posts\/84024\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/media\/84025"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/media?parent=84024"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/categories?post=84024"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/tags?post=84024"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}