32 bit processes on a 64 bit kernel apparently have a full 4G address space, the kernel sits at the end of the (inaccessible for 32 bit processes) 64 bit address space. as you can see here:

$ cat /proc/self/maps
08048000-0804f000 r-xp 00000000 08:01 1439239                            /bin/cat
0804f000-08050000 rw-p 00006000 08:01 1439239                            /bin/cat
08050000-08071000 rw-p 08050000 00:00 0                                  [heap]
f7e41000-f7e42000 rw-p f7e41000 00:00 0 
f7e42000-f7f7a000 r-xp 00000000 08:01 1440336                            /lib/libc-2.7.so
f7f7a000-f7f7b000 r--p 00138000 08:01 1440336                            /lib/libc-2.7.so
f7f7b000-f7f7d000 rw-p 00139000 08:01 1440336                            /lib/libc-2.7.so
f7f7d000-f7f80000 rw-p f7f7d000 00:00 0 
f7f87000-f7f89000 rw-p f7f87000 00:00 0 
f7f89000-f7fa3000 r-xp 00000000 08:01 1440333                            /lib/ld-2.7.so
f7fa3000-f7fa5000 rw-p 0001a000 08:01 1440333                            /lib/ld-2.7.so
ffca1000-ffcb6000 rw-p 7ffffffea000 00:00 0                              [stack]
ffffe000-fffff000 r-xp ffffe000 00:00 0                                  [vdso]

cat uses the full 4G space to map libraries, heap, stack.
these days it's nearly impossible to buy a pc without 64 bit capability and if in doubt you can use a normal 32 bit userspace on a 64 bit kernel.

btw, why did the original developer choose to hardcode the addresses in the code? it is much more readable to at lease use constants for that, eg. BASE=0xd000000, COMMAND=BASE+0x123, etc. someone decided to write unmaintainable code, here, and now you have to clean up the mess.