A sobrecarga do buffer altera o tipo de dados da variável sobrescrita? [fechadas]

8

Digamos que eu tenha uma matriz de caracteres C char buf[15] . Digamos que a variável int set_me = 0 tenha seus dados armazenados em um local de memória diretamente após char buf[15] . Se eu transbordasse buf com a string "aaabbbcccdddeee\xef\xbe\xad\xde" , o tipo de dados de set_me mudaria de um inteiro para um array de caracteres?

    
por Darien Springer 04.05.2018 / 04:51

2 respostas

33

Não.

O "tipo de dados" de uma variável só é relevante no código-fonte (e, mesmo assim, apenas em alguns idiomas). Diz ao compilador como tratar a variável.

Esses tipos de dados de alto nível não existem como tal no código compilado (nativo). Eles podem afetar as instruções que um compilador gera, mas as instruções em si não importam se os dados representam um caractere ou um número.

Variáveis não existem no hardware. No hardware, você tem locais de memória e as instruções que operam neles.

Uma variável pode ser vista como uma exibição dos dados em um local de memória - se você for semicerro e olhar para a mesma memória de forma ligeiramente diferente (uma variável diferente com um tipo diferente referindo-se ao mesmo local) , o mesmo valor binário pode ter um significado diferente.

Por exemplo, o byte 0x41 pode ser interpretado como o caractere codificado em UTF-8 A . Também pode ser interpretado como o inteiro de byte único 65 . Ele também pode ser interpretado como um byte em um inteiro de múltiplos bytes ou número de ponto flutuante, ou um byte em uma codificação de caractere de múltiplos bytes. Pode ser o bitset 0b1000001 . Tudo a partir do mesmo byte no mesmo local de memória. Na linguagem C, você pode ver esse efeito ao transmitir para esses tipos diferentes.

Quando você tem um "estouro de buffer", você está fazendo algo fora dos limites do que seu compilador ou idioma pode esperar. Mas, no que diz respeito ao hardware 1 , você está escrevendo bytes (seja ele único ou múltiplo) em um local da memória. Um local de memória não possui um "tipo". Na verdade, o hardware nem sabe que qualquer conjunto particular de bytes faz uma matriz ou buffer no seu código.

Sempre que você acessar a localização da memória em seu código, as instruções serão executadas conforme definido originalmente. por exemplo. se eles estivessem esperando um número lá, eles agirão em qualquer bytes de dados como se fossem um número.

Para usar seu exemplo, supondo que seu int seja um inteiro de 4 bytes (32 bits) assinado:

+-------------+--------------------------------------------+-----------+
| Source code |                  char[15]                  |    int    |
+-------------+--------------------------------------------------------+
| Memory      |61|61|61|62|62|62|63|63|63|64|64|64|65|65|65|EF|BE|AD|DE|
+-------------+--------------------------------------------------------+

Você pode ver que a localização da memória de int agora contém 0xEFBEADDE , supondo um sistema big-endian 2 . Este é o int -272716322 de 32 bits assinado. Agora, se você interpretar a mesma memória como um int não assinado ( uint ), ela será 4022250974 . Para exatamente os mesmos dados na memória, o significado depende inteiramente de como você o visualiza.

1 Existem alguns mecanismos que impedem que você grave em regiões protegidas de memória e travará seu programa se você tentar fazer isso.

2 x86 é na verdade little-endian, o que significa que você interpreta os bytes criando um valor maior para trás. Então, no x86, você teria 0xDEADBEEF , dando -559038737 ou unsigned 3735928559 .

    
por 04.05.2018 / 05:10
2

De uma perspectiva em C, a resposta seria "Quem sabe? É um comportamento indefinido".

Os tipos são um conceito C, não hardware. Mas as regras C não se aplicam se o seu programa tiver Comportamento Indefinido, que é o significado literal do Comportamento Indefinido no padrão C. E buffer overflows são uma forma disso.

Eu inicialmente escrevi "as regras C não se aplicam mais", mas na verdade o comportamento indefinido é retroativo. Regras C não se aplicam a um programa que terá Comportamento Indefinido no futuro.

    
por 04.05.2018 / 09:24

Tags