KUMEL'S NOTE

Here is the POC :
The script above will generate a fuzzer.asx file which have junk 2046 byte at the url part. Running the GOM Player and open that file with GOM Player and then boom!!! Hem, there's something wrong.
Now let's see what's happened with debugger

As we can see that our fuzzer was overwrite some register's value like EBX and EBP, but what's happend with the EIP register? Why do it have value 011A8D73?
Ok, let's see the instruction at 011A8D73 memory address
As we're seeing that the opcode of 011A8D73 memory address is "0000" which have mean in assembly language is "add byte ptr ds:[eax], al", but ain't it which we needed, so look some instruction around the offset of it and we will look a good opcode like "004100" and "41", have you thought what i'm thinking? May be it's our fuzzer's data, because in unicode application if we send "\x41" data it will converted to the "0041" in the stack. So if the offset in EIP register now is 011A8D73, maybe EIP already execute the offset of our fuzzer before.
For ensure about that now we will send the fuzzer which have value "\xcc", as a opcode it have an assembly instruction like a "break point", so if our fuzzer have executed, then it will pause at the break point instruction ^_^
We must know the format of our fuzzer when it have position in the stack first.
As we can see that first byte of our fuzzer become an opcode "004100", so if we send the fuzzer 'junk = "\xcc"*2046' then the first byte will become an opcode "00cc00" and it not an opcode of the break point instruction anymore
In order to solved this problem, i remember some words in the corelan post about unicode :
And then the fuzzer will become  :
Let's see how a lucky we are
As we can see that the flow of application have break at the offset 011A7D7B where the offset before was the offset of the break point instruction ("\xcc"). It have mean that all of our fuzzer will execute by the application.

The conclusion is now we have a full control of this application's flow, now we will landing the shellcode, in order to create a shellcode in unicode application, we need an special encoder like as alpha2 encoder, but the encoder needs a register that points directly at itself. In this state we can't find a register that points directly to the current location ("011A7D7A"), so where we must landing our shellcode?
We need to modify one of the registers in order to make it points directly to the encoded shellcode. Here we will modify EAX registers.

Now we search the register which have points almost at the current location now, Let's dump the data of all registers and look at the EPB register's data
Look like a good points location. Now we need to put the value of ebp into eax, but even if we did it, the eax register still haven't points directly to the encoded shellcode. So we will add 100 byte to the eax register and then we can use some padding to put the shellcode exactly where it needs to be.
In order to do that we need the following code :
Now search the byte of padding which allowing the EAX register points directly to the encode shellcode, the provisional fuzzer is :
Look what's happening with debugger
It's look like that our fuzzer have position on EAX register, but we still haven't find the direct position of it, now let's dump the data of eax register
Our fuzzer have point directly to the eax in offset 011A8EC4, meanwhile the first of the data "\x43" from our fuzzer was beginning from offset 011A8EB4, may be we must add 10 byte in the "\x42" data in our fuzzer
Look again what's happening with debugger
Hem, maybe we excess 2 byte from our fuzzer, now let's change a bit of the fuzzer
And the result is
It's look better than before ;)
Now we have the direct access to the eax register, and then we will generate the encoded shellcode using alpha2 encoder.
Ok, now let's combine that all and see what's happenning?
And the result is ^_^