Desenvolvimento de Analisador e Modificador de Pacotes para Detecção e Correção de Problemas de Interoperabilidade Do Sip Entre Dispositivos

UNIVERSIDADE DE CAXIAS DO SUL - UCS
CAMPUS UNIVERSITRIO DA REGIO DOS VINHEDOS - CARVI

CENTRO DE CINCIAS EXATAS DA NATUREZA E DE TECNOLOGIA - CENT
ENGENHARIA ELTRICA

GIOVANNI AUGUSTO ATTOLINI

DESENVOLVIMENTO DE ANALISADOR E MODIFICADOR DE
PACOTES PARA DETECO E CORREO DE PROBLEMAS DE
INTEROPERABILIDADE DO SIP ENTRE DISPOSITIVOS

BENTO GONALVES
2011



Trabalho de concluso do curso de graduao
em Engenharia Eltrica apresentado ao Centro
de Cincias Exatas da Natureza e de
Tecnologia, como requisito para obteno do
ttulo de Engenheiro Eletricista.

Orientador: Prof. Me. Ricardo Balbinot

BENTO GONALVES
2011



Trabalho de concluso do curso de graduao
em Engenharia Eltrica apresentado ao Centro
de Cincias Exatas da Natureza e de
Tecnologia, como requisito para obteno do
ttulo de Engenheiro Eletricista.

Aprovado em _____ de _________________ de _________.

BANCA EXAMINADORA:

Profa. Me. Marilda Spindola - UCS
________________________________

Prof. Me. Ricardo Becker - UCS
________________________________

Prof. Me. Ricardo Balbinot - UCS
________________________________

AGRADECIMENTOS
Aos professores do curso de Engenharia Eltrica da Universidade de Caxias do Sul
cuja meta de qualidade no ensino foi sempre superar as expectativas.
Ao professor Ricardo Balbinot em especial pela ajuda no desenvolvimento deste
projeto.
A minha famlia pelo apoio incondicional.
A minha noiva Mariele pela compreenso, confiana e amor.
A empresa Simar Telecom pela infraestrutura cedida para os testes.
Enfim, a todos que de alguma forma participaram desta etapa da minha vida.

The show must go on!
Freddie Mercury

RESUMO
Historicamente o homem tem produzido equipamentos buscando a evoluo e
facilitao da comunicao. A Voz Sobre IP (VoIP) um dos servios que nasceu dessa
evoluo. Este servio utiliza uma rede comutada por pacotes para a transmisso de voz. Para
que seja possvel o estabelecimento de uma chamada VoIP, necessrio o uso de um
protocolo de sinalizao chamado SIP ou Session Initiation Protocol. O sucesso no
estabelecimento depende da correta operao desse protocolo atravs da rede de dados.
Existem diversas falhas que podem ocorrer durante a configurao e a operao desse
protocolo. Portanto, observou-se a necessidade do desenvolvimento de uma ferramenta capaz
de criar um registro dos eventos para a anlise e que possibilite tambm a alterao da
sinalizao sem mesmo alterar qualquer configurao nos equipamentos envolvidos na
comunicao. Para que isso seja possvel, utilizada uma biblioteca junto com uma
linguagem de programao para efetuar a captura, anlise e alterao desses pacotes que
fazem parte da sinalizao. Detectado o problema, a alterao correta na configurao dos
equipamentos envolvidos ser feita reduzindo assim o tempo de implantao.

Palavras-chave: Voice over IP, rede, pacotes, protocolo, sinalizao, captura, injeo.

ABSTRACT
Historically, devices were produced always looking for the evolution of
communication. The Voice over IP (VoIP) is one service that came from this evolution. This
service uses a packet switching network to voice transmission. A protocol named SIP or
"Session Initiation Protocol" is used for VoIP calls signaling management. The establishment
successs depends on the correct SIP configuration and operation, but there are a lot of
problems that can appear during this proccess. Therefore, a development of a SIP analyzer
tool was observed. With this tool, the operator must be able to change the signaling between
the devices without any device configuration changing. A library with a programming
language is used to create a tool able to capture, change and inject the signaling packets. After
the fail detection, the correct changing in device configuration is made reducing the
implantation time.

Keywords: Voice over IP, network, packets, protocol, signaling, capture, injection.

LISTA DE ILUSTRAES
Figura 1 - Comunicao baseada em comutao de circuitos. ............................................... 24
Figura 2 - Comunicao baseada na comutao de pacotes. .................................................. 26
Figura 3 - Modelo de referncia OSI. ................................................................................... 29
Figura 4 - Modelo de referncia TCP/IP. .............................................................................. 30
Figura 5 - Campos do pacote IP. .......................................................................................... 31
Figura 6 Cabealho UDP. .................................................................................................. 33
Figura 7 - Campos utilizados para o clculo do checksum UDP. ........................................... 34
Figura 8 - Protocolos no modelo TCP/IP. ............................................................................. 35
Figura 9 - Cabealho RTP. ................................................................................................... 37
Figura 10 - Exemplo de requisio SIP. ............................................................................... 40
Figura 11 - Exemplo de linha de requisio. ......................................................................... 40
Figura 12 - Mtodo INVITE. ............................................................................................... 41
Figura 13 - Mtodo ACK. .................................................................................................... 42
Figura 14 - Mtodo CANCEL. ............................................................................................. 43
Figura 15 - Mtodo BYE. ..................................................................................................... 45
Figura 16 - Mtodo REGISTER. .......................................................................................... 46
Figura 17 - Exemplo de resposta SIP. ................................................................................... 47
Figura 18 - Exemplo de linha de estado. ............................................................................... 48
Figura 19 - Exemplo do campo From retirado de uma requisio SIP. .................................. 50
Figura 20 - Exemplo do campo To retirado de uma requisio SIP. ...................................... 50
Figura 21 - Exemplo do campo Via retirado de uma requisio SIP. .................................... 51
Figura 22 - Exemplo do campo Call-ID retirado de uma requisio SIP. .............................. 51
Figura 23 - Exemplo do campo CSeq retirado de uma requisio SIP. .................................. 52
Figura 24 - Exemplo do campo Contact retirado de uma requisio SIP. .............................. 52
Figura 25 - Exemplo do campo Max-Forwards retirado de uma requisio SIP. ................... 53
Figura 26 - Exemplo do campo WWW-Authenticate retirado de uma requisio SIP. ............ 53
Figura 27 - Exemplo do campo Authorization retirado de uma requisio SIP. ..................... 54
Figura 28 - Gerao da primeira criptografia. ....................................................................... 55
Figura 29 - Gerao da segunda criptografia. ....................................................................... 55
Figura 30 - Gerao da terceira criptografia. ........................................................................ 56

Figura 31 - Exemplo de criptografia com dados reais. .......................................................... 56
Figura 32 - Cdigo para criao de uma sesso de captura. .................................................. 59
Figura 33 - Compilao de um filtro de captura. ................................................................... 59
Figura 34 Aplicao de um filtro de captura em uma interface. ........................................... 60
Figura 35 - Exemplo de expresso de filtro. ......................................................................... 60
Figura 36 - Exemplo de cdigo utilizando libpcap. .............................................................. 61
Figura 37 - Viso geral do Eclipse........................................................................................ 64
Figura 38 - Viso geral do Wireshark. .................................................................................. 64
Figura 39 - Viso geral do eyeBeam. .................................................................................... 65
Figura 40 - Detalhes da configurao do eyeBeam................................................................ 66
Figura 41 - Configurao do Asterisk. .................................................................................. 67
Figura 42 - Configurao do plano de numerao no Asterisk. ............................................. 67
Figura 43 - Viso geral do menu principal. ........................................................................... 69
Figura 44 - Viso geral da seo "Escuta". ........................................................................... 70
Figura 45 - Viso geral da sesso de captura. ....................................................................... 71
Figura 46 - Viso geral da seo "Dados Escutados". ........................................................... 71
Figura 47 - Viso geral da seo "Injeo". .......................................................................... 72
Figura 48 - Viso geral da opo de "Mostrar Resultados". .................................................. 73
Figura 49 - Viso geral da seo "Limpar Resultados". ........................................................ 74
Figura 50 - Viso geral da seo "Limpar Tudo". ................................................................. 74
Figura 51 Fluxograma geral do projeto. ............................................................................. 75
Figura 52 - Exemplo de impresso realizada pela funo imprime_pkt. ................................ 96
Figura 53 - Topologia utilizada na validao da ferramenta desenvolvida. ......................... 126
Figura 54 - Seo "Dados Escutados". ................................................................................ 130
Figura 55 - Pacotes capturados pelo Wireshark. ................................................................. 130
Figura 56 - Pacote 01 capturado pelo Wireshark. ............................................................... 131
Figura 57 - Seo "Dados Escutados". ................................................................................ 132
Figura 58 - Seo "Injeo". ............................................................................................... 133
Figura 59 - Seo "Mostrar Resultados". ............................................................................ 133
Figura 60 - Pacotes capturados pelo Wireshark. ................................................................. 134
Figura 61 - Pacote 02 capturado pelo Wireshark. ............................................................... 135

TABELAS
Tabela 1 - Comparao entre a rede comutada por circuitos e a rede comutada por pacotes. . 27
Tabela 2 - Lista de codecs comumente utilizados. ................................................................ 38
Tabela 3 Campos no cabealho de uso obrigatrio no mtodo INVITE. ............................ 41
Tabela 4 - Campos no cabealho de uso obrigatrio no mtodo ACK. .................................. 43
Tabela 5 - Campos no cabealho de uso obrigatrio no mtodo CANCEL. .......................... 44
Tabela 6 - Campos no cabealho de uso obrigatrio no mtodo BYE. .................................. 45
Tabela 7 - Campos no cabealho de uso obrigatrio no mtodo REGISTER. ....................... 46
Tabela 8 - Campos no cabealho de uso obrigatrio no mtodo OPTIONS........................... 47
Tabela 9 - Classes das mensagens de resposta SIP. ............................................................... 48
Tabela 10 - Mensagens SIP. ................................................................................................. 48
Tabela 11 - Exemplo de arquivo de captura. ......................................................................... 79
Tabela 12 - Exemplo de arquivo de informao da sesso. ................................................... 82
Tabela 13 - Exemplo de arquivo de informaes dos campos SIP......................................... 82
Tabela 14 - Arquivo de cabealho config.h. .......................................................................... 85
Tabela 15 - Estrutura do cabealho Ethernet. ........................................................................ 88
Tabela 16 - Estrutura do cabealho IP. ................................................................................. 88
Tabela 17 - Estrutura do cabealho UDP. ............................................................................. 89
Tabela 18 - Estrutura do pseudo-header. .............................................................................. 89
Tabela 19 - Desenvolvimento da funo valor_string. .......................................................... 90
Tabela 20 - Desenvolvimento da funo troca_string. .......................................................... 91
Tabela 21 - Desenvolvimento da funo metodo_sip. ........................................................... 92
Tabela 22 - Desenvolvimento da funo valor_sip_string. ................................................... 93
Tabela 23 - Desenvolvimento da funo payload_sip. .......................................................... 93
Tabela 24 - Parte do desenvolvimento da funo str2hex...................................................... 94
Tabela 25 - Desenvolvimento da funo imprime_pkt. ......................................................... 95
Tabela 26 - Desenvolvimento da funo rl_ttyset. ................................................................ 96
Tabela 27 - Incio da funo callback. .................................................................................. 97
Tabela 28 - Primeira parte do desenvolvimento da funo callback. ..................................... 98
Tabela 29 Segunda parte do desenvolvimento da funo callback. .................................... 98
Tabela 30 - Terceira parte do desenvolvimento da funo callback. ..................................... 99

Tabela 31 - Desenvolvimento da funo cabecalho. ........................................................... 100
Tabela 32 - Desenvolvimento da funo menu_main. ......................................................... 101
Tabela 33 - Desenvolvimento da funo menu_1................................................................ 101
Tabela 34 - Desenvolvimento da funo menu_1_1. ........................................................... 102
Tabela 42 - Inicializao das variveis globais. .................................................................. 108
Tabela 43 - Carregamento dos valores salvos. .................................................................... 109
Tabela 44 - Verificao do diretrio de armazenamento. .................................................... 109
Tabela 45 - Desenvolvimento do controle de acesso principal. ........................................... 109
Tabela 46 - Desenvolvimento do controle de acesso da seo "Escuta". ............................. 111
Tabela 47 - Desenvolvimento da funo de captura da seo "Escuta". .............................. 112
Tabela 48 - Desenvolvimento das threads de controle da seo "Escuta". .......................... 113
Tabela 49 - Controle de menu da seo "Dados Escutados". ............................................... 114
Tabela 50 - Parte inicial da funo dados_esc. ................................................................... 115
Tabela 51 - Gravao dos campos SIP no arquivo. ............................................................. 115
Tabela 52 - Impresso do menu de acesso aos campos SIP. ................................................ 116
Tabela 53 - Controle interface operador seo "Injeo". ................................................... 117
Tabela 54 - Desenvolvimento das threads de controle de injeo e captura. ....................... 117
Tabela 55 - Declarao das variveis na funo injeta. ....................................................... 118
Tabela 56 - Alocao de memria das variveis. ................................................................ 119
Tabela 57 - Incio do processo de injeo e captura. ........................................................... 120
Tabela 58 - Autenticao do SIP. ....................................................................................... 121
Tabela 59 - Leitura dos dados do cabealho Ethernet. ........................................................ 122
Tabela 60 - Leitura dos dados e criao dos cabealhos IP e UDP. ..................................... 122
Tabela 61 - Gerao dos checksums IP e UDP. ................................................................... 123
Tabela 62 - Impresso do pacote e injeo. ........................................................................ 123
Tabela 63 - Desenvolvimento da funo func_escuta. ........................................................ 124
Tabela 64 - Desenvolvimento das threads de captura. ........................................................ 125
Tabela 65 - Pacote 01 capturado pelo software desenvolvido. ............................................ 130

Tabela 66 - Pacote 02 capturado pelo software. .................................................................. 134
Tabela 67 - Cdigo para gerao do checksum. .................................................................. 141
Tabela 68 - Cdigo utilizado para a gerao do hash MD5. ................................................ 142
Tabela 69 - Cdigo para organizao dos bits na criao do pacote. ................................... 148

SUMRIO
1 INTRODUO ............................................................................................... 19
1.1 RELEVNCIA E JUSTIFICATIVA ................................................................. 20
1.2 MOTIVAO PARA O DESENVOLVIMENTO ............................................. 20
1.3 OBJETIVOS GERAIS ....................................................................................... 21
1.4 OBJETIVOS ESPECFICOS ............................................................................. 21
1.5 LIMITAO DO ESCOPO .............................................................................. 22
1.6 ORGANIZAO DO TRABALHO ................................................................. 22
2 REVISO BIBLIOGRFICA ........................................................................ 23
2.1 COMUTAO DE CIRCUITOS ...................................................................... 23
2.2 COMUTAO DE PACOTES ......................................................................... 24
2.2.1 Pacotes .............................................................................................................. 25
2.3 COMPARAO ENTRE COMUTAO DE CIRCUITOS E COMUTAO
DE PACOTES ..................................................................................................................... 26
2.4 MODELOS DE REFERNCIA ......................................................................... 28
2.4.1 Modelo OSI ...................................................................................................... 28
2.4.2 Modelo TCP/IP ................................................................................................ 30
2.4.2.1 Camada de Inter-redes ....................................................................................... 31
2.4.2.1.1 Checksum I P ..................................................................................................... 32
2.4.2.2 Camada de Transporte ....................................................................................... 33
2.4.2.2.1 Checksum UDP ................................................................................................. 34
2.4.2.3 Camada de Aplicao ........................................................................................ 35
2.4.2.4 Camada de Infraestrutura de Rede ...................................................................... 35
2.5 VOZ SOBRE IP ................................................................................................ 36
2.5.1 RTP .................................................................................................................. 36
2.5.2 SIP .................................................................................................................... 38
2.5.2.1 Entidades SIP .................................................................................................... 39
2.5.2.2 Requisies SIP ................................................................................................. 39

2.5.2.2.1 Mtodo I NVI TE ................................................................................................ 40
2.5.2.2.2 Mtodo ACK ..................................................................................................... 42
2.5.2.2.3 Mtodo CANCEL .............................................................................................. 43
2.5.2.2.4 Mtodo BYE ...................................................................................................... 44
2.5.2.2.5 Mtodo REGISTER .......................................................................................... 45
2.5.2.2.6 Mtodo OPTI ONS............................................................................................. 46
2.5.2.3 Respostas SIP .................................................................................................... 47
2.5.2.4 Campos do Cabealho ....................................................................................... 49
2.5.2.4.1 From ................................................................................................................. 50
2.5.2.4.2 To ...................................................................................................................... 50
2.5.2.4.3 Via ..................................................................................................................... 51
2.5.2.4.4 Call-I D .............................................................................................................. 51
2.5.2.4.5 CSeq .................................................................................................................. 52
2.5.2.4.6 Contact .............................................................................................................. 52
2.5.2.4.7 Max-Forwards .................................................................................................. 52
2.5.2.4.8 WWW-Authenticate .......................................................................................... 53
2.5.2.4.9 Authorization .................................................................................................... 53
2.5.2.5 Autenticao do SIP .......................................................................................... 54
2.5.2.6 Vulnerabilidades do SIP .................................................................................... 56
2.6 BIBLIOTECA LIBPCAP .................................................................................. 57
2.6.1 Captura de Pacotes Utilizando a LI BPCAP ................................................... 58
2.6.2 Filtros de Captura Utilizados com a LIBPCAP .............................................. 59
2.6.3 Exemplo de Cdigo .......................................................................................... 60
3 IMPLEMENTAO DO PROTTIPO ........................................................ 62
3.1 METODOLOGIA .............................................................................................. 62
3.2 FERRAMENTAS UTILIZADAS ...................................................................... 62
3.2.1 EclipseI DE for C/C++ Developers ................................................................... 63
3.2.2 Wireshark Network Protocol Analyzer.............................................................. 63
3.2.3 eyeBeam............................................................................................................ 65
3.2.4 Asterisk ............................................................................................................. 66
3.3 ELABORAO DO FLUXOGRAMA ............................................................. 68
3.3.1 Anlises Possveis Atravs da Ferramenta...................................................... 68
3.3.2 Principais Funes do Analisador ................................................................... 68

3.3.3 Organizao da Interface com o Operador .................................................... 69
3.3.3.1 Seo Escuta .................................................................................................. 70
3.3.3.2 Seo Dados Escutados .................................................................................. 70
3.3.3.3 Seo Injeo ................................................................................................. 72
3.3.3.4 Seo Mostrar Resultados............................................................................... 72
3.3.3.5 Seo Limpar Resultados ............................................................................... 73
3.3.3.6 Seo Limpar Tudo ........................................................................................ 74
3.3.4 Fluxograma ...................................................................................................... 75
3.3.4.1 Determinao do Filtro de Captura .................................................................... 77
3.3.4.2 Determinao dos Campos para Alterao ......................................................... 77
3.4 DESENVOLVIMENTO DO ANALISADOR PROPOSTO ............................... 78
3.4.1 Definies Iniciais ............................................................................................ 78
3.4.2 Padres de Arquivos Utilizados ...................................................................... 78
3.4.2.1 Arquivos de Captura .......................................................................................... 79
3.4.2.2 Arquivo de Informaes da Sesso .................................................................... 81
3.4.2.3 Arquivo de Informaes dos Campos SIP .......................................................... 82
3.4.3 Estrutura do Cdigo ........................................................................................ 83
3.4.4 Declarao das Bibliotecas e Variveis Globais.............................................. 85
3.4.5 Estruturas de Cabealho ................................................................................. 88
3.4.6 Funes Globais ............................................................................................... 89
3.4.6.1 Funo valor_string ........................................................................................... 89
3.4.6.2 Funo troca_string ........................................................................................... 90
3.4.6.3 Funo metodo_sip ............................................................................................ 92
3.4.6.4 Funo valor_sip_string ..................................................................................... 92
3.4.6.5 Funo payload_sip ........................................................................................... 93
3.4.6.6 Funo str2hex .................................................................................................. 94
3.4.6.7 Funo imprime_pkt .......................................................................................... 95
3.4.6.8 Funo rl_ttyset ................................................................................................. 96
3.4.6.9 Funo callback ................................................................................................. 97
3.4.7 Controle de Menu .......................................................................................... 100
3.4.7.1 Funo cabecalho ............................................................................................ 100
3.4.7.2 Funo menu_main .......................................................................................... 100
3.4.7.3 Funo menu_1 ............................................................................................... 101
3.4.7.4 Funo menu_1_1 ............................................................................................ 102

3.4.7.5 Funo menu_1_2 ............................................................................................ 103
3.4.7.6 Funo menu_1_3 ............................................................................................ 103
3.4.7.7 Funo menu_2 ............................................................................................... 104
3.4.7.8 Funo menu_3 ............................................................................................... 105
3.4.7.9 Funo menu_4 ............................................................................................... 105
3.4.7.10 Funo menu_5 ............................................................................................... 106
3.4.7.11 Funo menu_6 ............................................................................................... 107
3.4.8 Controle Principal ......................................................................................... 107
3.4.9 Controle de Escuta ......................................................................................... 111
3.4.10 Controle de Alterao .................................................................................... 114
3.4.11 Controle de Injeo ........................................................................................ 116
4 VALIDAO DA FERRAMENTA ............................................................. 126
4.1 TOPOLOGIA UTILIZADA NA VALIDAO .............................................. 126
4.2 OBJETIVOS EM CADA TESTE .................................................................... 127
4.2.1 Teste de Validao de Captura ..................................................................... 127
4.2.2 Teste de Validao de Captura e Injeo ...................................................... 127
5 RESULTADOS E CONCLUSES ............................................................... 129
5.1 RESULTADOS OBTIDOS DO TESTE DE CAPTURA ................................. 129
5.2 RESULTADOS OBTIDOS DO TESTE DE CAPTURA E INJEO ............. 132
5.3 CONCLUSO ................................................................................................. 136
5.4 SUGESTO PARA TRABALHOS FUTUROS .............................................. 137
5.4.1 Aperfeioamento da Ferramenta .................................................................. 137
5.4.2 Continuidade da Proposta ............................................................................. 137
REFERNCIAS BIBLIOGRFICAS ............................................................................ 139
ANEXO A Cdigo para gerao do Checksumutilizado nos cabealhos IP e UDP ... 141
ANEXO B Cdigo para gerao do hash MD5 utilizado no SIP ................................. 142
ANEXO C Cdigo para organizao dos bits na criao do pacote ............................ 148

SIGLAS
ADPCM: Adaptive Differential Pulse Code Modulation
ARPANET: Advanced Research Projects Agency Network
CDR: Call Retail Records
DoD: Department of Defense
DSP: Digital Signal Processor
FTP: File Transfer Protocol
HTTP: Hyper Text Transfer Protocol
IEEE: Institute of Electrical and Electronics Engineers
IP: Internet Protocol
IPDR: IP Detail Record
ISO: International Organization for Standardization
ITU-T: International Telecommunication Union
MD5: Message-Digest Algorithm 5
MOS: Mean Opinion Score
MPEG: Moving Picture Experts Group
NAT: Network Address Translation
OSI: Open Systems Interconnection
PBX: Private Branch Exchange
PC: Personal Computer
PCM: Pulse Code Modulation
QoS: Quality of Service
RTP: Real-time Transport Protocol

SDP: Session Description Protocol
SIP: Session Initiation Protocol
SMTP: Simple Mail Transfer Protocol
TCP: Transmission Control Protocol
ToS: Type of Service
TTL: Time To Live
UA: User Agent
UDP: User Datagram Protocol
URI: Uniform Resource Identifier
VoIP: Voice Over IP
VPN: Virtual Private Network

19

1 INTRODUO
de amplo conhecimento a importncia da inveno do telefone na evoluo dos
sistemas de comunicao, pois foi a partir dele que a comunicao distncia tornou-se mais
simples e efetiva, fazendo com que notcias que antes levavam tempo para serem entregues
passassem a ser transmitidas em um perodo mais curto de tempo (WALLINGFORD, 2005).
Depois do telefone, a comunicao distncia evoluiu para a comunicao de dados, dando
origem posteriormente a rede mundial de computadores, hoje conhecida como Internet. A
Internet hoje possibilita a comunicao distncia de diversas formas e a transmisso de
dados em diversos formatos, sejam eles imagens, vdeos, msicas ou documentos. A Internet
nasceu de uma concepo de rede baseada na comutao de pacotes onde o meio
compartilhado (GOLENIEWSKI, 2006).
A comunicao por voz, antes normalmente feita utilizando o telefone, hoje pode
tambm ser feita pela Internet. Criou-se um servio especfico que trata da comunicao de
voz sobre a Internet, denominado Voz Sobre IP ou VoIP (Voice over IP), onde os dados
transmitidos possuem informaes de fala que saem de uma origem e chegam a um destino
(WALLINGFORD, 2005). Para o seu funcionamento, a VoIP conta com o auxlio de alguns
protocolos, entre os quais podem ser destacados o RTP (Realtime Transfer Protocol) e o SIP
(Session Initiation Protocol). O primeiro responsvel pelo transporte de dados em tempo
real, no caso da VoIP, a voz digitalizada, e o segundo responsvel pelo estabelecimento das
sesses multimdia, no caso as chamadas usando a rede IP (CAMARILLO, 2002).
O protocolo SIP, por ser um protocolo relativamente novo e ainda em franco
desenvolvimento, apresenta incompatibilidades entre implementaes, vulnerabilidades de
segurana e at mesmo eventuais brechas de operao que podem dificultar sua utilizao
(CAMARILLO, 2002). Dados esses possveis problemas de operao do SIP, em conjunto
com a necessidade de reduo do tempo de instalao de uma soluo de VoIP, o presente
trabalho trata do desenvolvimento de uma ferramenta capaz de capturar, alterar e injetar os
pacotes referentes a sinalizao da VoIP a fim de fornecer uma anlise da interoperabilidade
do protocolo SIP entre os dispositivos para o operador da ferramenta.
20

1.1 RELEVNCIA E JUSTIFICATIVA
Face aos fatos destacados anteriormente, em algumas implementaes da tecnologia
de VoIP ocorrem dificuldades em obter a interoperabilidade entre dispositivos distintos
atravs do uso do protocolo SIP. Como exemplo, em algumas situaes, seno a maioria
delas, apenas no envio da mensagem SIP na qual o usurio a ser contatado informado, j se
observam problemas na comunicao. Nota-se, portanto, que com o uso de uma ferramenta
que possibilite a anlise dessa troca de informaes entre esses dispositivos, e em um segundo
passo, permita a alterao dessas informaes de forma a corrigir a anomalia detectada, torna-
se possvel a reduo no tempo de anlise e soluo dos problemas reduzindo ao final o tempo
total de implantao.
A soluo proposta tambm se diferencia de softwares analisadores de protocolos
como o Wireshark (LAMPING, SHARPE e WARNICKE, 2011), pelo fato de conceber
tambm a alterao de campos do protocolo e posterior injeo do mesmo na rede para fins de
testes.
1.2 MOTIVAO PARA O DESENVOLVIMENTO
A motivao para o desenvolvimento deste projeto surgiu da observao feita em
campo durante a implantao de um dispositivo SIP interligado a um servidor SIP. No caso
especfico desta implantao, o dispositivo SIP em questo possui algumas limitaes quanto
a facilidade de configurao. Em alguns casos, muito tempo demandado para corrigir a
configurao do dispositivo adequando as informaes de identificao do usurio,
autenticao do usurio e identificao do usurio que est sendo convidado para uma sesso
multimdia. Com base nestas dificuldades, definiu-se como uma forma de minimizar o tempo
de implantao, criar uma ferramenta que pudesse fornecer anlises acerca da
interoperabilidade do protocolo SIP entre o dispositivo em questo e o servidor SIP. A
ferramenta deve ser capaz de capturar pacotes da rede, alterar esses pacotes e injetar esses
pacotes para gerar uma nova anlise. Sendo as alteraes efetuadas nos pacotes SIP mais
simples do que a configurao no prprio dispositivo SIP, ocorre uma minimizao no tempo
21

de implantao alm de no depender muitas vezes do fabricante para detectar possveis
problemas existentes na implementao do protocolo SIP dentro do equipamento.
1.3 OBJETIVOS GERAIS
O trabalho apresenta como tema o desenvolvimento de um software baseado no
sistema operacional Linux para efetuar a anlise e a possvel correo no fluxo de mensagens
SIP durante a negociao de uma chamada via VoIP. Esse software est baseado na captura,
alterao e injeo dos pacotes na rede, de forma que seja possvel efetuar alteraes nas
mensagens determinadas pelo operador do software durante a anlise fornecida pelo mesmo.
O objetivo geral do trabalho a reduo no tempo de implantao de sistemas
baseados em VoIP atravs do desenvolvimento de uma ferramenta capaz de gerar um registro
da troca de sinalizao para a anlise. Aps a anlise, a ferramenta deve permitir a alterao
dos pacotes com base na anlise do operador ou nas informaes recebidas atravs de regras
pr-estabelecidas para uma posterior injeo desses pacotes e gerao de um novo registro
para uma nova anlise.
1.4 OBJETIVOS ESPECFICOS
So objetivos especficos do presente trabalho:
a) Criar uma ferramenta que permita capturar, alterar e reinjetar os pacotes do fluxo
de mensagens SIP;
b) Fornecer uma interface adequada ao operador da ferramenta;
c) Validar a ferramenta desenvolvida;
d) Analisar os resultados e definir possveis melhorias na ferramenta.
22

1.5 LIMITAO DO ESCOPO
O desenvolvimento da ferramenta limita-se a:
a) No desenvolver qualquer tipo de dispositivo SIP, sendo que para os testes de
validao sero utilizados dispositivos j existentes;
b) A rede a ser utilizada para a validao da ferramenta ser uma rede j existente
que apresente as caractersticas que viabilizam o processo de validao;
c) A ferramenta no altera nenhum outro campo que no esteja relacionada ao
protocolo em questo ou ao seu processo funcional;
d) Questes relacionadas ao fluxo de audio das chamadas no sero abordadas.
1.6 ORGANIZAO DO TRABALHO
A sequncia do trabalho est descrita a seguir:
a) O captulo dois faz um apanhado geral da evoluo da telefonia at a criao da
VoIP dando uma ateno especial ao protocolo SIP e suas caractersticas;
b) O captulo trs trata do desenvolvimento do software proposto;
c) O captulo quatro determina os testes a serem realizados para a validao do
software;
d) No captulo cinco feita a exposio dos resultados obtidos no processo de
validao e as consideraes finais em relao ao trabalho como concluso e
trabalhos futuros.
23

