text:
This article is an open-access article distributed under the terms and conditions of the Creative Commons Attribution license (http://creativecommons.org/licenses/by/3.0/).
Stuxnet was the first targeted malware that received worldwide attention for causing physical damage in an industrial infrastructure seemingly isolated from the online world. Stuxnet was a powerful targeted cyber-attack, and soon other malware samples were discovered that belong to this family. In this paper, we will first present our analysis of Duqu, an information-collecting malware sharing striking similarities with Stuxnet. We describe our contributions in the investigation ranging from the original detection of Duqu via finding the dropper file to the design of a Duqu detector toolkit. We then continue with the analysis of the Flame advanced information-gathering malware. Flame is unique in the sense that it used advanced cryptographic techniques to masquerade as a legitimate proxy for the Windows Update service. We also present the newest member of the family, called Gauss, whose unique feature is that one of its modules is encrypted such that it can only be decrypted on its target system; hence, the research community has not yet been able to analyze this module. For this particular malware, we designed a Gauss detector service and we are currently collecting intelligence information to be able to break its very special encryption mechanism. Besides explaining the operation of these pieces of malware, we also examine if and how they could have been detected by vigilant system administrators manually or in a semi-automated manner using available tools. Finally, we discuss lessons that the community can learn from these incidents. We focus on technical issues, and avoid speculations on the origin of these threats and other geopolitical questions.
In June 2010, the Stuxnet malware [
It turned out that Stuxnet was not the single example of its kind. Thanks to the increasing attention, the shared knowledge and growing efforts of the malware research community, several new targeted threats that are related to Stuxnet in some way have been discovered. In October 2011, our CrySyS Lab in Budapest, Hungary discovered Duqu, a malware with striking similarities to Stuxnet, but apparently with a different objective. Indeed, Duqu does not aim at causing physical damage, but it is an information collecting malware used for cyber espionage. Interestingly, we discovered Duqu during a forensics investigation at a
As expected, Stuxnet and Duqu were not unique in their purpose, and since they came to light, more targeted malware attacks have been discovered. In May 2012, we participated in an international collaboration to investigate a recent threat called Flame (which at that time we named sKyWIper). Flame is another information-collecting malware built on a platform different from that of Stuxnet and Duqu. Yet, researchers found identical code segments in an early Stuxnet variant and Flame, making us believe that Flame belongs to the same cyber espionage operation and it is indeed member of the Stuxnet family. Flame received worldwide attention of security researchers and practitioners due to its advanced spreading techniques based on masquerading as a proxy for Windows Update [
Another information collection malware, called Gauss [
A common characteristic of Stuxnet, Duqu, Flame, and Gauss is that they have all been active for an extended period before they were actually discovered. This stealthiness is achieved by carefully avoiding the generation of visible anomalies. Yet, as we show in
Stuxnet and its cousins confront the IT security community with many challenging questions. We summarize the lessons that we could learn from these incidents in
Note that the discovery and analysis of Duqu, as well as the design of the Duqu Detector Toolkit and the lessons learned from the Duqu incident have been published in our earlier workshop paper [
In September 2011, a European company approached us to help them in the investigation of a security incident that occurred in their IT system. The NDA that we signed with the company does not allow us to reveal more information about the company itself and the details of the incident. However, the company allowed us to share information about the root cause behind the incident, which was a previously unknown malware. When we discovered this malware during the investigation of the incident, we gave it the name Duqu, because it has an infostealer component that creates files in the infected system with filenames starting with the string "∼DQ".
Our main contribution related to Duqu is threefold:
In the rest of this section, we give a brief overview of our first Duqu analysis results, focusing on the evidence that we found on the similarity between Duqu and Stuxnet, and we describe our Duqu detector toolkit. More technical details can be found in our full technical report [
In order to investigate the reason of the incident at the company that requested our help, and to be able to fix the system such that the same type of incident cannot happen again, we were allowed to access the hard drive of an infected computer. We produced a virtualized copy of the affected computer, which allowed us to revert the machine to a former state at any point during the analysis.
We hypothesized from the beginning that the malware loads a kernel driver, so the first task was to find that driver. The driver called cmi4432.sys became suspicious, but it was inactive on the particular computer we investigated, and it was digitally signed. Therefore, we performed a systematic search: we deleted groups of kernel drivers until we found that the malware was no longer active, and then refined the search iteratively to pinpoint the driver that was part of the malware. This led to the identification of another driver called jminet7.sys. After that, we recognized that cmi4432.sys is indeed connected to the threat. We also discovered some suspicious PNF files that did not have any corresponding INF files installed on the system. (Windows INF files contain setup information for programs and drivers in textual form, while PNF files contain the same information in a pre-compiled format. Normally, PNF files are generated automatically by Windows from INF files when they are copied on the computer.) Finally, we uncovered three main groups of malware components: a standalone keylogger, a group of objects related to jminet7.sys, and another group of objects related to cmi4432.sys. The keylogger is a standalone executable that was found on an infected computer. It contains an internal encrypted DLL, which provides the keylogging functions, whereas the main executable injects the DLL and controls the logging process. The objects of the jminet7 group work as follows: In the registry, a service is defined that loads the jminet7.sys driver during the Windows boot process. This kernel driver then loads configuration data from itself and from the registry, and injects code from a DLL called netp191.pnf into a system process. Finally, some configuration data is stored in an encrypted configuration file called netp192.pnf. The objects of the cmi4432 group essentially exhibit the same kind of behavior, but they use the files cmi4432.pnf and cmi4464.pnf.
This sort of behavior was very similar to the operation of Stuxnet. Our suspicion that Duqu and Stuxnet are related grew rapidly when we discovered that Duqu also injects code into the lsass.exe process; it uses non-existent virtual files, and it uses the same hooks from ntdll.dll as Stuxnet. In addition, as we mentioned before, the driver cmi4432.sys had a valid digital signature on it. The corresponding certificate belonged to a Taiwanese company that did not seem to be the author of the driver, so we suspected that the signature was generated with a compromised private key. The only known case at that time where malicious kernel drivers were signed with possibly compromised keys was the case of Stuxnet, and the compromised keys belonged to Taiwanese firms in that case too.
Given the strong evidence for a highly sophisticated malware, we decided to carry out a deeper analysis of Duqu to see if it is really related to Stuxnet. The potential connection between the two incidents urged us to reveal Duqu's existence to the security community as soon as possible. Thus, we set 10 days as a hard deadline for ourselves to finish the analysis; we did not aim at completeness, rather we wanted to understand as much as possible within 10 days and then release our analysis report. Below, we summarize the key findings of our analysis. Due to space limitations, we keep the discussion brief, and we refer the interested reader for more details to our technical report [
During the initialization of Duqu, three decryption operations are performed, exactly as in Stuxnet. In case of Duqu, the compiled-in configuration is decrypted with a fixed decryption routine and it does not use any specific key, the variable configuration in the registry is decrypted with a key loaded from the compiled-in configuration, and the PNF file netp191.pnf is decrypted with the same key loaded from the registry. The situation is the same for Stuxnet, the only difference is that the key loaded from the registry is different, and the decryption routines in Stuxnet are slightly different as well. In addition, in both cases, further configuration parameters are stored in a PNF file (in case of Duqu, this is netp192.pnf for the jminet7 variant and cmi4464.pnf for the cmi4432 variant), which starts with the magic number 0xAE790509. The same magic is used in Stuxnet.
The injection target selection of Duqu and Stuxnet are very similar. Both Duqu and Stuxnet first check for known anti-virus products. Their checklists are essentially the same (even ordered in the same way), however, Rising Antivirus appears as an additional element in the list of Duqu. The injection target is then selected from a list of system processes including svchost.exe, lsass.exe, and winlogon.exe. The same list is used by Stuxnet. In addition, after injecting the malicious DLL payload in the target process, export 1 of the DLL is called in both cases.
The DLL in netp191.pnf contains 8 exports, while that in cmi4432.pnf has only 6 exports. In case of Stuxnet, the number of exports was 32; we suspect that the reason for this difference is the additional PLC functionality in Stuxnet, which is completely missing in Duqu. Nevertheless, the exports in Duqu show strong similarities to the non-PLC related exports in Stuxnet. For instance, exports _1 and _8 of netp191.pnf of Duqu are essentially the same as exports _1 and _32 of Stuxnet's oam7a.pnf. In both cases, these exports are related to RPC communications and they differ only in a few bits.
Both Duqu and Stuxnet use the trick that instead of calling external functions by their name, they refer to external functions by their checksum. In other words, an external function is imported by matching its checksum to a particular value. This technique makes it harder to identify calls to external functions in the malware, because the names of common system calls do not appear in the code. While both Duqu and Stuxnet use this technique, their checksum calculation algorithms seem to be different.
The hook functions work in the exact same way in Duqu and in Stuxnet. In both cases, they use non-existent virtual files for libraries loaded from modules. Both Stuxnet and Duqu use the same 8 hooks in ntdll.dll during the injection process. Hooks used by rootkits are usually similar; however, the exact list of the hooks is specific to a given rootkit family and can serve as a fingerprint. Note that we discuss hooks in more details in
Duqu has a backdoor covert channel control communication module that is used to send information to and receive commands from a remote Command and Control (C&C) center. In our case, the remote C&C server was located at the address 188.8.131.52, but later evidence shows that other instances used different servers. The communication protocol uses both HTTP port 80 and HTTPS port 443, and it is encrypted. The communication through port 80 starts with a valid HTTP request, followed by the transmission of (possibly encrypted) binary data obfuscated as jpeg images.
Unlike Stuxnet, Duqu has a keylogger component that steals information from the infected system. The keylogger not only logs keystrokes but also regularly saves screenshots and packs other types of information. It stores data in the %TEMP% directory of the computer in a compressed format. The executable of the keylogger contains an embedded jpeg file. The jpeg image is not complete, the readable text shows "Interacting Galaxy System NGC 6745". This refers to a picture, taken from NASA, showing two colliding galaxies. Within the jpeg file, after the partial image, an encrypted DLL can be found which contains the main keylogger functions.
Duqu is a sophisticated malware that has avoided detection for a period of time that shocked malware analysts. The exact start of the Duqu operation is still unsure today, but the stealthy period of the malware spans several months, maybe years. The authors achieved this robustness with rigorous quality control, the use of advanced obfuscation techniques and thorough cleaning of activity traces.
Yet, thorough investigations uncovered several points where the malware authors could not fully cover their traces. We collected our observations and developed a set of heuristic tools to detect Duqu and, with a high chance, other variants of the same platform, including Stuxnet. Given the potential impact of false negatives, our tools aim at completeness rather than precision, and the results of the detection tools require a careful investigation by security experts.
At the time of this writing, we provide six tools [
The existence of ∼DN1.tmp shows that the keylogger/infostealer component might be installed on the computer. Our tool checks files recursively in predefined temporary directories,
∼DQ* files might be related to the keylogger/infostealer log files. Some parts of the files are checked against Duqu's magics.
∼DF* are compressed files created by a yet unknown part of Duqu and contain information gathered at the target computer. Our tool checks those files if they begin with a modified bzip magic, which shows that the temporary file is likely related to Duqu.
We tested our toolkit on virtual machines infected by our Duqu sample and an available Stuxnet sample (Stuxnet.A). All the six tools in the toolkit generated alarms for Duqu-infected machines. For the Stuxnet-infected machines, naturally, the Duqu signature scanner and the temporary file detectors did not signal any problems, however, the remaining four tools raised alarms. In all cases, we had a small number of false positive alarms, e.g., we found a few innocent PNF files without a corresponding INF file.
Our Duqu detector toolkit has been downloaded from more than 12,000 distinct IP addresses distributed over 150 countries. The highest number of downloads originate from Vietnam, followed by the US, France, Iran, India, Poland, Norway, Hungary, Indonesia, and Great Britain.
Multiple security vendors pursued technical analysis of Duqu after our initial work. The most detailed results are from Symantec [
Multiple other Duqu infections were identified around the world, about 20 in total, most of them located in Europe and the Middle East. We had no access to new samples, and thus this information is based on the publicly available reports of the anti-virus industry. Based on these reports, we can say that Duqu and Stuxnet are like malware Lego-kits. Both of them are based on small components assembled together, they exist in several different versions with slight modifications, and they are created to perform their activity in a fast and efficient way. They are designed to avoid identification using individual modifications and very careful error processing. This type of thinking about the threat was reinforced by Kaspersky in their report [
The zero-day exploit within the Duqu dropper was confirmed by Symantec and Microsoft in the last days of October 2011, and fixed by a Microsoft patch [
In May 2012, our team participated in the analysis of an as yet unknown malware, which we internally called sKyWIper, and which later became known as Flame. Based on the initially received information we realized that the malware is an important part of an attack campaign. When we started the analysis, we did not know how many countries were affected, but we suspected that it was not limited to a single country. Our suspicion was based on indications that pieces of the malware were probably identified and uploaded from European parties onto binary analysis sites in the past. In particular, the file WAVESUP3.DRV that belongs to Flame was first seen in December 2007 in Europe by the Webroot community, and later in April 2008 in the United Arab Emirates and in March 2010 in Iran. During the investigation, we received information about systems infected by Flame in different countries, including Hungary, our home country. This clearly justified our participation in the investigation efforts.
Flame's constitution is quite complex with a large number of components and substantial size of some of its files. Therefore, providing its full analysis in a limited amount of time was infeasible with our resources. Our goal was to get a quick understanding of the malware's purpose, and to identify its main modules, storage formats, encryption algorithms, injection mechanisms and activity in general. We published our analysis results in a detailed report [
In the remainder of this section, we give a brief overview on the analysis results of Flame, and we also discuss the MD5 hash collision attack mentioned above.
Flame is another information-stealer malware with a modular structure, targeting MS Windows based PCs, and incorporating multiple propagation and attack techniques, as well as special code injection methods. It gathers intelligence in multiple ways, including logging key strokes, saving screen shots, switching on the microphone and the web camera (if available) to record audio and video, and browsing through the storage devices attached to the infected computer. It also switches on the Bluetooth radio if available on the infected computer, and saves information about neighboring Bluetooth enabled devices. In addition, it can also use the Bluetooth radio to send information about the victim system to a nearby device (possibly controlled by the attackers).
Similar to Stuxnet and Duqu, Flame uses compression and encryption to obfuscate its files. In particular, we observed the usage of 5 different encryption methods (and some variants), 3 different compression techniques, and at least 5 different file formats (not counting Flame's proprietary file formats). Quite interestingly, some of the intelligence gathered by Flame is stored in a highly structured format in SQLite databases. Flame sends the information it collected to remote C&C servers if a network connection is available. Otherwise, it can also save the gathered intelligence on USB sticks, through which it can infect other computers and use their network connections to communicate with the C&C servers.
As our team played a significant role in the discovery and analysis of Duqu, we were curious about the relationship between the two pieces of malware. It turns out that Flame and Duqu have many differences, and it is likely that they were
Despite these differences, we cannot exclude the possibility that the attackers hired multiple, more or less independent development teams for the same purpose, and Flame and Duqu are two implementations developed for the same requirement specifications. This may be an approach to increase the robustness of an operation, which can persist even if one of the two (or more) implementations is uncovered. In addition, Flame uses the same print spooler exploit (MS10-061) and LNK exploit (MS10-046) to spread locally as Stuxnet, and it seems that a 2009 variant of Stuxnet included a module that was created based on the Flame platform [
Below, we give some details about the structure and operation of Flame, focusing on the differences with respect to Duqu and Stuxnet:
Unlike Duqu, Flame consists of a large number of modules, and many of those are installed on victim machines persistently, whereas Duqu does not store modules locally, but likely downloads them on an on-demand fashion. The most comprehensive list of Flame modules has been published by researchers form Kaspersky Lab [
To the best of our knowledge, no dropper component of Flame was ever made available to the research community. It is even possible that no dropper was identified at all. Thus, we do not know how Flame infects the first computer in a network. However, once infiltrated, Flame can spread locally by various methods. First of all, it uses the same print spooler exploit (MS10-061) and LNK exploit (MS10-046) as Stuxnet. Second, it can turn an infected computer into a proxy for Windows Update. As a result, computers in the local network try to obtain updates for Windows from the infected computer, which sends them the malware instead. In order to be successful, the installer of the malware must be digitally signed such that it appears to be created by Microsoft. For this purpose, the attackers created a private signing key and a fake certificate for the corresponding public signature verification key that appears to be a valid certificate issued by Microsoft. We will explain how the attackers managed to obtain such a fake certificate in
The modules of Flame as described by researchers from Kaspersky Lab.
|Enumerates Bluetooth devices around the infected machine. May turn itself into a beacon: announces the computer as a discoverable device and encode the status of the malware in device information using base64.
|Records audio from existing hardware sources. Lists all multimedia devices, stores complete device configuration, tries to select suitable recording device.
|Selects one of the methods for infecting media,
|Creates autorun.inf that contains the malware and starts with a custom "open" command. The same method was used by Stuxnet before it employed the LNK exploit.
|Creates a "junction point" directory with desktop.ini and target.lnk. The directory acts as a shortcut for launching Flame.
|Creates backdoor accounts with login "HelpAssistant" on the machines within the network domain if appropriate rights are available.
|Infects machines using pre-defined user accounts. The only user account specified in the configuration resource is "HelpAssistant" that is created by the Limbo attack.
|HTTP server that responds to /view.php and /wpad.dat requests.
|Listens on network interfaces, receives and saves NBNS packets in a log file. Has an option to start only when Munch is started. Collected data is then used for replicating by network.
|Communicates with Snack and Munch, and provides facilities for handling different events that come from those modules. Together with Snack and Munch, implements a replication method that is based on the Windows Update service.
|Configuration section that contains the list of all additional modules that should be loaded and started.
|Creates a directory listing of the infected computer.
|Creates a list of files using several filename masks.
|Logging facilities.
|When an Internet connection becomes available, it connects to the C&C servers, downloads new modules, and uploads collected data.
|Identifies programs that may be hazardous to Flame,
|Attack parameters or properties.
|Bunny Dbquery Driller
|The purpose of these modules was not known at the time of this writing.
Flame injects code into running system processes, but the code injection method is different from that of Duqu. In case of Duqu, ZwCreateSection and ZwMapViewOfSection were used to copy code, and LoadLibrary and LoadLibraryEx were used to load a library into running processes. These techniques can easily be detected as the inserted DLLs appear in the PEB's InLoadOrderModuleList, InInitializationOrderModuleList or InMemoryOrderModuleList. In case of Flame, the code injection mechanism is stealthier, and the presence of the code injection cannot be determined by conventional methods such as listing the modules of the corresponding system processes (
In case of Flame, hooking is the result of code injection that is performed in a custom way as discussed previously. All of the hooks (IAT and inline) belong to explorer.exe according to various anti-rootkit tools. For example, the tools XueTr and Gmer report that there is an inline hook in the shell32.dll module of explorer.exe at address 0x7C9EF858 pointing to 0x01F6041C. It is indicated by an unconditional jump instruction (jmp) to the target address. Note that it can be either a real hook or just a coincidence that the injected code contains the opcode of a jump at that address. More details about hooks are discussed in
Flame uses mutexes to make sure that only one instance of it is running. Mutexes are created for injected system processes (winlogon.exe, services.exe, explorer.exe) and for proprietary files. For example, for injected system processes, the following naming convention is used: TH POOL SHD PQOISNG #PID#SYNCMTX, where #PID# refers to the process ID of the system process the mutex belongs to. Other mutexes created by Flame are referenced in different manner (e.g., DVAAccessGuard51EF43_ ST_*, Dynamic*, msstx32*, where * stands for random characters), but we omit their detailed discussion here.
The malware creates encrypted files with names starting with ∼RF in the Windows/temp folder. This operation seems to be automatic, but perhaps it may also be remotely controlled. After decryption, the files appear to be SQLite databases, storing information on drivers, directories, and file names discovered on the infected machine. In addition, SQLite and unknown "CLAN" databases are used to store attack related information, such as attack parameters, attack logs with type and result (success or failure) of different attack methods, attack queues with remaining attacks to try and trial intervals, credentials (e.g., user names and passwords), and registry settings.
Flame uses 5 different encryption algorithms to obfuscate its code and hide its data stored in files. All of these encryption methods use either simple XOR masking with a constant or simple byte substitution. The decryption keys are available in the configuration data of the malware itself, although it takes some effort to find them. We were able to reconstruct the decryption algorithm for all of these encryption methods.
The attackers took extra precautions to evade detection by security products. The list of security products the presence of which is checked by the malware is quite extensive, containing more than 300 entries. In addition, the malware chooses the extension of its files according to the detected anti-virus products. We found that it usually uses the OCX extension, but if McAfee McShield is installed, the preferred extension is changed to TMP.
As mentioned before, Flame can masquerade as a proxy for Windows Update, and by doing that, it can spread on a local network as if it was a signed update for the Windows operating system. In order to be able to generate digital signatures on the malware, the attackers created a public key—private key pair, and they managed to obtain a certificate for the public key that can be used for the verification of signed code and that chains up to the Microsoft root Certification Authority (CA). In this subsection, we give a brief overview on how the attackers obtained this fake certificate. This overview is based on the research of other researchers, and in particular, on the presentation of Alex Sotirov [
The attackers used the Microsoft Terminal Services Licensing infrastructure to obtain their fake certificate. This infrastructure allows licensing servers to obtain a certificate from a Microsoft activation server in a fully automated process. For this purpose, the licensing server generates a key pair, and sends the public key to the activation server together with other user-supplied parameters in a certificate request message. The activation server then issues the certificate for the public key and sends it back to the licensing server. The licensing server can then use the private key to sign licenses for clients, which they can use to access different terminal services. The validity of the licenses can be verified by checking the licensing server's signature and the certificate obtained from the activation server.
The signature on the certificate issued by the activation server is generated on the MD5 hash of the content of the certificate. In addition, the certificate does not contain any extensions for restricting key usage, which means that the certificate can be used for code signing applications. However, the certificate contains some MS Hydra extensions, flagged as critical, which are not supported by Windows Vista and Windows 7. Thus, in effect, the certificate can be used as it is for code signing only on Windows XP (or earlier) systems. The attackers needed to get around the problem of the Hydra extensions, and they took advantage of the weaknesses of the MD5 hash algorithm to achieve their goal. More specifically, they mounted a chosen-prefix MD5 hash collision attack by which they obtained a valid signature from the Microsoft activation server on a crafted certificate that contained a public key whose private pair was known to the attackers, and in which the Hydra extensions were covered by an unusually long IssuerUniqueID field. Thus, the verifier of this fake certificate did not detect the presence of the Hydra extensions, and hence, the certificate could be used for code signing even on Windows Vista and Windows 7.
The objective of any hash collision attack is to generate two inputs to the hash function that map to the same output hash value. In case of a chosen-prefix hash collision attack, the attacker starts with two chosen inputs that have some known difference, and then appends the so-called near collision blocks to both until the resulting extended inputs yield the same hash value. Optionally, the two colliding inputs can be further extended with the same additional data. MD5 was known to be vulnerable to this type of attack, and the feasibility of such an attack in practice was demonstrated as early as in 2008 [
In case of Flame, the two colliding inputs were two certificates. One of them contained a certificate serial number, a validity period, the string "MS" as the certificate subject name, and the attackers' public key in the chosen prefix part, while the unstructured and long IssuerUniqueID field was used to hold the near collision blocks. The other certificate also contained a serial number and a validity period, the string "Terminal Services LS" as the certificate subject name (for Terminal Services Licensing Server), and part of a random public key in the chosen prefix part, while the rest of the random public key was used for the near collision blocks. At the end, both certificates contained the MS Hydra extensions, but as mentioned before, in the first certificate, the length of the IssuerUniqueID field was set in such a way that it covered all those Hydra extensions.
Once such a colliding pair of certificates was found, the attackers sent the random public key of the second certificate to the MS activation server in an appropriate certificate request, which created the second certificate by adding the predicted serial number and validity period, the Hydra extensions, and the signature on the MD5 hash. However, since the first certificate had the same MD5 hash, the signature of the second certificate was a valid signature on the first certificate too, and the attackers could use the first certificate to sign their malware.
The biggest challenge for the attackers was to send the certificate request to the activation server at the right moment such that the server returned a certificate with the serial number and validity period that were used to generate the hash collision by the attackers. Both the serial number and the validity period depend on the time of receiving the certificate request by the server, and given the way they are constructed, the attackers essentially had a 1 millisecond window to get their request to the server. Therefore, it is very likely that they had to make multiple attempts until they succeeded, and for each attempt they had to generate a new collision pair. This probably required substantial computing power, or the attackers are in possession of a new and fast method for generating MD5 collisions. Indeed, researchers from the cryptography community confirmed that the chosen-prefix collision attack used in Flame is a new variant of a previously known method [
Masquerading as the Windows Update service is of course the worst that we can imagine as a spreading technique for a malware: What can we trust if not even the mechanism used to install security patches can be trusted anymore? Naturally, Microsoft diligently investigated its Terminal Services Licensing infrastructure, and revoked a number of its CA certificates that represented risk to its users.
Gauss was discovered by researchers of Kaspersky Lab in June 2012 during an effort to search for new, unknown components of Flame. The first public technical report on Gauss [
Gauss is a malware platform that uses a modular structure resembling that of Flame, a similar code base and system for communicating with C&C servers, as well as numerous other similarities to Flame. The malware has been actively distributed in the Middle East, with the largest number of Gauss infections in Lebanon, in contrast to Flame, which spread primarily in Iran. Similar to Flame and Duqu, Gauss is designed to collect as much information about infected systems as possible. A distinguishing feature of Gauss, however, is that it also steals credentials for various banking systems and social networks, as well as for email and instant messaging accounts, by injecting its own modules into different browsers and intercepting session data, cookies, passwords, and browser history. In particular, the Gauss code includes commands to intercept data required to work with several Lebanese banks (e.g., Bank of Beirut, Byblos Bank, and Fransabank) [
We did not participate in the discovery and first analysis of Gauss, however, right after Kaspersky Lab published its technical report on Gauss, we developed an online Gauss detector service Mysteriously, Gauss installs a font called Palida Narrow on infected computers, and while we do not know the exact purpose of setting up this font on the victim systems, it provides the means to detect if a computer is infected with Gauss by simply checking if it has Palida Narrow installed on it. Our server remotely detects the presence of the Palida Narrow font on clients by sending them an HTML page that tries to use the Palida Narrow font and that contains a URL, pointing to our server, where Palida Narrow can be downloaded from if not available locally. If after downloading the HTML page, the client also tries to download the Palida Narrow font, then the client is not infected; otherwise, the client is likely infected by Gauss. In any case, we report the result of the test to the client. This simple service has been used by more than 80,000 clients and we detected (and notified) around 100 positive cases mainly in Lebanon and in the US.
Curiously, several Gauss modules are named after famous mathematicians such as Gauss, Lagrange, Gödel, Taylor,
As another contribution related to Gauss, we deployed a service [
An intriguing feature of Stuxnet, Duqu, Flame, and Gauss was that they all remained undetected for an extended period, despite the relatively large number of infected computers. Indeed, Stuxnet, Flame, and Gauss infected several thousands of machines, yet they were not detected for at least 1–2 years. We were interested in the question of how this stealthiness was achieved by the attackers. Quite surprisingly, we discovered that no particular effort was made by the attackers to hide their presence on infected machines: a vigilant system administrator could have detected all these pieces of malware by manual inspection of the system or by using available rootkit detector tools. To illustrate this, in this section, we show how Duqu and Flame could have been detected manually or with available tools. A similar approach for detecting unknown malware but in another context (
For our demonstration purposes, we infected virtual machines with samples of Duqu and Flame. The virtual environments were identical in terms of their hardware settings and their software stack, including the operating system. As for the OS, we used 32-bit Microsoft Windows XP SP3 with the latest patches installed to the date of the detection of the corresponding malware. We manually inspected the infected systems, and we also used a relatively large collection of freely available system administration tools and anti-rootkit programs. In the following, we give more details about our evaluation process and its results.
From a malware analyst's point of view, the detection of Duqu is not so difficult as it creates multiple Local Security Authentication Server (lsass.exe) processes, out of which only one exists on a clean MS Windows system. This fact on its own makes a well-prepared security practitioner suspicious about a possible infection. Hence, the first logical step is the examination of the newborn lsass.exe processes. For this purpose, we used Sysinternals Process Monitor [
Examining the stack trace of a newborn lsass.exe process on a Duqu infected machine with Process Monitor.
|Path in C:\Windows\system32\
|ntkrnlpa.exe + 0x6a61c
|ADVAPI32.dll + 0x6bf3
|ADVAPI32.dll + 0x6c9b
|ADVAPI32.dll + 0x19a6a
|ADVAPI32.dll + 0x17ffd
|sortEA74.nls + 0x1440c
|sortEA74.nls + 0x1444d
|sortEA74.nls + 0x174b2
|sortEA74.nls + 0xc3bc
|sortEA74.nls + 0x2222b
|sortEA74.nls + 0xc41b
|sortEA74.nls + 0xc3bc
|sortEA74.nls + 0x1ad0e
|sortEA74.nls +0x10f5d
At this point, we could have used a ring 3 debugger such as OllyDbg, to attach to the malicious lsass.exe processes and to try to understand their detailed operation. However, an even more interesting question is how the code injection was achieved. This can be answered by using a very useful feature of Process Monitor: boot time logging. This feature allows us to record and interpret all relevant events that occurred during system startup. After creating such a bootlog file, one can search for various operations, events, processes and similar entities. In our case, we searched for any match in the Path field for the name sort*.nls. We found two matching events, where an svchost.exe process wanted to read IFEO (Image File Execution Options) entries from the registry under subkeys sortC1D1.nls and sortBA08.nls. This must be an anti-debugging technique of Duqu, as IFEO allows for debugging of specified processes at startup, or a way to start any (in this case malicious) executables via a built-in method of Windows. If we check the parent process of this malicious svchost.exe, we end up with services.exe, which also injected malicious payload into other processes such as lsass.exe, alg.exe, imapi.exe, spoolsv.exe and other svchost.exe instances. As this services.exe is the process where the initial installer was injected by a system module (e.g., jminet7.sys), we stopped our investigation at this point.
While the method described above does not allow a system administrator to identify the malicious system module itself, it still identifies the fact of malicious code injection into system processes. Thus, it could have raised an alarm and triggered a deeper investigation.
An interesting method to reveal fraudulent process behavior (e.g., code injection) is the identification of an increased usage of resources of certain processes with respect to a clean system. Context switch delta is one such metric that counts the number of context switches per refresh interval. Other resource usage differences can be observed by comparing the number of threads or the referenced handles in the selected processes. To demonstrate these deviations in resource usage in case of Flame, we took samples from the corresponding context switch deltas, threads and handle reference values from specific MS Windows system processes (services.exe, winlogon.exe and explorer.exe) on a clean and a Flame-infected system using Sysinternal Process Explorer [
Comparing the context switch deltas (per 1 second) of benign and Flame-infected Windows system processes. Note that we indicate only the average and standard deviation statistics.
Comparing the number of threads in benign and Flame-infected Windows system processes. Note that we indicate only the average and standard deviation statistics.
Comparing the number of referenced handles in benign and Flame-infected Windows system processes. Note that we indicate only the average and standard deviation statistics.
At this point, one can already suspect that there are injected codes inside system processes, and use again Process Monitor's bootlog to examine unusual function calls in the stack trace of these processes. By checking the corresponding stack trace of services.exe, explorer.exe and winlogon.exe, we observed unknown function calls, which are always suspicious, because MS Windows uses standard calling conventions, hence only valid DLLs or SYS files should be enumerated in the stack trace.
Unknown function calls in the stack trace of services.exe.
|Path in C:\Windows\system32\
|ntkrnlpa.exe + 0xf954e
|ntkrnlpa.exe + 0xfa0d0
|ntkrnlpa.exe + 0x6a61c
By checking the bootlog of services.exe more carefully, we found thousands of references to C:\Program Files\Common Files\Microsoft Shared\MSSecurityMgr\mscrypt.dat, C:\Program Files\Common Files\Microsoft Shared\MSSecurityMgr\ntcache.dat and C:\WINDOWS\system32\mssecmgr.ocx, however, the corresponding stack traces contain seemingly valid function calls into shell32.dll as
Confusing function calls in services.exe.
|Path in C:\Windows\system32\
|fltmgr.sys + 0x1888
|fltmgr.sys + 0x31a7
|fltmgr.sys + 0xeabc
|ntkrnlpa.exe + 0xa574e
|ntkrnlpa.exe + 0x6a61c
|shell32.dll + 0xb553
|shell32.dll + 0x1534f
|shell32.dll + 0x182ae2
|shell32.dll + 0xd978d
|shell32.dll + 0xd8e3a
|shell32.dll + 0xd9b48
|shell32.dll + 0x3cb8e
|shell32.dll + 0x3d7ff
|shell32.dll + 0x1080d
|shell32.dll + 0x1a14d6
|shell32.dll + 0x1a157b
In order to draw some conclusions, we used the Sysinternals VMMap [
Thus, in case of Flame, the method described above would have allowed a system administrator not only to identify the fact of code injection, but also to pinpoint the main module of the malware.
So far, we have discussed manual detection methods, but industrial and academic anti-rootkit tools provide another detection option. In the following, we enumerate the most common features of these tools:
The detection of hidden files and folders are the most common feature of anti-rootkit tools as almost all of them support this feature. The interpretation of the term "hidden" may vary from vendor to vendor, but they generally look for files or folders with the hidden attribute set, Alternate Data Streams (ADS), or files whose presence cannot be revealed by standard API calls but which can be found via metadata information (e.g, via the Master File Table in case of NTFS).
In many cases, hidden processes/threads are the result of code injection, which can be performed either via direct memory writes (patching) into the address space of the victim process (e.g., with the combination of the CreateProcess Windows API call and the ZwMapViewOfSection native API call), or via DLL loading (e.g., with the combination of the LoadLibrary and the CreateRemoteThread Windows API calls).
Note that stealthy rootkits can also hide their behavior by a technique known as Direct Kernel Object Manipulation (DKOM). As Windows represents system resources (e.g., processes, threads, timers,
Services are background processes that accept no input from users and typically run with higher privileges than normal processes. To load and maintain services, a Service Control Manager (SCM) process is executed permanently under the name services.exe. This process uses a double-linked list of objects representing the state of the running services. A malware that unlinks entries from this double-linked list makes the corresponding service hidden from known tools and standard API calls (e.g., EnumServices). Some rootkit detector tools try to identify these hidden services by discovering the unlinked objects that represent them.
Many tools (e.g., Catchme, GMER, McAfee Rootkit Stinger, Panda Antirootkit,
Hooking is one of the oldest techniques implemented in malicious codes. Basically, it manipulates the normal behavior of specified functions or events by patching call tables or codes. Below, we summarize some known hooking techniques that rogue codes typically use and anti-rootkit tools try to spot in the memory:
In order to see how effectively the existing rootkit detector tools could have been used to detect members of the Stuxnet family, we collected 33 freely available tools and tested their capacity of discovering hidden processes and different types of hooks on a machine infected by either Duqu or Flame. Appendix 7 contains the complete list of tools that we used. (Note that we deliberately excluded the well-known malware forensics tool Volatility from the list, because it requires some user interaction and we are mainly interested in fully automated detection.) One interesting general result of our experiment is that the free anti-rootkit tools from known vendors such as McAfee, F-Secure, Microsoft, Kaspersky, TrendMicro, and Panda, show weak detection capabilities on the examined malware samples. However, there are other, not so well-known tools, notably XueTr [
Detecting hidden processes/threads/modules with anti-rootkit tools.
|Tool with hidden process detection capability
|Results on Duqu
|Bitdefender Rootkit Uncover (v1.0 Beta 2)
|Catchme 0.3.1398
|CMC CodeWalker (2008)
|Gmer (220.127.116.1141)
|sort[RAND].nls in lsass.exe (PID: 1236)
|IceSword v1.20
|Malwarebytes Anti-Malware 126.96.36.19900
|McAfee Rootkit Detective 1.0
|McAfee Rootkit Stinger 10.2.0.729
|NoVirusThanks Anti-Rootkit v1.2 (Free Edition)
|Panda Antirootkit v1.07
|Respledence Sanity Check Home Edition v2.01
|RKDetector v2.0 Beta Security Analyser Tool
|Rootkit Unhooker LE v3.7.300.509
|Sophos Virus Removal Tool v2.1
|sort[RAND].nls in lsass.exe (PID: 1236)
|sort[RAND].nls (no process name)
|Sysinternals RootkitRevealer
|TrendMicro Rootkit Buster v5.0 2011
|sort[RAND].nls in lsass.exe (PID: 1236, 1176, 1048, 1416)
|Usec Radix v18.104.22.168
|sort[RAND].nls in lsass.exe (Reports Thread IDs)
An interesting result of our experiment is that
Usermode hook detection by free anti-rootkit tools.
|Tool with hook detection capabilities
|Results on Duqu
|CMC CodeWalker (2008)
|16 hooks in lsass.exe (BSoD during test)
|inline hooks in lsass.exe (PID: 1176, 1236, 1930, 2016)
|Gmer (22.214.171.12441)
|inline hooks in svchost.exe (PID: 996, 1084)
|NoVirusThanks Anti-Rootkit v1.2
|- (detects only unrelated Message hooks in csrss.exe)
|McAfee Rootkit Detective 1.0
|RKDetector v2.0 IAT API Hooks Analyser
|IAT hook in explorer.exe
|inline hooks in svchost.exe (PID: 996)
|Rootkit Unhooker LE v3.7.300.509
|IAT hook in explorer.exe
|inline and IAT hooks in lsass.exe (PID: 1236, 1176, 1048, 1416)
|Sysinternals RootkitRevealer
|TrendMicro Rootkit Buster v5.0 2011
|Usec Radix v184.108.40.206
|IAT hook in explorer.exe
|inline and IAT hooks in svchost.exe (PID: 1084, 996)
|IAT hook in explorer.exe
|inline and IAT hooks in lsass.exe (PID:1176, 1920, 2016, 1236 )
|(IAT hooks in every process use the hooked function)
|CMC CodeWalker (2008)
|- (BSoD during test)
|Gmer (220.127.116.1141)
|inline hook explorer.exe
|NoVirusThanks Anti-Rootkit v1.2
|- (detects only unrelated Message hooks)
|McAfee Rootkit Detective 1.0 (2005-2007)
|RKDetector v2.0 IAT API Hooks Analyser
|Rootkit Unhooker LE v3.7.300.509
|inline and IAT hooks in explorer.exe
|Sysinternals RootkitRevealer
|TrendMicro Rootkit Buster v5.0 2011
|Usec Radix v188.8.131.52
|IAT hook in explorer.exe
|inline and IAT hooks in explorer.exe
|(IAT hooks in every process use the hooked function)
Stuxnet and its cousins raise a number of challenging questions to the IT security community. It must be clear that the currently used security mechanisms are not effective enough to detect advanced targeted attacks. In particular, both code signing as a means to establish the software trustworthiness and signature-based malware detection have serious limitations, which we discuss below in more details. We also identify the current information asymmetry between the attackers and the defenders as a major reason for the success of targeted attacks, and the reluctance to share forensic data and incident information by victims as a major barrier to effective incident response at a global level. Finally, we discuss the consequences of the advanced cryptographic tools used in Flame and Gauss.
Code signing is extensively used today to authenticate the identity of the producer of a software and the integrity of the code. A common assumption is that signed code can be trusted. As a consequence, many automated verification tools do not even check signed files, or they rely on the validity of signatures to filter false alarms. However, a valid digital signature does not necessarily mean that the code is trustworthy. Technically, the validity of the signature only tells the verifier that the code has been signed by someone who possesses the private key, which does not exclude the possibility that the key is compromised (as in case of Stuxnet and Duqu) or that the certificate vouching for the authenticity of the key is illegitimate (as in case of Flame). In addition, a valid signature does not tell anything about the trustworthiness of the signer, even if the key is intact and the certificate is legitimate.
Generating fake certificates is not an easy process. CAs usually follow strict policies and use various security measures to protect their services. In the case of Flame, the attackers were able to generate a fake certificate, because the CA used a weak cryptographic component, namely the MD5 hash function. However, if sufficiently strong cryptography is used, then such an attack becomes practically infeasible for the attackers. Thus, with reasonable effort, certificate forging can be made too expensive for the attackers, and less of an issue to worry about.
We believe that the management of code signing keys by software manufacturers is a much weaker point in the system. Code signing keys are often stored on developer machines that are connected to the Internet, either without any protection or protected with a password that is in turn stored in a batch file for convenience. While CAs have strict authentication policies when evaluating a certificate request, we are not aware of any periodic audits after the issuing of the certificate aiming at the verification of how the private keys are handled and used by the certificate owner. Similarly, we have not heard about any case when the certificate of a software maker was revoked due to its negligence in the key management and code signing procedures. Therefore, software companies have no real incentives to follow strict key management policies, while there is a temptation for neglecting even the basic precautions for the sake of efficiency and convenience. At the same time, it is not clear who actually should perform the auditing of software companies. Letting the CAs perform the audits would not be scalable, and it would be too costly for them. In addition, a CA can revoke the certificates of a company if it is detected negligent, but it cannot carry out any further actions against the company, which can then continue its operation and try to find another CA that would issue certificates for its code signing keys. Hence, the CA has no incentives to do strict verifications either, because it can lose clients and profit, while less diligent CAs may prosper in the market.
While we believe that, in principle, code signing is a useful feature as a first line of defense, because it raises the barrier for attackers, we emphasize that one should not fully trust code even if it is signed, and we argue that the practice of code signing today is far from being satisfactory. There exist misplaced incentives and scalability problems leading to negligent key management, which then limits the effectiveness of code signing as a mechanism to establish trust in software. Finally, we note that these problems need urgent solutions, because the attackers' demand for being able to sign their malware is expected to grow rapidly in the future, since unsigned software can no longer be installed on recent and future versions of Windows without warning messages, if at all.
Signature based malware detection is important, as it is the most effective way of detecting known malware; however, Stuxnet, Duqu, Flame, Gauss, and other recent targeted attacks clearly show that it is not sufficient against targeted attacks. In fact, the creators of high-profile targeted attacks have the resources to fine-tune their malware until it passes the verification of all known anti-virus products; therefore, such threats will basically never be detected by signature based tools before they are identified and their signatures are added to the signature database.
A solution could be heuristic anomaly detection. As we have shown in
A basic problem with anomaly detection based approaches is that they may generate false alarms, and it is difficult to filter those false positives. More work on white-listing techniques and collaborative information sharing may improve the situation. Academic research could contribute a lot in this area, because the problems require new, innovative solutions. We should also mention that, in some application areas, false positives may be better tolerated, because false negatives (
A major reason for targeted attacks to be so successful is that the information available to the attackers and the defenders of systems is highly asymmetric: the attackers can obtain the commercially available security products, and fine tune their attack until these products do not detect it, while defenders have much less information about the methods and tools used by the attackers. One challenge is, thus, to break, or at least to decrease this asymmetry either by individualizing security products and keeping their custom configuration secret, or by gathering intelligence on the attackers and trying to predict their methods. The second approach seems to be more difficult and, due to its slightly offensive nature, morally questionable. Therefore, we argue that the (white hat) defensive security community should focus more on the first approach.
One specific example in this vein would be the more widespread usage of honeypots and traps [
Once a high-profile malware incident is detected, the most important tasks are (a) to contain the threat and recover from the incident locally, and (b) to disseminate the intelligence information to mitigate the global effects of the malware. However, the problem is that once the victim of a malware attack has recovered from the incident, it has no incentive anymore to share information and forensics data. On the contrary, it prefers avoiding information sharing in order to preserve its reputation and the privacy of its sensitive data. Thus, again, the problem is related to misaligned incentives. Anecdotal evidence suggests that security vendors are often unable to obtain forensics information even if their own product detected the infection.
This lack of information sharing has negative consequences, as it practically hinders forensic analysis and efficient global response. For example, in case of Flame and Gauss, no dropper component has ever been made public, and it is possible that no dropper was identified at all, due to the lack of sharing forensic information by the victims. Consequently, the vulnerabilities exploited by the dropper of these pieces of malware are still unknown, and hence, they cannot be patched, letting the attackers continue using them in future attacks.
In contrast to this, in case of Duqu, our laboratory emerged as a trusted mediator between the victim company and Symantec, and we managed to convince the company to share information with our help with Symantec. Ultimately, this collaboration among these three parties led to the discovery of the dropper file, and the zero-day Windows kernel exploit that it used. We could then notify Microsoft, which proposed an immediate workaround, and released a patch for Windows [
Clearly, the solution we followed does not scale. According to our experience, very few end-user firms are able to produce sanitized forensic information that can be shared for global incident response. While security vendors possess the knowledge to produce sanitized forensic material, the process is demanding and highly personalized at the moment. This implies again that trust needs to be established between end-users and security experts who are able to prepare forensics evidence while protecting the firm's identity and interests at the same time. Furthermore, to ease the load on these experts, we need to seek semi-automatic production of anonymized forensics evidence, which is a key challenge.
Flame and Gauss taught us the lesson that the attackers are not shy to use advanced cryptographic methods to achieve their goals. The MD5 collision attack that resulted in the fake public key certificate that Flame used to masquerade as a legitimate Windows Update has a very straightforward message:
As described earlier, the Gödel module of Gauss is encrypted in a way that it can only be decrypted on its target systems. Again, the possibility of such an encrypted malware has already been envisioned by researchers earlier (see, e.g., [
In this paper, we presented the brief analysis of Duqu and Flame, two pieces of malware that have been used recently in state sponsored cyber espionage operations mainly in the Middle East. We also briefly mentioned Gauss, a malware based on the Flame platform. By participating in the initial technical analysis of both Duqu and Flame, we got a solid understanding of their operation. Our analysis results suggest that Duqu is very closely related to the infamous Stuxnet worm, while Flame and Gauss appear to be more distant cousins of Stuxnet.
Besides presenting how these pieces of malware work, we also described the results of some experiments aiming at the detection of Duqu and Flame manually and by using freely available rootkit detection tools. We argued that both Duqu and Flame could have been detected by vigilant system administrators earlier, as they produce detectable anomalies on the infected system. However, those anomalies are not immediately visible, and their discovery requires some tools and know-how.
Finally, we identified a few lessons that the IT security community can learn from the incidents related to these pieces of malware. We argued that code signing as a mechanism to establish trust in a piece of software has limitations, and one should not fully trust the code even if it is signed. The problems with code signing can be traced back to issues such as negligent key management and misaligned incentives of different parties to more strictly enforce key management policies. We also argued that in order to increase the effectiveness of anti-virus products in detecting previously unknown malware, they should be extended with anomaly detection capabilities, similar to those provided by rootkit detection tools. We identified the lack of sharing incident related information and forensics data by victims of attacks as a major barrier for effective threat mitigation at a global level, and the difficulty of producing sanitized forensics information as a main related technical challenge. We also identified the asymmetry of information available to the attackers and to the defenders as the main reason of recent failures in protecting our IT infrastructure from targeted malware attacks. It may never be possible to completely remove this asymmetry, but we believe that there are helpful techniques to at least decrease it. Finally, we discussed the consequences of the advanced cryptographic techniques used in Flame and Gauss.
Avast aswMBR 0.9.9.1665 (without !avast Free Download)
AVG Anti-Rootkit
Bitdefender Rootkit Uncover (v1.0 Beta 2)
Catchme0.3.1398 (rootkit/stealth malware detector by Gmer)
CMC CodeWalker - Rootkits Detector ? 2008 CMC InfoSec
Darkspy v 1.0.5 Test Version 2006.6.5
Fsecure-BlackLight Rootkit Eliminator (BlackLight Engine 2.2.1092)
Gmer 188.8.131.5241)
IceSword v1.20
KernelDetective v1.4.1
Malwarebytes Anti-Malware 22.214.171.12400
MBR rootkit/Mebroot/Sinowal/TDL4 detector 0.4.2
McAfee Rootkit Detective 1.0
McAfee Rootkit Stinger 10.2.0.729 (Aug 6 2012)
NoVirusThanks Anti-Rootkit v1.2 (Free Edition)
Panda Antirootkit v1.07
Respledence Sanity Check Home Edition v2.01
Respledence objmon
RKDetector v2.0 Beta Security Analyser Tool
RKDetector v2.0 IAT API Hooks Analyser module
Rootkit Razor
Rootkit Unhooker LE v3.7.300.509
Virus Removal Tool v2.1
Sysinternals RootkitRevealer
SysProt Anti-Rootkit v126.96.36.199
System Virginity Verifier (SVV) 2.3 (2006)
TrendMicro Rootkit Buster v5.0 2011
Usec Radix v22.214.171.124 (2011.08.18)
Windows Malicious Software Removal Tool (Full Scan) July 2012
We are thankful to researchers at Kaspersky and Symantec for the useful discussions on various aspects of Duqu, Flame, and Gauss. Márk Félegyházi has been partially supported by the Hungarian Academy of Sciences through the Bolyai Research Scholarship.


text:
Dear All,
I'm very new to m0n0wall.
Currently, I'm running m0n0wall for Internet Cable connection.
My m0n0wall gets Dinamic IP Public from My ISP.
Now I'm confused, How can I access my m0n0wall webconsole from Internet.
I browsed to current m0n0wall IP Public using web browser (Dial up from
another ISP), but It doesn't work.
Could Anyone tell me how to configure so that my m0n0wall can be
configured from internet?

subset: commoncrawl


text:
To try the thousands of add-ons available here, download Mozilla Firefox, a fast, free way to surf the Web!Close
Welcome to Firefox Add-ons.
Choose from thousands of extra features and styles to make Firefox your own.Close
Simple TTS 0.7.2.rev36.1-signed.1-signed
by vicanfon
Simple TTS, add a contextual menu item (right-click menu option) that reads with a uk female voice the selected text. The addons uses iSpeech. http://www.ispeech.org/.
Icon credit to http://www.visualpharm.com/
This add-on has been marked as experimental by its developers
This add-on is not compatible with your version of Firefox because of the following:
About this Add-on
Version Information
Version 0.7.2.rev36.1-signed.1-signed
- Source code released under Mozilla Public License, version 2.0
- What's this?
This add-on is not compatible with your version of Firefox because of the following:


text:
     I just slapped this up olde-school-style on the wiki: https://www.noisebridge.net/wiki/Burningman so please go there and correct my impertinence(s). ;)
Love and Lingonberries,
Molly
(gonna be my first burn! please send advices and invitations, kthx!)

It may all be hearsay and rumor, but this is what i've gleaned from studiously reading the entire internets. Please edit/update/expand/make perty:

Ruuuuubin: ETA Sat 22nd -> Wed 2nd, Ardent Heavy Industries, 4:00 & A.

Rubin suggests a NOISEBRIDGE MEETUP on TUESDAY the 1st, @ Camp Ardent, 4:00 & A, "for dinner or something" HELLS YES!

Daniel Silverstein: Fri 28th -> Mon 7th, Ocean's Serene Spa, Adapt & 8:30.

Mikolaj: arriving Sun or Mon, Hookahdome on Esplanade.

David Kelso: Sat 8/29 -> Mon 9/7, Station 9 Medical, under big glowing cross @ 9:00 plaza.

Martin/ Dr. Volts arriving 26th, 3:00 Keyhole like he said, at Ranger Post Berlin. Also look for him at Ranger Outpost Tokyo Bar.

Cristoph Maier: Wed 2nd -> Sun 6th, (maybe 4:30 & P[ermian Extinction]).

Jesse Zbikowski: Sun/Mon 31st -> Mon 7th/8th, Ille Ville, 5:00 & Esplanade, some shifts @ Flaming Lotus Girls Soma Project.

Rachel McConnell: early morning Thurs 3rd -> Sun/Mon with Rebecca @ Playagon, coordinates uncertain.

Rich Gibson: Wed 26th -> overhood, Burning Man Earth Krew, near Media Mecca, by Center Camp... and Tom.

Matt Peterson: Wed 12th -> Wed 9th, Fusion Valley 3:00 Outpost/ NOC in Center Camp, member of Playatech team.

Andy Isaacson: Rathskellar, (former Spike's Vampire Bar).

Tom Longson (nym): heading out Sat 29th, arriving Sun 30th, leaving Sun 6th (latest); Burning Man Earth / Center Camp (near Media Mecca (...and Rich)); contact for iPhone beta team, Burning Man Earth iPhone app.

Peter Youngmeister: Gee... maybe the Gee-Gnome?!

Christie, aestetix, Praveen: Camp System w/ Illumination Village, 5:00 & Esplanade. Christie's present from Fri 28th -> Tue Sep 8th

mollybee: likely arriving early Friday 28th to help construct Arachnophobia, 3:30 & Center Camp, though i don't know where i'll be campinating. Has surfeit of hugs'n'kisses for all; please contact to collect.

Hotmail® is up to 70% faster. Now good news travels really fast. Try it now.


text:
Looks like you are using an old version of Internet Explorer - Please update your browser
In this award-winning series, the Creation Adventure Team discovers the wonders of God's six-day creation and the incredible answers to the mystery of the dinosaurs.
All about dinosaurs … and the Bible! In this top-quality drama, Buddy Davis and the Creation Adventure Team explore a dinosaur museum and discover incredible answers to the amazing mystery of the giant lizards!Buy Individually
Proto, the fun-loving, animatronic dinosaur, joins Buddy Davis in this story about the wonders of the six days of creation. (Bonus features only available on DVD.)Buy Individually
Checking for included items.
Checking for discount packs.
Checking for more in this series.
Kids of all ages will enjoy traveling the world with The Creation Adventure Team on an unexpected, fun-filled quest to uncover some amazing mysteries. Through the help of the hilarious ABC Cam, the wonders of the six days of Creation are clearly seen in Six Short Days, One Big Adventure. And when the Team discover the "X-Tinct" files in A Jurassic Ark Mystery, the truth about dinosaurs becomes clear! This is great entertainment for the entire family!
Gifted by God in many ways, Buddy Davis is a speaker and singer/songwriter, an adventurer, and paleo-artist. He leads the very popular "Creation Adventure" children's workshop at AiG conferences. View resources by Buddy Davis.
Answers in Genesis is an apologetics ministry, dedicated to helping Christians defend their faith and proclaim the gospel of Jesus Christ.


text:
The study, described this week in The Journal of Urology, was the largest ever to look at major and minor "genitourinary" injuries, which involve the genitals, urinary tract and kidneys. It showed that 142,144 U.S. adults went to emergency rooms between 2002 and 2010 for such injuries – about 16,000 a year.
Painful truths about genital injuries
Current Status: Published (4)
Seeded on Sun Nov 11, 2012 12:17 AM
keyboard shortcuts: V vote up article J next comment K previous comment


text:
TULSA (AP) Zac Hanson of pop group Hanson will marry longtime girlfriend, Kate Tucker, this weekend, the group's publicist said.
Katie McNeil said, Hanson, 20, and Tucker, 22, his girlfriend of five years, will marry Saturday in Atlanta.
"The couple is planning an intimate ceremony with close family and friends," McNeil said in an e-mail.
Hanson and his brothers Isaac, 25, and Taylor, 23, formed Hanson in Tulsa. They are best known for their 1997 hit single, MMMBop, which helped ignite the boy band craze.
The trio is now working on a follow-up to their 2004 album, Underneath.
Copyright 2007 The Associated Press. All rights reserved. This material may not be published, broadcast, rewritten or redistributed.


text: So I'm currently shopping for a 38L 2button suit in a charcoalish colorway. Budget is $400-500 on sale. Purpose of suit is for internship interviews in the summer and professional interviews when I graduate in 1-2 years. Plus the random wedding or whatever. I'm 6 2 155, 36" Chest, the shoulders on my shirts measure 18" Best fit I found was a 40L Hugo Boss. The shoulder were a bit wide, the back needed quite a bit taken out, the sleeves had rivets that perhaps could be pressed out as well as some torquing, the front drape was pretty awful but for $769 retail fused canvas what do you expect... Went to Northpark in Dallas today. Found: Nordstroms's had a slimmer Hugo Boss in 40L. Neiman Marcus: Nothing at any price range Barney's: Nothing at any price range... well a longer 38r for $2200 that was short Hugo Boss Store: had one gross fabric in 40L and could order a couple others in Jcrew: Had the navy colorway of the 3button Ludlow no longs. The 38R was pulling the back vent and the front a bit - Seemed too small. The 40R seemed a touch too big but no longs so didn't spend much time. Then at stores outside the mall: Jos. A Bank - what a joke Off 5th- no Longs in 38 or 40 Nordstrom Rack - no longs in anything decent 38 or 40 Tomorrow: Saks Zara Men's Wearhouse (so help me god) I may just have to keep my eyes out for the next couple months. It's a pretty bad plight.


text:
A Hovercraft Skateboard like this Air Board almost blew our minds when we first saw it and we thought...could it be the new extreme? This Hovercraft Skateboard floats 8 inches off the ground and goes up to 15 mph on concrete, asphalt, grass or shallow wet areas, but you cannot hover over water, sand, stones or dirt-filled areas due to the bottomside vacuum. Control Speed and braking on the Air Board with two levers located on the steering bar. There's also a kill switch that automatically deactivates the Air Board in case you unexpectedly "jump off", and you steer by shifting your body weight (like a surfboard or skateboard). The gas capacity is 1.3 gallons, which is good for 1 hour of use. Buy this Air Board for a price of $14,000.
October 28, 2009 1:23 PM | Scooters
Self-balancing Unicycle Solowheel Great Green Way To Get Around
Hanebrink All-Terrain Electric Bike Would Be A Good Fit For Batman
Vertrax Tracked Skateboard Concept In Production In Our Dreams
Personal Mobility Vehicles - Honda U3-X Personal Mobility Device
Email to: Ilya Pikus
Gear Patrol
Product Dose
The Cool Hunter
Outside Magazine
Besportier Brazil
Cool Material
Copyright @ besportier.com 2012 | Privacy Policy


text:
Windows Mail will not open unless I turn my pc off then on again. Then it's fine for a while.
Any suggestions?
Windows Mail will not open unless I turn my pc off then on again. Then it's fine for a while.
Any suggestions?
If you open Task Manager does it appear in the process list? It could
be that it crashed during loading. Outlook did this to me a few years
ago and it turned out to be my Kaspersky AV plugin causing a problem.
If I ended the process in Task Manager after the 1st load, it would
then work (until I diagnosed further).
Windows 7 Forums - http://www.w7forums.com
On 30 Jan, 16:56, jublee <gu...@xxxxxx-email.com> wrote:
> Windows Mail will not open unless I turn my pc off then on again. Then
> it's fine for a while.
> Any suggestions?
> --
> jublee
You should find a better antivirus program than Norton. It causes many
problems. See point 3 here: www.oehelp.com/OETips.aspx#3
"jublee" <firstname.lastname@example.com> wrote in message
> Brink;954388 Wrote:>>>
>> > jublee;954381 Wrote:
>> > > > Brink;954368 Wrote:
>> > >
>> > >
>> > > Hello Jublee,
>> > >
>> > > Under the Processes tab, it will be listed as "winmail.exe" for
>> > > Windows
>> > > Mail if running.
>> > >
>> > > Hope this helps,
>> > > Shawn> > > >
>> > Yes I have winmail.exe in Task Manager when it's running.
>> > I did not realise Windows Mail had to be running in order to see it
>> > in Task Manager. Thank you.> >
>> Jublee,
>> You might also check to see if your antivirus program has any email
>> scanning features turned on. If it does, then you should disable or
>> turn that feature off to prevent it from interfering with Windows
>> Mail.
> Silly question No.2 Will having the "Log on using Secure
> Password Authentication" box ticked have any bearings on the situation?
> I am currently running Norton Anti Virus and will try to disable
> the email scanning feature.
> Thank you.
> --
> jublee
I do not think so since you had received your email with it set that way before. This is for just logging into your email provider to retrieve your email, but you should check with you email provider instructions on setting up your email account to see if that is required to be checked for them though.
Since you are using Norton, check the first part of PROBLEM ONE below to see if this may be a issue for you.
Windows Mail problems


text:
Brush Fire in Makakilo NOT Contained
A large brush fire continues to burn in Upper Makakilo. Ten fire companies and tankers are protecting 20 homes on Palehua Road and three on Umena Street. The occupants were evacuated Friday. The winds were expected to increase Saturday and Fire Captain David Jenkins says many areas are inaccessible and the fire is moving in multiple directions. The fire helicopter is making water drops and the police helicopter is expected to join the effort.


text:
I was swindled last week.
I poured my heart out about a post (this is the "copy") I found at creativebits.org being one of the best I'd seen in 2007. And today, I realize it was a knock-off. Others tried to express their concerns, as well, in the contents area of the post, but it appears they were ignored.
The original post, 10 Absolute "Nos!" for Freelancers, written about 60 days ago by Samuel over at the "Sleeping Late: Freelancing, Online Income, and Sleeping Late" blog, is A BRILLIANT list of guidelines that would serve any consultant well. Print and memorize it if you're in web development (or related ventures) and you will find more success with less heartache. Nice work and Great Blog. 2800 Diggs and counting and it deserves the attention.
Fooled …I shake my head, but earlier I even went over and gave the copy a vote at Mixx.com. I wonder if CameronLow or the other 56+ voters knew it was a copy? I'm betting that Joshua, James, and Thomas didn't know. The tiny little attribution links or mentions at the bottom doesn't cut it. In my mind, creativebits had
written, sorry, pasted the article on their fully-monetized blog with the intent of enhancing the blog's reputation and ringing the cash register.
(ps: It appears in several other autoblog sites and and in another, obscure blog that somehow reminds me of those pictures you see of Chinese knock offs that say "Sone Playstaten" – this one even disabled the links. Ug.)
Lastly …
I'm not used to this in the blogosphere I circulate in. A blog is mean to be authentic, transparent, and to help us learn about the very essence of the organization or person writing it. It builds trust that is returned through through comments, links, and attribution. To copy posts from those who spend the time and energy to create great stuff is to break trust, and people are getting called out about it. This stuff wouldn't be tolerated in print, so why would it be online?
It's not that they had a RSS feed, forum posts, or blog excerpts, which can be done in a respectful way that in my non-attorney opinion invokes "fair use." They copied the whole damn thing.
I've been told the readership of creativebits is a "small group" – but I ask, what is a "small group" on the public Internet, and does that matter? The post shows up in Google, in Technorati, and other search engines. So, please find a better excuse.
So, have I missed something about the blogosphere, fair use, and what has transpired? Do you agree with my point of view?
As I had review creativebits.org, I find great content, some very interesting posts, and a lot to like. But until they start giving authors their due, they'll have to do without this Kentuckian's participation and link equity.
If this is happening to you, there are some great resources on the issue you should check out. But most importantly, keep your cool and enjoy life.


text:
|2,000 sq. ft.
|Property type
|Minimum Stay
|2 nights
Elegant modern sunny home on two acres in rural residential area in the middle of the Russian River and Green Valley Wine appellation in West Sonoma County, 12 minutes from Bodega beaches, yet in a sunny inland weather area.
40' x 20' x 9' heated pool, non-chlorine (salt generator) and spa. Large views of redwood forest, meadow, mature landscaping, old Oaks, bordering 100 acre organic garden and orchard. Hiking and biking trails, minutes to the Russian River with boating and swimming. Fine dining, world class wineries, breathtaking beaches, fabulous weather.
60 minutes No. of San Francisco, within minutes of Healdsburg (25), Graton (7), Sebastopol (7), Forestville (12), Occidental (9), Bodega (5), Tomales Bay (25).
Artful, sunny, rural and relaxing.: This is a beautiful wine country setting. The house is open and sunny, with hand crafted furniture and finishings, oriental carpets, sculpture and paintings. The large heated pool and spa are inviting places to relax swim and sun (non-chlorine, salt generated pool).
You may canoe on the Russian River, go deep sea fishing at Bodega Bay, surfing at Salmon Creek beach, beach combing at the numerous beaches, antiquing in and around Sebastopol, go golfing at Bodega, Guernville, or Santa Rosa, try out a variety of wines at the scores of wineries in the area, eat fresh seafood, try out the various restaurants which feature the abundance of organic produce, meats and wines from Sonoma County.
Sonoma County, exciting wines, gorgeous beaches: Sonoma County has rolling hills, sweeping vineyards, world class wineries, exciting beaches and cliffs with surfing, fishing, and whale watching.
It is a gormandise paradise, with fine dining spots located in the little villages in the surrounding area for example: Healdsburg, Occidental, Freestone,Graton, Forestville, Sebastopol. You will find artist's studios, jazz and other music festivals and venues. You may go to Tomales or Marshall and pick the oysters out of the sea, or buy fresh fish from the docks at Bodega Bay and bring it all home to grill by the pool or on the deck.
San Francisco is an easy day trip away where you may cross over the Golden Gate Bridge, visit the museums such as the SF Museum of Modern Art, the Asian Art Museum, the Palace of the Legion of Honor and......many more. Visit the world famous Aquarium, the Exploratoriun, China Town, North Beach, Castro and Noe Valley all invite you to visit. The Napa Valley is just over the hills.
Plenty to do...or nothing: Within a 30 minute radius there are numerous activities. There is a large concert venue, Wells Fargo Center with classical and pop concerts year round. There are several repertory theaters, small venues for classical concerts as well as night club performances. Live Jazz is available in several places, including numerous winery concerts. We even have casinos north of Santa Rosa and in Rohnert Park. Visit one of our small local night spots for live music and dancing. We are a legal permitted Vacation Rental: Sonoma County Permit No. ZPE12-0070
I am an artist and a retired San Francisco high school teacher. Much of the furniture and cabinetry in the house was hand crafted by my husband and me. His furniture is shown in galleries in Northern California. I am a sculptor and web designer and live and work nearby. The house was designed and lovingly built to house our family, now gone to their own lives. It is sunny and private with lots of oak trees and a meadow. If you moved to Sonoma County, this is exactly where you would want to live...beautiful, quiet, private and inviting. We eat organic fruits and vegetables all year long, not to mention quaff the wine.
Sara Schomp purchased this house in 1991
As a child I came from Denver to visit my aunties here in Sebastopol in the 1940's-60's. While living in San Francisco during the 70-90's we set up our furniture and wood working shop here when it became too costly to work in SF, eventually moving the family here to live in the country. While living in SF we came up here for the Apple Festival, concerts and dances and enjoyed visiting the beach and all the little villages.
It is so quiet here I could not move back to the city. Everywhere one looks one sees beauty and that's important to me. It's exciting to have so many artists and vineyards surrounding us, and being near the ocean and seeing the green and hilly landscape, studded with oaks and redwoods just tops it all off.
Our stay at Sara's Oasis was a great value! We felt very welcome and would recommend it 100% . We spent one entire day of our 3 day vacation lounging at Sara's beautiful pool, spa and garden. We enjoyed Sonoma County wine tasting, and took some walks.
Particularly delightful was our lunch at Lynmar winery and our morning trips to nearby Wild Flour bakery for breakfast breads and coffee.
Just to be unbiased, there were a lot of leaves in the grill on the back deck which we quickly brushed aside.
My husband and I and our good friends just returned from a wonderful week at Sara's Oasis. In reading the reviews and looking at the pictures before we left we had high expectations. Upon first arrival and our look around the house and the grounds I told Sara that this house is actually more beautiful than the pictures! The grounds around the pool and the gardens are indescribably lovely. The beds are very comfortable and the gourmet kitchen fully stocked. We shopped for seafood at Bodega Bay and cooked some wonderful seafood at the house. We love to go to wineries and spent several days at the many local wineries within driving distance. The highlight of the trip however was canoeing down the Russian River which is only about a 20 minute drive. The house is centrally located in the county which makes it easy to get to many communities in the area for restaurants and sight seeing. Thanks Sara for the wonderful week and we plan to return soon!
We recently spent 4 nights with 2 other couples at Sara's Oasis and had a wonderful time. The house was great for relaxing and cooking and location was perfect for visiting wineries, redwoods, and coast. Sara was very responsive and easy to work with. Definitely hope to return one day!
This property is wonderful, and exceeded our expectations. The house is beautiful, and was very comfortable for our group of 5. We cooked and barbecued, and had everything we required. The highlight was the pool/hot tub area. It is very private, and planted beautifully. The pool house had everything we needed, and meant we didn't have to run back to the main house. My only regret is we couldn't stay longer. One caution: the contract specifies that it is a quiet neighborhood and that no noise is permitted outside after 10 pm. We were just sitting by the pool, looking at stars and talking in normal voices, and triggered a complaint from the neighbors. As long as you are not wanting to utilize the outside after 10:00 pm, this is a perfect vacation spot.
Our March stay was delightful. Depending on which of us you asked, the favorite elements were: The art in the house, the pool, the quiet of the whole area, the many charming areas where the 5 of us could spread out for conversation or quiet reading. Kitchen was very well provisioned with pans, utensils, etc. Sara was very willing to help.
I came to Sara's Oasis to get away for a relaxing weekend. I was not disappointed. To start with the house itself is lovely…homey, beautifully decorated with handcrafted furniture, interesting artwork, handmade furniture and cabinetry and antique rugs.
Though early in the season here the weather was warm and we spent a number of hours just hanging out in the outdoor hot tub with quick trips to splash in the beautiful pool surrounded with gorgeous landscaping.
There were two or three great restaurants we went to, but the Oasis had a beautiful kitchen making eating in easy as well.
I spent a wonderful morning exploring the many antique shops and little food markets.
The town is quaint and I loved seeing the apple blossoms and vineyards as we drove to and from the Oasis.
My only complaint is that I didn't have more time to spend. The weekend was over way too quickly.
Sara's home is beautiful, spacious, clean, quiet, private, well furnished, well appointed and full of works of art, amenities and modern conveniences. The photos shown in Sara's listing depict the home accurately. The pool and spa are both large and really made my stay enjoyable. The environs of the house certainly made me feel relaxed and gave me the feeling of being "away from it all". There are even deer and turkeys that roam the land surrounding the house.
The house is also in a very good location as Healdsburg, Dry Creek Valley, Guernsville, Kenwood, and Santa Rosa are all within a 20-30 minute drive. I would suggest visiting Kenwood as it's a wonderful town with fantastic wineries, but rarely mentioned in guidebooks.
Unfortunately, I didn't meet Sara, but she was certainly available to help/answer questions via text/email. Her wonderful daughter gave a good tour of the house. Sara also has guidebook for the house itself and the places to go and things to do in the area. Sara also mailed my security check back to me on the day that I checked out.
I highly recommend Sara's home and I would certainly seriously consider staying there again on future trips to Sonoma County.
We are located in the middle of the Russian River appellation. Several vineyards are within minutes- wine tasting, fine dining easily accessible. 12 minutes to Bodega Bay, River and ocean sports are nearby (surfing, deep sea fishing, canoeing), hiking swimming, sunning, biking and relaxing are all encouraged. There is even a zip-line through the redwood forest!
The villages of Occidental, Graton, Forestville, Sebastopol, Freestone, Valley Ford are within 10 minutes, and Healdsburg, Santa Rosa and Tomales are within 1/2 hour, so shopping, dining and visiting artist's studios and galleries, antique collecting is easy.
Other Activities: Wine tasting Russian River and Green Valley appellations, Hot Air Ballooning, Zip-line through the redwoods, Safari West Wild Animal park
Golf: Several challenging and beautiful golf links in this area, including one along the Pacific coastline and an inland local link.
|Rate Period
|Weekend Night
|Monthly *
My Standard Rate
2 night minimum stay
|Refundable damage deposit
|Cleaning fee
|$145 + Tax
|Tax Rate
Rates are subject to change until reservation is confirmed.
Days added on to weekend stay are discounted ($340 standard and $270 mid-Oct - April ).
Rate is for up to 6 people with additional $40 per night per person with a maximum of 8 people.
Holidays, 3 night minimum, charged at Standard Rate
* Approximate monthly rate. Actual rate will depend on the days of the month you stay.


text:
Socially Responsible Investments: How Do They Stack Up?
Motley Fool
Sep 17, 2012
The idea motivating the dramatic growth of socially responsible investing, or SRI, is that businesses that benefit society in addition to building wealth for shareholders will outperform businesses that do not improve society in the long run. Research by Mark Cohen, professor of management, is mentioned.


text:
Home > National News > Article
Seven-year-old Jack McQueen did not muck around when he heard the cries for help of another boy being swept away on an out-of-control surf ski.
Jack had just been swimming with two friends and their father while on a camping trip at Patonga Creek on the Central Coast in January.
Instead of running to get help, the Terrigal Nippers-trained boy from Wamberal got back in the water and pulled the boy to safety.
Not that you would know it from the reaction of the 11-year-old he had just saved. "He just ran away," Jack said. "He didn't even say thanks."
Yesterday the NSW branch of the Royal Life Saving Society said thanks to Jack, now 8, and 50 other recipients of commendation awards, 25 of whom were members of the NSW Police, at a ceremony at Government House.
Unlike the boy Jack helped, the man Ricky Barnett and Lee Edwards saved stuck around to say thanks. The men from Mullumbimby were surfing with their friend, Stuart Pontin, at Brunswick Heads in northern NSW last year when Mr Barnett and Mr Edwards noticed their friend's board was sticking up out of the water.
Mr Pontin had suffered an epileptic seizure and was head-down sinking towards the seabed. By the time they pulled him to the surface, he had stopped breathing. He was resuscitated by a rescue boat crew, also awarded, but the drama has not slowed him down. As a drummer, he now plays in a band named Stuey Died.
The awards do not recognise bravery, although many recipients demonstrated just that, rather they simply honour the real-life use of life-saving techniques. The chief executive of the NSW branch of the Royal Life Saving Society, David Macallister, said the organisation "supports any person who attempts to save a life, regardless of the outcome".
Yesterday's 51 commendations are the most conferred in the awards' decade-long existence, an increase Mr Macallister thinks is due to a wider knowledge of the awards rather than an increase in life-saving deeds.
However, the efforts of at least 30 recipients were in vain.
Ralph Seccombe was part of a Lake Macquarie volunteer coastal patrol that helped a sandbank-bound houseboat last year. One of his crew was found floating face down after the houseboat was saved and, despite a long period of attempted resuscitation, he died. He had suffered a heart attack. Mr Seccombe is sad his efforts were unsuccessful, but said:"I'm glad I was there and I'm glad I tried."
|Print this article Email to a friend
|text | handheld (how to)
membership |
conditions |
Copyright © 2003. The Sydney Morning Herald.
|advertise | contact us


text:
The 20th Manga Koshien, National High School Manga Championship of Japan, started today, August 6 at Cul-Port in Kochi-city, Kochi. The two day event is an annual nationwide high school manga tournament. Any manga, comic, and anime club in Japanese high school can participate in the tournament.
The 35 clubs (3-5 members each) from all over Japan fought the qualifying on the first day. Only 20 clubs are able to fight at the final on Sunday. The teams have to draw an original manga with a given-theme in a limited time each day. The first day's theme was "The strongest power generator" and the given time was five hour and a half. Power saving is the most important issue in Japanese
daily life after Fukushima I nuclear accidents on March 11. They had to create the strongest power
generator with a manga-way.
Cul-Port, the multipurpose hall where Manga Koshien is held
Opening ceremony
The three most popular manga artists in the judges. From the left:
Kazuhiko Shimamoto (Hono no Tenkousei, Moeyo Pen, Chokyu! Mobile Fighter G Gundam)
Mitsuru Adachi (Touch, Rough, H2, Cross Game)
Tetsuya Chiba (Ashita no Joe)
A video message from voice actor Daisuke Ono (Itsuki Koizumi in the Haruhi Suzumiya series).
He was born in Kochi in 1978.
The manga battle begins!
Digital manga tools are also permitted.
Some of the finalists' works
Some graffiti on the walls


text:
Τιμή για κάθε δρομολόγιο. Συμπεριλαμβάνονται οι φόροι.Αναζήτηση πτήσεων
Upbeat Bari might be Italy's second-most important southern city, but –despite a warren of alleys ideal for escaping the midday sun, all night summer nightlife, superb alfresco dining and laidback beaches– this lively resort is also one of the country's least-appreciated conurbations. So why not leave Rome and Rimini to the tourists, and follow our guide to the top spots to sip, sup, see or soak up the sun far from the madding crowds in this charming, but little-known, capital of Italy's food-loving Apulia region?


text:
A new £1million wing at a primary school has been officially opened.
The Warner Wing, named after Raymond Warner, the chairman of governors for almost 20 years, was opened at Hereward Primary School in Loughton yesterday.
Epping Forest MP Eleanor Laing unveiled a plaque at the site.
The building provides two additional classrooms, three small group rooms, a library and a hall at the school, which was rated outstanding by Ofsted.
Mrs Laing said: "I am delighted to celebrate the opening this important new part of Hereward School.
"I have watched the school go from strength to strength over the years and its increasing popularity has made the extension of the buildings all the more important.
"Raymond Warner has been a dedicated and very hard-working Chairman of Governors. He deserves every credit for all that he and his team have achieved for the school."


text:
Don't put your handbag on an unsanitary restaurant floor, or on the back of your chair when dining out—Pavina Hangbag Holders are the most stylish and elegant way to protect and display your purse!
Made of premium quality materials, Pavina's classic jeweled designs are hand set with the highest quality, genuine Swarovski crystals and stones. All designs are stress tested to hold 25 lbs. Each comes with a pouch, gift box, and instructions for use.
Click here to start shopping!


text:
Education / Community Engagement
The Virginia Symphony Orchestra's Education and Community Engagement Department touches the lives of over 56,000 people per season through concerts, lectures and presentations, in-school-residences, master classes, open rehearsals, student performances, collaborations with other organizations and an array of community engagement programs. We believe that the impact of these programs will build future audiences and musically enrich the lives of the very young and young at heart. The sound of the Virginia Symphony Orchestra, through its education and community engagement programs, is heard throughout the Hampton Roads community as well as various venues within the Commonwealth of Virginia. The sound, indeed, IS all around you. Come, see where music takes you!