Are there any default values for registers?

I think what you are really asking about is calling convention, which describes how subroutines in a program pass information to one another, and how the operating system passes information to the program, and in general what the different registers are supposed to mean.

For example, the cdecl calling convention on the x86, which is used by most C compilers, says that when a function returns, the return value value goes on the eax register. So if you have a function int foo(), you know that after foo executes its ret opcode, eax will contain that int that foo returned.

By contrast, the PowerPC processor (usually) has (at least) 32 registers, simply named r0, r1, ... r31. The AIX calling convention for this chip says that the stack pointer goes on r1, that function parameters get passed on r3 through r11, that return values come back on r3, and so on.

It is important to remember that a calling convention is sort of like an agreement between the functions in a program, or between libraries. It isn't part of the hardware, or a law, and there are usually many different calling conventions that may be used on a platform. This is why sometimes you will see code like

struct CFoo {  void __stdcall method(); };

That is an instruction to MSVC, which usually likes to use the fastcall convention, telling it to use a different convention for that one function. This is important if eg the function is defined in a library that was built by some other compiler which uses stdcall instead.

When we talk about how the operating system passes information to a program (or the hardware to the operating system), we usually call it an ABI instead of a calling convention, but it is the same idea. So in the case of your program, it was written assuming that the OS would pass it some particular piece of information on eax. That assumption would be particular to the operating system, the compiler, and possibly even the individual program.

Some instructions implicitly update the registers, even if the destinations aren't listed explicitly in the code. Some examples:

• cpuid returns values in eax, ebx, ecx and edx
• loop decrements ecx
• rep string instructions change ecx, edi and esi
• rdmsr changes eax and edx
• mul and div change eax and edx

And there are many other examples.

You can't assume just by seeing that eax isn't listed in the code that it's not changed.

Even assuming you know which registers are affected by which instructions, the only times you have any guarantee for a value are:

• after an instruction that you know updates it
• immediately after hardware reset

At any other time, you can never make assumptions on the values.

It doesn't seem to be valid code. Are you sure it wasn't text?

Decoding it as 32bit x86 gives string ELF :

00: 7F 45  // 0x7F E
02: 4C     // L
03: 46     // F
04: 01 01  // ?? ??

Try opening the file as ELF file and not as just binary.