2 REVISO BIBLIOGRFICA
A partir da inveno do telefone, o crescimento da demanda pela sua utilizao foi
significativo. Novos servios e novos equipamentos surgiram e com eles novos cenrios se
tornaram comuns no contexto das telecomunicaes (WALLINGFORD, 2005).
A partir da interconexo de dois ou mais telefones surgiu a necessidade de um meio
fsico comum entre esses equipamentos para que o sinal fosse transmitido de um telefone para
outro, dando motivao para a criao das centrais telefnicas. No contexto de uso privado
surgiu igualmente um novo equipamento compartilhando esse meio comum, o qual foi
denominado de PBX ou Private Branch Exchange. Esses equipamentos usam o conceito de
comutao de circuitos que detalhado na prxima seo (WALLINGFORD, 2005).
2.1 COMUTAO DE CIRCUITOS
Para Goleniewski (2006), a comutao de circuitos foi a base da telefonia desde a sua
criao. A principal caracterstica desse tipo de comutao a alocao do circuito durante
todo o tempo da comunicao entre os dois equipamentos interconectados e isso requer que
um circuito esteja previamente configurado entre eles, ressaltando-se que quando a
comunicao encerrada o circuito liberado. Antes mesmo da comunicao propriamente
dita, nesse tipo de comutao se faz necessrio uma requisio partindo da origem at o
destino. Depois de alocado o circuito e o destino ter sido notificado sobre a comunicao
que se inicia a transmisso do sinal desejado. Na Figura 1, um exemplo de comunicao
baseada na comutao de circuitos, pode-se observar circuitos alocados permanentemente
representados pela linha fixa e circuitos alocados por demanda ou quando a comunicao
estabelecida representados pela linha tracejada.
24

Figura 1 - Comunicao baseada em comutao de circuitos.
Fonte: (GOLENIEWSKI, 2006)
2.2 COMUTAO DE PACOTES
Da origem da comutao de pacotes pode-se observar:
"Enquanto a comutao de circuitos foi inventada para facilitar a comunicao de
voz, a comutao de pacotes teve sua origem na comunicao de dados."
(GOLENIEWSKI, 2006)
A comutao de pacotes teve sua origem na comunicao de dados e se baseou no
processamento interativo de dados. A primeira gerao do processamento de dados foi o
processamento em lote. Nesse caso, o sujeito que estava gerenciando ou produzindo os dados
o fazia atravs de um terminal e armazenava os dados em cartes perfurados que
posteriormente evoluram para fitas e depois para discos magnticos. Depois de armazenados,
os dados eram transmitidos a um host
1
que era responsvel pelo processamento desses dados.
A transmisso era caracterizada pelo uso de um circuito comutado e por gerar um fluxo de
dados alto e constante (GOLENIEWSKI, 2006).
Ao contrrio do processamento em lote, o processamento interativo feito online
2
,
sendo que essencialmente o trfego de dados s existe se o usurio pressionar a tecla Enter e
no quando ele estiver editando uma planilha por exemplo. Isso significa um baixo uso da

1
Host: computador que recebe ou envia dados atravs de um meio de comunicao (GOLENIEWSKI, 2006).
2
online: estado de comunicao constante (GOLENIEWSKI, 2006).
25

conexo que utilizada em um grande espao de tempo com um baixo trfego de dados.
Assim, Goleniewski (2006) afirma que no processamento interativo no eficiente se utilizar
um circuito comutado, onde existe um tempo de conexo maior com um fluxo de dados
menor que o processamento em lote. A comutao de pacotes foi desenvolvida para aumentar
a eficincia da transmisso que feita atravs da multiplexao de pacotes de dados sobre um
circuito virtual. Dessa forma, a utilizao dos circuitos otimizada e a inteligncia da rede
descentralizada, pois os terminais tambm gerenciam a conexo ao contrrio da comutao de
circuitos, que feita somente por uma entidade centralizada.
2.2.1 Pacotes
Para Tanenbaum (2003), um pacote essencialmente uma pequena mensagem
enviada por um dispositivo atravs de um meio compartilhado. Pacotes so enviados para os
comutadores de pacotes que definem o caminho por onde devem ser enviados com base na
informao do cabealho do pacote. O cabealho possui informaes de origem, destino e a
sequncia do pacote, sendo que pelo fato de cada pacote ter um tratamento individual pelo
comutador de pacotes, cada pacote pode percorrer um caminho diferente da origem at seu
destino. Percorrendo caminhos diferentes, os pacotes podem chegar de forma desordenada ao
seu destino. Por essa razo, o destino deve ser capaz de reordenar esses pacotes para recompor
a informao contida nos dados de forma correta. Na Figura 2 pode ser observado um
exemplo da comutao de pacotes sendo realizada, onde pacotes que partem de uma origem
para um destino tomam caminhos diferentes.
26

Figura 2 - Comunicao baseada na comutao de pacotes.
2.3 COMPARAO ENTRE COMUTAO DE CIRCUITOS E COMUTAO DE
PACOTES
Segundo Goleniewski (2006), a comutao de pacotes possui uma srie de
caractersticas negativas, como latncia, jitter
3
e perda de pacotes, o que geralmente no
ocorre na comutao de circuitos. Por essa razo, uma rede comutada por pacotes no oferece
as mesmas caractersticas de operao que uma rede comutada por circuitos, porm, uma rede
comutada por pacotes oferece maior confiabilidade de entrega pelo fato dos pacotes poderem
ser enviados por caminhos diferentes, aumentando a chance de entrega. Redes baseadas em
comutao de pacotes possuem uma bilhetagem
4
diferenciada das redes comutadas por
circuitos. A bilhetagem em redes comutadas por pacotes formulada sobre o volume de
pacotes transmitidos e/ou a banda utilizada (GOLENIEWSKI, 2006).
Para Goleniewski (2006) redes baseadas em comutao de circuitos so consideradas
superiores em termos de atrasos em filas de entrega, tornando assim latncia e jitter

3
Jitter: variao do atraso na entrega de um pacote (DAVIDSON, 2008).
4
bilhetagem: ato de taxar pelo seu uso; a taxao pelo uso do telefone um exemplo de bilhetagem
(GOLENIEWSKI, 2006).
27

previsveis e sendo consideradas mais eficientes para transmisso de dados em tempo real. Na
Tabela 1 esto descritas algumas diferenas entre redes comutadas por circuitos e comutadas
por pacotes.
Tabela 1 - Comparao entre a rede comutada por circuitos e a rede comutada por pacotes.
CARACTERSTICAS COMUTAO POR
CIRCUITOS
COMUTAO POR
PACOTES
Origem Telefonia Comum Redes de dados
Orientao ou no
conexo
Orientado conexo Ambos
Aplicaes Voz em tempo real, fluxo
de mdia,
videoconferncia, vdeo-
sob-demanda, aplicaes
que precisam de baixo
atraso e baixa perda de
pacotes
Trfego de dados com
longo tempo de conexo
mas baixo fluxo de dados,
aplicaes que toleram
atrasos e perda de pacotes
Latncia/atraso/jitter Baixa latncia e mnimo
atraso
Sujeita a latncia, atrasos e
jitter por causa do
mecanismo de comutao
Inteligncia da rede Centralizada Descentralizada
Eficincia da largura de
banda
Baixa Alta
Perda de pacotes Baixa De baixa a alta dependendo
da rede
28

2.4 MODELOS DE REFERNCIA
A comunicao entre dispositivos atravs de uma rede realizada segundo as
seguintes afirmaes:
"Antes que dois computadores ou dispositivos de rede possam trocar informaes,
eles precisam estabelecer uma comunicao, e onde os protocolos so utilizados.
Um protocolo de rede habilita dois dispositivos a se comunicarem por usar um
conjunto de regras. O modelo OSI e os padres de protocolo ajudam a assegurar que
os dispositivos de rede esto aptos a trabalhar juntos sobre a rede."
(GOLENIEWSKI, 2006)
Conforme Goleniewski (2006), os modelos de referncia ajudam a assegurar a
compatibilidade entre os dispositivos de rede. Junto com os modelos de referncia, existem
tambm os padres de protocolos que podem ser definidos como um conjunto de regras ou
coleo de componentes responsveis pela execuo de determinadas tarefas. Uma pilha de
protocolos constituda de vrios protocolos, onde alguns podem ser responsveis pela
comunicao das interfaces de rede com a rede e outros so responsveis pela leitura das
informaes da interface de rede feita pelo computador. J uma camada pode ser definida
como uma seo da pilha de protocolos que responsvel por realizar tarefas semelhantes.
2.4.1 Modelo OSI
Para Tanenbaum (2003), o modelo de referncia OSI (Open Systems
Interconnection) foi criado com a inteno de padronizar os protocolos utilizados na
comunicao entre os sistemas operacionais. OSI significa "Interconexo de Sistemas
Abertos", pois trata da comunicao entre sistemas que esto abertos para comunicar-se com
outros sistemas. Conforme Goleniewski (2006), o modelo OSI teve sua origem em 1970,
devido s vrias incompatibilidades existentes entre os fabricantes de computadores, sendo
concebido pela Organizao Internacional de Padronizao (ISO). O modelo de referncia
OSI foi adotado pelos fabricantes de dispositivos de rede e pelos desenvolvedores de software
como um padro de comunicao para os seus produtos.
O modelo possui sete camadas que foram criadas com base em alguns princpios:
e) Cada camada possui um nvel de abstrao diferente;
29

f) Cada camada possui uma funo bem definida;
g) As funes das camadas foram definidas buscando a padronizao;
h) Os limites das camadas foram definidos buscando a diminuio do fluxo entre as
interfaces;
i) O nmero de camadas foi definido pequeno o bastante para que o modelo no se
torne complexo e grande o bastante para que funes diferentes no estejam
associadas a mesma camada.
Pode-se observar a Figura 3 que representa as sete camadas do modelo OSI e
tambm denomina cada unidade em cada camada descrita.

Figura 3 - Modelo de referncia OSI.
Fonte: (TANENBAUM, 2003)
30

2.4.2 Modelo TCP/IP
Conforme Tanenbaum (2003), o modelo de referncia TCP/IP nasceu de uma
deficincia com a ARPANET, que era uma rede de pesquisa patrocinada pelo Departamento
de Defesa dos Estados Unidos (DoD). A ARPANET conectava vrias universidades e
estabelecimentos pblicos atravs de linhas telefnicas. Com o surgimento dos rdios e
satlites, os protocolos at ento utilizados apresentavam alguns problemas de interconexo e
foi necessrio ento a criao de um novo modelo que tinha como principal caracterstica a
conexo de vrias redes de forma transparente. Outra necessidade que alavancou o
desenvolvimento de um novo modelo foi a diversidade de exigncias das aplicaes utilizadas
sobre a rede que variava de uma simples troca de arquivos at uma conversao telefnica
feita em tempo real.
O modelo TCP/IP possui apenas quatro camadas e vrias semelhanas com o modelo
OSI. Pode ser observado na Figura 4 o modelo de referncia TCP/IP juntamente com o
modelo OSI.

Figura 4 - Modelo de referncia TCP/IP.
31

2.4.2.1 Camada de Inter-redes
Dadas as necessidades da criao de um novo modelo, a camada de inter-redes foi
criada em semelhana a camada de rede do modelo de referncia OSI. Basicamente a funo
desta camada fazer com que os pacotes cheguem ao seu destino. Ela responsvel tambm
por assuntos como congestionamento e endereamento. Pelo fato dela ser uma camada no
orientada conexo, ela trata cada pacote de maneira individual e por isso cada um deles pode
tomar um caminho diferente at o seu destino. Tomando caminhos diferentes, existe a
possibilidade dos pacotes chegarem ao seu destino em ordem incorreta, a reorganizao
desses pacotes tarefa de outra camada. O protocolo utilizado pela camada de inter-redes para
garantir a entrega dos pacotes o chamado protocolo IP (Internet Protocol). Ele utilizado
para enderear os pacotes conforme sua origem e destino fazendo com que a camada de inter-
redes baseada neste sistema de endereamento seja capaz de envi-lo para o seu correto
destino (TANENBAUM, 2003). A Figura 5 mostra os campos do pacote IP.

Figura 5 - Campos do pacote IP.
Fonte: (DAVIDSON, 2008)

Os campos observados na Figura 5 so definidos como:
a) Verso - indica a verso do IP que est sendo utilizada IPv4 ou IPv6.
b) Comprimento do cabealho IP (CCIP) - indica o tamanho do cabealho do
pacote em mltiplos de 32 bits.
32

c) Tipo de servio - especifica como um protocolo da camada superior deve
tratar este pacote e tambm atravs deste campo pode-se atribuir nveis de QoS para
cada pacote.
d) Comprimento total - especifica o tamanho total do pacote IP somando o
cabealho IP e os dados em bytes.
e) Identificador - campo que identifica o pacote, utilizado para uma possvel
reorganizao no caso de fragmentao de pacotes.
f) Flags - 3 bits sendo que os 2 menos significativos controlam a fragmentao e
o mais significativo no utilizado.
g) Tempo de vida (TTL) - esse campo especifica um contador que
decrementado gradualmente em cada salto para evitar que pacotes fiquem girando
infinitamente na rede.
h) Protocolo - especifica qual protocolo da camada superior deve tratar os dados
depois do nvel IP.
i) Checksumdo cabealho - nmero utilizado para verificar se o cabealho est
ou no corrompido.
j) Endereo de origem - endereo de origem do pacote.
k) Endereo de destino - endereo de destino do pacote.
l) Opes - algumas opes que o pacote suporta a nvel de segurana.
m) Dados - os dados da camada de aplicao bem como informaes de
protocolos de nvel superior.
2.4.2.1.1 Checksum I P
Como observado no cabealho IP, o checksum um nmero utilizado para verificar a
integridade do cabealho IP. Ele garante apenas a verificao da integridade do cabealho,
cabendo aos protocolos das camadas superiores a garantia da integridade desses protocolos e
dos dados por eles transportados (STEVENS, 1993).
Para a determinao do nmero de checksum, utilizado o cabealho IP dividido em
conjuntos de 16 bits cada, considerando o campo do checksum zerado, efetuado um clculo
chamado de complemento de um que resulta em uma palavra de 16 bits. Essa palavra
ento adicionada ao cabealho IP para que o dispositivo de destino possa verificar a
33

integridade do cabealho IP (STEVENS, 1993). Detalhes do clculo e do algoritmo utilizado
vide ANEXO A.
2.4.2.2 Camada de Transporte
A camada de transporte, como no modelo OSI, tem a funo de manter um dilogo
entre a origem e o destino. Nesta camada do modelo TCP/IP, dois protocolos so definidos:
TCP e UDP. O protocolo TCP (Transmission Control Protocol) orientado conexo e
possui um controle de entrega baseado em confirmao de recebimento, o que transforma o
TCP em um protocolo confivel. J o protocolo UDP (User Datagram Protocol) no
orientado conexo e no possui um sistema de confirmao de entrega. O protocolo UDP
geralmente utilizado quando a entrega rpida mais importante que a entrega confivel, isso
pelo fato do protocolo TCP com seu mtodo de confirmao de recebimento gerar mais
trfego do que o protocolo UDP e consequentemente demandar mais tempo na troca de
informaes (TANENBAUM, 2003).
Na Figura 6 pode-se observar o cabealho UPD.

Figura 6 Cabealho UDP.
Fonte: (TANENBAUM, 2003).
O cabealho UDP possui quatro campos:
a) Porta de Origem - identifica o processo do qual o pacote originou.
b) Porta de Destino - identifica o processo para o qual o pacote deve ser entregue.
c) Comprimento - especifica o tamanho total do pacote UDP somando o cabealho
UDP e os dados por ele transportados em bytes.
d) Checksum- nmero utilizado para verificar a integridade do cabealho UDP e
dos dados que ele carrega.
34

2.4.2.2.1 Checksum UDP
O checksum do protocolo UDP utilizado para verificar a integridade do cabealho
UDP e dos dados por ele transportados. O clculo do checksum do cabealho UDP efetuado
a partir de um bloco de dados chamado pseudo-header, o cabealho UDP e o bloco de dados
transportados pelo UDP (STEVENS, 1993).
Os dados utilizados para a determinao do checksum UDP so divididos em
conjuntos de 16 bits cada. Devido ao bloco de dados transportados pelo protocolo UDP ser
varivel, pode ocorrer a situao em que o nmero de conjuntos de 8 bits seja mpar, o que
inviabiliza o clculo do checksum por no possuir um nmero inteiro de palavras de 16 bits.
Quando isso ocorrer, deve-se adicionar uma palavra de 8 bits ao fim do bloco chamada de pad
byte, deixando em nmero par o total de conjuntos de 8 bits. O pad byte caracterizado por
ser uma palavra de 8 bits zerada (STEVENS, 1993). Na Figura 7 pode-se observar os campos
que compes o pseudo-header.

Figura 7 - Campos utilizados para o clculo do checksumUDP.
Fonte: (STEVENS, 1993)
O algoritmo utilizado pode ser verificado no ANEXO A.
35

2.4.2.3 Camada de Aplicao
A camada de aplicao a camada mais alta no modelo TCP/IP, assim como no
modelo OSI. No caso do modelo TCP/IP, no existem as camadas de sesso e apresentao. A
camada de aplicao fica responsvel por todos os protocolos utilizados pelos usurios, como
exemplos pode-se citar o FTP (File Transfer Protocol) utilizado para a transferncia de
arquivos e o SMTP (Simple Mail Transfer Protocol) utilizado para a troca de e-mails atravs
da rede (TANENBAUM, 2003).
2.4.2.4 Camada de Infraestrutura de Rede
Esta camada no realmente especificada pelo modelo TCP/IP. O modelo no
especifica nenhum protocolo desta camada, somente comenta que deve existir um protocolo
atravs do qual o pacote deve ser enviado (TANENBAUM, 2003).
Na Figura 8 pode-se observar a distribuio dos protocolos comentados nas camadas
do modelo TCP/IP.

Figura 8 - Protocolos no modelo TCP/IP.
36

2.5 VOZ SOBRE IP
Pode-se definir VoIP como:
"[...]VoIP refere-se a ao especfica de transmitir dados de som digitalizado em
uma rede IP[...]" (WALLINGFORD, 2005)
Conforme Wallingford (2005), a VoIP definida como o ato de transmitir som sobre
uma rede IP, ou mais especificamente voz. Uma das vantagens da VoIP est relacionada a
convergncia, enquanto um sistema de telefonia comum necessita de uma rede totalmente
separada e especfica, a VoIP consegue utilizar a infraestrutura da rede de dados existente
tornando a logstica de implantao mais simples na questo fsica.
A VoIP utiliza dois protocolos para conseguir estabelecer a comunicao e transmitir
o som digitalizado: o protocolo de sinalizao e o protocolo de transmisso multimdia. O
protocolo de sinalizao tem a funo de estabelecer e negociar os detalhes da comunicao e
o protocolo multimdia tem a funo de fazer a transmisso do som digitalizado. Comumente
um dos protocolos de sinalizao utilizado o SIP, e um dos protocolos utilizado para a
transmisso de mdia utilizado o RTP ou "Real-time Transport Protocol" (DAVIDSON,
2008).
2.5.1 RTP
O protocolo RTP possui suas funes definidas dentro das necessidades de uma
transmisso em tempo real.
"A parte de dados do RTP um protocolo que d suporte para aplicaes com
propriedades de tempo real, como uma mdia contnua (por exemplo, udio e vdeo),
incluindo reconstruo temporal, deteco de perda e identificao de contedo."
(DAVIDSON, 2008)
Conforme Davidson (2008), o RTP responsvel pelos detalhes da comunicao em
tempo real. Reconstruo temporal, deteco de perdas e identificao de contedo so
algumas das funes do protocolo RTP. Na Figura 9 pode ser observado o cabealho do
protocolo RTP.
37

Figura 9 - Cabealho RTP.
Fonte: (DAVIDSON, 2008)
Para que a voz, um sinal analgico, seja transmitida atravs de uma rede em
fragmentos dentro de pacotes, ela precisa antes ser convertida para um sinal digital. Segundo
o teorema de Nyquist, para se amostrar um sinal analgico, preciso utilizar uma frequncia
de amostragem duas vezes maior que a frequncia que se pretende amostrar (DAVIDSON,
2008). Outra questo relevante a resoluo da quantizao, que significa o nmero de bits
que cada amostra possui. Quanto maior o nmero de bits maior a resoluo do sinal
amostrado, quanto maior a resoluo do sinal amostrado mais ele se assemelha ao sinal
original analgico. O padro de modulao dos sistemas de telefonia a modulao PCM
(Pulse Code Modulation) que utiliza uma frequncia de amostragem de 8kHz e uma resoluo
com escala logartmica de 8 bits, gerando uma taxa de 64kbps (DAVIDSON, 2008).
A compresso da voz est relacionada com o nmero de bits das amostras de voz. A
modulao PCM possui dois mtodos de compresso que conseguem estabelecer um bom
nvel de resoluo utilizando apenas 8 bits graas a um mtodo logartmico de quantizao.
Geralmente, para se atingir o mesmo resultado em uma escala linear de quantizao seriam
ncessrios 12 ou 13 bits (DAVIDSON, 2008). O mtodo ADPCM (Adaptive Differential
Pulse Code Modulation) que utiliza apenas 4 bits de resoluo gerando uma taxa de 32kbps.
Esse tipo de compresso utiliza a variao do sinal como dado ao invs do dado propriamente
dito, conseguindo uma boa resoluo com um menor nmero de bits por amostra
(DAVIDSON, 2008).
Existem padres especificados pela ITU-T para codificao e compresso de voz que
so comumente utilizados na tecnologia de VoIP, sendo tambm chamados de codecs. Os
codecs influenciam diretamente na largura de banda necessria para o trfego de voz
(DAVIDSON, 2008). Na Tabela 2 esto relacionados alguns codecs utilizados hoje e suas
respectivas taxas e tamanhos.
38

Tabela 2 - Lista de codecs comumente utilizados.
CODEC
TAXA DE
AMOSTR.
TAXA
DE
BITS
INTERVALO
DE
AMOSTR.
TAMANHO
DA
AMOSTRA
DE VOZ
BANDA
ETHERNET
MOS
G.711 8kHz 64kbps 10ms 20ms 87.2kbps 4.1
G.729 8kHz 8kbps 10ms 20ms 31.2kbps 3.92
G.723.1 8kHz 5.3kbps 30ms 30ms 20.8kbps 3.8
G.723.1 8kHz 6.3kbps 30ms 30ms 21.9kbps 3.9
Fonte: (CISCO, 2006)
De acordo com a Tabela 2, existem algumas diferenas entre os codecs quanto as
taxas e tamanhos e tambm quanto ao MOS. O MOS ou Mean Opinion Score, um sistema
de medida utilizado para mensurar a qualidade de cada codec do ponto de vista do usurio do
servio. No caso dos codecs apresentados o que possui maior MOS o que consegue prover
uma qualidade superior na conversao de acordo com a percepo do usurio do servio
(DAVIDSON, 2008).
2.5.2 SIP
O SIP ou Session Initiation Protocol um protocolo de sinalizao baseado no
HTTP capaz de gerenciar sesses multimdia conforme Camarillo (2002):
"SIP estabelece, modifica e termina sesses multimdias."
As principais funes que fazem parte do protocolo SIP (BALBINOT, 2002) so:
a) Localizao de pontos terminais;
b) Contatar os pontos terminais para o estabelecimento da sesso;
c) Troca de informaes a respeito da mdia a ser utilizada e permitindo assim o
estabelecimento da sesso;
d) Modificao das sesses j iniciadas;
39

e) Finalizao das sesses existentes.
No SIP existe um cliente que faz requisies a um servidor que as responde
(CAMARILLO, 2002).
2.5.2.1 Entidades SIP
O protocolo prev entidades fundamentais para entender a sua arquitetura
(CAMARILLO, 2002), so elas:
a) User Agent (UA): uma entidade SIP que interage com o usurio
(CAMARILLO, 2002). Por exemplo, se o usurio A precisa estabelecer uma
sesso multimdia com o usurio B, atravs do PC do usurio A ele vai utilizar
um software que contm um User Agent. O usurio B tambm possui um UA que
ser contatado para o estabelecimento da sesso (CAMARILLO, 2002).
b) Redirect Servers: sua funo ajudar na localizao de UAs para o
estabelecimento de sesses (CAMARILLO, 2002). Esse servidor contribui para a
mobilidade do usurio uma vez que ele passa informaes de localizao quando
um UA tenta ser contatado e depois sai do fluxo de mensagens (BALBINOT,
2002).
c) Proxy Servers: o proxy server possui informaes de localizao mas participa
de todo o fluxo de mensagens (CAMARILLO, 2002). Quando um UA tenta ser
contatado, o proxy server reencaminha as mensagens SIP para o destino e
continua no fluxo de mensagens se comunicando com a origem e o destino
(CAMARILLO, 2002).
d) Registrars: um registrar um rgo que aceita o registro e a autenticao de
usurios com a finalidade de localizao e identificao dos mesmos, utilizado
pelo proxy server e pelo redirect server na localizao de usurios (BALBINOT,
2002).
2.5.2.2 Requisies SIP
A requisio SIP formada por uma linha de requisio ou request-line, cabealho,
uma linha em branco e o corpo da mensagem como mostrado na Figura 10 com os fundos em
amarelo, azul, vermelho e verde respectivamente.
40

Figura 10 - Exemplo de requisio SIP.
Fone: o autor, 2011.
A linha de requisio possui trs elementos: o mtodo, o Request-URI ou endereo
de requisio e a verso do protocolo. O mtodo indica o tipo de requisio, o endereo de
requisio indica a quem a requisio direcionada e a verso indica a verso do protocolo
(CAMARILLO, 2002). Na Figura 11 o mtodo utilizado o INVITE, o endereo a quem se
destina a requisio o sip:300@192.168.33.1 e a verso do protocolo SIP/2.0.

Figura 11 - Exemplo de linha de requisio.
Fone: o autor, 2011.
2.5.2.2.1 Mtodo I NVI TE
41

O mtodo INVITE utilizado para convidar um usurio para uma sesso
(CAMARILLO, 2002). Este mtodo pode utilizar o protocolo SDP (Session Description
Protocol) para fazer a descrio da sesso e definir entre demais detalhes o codec a ser
utilizado na sesso. Na Figura 12 pode ser observada uma troca de mensagens onde o mtodo
INVITE utilizado.

Figura 12 - Mtodo INVITE.
Fonte: (CAMARILLO, 2002)
Conforme observado na Figura 12, o UA do usurio Joo est enviando um convite
para uma sesso atravs da requisio INVITE para o UA do usurio Maria. Por sua vez o UA
do usurio Maria responde a requisio informando que o aparelho de Maria est despertando.
Quando o usurio Maria atende a chamada aceitando o convite da sesso, o UA do usurio
Maria envia uma mensagem de sucesso para o UA do usurio Joo (CAMARILLO, 2002).
Quando utilizado o mtodo INVITE existem alguns campos no cabealho que so de
uso obrigatrio (JOHNSTON, 2009) e esto listados na Tabela 3.
Tabela 3 Campos no cabealho de uso obrigatrio no mtodo INVITE.
CAMPOS DO CABEALHO
Via
To
From
Call-ID
42

CSeq
Contact
Max-Forwards
Fonte: (JOHNSTON, 2009)
2.5.2.2.2 Mtodo ACK
O mtodo ACK utilizado pela origem da requisio para fazer com que o UA
destino compreenda que o UA origem entendeu a resposta enviada. No caso do INVITE, aps
a recepo da mensagem que o usurio Maria aceitou a sesso, o UA do usurio Joo envia
uma mensagem de ACK informando o entendimento da ltima mensagem do mtodo INVITE
como pode ser obsevado na Figura 13 (CAMARILLO, 2002).

Figura 13 - Mtodo ACK.
Quando utilizado o mtodo ACK, existem alguns campos do cabealho que so de
43

Tabela 4 - Campos no cabealho de uso obrigatrio no mtodo ACK.
CAMPOS DO CABEALHO
Via
To
From
Call-ID
CSeq
Max-Forwards
2.5.2.2.3 Mtodo CANCEL
O mtodo CANCEL utilizado para terminar negociaes pendentes
(CAMARILLO, 2002). Se por exemplo um UA receber uma requisio de INVITE, ele no
ir parar de processar a requisio at que receba uma mensagem CANCEL vinda da origem
da requisio INVITE. A mensagem CANCEL no tem efeito algum sobre uma sesso j
estabelecida (CAMARILLO, 2002). Na Figura 14 se pode observar com mais detalhes o uso
da mensagem CANCEL.

Figura 14 - Mtodo CANCEL.
44

Como pode ser observado na Figura 14, o mtodo CANCEL foi utilizado para
cancelar uma requisio de INVITE em andamento onde o UA do usurio Maria reponde com
uma mensagem de transao cancelada.
Quando utilizado o mtodo CANCEL existem alguns campos do cabealho que so
de uso obrigatrio (JOHNSTON, 2009) e esto listados na Tabela 5.
Tabela 5 - Campos no cabealho de uso obrigatrio no mtodo CANCEL.
CAMPOS DO CABEALHO
Via
To
From
Call-ID
CSeq
Max-Forwards
2.5.2.2.4 Mtodo BYE
O mtodo BYE utilizado para abandonar uma sesso existente ou termin-la no
caso de apenas dois UAs participarem dela. (CAMARILLO, 2002). No caso de uma sesso
onde vrios UAs esto em comunicao, o envio de uma mensagem BYE apenas identifica
que o UA qua a enviou est deixando a sesso (CAMARILLO, 2002). Na Figura 15 est
ilustrado o uso do mtodo BYE para terminar uma sesso pois no exemplo apenas dois UAs
fazem parte dela.
Quando utilizado o mtodo BYE existem alguns campos do cabealho que so de
45

Figura 15 - Mtodo BYE.
Tabela 6 - Campos no cabealho de uso obrigatrio no mtodo BYE.
CAMPOS DO CABEALHO
Via
To
From
Call-ID
CSeq
Max-Forwards
2.5.2.2.5 Mtodo REGI STER
O mtodo REGISTER utilizado pelo UA para enviar ao registrador sua localizao
e s vezes sua autentio (CAMARILLO, 2002). Na Figura 16 pode-se observar o uso do
mtodo REGISTER onde no exemplo utilizado apenas para a localizao do UA.
46

Figura 16 - Mtodo REGISTER.
Quando utilizado o mtodo REGISTER existem alguns campos do cabealho que so
Tabela 7 - Campos no cabealho de uso obrigatrio no mtodo REGISTER.
CAMPOS DO CABEALHO
Via
To
From
Call-ID
CSeq
Max-Forwards
2.5.2.2.6 Mtodo OPTI ONS
O mtodo OPTIONS utilizado para perguntar ao destino quais os mtodos
suportados e quais os protocolos suportados (CAMARILLO, 2002). Se for utilizado o mtodo
OPTIONS e o destino responder que suporta os mtodos INVITE, ACK, CANCEL, BYE e
OPTIONS, pode-se deduzir que ele no seja um registrador, pois no suporta o mtodo
REGISTER (CAMARILLO, 2002).
Quando utilizado o mtodo OPTIONS existem alguns campos do cabealho que so
47

Tabela 8 - Campos no cabealho de uso obrigatrio no mtodo OPTIONS.
CAMPOS DO CABEALHO
Via
To
From
Call-ID
CSeq
Max-Forwards
2.5.2.3 Respostas SIP
Uma resposta a uma requisio segue o mesmo padro da requisio, porm, ao
invs de uma linha de requisio a resposta tem como seu primeiro elemento a linha de estado
ou status line (CAMARILLO, 2002). Na Figura 17 est o estado da linha com fundo amarelo
e os cabealhos com fundo azul.

