Was API hooking done as needed for Stuxnet to work? I don't think so

Question

Caveat: I am a political science student and I have tried my level best to understand the technicalities; if I still sound naive please overlook that.

In the Symantec report on Stuxnet, the authors say that once the worm infects the 32-bit Windows computer which has a WINCC setup on it, Stuxnet does many things and that it specifically hooks the function CreateFileA(). This function is the route which the worm uses to actually infect the .s7p project files that are used to program the PLCs. ie when the PLC programmer opens a file with .s7p the control transfers to the hooked function CreateFileA_hook() instead of CreateFileA(). Once Stuxnet gains the control it covertly inserts code blocks into the PLC without the programmers knowledge and hides it from his view.

However, it should be noted that there is also one more function called CreateFileW() which does the same task as CreateFileA() but both work on different character sets. CreateFileA works with ASCII character set and CreateFileW works with wide characters or Unicode character set. Farsi (the language of the Iranians) is a language that needs unicode character set and not ASCII Characters. I'm assuming that the developers of any famous commercial software (for ex. WinCC) that will be sold in many countries will take 'Localization' and/or 'Internationalization' into consideration while it is being developed in order to make the product fail-safe ie. the software developers would use UNICODE while compiling their code and not just 'ASCII'. Thus, I think that CreateFileW() would have been invoked on a WINCC system in Iran instead of CreateFileA(). Do you agree?

My question is: If Stuxnet has hooked only the function CreateFileA() then based on the above assumption there is a significant chance that it did not work at all? I think my doubt will get clarified if: my assumption is proved wrong, or the Symantec report is proved incorrect. Please help me clarify this doubt.

Edit: For more clarity of my question and what I'm looking for.

Is it possible that the WinCC STL Editor be programmed in the following way?

//Pseudocode Begins
if (locale == ASCII Dependent) //like US, UK, Australia etc.
{
     CreateFileA(); //with appropriate parameters
}
else if (locale == UNICODE Dependent) //like Middle East, China, Japan etc
{
     CreateFileW(); //with appropriate parameters
} //Pseudocode ends

If it is possible then does it follows that Stuxnet would work appropriately in the US but not in China or Japan or Iran?

Answer 1

Many technical works are carried out all in English- it is the lingua franca of programming. It is not particularly uncommon at all for foreign teams to work, code, and document exclusively in English. For example, look at the Lua project, written by a bunch of Brazilians. Documentation? English only. Filenames? All English. And the PLC code would not support Unicode either, so it's not like the Iranians had the option to work all in Arabic.

It does surprise me that it didn't hook CreateFileW, but I suppose that it knew in advance that WinCC only uses CreateFileA.

Answer 2

Note that CreateFileA and CreateFileW differ only in the character set of the filename itself. The actual contents of the file are just bytes in both cases, and free to be interpreted by the program in whatever way it likes.

In fact, in all modern Windows, the *A functions are typically just very thin wrappers around the *W functions where all they do is convert the arguments to/from Unicode.

Answer 3

I'm assuming that the developers of any famous commercial software (for ex. WinCC) that will be sold in many countries will take 'Localization' and/or 'Internationalization' into consideration while it is being developed in order to make the product fail-safe ie. the software developers would use UNICODE while compiling their code and not just 'ASCII'. Thus, I think that CreateFileW() would have been invoked on a WINCC system in Iran instead of CreateFileA(). Do you agree?

Today, yes. But WinCC was first introduced in 1995. Back then, Unicode was still quite new and it wasn't common that programs supported unicode. Among other reasons, so they would be run on Windows 95/98/ME, which never supported unicode.

Instead, people used codepages to display non-latin characters: Simply put, you'd tell the OS that your process was using codepage 1256 now and the operating system would display characters in the 128..255 range as farsi characters (if you have the right fonts).

My question is: If Stuxnet has hooked only the function CreateFileA() then based on the above assumption there is a significant chance that it did not work at all?

Whoever created Stuxnet didn't just write a worm that would hook into CreateFileA and hope WinCC would call CreateFileA eventually. I'm sure they had a copy of exactly the version of WinCC they were targeting. They probably debugged it to find out which function to hook into. If WinCC would have been built using unicode, they'd have hooked into CreateFileW instead.