mov al, byte ptr [ebp+source]
add al, 5
add eax, eax
add al, 3
xor [ebp+_byte], al


_byte:=Integer(source[bufpos])+5 xor Integer(source[bufpos])+3;


Please if you know how this should be in code please tell me.

asm is exactly a programming language (one of them)

_byte=_byte xor (3 + 2*(source+5))

ebp usually used to point not buffers in memory, but data in stack: local variables or function parameters, but of course, there could be a local buffer. looks like cryptor/decrytor.

Hm you sure thats it? Where do you get * from

"add eax,eax" is the same as: eax=eax+eax ----> eax=eax*2

Old code:
CODE:0046F8EB mov al, [eax+edx]
CODE:0046F8EE mov [ebp+var_1A], al <--here is different
CODE:0046F8F1 mov al, byte ptr [ebp+i]
CODE:0046F8F4 add al, 5
CODE:0046F8F6 add eax, eax
CODE:0046F8F8 add al, 3
CODE:0046F8FA xor [ebp+var_1A], al <--here is different

My code makes:
CODE:0044EF96 mov bl, [eax+edx]
<--Missing that line from real code-->
CODE:0044EF99 mov al, byte ptr [ebp+i]
CODE:0044EF9C add al, 5
CODE:0044EF9E add eax, eax
CODE:0044EFA0 add al, 3
CODE:0044EFA2 xor bl, al <--here is different from real code


My actual code:
ch := ch xor (((i+5)*2)+3);
ch := ch xor (Byte(n4CEEF4) + Byte(n4CEEF4));


What is:
mov [ebp+var_1A], al


It seems its xoring with it too.. I can't figure it out.

Your new code uses an extra CPU register and hence the local variable is not needed anymore (because now it is stored in BL register).

Can you elaborate a bit more?

The codes slightly off.. so it wont encrypt correctly I can't figure out the problem.

Also how do I stop it from using another cpu registery ? confused :X

Also does anyone know what this function does?
movzx eax, ax
shr eax, 8
retn

Thinking its loword,hiword,hibyte or lobyte?

I haven't seen the full code, but its very dangerous to load/store only the lowest 8-bit part of eax (al), but one instruction acts on the whole register. You might have something off there...

vexusdev, better put a more complete ASM dump since if this is supposed to encrypt/decrypt something then it looks somewhat incomplete (there are no loops there for instance).

And as for the more elaboration of my previous answer what occurred there was that the compiler decided to store one of the local variables in BL register rather than an stack variable (like [ebp+var_1A]). The compiler probably decided so because that way is faster and/or makes the code size smaller but it doesn't change the final result at all, only timing is affected.

Also, I don't see the "ch := ch xor (Byte(n4CEEF4) + Byte(n4CEEF4));" line in your Assembly dump, if it would be there and "Byte(n4CEEF4)" means the byte at memory address 0x4CEEF4 then you should see something like this:

movzx eax, ax
shr eax, 8

similar to

movzx eax,ah

such code which looks like not-wise is usually result of code obfuscating to make reversing harder

Without more code it is difficult to say if there is an intent to grab bits overflowing from AL in instruction ADD EAX,EAX. Maybe it is a valid assumption given later posts regarding contents of AH:

AH <= AH*2
AH <= 0x7A < AL < 0xFB ? AH+1
AL <= 2*(AL+5)+3

Remapping has values in the range [7B,FA] producing set bits in the lsb of AH.

The code was given above: So AH is not used and is ignored.