Figura 17 - Exemplo de resposta SIP.
Fonte: o autor, 2011.
A linha de estado tambm possui trs elementos: a verso do protocolo, o cdigo de
estado e uma frase. A verso mostra a verso do protocolo que est sendo utilizado, o cdigo
48

de estado representa o estado da transao e a frase mostra o estado da transao sem a
necessidade de interpretao do cdigo de estado (CAMARILLO, 2002). Na Figura 18 a
verso do protocolo a SIP/2.0, o cdigo de estado o 401 e a frase Unauthorized, isso
significa que ocorreu um erro no cliente com cdigo 401 indicando uma falta de autorizao.

Figura 18 - Exemplo de linha de estado.
Os estados esto divididos em classes, cada classe possui um significado. Essas
classes se identificam por cdigos que esto dentro da faixa compreendida entre 100 e 699
(CAMARILLO, 2002). Na Tabela 9 pode-se observar todas as classes e seus respectivos
significados.
Tabela 9 - Classes das mensagens de resposta SIP.
FAIXA SIGNIFICADO DA RESPOSTA
100-199 Informao
200-299 Sucesso
300-399 Redirecionamento
400-499 Erro no Cliente
500-599 Erro no Servidor
600-699 Falha Global
J na Tabela 10 esto descritas as mensagens de resposta SIP com seus respectivos
cdigos.
Tabela 10 - Mensagens SIP.
CDIGO MENSAGEM CDIGO MENSAGEM
100 Trying 414 Request-URI Too Long
180 Ringing 415 Unsupported media type
181 Call is being forwarded 420 Bad extension
182 Queued 480 Temporarily not available
49

183 Session progress 481 Call leg/transaction does not exist
200 OK 482 Loop detected
202 Accepted 483 Too many hops
300 Multiple choices 484 Address incomplete
301 Moved permanently 485 Ambiguous
302 Moved temporarily 486 Busy here
305 Use proxy 487 Request cancelled
380 Alternative service 488 Not acceptable here
400 Bad request 491 Request Pending
401 Unauthorized 493 Undecipherable
402 Payment required 500 Internal servere error
403 Forbidden 501 Not implemented
404 Not found 502 Bad gateway
405 Method not allowed 503 Service unavailable
406 Not acceptable 504 Gateway time-out
407 Proxy authentication required 505 SIP version not supported
408 Request time-out 513 Message Too Large
409 Conflict 600 Busy everywhere
410 Gone 603 Decline
411 Length required 604 Does not exist anywhere
413 Request entity too large 606 Not acceptable
Fonte: (ROSENBERG, 2002)
2.5.2.4 Campos do Cabealho
Segundo Camarillo (2002), os campos do cabealho carregam informaes da
requisio ou da resposta requisio. Alguns campos so utilizados somente nas requisies
ou nas respostas s requisies enquanto alguns so utilizados em ambos os casos.
50

2.5.2.4.1 From
O campo From identifica o originador da requisio que um dos endereos usados
na identificao do dilogo. Juntamente com a identificao do originador, o campo From
pode informar o nome do originador. Pode conter tambm uma tag ou etiqueta utilizada para
identificar a chamada, essa etiqueta formada por um nmero aleatrio de no mnimo 32 bits
(JOHNSTON, 2009). Na Figura 19 o campo From identifica que o originador o
sip:200@192.168.33.1 de nome TCC e a etiqueta que identifica a chamada 7136ca6e.

Figura 19 - Exemplo do campo From retirado de uma requisio SIP.
Este campo utilizando tanto em requisies quanto em respostas s requisies
(JOHNSTON, 2009).
2.5.2.4.2 To
O campo To indica quem deve receber a requisio. Todas as respostas geradas pelo
proxy server devem conter este campo juntamente com a etiqueta que identifica a chamada, o
usurio que gera a chamada no coloca etiqueta no campo To a no ser que mais de um
campo Via possa existir no cabealho. O campo To pode conter tambm o nome do usurio
que deve receber a requisio alm de sua identificao (JOHNSTON, 2009). A Figura 20
identifica que o destino da requisio sip:300@192.168.33.1.

Figura 20 - Exemplo do campo To retirado de uma requisio SIP.
(JOHNSTON, 2009).
51

2.5.2.4.3 Via
O campo Via utilizado para rotear as respostas para a origem da requisio. Esse
campo carrega o nome e a verso do protocolo, o nome do protocolo de transporte e o
endereo da origem. Alm do endereo, esse campo carrega tambm uma etiqueta chamada
branch que contm informaes dos campos To, From, Call-ID e do elemento Request-URI.
Ele pode conter tambm o elemento rport onde o proxy server preenche este elemento com o
nmero da porta a qual ele recebeu a requisio (JOHNSTON, 2009). Na Figura 21 pode-se
observar a verso do protocolo SIP/2.0, o protocolo de transporte UDP, o endereo de origem
da requisio 192.168.33.100:9195, a etiqueta branch=z9hG4bK-d87543-785719176-1--
d87543- e o elemento rport em branco.

Figura 21 - Exemplo do campo Via retirado de uma requisio SIP.
(JOHNSTON, 2009).
2.5.2.4.4 Call-I D
O campo Call-ID obrigatrio em todas as mensagens SIP, ele carrega a
identificao de uma sesso entre dois UAs. Esse campo formado por um nmero criado de
forma aleatria pelo UA e no modificado pelo servidor (JOHNSTON, 2009). No exemplo
da Figura 22 o campo Call-ID possui a identificao 3d4a33459546e23f.

Figura 22 - Exemplo do campo Call-ID retirado de uma requisio SIP.
(JOHNSTON, 2009).
52

2.5.2.4.5 CSeq
O campo Cseq obrigatrio em todas as mensagens de requisio. Usualmente este
campo possui um nmero decimal que incrementa a cada nova requisio. Ele utilizado pelo
servidor para identificar se a mensagem faz parte de uma nova requisio ou de uma
requisio j efetuada. Na Figura 23 o campo Cseq preenchido com 1 INVITE.

Figura 23 - Exemplo do campo CSeq retirado de uma requisio SIP.
(JOHNSTON, 2009).
2.5.2.4.6 Contact
O campo Contact utilizado para identificar o recurso requisitado ou o originador da
requisio dependendo se o campo faz parte de uma mensagem de requisio ou de resposta.
Essa identificao utilizada nas mensagens de requisio INVITE ou de resposta 200 OK s
requisies INVITE para criar uma espcie de registro permitindo que requisies futuras
possam ser feitas diretamente ao UA sem o uso de proxy servers (JOHNSTON, 2009). Na
Figura 24 o campo Contact igual a <sip:200@192.168.33.100:9195>.

Figura 24 - Exemplo do campo Contact retirado de uma requisio SIP.
(JOHNSTON, 2009).
2.5.2.4.7 Max-Forwards
53

O campo Max-Forwards usado para indicar o nmero mximo de saltos que uma
mensagem SIP pode fazer. A cada novo salto esse campo decrementado. No caso do proxy
server receber uma mensagem SIP com este campo zerado, a mensagem descartada e
gerada uma resposta com a linha de estado igual a 483 Too Many Hops que indica que o
nmero de saltos ultrapassou o permitido (JOHNSTON, 2009). Na Figura 25 pode-se
observar que o campo Max-Forwards igual a 70, sendo assim esta mensagem pode ainda
passar por at 70 saltos.

Figura 25 - Exemplo do campo Max-Forwards retirado de uma requisio SIP.
Este campo utilizando apenas em requisies (JOHNSTON, 2009).
2.5.2.4.8 WWW-Authenticate
O campo WWW-Authenticate utilizado quando uma autenticao solicitada a um
UA. Junto com esse campo so informados tipo de algoritmo utilizado (geralmente MD5), o
realm utilizado na autenticao e o nonce tambm utilizado na autenticao (JOHNSTON,
2009). Na Figura 26 o campo WWW-Autehnticate informando o algoritmo MD5,
realm=asterisk e nonce=0cdf8f98.

Figura 26 - Exemplo do campo WWW-Authenticateretirado de uma requisio SIP.
Este campo utilizando apenas em respostas (JOHNSTON, 2009).
2.5.2.4.9 Authorization
54

O campo Authorization utilizado para carregar as credenciais do usurio SIP e mais
algumas informaes utilizadas pelo servidor SIP para completar a autenticao. Fazem parte
do campo Authorization os elementos username, realm, nonce, uri, response e algorithm
informando o usurio para a autenticao, o realm informado pelo servidor no campo WWW-
Authenticate, o nonce informado pelo servidor no campo WWW-Authenticate, o uri, a resposta
gerada pelo algoritmo de criptografia e o tipo de algoritmo utilizado na criptografia
(JOHNSTON, 2009). Na Figura 27 pode-se observar um exemplo do campo Authorization.

Figura 27 - Exemplo do campo Authorization retirado de uma requisio SIP.
Este campo utilizando apenas em requisies (JOHNSTON, 2009).
2.5.2.5 Autenticao do SIP
Existem vrias formas de efetuar a autenticao de um UA SIP, uma delas a
autenticao Digest baseada no protocolo HTTP. Utilizando a autenticao Digest, o servidor
faz a requisio para o cliente enviar a senha criptografada pelo algoritmo MD5
5

(JOHNSTON, 2009). O envio da senha criptografada previne contra ataques, pois se o pacote
que contm as informaes de autenticao for interceptado no meio do caminho, a senha no
poder ser visualizada (JOHNSTON, 2009).
A requisio de autenticao feita atravs da resposta 401 Unauthorized. No
mesmo pacote da resposta enviado um campo chamado WWW-Authenticate que possui
algumas informaes utilizadas na criptografia da senha. Recebendo a requisio e essas
informaes, o usurio deve enviar um pacote com o mesmo mtodo utilizado no incio da
conversao com o campo Authorization. Nesse campo so enviadas as informaes
utilizadas para criar a criptografia da chave alm da prpria chave (JOHNSTON, 2009).
O algoritmo MD5 utilizado para a criptografia da chave converte uma mensagem de
qualquer tamanho em uma assinatura de 128 bits. A partir de uma mensagem criptografada

5
MD5 ou Message-Digest Algorithm 5 pode ser definido como um algoritmo de criptografia (ABZUG, 1991).
55

com o algoritmo MD5 impossvel obter a mensagem original, portanto, a autenticao se d
comparando a criptografia gerada na origem com a criptografia gerada no destino, ambas
geradas a partir dos mesmos dados (ABZUG, 1991).
No SIP, a mensagem utilizada para criar a criptografia formada por alguns
elementos do cliente e outros elementos do servidor. No caso do cliente, so utilizadas as
informaes de username, password, uri e mtodo utilizado. No caso do servidor so
utilizadas as informaes de realm e nonce (KRIVUTSENKO'S, 2006). Como visto na seo
anterior, o servidor envia para o cliente as informaes utilizadas na autenticao no campo
WWW-Authenticate e o cliente responde com as informaes de autenticao no campo
Authorization.
O padro utilizado para a criao da criptografia de autenticao formado atravs
da gerao de trs diferentes chaves:
- A primeira chave criada a partir das informaes de username, realm e password
(KRIVUTSENKO'S, 2006);
- A segunda chave criada a partir das informaes de mtodo e uri
(KRIVUTSENKO'S, 2006);
- A terceira e ltima chave, que exatamente a mensagem criptografada a ser
enviada no pacote de autenticao, criada a partir da primeira chave, do nonce e da segunda
chave (KRIVUTSENKO'S, 2006).
A primeira chave criada a partir da mensagem mostrada na Figura 28.

Figura 28 - Gerao da primeira criptografia.
A segunda chave criada a partir da mensagem mostrada na Figura 29.

Figura 29 - Gerao da segunda criptografia.
A terceira e ltima chave criada a partir da mensagem mostrada na Figura 30.
56

Figura 30 - Gerao da terceira criptografia.
Na Figura 31 pode-se observar um exemplo prtico com dados reais.

Figura 31 - Exemplo de criptografia com dados reais.
2.5.2.6 Vulnerabilidades do SIP
Citando McGann (2005):
"A complexidade da VoIP cria um alto nmero de vulnerabilidades que afetam as
trs reas clssicas da segurana da informao: confidencialidade, integridade e
disponibilidade"
Conforme afirmao de McGann, a complexidade a qual a tecnologia VoIP
concebida, cria vulnerabilidades que afetam a segurana da informao. Pode-se destacar
tambm Johnston (2006):
"Identidade no SIP significa o SIP URI do usurio. Quando uma requisio
recebida, um UA pode observar o campo "From" do cabealho e usar ese como
identidade[...]"
Existem portanto, campos q ue fazem parte do SIP, como o caso do campo From
que identifica a origem de uma chamada VoIP por exemplo. Nesse caso fica clara a
vulnerabilidade uma vez que um dispositivo pode iniciar a negociao de uma sesso se
fazendo passar por outro dispositivo.
57

"SIP no um protocolo fcil de assegurar. Seu uso de intermedirios, suas relaes
multifacetadas confiveis, suas expectativas de uso entre elementos sem uma total
confiabilidade, e sua operao de usurio-para-usurio faz com que a segurana
esteja longe da trivial." (ROSENBERG, 2002)
Pelo fato do SIP operar em diversos pontos intermedirios e entre dispositivos que
podem no ser confiveis, a segurana no SIP fica a cargo de terceiros uma vez que nele ela
no ideal.
2.6 BIBLIOTECA LIBPCAP
A biblioteca de desenvolvimento libpcap ou Packet Capture Library, pode ser
definida como:
"A biblioteca de captura de pacotes fornece uma interface de alto nvel para sistemas
de captura de pacotes. Todos os pacotes na rede, mesmo que destinados a outros
hosts, so acessveis atravs deste mecanismo." (JACOBSON, LERES e
MCCANNE, 2003)
Conforme citado, a biblioteca libpcap fornece suporte a captura de pacotes da rede
de dados mesmo que eles no sejam destinados ao host onde ela se encontra
6
. Desenvolvida
para a utilizao na linguagem de programao C (JACOBSON, LERES e MCCANNE,
2003), ela possui um nmero considervel de funes definidas que facilitam a captura dos
pacotes. Alm da captura, a bilbioteca permite tambm que sejam injetados pacotes na rede
atravs de funes especficas. As funes pertinentes a este projeto esto listadas abaixo:
a) pcap_open_live() - esta funo utilizada para criar a sesso de captura dos
pacotes da rede (JACOBSON, LERES e MCCANNE, 2003). Nela so utilizados
argumentos como interface de captura onde ser efetuada a captura, tamanho
mximo de bytes a serem capturados, time-out para o encerramento da captura,
modo de captura (promscuo ou no) e registro de erro ou aviso.
b) pcap_loop() - esta funo utilizada para criar um loop de captura de modo que a
cada novo pacote recebido seja executada uma outra funo (JACOBSON,
LERES e MCCANNE, 2003). Ela importante pelo fato de que a cada novo
pacote recebido, pode-se process-lo de acordo com a necessidade do
programador.
c) pcap_compile() - esta funo utilizada para compilar o filtro a partir de uma
varivel antes de aplic-lo na sesso de captura (JACOBSON, LERES e

6
Para que isso seja possvel, necessrio que todos os pacotes (mesmo os no destinados ao host) estejam
chegando at a interface de captura do host.
58

MCCANNE, 2003) de forma que no necessrio se capturar todos os pacotes
da rede, apenas os que se deseja processar.
d) pcap_setfilter() - esta funo utilizada para aplicar o filtro compilado na sesso
de captura (JACOBSON, LERES e MCCANNE, 2003).
e) pcap_inject() - esta funo tem a finalidade de injetar um pacote na rede
(JACOBSON, LERES e MCCANNE, 2003). Nela pode se determinar a sesso a
qual o pacote ser injetado, o resultado determina se ele foi ou no corretamente
injetado.
f) pcap_dispatch() - esta funo utilizada para efetuar o processamento dos
pacotes aps a captura na sesso. necessrio passar argumentos a esta funo
como nmero de pacotes que sero processados e nome da funo que ir fazer o
processamento do pacote (JACOBSON, LERES e MCCANNE, 2003).
g) pcap_lookupnet() - esta funo utilizada para obter os dados de endereo e
mscara da interface utilizada para fazer a captura necessrios para a aplicao
do filtro de captura na sesso (JACOBSON, LERES e MCCANNE, 2003).
h) pcap_setnonblock() - esta funo utilizada para bloquear ou no a sesso de
captura, se bloqueada, a execuo da funo de captura fica aguardando a captura
de algum pacote ao invs de executar a prxima linha de cdigo (JACOBSON,
LERES e MCCANNE, 2003).
2.6.1 Captura de Pacotes Utilizando a LI BPCAP
A captura pode ser definida como:
Captura de pacotes nos permite interceptar qualquer pacote que visto pelo
dispositivo de rede, e peg-lo com os cabealhos e tudo! Independentemente em
qual porta est sendo enviado, ou mesmo qual host! (CASADO, 2001)
Segundo Casado (2001), a captura de pacotes permite que qualquer pacote seja
capturado independente de quem o est enviando ou para quem est enviando. Isso torna
possvel a idia de que um host pode capturar um pacote destinado a outro host e ver todas as
informaes contidas neste pacote.
A sesso de captura pode ser considerada uma tarefa simples:
A tarefa de criar uma sesso de sniffing realmente muito simples. Para isso,
usamos pcap_open_live(). (CARSTENS, 2002)
59

Conforme Carstens (2002), a tarefa de criar uma sesso de sniffing
7
simples, como
pode ser observada na Figura 32 que mostra algumas linhas de cdigo criando uma sesso de
captura.

Figura 32 - Cdigo para criao de uma sesso de captura.
Fonte: (CARSTENS, 2002)
O cdigo observado na Figura 32, abre o dispositivo armazenado na varivel
somedev e lhe diz para ler tantos bytes quantos so especificados em BUFSIZ (que definido
no pcap.h). informado tambm para a interface ser colocada em modo promscuo, ou seja,
capturar pacotes at que um erro ocorra, e se algum erro ocorrer uma mensagem impressa na
tela (CARSTENS, 2002).
2.6.2 Filtros de Captura Utilizados com a LIBPCAP
Os filtros de captura so utilizados no caso em que se tem interesse em apenas parte
do trfego da rede (CARSTENS, 2002). Um filtro de captura precisa ser compilado antes de
ser aplicado na sesso de captura (CARSTENS, 2002) e a funo de compilao pode ser
observada na Figura 33.

Figura 33 - Compilao de um filtro de captura.
Aps a compilao, o filtro pode ser ento aplicado na sesso de captura. Para isso
preciso utilizar a funo descrita na Figura 34 (CARSTENS, 2002).

7
Sesso de sniffing neste contexto pode ser definida como uma sesso de captura.
60

Figura 34 Aplicao de um filtro de captura em uma interface.
A expresso de um filtro define-se como:
A expresso de filtro consiste de uma ou mais primitivas. Primitivas geralmente
consistem de um ID (nome ou nmero) precedidas de um ou mais qualificadores.
(JACOBSON, LERES e MCCANNE, 2008)
Conforme definio, um filtro definido por um ou mais primitivas e uma primitiva
consiste em um nome ou nmero precedido de um qualificador. Nos filtros utilizados na
libpcap existem trs diferentes qualificadores que podem ser utilizados:
a) Tipo - define no que o filtro aplicado. Os tipos possveis so host, net, port e
portrangeque significam o host ou dispositivo, a rede a porta ou faixa de portas
respectivamente (JACOBSON, LERES e MCCANNE, 2008).
b) Dir - define o tipo especfico de direcionamento do trfego a ser filtrado. Os
possveis valores so src, dst, src or dst e src and dst, significam origem, destino,
origem ou destino, e origem e destino respectivamente (JACOBSON, LERES e
MCCANNE, 2008).
c) Proto - define o tipo especfico de protocolo a ser filtrado. Os possveis valores
so ether, ip, tcp e udp, significam Ethernet, IP, TCP e UDP respectivamente
(JACOBSON, LERES e MCCANNE, 2008).
Na Figura 35 pode ser observado um exemplo de expresso de filtro que pode ser
aplicada, no caso desta expresso, est sendo filtrado todo trfego destinado e originado do
host 192.168.0.1 que utiliza o protocolo UDP cuja porta de destino igual a 5060

Figura 35 - Exemplo de expresso de filtro.
2.6.3 Exemplo de Cdigo
Conforme Carstens (2002), o cdigo mostrado na Figura 36 pode servir como
exemplo do uso da biblioteca libpcap.
61

Figura 36 - Exemplo de cdigo utilizando libpcap.
Observando o cdigo mostrado, so declaradas algumas variveis como handle que
representa a sesso de captura, dev que armazena o nome da interface utilizada para a captura,
errbuf que armazena possveis erros na execuo das funes da biblioteca, fp que a
estrutura onde o filtro deve ser compilado, filter_exp que guarda a expresso do filtro de
captura, mask que armazena a mscara da interface de rede e net que armazena o endereo IP
da interface de rede (CARSTENS, 2002).
Depois de declaradas as variveis, a funo pcap_lookupdev utilizada para descobrir
as informaes de endereamento e mscara da interface executada. O segundo passo a
execuo da funo pcap_open_live que configura e abre a sesso de captura. O terceiro passo
a compilao do filtro com uso da funo pcap_compile e o quarto e ltimo passo a
aplicao do filtro na sesso de captura com uso da funo pcap_setfilter (CARSTENS,
2002).
62

3 IMPLEMENTAO DO PROTTIPO
No captulo dois foi realizada uma pesquisa bibliogrfica sobre os conceitos
fundamentais para a elaborao do analisador SIP que a proposta deste trabalho. Neste
captulo sero abordados os assuntos acerca da criao desta ferramenta que visa a anlise da
interoperabilidade do SIP entre os dispositivos, dando ao operador a possibilidade de fazer
alteraes nos pacotes coletados, e injetar esses pacotes na rede para realizar uma nova
anlise.
3.1 METODOLOGIA
No presente trabalho a metodologia utilizada a que segue:
d) Elaborao de um fluxograma do software proposto detalhando interface com o
operador e as funes de captura, alterao e injeo dos pacotes a fim de guiar o
desenvolvimento.
e) Desenvovimento do analisador SIP proposto seguindo o padro estabelecido no
fluxograma criado.
f) Validao do analisador SIP atravs da criao de um cenrio real de
implementao de VoIP com o auxlio de ferramentas de apoio.
3.2 FERRAMENTAS UTILIZADAS
Para a elaborao e validao do analisador SIP proposto, foram utilizadas
basicamente quatro ferramentas:
a) Eclipse IDE for C/C++ Developers
b) Wireshark Network Protocol Analyzer
63

c) eyeBeam
d) Asterisk
3.2.1 EclipseI DE for C/C++ Developers
O Eclipse IDE for C/C++ Developers uma plataforma que possui uma coleo de
recursos e fornece suporte para criao, edio, navegao, compilao e depurao de
projetos que usam C ou C++ como linguagem de programao. A plataforma no inclui os
compiladores utilizados para converter o cdigo de programao em programas executveis
ou depurar esses cdigos, mas fornece suporte para que essas ferramentas sejam integradas a
plataforma (ECLIPSE, 2011).
Algumas das facilidades que a plataforma fornece a criao do makefile
8
para
auxlio na compilao, ambiente grfico para a depurao do cdigo e o conceito de
perspectivas para cada tipo de tarefa que est sendo executada, seja programao ou
depurao. Atravs do uso de perspectivas, simplifica-se a visualizao do cdigo em questo
ou das linhas em execuo juntamente com valores de variveis no caso da depurao
(ECLIPSE, 2011). A plataforma obtida de forma gratuita na pgina da Fundao Eclipse na
Internet, foi utilizada no sistema operacional Linux, distribuio CentOS verso 5.5 e
interface grfica Gnome. Na Figura 37 pode-se ter uma viso geral da plataforma Eclipse.
3.2.2 Wireshark Network Protocol Analyzer
O Wireshark um analisador de pacotes da rede. A funo deste tentar capturar os
pacotes da rede e tentar mostr-los da forma mais detalhada possvel (LAMPING, SHARPE e
WARNICKE, 2011). Existem diversos protocolos que o analisador pode reconhecer e
detalhar ao operador. No presente trabalho foi necessrio verificar os pacotes capturados pelo
analisador SIP de forma a comprovar se realmente todo o trfego gerado pelo dispositivo SIP

8
Makefile pode ser definido como um arquivo que auxilia no processo de compilao de projetos (WALL,
WATSON e WHITIS, 1999).
64

estava sendo capturado, alm de comprovar a correta criao dos pacotes injetados pelo
analisador aps a alterao dos dados dos pacotes. O Wireshark obtido de forma gratuita
atravs da sua pgina na Internet e foi utilizado no sistema operacional Windows. Na Figura
38 pode-se ter uma viso geral do Wireshark.

Figura 37 - Viso geral do Eclipse.

Figura 38 - Viso geral do Wireshark.
65

3.2.3 eyeBeam
O eyeBeam um software que utilizado como um telefone SIP, capaz de
estabelecer sesses multimdia com outros usurios SIP (COUNTERPATH, 2011). Na Figura
39 pode-se ter uma viso geral do software. Atravs da tela mostrada, o usurio pode discar
um nmero ou o nome de um usurio. Para estabelecer uma sesso multimdia, um servidor
precisa estar cadastrado. Na Figura 40 so mostrados os campos a serem configurados para
que o software tenha acesso a um servidor. Podem ser verificados os campos: display name
que identifica o nome do usurio, o campo user name que identifica o usurio que est
estabelecendo a sesso multimdia, o campo password que armazena a senha do usurio
utilizada para a autenticao do usurio no servidor SIP, o campo authorization user name
que identifica o username utilizado na autenticao do usurio SIP e o campo domain que
identifica o endereo do servidor para o qual as requisies so enviadas.

Figura 39 - Viso geral do eyeBeam.
66

Figura 40 - Detalhes da configurao do eyeBeam.
No presente trabalho, o software utilizado como um dispositivo SIP monitorado
durante o envio das requisies para o servidor. Ele utilizado durante o desenvolvimento e
da validao do analisador SIP uma vez que a interoperabilidade entre este software e o
servidor, serve como exemplo de negociao do protocolo SIP.
3.2.4 Asterisk
O Asterisk uma plataforma open source
9
de telefonia convergente que foi projetado
primeiramente para rodar em plataforma Linux. Asterisk um servidor de comunicao com
um conjunto de aplicaes de telefonia integrado (MADSEN, MEGGELEN e BRYANT,
2011).
Analisando superficialmente, o Asterisk pode ser definido como um servidor de
comunicao que registra, interliga e controla usurios que precisam se comunicar. Dentre os
protocolos por ele suportados, o SIP um deles, pode ento ser considerado um servidor SIP
(MADSEN, MEGGELEN e BRYANT, 2011).
No desenvolvimento deste trabalho, o Asterisk foi utilizado como uma ferramenta de
apoio para os testes durante o desenvolvimento e a validao do analisador SIP. Nele foram
configurados dois usurios SIP para efetuar os testes. Na Figura 41 pode-se observar o
arquivo que armazena as configuraes dos usurios SIP denominado sip.conf (MADSEN,
MEGGELEN e BRYANT, 2011).

9
Open source o conceito de software livre, que possui cdigo aberto.
67

Figura 41 - Configurao do Asterisk.
Os usurios identificados como 200 e 300 foram criados e definidos como tipo
friend, fazendo parte do contexto phones e com endereos de host dinmico. O tipo friend
determina que o reconhecimento do usurio pode ser feito tanto pelo endereo IP de origem
das requisies enviadas quanto pela autenticao de um usurio atravs de mtodos
tradicionais utilizando um nome de usurio e uma senha. O campo secret define a senha de
cada usurio e o campo allow define os protocolos de compresso de audio permitidos para
cada usurio (MADSEN, MEGGELEN e BRYANT, 2011). O contexto situa o processamento
do usurio dentro do plano de numerao criado no arquivo extensions.conf (MADSEN,
MEGGELEN e BRYANT, 2011) que pode ser visualizado na Figura 42.

Figura 42 - Configurao do plano de numerao no Asterisk.
No plano de numerao configurado foi definido que se algum usurio tentar enviar
requisies para o nmero 200, elas sero encaminhadas para o usurio SIP identificado como
200 e se algum usurio tentar enviar requisies para o nmero 300, elas sero encaminhadas
para o usurio SIP identificado como 300.
68

3.3 ELABORAO DO FLUXOGRAMA
Para a elaborao do fluxograma do analisador SIP proposto, foi necessrio fazer a
definio das anlises que a ferramenta poderia proporcionar ao operador para depois listar as
principais funes da ferramenta alm da organizao da interface com o operador.
3.3.1 Anlises Possveis Atravs da Ferramenta
Foi definido que a ferramenta deveria proporcionar ao operador anlises quanto a
identificao do usurio que est efetuando o estabelecimento da sesso multimdia
(denominado ativo no presente trabalho) e a identificao do usurio o qual est sendo
convidado para participar da sesso multimdia (denominado passivo no presente trabalho).
Com base no protocolo SIP e nas anlises que a ferramenta deve proporcionar, possvel
definir quais campos do protocolo devem ser observados e alterados, alm de ser possvel
tambm definir uma estrutura bsica para guiar o desenvolvimento da ferramenta.
3.3.2 Principais Funes do Analisador
Um analisador de protocolos de rede precisa de uma interface de rede e uma rede
como fonte de dados para efetuar a captura dos pacotes e a anlise de um protocolo
(LAMPING, SHARPE e WARNICKE, 2011). No caso do analisador SIP proposto, a fonte de
dados a rede onde os pacotes esto trafegando entre os dispositivos. Para ter acesso a esses
pacotes necessrio o uso de uma interface de rede fsica conectada a rede onde existe o
trfego. A primeira funo ento estabelecida como a captura dos pacotes da rede.
A segunda funo surgiu da necessidade de disponibilizar ao operador uma anlise
dos pacotes capturados que representam a interoperabilidade do protocolo em questo, dando
a possibilidade de alterao de alguns dados. Portanto, a segunda funo ficou definida como
anlise e alterao dos dados dos pacotes coletados.
69

A terceria funo partiu da necessidade da injeo dos pacotes alterados para fazer
uma nova anlise. Portanto, esta funo trata da criao, injeo e sincronismo entre os
pacotes injetados e os pacotes recebidos como resposta.
3.3.3 Organizao da Interface com o Operador
Para permitir ao operador o acesso s funes do analisador, foi definida a utilizao
de menus baseados em texto puro. Foi definido um padro de cabealho que mostra o nome
do software e informaes sobre a seo a qual o operador est acessando no momento. Sete
diferentes opes esto disponveis na tela principal do software. Na Figura 43 tem-se uma
viso geral do menu principal com o padro de cabealho na parte superior e todas as opes
disponveis ao operador.

Figura 43 - Viso geral do menu principal.
70

3.3.3.1 Seo Escuta
Dentro da seo Escuta, o operador faz a configurao da sesso de captura
definindo a interface atravs da qual a captura ser efetuada, endereo IP do dispositivo
monitorado e a porta de origem ou destino das mensagens SIP. Nesta seo o operador
tambm inicia e finaliza a sesso de captura visualizando em tempo real os pacotes sendo
capturados com as informaes de sequncia de pacote, endereo IP de origem, porta de
origem, endereo IP de destino, porta de destino, direcionamento do trfego e o mtodo SIP
utilizado em cada pacote. Na Figura 44 pode-se visualizar a tela principal dentro da seo
Escuta

