# CRC

A verificação cíclica de redundância (do inglês, CRC - Cyclic Redundancy Check) é um método de detecção de erros normalmente usada em redes digitais e dispositivos de armazenamento para detectar mudança acidental em cadeias de dados. Mensagens de dados entrando nesses sistemas recebem um pequeno anexo com um valor de verificação baseado no resto de divisão polinomial do seu conteúdo. No ato da recuperação do dado o cálculo é refeito e comparado com o valor gerado anteriormente. Se os valores não se mostrarem semelhantes podem ser aplicadas ações para correção de dados, evitando assim a corrupção de dados. CRC pode ser usada para correção de erros a partir de alguns métodos.
O nome CRC vem da redundância do valor de verificação atrelado ao dado (A mensagem recebe um aumento em seu tamanho sem adicionar uma informação) e o algoritmo de validação é construído com laços de repetição cíclicos.
A verificação cíclica de redundância é amplamente utilizada em dispositivos binários por ser de simples implementação, é matematicamente fácil de ser analisada e apresenta bons resultados na detecção de erros comuns em canais de transmissão causados por ruído. A função utilizada para gerar o valor de verificação possui tamanho fixo, e é utilizada igualmente como uma função hash.
O primeiro a propor a CRC foi W. Wesley Peterson em 1961. Hoje, a função CRC de 32 bits do Ethernet e vários outros padrões são trabalhos de vários pesquisadores e foi publicada em 1975.

## Introdução

Verificação cíclica de redundância é baseada na teoria de códigos de correção de erros cíclicos. O uso de códigos cíclicos sistemáticos, que alteram a mensagem adicionando um valor de verificação de tamanho fixo, com o propósito de detecção de erros em redes de comunicação foi proposta por W. Wesley Peterson em 1961. Códigos cíclicos são simples de implementar e possuem o benefício apresentar ótimas respostas na detecção de erros causados pela “Rajada” de bits: sequencias continuas de símbolos de dados errados (Burst Errors).
Eles são importantes porque Burst Errors são ocorrências comuns em canais de comunicação, incluindo canais óticos ou magnéticos. Geralmente, um n-bit CRC aplicado sobre uma mensagem de tamanho qualquer irá detectar cada um desses erros que forem menores que n bits e uma fração de 1/(1- 2^(-n)) de bits em mensagens maiores.
A determinação de um valor para o código de validação requer a definição de um Gerador Polinomial.
Esse polinômio será o divisor em uma divisão polinomial em que a mensagem de dados será o dividendo e o quociente é descartado, porém o resto será o código de verificação. É importante mencionar que os coeficientes do gerador são calculados de acordo com a aritmética de campo finito, para que a operação de adição possa sempre ocorrer paralelamente bit-a-bit (sem carry entre dígitos).O tamanho do resto será sempre menor que o do gerador polinomial, com isso pode-se determinar o tamanho do código de verificação.
Na prática, a maioria dos códigos utilizam um campo Galois de 2 elementos, GF(2).Os elementos são geralmente chamados de 0 e 1 coincidentemente utilizados na arquitetura binária.
Um CRC é chamado de n-bit CRC quando seu código de verificação possui tamanho de n bits. Para um dado n, múltiplos códigos de verificação são possíveis de serem construídos, cada um com um polinômio diferente. Tal polinômio possui o maior grau de valor n, além de n + 1 termos. Ou seja, ele possui tamanho n + 1 bits.
Várias especificações descartam o MSB ou o LSB, pois eles sempre serão iguais a 1. Essas especificações serão encontradas mais a frente na forma de CRC-n-XXX.
O sistema de detecção de erro mais simples, o bit de paridade, é na verdade um 1-bit CRC, de polinômio x + 1 (dois termos), de nome CRC-1.

## Aplicações

Um dispositivo que suporta CRC calcula uma pequena sequência binária de tamanho fixo, conhecido como código de verificação ou CRC, para cada mensagem que será enviada ou recebida e a anexa aos dados, formando uma palavra-código (codeword).
Quando uma palavra código é recebida ou lida, o dispositivo compara seu código de verificação anexado com um novo, calculado a partir da mensagem, ou aplica o CRC sobre toda a palavra-código e compara o resultado com uma constante residual pré-definida.
Se os códigos CRC não são semelhantes a mensagem contém erros de dados. O dispositivo pode realizar ações corretivas como reler a mensagem ou requisitar um novo envio da mesma.
Senão os dados podem ser tratados como corretos e sem erro. (Com uma pequena probabilidade o código pode conter erros não detectados; essa é a natureza fundamental da verificação de erros).

