Radare produces a bunch of `add byte [rax], al`, but why?

Question

What does a bunch of add byte [rax], al mean? I see a lot of memory addressing point to specific parts of the shared library (.dll) that have for instance, this...

  0x10064faf8      0000           add byte [rax], al
  0x10064fafa      0000           add byte [rax], al
  0x10064fafc      0000           add byte [rax], al
  0x10064fafe      0000           add byte [rax], al
     ; XREFS: DATA 0x10041db20  DATA 0x100545d2c  DATA 0x100546999  DATA 0x1005469b0  DATA 0x100549de0  DATA 0x100549e00  
  0x10064fb00      0000           add byte [rax], al
  0x10064fb02      0000           add byte [rax], al
  0x10064fb04      0000           add byte [rax], al
  0x10064fb06      0000           add byte [rax], al

What is that supposed to indicate to me when I see it? Do those spaces get rewritten or something when the dll is loaded into memory?

Answer 1

I am adding another answer here because the comment by op is akin to a new question

I'm still confused. If ix has numerious references to the point at which I >!seeked too, why would it be that there is neither data nor code? Why would >!these references be pointed to the padded area or the alignment area?

this is a demo of code which is referenced but doing a pd on reference would yield a bunch of zeros and has nothing to do with alignment or any other artifacts

C:\evancarr>cat evancarr0.cpp
#include <stdio.h>
#include <windows.h>
char somecipher[MAX_PATH + 1];
char curdir[MAX_PATH + 1];
char deccipher[MAX_PATH + 1];
int main(void) {
    GetCurrentDirectoryA(MAX_PATH, curdir);
    int cdlen = strlen(curdir);
    for (int i = 0; i < cdlen; i++) {
        somecipher[i] = curdir[i] ^ 0x1;
    }
    printf("%s\n", somecipher);
    for (int i = 0; i < cdlen; i++) {
        deccipher[i] = somecipher[i] ^ 0x1;
    }
    printf("%s\n", deccipher);
}

compiled and executed

C:\evancarr>cl /Zi /W4 /analyze /EHsc /O2 evancarr0.cpp
Microsoft (R) C/C++ Optimizing Compiler Version 19.12.25835 for x86
Copyright (C) Microsoft Corporation.  All rights reserved.

evancarr0.cpp
Microsoft (R) Incremental Linker Version 14.12.25835.0
Copyright (C) Microsoft Corporation.  All rights reserved.

/out:evancarr0.exe
/debug
evancarr0.obj

C:\evancarr>evancarr0.exe
B;]dw`ob`ss
C:\evancarr

loading it in radare2 seeking to main and doing a pd on the referenced global buffer (as can be seen the buffer has a lot of xrefs but it is a bunch of zeroes and disassembling throws a bunch of add [eax] , al

C:\evancarr>radare2 -AA evancarr0.exe

[0x004015cd]> s 0x4065a0

[0x004065a0]> pd 5
|              ; JMP XREF from 0x00403161 (sub.KERNEL32.dll_GetCurrentDirectoryA_161)
|           0x004065a0      56             push esi
|           0x004065a1      68380d4600     push 0x460d38 <<<<<<<
|           0x004065a6      6804010000     push 0x104                  ; 260
|           0x004065ab      ff1500304600   call dword [sym.imp.KERNEL32.dll_GetCurrentDirectoryA] ;
0x463000
|           0x004065b1      be380d4600     mov esi, 0x460d38


[0x004065a0]> pd 5 @ 0x460d38 
               ; DATA XREF from 0x004065a1  
               ; DATA XREF from 0x004065b1 
               ; DATA XREF from 0x004065f1 
               ; DATA XREF from 0x00406650 
               ; DATA XREF from 0x004065c0 

            0x00460d38      0000           add byte [eax], al
            0x00460d3a      0000           add byte [eax], al
            0x00460d3c      0000           add byte [eax], al
            0x00460d3e      0000           add byte [eax], al
            0x00460d40      0000           add byte [eax], al


[0x004065a0]> pd 5 @ 0x460c30
               ; DATA XREF from 0x00406658 
               ; DATA XREF from 0x00406663 
               ; DATA XREF from 0x004066a0 
               ; DATA XREF from 0x00406700 
               ; DATA XREF from 0x004065fc 


            0x00460c30      0000           add byte [eax], al
            0x00460c32      0000           add byte [eax], al
            0x00460c34      0000           add byte [eax], al
            0x00460c36      0000           add byte [eax], al
            0x00460c38      0000           add byte [eax], al
[0x004065a0]>

Answer 2

add byte [eax], al 

This instruction is falsly and accidentally blind-translated by disassemblers that don't distinguish between stored buffer/void spans and code segs, to explain what happens here you can refer to this blog section:

ADD has an opcode equal to 0000(h)=00000000 0000 0000(2) where the two last flagbits {d,s} of the command opcode are not set which indicates an addition from a register to an R/M field, s stands for size of transfer that is 8 bites = 2bytes.

The second operand denotes an addition of reg value to local address in EAX, in 32 bits intel ASM, it is encoded 00(h) for the reg AL, I don't know about 86/64x architectures but i guess it's same. Thus you see, mere coincidence.

Void spans are also a case where the program reserves extraspace to store imported DLL functions' entrypoints for locally invoked labels, local constants/strings, or between chunks of any forms of dispersed data.

These types of 0' spans can be frequently remarked in polymophic programs that dump themselves differently in RAM after each execution instance, where they often change their relative EP's and function call addresses in an evasive way against unpackers and any form of code tracking.

A very strong guess that this stream of padded DATA either stored for cache purpose or steganographed should be preceded by a JMP instruction CALL or RET, otherwise, there must be a problem.

See here an example of some debuggers/decompilers that recognize padded DB's and skip over them.

Answer 3

you probably have a seek outside of any known function in an area where there is no data or code an area that is a filler to meet alignment requirements of page / section sizes

also called as zero padded area

for example

[0x010546bc]> px 10 ; pd 10
- offset -   0 1  2 3  4 5  6 7  8 9  A B  C D  E F  0123456789ABCDEF

0x010546bc  0000 0000 0000 0000 0000                 ..........
            0x010546bc      0000           add byte [eax], al
            0x010546be      0000           add byte [eax], al
            0x010546c0      0000           add byte [eax], al
            0x010546c2      0000           add byte [eax], al
            0x010546c4      0000           add byte [eax], al
            0x010546c6      0000           add byte [eax], al
            0x010546c8      0000           add byte [eax], al
            0x010546ca      0000           add byte [eax], al
            0x010546cc      0000           add byte [eax], al
            0x010546ce      0000           add byte [eax], al
[0x010546bc]>