udis86 disassembler library has a very useful and handy disassembler called udcli.
For example, what I did to understand your code:
First, copy all the hex code bytes into an ASCII file. I copied your OllyDbg output and then cut off with Vim everything except the binary code, resulting in a text file like this (let's say hexcode.txt):
68 01 50 44 00 E8 01 00 00 00 C3 C3 A9 FE 39 B1 30 D8 BB A6 45 23 92 AC 3D B3 9C 8C 90 0E 26 3B D3 48 49 70 88 07 78 36 7C 88
Then wondering whether this is 16-bit, 32-bit or 64-bit Intel code... usually you can see and feel if the code seems strange, in that case it's either wrong processor, wrong processor mode or the code may be encrypted or it may be data and not code.
Let's try if it's 16-bit code:
In Linux console, $ cat hexcode.txt | udcli -x -16
0000000000000000 680150 push word 0x5001
0000000000000003 44 inc sp
0000000000000004 00e8 add al, ch
0000000000000006 0100 add [bx+si], ax
0000000000000008 0000 add [bx+si], al
000000000000000a c3 ret
000000000000000b c3 ret
000000000000000c a9fe39 test ax, 0x39fe
000000000000000f b130 mov cl, 0x30
0000000000000011 d8bba645 fdivr dword [bp+di+0x45a6]
0000000000000015 2392ac3d and dx, [bp+si+0x3dac]
0000000000000019 b39c mov bl, 0x9c
000000000000001b 8c900e26 mov [bx+si+0x260e], ss
000000000000001f 3bd3 cmp dx, bx
0000000000000021 48 dec ax
0000000000000022 49 dec cx
0000000000000023 7088 jo 0xffffffffffffffad
0000000000000025 07 pop es
0000000000000026 7836 js 0x5e
0000000000000028 7c88 jl 0xffffffffffffffb2
Hmmm. Already in the beginning inc sp, very strange instruction. Conclusion: not 16-bit code.
Maybe it's 32-bit code?
$ cat hexcode.txt | udcli -x -32
0000000000000000 6801504400 push dword 0x445001
0000000000000005 e801000000 call dword 0xb
000000000000000a c3 ret
000000000000000b c3 ret
000000000000000c a9fe39b130 test eax, 0x30b139fe
0000000000000011 d8bba6452392 fdivr dword [ebx+0x922345a6]
0000000000000017 ac lodsb
0000000000000018 3db39c8c90 cmp eax, 0x908c9cb3
000000000000001d 0e push cs
000000000000001e 263bd3 cmp edx, ebx
0000000000000021 48 dec eax
0000000000000022 49 dec ecx
0000000000000023 7088 jo 0xffffffffffffffad
0000000000000025 07 pop es
0000000000000026 7836 js 0x5e
0000000000000028 7c88 jl 0xffffffffffffffb2
This looks already better. First, you could set a breakpoint into 0x445001. As that dword gets pushed immediately before a call dword 0xb followed by a ret, it may be that the ret after call 0xb actually pops the value 0x445001 from stack and jumps to cs:0x445001. On the other hand, if there's an intent to obfuscate the code, it may be that the function called with call dword 0xb may modify the value 0x445001 pushed into stack, so that ret after call dword 0xb would not jump to 0x445001, but somewhere else. So set another breakpoint to the stack address where 0x445001 is stored. Before the function call call dword 0xb [ss:esp] should point to the value 0x445001, so set the breakpoint there. It can be set also inside the function, but in that case the address will be [ss:esp+4] ([ss:esp] holds the return address). So I would try first set these 2 breakpoints and then trace the code with single-stepping inside the call dword 0xb function.
A final thought: what if this is 64-bit code?
$ cat hexcode.txt | udcli -x -64
0000000000000000 6801504400 push dword 0x445001
0000000000000005 e801000000 call dword 0xb
000000000000000a c3 ret
000000000000000b c3 ret
000000000000000c a9fe39b130 test eax, 0x30b139fe
0000000000000011 d8bba6452392 fdivr dword [rbx-0x6ddcba5a]
0000000000000017 ac lodsb
0000000000000018 3db39c8c90 cmp eax, 0x908c9cb3
000000000000001d 0e invalid
000000000000001e 263bd3 cmp edx, ebx
0000000000000021 48497088 jo 0xffffffffffffffad
0000000000000025 07 invalid
0000000000000026 7836 js 0x5e
0000000000000028 7c88 jl 0xffffffffffffffb2
Begins the same way as 32-bit code, but later there's an invalid instruction, so probably it's not 64-bit code (unless the code hooks invalid opcode exception handler int 6), or never executes that code.