## Integridade dos dados

Os códigos de verificação cíclica de redundância são projetados para proteger contra erros típicos dos canais de comunicação, onde podem garantir a integridade de mensagens de forma rápida e confiável. Entretanto, eles não são aplicáveis para proteção contra alteração intencional de dados.
Não há nenhum tipo de autenticação, um invasor pode editar a mensagem e recalcular seu código de verificação sem que a substituição seja detectada. Quando as funções criptográficas de hash e a CRC são armazenadas em conjunto com os dados, elas não podem proteger contra alterações intencionais dos dados. Aplicações que requerem tal proteção devem usar mecanismos de autenticação criptográficas como códigos de autenticação da mensagem ou assinaturas digitais.
Diferente das funções hash criptográficas , um CRC pode ser revertido facilmente, o que o torna inaplicável para uso com assinaturas digitais.
Finalmente, CRC são criados a partir de funções lineares, com a seguinte propriedade:$crc(x\oplus y\oplus z)=crc(x)\oplus crc(y)\oplus crc(z)$
Logo, mesmo que o CRC seja criptografado com uma cifra de fluxo (Stream cipher, um algoritmo de chave simétrica) que use a operação lógica OU exclusivo (XOR) como sua operação combinatória, ambas mensagem e CRC associada podem ser manipuladas sem o conhecimento da chave de manipulação. Essa era uma das falhas conhecidas do protocolo WEP.

## Cálculo

Para calcular um CRC de n bits, coloque os bits representando o dado em uma linha, e abaixo do MSB dessa linha posicione o padrão (n + 1)-bit que representa o divisor CRC, também chamado de "polinômio".
Neste exemplo será utilizado uma mensagem de 14 bits, com um 3-bit CRC, e o polinômio gerador. O polinômio precisa ser escrito em binário, um polinômio de 3ª ordem possui 4 coeficientes. Nesse caso, os coeficientes são: 1, 0, 1, 1. O resultado do cálculo tem 3 bits de tamanho.
A mensagem a ser codificada será:
Primeiro, são adicionados zeros no fim da palavra correspondentes ao tamanho n do CRC. Então é feito o primeiro cálculo para se obter o 3-bit CRC:
O algoritmo age sobre os bits diretamente acima do divisor em cada passo. O resultado para a iteração acima é a operação OU-exclusivo bit-a-bit para os bits acima do divisor polinomial. Os bits restantes são diretamente copiados para o resultado daquele passo. O Divisor é então deslocado para a direita em 1 bit e o processo é repetido até que divisor alcance o ultimo bit da mensagem. O cálculo completo pode ser visto a seguir:
Como o bit divisor mais à esquerda zerou todos os bits que interagiu, ao final desse processo apenas os n bits mais à direita da mensagem não serão zerados. Esses n bits correspondem ao resto da divisão polinomial, e ao valor da função CRC (a menos que a especificação do CRC escolhido exija algum processamento posterior).
A validade de uma mensagem recebida pode ser avaliada de maneira simples, aplicando o calculo acima novamente, porém o valor da função CRC será adicionado no lugar dos zeros à direita. O resto dessa operação deverá ser zero se nenhum erro for detectado.

## Matemática

A análise matemática desse processo de “divisão” demonstra como selecionar um divisor que garantirá boas propriedades de detecção de erro. Nessa análise, os dígitos da linha de bits são utilizados como coeficientes de um polinômio em uma variável qualquer x (coeficientes que são na verdade elementos do campo finito de GF(2), ao invés de números quaisquer propriamente). Esse conjunto binário polinomial é um anel matemático.

### Determinando polinômios

