Hello readers,

Pop a calculator here, pop one there! I’m focusing on exploit development at the moment, because I love calculators ;-). My exploit targets the vulnerability described in CVE-2013-3934:

Stack-based buffer overflow in Kingsoft Writer 2012, as used in Kingsoft Office 2013 before, allows remote attackers to execute arbitrary code via a long font name in a WPS file.

It’s a SEH-based exploit and works reliably on all Windows versions up to Windows 8:


While working on this exploit, I had to look twice at this mona.py output:


Looks like the devs missed one small module (IRLAS.dll) when compiling with SafeSEH options, which leads to a complete SafeSEH protection bypass. So here’s the complete pwnage script – have fun 🙂

Update #1

Thanks mood for your comment!

I double-checked my exploit and recognized a small difference. First I’ve tested it against a fully patched Windows 7 x64 (German) using an arbitrary .wps file generated on my Linux box using Python 2.7.5:

This results in a successful code execution:


If you execute the same script on a Windows box using e.g. Python v2.7.6, the exploit fails:


If you compare both exploit files, you’ll recognized some 0x0D that are added in the Windows-Version of the exploit:


But these 0x0Ds are only added in the head and the tail, and these are basically not present in the Python script, e.g.:

Since I generate all my exploits on a Linux machine I did not recognize this behavior, and unfortunately I don’t know where these come from. If someone knows why this happens, feel free to leave a comment below!

CVE-2013-3934: Kingsoft Office Writer v2012 Buffer Overflow SafeSEH Bypass Exploit
Tagged on:             

4 thoughts on “CVE-2013-3934: Kingsoft Office Writer v2012 Buffer Overflow SafeSEH Bypass Exploit

  • March 19, 2014 at 10:24 am

    I’ve tested this POC a few times now on both Win XP SP3 and Win 7 SP1 machines on Kingsoft Office Writer 8.1.3385 & 8.1.3030 and it most definitely does not work, let alone even provide a crash.

    Mind double checking your POC?

  • March 22, 2014 at 11:49 pm

    I’ve edited the blog article – looks like there is a problem with added 0x0Ds, if you’re using the Python script on Windows.

    • March 23, 2014 at 5:58 am

      ahhhh. As soon as you pointed out the differences, the cause is pretty clear.  You should be opening your out file in binary mode (wb), not ascii (w) (;

      I suppose windows converts what it sees as ascii line endings to its native CRLF (\x0d\x0a), while linux only uses LF (\x0a) which leaves the exploit as expected.

      Thanks for taking a second look.

      • March 23, 2014 at 10:41 am

        This makes sense and works smoothly. I’v updated my exploit script – thanks for the hint :-)!


Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.