Поиск строки в скомпилированном исполняемом файле

Question

У меня очень простая программа, как показано ниже: #include

int main(){
char* mystring = "ABCDEFGHIJKLMNO";
puts(mystring);

char otherstring[15];
otherstring[0]  = 'a';
otherstring[1]  = 'b';
otherstring[2]  = 'c';
otherstring[3]  = 'd';
otherstring[4]  = 'e';
otherstring[5]  = 'f';
otherstring[6]  = 'g';
otherstring[7]  = 'h';
otherstring[8]  = 'i';
otherstring[9]  = 'j';
otherstring[10] = 'k';
otherstring[11] = 'l';
otherstring[12] = 'm';
otherstring[13] = 'n';
otherstring[14] = 'o';
puts(otherstring);

return 0;
}

Компилятором был MS VC ++.

Собираю ли я эту программу с оптимизацией или без нее, я могу найти строку "ABCDEFGHIJKLMNO" в исполняемом файле с помощью шестнадцатеричного редактора.

Однако я не могу найти строку "abcdefghijklmno"

Чем отличается компилятор от других строк?

Шестнадцатеричный редактор, который я использовал, был Hexedit - но пробовал другие и все еще не мог найти другую строку. У кого-нибудь есть идеи, почему нет или как найти?

Кстати, я не делаю этого по причинам взлома.

Answer 1

Это то, что мой gcc сделал с этим кодом.Я предполагаю, что ваш компилятор делает то же самое.Строковая константа хранится в разделе только для чтения, а mystring инициализируется с помощью своего адреса.
Отдельные символы помещаются непосредственно в их расположение в массиве в стеке.Также обратите внимание, что otherstring не завершается NULL при вызове путов с ним.

           .file   "test.c"
            .section        .rodata
    .LC0:
            .string "ABCDEFGHIJKLMNO"
            .text
    .globl main
            .type   main, @function
    main:
    .LFB0:
            .cfi_startproc
            pushq   %rbp
                .cfi_def_cfa_offset 16
            movq    %rsp, %rbp
            .cfi_offset 6, -16
            .cfi_def_cfa_register 6
            subq    $48, %rsp
            movq    %fs:40, %rax
            movq    %rax, -8(%rbp)
            xorl    %eax, %eax
    /* here is where mystring is loaded with the address of "ABCDEFGHIJKLMNO" */
            movq    $.LC0, -40(%rbp)
    /* this is the call to puts */
                movq    -40(%rbp), %rax
            movq    %rax, %rdi
            call    puts
    /* here is where the bytes are loaded into otherstring on the stack */            
            movb    $97, -32(%rbp)  //'a'
            movb    $98, -31(%rbp)  //'b'
            movb    $99, -30(%rbp)  //'c'
            movb    $100, -29(%rbp) //'d'
            movb    $101, -28(%rbp) //'e'
            movb    $102, -27(%rbp) //'f'
            movb    $103, -26(%rbp) //'g'
            movb    $104, -25(%rbp) //'h'
            movb    $105, -24(%rbp) //'i'
            movb    $106, -23(%rbp) //'j'
            movb    $107, -22(%rbp) //'k'
            movb    $108, -21(%rbp) //'l'
            movb    $109, -20(%rbp) //'m'
            movb    $110, -19(%rbp) //'n'
            movb    $111, -18(%rbp) //'o'

Answer 2

В первом случае компилятор инициализирует данные точной строкой "ABC ...".

Во втором случае каждое назначение выполняется последовательно, поэтому компилятор генерирует код для выполнения этого назначения. В исполняемом файле вы должны увидеть 15 повторяющихся байтовых последовательностей, в которых изменяется только инициализатор ('a', 'b', 'c' ...).

Answer 3

Компилятор, скорее всего, поместит число для каждого символа в каждую позицию массива, как вы написали, без какой-либо оптимизации, которую можно найти при чтении кода.Помните, что один символ ничем не отличается от числа в c, поэтому вы можете даже использовать коды ascii вместо «a».В гекседиторе я бы ожидал, что вы увидите конвертированные обратно в буквы, только немного расставленные.