Selecionar o polinômio gerador é a parte mais importante de um algoritmo de verificação cíclica de redundância(CRC). O polinômio deve ser escolhido a fim de maximizar a capacidade de detecção de erros e minimizar a probabilidade de resultados semelhantes se utilizado outros polinômios.
O atributo mais importante do polinômio é seu tamanho (o maior grau de qualquer termo da expressão (maior expoente) + 1), pois isso impactará diretamente sobre o tamanho do valor de verificação.
Os tamanhos mais utilizados de polinômios são:
* 9 bits (CRC-8)
* 17 bits (CRC-16)
* 33 bits (CRC-32)
* 65 bits (CRC-64)
A determinação do polinômio de CRC depende do tamanho total da mensagem de dados a ser protegida (dados + bits de verificação CRC), das propriedades de proteção contra erros desejadas e da quantidade/tipo de recursos disponíveis para a implementação do CRC, além, é claro, da performance desejada. Um erro comum é assumir que os “melhores” polinômios para CRC são encontrados a partir de polinômios irredutíveis ou polinômios irredutíveis multiplicados pelo fator 1+x, que adiciona ao algoritmo a capacidade de detectar todos os erros que afetam um número ímpar de bits (1, 3, 5, ...).
Na realidade, todos os fatores descritos acima devem ser considerados para a escolha do polinômio e podem levar a um polinômio redutível. Entretanto, a escolha de um polinômio redutível irá causar um aumento na quantidade de erros que não serão detectados pelo CRC, pois o quociente do anel matemático terá divisores nulos.
A vantagem na escolha de um polinômio primitivo como gerador para um código CRC será encontrada no resultado que terá um tamanho total de mensagem tal que todos os erros de 1-bit contidos na mensagem terão restos da divisão distintos (chamados de síndromes) e por isso, o resto será uma função linear, e o algoritmo será capaz de detectar qualquer erro de 2 bits contidos na mensagem. Se $r$ é o grau do polinômio primitivo gerador, então o tamanho máximo da mensagem de dados será $2^{r}-1$ , e o código de verificação anexado será capaz de detectar qualquer erro de um bit ou de um par de bits.
Isso pode ser otimizado, se for utilizado um polinômio gerador $g(x)=p(x)(1+x)$, onde $p(x)$ é um polinômio primitivo de grau $r-1$ , então o tamanho máximo da mensagem será $2^{r-1}-1$, e o código se tornará capaz de detectar erros de bit único, duplo, triplo e qualquer conjunto de tamanho ímpar de bits.
O polinômio $g(x)$ admite que fatorações possam ser escolhidas para controlar o tamanho da mensagem com p poder de detecção de erros desejado. Os algoritmos de BCH são classes de tais polinômios. Eles incluem os dois exemplos acima. Independente das propriedades de redução de um gerador polinomial de grau , se ele é expresso com o termo “+1”, o código será capaz de detectar padrões de erro contidos em uma janela de bits contínuos. Esses padrões são chamados de “rajada de erros” (errors bursts).

## Especificação

