Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question
    
there is a significant chance that it did not work at all? I think there's ample evidence that it did in fact work. For one thing, if it hadn't worked, it's unlikely that anybody would have ever noticed it. Or are you suggesting that Symantec's analysis is wrong and there was some other mechanism involved? –  Caleb Apr 15 '12 at 0:32
    
@Caleb People say Stuxnet worked on the basis of 'correlation'. The timeline of the dip in the no. of centrifuges was correlated with Stuxnet's timeline. No one has ever proved/disproved the 'causality'. It is difficult to establish causality between Stuxnet and the dip in the no. of centrifuges based only on open-source data. I'm just questioning everything to either prove or disprove causality. –  The Kaykay Apr 15 '12 at 0:51
add comment

3 Answers

up vote 3 down vote accepted

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.

share|improve this answer
    
I'm not sure about your statement "The PLC code would not support Unicode either." I dug into the Siemens Automation Chat Forum for the details about programming using WinCC and found this document. cache.automation.siemens.com/dnl/Dk2NTYzAAAA_27251400_DL/… On the second page it says "1. You can only edit projects which were created with the English or Japanese character set. 2. Please note that you use the single byte format when entering addresses" and other important points. Does that convince you about my doubt? Thanks for the reply! –  The Kaykay Apr 14 '12 at 11:14
    
Although I must say that there is no 'Persian' or 'Farsi' service pack available for WinCC. But I don't know how much it would impact my original question. –  The Kaykay Apr 14 '12 at 11:15
1  
@TheKaykay: No, it proves my assertion that all the code would be in English. Obviously WinCC does not support coding in Arabic, and the developers would have had to give their files Latin-alphabet names, so WinCC could use CreateFileA to create them. –  DeadMG Apr 14 '12 at 13:01
1  
@TheKaykay: Most likely, they just set the OEM character page to Japanese to support that language. –  DeadMG Apr 14 '12 at 15:21
2  
@TheKayKay: Nope, not at all. Those guys almost certainly knew the exact WinCC, Windows, etc versions in use, had a copy, and reverse-engineered it significantly- for example, you can write or download a trivial tool to see what Windows functions a given executable uses. They most certainly tested it before use. Many hacks and other things work this way. It does not surprise me or introduce doubt at all that in a totally ideal world, something different should have been hooked, given that we know in advance that it was not ideal in exactly this respect. –  DeadMG Apr 14 '12 at 23:43
show 9 more comments

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.

share|improve this answer
    
Yes absolutely it would be dependent on the filename and not the content of the file. And, CreateFileA() internally calls CreateFileW() Be the filename in Unicode or not CreateFileW() would be called anyway. But CreateFileA() would be called is not necessarily true right? But it would all depend on UNICODEwas used in compiling WinCC or not. Is there any possibility that 'locale' configuration would affect which of the two functions will be called by WinCC? Can WinCC be configured in a way to call CreateFileA() in the US and CreateFileW() in Japan or the Middle East? –  The Kaykay Apr 14 '12 at 13:23
    
Technically it's possible to choose between calling CreateFileW and CreateFileA at runtime, but in practise it never happens. It's far too complicated and since one is just written in terms of the other, there's just no benefit (i.e. if you ever "need" the CreateFileW version, it's easier to just call CreateFileW in all situations). In most situations, the *A versions are almost always used by applications that were originally written before Windows 2000/XP became the dominant versions of Windows (it's harder to convert from *A to *W than to use *W from the start). –  Dean Harding Apr 15 '12 at 5:50
    
Okay. But we don't know when was WinCC's STL Editor written. So anything is possible. They might have written using only *A versions or they might have used *W versions too. But since by default WinCC supports five languages English, German, Spanish, French and Italian and also has WinCC Asian version for Japanese, Chinese and Korean, can we say that WinCC uses only *A versions of APIs? –  The Kaykay Apr 15 '12 at 9:08
add comment

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.

share|improve this answer
    
thank you great answer. Stuxnet looks specifically for WinCC Step 7 version. I checked on the Siemens website and found WinCC S7 SP3 was released in Dec2011, SP2 was released in Sep 2010 . Stuxnet was estimated to have been developed in 2008 by computer experts. I can safely say that the WinCC in operation in Iran is not the one made in 1995? So either WinCC only works with CreateFileA in all the locations or they use some method to invoke CreateFileW whenever needed? Would you agree? –  The Kaykay Apr 14 '12 at 13:42
    
Secondly, perhaps you can be sure that the developers had exact version of WinCC they were targeting. But can you say with the same conviction that Symantec used that exact version in their test-setup they created in their Culver City office? I don't think you can say that with absolute conviction. :-) perhaps I'm wrong... –  The Kaykay Apr 14 '12 at 14:06
    
@TheKaykay: You have a wrong impression of how software development works. They don't rewrite WinCC from scratch for every new version. They started development in the 90's, and at that time, it was common to write non-unicode software- So they wrote non-unicode software. And that kind of software doesn't get magically unicode-aware just by adding new features or putting a new version label on it. –  nikie Apr 14 '12 at 17:04
    
Yeah but they do try to do away with the deprecated practices of software development in their newer versions of software. 95 to 2008 is 13 years. They are releasing the service pack in about a years time, as mentioned above. If they keep all the legacy stuff without phasing out then I think they are too incompetent. –  The Kaykay Apr 14 '12 at 17:20
1  
You are looking at industrial software, which tends to get written once against certain hardware and not fixed. And you are looking at a 3rd world country which has older hardware and older OS versions. I would be more surprised if they were running on Win7x64 than if they were running on 98SE. –  Wyatt Barnett Apr 14 '12 at 17:23
show 7 more comments

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.