Figura 44 - Viso geral da seo "Escuta".
Na Figura 45 pode-se observar a sesso de captura com alguns pacotes capturados e
suas informaes.
3.3.3.2 Seo Dados Escutados
Dentro da Seo Dados Escutados, o operador tem acesso aos pacotes capturados
atravs da sesso de captura efetuada dentro da seo Escuta. possvel visualizar uma
sequncia de pacotes, seus endereos IP de origem e destino, portas de origem e destino e o
mtodo SIP utilizado. O acesso a esta seo s disponibilizado se j existirem pacotes
71

capturados. Dentro desta seo, o operador tem acesso aos campos SIP disponveis para
alterao, visualizando os valores originais obtidos atravs da anlise dos pacotes capturados.
As alteraes efetuadas pelo operador so armazenadas em arquivos para que possam ser
aplicadas no momento da injeo desses pacotes. No havendo nenhuma alterao, os pacotes
so injetados com os valores originais. Na Figura 46 pode-se observar a tela principal da
seo Dados Escutados, visualizando os pacotes capturados na seo de Escuta e os
campos SIP disponveis para a alterao.

Figura 45 - Viso geral da sesso de captura.

Figura 46 - Viso geral da seo "Dados Escutados".
72

3.3.3.3 Seo Injeo
O acesso a seo Injeo somente disponibilizado se existirem pacotes
previamente capturados e armazenados e se nenhuma sesso de injeo fora anteriormente
realizada. Dentro da seo Injeo possvel, ao comando do operador, iniciar o processo
de injeo dos pacotes com as alteraes propostas na seo anterior. O cancelamento da
injeo pode ser feito a qualquer momento tambm sob o comando do operador. Ao passo que
os pacotes so injetados, pode-se visualizar a sequncia dos pacotes com as informaes de
endereamento IP de origem e destino, portas de origem e destino e o mtodo SIP utilizado.
Ao trmino da injeo o operador pode retornar ao menu anterior pressionando qualquer tecla.
Na Figura 47 pode ser observada a seo Injeo com alguns pacotes injetados e suas
respectivas informaes.

Figura 47 - Viso geral da seo "Injeo".
3.3.3.4 Seo Mostrar Resultados
A seo Mostrar Resultados fornece a visualizao dos pacotes capturados e
injetados nas sees Escuta e Injeo. Pode-se atravs desta opo fazer uma comparao
73

entre as duas sees e observar as diferenas na interoperabilidade do protocolo diante das
alteraes efetuadas ou no pelo operador. O acesso a esta seo s disponibilizado se uma
injeo fora previamente executada. Nesta seo mostrada a sequncia dos pacotes com
endereamento IP de origem e destino, portas de origem e destino e o mtodo SIP utilizado.
Na Figura 48 tem-se uma viso geral da seo Mostrar Resultados com todos os pacotes.

Figura 48 - Viso geral da opo de "Mostrar Resultados".
3.3.3.5 Seo Limpar Resultados
A seo Limpar Resultados faz a limpeza dos pacotes capturados e injetados na
seo Iinjeo. Essa opo utilizada sempre que se necessita realizar uma nova injeo.
Na Figura 49 observa-se a mensagem disponibilizada quando a seo Limpar Resultados
acessada.
74

Figura 49 - Viso geral da seo "Limpar Resultados".
3.3.3.6 Seo Limpar Tudo
A seo Limpar Tudo faz uma limpeza geral, excluindo todos os dados
armazenados. Essa opo exclui tambm os arquivos de controle gerados pelo software. Esses
arquivos sero mencionados no decorrer deste trabalho. Na Figura 50 observa-se a mensagem
disponibilizada quando a seo Limpar Tudo acessada.

Figura 50 - Viso geral da seo "Limpar Tudo".
75

3.3.4 Fluxograma
Depois de definidas as principais funes do software e a interface com o operador,
foi elaborado o fluxograma da ferramenta para servir como guia durante o processo de
programao. A Figura 51 mostra o fluxograma do projeto.

Figura 51 Fluxograma geral do projeto.

76

Com base nas funes, na interface com o operador e no fluxograma, o software
pode ser dividido em:
a) Controle principal;
b) Controle de escuta;
c) Controle de visualizao e alterao de dados escutados;
d) Controle de injeo;
e) Controle de amostragem de resultados;
f) Controle de limpeza de resultados;
g) Controle de limpeza total.
Fazendo uma primeira anlise no fluxograma antes mesmo do incio do
desenvolvimento, determinaram-se algumas responsabilidades a cada seo de controle.
A seo de controle principal deve controlar o acesso a todas as outras sees, vai
representar a entidade principal do software sendo inicializada por primeiro e deve tambm
fazer as adequaes necessrias das variveis globais utilizadas no software.
A seo de controle de escuta deve ser responsvel pela configurao do filtro de
captura baseado nos dados de endereo IP de origem e porta de destino informados pelo
operador. Ela tambm reponsvel por controlar o acesso a interface de rede para efetuar a
captura dos pacotes e salv-los de forma a serem reutilizados posteriormente.
A seo de controle de visualizao e alterao de dados escutados deve controlar a
exposio dos pacotes capturados na seo de escuta, alm de controlar as alterao dos
campos SIP.
A seo de controle de injeo deve alterar os dados dos pacotes conforme as
alteraes efetuadas nos campos SIP alm da criao dos pacotes para a injeo.
Devecontrolar o acesso a interface de rede para fazer a injeo e a captura de pacotes,
controlar o sincronismo de envio e recebimento de pacotes para o dispositivo em
comunicao com o dispositivo monitorado e armazenar esses pacotes enviados e recebidos
para a posterior anlise.
A seo de controle de visualizao de resultados deve controlar a exposio dos
dados capturados na seo de escuta e dos dados capturados e injetados na seo de injeo.
77

A seo de controle de limpeza de resultados responsvel pela limpeza de todos os
dados obtidos aps o processo de injeo de forma a deixar o software preparado para realizar
uma nova injeo.
A seo de controle de limpeza total responsvel pela limpeza geral de todos os
dados armazenados.
3.3.4.1 Determinao do Filtro de Captura
A determinao do filtro de captura se deu com base na pesquisa efetuada sobre o
protocolo SIP e o protocolo IP. Verificando que o pacote IP possui um endereo IP de origem
e um endereo IP de destino, e o mecanismo IP no permite a existncia de dois dispositivos
com o mesmo endereo em operao, simultaneamente em uma rede, define-se como parte
necessria do filtro a ser aplicado na captura o endereo IP de origem dos pacotes originados
no dispositivo monitorado e o endereo IP de destino dos pacotes originados no dispositivo
em comunicao com o dispositivo monitorado. Outra parte do filtro diz respeito a porta
utilizada no cabealho UDP: tendo por base que o protocolo UDP sempre utiliza uma porta de
origem e uma de destino na comunicao, define-se como parte necessria do filtro a ser
aplicado na captura, a porta de destino dos pacotes originados no dispositivo monitorado e a
porta de origem dos pacotes originados no dispositivo em comunicao com o dispositivo
monitorado (TANENBAUM, 2003).
3.3.4.2 Determinao dos Campos para Alterao
Com base nas anlises propostas no item 3.3.1 e no protocolo SIP, definem-se como
os campos passveis de alterao para o usurio ativo o campo que identifica o originador da
requisio, denominado de caller neste trabalho e os campos que fazem a autenticao do
usurio denominados de username e password neste trabalho.
78

Para o usurio passivo foi definido como passvel de alterao o campo que
identifica o convidado da sesso multimdia, denominado de called neste trabalho.
3.4 DESENVOLVIMENTO DO ANALISADOR PROPOSTO
3.4.1 Definies Iniciais
Para facilitar o desenvolvimento, foram definidas algumas funes como globais por
serem utilizadas em diversas reas do cdigo. Essas funes esto armazenadas em arquivos
separados de forma a facilitar o acesso a elas.
Os pacotes capturados na seo Escuta e os capturados e injetados na seo
Injeo ficam armazenados em arquivos texto, seguindo um padro de estrutura e
formatao. Dados das sesses de captura e injeo e informaes sobre o filtro de captura
ficam armazenadas em um arquivo texto especfico denominado info_sessao.txt tambm com
estrutura e formatao especficas. Informaes sobre os campos SIP ficam armazenadas em
outro arquivo texto denominado capture_data.txt tambm com estrutura e formatao
especficas.
3.4.2 Padres de Arquivos Utilizados
Conforme mencionado, os pacotes capturados, os dados de sesses de captura e os
dados referentes aos campos do protocolo SIP, ficam armazenados em arquivos diferentes.
Para cada arquivo foi definido um padro de armazenamento dos dados.
79

3.4.2.1 Arquivos de Captura
Os arquivos de captura podem ser dividos em arquivos de captura gerados pela seo
Escuta e arquivos de captura e injeo gerados pela seo Injeo. Eles possuem a
nomenclatura diferenciada, porm, o padro de armazenamento dos dados dos pacotes
exatamente o mesmo. Os padres de nomenclatura dos arquivos de captura so:
a) Arquivos capturados atravs da seo Escuta - estes arquivos so
denominados capture_xx.cap, sendo xx um nmero de dois algarismo
representando a sequncia de captura.
b) Arquivos capturados atravs da seo Injeo - estes arquivos so
denominados capture_res_xx.cap, sendo xx um nmero de dois algarismo
representando a sequncia de captura.
Os arquivos so formados por duas partes distintas: uma separa e identifica todos os
campos dos cabealhos Ethernet, IP e UDP, e a outra constitui o bloco de dados do protocolo
SIP. Na Tabela 11 observa-se um exemplo de arquivo de captura, os nmeros visualizados
esquerda so identificaes das linhas do arquivo, no fazendo parte do contedo.
Tabela 11 - Exemplo de arquivo de captura.
1 ARQ_NUM=01
2
3 ETHER_MAC_SRC=0:C:29:68:26:3A;
4 ETHER_MAC_DST=0:C:29:41:58:95;
5 ETHER_TYPE=8
6
7 IP_VER=69
8 IP_TOS=0
9 IP_LEN=746
10 IP_ID=1374
11 IP_OFF=0
12 IP_TTL=128
13 IP_PROTO=17
14 IP_CHK=28497
15 IP_SRC=192.168.33.2
16 IP_DST=192.168.33.1
17
18 UDP_SRC=8304
19 UDP_DST=5060
20 UDP_LEN=726
21 UDP_CHK=12546
22
23 INVITE sip:300@192.168.33.1 SIP/2.0
24 To: <sip:300@192.168.33.1>
25 From: TCC 200<sip:200@192.168.33.1>;tag=66064d22
26 Via: SIP/2.0/UDP 192.168.33.2:8304;branch=z9hG4bK-d87543-127761736-1--d87543-;rport
27 Call-ID: 4c15ae004b318627
28 CSeq: 1 INVITE
29 Contact: <sip:200@192.168.33.2:8304>
30 Max-Forwards: 70
31 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO
32 Content-Type: application/sdp
33 User-Agent: eyeBeam release 3004w stamp 16863
34 Content-Length: 235
35
36 v=0
37 o=- 56250259 56250343 IN IP4 192.168.33.2
80

38 s=eyeBeam
39 c=IN IP4 192.168.33.2
40 t=0 0
41 m=audio 8306 RTP/AVP 0 8 18 101
42 a=alt:1 1 : DCFAF33A 4E58F998 192.168.33.2 8306
43 a=fmtp:101 0-15
44 a=rtpmap:101 telephone-event/8000
45 a=sendrecv
Cada arquivo armazenado representa um pacote capturado efetuado pela seo
Escuta, ou um pacote capturado ou injetado efetuado pela seo Injeo. Cada arquivo
possui um padro de armazenamento que identifica todas as partes do pacote incluindo a
sequncia do pacote, dados dos cabealhos e dados do protocolo SIP.
Observando a Tabela 11, segue a descrio do padro de arquivo utilizado para o
armazenamento dos dados capturados e/ou injetados:
ARQ_NUM= - identificao utilizada para armazenar a sequncia do pacote.
ETHER_MAC_SRC= - identificao utilizada para armazenar o endereo MAC
de origem do pacote; a linha finalizada com o caractere ; para facilitar o resgate da
informao no momento da injeo.
ETHER_MAC_DST= - identificao utilizada para armazenar o endereo MAC
de destino do pacote; a linha finalizada com o caractere ; para facilitar o resgate da
informao no momento da injeo.
ETHER_TYPE= - identificao utilizada para armazenar o tipo de protocolo da
camada de inter-redes do pacote, no caso deste trabalho, apenas o protocolo IP ser coletado
restringindo a identificao do protocolo ser sempre representada pelo nmero 8.
IP_VER= - identificao utilizada para armazenar as informaes de verso do
protocolo IP e o nmero de blocos de 32 bits que compe o cabealho IP.
IP_TOS= - identificao utilizada para armazenar a informao do campo ToS do
cabealho IP.
IP_LEN= - identificao utilizada para armazenar a informao do tamanho do
pacote coletado incluindo o cabealho IP e demais camadas superiores.
IP_ID= - identificao utilizada para armazenar o campo de identificao do
cabealho IP.
IP_OFF= - identificao utilizada para armazenar o campo de offset do cabealho
IP.
81

IP_TTL= - identificao utilizada para armazenar o campo de tempo de vida do
cabealho IP.
IP_PROTO= - identificao utilizada para armazenar o campo de identificao de
protocolo da camada superior da camada IP; no caso deste trabalho, apenas o protocolo UDP
ser coletado, restringindo a identificao do protocolo ser sempre representada pelo nmero
17.
IP_CHK= - identificao utilizada para armazenar o nmero de checksum do
cabealho IP do pacote coletado.
IP_SRC= - identificao utilizada para armazenar o endereo IP de origem do
pacote.
IP_DST= - identificao utilizada para armazenar o endereo IP de destino do
pacote.
UDP_SRC= - identificao utilizada para armazenar a porta de origem do
protocolo UDP.
UDP_DST= - identificao utilizada para armazenar a porta de destino do
protocolo UDP.
UDP_LEN= - identificao utilizada para armazenar a identificao do tamanho
do pacote coletado incluindo o cabealho UDP e os dados por ele transportado.
UDP_CHK= - identificao utilizada para armazenar o nmero de checksum do
cabealho UDP do pacote coletado.
A partir da linha 23, as informaes armazenadas fazem parte do protocolo SIP que
transportado pelo protocolo UDP.
3.4.2.2 Arquivo de Informaes da Sesso
O arquivo de informaes da sesso utilizado para armazenar as informaes da
sesso de captura efetuada na seo de escuta e na seo de injeo. Na Tabela 12 pode-se
observar um exemplo do arquivo de informaes da sesso, os nmeros esquerda so apenas
identificadores das linhas do arquivo e no fazem parte do contedo.
82

Tabela 12 - Exemplo de arquivo de informao da sesso.
1 DEV=eth1
2 IP_ORIG=192.168.33.2
3 PORTA_DST=5060
4 ARQ_CAP_TOTAL=8
5 ARQ_RES_TOTAL=6
Observando a Tabela 12, segue descrio do padro de armazenamento utilizado
para as informaes da sesso:
DEV= - identificao utilizada para armazenar o nome do dispositivo utilizado na
captura e injeo dos pacotes.
IP_ORIG= - identificao utilizada para armazenar o endereo IP do dispositivo
monitorado pelo analisador SIP.
PORTA_DST= - identificao utilizada para armazenar a informao da porta de
destino ou origem do protocolo UDP.
ARQ_CAP_TOTAL= - identificao utilizada para armazenar o total de arquivos
capturados na sesso de captura efetuada dentro da seo Escuta.
ARQ_RES_TOTAL= - identificao utilizada para armazenar a informao do
total de arquivos injetados e capturados dentro da seo Injeo.
3.4.2.3 Arquivo de Informaes dos Campos SIP
O arquivo de informaes dos campos SIP armazena o valor original e o novo valor
dos campos do protocolo SIP. Na Tabela 13 pode-se observar um exemplo do arquivo de
informaes dos campos SIP, os nmeros esquerda so apenas identificadores das linhas do
arquivo, no fazendo parte do seu contedo.
Tabela 13 - Exemplo de arquivo de informaes dos campos SIP.
1 CALLER_ORIG=200
2 CALLED_ORIG=300
3 USERNAME_ORIG=200
4 CALLER=200
5 CALLED=500
6 USERNAME=200
7 PASSWORD=5678
Conforme observao efetuada na Tabela 13 segue descrio do padro utilizado no
armazenamento das informaes referentes aos campos do protocolo SIP:
83

CALLER_ORIG= - identificao utilizada para armazenar a informao original
do campo caller do protocolo SIP.
CALLED_ORIG= - identificao utilizada para armazenar a informao original
do campo called do protocolo SIP.
USERNAME_ORIG= - identificao utilizada para armazenar a informao
original do campo username do protocolo SIP.
CALLER = - identificao utilizada para armazenar o novo valor do campo caller
do protocolo SIP a ser atribuda no momento da injeo.
CALLED = - identificao utilizada para armazenar o novo valor do campo
called do protocolo SIP a ser atribuda no momento da injeo.
USERNAME = - identificao utilizada para armazenar o novo valor do campo
username do protocolo SIP a ser atribuda no momento da injeo.
PASSWORD= - identificao utilizada para armazenar a informao da senha do
usurio SIP que est sendo monitorado. Esse campo apenas utilizado no momento da
injeo pelo tipo de mecanismo de autenticao utilizado no SIP.
3.4.3 Estrutura do Cdigo
A estrutura de armazenamento do cdigo fonte do software a que segue:
main.c - arquivo de cdigo responsvel pela inicializao de todas as variveis
globais do software e pelo controle de acesso s sees.
config.h - arquivo de cabealho onde todas as bibliotecas so adicionadas, todos os
arquivos de cdigo devem adicionar este arquivo para ter acesso s bibliotecas.
varredura.h - arquivo de cabealho onde esto declaradas as funes de varredura
como por exemplo a localizao de campos em arquivos de captura.
varredura.c - arquivo de cdigo que desenvolve todas as funes de varredura como
por exemplo a localizao de campos em arquivos de captura.
84

extract.h - arquivo que possui as funes de manipulao de organizao de bits no
formato necessrio para a criao dos pacotes.
pkt_header.h - arquivo de cabealho que possui a declarao das estruturas de dados
utilizados na captura e injeo dos pacotes.
print_pkt.h - arquivo de cabealho onde est declarada a funo de impresso dos
dados do pacote na tela.
print_pkt.c - arquivo de cdigo que desenvolve a funo de impresso dos dados do
pacote na tela.
escuta.h - arquivo de cabealho que declara as funes utilizadas no controle da
seo Escuta.
escuta.c - arquivo de cdigo que desenvolve as funes utilizadas no controle da
seo Escuta.
altera.h - arquivo de cabealho que declara as funes utilizadas no controle de
visualizao dos dados escutados e alterao dos campos do protocolo SIP.
altera.c - arquivo de cdigo que desenvolve as funes utilizadas no controle de
visualizao dos dados escutados e alteraes dos campos do protocolo SIP.
injection.h - arquivo de cabealho que declara as funes utilizadas no controle da
seo Injeo.
injection.c - arquivo de cdigo que desenolve as funes utilizadas no controle da
seo Injeo.
cap.h - arquivo de cabealho que declara a funo de processamento do pacote aps
a sua captura.
cap.c - arquivo de cdigo que desenvolve a funo de processamento do pacote aps
a sua captura.
menu.h - arquivo de cabealho que declara as funes de controle de menu.
menu.c - arquivo de cdigo que desenvolve as funes de controle de menu.
checksum.h - arquivo de cabealho que declara a funo de gerao do nmero de
checksum dos cabealhos IP e UDP.
85

checksum.c - arquivo de cdigo que desenvolve a funo de gerao do nmero de
checksum dos cabealhos IP e UDP.
md5.h - arquivo de cabealho que declara as funes envolvidas na autenticao
MD5 utilizada no protocolo SIP.
md5.c - arquivo de cdigo que desenvolve as funes envolvidas na autenticao
MD5 utilizada no protocolo SIP.
tty_set.h - arquivo de cabealho que declara a funo de manipulao do modo de
entrada de dados no terminal.
tty_set.c - arquivo de cdigo que desenvolve a funo de manipulao do modo de
entrada de dados no terminal.
3.4.4 Declarao das Bibliotecas e Variveis Globais
O arquivo de cabealho config.h descreve a declarao das bibliotecas e das variveis
globais utilizadas. Na Tabela 14 pode-se observar a descrio completa do arquivo, os
nmeros visualizados esquerda so apenas identificadores das linhas do arquivo e no fazem
parte do cdigo.
Tabela 14 - Arquivo de cabealho config.h.
1 #ifndef CONFIG_H_
2 #define CONFIG_H_
3
4 char *dev;
5 char *ip_orig;
6 char *porta_dst;
7 char *arq_info_nome;
8 char *arq_cap_nome;
9 char *arq_res_nome;
10 char *arq_pcap_nome;
11 char *arq_data_nome;
12 int *arq_cap_cnt;
13 int *arq_res_cnt;
14 int *arq_pcap_cnt;
15 char *arq_cap_local;
16 char *int_arq;
17 int *stop_thread;
18 char *sip_caller;
19 char *sip_callern;
20 char *sip_called;
21 char *sip_calledn;
22 char *sip_username;
23 char *sip_usernamen;
24 char *sip_password;
25 char *sip_passwordn;
26
27 #include <stdio.h>
28 #include <stdlib.h>
86

29 #include <stdio_ext.h>
30 #include <unistd.h>
31 #include <string.h>
32 #include <termios.h>
33 #include <pthread.h>
34
35 #include "pkt_header.h"
36 #include "extract.h"
37 #include "checksum.h"
38 #include "md5.h"
39 #include "varredura.h"
40 #include "tty_set.h"
41
42 #include <pcap.h>
43 #include <netinet/if_ether.h>
44 #include <netinet/ip.h>
45 #include <arpa/inet.h>
46
47 #include <netdb.h>
48 #include <netinet/in.h>
49 #include <sys/socket.h>
50
51 #endif /* CONFIG_H_ */
As varireis globais utilizadas so ponteiros do tipo char
10
e int
11
. Os ponteiros so:
dev - ponteiro utilizado para armazenar o nome da interface utilizada na captura e
injeo dos pacotes.
ip_orig - ponteiro utilizado para armazenar o endereo IP do dispositivo monitorado.
porta_dst - ponteiro utilizado para armazenar a porta de origem e destino UDP dos
pacotes a serem capturados.
arq_info_nome- ponteiro utilizado para armazenar o nome do arquivo que possui as
informaes da sesso.
arq_cap_nome - ponteiro utilizado para armazenar parte do nome dos arquivos de
captura.
arq_data_nome - ponteiro utilizado para armazenar o nome do arquivo das
informaes dos campos SIP.
arq_pcap_nome- ponteiro utilizado para apontar o nome de arquivo a ser utilizado
na funo de processamento de pacotes callback.
arq_cap_local - ponteiro utilizado para armazenar o caminho onde os arquivos de
captura e informaes so armazenados.

10
Char pode ser definido como um tipo de varivel que ocupa o espao de 1 byte na memria (CPLUSPLUS,
2011).
11
Int pode ser definido como um tipo de varivel que ocupa o espao de 4 bytes na memria e armazena um
nmero inteiro (CPLUSPLUS, 2011).
87

arq_cap_cnt - ponteiro utilizado para armazenar o nmero de pacotes capturados
pela sesso de captura efetuada na seo Escuta.
arq_res_cnt - ponteiro utilizado para armazenar o nmero de pacotes capturados pela
sesso de captura e injeo efetuadas na seo Injeo.
arq_pcap_cnt - ponteiro utilizado para apontar o nmero de pacotes capturados
utilizados na funo de processamento de pacotes callback.
int_arq - ponteiro utilizado para manipulao do nmero de pacotes capturados em
formato char.
stop_thread - ponteiro utilizado para controle de execuo de uma thread
12
.
sip_caller - ponteiro utilizado para armazenamento do valor original do campo caller
do protocolo SIP.
sip_callern - ponteiro utilizado para armazenamento do novo valor do campo caller
do protocolo SIP.
sip_called - ponteiro utilizado para armazenamento do valor original do campo
called do protocolo SIP.
sip_calledn - ponteiro utilizado para armazenamento do novo valor do campo called
do protocolo SIP.
sip_username- ponteiro utilizado para armazenamento do valor original do campo
username do protocolo SIP.
sip_usernamen - ponteiro utilizado para armazenamento do novo valor do campo
username do protocolo SIP.
sip_passwordn - ponteiro utilizado para armazenamento do valor do campo
password do protocolo SIP.
Pode-se identificar as bibliotecas utilizadas: stdio.h, stdlib.h, stdio_ext.h, unistd.h,
string.h, termios.h, pthread.h, pcap.h, if_ether.h, ip.h, inet.h, netdb.h, in.h e socket.h.
Pode-se identificar tambm os arquivos de cabealhos de uso geral: pkt_header.h,
extract.h, checksum.h, md5.h, varredura.h e tty_set.h.

12
Uma thread pode ser definida como uma forma de execuo paralela dentro de um mesmo software
(CPLUSPLUS, 2011).
88

Demais arquivos de cabealho contidos na estrutura de arquivos do software no
declarados neste arquivo, so referenciados individualmente nos arquivos de cdigo.
3.4.5 Estruturas de Cabealho
A estrutura de cabealho consiste em uma estrutura de dados onde os cabealhos dos
pacotes capturados so conformados (CASADO, 2001). Atravs desta conformao,
possvel separar todos os campos dos cabealhos Ethernet, IP, UDP e pseudo-header. As
estruturas de cabealho so declaradas no arquivo pkt_header.h.
A estrutura do cabealho Ethernet formada por trs variveis: o endereo MAC de
origem, o endereo MAC de destino e o tipo de protocolo da camada superior. Na Tabela 15
mostrada a declarao da estrutura do cabealho Ethernet.
Tabela 15 - Estrutura do cabealho Ethernet.
9 struct sniff_ethernet {
10 u_int8_t ether_dhost[ETHER_ADDR_LEN];
11 u_int8_t ether_shost[ETHER_ADDR_LEN];
12 u_int16_t ether_type;
13 };
A estrutura do cabealho IP formada por dez variveis: verso do protocolo IP,
campo ToS, tamanho, campo id, campo offset, campo ttl, protocolo da camada superior,
checksum, endereo IP de origem e endereo IP de destino. Na Tabela 16 pode-se observar a
declarao da estrutura do cabealho IP.
Tabela 16 - Estrutura do cabealho IP.
15 struct sniff_ip {
16 u_char ip_vhl;
17 u_char ip_tos;
18 u_short ip_len;
19 u_short ip_id;
20 u_short ip_off;
21 #define IP_RF 0x8000
22 #define IP_DF 0x4000
23 #define IP_MF 0x2000
24 #define IP_OFFMASK 0x1fff
25 u_char ip_ttl;
26 u_char ip_p;
27 u_short ip_sum;
28 struct in_addr ip_src,ip_dst;
29 };
A estrutura do cabealho UDP formada por quatro variveis: porta de origem, porta
de destino, tamanho e checksum. Na Tabela 17 pode-se observar a declarao da estrutura do
cabealho UDP.
89

Tabela 17 - Estrutura do cabealho UDP.
32 struct sniff_udp {
33 u_short uh_sport;
34 u_short uh_dport;
35 u_short uh_ulen;
36 u_short uh_sum;
37 };
O pseudo-header utilizado para a gerao do checksum tambm foi conformado
atravs de uma estrutura que possui os campos: endereo IP de origem, endereo IP de
destino, campo zerado, protocolo da camada de transporte e campo tamanho do protocolo
UDP. Na Tabela 18 pode ser observada a declarao da estrutura do pseudo-header.
Tabela 18 - Estrutura do pseudo-header.
40 struct pseudo_header {
41 u_int32_t ip_src;
42 u_int32_t ip_dst;
43 u_char zero1;
44 u_char proto;
45 u_int16_t udp_len;
46 };
3.4.6 Funes Globais
Como funes globais podemos citar as que so desenvolvidas nos arquivos:
varredura.c, extract.h, print_pkt.c, cap.c, tty_set.c, md5.c e checksum.c.
As funes contidas nos arquivos checksum.c, md5.c e extract.h no esto detalhadas
neste trabalho pois foram apenas adicionadas ao projeto e no desenvolvidas. Estas funes
podem ser observadas nos ANEXOS A, B e C respectivamente.

3.4.6.1 Funo valor_string
A funo valor_string desenvolvida no arquivo varredura.c e utilizada para
retornar o valor dos campos que identificam os dados dos pacotes capturados e os dados dos
campos SIP. A Tabela 19 mostra o desenvolvimento da funo. Os nmeros que aparecem
esquerda no fazem parte do cdigo, apenas identificam as linhas do aquivo.
90

Tabela 19 - Desenvolvimento da funo valor_string.
7 int valor_string(FILE *my_stream,char *str_to_find, char *ptr_rec, char end_char, char
exc_char)
8 {
9 char buffer[300];
10 char val[300];
11 char *buff_ptr, *find_ptr;
12 int i,j,len,saida;
13 len = strlen(str_to_find);
14 memset(&buffer,0,sizeof(char)*300);
15 memset(&val,0,sizeof(char)*300);
16 i = 0;
17 j = 0;
18 saida = 0;
19
20 rewind(my_stream);
21 while (fgets(buffer,300,my_stream)) {
22 buff_ptr = buffer;
23 if ((find_ptr = strstr(buff_ptr,str_to_find))) {
24 saida = 1;
25 find_ptr += len;
26 while(*find_ptr != end_char && *find_ptr != EOF)
27 if (*find_ptr != exc_char)
28 val[i++]=*find_ptr++;
29 else
30 find_ptr++;
31 }
32 }
33 if (i > 0)
34 val[i++] = '\0';
35 memcpy(ptr_rec,val,i);
36 return(saida);
37 }
A funo deve encontrar no stream
13
denominado como my_stream o campo
identificado pelo ponteiro str_to_find, armazenar individualmente os caracteres diferentes do
caractere identificado pela varivel exc_char em uma varivel de apoio at encontrar o
caractere identificado na varivel end_char. Quando encontrar o caractere que finaliza o valor
do campo, os dados so copiados da varivel de apoio para o ponteiro ptr_rec. A funo
retorna 1 se o campo procurado foi encontrado e 0 se o campo procurado no foi
encontrado.
3.4.6.2 Funo troca_string
A funo troca_string desenvolvida no arquivo varredura.c e utilizada para
efetuar a troca de valores de campos dentro de um arquivo. Na Tabela 20 pode-se observar o
desenvolvimento da funo, os nmeros esquerda so apenas identificadores das linhas no
arquivo e no fazem parte do cdigo de desenvolvimento da funo.

13
Stream pode ser definido como um bloco de dados que representa um arquivo (WALL, WATSON e WHITIS,
1999).
91