O conceito da verificação cíclica de redundância como um algoritmo de detecção de erros ganha complexidade à medida que implementações ou comitês de normas à aplicam em sistemas reais. Alguns exemplos de complicações são:
* Algumas implementações usam um padrão de bits prefixado na linha dos dados a ser verificada. Isso é especialmente útil quando erros de temporização podem inserir bits de valor 0 antes da mensagem, essa alteração não iria alterar o código de verificação.
* Há uma chance da implementação anexar n bits de valor 0 (n sendo o tamanho do CRC) à linha de dados que será verificada antes que a divisão polinomial ocorra. Esse tipo de anexação é demonstrada explicitamente no artigo Computation of CRC. É conveniente que o resto da linha de dados original com o valor de verificação anexado seja exatamente zero, para que a validade do CRC possa ser avaliada simplesmente efetuando a divisão polinomial dos dados recebidos e comparar o resto dessa operação com zero. Devido a propriedade associativa e comutativa da operação OU-exclusivo, implementações que utilizam tabelas de resultados para comparação podem obter um resultado numericamente equivalente a essa anexação de bits 0 sem ser necessário que ela aconteça, usando algum algoritmo equivalente [6] que combina os dados recebidos imediatamente com dados que acabaram de ser verificados, o tornando mais rápido.
* Padrões que implementam a operação OU-exclusivo em um número fixo de bits no resto da divisão polinomial.
* A ordem dos bits: algumas arquiteturas utilizam o bit de menor ordem de cada byte como o “primeiro” bit, que implica na divisão polinomial ser realizada a partir do bit mais à direita. Essa convenção é utilizada em transmissões via porta serial são validadas em hardware, admitindo-se que o bit menos significativo é transmitido primeiro.
* A ordem do byte: com CRC aplicado à múltiplos bytes pode haver confusão se o primeiro byte transmitido será o byte mais significativo ou o menos significativo. Algumas implementações 16-bit CRC trocam os bytes que devem ser avaliados pelo código de verificação.
* Omissão do bit mais significativo do divisor polinomial: como o bit de maior grau é sempre 1, e como um n-bit CRC é definido com o tamanho (n + 1) bits que é maior que um registro de n bits, alguns autores assumem que é desnecessário mencionar o bit de maior grau do divisor.
* Omissão do bit menos significativo do divisor polinomial: como o bit de menor grau é sempre 1, autores como Phillip Koopman representam polinômios com seu bit mais significativo intacto, porém o bit menos significativo ( o de termo $x^{0}$ ou 1 ) é descartado. Essa convenção representa o polinômio completo com seu grau em apenas uma variável inteira.
Essas complicações demonstram que um polinômio pode ser expresso de 3 formas diferentes: as duas primeiras são as mais encontradas em algoritmos, sendo que uma é a negação logica da outra; e a terceira é a forma encontrada nos artigos escritos por Koopman. Em cada caso, um termo é omitido. E o polinômio $x^{4}+x+1$ pode ser representado como:
* 0x3 = 0b0011, representando $x^{4}+(0x^{3}+0x^{2}+1x^{1}+1x^{0})$ (Com o bit mais significativo à esquerda)
* 0xC = 0b1100, representando $(1x^{0}+1x^{1}+0x^{2}+0x^{3})+x^{4}$ (Com o bit menos significativo à esquerda)
* 0x9 = 0b1001, representando $(1x^{4}+0x^{3}+0x^{2}+1x^{1})+x^{0}$ (notação utilizada por Koopman)
Na tabela abaixo eles são representados como:
| Nome | Normal | Reversa | Reversa Reciproca |
| CRC-4 | 0x3 | 0xC | 0x9 |

## Padrões e Usos

