What Is 0 ^ 0?

Quick questions:

What is 2 ^ 3? 8

What is 10 ^ 2? 100

What is 912873683428920348791239817231928370 ^ (200 – (40 * 5)) ? 1

Very good. It is an easy test, right? Yes indeed. OK let’s try another question: what is 0 ^ 0?

I repeat: what is 0 ^ 0?

..

..

Give up? OK. This time I’ll answer this question programmatically, not mathematically (there are several approach used to tackle this problems: limit, set theory, etc). Here’s the X86 assembly to outline the idea:


format PE console 4.0

include 'win32a.inc'

entry start

section '.data' readable executable
num1 dd 0
num2 dd 0
fmt db "%d",0

section '.code' code readable executable
start:
mov ecx, [num1]
mov eax, [num2]
mov ebx, ecx

process:
cmp eax, 1
jg multiply
je done

multiply:
imul ecx, ebx
dec eax
jmp process

done:
invoke printf, fmt, ecx
invoke ExitProcess, 0

section '.idata' import data readable writable
library kernel32,'kernel32.dll', msvcrt, 'msvcrt.dll'
import kernel32, ExitProcess, 'ExitProcess'
import msvcrt, printf, 'printf'

The output is, surprisingly (or not surprisingly) 0.

I expect careful readers to complain that I’m cheating, since the output of the code will always be 0.

No, I’m not cheating. May I suggest you to play with the code yourself? Probably you’ll be even more surprised :mrgreen:

A Simple CMS written in assembly

Someone is working on a simple CMS, written in assembly.

..

Wait a sec. Did you just say assembly? Yup. FASM, to be precise. The CMS it’s called MiniMagAsm.

That’s CGI programming. And honestly, I’m not familliar with it, so I just built and ran it using lighttpd.

It works. Maybe somewhen in the future we’ll have a web framework written in assembly.

:mrgreen:

Surprise Surprise!

Could you figure out what is the output of this snippet?


format PE console 4.0

include 'win32a.inc'

entry start

section '.data' data readable
fmt db "%d ", 0

section '.code' readable executable
start:
 mov ecx, 15
 cinvoke printf, fmt, ecx
 inc ecx
 cinvoke printf, fmt, ecx
 inc ecx
 cinvoke printf, fmt, ecx
invoke ExitProcess,

section '.idata' data import readable writeable
library kernel32, 'kernel32.dll', msvcrt, 'msvcrt.dll'
import kernel32, ExitProcess, 'ExitProcess'
import msvcrt, printf, 'printf'

At a glance, this snippet looks so simple and self-explaining.

mov ecx, 15 -> ecx = 15
cinvoke printf, fmt, ecx -> print 15
inc ecx -> ecx = 15 + 1 = 16
cinvoke printf, fmt, ecx -> print 16
inc ecx -> ecx = 16 + 1 = 17
cinvoke printf, fmt, ecx -> print 17
 invoke ExitProcess, 0 -> exit

So the result must be 15 16 17, right? That’s easy.

..

..

..

Huh??

Built and run it  yourself (use FASM). On my laptop, the result is 15 1986971169 1986971169.

Surprised? :mrgreen:

The pitfall is the ECX register is trashed, due to the invocation of printfs (hint).

So, what to do, then? Simple. Either

  1. Use EBX, ESI, or EDI because they are guaranteed to be preserved
  2. Or use a pair of push & pop to preserve the value, if you must use EAX, ECX, etc.

Example #1


format PE console 4.0

include 'win32a.inc'

entry start

section '.data' data readable
fmt db "%d ", 0

section '.code' readable executable
start:
 mov ebx, 15
 cinvoke printf, fmt, ebx
 inc ebx
 cinvoke printf, fmt, ebx
 inc ebx
 cinvoke printf, fmt, ebx
 invoke ExitProcess, 0

section '.idata' data import readable writeable
library kernel32, 'kernel32.dll', msvcrt, 'msvcrt.dll'
import kernel32, ExitProcess, 'ExitProcess'
import msvcrt, printf, 'printf'

Example #2


format PE console 4.0

include 'win32a.inc'

entry start

section '.data' data readable
fmt db "%d ", 0

section '.code' readable executable
start:
 mov ecx, 15
 push ecx
 cinvoke printf, fmt, ecx
 pop ecx
 inc ecx
 push ecx
 cinvoke printf, fmt, ecx
 pop ecx
 inc ecx
 push ecx
 cinvoke printf, fmt, ecx
 pop ecx
 invoke ExitProcess, 0

section '.idata' data import readable writeable
library kernel32, 'kernel32.dll', msvcrt, 'msvcrt.dll'
import kernel32, ExitProcess, 'ExitProcess'
import msvcrt, printf, 'printf'

Either way works :mrgreen:

BTW, the reason I write this post is sometimes I still stumble unto this error. So, yeah, let this post be the reminder.