Tabela 20 - Desenvolvimento da funo troca_string.
40 int troca_string(char *file_name, char *str_to_find, char *str_to_change)
41 {
42 FILE *my_stream,*temp_stream;
43 char temp_name[50];
44 char comando[150];
45 char line_buff[300],str2find_buff[50],str2change_buff[50];
46 char *new_line_buff;
47 char ini_buff[200],end_buff[200];
48 char *line_ptr, *find_ptr, *aft_find_ptr;
49 int len_line,len_str2find,len_str2change,trocaok,i;
50 fpos_t posit;
51
52 new_line_buff = (char *)malloc(sizeof(char)*300);
53 memset(&temp_name,'\0',sizeof(char)*50);
54 memset(&comando,'\0',sizeof(char)*150);
55 memset(&line_buff,'\0',sizeof(char)*300);
56 memset(&str2find_buff,'\0',sizeof(char)*50);
57 memset(&str2change_buff,'\0',sizeof(char)*50);
58 len_str2find = 0;
59 len_str2change = 0;
60 trocaok = 0;
61
62 sprintf(temp_name,"%s_temp",file_name);
63 temp_stream = fopen(temp_name,"w");
64 sprintf(str2find_buff,"%s",str_to_find);
65 sprintf(str2change_buff,"%s",str_to_change);
66 len_str2find = strlen(str2find_buff);
67 len_str2change = strlen(str2change_buff);
68
69 if ((my_stream = fopen(file_name,"r"))){
71 while (fgets(line_buff,300,my_stream)) {
72 memset(new_line_buff,'\0',sizeof(char)*300);
73 fgetpos(my_stream,&posit);
74 line_ptr = line_buff;
75 len_line = strlen(line_buff);
76 if ((find_ptr = strstr(line_ptr,str_to_find))) {
77 aft_find_ptr = find_ptr + len_str2find;
78 memset(&ini_buff,'\0',sizeof(char)*200);
79 memset(&end_buff,'\0',sizeof(char)*200);
80 i = 0;
81 while (line_ptr != find_ptr) {
82 ini_buff[i++] = *line_ptr++;
83 };
84 i = 0;
85 while (*aft_find_ptr != '\n') {
86 end_buff[i++] = *aft_find_ptr++;
87 };
88 memcpy(new_line_buff,ini_buff,strlen(ini_buff));
89 memcpy(new_line_buff+strlen(ini_buff),str2change_buff,\
90 strlen(str2change_buff));
91
memcpy(new_line_buff+strlen(ini_buff)+strlen(str2change_buff),\
92 end_buff,strlen(end_buff));
93 fprintf(temp_stream,"%s\n",new_line_buff);
94 trocaok = trocaok + 1;
95 } else {
96 fprintf(temp_stream,"%s",line_buff);
97 }
98 }
99 fclose(my_stream);
100 }
101 fclose(temp_stream);
102 sprintf(comando,"mv -f %s %s",temp_name,file_name);
103 system(comando);
104 return(trocaok);
105 }
Esta funo deve abrir o arquivo identificado pelo argumento file_name, encontrar a
sequncia de caracteres armazenada em str_to_find e substituir pela sequncia de caracteres
armazenada em str_to_change.A funo retorna um nmero inteiro de quantas vezes a troca
92

foi efetuada no arquivo. O processo de troca utiliza a criao de um arquivo temporrio onde
so gravados os dados do arquivo original com a troca efetuada, depois disso o arquivo
original apagado e o arquivo temporrio renomeado para o arquivo original.
3.4.6.3 Funo metodo_sip
A funo metodo_sip desenvolvida no arquivo varredura.c, utilizada para
identificar o mtodo utilizado pelo protocolo SIP no stream passado como argumento. A
Tabela 21 mostra o desenvolvimento da funo. Os nmeros visualizados esquerda no
fazem parte do cdigo, apenas identificam as linhas no arquivo.
Tabela 21 - Desenvolvimento da funo metodo_sip.
108 void metodo_sip(FILE *my_stream, char *ptr_rec)
109 {
110 char buffer[300];
111 char ch;
112 int i,k;
113 fpos_t positn,positr;
114 memset(&buffer,0,sizeof(char)*300);
115 i = 0;
116 k = 0;
117
119 do {
120 ch = fgetc(my_stream);
121 if (ch == '\n') {
122 fgetpos(my_stream,&positn);
123 k++;
124 }
125 } while (ch != '\r');
126 fgetpos(my_stream,&positr);
127 i = positr.__pos - positn.__pos;
128 fsetpos(my_stream,&positn);
129 fgets(ptr_rec,i,my_stream);
130 }
3.4.6.4 Funo valor_sip_string
A funo valor_sip_string desenvolvida no arquivo varredura.c, baseada na
funo valor_string descrita na seo 3.4.6.1. A diferena est no ponteiro do tipo char
denominado start_line que passado para a funo valor_sip_string. O processo semelhante
a funo valor_string, a diferena que esta funo localiza apenas o valor da varivel cuja
93