Vários algoritmos de verificação cíclica de redundância são regidos por Normas Técnicas. Nenhum algoritmo, ou implementação de um polinômio de qualquer grau pode ser utilizado para todas as aplicações. Koopman e Chakravarty recomendam que a seleção de um polinômio seja feita de modo a atender as necessidades da aplicação e o tamanho esperado das mensagens enviadas. O número de algoritmos de CRC que podem ser usados gera certa confusão nos desenvolvedores, esse é o problema que a maioria de autores sobre o assunto busca resolver. Existem 3 polinômios utilizados para o CRC-12, 19 conflitos nas definições para o CRC-16, e 7 para o CRC-32.
Os polinômios que são utilizados não são necessariamente os mais eficientes. Desde 1993, Koopman, Castagnoli e outros trabalharam com a abrangência de polinômios entre 3 e 64 bits de comprimento, buscando exemplos que possuíam uma melhora na performance (em termos da Distância de Hamming para determinado tamanho de mensagem) em comparação com os polinômios utilizados em padrões anteriores, publicando os que apresentavam melhores resultados com o intuito de otimizar a capacidade de detecção de erros de padrões futuros. Em particular, o iSCSI e SCTP utilizam um dos polinômios descobertos durante a pesquisa, o polinômio (Castagnoli) CRC-32C.
O projeto do polinômio de 32 bits utilizado na maioria dos padrões, o CRC-32-IEEE, foi resultado de um esforço conjunto para Laboratório Rome e a Divisão de Sistemas Eletrônicos das Forças Aéreas americanas obtido por Joseph Hammond, James Brown, Shyan-Shiang Liu, do Instituto de Tecnologia da Georgia, e Kenneth Brayer da Corporação MITRE.
As primeiras publicações sobre o polinômio de 32 bits ocorreram em 1975: no Relatório Técnico 2956 da Corporação MITRE, publicado internamente em Janeiro e divulgado para o público em Agosto pelo DTIC, além do relatório de Hammond, Brown e Liu para o laboratório de Roma publicado em Maio.Ambos os relatórios continham contribuições das equipes envolvidas. Em Dezembro de 1975, Brayer e Hammond apresentaram um artigo com informações sobre seu trabalho na Conferência Nacional de Telecomunicações IEEE: o CRC-32-IEE é o polinômio gerado a partir de um código Hamming e foi escolhido pela sua performance na detecção de erros. No entanto, o polinômio CRC-32C de Castagnoli usado nos protocolos iSCSI ou SCTP apresenta o mesmo desempenho para mensagens com o tamanho entre 58 bits a 131k bits, e um desempenho superior para diferentes tamanhos de mensagens, incluindo os e tamanhos de pacotes mais utilizados pela internet. O padrão ITU-T G.hn também faz uso do CRC-32C para detectar erros nos dados( entretanto ele utiliza o CRC-16-CCITT para outras aplicações).
A tabela abaixo lista apenas polinômios de vários algoritmos que estão em uso. Variações particulares dos protocolos podem utilizar pré-inversão, pós-inversão e ordenação reversa de bits como descrito acima. Por exemplo, o CRC32 utilizado nos padrões Gzip e Bzip2 utilizam o mesmo polinômio, porém o Gzip aplica a ordenação reversa de bits.
CRCs de protocolos proprietários podem utilizar valores iniciais não triviais e um operação XOR adicional para esconder seu valor, mas tais técnicas não aumentam a força da criptografia utilizada no algoritmo e podem ser desmascaradas utilizando métodos diretos de engenharia reversa.
| Nome | Uso | Polynomial representations | Polynomial representations | Polynomial representations |
| Nome | Uso | Normal | Reversa | Reversa Reciproca |
| CRC-1 | Maioria em hardware;conhecido como parity bit | 0x1 | 0x1 | 0x1 |
| CRC-3-GSM | redes móveis | 0x3 | 0x6 | 0x5 |
| CRC-4-ITU | G.704 | 0x3 | 0xC | 0x9 |
| CRC-5-EPC | Gen 2 RFID | 0x09 | 0x12 | 0x14 |
| CRC-5-ITU | G.704 | 0x15 | 0x15 | 0x1A |
| CRC-5-USB | USB pacotes de token | 0x05 | 0x14 | 0x12 |
| CRC-6-CDMA2000-A | redes móveis | 0x27 | 0x39 | 0x33 |
| CRC-6-CDMA2000-B | redes móveis | 0x07 | 0x38 | 0x23 |
| CRC-6-DARC | Canal de Dados via Rádio | 0x19 | 0x26 | 0x2C |
| CRC-6-GSM | redes móveis | 0x2F | 0x3D | 0x37 |
| CRC-6-ITU | G.704 | 0x03 | 0x30 | 0x21 |
| CRC-7 | sistemas de telecomunicação, G.707, G.832, MMC, SD | 0x09 | 0x48 | 0x44 |
| CRC-7-MVB | Rede de Comunicação Ferroviária, IEC 60870-5 | 0x65 | 0x53 | 0x72 |
| CRC-8 | DVB-S2 | 0xD5 | 0xAB | 0xEA |
| CRC-8-AUTOSAR | Integração Automotiva, OpenSafety | 0x2F | 0xF4 | 0x97 |
| CRC-8-Bluetooth | Conectividade Wireless | 0xA7 | 0xE5 | 0xD3 |
| CRC-8-CCITT | I.432.1; ATM HEC, ISDN HEC e fronteiras de células | 0x07 | 0xE0 | 0x83 |
| CRC-8-Dallas/Maxim | 1-Wire bus | 0x31 | 0x8C | 0x98 |
| CRC-8-DARC | Canal de Dados via Rádio | 0x39 | 0x9C | 0x9C |
| CRC-8-GSM-B | redes móveis | 0x49 | 0x92 | 0xA4 |
| CRC-8-SAE J1850 | AES3 | 0x1D | 0xB8 | 0x8E |
| CRC-8-WCDMA | redes móveis | 0x9B | 0xD9 | 0xCD |
| CRC-10 | ATM; I.610 | 0x233 | 0x331 | 0x319 |
| CRC-10-CDMA2000 | redes móveis | 0x3D9 | 0x26F | 0x3EC |
| CRC-10-GSM | redes móveis | 0x175 | 0x2BA | 0x2BA |
| CRC-11 | FlexRay | 0x385 | 0x50E | 0x5C2 |
| CRC-12 | sistemas de telecomunicação | 0x80F | 0xF01 | 0xC07 |
| CRC-12-CDMA2000 | redes móveis | 0xF13 | 0xC8F | 0xF89 |
| CRC-12-GSM | redes móveis | 0xD31 | 0x8CB | 0xE98 |
| CRC-13-BBC | Sinal Temporizado, Radio teleswitch | 0x1CF5 | 0x15E7 | 0x1E7A |
| CRC-14-DARC | Canal de Dados via Rádio | 0x0805 | 0x2804 | 0x2402 |
| CRC-14-GSM | redes móveis | 0x202D | 0x2D01 | 0x3016 |
| CRC-15-CAN | | 0x4599 | 0x4CD1 | 0x62CC |
| CRC-15-MPT1327 | | 0x6815 | 0x540B | 0x740A |
| CRC-16-Chakravarty | Otimizado para mensagens ≤64 bits | 0x2F15 | 0xA8F4 | 0x978A |
| CRC-16-ARINC | ACARS aplicações | 0xA02B | 0xD405 | 0xD015 |
| CRC-16-CCITT | X.25, V.41, HDLC FCS, XMODEM, Bluetooth, PACTOR, SD, DigRF, Vários outros; conhecido como CRC-CCITT | 0x1021 | 0x8408 | 0x8810 |
| CRC-16-CDMA2000 | redes móveis | 0xC867 | 0xE613 | 0xE433 |
| CRC-16-DECT | Telefones Sem Fio | 0x0589 | 0x91A0 | 0x82C4 |
| CRC-16-T10-DIF | SCSI DIF | 0x8BB7 | 0xEDD1 | 0xC5DB |
| CRC-16-DNP | DNP, IEC 870, M-Bus | 0x3D65 | 0xA6BC | 0x9EB2 |
| CRC-16-IBM | Bisync, Modbus, USB, ANSI X3.28, SIA DC-07, Vários outros; também conhecido como CRC-16 e CRC-16-ANSI | 0x8005 | 0xA001 | 0xC002 |
| CRC-16-OpenSafety-A | bateria de testes seguros | 0x5935 | 0xAC9A | 0xAC9A |
| CRC-16-OpenSafety-B | bateria de testes seguros | 0x755B | 0xDAAE | 0xBAAD |
| CRC-16-Profibus | redes de testes seguros | 0x1DCF | 0xF3B8 | 0x8EE7 |
| CRC-17-CAN | CAN FD | 0x1685B | 0x1B42D | 0x1B42D |
| CRC-21-CAN | CAN FD | 0x102899 | 0x132281 | 0x18144C |
| CRC-24 | FlexRay | 0x5D6DCB | 0xD3B6BA | 0xAEB6E5 |
| CRC-24-Radix-64 | OpenPGP, RTCM104v3 | 0x864CFB | 0xDF3261 | 0xC3267D |
| CRC-30 | CDMA | 0x2030B9C7 | 0x38E74301 | 0x30185CE3 |
| CRC-32 | HDLC, ANSI X3.66 (ADCCP), ITU-T V.42, ISO/IEC/IEEE 8802-3 (Ethernet), Serial ATA, MPEG-2, PKZIP, Gzip, Bzip2, POSIX cksum, PNG, Vários outros | 0x04C11DB7 | 0xEDB88320 | 0x82608EDB |
| CRC-32C (Castagnoli) | iSCSI, SCTP, G.hn payload, SSE4.2, Btrfs, ext4, Ceph | 0x1EDC6F41 | 0x82F63B78 | 0x8F6E37A0 |
| CRC-32K (Koopman {1,3,28}) | | 0x741B8CD7 | 0xEB31D82E | 0xBA0DC66B |
| CRC-32K$_2$ (Koopman {1,1,30}) | | 0x32583499 | 0x992C1A4C | 0x992C1A4C |
| CRC-32Q | aviação; AIXM | 0x814141AB | 0xD5828281 | 0xC0A0A0D5 |
| CRC-40-GSM | Canal de Controle GSM | 0x0004820009 | 0x9000412000 | 0x8002410004 |
| CRC-64-ECMA | ECMA-182, XZ Utils | 0x42F0E1EBA9EA3693 | 0xC96C5795D7870F42 | 0xA17870F5D4F51B49 |
| CRC-64-ISO | HDLC, Swiss-Prot/TrEMBL; considerado fraco para hashing | 0x000000000000001B | 0xD800000000000000 | 0x800000000000000D |