linha do bloco de dados do protocolo SIP inicia com os caracteres identificados pelo ponteiro
start_line. A funo retorna 1 se encontrar o valor procurado e 0 se no encontrar. A
Tabela 22 mostra o desenvolvimento da funo, os nmeros visualizados esquerda da figura
so apenas identificadores das linhas do arquivo no fazendo parte do cdigo.
Tabela 22 - Desenvolvimento da funo valor_sip_string.
133 int valor_sip_string(FILE *my_stream, char *start_line, char *str_to_find,\
134 char *ptr_rec, char end_char, char exc_char)
135 {
136 char buffer[300];
137 char val[300];
138 char *buff_ptr, *find_ptr;
139 int i,j,k,len,saida;
140 len = strlen(str_to_find);
141 memset(&buffer,'\0',sizeof(char)*300);
142 memset(&val,'\0',sizeof(char)*300);
143 i = 0;
144 j = 0;
145 k = 0;
146
148 while (fgets(buffer,300,my_stream)) {
149 buff_ptr = buffer;
150 if ((find_ptr = strstr(buff_ptr,start_line))) {
151 if ((find_ptr = strstr(buff_ptr,str_to_find))) {
152 saida = 1;
153 find_ptr += len;
154 while(*find_ptr != end_char && *find_ptr != EOF)
155 if (*find_ptr != exc_char)
156 val[i++]=*find_ptr++;
157 else
158 find_ptr++;
159 }
160 }
161 }
162 if (i > 0)
163 val[i++] = '\0';
164 memcpy(ptr_rec,val,i);
165 return(saida);
166 }
3.4.6.5 Funo payload_sip
A funo payload_sip desenvolvida no arquivo varredura.c, utilizada para obter
todo o contedo do protocolo SIP armazenado em um arquivo de captura. A Tabela 23 mostra
o desenvolvimento da funo. Os nmeros visualizados esquerda da figura so apenas
indentificadores das linhas e no fazem parte do cdigo.
Tabela 23 - Desenvolvimento da funo payload_sip.
169 void payload_sip(FILE *my_stream,int *i,fpos_t *j)
170 {
171 char ch;
172 fpos_t positn,positr;
173
174 *i = 0;
175
94

177 do {
179 if (ch == '\n') {
180 fgetpos(my_stream,&positn);
181 }
182 } while (ch != '\r');
183 //positn.__pos++;
184 fsetpos(my_stream,&positn);
185 do {
187 } while (ch != EOF);
188 fgetpos(my_stream,&positr);
189 *i = positr.__pos - positn.__pos;
190 memcpy(j,&positn,sizeof(fpos_t));
191 }
A funo varre o stream passado como argumento, localiza o incio do bloco de
dados SIP, o seu tamanho, grava ambos os dados nos demais argumentos passados e finaliza.
Com esses dados a funo que executou a funo payload_sip faz a leitura dos dados no
arquivo.
3.4.6.6 Funo str2hex
A funo str2hex desenvolvida no arquivo varredura.c, utilizada para converter
uma string
14
de dois caracteres em um nmero hexadecimal. O processo consiste na
comparao de cada caractere da string com todos os possveis caracteres da base
hexadecimal e assim montar o nmero hexadecimal. O retorno da funo o prprio nmero
hexadecimal convertido. A Tabela 24 mostra parte do desenvolvimento da funo. Os
nmeros esquerda so utilizados apenas para identificar as linhas do arquivo e no fazem
parte do cdigo.
Tabela 24 - Parte do desenvolvimento da funo str2hex.
194 u_int8_t str2hex(char *str_ary)
195 {
196 u_int8_t saida;
197 char str[3];
198 char ch;
199 memcpy(&str,str_ary,sizeof(char)*3);
200 if ((str[1] == '\0')) {
201 str[2] = '\0';
202 ch = str[0];
203 str[1] = ch;
204 str[0] = '0';
205 }
206 if (str[0] == '0') {
207 if (str[1] == '0')
208 saida = 0x00;
209 else if (str[1] == '1')
210 saida = 0x01;

14
String pode ser definido como um vetor de variveis do tipo char (CPLUSPLUS, 2011).
95

211 else if (str[1] == '2')
212 saida = 0x02;
213 else if (str[1] == '3')
214 saida = 0x03;
215 else if (str[1] == '4')
216 saida = 0x04;
217 else if (str[1] == '5')
218 saida = 0x05;
219 else if (str[1] == '6')
220 saida = 0x06;
221 else if (str[1] == '7')
222 saida = 0x07;
223 else if (str[1] == '8')
224 saida = 0x08;
225 else if (str[1] == '9')
226 saida = 0x09;
227 else if ((str[1] == 'a') || (str[1] == 'A'))
228 saida = 0x0a;
229 else if ((str[1] == 'b') || (str[1] == 'B'))
230 saida = 0x0b;
231 else if ((str[1] == 'c') || (str[1] == 'C'))
232 saida = 0x0c;
233 else if ((str[1] == 'd') || (str[1] == 'D'))
234 saida = 0x0d;
235 else if ((str[1] == 'e') || (str[1] == 'E'))
236 saida = 0x0e;
237 else if ((str[1] == 'f') || (str[1] == 'F'))
238 saida = 0x0f;
239 } else if (str[0] == '1') {
3.4.6.7 Funo imprime_pkt
A funo imprime_pkt desenvolvida no arquivo print_pkt.c, utilizada para gerar a
impresso dos dados do arquivo de captura em um formato padro na tela do operador do
software. O processo consiste na abertura do arquivo passado como argumento e varredura
em busca das informaes de: sequncia de captura, endereo IP de origem, endereo IP de
destino, porta UDP de origem, porta UDP de destino e mtodo SIP. Depois disso efetuada a
impresso das informaes na tela do operador. A Tabela 25 mostra o desenvolvimento da
funo. Os nmeros observados na figura so apenas para identificar as linhas do arquivo no
fazendo parte do cdigo.
Tabela 25 - Desenvolvimento da funo imprime_pkt.
1 #include "config.h"
2 #include "menu.h"
3
4 void imprime_pkt(char *pathname)
5 {
6 FILE *arq_data = NULL;
7
8 char arqnum[5];
9 char srcip[30];
10 char dstip[30];
11 char udpsrc[10];
12 char udpdst[10];
13 char header[100];
14
96

15 arq_data = fopen(pathname,"r");
16
17 valor_string(arq_data,"ARQ_NUM=",arqnum,'\n','\0');
18 valor_string(arq_data,"IP_SRC=",srcip,'\n','\0');
19 valor_string(arq_data,"IP_DST=",dstip,'\n','\0');
20 valor_string(arq_data,"UDP_SRC=",udpsrc,'\n','\0');
21 valor_string(arq_data,"UDP_DST=",udpdst,'\n','\0');
22 metodo_sip(arq_data,header);
23
24 fclose(arq_data);
25 if (strcmp(srcip,ip_orig) == 0)
26 printf("\t%s %s:%s\t\t---->\t\t%s:%s
\t%s\n",arqnum,srcip,udpsrc,dstip,udpdst,header);
27 else
28 printf("\t%s %s:%s\t\t<----\t\t%s:%s
\t%s\n",arqnum,dstip,udpdst,srcip,udpsrc,header);
29 }
Na Figura 52 pode-se visualizar o formato de impresso realizado pela funo
imprime_pkt com todas as informaes mencionadas.

Figura 52 - Exemplo de impresso realizada pela funo imprime_pkt.
3.4.6.8 Funo rl_ttyset
A funo rl_ttyset desenvolvida no arquivo tty_set.c, utilizada para alterar o modo
padro de entrada de dados no terminal onde a interface com o operador apresentada. A
Tabela 26 mostra o desenvolvimento da funo. Os nmeros esquerda da figura so
utilizados apenas para identificar as linhas do arquivo e no fazem parte do cdigo.
Tabela 26 - Desenvolvimento da funo rl_ttyset.
1 #include <termios.h>
2
3 void rl_ttyset(int reset)
4 {
5 static struct termios old_conf; // Armazena as configuracoes antigas
6 struct termios new_conf; // Recebe as novas configuracoes
7
8 if (reset == 0) {
9 (void) tcgetattr (0, &old_conf);
10 new_conf = old_conf; // Copia as configuracoes antigas
11 new_conf.c_lflag &= ~(ECHO | ICANON);
12 new_conf.c_iflag &= ~(ISTRIP | INPCK);
13 (void) tcsetattr (0, TCSANOW, &new_conf); // Habilita as novas configuracoes
14 } else
15 (void) tcsetattr (0, TCSANOW, &old_conf); // Restaura as configuracoes antigas
16 }
97

O processo consiste em modificar duas flags
15
ou restaurar a configurao anterior
do terminal para permitir que o usurio entre com dados atravs do teclado sem a confirmao
de entrada pela tecla Enter.
3.4.6.9 Funo callback
A funo callback desenvolvida no arquivo cap.c, utilizada durante uma sesso
de captura para efetuar o processamento dos pacotes capturados. Esta funo executada pela
funo pcap_dispatch da libpcap que responsvel pela captura dos pacotes.
Inicialmente a funo declara e inicializa as variveis necessrias como pode ser
observado na Tabela 27, os nmeros visualizados esquerda so apenas identificadores das
linhas do arquivo no fazendo parte do cdigo.
Tabela 27 - Incio da funo callback.
5 void callback(u_char *useless,const struct pcap_pkthdr* pkthdr,const u_char* packet)
6 {
7 char file_num[5];
8 char sip_fhdr[100];
9 char pathname[20];
10
11 const struct sniff_ethernet *ethernet;
12 const struct sniff_ip *ip;
13 const struct sniff_udp *udp;
14
15 const u_char *payload;
16
17 u_int size_ip;
18 u_int size_udp;
19
20 FILE *arq = NULL;
21
22 char srcip[100];
23 char dstip[100];
24 u_int16_t srcudp;
25 u_int16_t dstudp;
26
27 char hdr_sip[1000];
28 char aux1,aux2;
29
30 int j,k;
31
32 memset(&sip_fhdr,0,sizeof(char)*100);
33 memset(&file_num,0,sizeof(char)*5);
Continuando com o desenvolvimento da funo callback na Tabela 28, o segundo
passo a configurao do nome e criao do arquivo que vai armazenar os dados do pacote
nas linhas 35 a 40. Depois feita a conformao do pacote na estrutura do cabealho

15
Uma flag pode ser definida como uma opo a ser configurada com valores pr-definidos.
98

Ethernet, o incio da extrao dos campos do cabealho e a gravao desses campos no
arquivo criado. Os nmeros visualizados esqueda apenas identificam as linhas, no fazem
parte do cdigo.
Tabela 28 - Primeira parte do desenvolvimento da funo callback.
35 if (*arq_pcap_cnt < 10)
36 sprintf(file_num,"0%d",*arq_pcap_cnt);
37 else
38 sprintf(file_num,"%d",*arq_pcap_cnt);
39 sprintf(pathname,"%s%s.cap",arq_pcap_nome,file_num);
40 arq = fopen(pathname,"w");
41
42 fprintf(arq,"ARQ_NUM=%s\n\n",file_num);
43
44 ethernet = (struct sniff_ethernet*)packet;
45
46 aux1 = '=';
47 aux2 = ':';
48 j = ETHER_ADDR_LEN;
49 fprintf(arq,"ETHER_MAC_SRC");
50 do{
51 fprintf(arq,"%c%X",(j == ETHER_ADDR_LEN) ? aux1 : aux2,ethernet-
>ether_shost[6-j]);
52 }while(--j>0);
53 fprintf(arq,";");
54
55 j = ETHER_ADDR_LEN;
56 fprintf(arq,"\nETHER_MAC_DST");
57 do{
58 fprintf(arq,"%c%X",(j == ETHER_ADDR_LEN) ? aux1 : aux2,ethernet-
>ether_dhost[6-j]);
59 }while(--j>0);
60 fprintf(arq,";");
61
62 fprintf(arq,"\nETHER_TYPE=%u\n\n",ethernet->ether_type);
Na Tabela 29 inicia o processo de conformao do pacote na estrutura do cabealho
IP e UDP, extraindo todos os campos de cada cabealho e gravando esses dados no arquivo de
armazenamento. Depois disso feita a leitura do payload
16
do pacote que corresponde ao
bloco de dados do protocolo SIP, e a gravao desses dados no arquivo de armazenamento.
Os nmeros visualizados esquerda so apenas identificadores das linhas do arquivo no
Tabela 29 Segunda parte do desenvolvimento da funo callback.
65 if (ethernet->ether_type == 0x0008) {
66 ip = (struct sniff_ip*)(packet + SIZE_ETHERNET);
67 size_ip = IP_HL(ip)*4;
68 inet_ntop(AF_INET, &ip->ip_src, srcip, sizeof(srcip));
69 inet_ntop(AF_INET, &ip->ip_dst, dstip, sizeof(dstip));
70
71 fprintf(arq,"IP_VER=%u\n",ip->ip_vhl);
72 fprintf(arq,"IP_TOS=%u\n",ip->ip_tos);
73 fprintf(arq,"IP_LEN=%u\n",EXTRACT_16BITS(&ip->ip_len));
74 fprintf(arq,"IP_ID=%u\n",EXTRACT_16BITS(&ip->ip_id));
75 fprintf(arq,"IP_OFF=%u\n",ip->ip_off);
76 fprintf(arq,"IP_TTL=%u\n",ip->ip_ttl);
77 fprintf(arq,"IP_PROTO=%u\n",ip->ip_p);
78 fprintf(arq,"IP_CHK=%u\n",EXTRACT_16BITS(&ip->ip_sum));
79 fprintf(arq,"IP_SRC=%s\n",srcip);
80 fprintf(arq,"IP_DST=%s\n\n",dstip);
81

16
Payload pode ser definido como a carga de dados transportada pelo pacote (TANENBAUM, 2003).
99

82 if (ip->ip_p == 17) {
83 udp = (struct sniff_udp*)(packet + SIZE_ETHERNET + size_ip);
84 srcudp = ntohs(udp->uh_sport);
85 dstudp = ntohs(udp->uh_dport);
86
87 fprintf(arq,"UDP_SRC=%d\n",srcudp);
88 fprintf(arq,"UDP_DST=%d\n",dstudp);
89 fprintf(arq,"UDP_LEN=%u\n",EXTRACT_16BITS(&udp->uh_ulen));
90 fprintf(arq,"UDP_CHK=%u\n\n",EXTRACT_16BITS(&udp->uh_sum));
91
92 size_udp = 8;
93 payload=(u_char *)malloc(EXTRACT_16BITS(&udp-
>uh_ulen)*sizeof(u_char));
94 payload = (u_char *)(packet + SIZE_ETHERNET + size_ip +
size_udp);
95 fprintf(arq,"%s",payload);
96 fclose(arq);
97
98 sprintf(hdr_sip,"%s",payload);
Na Tabela 30 efetuado o ltimo processo da funo callback, a impresso dos
dados do pacote na tela de captura da seo Escuta. No caso da funo callback, a
impresso dos dados efetuada diretamente ao invs de utilizar a funo imprime_pkt. Foi
definido desta forma pelo fato da funo imprime_pkt abrir o arquivo de captura, ler os dados
e fechar o arquivo, sendo que neste ponto da funo callback todos os dados j esto
armazenados em variveis tornando mais rpido o acesso a eles e diminuindo assim o
processamento.
Tabela 30 - Terceira parte do desenvolvimento da funo callback.
99 k = 0;
100 j = 0;
101 do {
102 if (hdr_sip[k] != 0x0a)
103 sip_fhdr[j++] = hdr_sip[k];
104 else
105 break;
106 k++;
107 } while (1);
108
109 if (k > 5) {
110 if (strcmp(srcip,ip_orig) == 0)
111 printf("\t%s %s:%u\t\t---->\t\t%s:%u
\t%s\n",file_num,srcip,srcudp,dstip,dstudp,sip_fhdr);
112 else
113 printf("\t%s %s:%u\t\t<----\t\t%s:%u
\t%s\n",file_num,dstip,dstudp,srcip,srcudp,sip_fhdr);
114 *arq_pcap_cnt = *arq_pcap_cnt + 1;
115
116 if (arq_pcap_cnt == arq_res_cnt) {
117 *stop_thread = 1;
118 }
119 } else
120 remove(pathname);
121 }
122 }
123 }
100

3.4.7 Controle de Menu
O controle de menu do software feito pelo cdigo contido no arquivo menu.c.
Basicamente os controles de menu so responsveis pela impresso do menu na tela do
operador e pela leitura de entrada de teclado, algumas funes possuem ainda alguns
controles especficos descritos a seguir.
3.4.7.1 Funo cabecalho
A funo cabecalho utilizada para imprimir o cabealho das telas do software. Esta
funo recebe dois argumentos que complementam a impresso da tela de cada seo. A
Tabela 31 mostra o desenvolvimento da funo cabecalho. Os nmeros visualizados
esquerda so apenas identificadores das linhas, no fazendo parte do cdigo.
Tabela 31 - Desenvolvimento da funo cabecalho.
4 void cabecalho(char *arg1, char *arg2)
5 {
6 system("clear");
7 printf("\n");
8 printf("\t############################################################\n");
9 printf("\t### ANALISADOR SIP ###\n");
10 printf("\t############################################################\n\n");
11 printf("\t###\t%s\n\n\t%s\n\n\n",arg1,arg2);
12 }
3.4.7.2 Funo menu_main
A funo menu_main utilizada para imprimir o menu principal na tela do operador
e para efetuar a leitura de teclado que define qual seo o operador deseja acessar. A leitura
efetuada, processada de acordo com as opes disponveis para acesso, repetindo a funo
caso a opo do operador for considerada invlida, depois a opo repassada como retorno
da funo. A Tabela 32 mostra o desenvolvimento da funo menu_main. Os nmeros
visualizados esquerda so apenas identificadores das linhas, no fazendo parte do cdigo.
101

Tabela 32 - Desenvolvimento da funo menu_main.
14 char menu_main()
15 {
16 char opt;
17 int saida;
18 do {
19 cabecalho("MENU PRINCIPAL","");
20 printf("\t\t1 - Escuta\n");
21 printf("\t\t2 - Dados Escutados\n");
22 printf("\t\t3 - Injeo\n");
23 printf("\t\t4 - Mostra Resultados\n");
24 printf("\t\t5 - Limpar Resultados\n");
25 printf("\t\t6 - Limpar Tudo\n");
26 printf("\t\n\n");
27 printf("\t\tDigite a opo ou 'q' para sair: ");
28
29 opt = getchar();
30 if ((opt != '1') && (opt != '2') && (opt != '3') && (opt != '4') \
31 && (opt != '5') && (opt != '6') && (opt != 'q')) {
32 printf("\n\t\tOpo invlida!");
33 __fpurge(stdin);
34 getchar();
35 saida = 0;
36 printf("\n");
37 } else {
38 __fpurge(stdin);
39 saida = 1;
40 }
41 } while (saida != 1);
42
43 return opt;
44 }
Nota-se o uso do comando __fpurge(stdin) antes do comando getchar(), esse
comando foi utilizado para fazer a limpeza do buffer
17
de teclado para garantir que o software
receba apenas o que o usurio digitar.
3.4.7.3 Funo menu_1
A funo menu_1 utilizada para imprimir o menu da seo Escuta na tela do
operador e efetuar a leitura de teclado que identifica a opo do operador dentro desta seo.
A Tabela 33 mostra o desenvolvimento da funo menu_1. Os nmeros visualizados
Tabela 33 - Desenvolvimento da funo menu_1.
46 char menu_1()
47 {
48 char opt;
49 int saida;
50
51 do {
52 cabecalho("MENU PRINCIPAL >>> 1-ESCUTA","");
53 printf("\t\t1 - Interface (%s)\n",dev);

17
Buffer pode ser definido como uma memria de armazenamento temporrio (WALL, WATSON e WHITIS,
1999).
102

54 printf("\t\t2 - IP Origem (%s)\n",ip_orig);
55 printf("\t\t3 - Porta Destino (%s)\n",porta_dst);
56 printf("\t\t4 - Iniciar Escuta\n");
57 printf("\n\n");
58 printf("\t\tDigite a opo ou 'q' para voltar: ");
59
60 opt = getchar();
61 if ((opt != '1') && (opt != '2') && (opt != '3') && \
62 (opt != '4') && (opt != 'q')) {
63 printf("\n\t\tOpo invlida!");
64 __fpurge(stdin);
65 getchar();
66 saida = 0;
67 printf("\n");
68 } else {
69 __fpurge(stdin);
70 saida = 1;
71 }
73 return opt;
74 }
3.4.7.4 Funo menu_1_1
A funo menu_1_1 utilizada para impresso do menu de configurao da interface
de captura na tela do operador e para efetuar a leitura da interface de captura. A leitura do
nome da interface efetuada, a interface testada e se ela estiver disponvel gravada na
varivel dev. A Tabela 34 mostra o desenvolvimento da funo menu_1_1. Os nmeros
Tabela 34 - Desenvolvimento da funo menu_1_1.
76 void menu_1_1()
77 {
78 char opt[10];
79 int saida;
80 char errbuf[PCAP_ERRBUF_SIZE];
81 pcap_t *handle;
82 do {
83 cabecalho("MENU PRINCIPAL >>> 1-ESCUTA >>> 1-INTERFACE","");
84 printf("\t\t1 - Interface: ");
85
86 scanf("%s",opt);
87 memcpy(dev,opt,strlen(opt));
88 handle = pcap_open_live(dev,BUFSIZ,1,0,errbuf);
89 if (handle == NULL) {
90 printf("\n Opo invlida!");
91 __fpurge(stdin);
92 getchar();
93 saida = 0;
94 printf("\n");
95 } else {
96 __fpurge(stdin);
97 saida = 1;
98 }
100 }
103

3.4.7.5 Funo menu_1_2
A funo menu_1_2 utilizada para impresso do menu de configurao do
endereo IP do dispositivo a ser monitorado na tela do operador e para efetuar a leitura do
endereo IP. A leitura do endereo IP efetuada e gravada na varivel ip_orig. Na Tabela 35
pode-se observar o desenvolvimento da funo menu_1_2. Os nmeros visualizados
102 void menu_1_2()
103 {
104 char opt[30];
105
106 cabecalho("MENU PRINCIPAL >>> 1-ESCUTA >> 2-IP ORIGEM","");
107 printf("\t\t2 - IP Origem: ");
108
109 scanf("%s",opt);
110 memcpy(ip_orig,opt,strlen(opt));
111 __fpurge(stdin);
112 }
3.4.7.6 Funo menu_1_3
A funo menu_1_3 utilizada para impresso do menu de configurao da porta de
origem ou destino UDP utilizada no filtro de captura na tela do operador, e para efetuar a
leitura do valor da porta. A leitura da porta de destino UDP efetuada e gravada na varivel
porta_dst. Na Tabela 36 observa-se o desenvolvimento da funo menu_1_3. Os nmeros
114 void menu_1_3()
115 {
116 char opt[30];
117
118 cabecalho("MENU PRINCIPAL >>> 1-ESCUTA >>> 3-PORTA DESTINO","");
119 printf("\t\t3 - Porta Destino: ");
120
122 memcpy(porta_dst,opt,strlen(opt));
124 }
104

3.4.7.7 Funo menu_2
A funo menu_2 utilizada para impresso do menu de configurao dos campos
do SIP. Ele recebe dois ponteiros do tipo char como argumento, o primeiro informa o campo
que est sendo alterado e o segundo informa o nome do campo seguido do valor original do
campo. O processo consiste em efetuar a leitura do novo valor do campo que est sendo
alterado atravs da leitura do teclado, depois efetuar a troca do valor da varivel no arquivo
que armazena as informaes dos campos do SIP atravs da funo global troca_string. Caso
o usurio digite um valor invlido a funo repetida, e caso o arquivo de informaes dos
campos SIP no exista ele criado dentro desta funo. Na Tabela 37 pode-se observar o
desenvolvimento da funo menu_2. Os nmeros visualizados esquerda so apenas
identificadores das linhas, no fazendo parte do cdigo.
126 void menu_2(char *campo, char *entire_str)
127 {
128 FILE *camp_data = NULL;
129 char opt[10];
130 char part_cab[200];
131 char part_func[200];
132 char new_value[50];
133 int saida;
134
135 memset(&part_cab,'\0',sizeof(char)*200);
136 memset(&part_func,'\0',sizeof(char)*200);
137 memset(&new_value,'\0',sizeof(char)*50);
138
139 sprintf(part_cab,"MENU PRINCIPAL >>> 2-DADOS ESCUTADOS >>> %s",campo);
140 sprintf(part_func,"%s=",campo);
141
142
143 do {
144 cabecalho(part_cab,"");
145 printf("\t\t1 - %s: ",campo);
146
148
149 sprintf(new_value,"%s=%s",campo,opt);
150
151 if (opt != "") {
152 if (troca_string(arq_data_nome,entire_str,new_value) == 0) {
153 if ((camp_data = fopen(arq_data_nome,"r+"))) {
154 fseek(camp_data,0,SEEK_END);
155 fprintf(camp_data,"%s\n",new_value);
156 fclose(camp_data);
158 saida = 1;
159 } else if ((camp_data = fopen(arq_data_nome,"w"))) {
161 fprintf(camp_data,"%s\n",new_value);
164 saida = 1;
165 } else {
166 printf("\n Problema gravando alterao,
verificar arquivo!");
168 getchar();
169 saida = 1;
105

170 }
171 } else
172 saida = 1;
173 } else {
174 printf("\n Opo invlida!");
176 getchar();
177 saida = 0;
178 printf("\n");
179 }
181 }
3.4.7.8 Funo menu_3
A funo menu_3 utilizada na impresso da tela de injeo na tela do operador e
para efetuar a leitura de teclado que indica o incio da injeo ou o cancelamento da injeo.
O tratamento da entrada de teclado no efetuado nesta funo. Na Tabela 38 pode-se
observar o desenvolvimento da funo menu_3. Os nmeros visualizados esquerda so
apenas identificadores das linhas, no fazendo parte do cdigo.
183 char menu_3()
184 {
185 char opt;
186
187 cabecalho("MENU PRINCIPAL >>> 3-INJEO",\
188 "Escolha (1-Iniciar) ou 'q' para cancelar a injeo a qualquer
momento.");
189 printf("\tEscolha: ");
191 opt = getchar();
192 return(opt);
193 }
3.4.7.9 Funo menu_4
A funo menu_4 trata do controle da seo Mostrar Resultados e utilizada para
impresso da tela juntamente com os pacotes capturados atravs na seo Escuta e os
pacotes capturados e injetados na seo Injeo. A Tabela 39 mostra o desenvolvimento da
funo menu_4 onde pode-se observar a varredura dos arquivos de coleta e de resultado de
injeo nas linhas 217 a 223, e a cada arquivo efetuada a impresso dos dados do arquivo
106

atravs do uso da funo imprime_pkt. Os nmeros visualizados esquerda so apenas
identificadores das linhas, no fazendo parte do cdigo.
195 void menu_4()
196 {
197 char opt;
198 int i;
199 char pathname[100];
200
201 do {
202 cabecalho("MENU PRINCIPAL >>> 4-MOSTRAR RESULTADOS",\
203 "Escolha 'q' para voltar.");
204 printf("\n\tANTES DA ALTERAO\n\n");
205 printf("\tPKT IP SRC\t\t\t\t\tIP DST\t\t\tSIP\n\n");
206 for (i=1;i<*arq_cap_cnt;i++) {
207 memset(pathname,'\0',sizeof(char)*100);
208 if (i < 10)
209 sprintf(pathname,"%s0%d.cap",arq_cap_nome,i);
210 else
211 sprintf(pathname,"%s%d.cap",arq_cap_nome,i);
212 imprime_pkt(pathname);
213 }
214 printf("\n\n\n\tDEPOIS DA ALTERAO\n\n");
216 for (i=1;i<*arq_res_cnt;i++) {
217 memset(pathname,'\0',sizeof(char)*100);
218 if (i < 10)
219 sprintf(pathname,"%s0%d.cap",arq_res_nome,i);
220 else
221 sprintf(pathname,"%s%d.cap",arq_res_nome,i);
223 }
224 printf("\n\n\tEscolha: ");
226 opt = getchar();
227 } while (opt != 'q');
229 }
3.4.7.10 Funo menu_5
A funo menu_5 responsvel pelo controle da limpeza dos resultados. utilizada
na impresso da tela da opo de limpeza de resultados na tela do operador e na excluso dos
arquivos referentes a captura e injeo da seo Injeo. Essa tela informa que os resultados
esto sendo apagados, aguarda o tempo de 1s atravs do comando sleep
18
e finaliza. Na
Tabela 40 pode-se observar o desenvolvimento da funo menu_5. Os nmeros visualizados
231 void menu_5()
232 {

18
A funo sleep efetua uma pausa do tempo em segundos passado como argumento para a fuo
(CPLUSPLUS, 2011).
107

234 char troca_valor[100];
235 cabecalho("MENU PRINCIPAL >>> 5-LIMPAR RESULTADOS",\
236 "Excluindo resultados...");
237 sprintf(comando,"rm -rf %s*.*",arq_res_nome);
239 sprintf(troca_valor,"ARQ_RES_TOTAL=%d",*arq_res_cnt);
240 troca_string(arq_info_nome,troca_valor,"ARQ_RES_TOTAL=0");
241 sleep(1);
242 }
3.4.7.11 Funo menu_6
A funo menu_6 responsvel pelo controle da limpeza geral dos arquivos do
software. utilizada na impresso da tela da opo de limpeza geral na tela do operador e na
excluso de todos os arquivos de armazenamento. O processo exclui os arquivos, informa a
excluso dos dados, aguarda o tempo de 1s atravs do comando sleep, e finaliza. Na Tabela
41 pode-se observar o desenvolvimento da funo menu_6. Os nmeros visualizados
244 void menu_6()
245 {
247 cabecalho("MENU PRINCIPAL >>> 6-LIMPAR TUDO",\
248 "Excluindo tudo...");
249 sprintf(comando,"rm -rf %s*.*",arq_cap_local);
251 sleep(1);
252 }
3.4.8 Controle Principal
O controle principal responsvel por inicializar as variveis globais, carregar os
valores de uma sesso de captura j salvos, carregar valores dos campos SIP j salvos e
controlar o acesso s demais sees do software. O cdigo do controle principal faz parte do
arquivo main.c e a funo denominada main.
A inicializao das variveis feita no incio da execuo do software. Como as
variveis globais so praticamente ponteiros, cabe ao controle principal fazer a alocao de
108

memria para cada ponteiro descrito na seo 3.4.4. A inicializao feita atravs da funo
malloc
19
. Na Tabela 42 pode-se verificar o incio do cdigo do controle principal e nas linhas
13 a 32 a inicializao das variveis globais. Os nmeros visualizados esquerda so apenas
identificadores das linhas no fazendo parte do cdigo.
Tabela 42 - Inicializao das variveis globais.
1 #include "config.h"
2 #include "escuta.h"
3 #include "menu.h"
4 #include "altera.h"
5 #include "injection.h"
6
7 int main()
8 {
9 char com_cria[50];
10 FILE *file_info;
11 char opt;
12
13 dev=(char *)malloc(5*sizeof(char));
14 ip_orig=(char *)malloc(20*sizeof(char));
15 porta_dst=(char *)malloc(6*sizeof(char));
16 arq_info_nome=(char *)malloc(100*sizeof(char));
17 arq_cap_nome=(char *)malloc(100*sizeof(char));
18 arq_res_nome=(char *)malloc(100*sizeof(char));
19 arq_data_nome=(char *)malloc(100*sizeof(char));
20 arq_cap_cnt=(int *)malloc(3*sizeof(int));
21 arq_res_cnt=(int *)malloc(3*sizeof(int));
22 arq_cap_local=(char *)malloc(50*sizeof(char));
23 int_arq=(char *)malloc(10*sizeof(char));
24 stop_thread=(int *)malloc(5*sizeof(int));
25 sip_caller=(char *)malloc(50*sizeof(char));
26 sip_callern=(char *)malloc(50*sizeof(char));
27 sip_called=(char *)malloc(50*sizeof(char));
28 sip_calledn=(char *)malloc(50*sizeof(char));
29 sip_username=(char *)malloc(50*sizeof(char));
30 sip_usernamen=(char *)malloc(50*sizeof(char));
31 sip_password=(char *)malloc(50*sizeof(char));
32 sip_passwordn=(char *)malloc(50*sizeof(char));
A prxima etapa executada pelo controle principal aps a inicializao das variveis,
o carregamento dos valores salvos e as definies bsicas para a operao do sofware. Na
Tabela 43 pode-se verificar a continuao do controle principal, os nmeros visualizados
esquerda so apenas identificadores das linhas do arquivo, no fazendo parte do cdigo. Nas
linhas 34 a 38 so definidos o local onde sero gravados os arquivos e os nomes dos arquivos.
Nota-se que os nomes dos arquivos de captura da seo Escuta e da seo Injeo esto
incompletos, eles so completados no momento do armazenamento de acordo com a
sequncia de captura. Na linha 40 o controle verifica a existncia do arquivo de informaes
da sesso de captura salva, nas linhas seguintes faz a leitura dos dados utilizando a funo
global valor_string. Na linha 59 ocorre a mesma situao com o arquivo de informaes do
protocolo SIP, verifica-se a existncia do arquivo e faz-se a leitura dos dados.

19
Malloc uma funo da biblioteca stdlib.h que aloca um espao de memria para uma determinada varivel
sem alterar os dados j contidos na memria (CPLUSPLUS, 2011).
109

Tabela 43 - Carregamento dos valores salvos.
34 sprintf(arq_cap_local,"./capture/");
35 sprintf(arq_info_nome,"%sinfo_sessao.txt",arq_cap_local);
36 sprintf(arq_cap_nome,"%scapture_",arq_cap_local);
37 sprintf(arq_res_nome,"%scapture_res_",arq_cap_local);
38 sprintf(arq_data_nome,"%scapture_data.txt",arq_cap_local);
39
40 if ((file_info = fopen(arq_info_nome,"r"))) {
41 valor_string(file_info,"DEV=",dev,'\n','\0');
42 valor_string(file_info,"IP_ORIG=",ip_orig,'\n','\0');
43 valor_string(file_info,"PORTA_DST=",porta_dst,'\n','\0');
44 valor_string(file_info,"ARQ_CAP_TOTAL=",int_arq,'\n','\0');
45 *arq_cap_cnt = atoi(int_arq);
46 if (valor_string(file_info,"ARQ_RES_TOTAL=",int_arq,'\n','\0') > 0)
47 *arq_res_cnt = atoi(int_arq);
48 else
49 *arq_res_cnt = 0;
50 fclose(file_info);
51 } else {
52 sprintf(dev,"eth1");
53 sprintf(ip_orig,"192.168.33.2");
54 sprintf(porta_dst,"5060");
56 *arq_cap_cnt = 0;
57 }
58
59 if ((file_info = fopen(arq_data_nome,"r"))) {
60 valor_string(file_info,"CALLER_ORIG=",sip_caller,'\n','\0');
61 valor_string(file_info,"CALLER=",sip_callern,'\n','\0');
62 valor_string(file_info,"CALLED_ORIG=",sip_called,'\n','\0');
63 valor_string(file_info,"CALLED=",sip_calledn,'\n','\0');
64 valor_string(file_info,"USERNAME_ORIG=",sip_username,'\n','\0');
65 valor_string(file_info,"USERNAME=",sip_usernamen,'\n','\0');
66 valor_string(file_info,"PASSWORD=",sip_passwordn,'\n','\0');
68 };
Outra etapa executada pelo controle principal a verificao da existncia do
diretrio de armazenamento dos dados. Pode-se verificar na Tabela 44 a verificao do
diretrio e a criao do mesmo no caso de sua inexistncia. Os nmeros esquerda so apenas
identificadores das linhas do arquivo no fazendo parte do cdigo.
Tabela 44 - Verificao do diretrio de armazenamento.
71 if (fopen(arq_cap_local,"r") == NULL) {
72 memset(&com_cria,0,sizeof(char)*50);
73 sprintf(com_cria,"mkdir %s",arq_cap_local);
74 system(com_cria);
75 }
A ltima etapa a ser executada pelo controle principal o controle do acesso s
demais sees. Na Tabela 45 observa-se o desenvolvimento do controle de acesso. Os
nmeros esquerda so identificadores das linhas do arquivo no fazendo parte do cdigo.
Tabela 45 - Desenvolvimento do controle de acesso principal.
77 do {
78 opt = menu_main();
79 switch(opt) {
80 case '1':
81 if (escuta_func() == 1) {
82 printf(" ");
83 }
84 break;
85 case '2':
86 if (*arq_cap_cnt > 0)
87 dados_esc_menu();
110

88 else {
89 cabecalho("MENU PRINCIPAL >>> 2-DADOS
ESCUTADOS","No existem dados a serem visualizados!\n");
90 sleep(1);
91 }
92 break;
93 case '3':
94 if (*arq_cap_cnt > 0)
95 if (*arq_res_cnt > 0) {
96 cabecalho("MENU PRINCIPAL >>> 3-
INJEO","Voc deve limpar os resultados primeiro!\n");
97 sleep(2);
98 } else
99 injecao();
100 else {
101 cabecalho("MENU PRINCIPAL >>> 3-INJEO","No
existem dados a serem injetados!\n");
102 sleep(1);
103 }
104 break;
105 case '4':
106 if (*arq_res_cnt == 0) {
107 cabecalho("MENU PRINCIPAL >>> 4-MOSTRAR
RESULTADOS","Voc no possui resultados para mostrar!\n");
108 sleep(2);
109 } else
110 menu_4();
111 break;
112 case '5':
113 menu_5();
115 break;
116 case '6':
117 menu_6();
119 break;
120 case 'q':
121 printf("\n\t\tSaindo...\n\n\n\n");
122 }
123 } while (opt != 'q');
124
125 sleep(1);
126 return(0);
127 }
O controle de acesso feito atravs do uso de um lao do while
20
onde a funo
menu_main, responsvel pela impresso da tela principal na tela do operador e pela leitura da
opo do operador atravs do teclado, executada e seu retorno analisado para determinar a
qual seo disponvel o acesso ser efetuado.
Observando a Tabela 45, pode-se verificar sete diferentes opes de acesso
disponveis. A opo 1 define o acesso a funo escuta_func desenvolvida no arquivo
escuta.c que trata da seo Escuta. A opo 2 define o acesso a funo dados_esc_menu
desenvolvida no arquivo altera.c que trata da seo Dados Escutados. A opo 3 define o
acesso a funo injecao desenvolvida no arquivo injection.c que trata da seo Injeo. A
opo 4 define o acesso a funo menu_4 desenvolvida no arquivo menu.c que trata da
seo Mostrar Resultados. A opo 5 define o acesso a funo menu_5 desenvolvida no

20
Do while pode ser definido como um comando onde o do determina um trecho de cdigo a ser executado
enquanto a condio determinada pelo while seja verdadeira (CPLUSPLUS, 2011).
111

arquivo menu.c que trata da seo Limpar Resultados. A opo 6 define o acesso a funo
menu_6 desenvolvida no arquivo menu.c que trata da seo Limpar Tudo. A stima opo
a de finalizao do software atravs da letra q.
3.4.9 Controle de Escuta
O controle de escuta est armazenado no arquivo escuta.c, ele responsvel pela
criao do filtro de captura atravs da leitura dos dados que compe o filtro e pela seleo da
interface atravs da qual a captura dos pacotes ser executada. Esse controle tambm
responsvel pelo controle da captura dos dados.
A primeira funo executada dentro do controle de escuta a funo escuta_func.
Essa funo executa uma outra funo j mencionada denominada menu_1 que responsvel
pela impresso da tela de escuta na tela do operador e pela leitura da opo do operador. A
opo aps lida retornada a funo escuta_func que seleciona qual das opes ser acessada.
Na Tabela 46 pode-se verificar o desenvolvimento da funo escuta_func, os nmeros
visualizados esquerda so apenas identificadores das linhas do arquivo no fazendo parte do
cdigo.
Tabela 46 - Desenvolvimento do controle de acesso da seo "Escuta".
84 int escuta_func()
85 {
86 char opt;
87
88 do {
89 opt = menu_1();
90 switch(opt) {
91 case '1':
92 memset(dev,'\0',5);
93 menu_1_1();
94 break;
95 case '2':
96 memset(ip_orig,'\0',20);
97 menu_1_2();
98 break;
99 case '3':
100 memset(porta_dst,'\0',6);
101 menu_1_3();
102 break;
103 case '4':
104 captura();
105 break;
106 }
107 } while (opt != 'q');
108 return(0);
109 }
112

No caso do operador selecionar as opes 1, 2 ou 3, ele estar acessando a
configurao da interface, do endereo IP do dispositivo monitorado e da porta UDP dos
pacotes. Se o operador escolher a opo 4, ele estar acessando a rea de captura que
desenvolvida na Tabela 47 atravs da funo captura. Os nmeros visualizados esquerda
so apenas identificadores das linhas do arquivo e no fazem parte do cdigo.
Tabela 47 - Desenvolvimento da funo de captura da seo "Escuta".
31 int captura()
32 {
33 struct bpf_program fp;
34 char filter_exp[100];
35 FILE *file_info;
36
38 bpf_u_int32 mask;
39 bpf_u_int32 net;
40
42 sprintf(comando,"rm -rf %s*",arq_cap_local);
43 system(comando);
44
45 file_info = fopen(arq_info_nome,"w");
46 fprintf(file_info,"DEV=%s\n",dev);
47 fprintf(file_info,"IP_ORIG=%s\n",ip_orig);
48 fprintf(file_info,"PORTA_DST=%s\n",porta_dst);
49
50 sprintf(filter_exp,"host %s and (udp src port %s or udp dst port %s)"\
51 ,ip_orig,porta_dst,porta_dst);
52 // carrega net e mask
53 pcap_lookupnet(dev, &net, &mask, errbuf);
54 // captura
55 if ((handle = pcap_open_live(dev,BUFSIZ,1,0,errbuf))) {
56 pcap_setnonblock(handle,0,errbuf);
57 pcap_compile(handle, &fp, filter_exp, 0, net);
58 pcap_setfilter(handle, &fp);
59
60 cabecalho("MENU PRINCIPAL >>> 1-ESCUTA >>> 4-CAPTURA",\
61 "Pressione 'q' para encerrar a captura...");
63
64 arq_pcap_nome = arq_cap_nome;
65 arq_pcap_cnt = arq_cap_cnt;
66
67 pthread_create (&pollThread, 0, PollKbd,0);
68 pthread_create (&crunchThread, 0, Cruncher,0);
69
70 pthread_join (pollThread, 0);
71 pthread_join (crunchThread, 0);
72
73 sprintf(int_arq,"%d",*arq_cap_cnt);
74 fprintf(file_info,"ARQ_CAP_TOTAL=%s\n",int_arq);
76
77 pcap_close(handle);
78
79 return 0;
80 }
81 return 1;
82 }
Observando a funo captura, pode-se verificar inicialmente a definio de algumas
variveis utilizadas na funo e a excluso de todos os arquivos que podem estar
armazenados. Essa operao visa garantir que a partir do momento que o operador inicia o
processo de captura, nenhum dado antigo permanece armazenado. Depois da excluso dos
113

dados criada a expresso do filtro de captura na linha 50. Na linha 53 efetuada a leitura
dos dados de endereamento da interface que est sendo utilizada para a captura. Esses dados
so necessrios quando o filtro aplicado na interface.
Iniciando o processo de captura efetuada a abertura da interface na linha 55, em
caso de sucesso continuado o processo setando o desbloqueio do processo de captura da
libpcap na linha 56, compilando o filtro na linha 57 e aplicando o filtro de captura na linha 58.
Nas linhas 60 a 62 preparada a tela de captura com o uso da funo cabecalho e setado na
linha 64 para que o ponteiro utilizado pela captura para denominar os arquivos, aponte para o
ponteiro que armazena o arquivo de captura da seo Escuta. tambm setado na linha 65
para que o ponteiro utilizado pela captura para contar a sequncia de pacotes capturados,
aponte para o ponteiro que armazena a contagem de arquivos capturados na seo Escuta.
Com todas as variveis setadas chega o momento de iniciar a captura. Como
observado nas linhas 67 e 68, so criadas duas threads para iniciar a captura. Depois as
mesmas threads so combinadas para que o cdigo s continue a ser executado quando ambas
terminarem sua execuo. Depois disso a varivel de contagem de pacotes capturados
armazenada no arquivo de informaes da sesso na linha 74.
As threads executadas na funo captura podem ser visualizadas na Tabela 48. Os
nmeros visualizados esquerda so apenas identificadores das linhas do arquivo e no fazem
parte do cdigo.
Tabela 48 - Desenvolvimento das threads de controle da seo "Escuta".
5 pcap_t *handle;
6 char errbuf[PCAP_ERRBUF_SIZE];
7
8 pthread_t crunchThread, pollThread;
9
10 void* Cruncher (void* info)
11 {
12 do {
13 pcap_dispatch(handle,-1,callback,NULL);
14 } while (1);
15 return (void*) 0;
16 }
17
18 void* PollKbd (void* info)
19 {
20 char ch;
21 do {
22 rl_ttyset(0);
23 ch = getchar();
24 rl_ttyset(1);
25 } while (ch != 'q');
26 pthread_cancel(crunchThread);
27
29 }
114

Como mencionado, duas threads so executadas para que o processo de captura seja
executado. Uma das threads denominada Cruncher ativa a captura. A thread PollKdb faz a
leitura do teclado, utiliza a funo j conhecida rl_ttyset para setar o terminal para efetuar a
leitura do teclado sem a confirmao com a tecla Enter. Depois disso a configurao do
terminal restaurada. Isso permite ao operador cancelar a captura a qualquer momento apenas
pressionando a tecla q, quebrando o lao do while e cancelando a thread de captura atravs
do comando pthread_cancel. Essencialmente, uma thread controla a execuo da outra.
3.4.10 Controle de Alterao
O controle de alterao est armazenado no arquivo altera.c, ele responsvel pela
verificao dos campos do SIP nos pacotes capturados mostrando os valores originais para o
operador e fornecendo o controle da alterao desses campos.
O primeiro processo dentro da funo de controle dados_esc_menu, a criao do
lao do while que executa a funo dados_esc responsvel pela impresso da tela da seo
Dados Escutados e pela leitura de teclado que direciona o operador a um dos campos SIP a
serem alterados. Dentro do lao do while, conforme a opo retornada pela funo dados_esc,
executada a funo menu_2 com diferentes argumentos. Na Tabela 49 pode ser observado o
desenvolvimento do controle de menu da seo Dados Escutados. Os nmeros visualizados
esquerda so apenas identificadores das linhas do arquivo e no fazem parte do cdigo.
Tabela 49 - Controle de menu da seo "Dados Escutados".
84 void dados_esc_menu()
85 {
86 char opt;
87 char *entire_value;
88
89 do {
90 opt = dados_esc();
91 switch(opt) {
92 case '1':
93 entire_value = (char *)malloc(sizeof(char)*50);
94 sprintf(entire_value,"CALLER=%s",sip_callern);
95 menu_2("CALLER",entire_value);
96 break;
97 case '2':
99 sprintf(entire_value,"CALLED=%s",sip_calledn);
100 menu_2("CALLED",entire_value);
101 break;
102 case '3':
104 sprintf(entire_value,"USERNAME=%s",sip_usernamen);
105 menu_2("USERNAME",entire_value);
106 break;
115

107 case '4':
109 sprintf(entire_value,"PASSWORD=%s",sip_passwordn);
110 menu_2("PASSWORD",entire_value);
111 break;
112 }
113 } while (opt != 'q');
115 }
Na Tabela 50 pode-se observar o incio da funo dados_esc. Os nmeros
observados esquerda so apenas identificadores das linhas e no fazem parte do cdigo.
Tabela 50 - Parte inicial da funo dados_esc.
5 char dados_esc()
6 {
7 FILE *arq_data = NULL;
8 FILE *camp_data = NULL;
9 int i;
10 char *pathname;
11 char opt;
12
13 char var_aux[10];
14
15 memset(&var_aux,'\0',sizeof(char)*10);
16
17 cabecalho("MENU PRINCIPAL >>> 2-DADOS ESCUTADOS","");
19
20 pathname=(char*)malloc(50*sizeof(char));
21 for (i=1;i < *arq_cap_cnt;i++) {
22 if (*arq_cap_cnt < 10)
23 sprintf(pathname,"%s0%d.cap",arq_cap_nome,i);
24 else
25 sprintf(pathname,"%s%d.cap",arq_cap_nome,i);
26 arq_data = fopen(pathname,"r");
27 if (i==1) {
28 valor_sip_string(arq_data,"From:","sip:",sip_caller,'@','\0');
29 valor_sip_string(arq_data,"To:","sip:",sip_called,'@','\0');
30 }
31 if (valor_string(arq_data,"Authorization",var_aux,' ','"') == 1)
32 valor_string(arq_data,"username=",sip_username,',','"');
33 fclose(arq_data);
35 };
Inicialmente a funo dados_esc varre os arquivos capturados buscando os campos
caller, called e username. Depois de encontrados os valores dos campos, utilizada a funo
imprime_pkt para imprimir na tela os pacotes capturados na seo Escuta.
Na Tabela 51 iniciado o processo de gravao dos dados dos campos no arquivo de
armazenamento dos campos SIP. Pode-se observar tambm a gravao de uma informao na
varivel password que visa informar o operador que a senha no pode ser detectada e est no
formato MD5. Os nmeros visualizados esquerda so apenas identificadores das linhas do
arquivo no fazendo parte do cdigo.
Tabela 51 - Gravao dos campos SIP no arquivo.
37 sprintf(sip_password,"MD5");
38
39 camp_data = fopen(arq_data_nome,"r+");
40 if (camp_data == NULL)
41 camp_data = fopen(arq_data_nome,"w");
116

42 if (valor_string(camp_data,"CALLER_ORIG=",sip_caller,'\n','\0') == 0) {
44 fprintf(camp_data,"CALLER_ORIG=%s\n",sip_caller);
45 }
46 if (valor_string(camp_data,"CALLED_ORIG=",sip_called,'\n','\0') == 0) {
48 fprintf(camp_data,"CALLED_ORIG=%s\n",sip_called);
49 }
50 if (valor_string(camp_data,"USERNAME_ORIG=",sip_username,'\n','\0') == 0) {
52 fprintf(camp_data,"USERNAME_ORIG=%s\n",sip_username);
53 }
54 if (valor_string(camp_data,"CALLER=",sip_callern,'\n','\0') == 0) {
56 fprintf(camp_data,"CALLER=%s\n",sip_caller);
57 memcpy(sip_callern,sip_caller,sizeof(char)*50);
58 }
59 if (valor_string(camp_data,"CALLED=",sip_calledn,'\n','\0') == 0) {
61 fprintf(camp_data,"CALLED=%s\n",sip_called);
62 memcpy(sip_calledn,sip_called,sizeof(char)*50);
63 }
64 if (valor_string(camp_data,"USERNAME=",sip_usernamen,'\n','\0') == 0) {
66 fprintf(camp_data,"USERNAME=%s\n",sip_username);
67 memcpy(sip_usernamen,sip_username,sizeof(char)*50);
68 }
69 valor_string(camp_data,"PASSWORD=",sip_passwordn,'\n','\0');
70
Na Tabela 52 impresso o menu de seleo do campo SIP a ser alterado e aguardada
a entrada de teclado pelo operador informando qual campo ser acessado para efetuar a
alterao. O retorno da funo dados_esc processado pela funo dados_esc_menu
observada na Tabela 49. Os nmeros observados esquerda esto apenas identificando as
linhas do arquivo no fazendo parte do cdigo.
Tabela 52 - Impresso do menu de acesso aos campos SIP.
73 printf("\n\n\t CAMPO\t\tESCUTA\t\tINJEO\n\n");
74 printf("\t1 - Caller\t\t%s \t%s\n",sip_caller,sip_callern);
75 printf("\t2 - Called\t\t%s \t%s\n",sip_called,sip_calledn);
76 printf("\t3 - Username\t\t%s \t%s\n",sip_username,sip_usernamen);
77 printf("\t4 - Password\t\t%s \t%s\n",sip_password,sip_passwordn);
78 printf("\n\n\tEscolha o campo que deseja alterar ou 'q' para voltar: ");
79 __fpurge(stdin);
80 opt = getchar();
81 return(opt);
82 }
3.4.11 Controle de Injeo
Superficialmente, o controle de injeo responsvel por injetar os pacotes com as
alteraes efetuadas pelo operador, fazer a captura dos pacotes resposta dos pacotes injetados,
e fazer a sincronia desse dilogo entre o analisador e o servidor SIP.
117

O processo inicia sob o comando do operador. O operador pode decidir por iniciar o
processo de injeo ou voltar para o menu principal. A Tabela 53 mostra o desenvolvimento
da funo que controla a interface com o operador. Os nmeros observados esquerda so
apenas identificadores das linhas do arquivo, no fazendo parte do cdigo.
Tabela 53 - Controle interface operador seo "Injeo".
446 int injecao()
447 {
448 char opt;
449
450 do {
451 opt = menu_3();
452 switch(opt) {
453 case '1':
454 pthread_create (&injThread, 0, inj,0);
455 pthread_create (&caninjThread, 0, caninj,0);
456 pthread_join (injThread, 0);
457 pthread_join (caninjThread, 0);
458 opt = 'q';
459 break;
460 }
461 } while (opt != 'q');
463 return(0);
464 }
Se o operador optar por iniciar o processo de injeo, duas threads so criadas.
Semelhantes ao processo de captura da seo Escuta, essas threads so necessrias para que
o operador consiga parar o processo de injeo utilizando uma entrada de teclado. Enquanto
uma thread responsvel pelo controle da injeo e captura dos pacotes, a outra thread
responsvel pela leitura de teclado que define se o processo deve ou no continuar. A Tabela
54 mostra o desenvolvimento dessas duas threads.
Tabela 54 - Desenvolvimento das threads de controle de injeo e captura.
426 void* inj (void* info)
427 {
428 injeta();
430 }
431
432 void* caninj (void* info)
433 {
434 char ch;
435
436 do {
437 rl_ttyset(0);
438 ch = getchar();
439 rl_ttyset(1);
440 } while (ch != 'q');
442 pthread_cancel(injThread);
444 }
A thread inj inicia o processo de injeo e captura executando a funo injeta.
Resumidamente, a funo injeta formada por um lao do while que s finaliza
quando a flag fim setada, sendo esta setada pelo prprio processo. Dentro deste lao, o
118

processo inicia verificando os pacotes salvos pela seo Escuta. O arquivo em questo
duplicado e salvo com o padro de nomenclatura dos arquivos da seo Injeo. Essa
duplicao visa manter o arquivo de captura original salvo para a posterior comparao dos
dados capturados na seo Escuta com os injetados e capturados na seo Injeo.
Cada arquivo de pacote aberto e o endereo IP de origem verificado. atravs da
comparao do endereo de origem salvo no arquivo com o endereo armazenado na varivel
ip_orig que o processo sabe se o pacote em questo deve ser injetado ou capturado. De acordo
com essa comparao ou iniciado o processo de captura ou o processo de injeo.
Dentro do processo de injeo, so feitas as alteraes no arquivo de captura de
acordo com as alteraes efetuadas pelo operador nos campos SIP. Depois disso o pacote
criado e injetado. Dentro do processo de captura efetuada a captura dos pacotes na interface
de acordo com um filtro criado. Dessa forma o processo repetido at que os pacotes
capturados na seo Escuta se esgotem ou at que a resposta do servidor SIP a uma
requisio enviada atravs da seo Injeo seja diferente da capturada na seo Escuta.
A Tabela 55 mostra o incio do desenvolvimento da funo injeta. Nesta parte do
desenvolvimento so declaradas todas as variveis utilizadas pela funo.
Tabela 55 - Declarao das variveis na funo injeta.
84 int injeta()
85 {
86 struct sniff_ethernet *ether_inj;
87 struct sniff_ip *ip_inj;
88 struct sniff_udp *udp_inj;
89 struct pseudo_header *pseudo_inj;
90 char *payload_inj;
91
92 u_char *packet;
93 int packet_size;
94
95 int sentbytes,i,j,l,m,sai;
96 char mac_add[3],mac_src[20],mac_dst[20],ch;
97
98 u_short *pack_ip,*pseudo;
99 char udp_len;
100 char pseudo_zero;
101 char pad_byte;
102
103 char *ip_vhl,*ip_tos,*ip_id,*ip_ttl,*ip_off,*ip_p,*ip_src,*ip_dst;
104 char *udp_src,*udp_dst;
105
107 char var_aux[10];
108 fpos_t posit;
109
110 char sip_tag_1[30];
111 char sip_tag_2[30];
112 char sip_tag_aux[30];
113 char sip_caller_1[30];
114 char sip_caller_2[30];
115 char sip_called_1[30];
116 char sip_called_2[30];
117 char sip_username_1[30];
118 char sip_username_2[30];
119
119

120 /* MD5 ... */
121 md5_state_t state;
122 md5_byte_t digest[16];
123 char hex_output[16*2 + 1];
124 char md5_atual[16*2 + 1];
125 char nonce_atual[16*2 + 1];
126 int di;
127
128 char sip_user[100];
129 char sip_realm[100];
130 //char sip_passwd[100];
131 char sip_nonce[100];
132 char sip_uri[100];
133
134 char A1[200];
135 char A2[200];
136 char A3[200];
137 char md5_1[16*2 + 1];
138 char md5_2[16*2 + 1];
139
140 char *acha_var, *troca_por;
Depois de declaradas as variveis, a funo inicia a alocao de memria para os
ponteiros, posiciona o incio da injeo no pacote 01 como pode ser observado na linha 158
da Tabela 56. Os nmeros observados esquerda so apenas identificadores das linhas do
Tabela 56 - Alocao de memria das variveis.
142 printf("\n\n\tPKT IP SRC\t\t\t\t\tIP DST\t\t\tSIP\n\n");
143
144 pathcap=(char *)malloc(sizeof(char)*50);
145 pathcap_aux=(char *)malloc(sizeof(char)*50);
146
147 ip_vhl=(char *)malloc(sizeof(char)*2);
148 ip_tos=(char *)malloc(sizeof(char)*2);
149 ip_id=(char *)malloc(sizeof(char)*4);
150 ip_off=(char *)malloc(sizeof(char)*4);
151 ip_ttl=(char *)malloc(sizeof(char)*2);
152 ip_p=(char *)malloc(sizeof(char)*2);
153 ip_src=(char *)malloc(sizeof(char)*22);
154 ip_dst=(char *)malloc(sizeof(char)*22);
155 udp_src=(char *)malloc(sizeof(char)*4);
156 udp_dst=(char *)malloc(sizeof(char)*4);
157
159 fim = 0;
A Tabela 57 mostra o incio do processo de injeo e captura onde realizada a
comparao entre o endereo IP de origem armazenado no arquivo com o endereo IP do
dispositivo armazenado na varivel ip_orig (linha 170). Atravs desta comparao possvel
saber se o pacote originou do dispositivo monitorado ou do servidor SIP. Pode-se observar
tambm a duplicao do arquivo do pacote armazenado (linhas 171 a 181) para que as
alteraes no sejam efetuadas no arquivo original. Depois da duplicao do arquivo
iniciado o processo de alterao do arquivo duplicado (linhas 182 a 193) de acordo com as
alteraes sugeridas pelo operador. Os nmeros visualizados esquerda so apenas
identificadores das linhas do arquivo, no fazendo parte do cdigo.
120

Tabela 57 - Incio do processo de injeo e captura.
161 do {
162 if (*arq_res_cnt < 10)
163 sprintf(pathcap,"%s0%d.cap",arq_cap_nome,*arq_res_cnt);
164 else
165 sprintf(pathcap,"%s%d.cap",arq_cap_nome,*arq_res_cnt);
166 if ((cap_file = fopen(pathcap,"r"))) {
167 memset(ip_src,'\0',sizeof(char)*20);
168 valor_string(cap_file,"IP_SRC=",ip_src,'\n','\0');
169 fclose(cap_file);
170 if (strcmp(ip_src,ip_orig) == 0) {
171 memset((char *)comando,'\0',sizeof(char)*100);
172 if (*arq_res_cnt < 10) {
173 sprintf(comando,"cp -f %s
%s0%d.cap",pathcap,arq_res_nome,*arq_res_cnt);
174 memset(pathcap,'\0',sizeof(char)*50);
175
sprintf(pathcap,"%s0%d.cap",arq_res_nome,*arq_res_cnt);
176 } else {
177 sprintf(comando,"cp -f %s
%s%d.cap",pathcap,arq_res_nome,*arq_res_cnt);
178 memset(pathcap,'\0',sizeof(char)*50);
179
sprintf(pathcap,"%s%d.cap",arq_res_nome,*arq_res_cnt);
180 }
182 sprintf(sip_caller_1,"sip:%s@",sip_caller);
183 sprintf(sip_caller_2,"sip:%s@",sip_callern);
184 sprintf(sip_called_1,"sip:%s@",sip_called);
185 sprintf(sip_called_2,"sip:%s@",sip_calledn);
186 sprintf(sip_username_1,"username=\"%s\"",sip_username);
187 sprintf(sip_username_2,"username=\"%s\"",sip_usernamen);
188 if (strcmp(sip_caller_1,sip_caller_2) != 0)
189 troca_string(pathcap,sip_caller_1,sip_caller_2);
190 if (strcmp(sip_called_1,sip_called_2) != 0)
191 troca_string(pathcap,sip_called_1,sip_called_2);
192 if (strcmp(sip_username_1,sip_username_2) != 0)
193
troca_string(pathcap,sip_username_1,sip_username_2);
Na Tabela 58 inicia-se o processo de autenticao do SIP. Depois de efetuadas as
alteraes no pacote duplicado, faz-se uma verificao no pacote a ser injetado para saber se
existem dados referentes a autenticao. Se os dados da autenticao existirem no pacote que
est sendo injetado, so verificados os pacotes anteriores para extrair os dados da requisio
de autenticao. A requisio de autenticao caracterizada pelo campo WWW-Authenticate
no pacote recebido do servidor. Nas linhas 226 a 234 efetuada a leitura dos dados enviados
pelo servidor para compor a hash
21
MD5 utilizada na autenticao SIP. Como j mencionado,
so utilizados os dados realm, nonce, username e uri na composio da chave de autenticao
do SIP. Depois do processo de leitura dos dados, efetuada a gerao da chave com o auxlio
das funes do arquivo md5.c. Depois de gerada a chave, os dados so includos no pacote
que est sendo injetado com o uso da funo troca_string como pode ser observado nas linhas
270 a 277. Os nmeros visualizados esquerda so apenas identificadores das linhas do

21
Uma hash pode ser definida como uma sequncia de bits gerada por um algoritmo (WALL, WATSON e
WHITIS, 1999).
121

Tabela 58 - Autenticao do SIP.
216 cap_file = fopen(pathcap,"r");
217 if (valor_string(cap_file,"Authorization",var_aux,' ','\0') == 1) {
218 h = *arq_res_cnt - 2;
219 memset(pathcap_aux,'\0',sizeof(char)*50);
220 if (h < 10)
221 sprintf(pathcap_aux,"%s0%d.cap",arq_res_nome,h);
222 else
223 sprintf(pathcap_aux,"%s%d.cap",arq_res_nome,h);
224 if ((cap_file_ant = fopen(pathcap_aux,"r"))) {
225 if (valor_string(cap_file_ant,"WWW-
Authenticate",var_aux,' ','"') == 1) {
226
valor_string(cap_file_ant,"realm=",sip_realm,',','"');
227
valor_string(cap_file_ant,"nonce=",sip_nonce,'\r','"');
228 }
229 fclose(cap_file_ant);
230 }
231 valor_string(cap_file,"username=",sip_user,',','"');
232 valor_string(cap_file,"uri=",sip_uri,',','"');
233 valor_string(cap_file,"response=",md5_atual,',','"');
234 valor_string(cap_file,"nonce=",nonce_atual,',','"');
235
236 strcat(A1,sip_user);
237 strcat(A1,":");
238 strcat(A1,sip_realm);
239 strcat(A1,":");
240 strcat(A1,sip_passwordn);
241
242 strcat(A2,"INVITE");
243 strcat(A2,":");
244 strcat(A2,sip_uri);
245
246 md5_init(&state);
247 md5_append(&state, (const md5_byte_t *)A1, strlen(A1));
248 md5_finish(&state, digest);
249 for (di = 0; di < 16; ++di)
250 sprintf(md5_1 + di * 2, "%02x", digest[di]);
254 for (di = 0; di < 16; ++di)
255 sprintf(md5_2 + di * 2, "%02x", digest[di]);
256
257 strcat(A3,md5_1);
258 strcat(A3,":");
259 strcat(A3,sip_nonce);
260 strcat(A3,":");
261 strcat(A3,md5_2);
262
266 for (di = 0; di < 16; ++di)
267 sprintf(hex_output + di * 2, "%02x", digest[di]);
269
270 acha_var = (char *)malloc(sizeof(char)*100);
271 troca_por = (char *)malloc(sizeof(char)*100);
272 sprintf(acha_var,"response=\"%s\"",md5_atual);
273 sprintf(troca_por,"response=\"%s\"",hex_output);
274 troca_string(pathcap,acha_var,troca_por);
275 sprintf(acha_var,"nonce=\"%s\"",nonce_atual);
276 sprintf(troca_por,"nonce=\"%s\"",sip_nonce);
277 troca_string(pathcap,acha_var,troca_por);
278 }
Depois do processo de autenticao, iniciado o processo de criao do pacote a
partir do pacote armazenado no arquivo. Todos os dados dos cabealhos so lidos juntamente
com o payload j com as alteraes dos campos SIP efetuadas.
122

Na Tabela 59 mostrado o processo de leitura dos endereos MAC de origem e
destino salvos no arquivo. Pode ser observada na linha 315 o uso da funo str2hex que
retorna o valor em formato hexadecimal da string lida do arquivo do pacote. Os nmeros
observados esquerda so apenas identificadores das linhas no fazendo parte do cdigo.
Tabela 59 - Leitura dos dados do cabealho Ethernet.
305 sai = 0;
306 j = 0;
307 m = 0;
308 l = 0;
309 do {
310 ch = mac_src[j++];
311 if ((ch != ':') && (ch != ';')) {
312 mac_add[m] = ch;
313 m++;
314 } else {
315 ether_inj->ether_shost[l++] = str2hex(mac_add);
316 m = 0;
317 memset((char *)mac_add,'\0',sizeof(char)*3);
318 if (ch == ';')
319 sai = 1;
320 }
321 } while(sai == 0);
322
323 sai = 0;
324 j = 0;
325 m = 0;
326 l = 0;
327 do {
328 ch = mac_dst[j++];
329 if ((ch != ':') && (ch != ';')) {
330 mac_add[m] = ch;
331 m++;
332 } else {
333 ether_inj->ether_dhost[l++] = str2hex(mac_add);
334 m = 0;
335 if (ch == ';')
336 sai = 1;
337 }
338 } while(sai == 0);
Segue o processo de leitura e criao do pacote na Tabela 60, nas linhas 342 a 350
so lidos os dados do cabealho IP e UDP e nas linhas 352 a 364 esses dados so carregados
na estrutura de dados do pacote. Os nmeros visualizados esquerda so apenas
identificadores das linhas do arquivo no fazendo parte do cdigo.
Tabela 60 - Leitura dos dados e criao dos cabealhos IP e UDP.
342 valor_string(cap_file,"IP_VER=",ip_vhl,'\n','\0');
343 valor_string(cap_file,"IP_ID=",ip_id,'\n','\0');
344 valor_string(cap_file,"IP_TTL=",ip_ttl,'\n','\0');
345 valor_string(cap_file,"IP_OFF=",ip_off,'\n','\0');
346 valor_string(cap_file,"IP_PROTO=",ip_p,'\n','\0');
347 valor_string(cap_file,"IP_SRC=",ip_src,'\n','\0');
348 valor_string(cap_file,"IP_DST=",ip_dst,'\n','\0');
349 valor_string(cap_file,"UDP_SRC=",udp_src,'\n','\0');
350 valor_string(cap_file,"UDP_DST=",udp_dst,'\n','\0');
351
353 ip_inj->ip_vhl= atoi(ip_vhl);
354 ip_inj->ip_id = htons(atoi(ip_id));
355 ip_inj->ip_ttl = atoi(ip_ttl);
356 ip_inj->ip_off = atoi(ip_off);
357 ip_inj->ip_p = atoi(ip_p);
358 ip_inj->ip_len = htons(sizeof(struct sniff_ip) + sizeof(struct
sniff_udp) + i);
123

359 inet_aton(ip_src,&ip_inj->ip_src);
360 inet_aton(ip_dst,&ip_inj->ip_dst);
361 udp_inj->uh_sport = htons(atoi(udp_src));
362 udp_inj->uh_dport = htons(atoi(udp_dst));
363 udp_inj->uh_ulen = htons(sizeof(struct sniff_udp) + i);
364 udp_len = sizeof(struct sniff_udp);
Depois de criado o pacote, o momento de gerar os checksums IP e UDP. Como j
mencionado, para a gerao do checksum IP necessrio apenas o cabealho IP mas para a
gerao do checksum UDP necessrio a utilizao de uma estrutura denominada psudo-
header.
A Tabela 61 mostra o desenvolvimento do processo de gerao dos checksums IP e
UDP. O checksum IP gerado nas linhas 367 e 368 utilizando apenas a estrutura do prprio
cabealho IP. A formao do pseudo-header inicia na linha 371 e termina na linha 376 onde
so includos todos os dados necessrios para a gerao do checksum UDP. Depois disso
efetuada a gerao do checksum nas linhas 377 a 382. Os nmeros observados esquerda so
apenas identificadores das linhas do arquivo no fazendo parte do cdigo.
Tabela 61 - Gerao dos checksums IP e UDP.
367 memcpy(pack_ip,(u_char *)ip_inj,sizeof(struct sniff_ip));
368 ip_inj->ip_sum = checksum(pack_ip, sizeof(struct sniff_ip));
369
370 //formao do pseudo header p/ calculo do checksum udp
371 pad_byte = 0x00;
372 memcpy(&pseudo_inj->ip_src,&ip_inj->ip_src,sizeof(u_short)*2);
373 memcpy(&pseudo_inj->ip_dst,&ip_inj->ip_dst,sizeof(u_short)*2);
374 pseudo_inj->proto = ip_inj->ip_p;
375 pseudo_inj->zero1 = 0;
376 pseudo_inj->udp_len = udp_inj->uh_ulen;
377 memcpy(pseudo+6,(u_char *)udp_inj,8);
378 memcpy(pseudo+10,payload_inj,i);
379 if (((sizeof(struct pseudo_header)+sizeof(struct sniff_udp)+i) % 2) !=
0) {
380 memcpy(pseudo+10+i,&pad_byte,sizeof(char));
381 udp_inj->uh_sum = checksum(pseudo,sizeof(struct
pseudo_header)+sizeof(struct sniff_udp)+i+1);
382 } else
383 udp_inj->uh_sum = checksum(pseudo,sizeof(struct
pseudo_header)+sizeof(struct sniff_udp)+i);
Aps a criao do pacote e da gerao dos checksums, o pacote impresso na tela do
operador e de fato injetado. Na Tabela 62 podem ser observados os processos de impresso e
injeo. Os nmeros observados esquerda so apenas identificadores das linhas do arquivo e
no fazem parte do cdigo.
Tabela 62 - Impresso do pacote e injeo.
392 imprime_pkt(pathcap);
393 handle_inj = pcap_open_live(dev,BUFSIZ,1,0,errbuf_inj);
394 sentbytes=pcap_inject(handle_inj,packet,packet_size);
395 *arq_res_cnt = *arq_res_cnt + 1;
No caso da comparao entre o endereo de origem IP armazenado no arquivo com o
endereo aramazenado na varivel ip_orig comprovar a diferena entre esses valores,
124

iniciado o processo de captura atravs da funo func_escuta. Essa funo desenvolvida na
Tabela 63. Ela inicia declarando as variveis necessrias para o processo, depois criado o
filtro a ser aplicado na captura, a sesso de captura e por ltimo so criadas as threads de
captura. Depois de efetuada a captura, a tarefa seguinte a comparao entre o mtodo SIP da
captura efetuada nesta seo com a captura na seo Escuta, caso os mtodos sejam
diferentes, o processo de captura e injeo paralizado.
Tabela 63 - Desenvolvimento da funo func_escuta.
39 void func_escuta()
40 {
41 struct bpf_program fp;
42 char filter_exp[100];
43
44 bpf_u_int32 mask;
45 bpf_u_int32 net;
46
47 sprintf(filter_exp,"host %s and (udp src port %s or udp dst port
%s)",ip_orig,porta_dst,porta_dst);
48 pcap_lookupnet(dev, &net, &mask, errbuf_inj);
49 handle_inj = pcap_open_live(dev,BUFSIZ,1,0,errbuf_inj);
50 pcap_setnonblock(handle_inj,0,errbuf_inj);
//seta porta para no nonblock
51 pcap_compile(handle_inj, &fp, filter_exp, 0, net); //monta
filtro
52 pcap_setfilter(handle_inj, &fp);
//seta filtro
53
54 arq_pcap_nome = arq_res_nome;
55 arq_pcap_cnt = arq_res_cnt;
56
58 pthread_create (&captThread, 0, capt,0);
59 pthread_create (&kbdThread, 0, kbd,0);
60 pthread_join (captThread, 0);
61 pthread_join (kbdThread, 0);
62
63 pcap_close(handle_inj);
64
65 //comparar o metodo SIP
66 h = *arq_res_cnt - 1;
67 if (h < 10) {
68 sprintf(pathcap,"%s0%d.cap",arq_cap_nome,h);
69 sprintf(pathcap_aux,"%s0%d.cap",arq_res_nome,h);
70 } else {
71 sprintf(pathcap,"%s%d.cap",arq_cap_nome,h);
72 sprintf(pathcap_aux,"%s%d.cap",arq_res_nome,h);
73 }
74 cap_file = fopen(pathcap,"r");
75 metodo_sip(cap_file,sip_metodo_cap_1);
77 cap_file = fopen(pathcap_aux,"r");
78 metodo_sip(cap_file,sip_metodo_cap_2);
80 if (strcmp(sip_metodo_cap_1,sip_metodo_cap_2) != 0)
81 fim = 1;
82 }
Semelhante ao processo de captura onde a paralizao do processo pode ser feita
pelo operador, a captura da seo Injeo paralizada pelo prprio processo de captura do
pacote. Dentro da funo callback setada a varivel stop_thread para 1, o lao do while da
funo kbd no continua sendo executado e o comando pthread_cancel paraliza a thread de
captura capt. O desenvolvimento das threads de captura pode ser observado na Tabela 64, os
125

nmeros visualizados esquerda so apenas identificadores das linhas e no fazem parte do
cdigo.
Tabela 64 - Desenvolvimento das threads de captura.
22 void* capt (void* info)
23 {
24 do {
25 pcap_dispatch(handle_inj,1,callback,NULL);
26 } while (*stop_thread == 0);
28 }
29
30 void* kbd (void* info)
31 {
32 do {
33 } while (*stop_thread == 0);
34 pthread_cancel(captThread);
35
37 }
126

4 VALIDAO DA FERRAMENTA
Para a validao da ferramenta desenvolvida foram definidos dois diferentes testes:
- Verificao dos dados capturados na da seo Escuta;
- Verificao dos dados injetados e capturados na seo Injeo.
Ambos os testes executados utilizam as ferramentas Wireshark, Asterisk e eyeBeam
como apoio.
4.1 TOPOLOGIA UTILIZADA NA VALIDAO
Para a validao da ferramenta foi adotada uma topologia fsica e lgica de rede, de
forma a permitir que a troca de informaes entre o dispositivo monitorado e o servidor de
comunicao Asterisk, fique a disposio do software desenvolvido e da ferramenta de apoio.
Na Figura 53 pode ser observada a topologia utilizada.

Figura 53 - Topologia utilizada na validao da ferramenta desenvolvida.
127

A utilizao do HUB como concentrador de rede se d pela caracterstica dele no
segmentar a rede em um domnio de coliso por porta, o domnio de coliso o mesmo para
toda a rede. Devido a esta caracterstica, qualquer dado que esteja passando por este
dispositivo visvel a toda a rede, permitindo a sua captura (TANENBAUM, 2003).
4.2 OBJETIVOS EM CADA TESTE
Diferentes caractersticas so analisadas em cada teste, visto que um dos testes valida
apenas a funo de captura da ferramenta enquanto o outro valida as funes de captura e
injeo em conjunto.
4.2.1 Teste de Validao de Captura
No teste de validao de captura efetuada na seo Escuta, o objetivo verificar se
a ferramenta capaz de capturar todos os dados da interoperabilidade do SIP entre o
dispositivo monitorado e o servidor Asterisk e se os dados capturados e armazenados so
ntegros. Assume-se para este teste que o trfego total da interoperabilidade do SIP o trfego
capturado e mostrado pela ferramenta Wireshark, que os pacotes capturados e mostrados pelo
Wireshark so ntegros e possuem uma construo correta, e portanto, a integridade dos dados
capturados obtida atravs da comparao entre os dados capturados pelo software
desenvolvido e os dados capturados pela ferramenta Wireshark.
4.2.2 Teste de Validao de Captura e Injeo
No teste de validao de captura e injeo efetuados na seo Injeo, o objetivo
verificar se a ferramenta capaz de capturar todos os dados da interoperabilidade do SIP entre
o dispositivo monitorado e o servidor Asterisk, se os dados capturados e armazenados esto
128

ntegros, se a construo dos pacotes est sendo feita de forma correta e se capaz de
sincronizar a injeo e a captura dos pacotes de forma a permitir que a interoperabilidade do
SIP seja entre a ferramenta desenvolvida e o servidor Asterisk. Assume-se para este teste que
o trfego total da interoperabilidade do SIP o trfego capturado e mostrado pela ferramenta
Wireshark, que os pacotes capturados e mostrados pelo Wireshark so ntegros e possuem
uma construo correta, e portanto a integridade dos dados capturados obtida atravs da
comparao entre os dados capturados pelo software desenvolvido e os dados capturados pela
ferramenta Wireshark, e que o relatrio de interoperabilidade do SIP disponibilizado pelo
Wireshark seja o que est realmente acontecendo entre os dispositivos em questo.
129

5 RESULTADOS E CONCLUSES
Neste captulo so mostrados os resultados dos testes efetuados para a validao da
ferramenta juntamente com a concluso a respeito da proposta.
5.1 RESULTADOS OBTIDOS DO TESTE DE CAPTURA
Este teste visa verificar se todos os pacotes da interoperabilidade do SIP entre os
dispositivos foram capturados pelo software desenvolvido na seo Escuta e se os dados
capturados e armazenados so ntegros. Para que o teste seja realizado gerado um evendo,
neste evento o dispositivo SIP de identificao 200 tenta estabelecer uma sesso multimdia
com o usurio 300 que no est autenticado no servidor no momento da tentativa.
Na Figura 54 pode-se visualizar a seo Dados Escutados que mostra todos os
pacotes capturados juntamente com os valores dos campos SIP detectados. So visualizados
sete pacotes capturados, pode-se verificar a deteco dos campos na coluna ESCUTA. O
usurio que tentou efetuar o estabelecimento da sesso multimdia identificado como 200, e o
usurio o qual foi convidado para sesso multimdia identificado como 300. Pode-se verificar
tambm o username utilizado na autenticao do usurio 200 que o prprio nmero do
usurio. A password como j mencionado, no possvel detectar na captura dos pacotes.
130

Figura 54 - Seo "Dados Escutados".
J na Figura 55 pode-se verificar os dados capturados pelo Wireshark. Podem ser
visualizados tambm sete pacotes capturados. Se comparados aos capturados pelo software
desenvolvido, pode-se afirmar que todos os pacotes foram capturados com sucesso.

Figura 55 - Pacotes capturados pelo Wireshark.
Na Tabela 65 pode-se observar o pacote 01 capturado pelo software desenvolvido
enquanto na Figura 56 pode-se observar o mesmo pacote capturado pelo Wireshark. Constata-
se atravs dessas duas imagens, a integridade dos dados capturados pelo software
desenvolvido uma vez que todos os campos dos cabealhos foram identificados e
armazenados de maneira correta.
Tabela 65 - Pacote 01 capturado pelo software desenvolvido.
1 ARQ_NUM=01
2
3 ETHER_MAC_SRC=0:C:29:68:26:3A;
4 ETHER_MAC_DST=0:C:29:41:58:95;
5 ETHER_TYPE=8
6
131

7 IP_VER=69
8 IP_TOS=0
9 IP_LEN=746
10 IP_ID=1374
11 IP_OFF=0
12 IP_TTL=128
13 IP_PROTO=17
14 IP_CHK=28497
15 IP_SRC=192.168.33.2
16 IP_DST=192.168.33.1
17
18 UDP_SRC=8304
19 UDP_DST=5060
20 UDP_LEN=726
21 UDP_CHK=12546
22
23 INVITE sip:300@192.168.33.1 SIP/2.0
24 To: <sip:300@192.168.33.1>
25 From: TCC 200<sip:200@192.168.33.1>;tag=66064d22
26 Via: SIP/2.0/UDP 192.168.33.2:8304;branch=z9hG4bK-d87543-127761736-1--d87543-;rport
27 Call-ID: 4c15ae004b318627
28 CSeq: 1 INVITE
29 Contact: <sip:200@192.168.33.2:8304>
30 Max-Forwards: 70
31 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO
32 Content-Type: application/sdp
33 User-Agent: eyeBeam release 3004w stamp 16863
35
36 v=0
37 o=- 56250259 56250343 IN IP4 192.168.33.2
38 s=eyeBeam
39 c=IN IP4 192.168.33.2
40 t=0 0
41 m=audio 8306 RTP/AVP 0 8 18 101
42 a=alt:1 1 : DCFAF33A 4E58F998 192.168.33.2 8306
43 a=fmtp:101 0-15
44 a=rtpmap:101 telephone-event/8000
45 a=sendrecv

Figura 56 - Pacote 01 capturado pelo Wireshark.
132

5.2 RESULTADOS OBTIDOS DO TESTE DE CAPTURA E INJEO
Este teste visa verificar se todos os pacotes da interoperabilidade do SIP entre os
dispositivos foram capturados pelo software desenvolvido na seo Injeo. Neste teste o
dispositivo SIP de identificao 200 tenta estabelecer uma sesso multimdia com o usurio
300 que no est autenticado no servidor no momento da tentativa. Porm, a injeo ser
efetuada alterando a identificao do usurio convidado para 500.
A Figura 57 mostra a seo Dados Escutados com todos os pacotes capturados na
seo Escuta e com os campos do SIP detectados. Nota-se que o usurio convidado para a
sesso multimdia detectado na Escuta diferente do que ser utilizado na Injeo. No
caso, o operador efetuou a alterao desse campo do SIP alm de incluir a password do
usurio 200 que quem est tentando estabelecer a sesso multimdia. Essa senha foi
mencionada anteriormente na configurao do Asterisk que utilizado como ferramenta de
apoio para este teste. A senha deve ser includa para que ocorra a autenticao do usurio SIP
uma vez que no possvel detectar a senha na captura dos pacotes e a chave criptografada
varia em cada nova sesso multimdia a ser estabelecida.

Figura 57 - Seo "Dados Escutados".
A Figura 58 mostra a seo Injeo e os pacotes que foram capturados e injetados.
133

Figura 58 - Seo "Injeo".
Na Figura 59 pode-se verificar a seo Mostrar Resultados onde visualizam-se os
pacotes da seo Escuta e da seo Injeo.

Figura 59 - Seo "Mostrar Resultados".
Na Figura 60 pode-se visualizar os pacotes capturados pelo Wireshark.
134

Figura 60 - Pacotes capturados pelo Wireshark.
Nota-se que os pacotes capturados pelo Wireshark no coincidem com os capturados
e/ou injetados pelo software. Pode-se perceber primeiramente no Wireshark, que o servidor
enviou dois pacotes resposta com o status 401 Unauthorized que significa a solicitao da
autenticao. No analisador, apenas um pacote com o status 401 Unauthorized pode ser
visualizado. Com base nessa comparao, pode-se afirmar que o analisador no capturou um
dos pacotes. Ao final do fluxo de mensagens, no Wireshark podem ser observados vrios
pacotes com o status 404 Not Found enquanto no analisador apenas um pacote com as
mesmas caractersticas pode ser observado. Nesse caso, o analisador parou a captura pois a
resposta contida no pacote de sequncia cinco capturado na seo Injeo difere da resposta
contida no pacote de sequncia cinco capturado na seo Escuta, portanto trata-se de uma
situao prevista no software.
No se pode afirmar de fato o que est ocorrendo, mas pode-se afirmar que a
ferramenta consegue gerenciar o sincronismo entre os pacotes enviados e recebidos. Nota-se
que ocorre praticamente da mesma maneira a interoperabilidade entre os dispositivos. Em
uma anlise superficial do problema, possvel verificar que o software est perdendo um
pacote no momento da captura na seo Injeo pelo fato de estar no momento processando
o pacote a ser injetado. Esta situao poderia a vir ocorrer uma vez que o analisador possui
todos os pacotes a serem injetados armazenados em um disco rgido cujo acesso pode
demandar mais tempo do que a prpria resposta do servidor SIP.
A Tabela 66 mostra o pacote 02 capturado pelo software desenvolvido.
Tabela 66 - Pacote 02 capturado pelo software.
1 ARQ_NUM=02
2
3 ETHER_MAC_SRC=0:C:29:41:58:95;
4 ETHER_MAC_DST=0:C:29:68:26:3A;
5 ETHER_TYPE=8
6
7 IP_VER=69
8 IP_TOS=0
9 IP_LEN=532
135

10 IP_ID=62754
11 IP_OFF=0
12 IP_TTL=64
13 IP_PROTO=17
14 IP_CHK=49250
15 IP_SRC=192.168.33.1
16 IP_DST=192.168.33.2
17
18 UDP_SRC=5060
19 UDP_DST=8304
20 UDP_LEN=512
21 UDP_CHK=28863
22
23 SIP/2.0 401 Unauthorized
24 Via: SIP/2.0/UDP 192.168.33.2:8304;branch=z9hG4bK-d87543-127761736-1--d87543-
;received=192.168.33.2;rport=8304
25 From: TCC 200<sip:200@192.168.33.1>;tag=66064d22
26 To: <sip:300@192.168.33.1>;tag=as054b9133
27 Call-ID: 4c15ae004b318627
28 CSeq: 1 INVITE
29 Server: Asterisk PBX 1.6.2.11
30 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
31 Supported: replaces, timer
32 WWW-Authenticate: Digest algorithm=MD5, realm="asterisk", nonce="5255188f"
A Figura 61 mostra o pacote 02 capturado pelo Wireshark.

Figura 61 - Pacote 02 capturado pelo Wireshark.
Analisando os dados dos pacotes capturados, pode-se afirmar que o pacote capturado
e armazenado pelo software desenvolvido est ntegro.
136

5.3 CONCLUSO
O trabalho apresentou como proposta o desenvolvimento de um analisador SIP capaz
de efetuar a captura, alterao e injeo dos pacotes relacionados a interoperabilidade do SIP
de forma a proporcionar uma anlise a respeito da interoperabilidade que ocorre entre os
dispositivos SIP. As principais tarefas determinadas para o desenvolvimento foram concludas
com sucesso, alguns problemas foram detectados mas sero tratados no aperfeioamento da
ferramenta.
Dentre as informaes contidas neste trabalho pode-se destacar:
a) Detalhamento da captura e de um pacote da rede de dados;
b) Detalhamento dos campos dos cabealhos, Ethernet, IP e UDP;
c) Detalhamento do clculo do checksum IP e do checksum UDP;
d) Detalhamento da autenticao do protocolo SIP com uso de um algoritmo MD5;
e) Detalhamento da conformao de um pacote;
f) Detalhamento da injeo de um pacote na rede de dados.
Observando a quantidade de informaes, pode-se afirmar que o trabalho pode servir
como base de conhecimento para futuras implementaes na rea de redes digitais. Portanto, a
principal contribuio que fica alm do estmulo anlise do protocolo SIP, o conjunto de
informaes a respeito do tratamento de pacotes capturados e/ou injetados em uma rede de
dados. Tambm fica como contribuio uma ferramenta que se aperfeioada, pode ser
utilizada como apoio na soluo de problemas relacionados a interoperabilidade do protocolo
SIP.
Do ponto de vista do cenrio de telecomunicaes nos dias de hoje, pode-se afirmar
que o tema aqui apresentado de grande importncia frente a unificao das redes de
comunicao e a expanso dos servios sobre essas redes. Este tema atual e possui bastante
valor agregado.
137

5.4 SUGESTO PARA TRABALHOS FUTUROS
As sugestes para trabalhos futuros seguem duas linhas de raciocnio. A primeira
est relacionada ao aperfeioamento da ferramenta criada, visando resolver os problemas
detectados e a sua qualidade em relao a interface com o operador. A segunda linha est
relacionada com a expanso da ferramenta para anlises no previstas neste projeto.
Conhecendo um pouco do protocolo estudado, pode-se afirmar que existem muitos caminhos
a serem seguidos neste sentido.
5.4.1 Aperfeioamento da Ferramenta
Percebidas as deficincias da ferramenta, pode-se afirmar que primeiramente devem
ser corrigidos alguns problemas detectados no processo de validao como a perda de alguns
pacotes na etapa captura, injeo e sincronismo. Talvez pelo fato de estar se trabalhando com
o dispositivo de armazenamento, o processo de leitura dos dados armazenados pode estar
demandando um tempo alto o que acaba comprometendo a agilidade da ferramenta. Portanto
uma das melhorias sugeridas seria uma anlise quanto ao desempenho da ferramenta.
Outra melhoria sugerida seria na linha de interface com o operador, visto que esto
disponveis hoje bibliotecas que auxiliam na criao de interface grfica para softwares
baseados em plataforma Linux, seria interessante criar uma interface mais amigvel com o
operador ao invs de utilizar apenas menus baseados em texto puro. Essa melhoria pode
ajudar a difundir o uso da ferramenta no caso da disponibilizao da mesma.
5.4.2 Continuidade da Proposta
Visto que apenas alguns campos do protocolo SIP foram disponibilizados para
alterao em apenas um mtodo, e sabendo da complexidade do protocolo, interessante
continuar a proposta no sentido de expandir a anlise do protocolo. Essa expanso se daria no
138

sentido de disponibilizar mais campos do SIP para serem alterados alm de disponibilizar a
anlise de outros mtodos do protocolo.

139

REFERNCIAS BIBLIOGRFICAS
ABZUG, M. T. MD5 Homepage (unofficial). UMBC, 1991. Disponivel em:
<http://userpages.umbc.edu/~mabzug1/cs/md5/md5.html>. Acesso em: 05 Junho 2011.
BALBINOT, R. Modelagem e Prototipagem de Sistemas de Voz Sobre IP com
Mecanismos de Trasmisso Robusta. Dissertao de Mestrado. [S.l.]: Faculdade de
Engenharia PUCRS, 2002.
CAMARILLO, G. SIP Demystified. [S.l.]: McGraw-Hill, 2002. ISBN 0-07-137340-3.
CARSTENS, T. Programming with pcap. TCPDump & LibPcap, 2002. Disponivel em:
<http://www.tcpdump.org/pcap.html>. Acesso em: 13 Abril 2011.
CASADO, M. Packet Capture With libpcap and other Low Level Network Tricks.
Washington State University - The School of Electrical Engineering and Computer
Science, 2001. Disponivel em: <http://eecs.wsu.edu/~sshaikot/docs/lbpcap/libpcap-
tutorial.pdf>. Acesso em: 14 Abril 2011.
CISCO. Voice Over IP, Per Call Bandwidth Comsuption. Cisco Systems, 2006. Disponivel
em:
<http://www.cisco.com/en/US/tech/tk652/tk698/technologies_tech_note09186a0080094ae2.s
html>. Acesso em: 22 Junho 2010.
COUNTERPATH. eyeBeam - Datasheet. CounterPath, 2011. Disponivel em:
<http://www.counterpath.com>. Acesso em: 7 Junho 2011.
CPLUSPLUS. cplusplus.com, 2011. Disponivel em: <http://www.cplusplus.com/>. Acesso
em: 10 Junho 2011.
DAVIDSON, J. VoIP Fundamentals. Traduo de Ricardo Balbinot. 2. ed. [S.l.]: Bookman,
2008. ISBN 978-85-7780-113-8.
ECLIPSE. Eclipse documentation - Helios. Eclipse, 2011. Disponivel em:
<http://help.eclipse.org/helios/index.jsp>. Acesso em: 7 Junho 2011.
GOLENIEWSKI, L. Telecommunications Essentials, Second Edition: The Complete
Global Source. 2. ed. [S.l.]: Addison Wesley Professional, 2006. ISBN 978-0-321-42761-8.
140

HALSALL, F. Computer Networking and the Internet. 5. ed. [S.l.]: Addison Wesley
Professional, 2005. ISBN 0-321-26358-8.
JACOBSON, V.; LERES, C.; MCCANNE, S. PCAP, C Library Functions. TCPDump &
LibPcap, 2003. Disponivel em: <http://www.tcpdump.org/pcap3_man.html>. Acesso em: 14
Novembro 2010.
JACOBSON, V.; LERES, C.; MCCANNE, S. Filtering expression syntax. Berkeley National
Laboratory - University of California, 2008. Disponivel em:
<http://www.manpagez.com/man/7/pcap-filter/>. Acesso em: 27 Maio 2011.
JOHNSTON, A. B. SIP: Understanding the Session Initiation Protocol. 3. ed. [S.l.]: Artech
House, 2009. ISBN 978-1-60783-995-8.
KRIVUTSENKO'S, A. Digest authorization in SIP with MD5. Persistent notes, 2006.
Disponivel em: <http://alexkr.com/memos/66/digest-authorization-in-sip-with-md5/>. Acesso
em: 23 Maio 2011.
LAMPING, U.; SHARPE, R.; WARNICKE, E. Wireshark User's Guide: for Wireshark 1.7.
Wireshark, 2011. Disponivel em: <http://www.wireshark.org>. Acesso em: 25 Maio 2011.
MADSEN, L.; MEGGELEN, J. V.; BRYANT, R. Asterisk: The Definitive Guide. 3. ed.
[S.l.]: OReilly Media, 2011.
MCGANN, S.; SICKER, D. C. An Analysis of Security Threats and Tools in SIP-Based
VoIP Systems. [S.l.]: University of Colorado, 2005.
ROSENBERG, J. RFC3261 - SIP: Session Initiation Protocol. Internet Engineering Task
Force. [S.l.]. 2002.
STEVENS, W. R. TCP/IP Illustrated: The Protocols. 1. ed. [S.l.]: Addison Wesley, v. I,
1993. ISBN 0201633469.
TANENBAUM, A. S. Computer Networks. 4. ed. [S.l.]: Prentice Hall, 2003. ISBN 0-13-
066102-3.
TCPDUMP. Latest Release. TCPDump & LibPcap, 2011. Disponivel em:
<http://www.tcpdump.org/#>. Acesso em: 15 Maio 2011.
WALL, K.; WATSON, M.; WHITIS, M. Linux Programming Unleashed. [S.l.]: Sams,
1999. ISBN 0-672-31607-2.
WALLINGFORD, T. Switching to VoIP. [S.l.]: O'Reilly, 2005. ISBN 0-596-00868-6.
141

ANEXO A Cdigo para gerao do Checksumutilizado nos cabealhos IP e UDP
Tabela 67 - Cdigo para gerao do checksum.
1 /*
2 * Copyright (c) 1998-2006 The TCPDUMP project
3 *
4 * Redistribution and use in source and binary forms, with or without
5 * modification, are permitted provided that: (1) source code
6 * distributions retain the above copyright notice and this paragraph
7 * in its entirety, and (2) distributions including binary code include
8 * the above copyright notice and this paragraph in its entirety in
9 * the documentation or other materials provided with the distribution.
10 * THIS SOFTWARE IS PROVIDED ``AS IS'' AND
11 * WITHOUT ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, WITHOUT
12 * LIMITATION, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
13 * FOR A PARTICULAR PURPOSE.
14 *
15 * miscellaneous checksumming routines
16 *
17 * Original code by Hannes Gredler (hannes@juniper.net)
18 */
19
20 #include <stdio.h>
21 #include <stdlib.h>
23 #include <assert.h>
24
25 /*
26 * Creates the OSI Fletcher checksum. See 8473-1, Appendix C, section C.3.
27 * The checksum field of the passed PDU does not need to be reset to zero.
28 */
29 u_short checksum(u_short *ptr, int length){
30 register int sum = 0;
31 u_short answer = 0;
32 register u_short *w = ptr;
33 register int nleft = length;
34
35 while(nleft > 1){
36 sum += *w++;
37 nleft -= 2;
38 }
39
40 sum = (sum >> 16) + (sum & 0xFFFF);
41 sum += (sum >> 16);
42 answer = ~sum;
43 return(answer);
44 }
Fonte: (TCPDUMP, 2011)
Os nmeros visualizados esquerda so apenas identificadores das linhas no
142

ANEXO B Cdigo para gerao do hash MD5 utilizado no SIP
Tabela 68 - Cdigo utilizado para a gerao do hash MD5.
1 /*
2 Copyright (C) 1999, 2000, 2002 Aladdin Enterprises. All rights reserved.
3
4 This software is provided 'as-is', without any express or implied
5 warranty. In no event will the authors be held liable for any damages
6 arising from the use of this software.
7
8 Permission is granted to anyone to use this software for any purpose,
9 including commercial applications, and to alter it and redistribute it
10 freely, subject to the following restrictions:
11
12 1. The origin of this software must not be misrepresented; you must not
13 claim that you wrote the original software. If you use this software
14 in a product, an acknowledgment in the product documentation would be
15 appreciated but is not required.
16 2. Altered source versions must be plainly marked as such, and must not be
17 misrepresented as being the original software.
18 3. This notice may not be removed or altered from any source distribution.
19
20 L. Peter Deutsch
21 ghost@aladdin.com
22
23 */
24 /* $Id: md5.c,v 1.6 2002/04/13 19:20:28 lpd Exp $ */
25 /*
26 Independent implementation of MD5 (RFC 1321).
27
28 This code implements the MD5 Algorithm defined in RFC 1321, whose
29 text is available at
30 http://www.ietf.org/rfc/rfc1321.txt
31 The code is derived from the text of the RFC, including the test suite
32 (section A.5) but excluding the rest of Appendix A. It does not include
33 any code or documentation that is identified in the RFC as being
34 copyrighted.
35
36 The original and principal author of md5.c is L. Peter Deutsch
37 <ghost@aladdin.com>. Other authors are noted in the change history
38 that follows (in reverse chronological order):
39
40 2002-04-13 lpd Clarified derivation from RFC 1321; now handles byte order
41 either statically or dynamically; added missing #include <string.h>
42 in library.
43 2002-03-11 lpd Corrected argument list for main(), and added int return
44 type, in test program and T value program.
45 2002-02-21 lpd Added missing #include <stdio.h> in test program.
46 2000-07-03 lpd Patched to eliminate warnings about "constant is
47 unsigned in ANSI C, signed in traditional"; made test program
48 self-checking.
49 1999-11-04 lpd Edited comments slightly for automatic TOC extraction.
50 1999-10-18 lpd Fixed typo in header comment (ansi2knr rather than md5).
51 1999-05-03 lpd Original version.
52 */
53
54 #include "md5.h"
56
57 #undef BYTE_ORDER /* 1 = big-endian, -1 = little-endian, 0 = unknown */
58 #ifdef ARCH_IS_BIG_ENDIAN
59 # define BYTE_ORDER (ARCH_IS_BIG_ENDIAN ? 1 : -1)
60 #else
61 # define BYTE_ORDER 0
62 #endif
63
64 #define T_MASK ((md5_word_t)~0)
143

65 #define T1 /* 0xd76aa478 */ (T_MASK ^ 0x28955b87)
66 #define T2 /* 0xe8c7b756 */ (T_MASK ^ 0x173848a9)
67 #define T3 0x242070db
68 #define T4 /* 0xc1bdceee */ (T_MASK ^ 0x3e423111)
69 #define T5 /* 0xf57c0faf */ (T_MASK ^ 0x0a83f050)
70 #define T6 0x4787c62a
71 #define T7 /* 0xa8304613 */ (T_MASK ^ 0x57cfb9ec)
72 #define T8 /* 0xfd469501 */ (T_MASK ^ 0x02b96afe)
73 #define T9 0x698098d8
74 #define T10 /* 0x8b44f7af */ (T_MASK ^ 0x74bb0850)
75 #define T11 /* 0xffff5bb1 */ (T_MASK ^ 0x0000a44e)
76 #define T12 /* 0x895cd7be */ (T_MASK ^ 0x76a32841)
77 #define T13 0x6b901122
78 #define T14 /* 0xfd987193 */ (T_MASK ^ 0x02678e6c)
79 #define T15 /* 0xa679438e */ (T_MASK ^ 0x5986bc71)
80 #define T16 0x49b40821
81 #define T17 /* 0xf61e2562 */ (T_MASK ^ 0x09e1da9d)
82 #define T18 /* 0xc040b340 */ (T_MASK ^ 0x3fbf4cbf)
83 #define T19 0x265e5a51
84 #define T20 /* 0xe9b6c7aa */ (T_MASK ^ 0x16493855)
85 #define T21 /* 0xd62f105d */ (T_MASK ^ 0x29d0efa2)
86 #define T22 0x02441453
87 #define T23 /* 0xd8a1e681 */ (T_MASK ^ 0x275e197e)
88 #define T24 /* 0xe7d3fbc8 */ (T_MASK ^ 0x182c0437)
89 #define T25 0x21e1cde6
90 #define T26 /* 0xc33707d6 */ (T_MASK ^ 0x3cc8f829)
91 #define T27 /* 0xf4d50d87 */ (T_MASK ^ 0x0b2af278)
92 #define T28 0x455a14ed
93 #define T29 /* 0xa9e3e905 */ (T_MASK ^ 0x561c16fa)
94 #define T30 /* 0xfcefa3f8 */ (T_MASK ^ 0x03105c07)
95 #define T31 0x676f02d9
96 #define T32 /* 0x8d2a4c8a */ (T_MASK ^ 0x72d5b375)
97 #define T33 /* 0xfffa3942 */ (T_MASK ^ 0x0005c6bd)
98 #define T34 /* 0x8771f681 */ (T_MASK ^ 0x788e097e)
99 #define T35 0x6d9d6122
100 #define T36 /* 0xfde5380c */ (T_MASK ^ 0x021ac7f3)
101 #define T37 /* 0xa4beea44 */ (T_MASK ^ 0x5b4115bb)
102 #define T38 0x4bdecfa9
103 #define T39 /* 0xf6bb4b60 */ (T_MASK ^ 0x0944b49f)
104 #define T40 /* 0xbebfbc70 */ (T_MASK ^ 0x4140438f)
105 #define T41 0x289b7ec6
106 #define T42 /* 0xeaa127fa */ (T_MASK ^ 0x155ed805)
107 #define T43 /* 0xd4ef3085 */ (T_MASK ^ 0x2b10cf7a)
108 #define T44 0x04881d05
109 #define T45 /* 0xd9d4d039 */ (T_MASK ^ 0x262b2fc6)
110 #define T46 /* 0xe6db99e5 */ (T_MASK ^ 0x1924661a)
111 #define T47 0x1fa27cf8
112 #define T48 /* 0xc4ac5665 */ (T_MASK ^ 0x3b53a99a)
113 #define T49 /* 0xf4292244 */ (T_MASK ^ 0x0bd6ddbb)
114 #define T50 0x432aff97
115 #define T51 /* 0xab9423a7 */ (T_MASK ^ 0x546bdc58)
116 #define T52 /* 0xfc93a039 */ (T_MASK ^ 0x036c5fc6)
117 #define T53 0x655b59c3
118 #define T54 /* 0x8f0ccc92 */ (T_MASK ^ 0x70f3336d)
119 #define T55 /* 0xffeff47d */ (T_MASK ^ 0x00100b82)
120 #define T56 /* 0x85845dd1 */ (T_MASK ^ 0x7a7ba22e)
121 #define T57 0x6fa87e4f
122 #define T58 /* 0xfe2ce6e0 */ (T_MASK ^ 0x01d3191f)
123 #define T59 /* 0xa3014314 */ (T_MASK ^ 0x5cfebceb)
124 #define T60 0x4e0811a1
125 #define T61 /* 0xf7537e82 */ (T_MASK ^ 0x08ac817d)
126 #define T62 /* 0xbd3af235 */ (T_MASK ^ 0x42c50dca)
127 #define T63 0x2ad7d2bb
128 #define T64 /* 0xeb86d391 */ (T_MASK ^ 0x14792c6e)
129
130
131 static void
132 md5_process(md5_state_t *pms, const md5_byte_t *data /*[64]*/)
133 {
134 md5_word_t
135 a = pms->abcd[0], b = pms->abcd[1],
136 c = pms->abcd[2], d = pms->abcd[3];
137 md5_word_t t;
138 #if BYTE_ORDER > 0
139 /* Define storage only for big-endian CPUs. */
140 md5_word_t X[16];
141 #else
144

142 /* Define storage for little-endian or both types of CPUs. */
143 md5_word_t xbuf[16];
144 const md5_word_t *X;
145 #endif
146
147 {
148 #if BYTE_ORDER == 0
149 /*
150 * Determine dynamically whether this is a big-endian or
151 * little-endian machine, since we can use a more efficient
152 * algorithm on the latter.
153 */
154 static const int w = 1;
155
156 if (*((const md5_byte_t *)&w)) /* dynamic little-endian */
157 #endif
158 #if BYTE_ORDER <= 0 /* little-endian */
159 {
160 /*
161 * On little-endian machines, we can process properly aligned
162 * data without copying it.
163 */
164 if (!((data - (const md5_byte_t *)0) & 3)) {
165 /* data are properly aligned */
166 X = (const md5_word_t *)data;
167 } else {
168 /* not aligned */
169 memcpy(xbuf, data, 64);
170 X = xbuf;
171 }
172 }
173 #endif
174 #if BYTE_ORDER == 0
175 else /* dynamic big-endian */
176 #endif
177 #if BYTE_ORDER >= 0 /* big-endian */
178 {
179 /*
180 * On big-endian machines, we must arrange the bytes in the
181 * right order.
182 */
183 const md5_byte_t *xp = data;
184 int i;
185
186 # if BYTE_ORDER == 0
187 X = xbuf; /* (dynamic only) */
188 # else
189 # define xbuf X /* (static only) */
190 # endif
191 for (i = 0; i < 16; ++i, xp += 4)
192 xbuf[i] = xp[0] + (xp[1] << 8) + (xp[2] << 16) + (xp[3] << 24);
193 }
194 #endif
195 }
196
197 #define ROTATE_LEFT(x, n) (((x) << (n)) | ((x) >> (32 - (n))))
198
199 /* Round 1. */
200 /* Let [abcd k s i] denote the operation
201 a = b + ((a + F(b,c,d) + X[k] + T[i]) <<< s). */
202 #define F(x, y, z) (((x) & (y)) | (~(x) & (z)))
203 #define SET(a, b, c, d, k, s, Ti)\
204 t = a + F(b,c,d) + X[k] + Ti;\
205 a = ROTATE_LEFT(t, s) + b
206 /* Do the following 16 operations. */
207 SET(a, b, c, d, 0, 7, T1);
208 SET(d, a, b, c, 1, 12, T2);
209 SET(c, d, a, b, 2, 17, T3);
210 SET(b, c, d, a, 3, 22, T4);
211 SET(a, b, c, d, 4, 7, T5);
212 SET(d, a, b, c, 5, 12, T6);
213 SET(c, d, a, b, 6, 17, T7);
214 SET(b, c, d, a, 7, 22, T8);
215 SET(a, b, c, d, 8, 7, T9);
216 SET(d, a, b, c, 9, 12, T10);
217 SET(c, d, a, b, 10, 17, T11);
218 SET(b, c, d, a, 11, 22, T12);
145

219 SET(a, b, c, d, 12, 7, T13);
220 SET(d, a, b, c, 13, 12, T14);
221 SET(c, d, a, b, 14, 17, T15);
222 SET(b, c, d, a, 15, 22, T16);
223 #undef SET
224
225 /* Round 2. */
226 /* Let [abcd k s i] denote the operation
227 a = b + ((a + G(b,c,d) + X[k] + T[i]) <<< s). */
228 #define G(x, y, z) (((x) & (z)) | ((y) & ~(z)))
230 t = a + G(b,c,d) + X[k] + Ti;\
233 SET(a, b, c, d, 1, 5, T17);
234 SET(d, a, b, c, 6, 9, T18);
235 SET(c, d, a, b, 11, 14, T19);
236 SET(b, c, d, a, 0, 20, T20);
237 SET(a, b, c, d, 5, 5, T21);
238 SET(d, a, b, c, 10, 9, T22);
239 SET(c, d, a, b, 15, 14, T23);
240 SET(b, c, d, a, 4, 20, T24);
241 SET(a, b, c, d, 9, 5, T25);
242 SET(d, a, b, c, 14, 9, T26);
243 SET(c, d, a, b, 3, 14, T27);
244 SET(b, c, d, a, 8, 20, T28);
245 SET(a, b, c, d, 13, 5, T29);
246 SET(d, a, b, c, 2, 9, T30);
247 SET(c, d, a, b, 7, 14, T31);
248 SET(b, c, d, a, 12, 20, T32);
249 #undef SET
250
251 /* Round 3. */
252 /* Let [abcd k s t] denote the operation
253 a = b + ((a + H(b,c,d) + X[k] + T[i]) <<< s). */
254 #define H(x, y, z) ((x) ^ (y) ^ (z))
256 t = a + H(b,c,d) + X[k] + Ti;\
259 SET(a, b, c, d, 5, 4, T33);
260 SET(d, a, b, c, 8, 11, T34);
261 SET(c, d, a, b, 11, 16, T35);
262 SET(b, c, d, a, 14, 23, T36);
263 SET(a, b, c, d, 1, 4, T37);
264 SET(d, a, b, c, 4, 11, T38);
265 SET(c, d, a, b, 7, 16, T39);
266 SET(b, c, d, a, 10, 23, T40);
267 SET(a, b, c, d, 13, 4, T41);
268 SET(d, a, b, c, 0, 11, T42);
269 SET(c, d, a, b, 3, 16, T43);
270 SET(b, c, d, a, 6, 23, T44);
271 SET(a, b, c, d, 9, 4, T45);
272 SET(d, a, b, c, 12, 11, T46);
273 SET(c, d, a, b, 15, 16, T47);
274 SET(b, c, d, a, 2, 23, T48);
275 #undef SET
276
277 /* Round 4. */
278 /* Let [abcd k s t] denote the operation
279 a = b + ((a + I(b,c,d) + X[k] + T[i]) <<< s). */
280 #define I(x, y, z) ((y) ^ ((x) | ~(z)))
282 t = a + I(b,c,d) + X[k] + Ti;\
285 SET(a, b, c, d, 0, 6, T49);
286 SET(d, a, b, c, 7, 10, T50);
287 SET(c, d, a, b, 14, 15, T51);
288 SET(b, c, d, a, 5, 21, T52);
289 SET(a, b, c, d, 12, 6, T53);
290 SET(d, a, b, c, 3, 10, T54);
291 SET(c, d, a, b, 10, 15, T55);
292 SET(b, c, d, a, 1, 21, T56);
293 SET(a, b, c, d, 8, 6, T57);
294 SET(d, a, b, c, 15, 10, T58);
295 SET(c, d, a, b, 6, 15, T59);
146

296 SET(b, c, d, a, 13, 21, T60);
297 SET(a, b, c, d, 4, 6, T61);
298 SET(d, a, b, c, 11, 10, T62);
299 SET(c, d, a, b, 2, 15, T63);
300 SET(b, c, d, a, 9, 21, T64);
301 #undef SET
302
303 /* Then perform the following additions. (That is increment each
304 of the four registers by the value it had before this block
305 was started.) */
306 pms->abcd[0] += a;
307 pms->abcd[1] += b;
308 pms->abcd[2] += c;
309 pms->abcd[3] += d;
310 }
311
312 void
313 md5_init(md5_state_t *pms)
314 {
315 pms->count[0] = pms->count[1] = 0;
316 pms->abcd[0] = 0x67452301;
317 pms->abcd[1] = /*0xefcdab89*/ T_MASK ^ 0x10325476;
318 pms->abcd[2] = /*0x98badcfe*/ T_MASK ^ 0x67452301;
319 pms->abcd[3] = 0x10325476;
320 }
321
322 void
323 md5_append(md5_state_t *pms, const md5_byte_t *data, int nbytes)
324 {
325 const md5_byte_t *p = data;
326 int left = nbytes;
327 int offset = (pms->count[0] >> 3) & 63;
328 md5_word_t nbits = (md5_word_t)(nbytes << 3);
329
330 if (nbytes <= 0)
331 return;
332
333 /* Update the message length. */
334 pms->count[1] += nbytes >> 29;
335 pms->count[0] += nbits;
336 if (pms->count[0] < nbits)
337 pms->count[1]++;
338
339 /* Process an initial partial block. */
340 if (offset) {
341 int copy = (offset + nbytes > 64 ? 64 - offset : nbytes);
342
343 memcpy(pms->buf + offset, p, copy);
344 if (offset + copy < 64)
345 return;
346 p += copy;
347 left -= copy;
348 md5_process(pms, pms->buf);
349 }
350
351 /* Process full blocks. */
352 for (; left >= 64; p += 64, left -= 64)
353 md5_process(pms, p);
354
355 /* Process a final partial block. */
356 if (left)
357 memcpy(pms->buf, p, left);
358 }
359
360 void
361 md5_finish(md5_state_t *pms, md5_byte_t digest[16])
362 {
363 static const md5_byte_t pad[64] = {
364 0x80, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
365 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
366 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
367 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0
368 };
369 md5_byte_t data[8];
370 int i;
371
372 /* Save the length before padding. */
147

373 for (i = 0; i < 8; ++i)
374 data[i] = (md5_byte_t)(pms->count[i >> 2] >> ((i & 3) << 3));
375 /* Pad to 56 bytes mod 64. */
376 md5_append(pms, pad, ((55 - (pms->count[0] >> 3)) & 63) + 1);
377 /* Append the length. */
378 md5_append(pms, data, 8);
379 for (i = 0; i < 16; ++i)
380 digest[i] = (md5_byte_t)(pms->abcd[i >> 2] >> ((i & 3) << 3));
381 }
Fonte: (ABZUG, 1991)
148

ANEXO C Cdigo para organizao dos bits na criao do pacote
Tabela 69 - Cdigo para organizao dos bits na criao do pacote.
1 /*
2 * Copyright (c) 1992, 1993, 1994, 1995, 1996
3 * The Regents of the University of California. All rights reserved.
4 *
5 * Redistribution and use in source and binary forms, with or without
6 * modification, are permitted provided that: (1) source code distributions
7 * retain the above copyright notice and this paragraph in its entirety, (2)
8 * distributions including binary code include the above copyright notice and
9 * this paragraph in its entirety in the documentation or other materials
10 * provided with the distribution, and (3) all advertising materials mentioning
11 * features or use of this software display the following acknowledgement:
12 * ``This product includes software developed by the University of California,
13 * Lawrence Berkeley Laboratory and its contributors.'' Neither the name of
14 * the University nor the names of its contributors may be used to endorse
15 * or promote products derived from this software without specific prior
16 * written permission.
17 * THIS SOFTWARE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR IMPLIED
18 * WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF
19 * MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.
20 *
21 * @(#) $Header: /var/repositorio/20110507_captura_sip/src/extract.h,v 1.1 2011/05/08
12:55:03 gio Exp $ (LBL)
22 */
23
24 /*
25 * Macros to extract possibly-unaligned big-endian integral values.
26 */
27 #ifdef LBL_ALIGN
28 /*
29 * The processor doesn't natively handle unaligned loads.
30 */
31 #ifdef HAVE___ATTRIBUTE__
32 /*
33 * We have __attribute__; we assume that means we have __attribute__((packed)).
34 * Declare packed structures containing a u_int16_t and a u_int32_t,
35 * cast the pointer to point to one of those, and fetch through it;
36 * the GCC manual doesn't appear to explicitly say that
37 * __attribute__((packed)) causes the compiler to generate unaligned-safe
38 * code, but it apppears to do so.
39 *
40 * We do this in case the compiler can generate, for this instruction set,
41 * better code to do an unaligned load and pass stuff to "ntohs()" or
42 * "ntohl()" than the code to fetch the bytes one at a time and
43 * assemble them. (That might not be the case on a little-endian platform,
44 * where "ntohs()" and "ntohl()" might not be done inline.)
45 */
46 typedef struct {
47 u_int16_t val;
48 } __attribute__((packed)) unaligned_u_int16_t;
49
50 typedef struct {
51 u_int32_t val;
52 } __attribute__((packed)) unaligned_u_int32_t;
53
54 #define EXTRACT_16BITS(p) \
55 ((u_int16_t)ntohs(((const unaligned_u_int16_t *)(p))->val))
57 ((u_int32_t)ntohl(((const unaligned_u_int32_t *)(p))->val))
59 ((u_int64_t)(((u_int64_t)ntohl(((const unaligned_u_int32_t *)(p) + 0)->val))
<< 32 | \
60 ((u_int64_t)ntohl(((const unaligned_u_int32_t *)(p) + 1)->val)) <<
0))
61
149

62 #else /* HAVE___ATTRIBUTE__ */
63 /*
64 * We don't have __attribute__, so do unaligned loads of big-endian
65 * quantities the hard way - fetch the bytes one at a time and
66 * assemble them.
67 */
69 ((u_int16_t)((u_int16_t)*((const u_int8_t *)(p) + 0) << 8 | \
70 (u_int16_t)*((const u_int8_t *)(p) + 1)))
73 (u_int32_t)*((const u_int8_t *)(p) + 1) << 16 | \
85 #endif /* HAVE___ATTRIBUTE__ */
86 #else /* LBL_ALIGN */
87 /*
88 * The processor natively handles unaligned loads, so we can just
89 * cast the pointer and fetch through it.
90 */
92 ((u_int16_t)ntohs(*(const u_int16_t *)(p)))
94 ((u_int32_t)ntohl(*(const u_int32_t *)(p)))
96 ((u_int64_t)(((u_int64_t)ntohl(*((const u_int32_t *)(p) + 0))) << 32 | \
97 ((u_int64_t)ntohl(*((const u_int32_t *)(p) + 1))) << 0))
98 #endif /* LBL_ALIGN */
99
104
105 /*
106 * Macros to extract possibly-unaligned little-endian integral values.
107 * XXX - do loads on little-endian machines that support unaligned loads?
108 */
109 #define EXTRACT_LE_8BITS(p) (*(p))
110 #define EXTRACT_LE_16BITS(p) \
Fonte: (TCPDUMP, 2011)

Desenvolvimento de Analisador e Modificador de Pacotes para Detecção e Correção de Problemas de Interoperabilidade Do Sip Entre Dispositivos

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Desenvolvimento de Analisador e Modificador de Pacotes para Detecção e Correção de Problemas de Interoperabilidade Do Sip Entre Dispositivos

Transféré par

Droits d'auteur :

Formats disponibles

UNIVERSIDADE DE CAXIAS DO SUL - UCS

CAMPUS UNIVERSITRIO DA REGIO DOS VINHEDOS - CARVI

Vous aimerez peut-être aussi