Stuxnet, of hoe de cyberoorlog tot in perfectie is uitgevoerd...

quote:

Stuxnet heeft drie speficieke payloads, zeg maar 'kernkoppen'. Uit onderzoek van Symantec blijkt dat twee van de drie aanvalsmodules alleen in werking treden als zij industriële frequentieregelaars tegenkomen die electromotoren aansturen die met extreme snelheden draaien. Boven de 800 Hz, dat is 48420 toeren per minuut (rpm). [...]

Er zijn bovendien maar heel weinig industriële processen waarbij dergelijke omwentelingssnelheid noodzakelijk zijn. De belangrijkste is uraniumverrijking. Maar zijn er geen andere industriële toepassingen met dergelijke toerentallen? Pompen, turbines? We vroegen het aan Adrie Huesman, universitair docent TU Delft van het Delft Center for Systems and Control.

"50.000 rpm is wel extreem hoog. Compressoren komen hier nog het dichtste bij, maar die komen meestal niet uit boven de 10.000 rpm. Met dat toerental kun je een druk opbouwen van 200 bar, dat is ongeveer de maximum gangbare druk in bijvoorbeeld de chemische industrie. Hogere snelheden zijn niet nodig en dus de investering niet waard, omdat het veel duurder wordt. Vanwege de extreme centrifugale krachten zijn dan speciale materialen nodig", legt Huesman uit.

"De Chinezen werken momenteel aan geavanceerde separatoren, maar die halen ook niet meer dan 10.000 rpm. Ik ken geen industriële applicaties die hogere toeren hebben dan dat."
bron

quote:

“The STL code [in Stuxnet] was sending down things like ‘word 47F and 1′,” Chien recalls. “And you look at the frequency converter [manual], and it says, ‘To start the frequency converter, send down the word 47F and set this value to 1. We were speechless.”

Based on information in the code, Stuxnet was targeting a facility that had 33 or more of the frequency converter drives installed, all operating at between 807Hz and 1,210Hz.

Stuxnet searches for a facility that has a minimum of 33 frequency converters installed.
The malware would sit quietly on the system doing reconnaissance for about two weeks, then launch its attack swiftly and quietly, increasing the frequency of the converters to 1,410Hz for 15 minutes, before restoring them to a normal frequency of 1,064Hz. The frequency would remain at this level for 27 days, before Stuxnet would kick in again and drop the frequency down to 2Hz for 50 minutes.

The drives would remain untouched for another 27 days, before Stuxnet would attack again with the same sequence. The extreme range of frequencies suggested Stuxnet was trying to destroy whatever was on the other end of the converters.

quote:

Op woensdag 15 februari 2012 20:59 schreef YuckFou het volgende:
Aangezien Resonancer een eigen topic aan heeft gemaakt kan ik deze wel even kapen
Ik zit te dubben of ik een [BNW] topic aan Stuxnet moet wijden, de code is inmiddels in ieder gevaal deels op t net gekomen en dus in handen van virusschrijvers en andere nerds, ik hoef denk ik niet te vertellen wat dit voor impact kan hebben als Anonymous in plaats van een ddos attack een derivaat van Stuxnet inzet om een bedrijf klem te zetten, dat kan heel verre gevolgen hebben....

quote:

Op woensdag 15 februari 2012 22:57 schreef Bankfurt het volgende:
"Volgens vooraanstaand computerbeveiliger Symantec zijn sinds juli van dit jaar 63 pc's in Japan besmet geraakt met Stuxnet. Een computervirus dat is gekweekt om servers aan te vallen die geïsoleerd zijn van het internet".

quote:

Within a week of establishing the sinkhole, about 38,000 infected machines were reporting in from dozens of countries. Before long, the number would surpass 100,000. Stuxnet was spreading rapidly, despite signatures distributed by antivirus firms to stop it.

As Chien and O Murchu mapped the geographical location of the infections, a strange pattern emerged. Out of the initial 38,000 infections, about 22,000 were in Iran. Indonesia was a distant second, with about 6,700 infections, followed by India with about 3,700 infections. The United States had fewer than 400. Only a small number of machines had Siemens Step 7 software installed – just 217 machines reporting in from Iran and 16 in the United States.

The infection numbers were way out of sync with previous patterns of worldwide infections — such as what occurred with the prolific Conficker worm — in which Iran never placed high, if at all, in infection stats. South Korea and the United States were always at the top of charts in massive outbreaks, which wasn’t a surprise since they had the highest numbers of internet users. But even in outbreaks centered in the Middle East or Central Asia, Iran never figured high in the numbers. It was clear the Islamic Republic was at the center of the Stuxnet infection.

quote:

"Investigators analyzed log files and connections to foreign Internet protocol addresses within the utility’s computer system, said the source, who was not authorized to speak for attribution. “No indictors of malicious activity were found” in the computer system of the Curran-Gardner Townships Public Water District in Springfield, the source said."

quote:

Stuxnet/Duqu: The Evolution of Drivers
We have been studying the Duqu Trojan for two months now, exploring how it emerged, where it was distributed and how it operates. Despite the large volume of data obtained (most of which has yet to be published), we still lack the answer to the fundamental question - who is behind Duqu?

In addition, there are other issues, mostly to do with the creation of the Trojan, or rather the platform used to implement Duqu as well as Stuxnet.

In terms of architecture, the platform used to create Duqu and Stuxnet is the same. This is a driver file which loads a main module designed as an encrypted library. At the same time, there is a separate configuration file for the whole malicious complex and an encrypted block in the system registry that defines the location of the module being loaded and name of the process for injection.


We believe Duqu and Stuxnet were simultaneous projects supported by the same team of developers.

Several other details have been uncovered which suggest there was possibly at least one further spyware module based on the same platform in 2007-2008, and several other programs whose functionality was unclear between 2008 and 2010.

These facts significantly challenge the existing "official" history of Stuxnet. We will try to cover them in this publication, but let us first recap the story so far.

The ‘official’ Stuxnet story
Let me start with a question: how many Stuxnet driver files are known? As of today, the correct answer would be four. See below for more information about them.

File name Size (bytes) Compilation date Where and when it was used Digital signature/signing date
Mrxcls.sys 19840 01.01.2009 Stuxnet (22.06.2009) No
Mrxcls.sys 26616 01.01.2009 Stuxnet (01.03.2010/14.04.2010) Realtek, 25.01.2010
Mrxnet.sys 17400 25.01.2010 Stuxnet (01.03.2010/14.04.2010) Realtek, 25.01.2010
Jmidebs.sys 25552 14.07.2010 Presumably, Stuxnet Jmicron, unknown

The first modification of the Stuxnet worm, created in 2009, used only one driver file – mrxcls.sys without a digital signature.

In 2010, the authors created the second driver mrxnet.sys (to hide the worm’s component files on USB drives) and equipped mrxnet.sys and mrxcls.sys drivers with digital certificates from Realtek. The mrxnet.sys driver is of no great significance to our story, as it is a separate module not included into the general architecture of the platform.

On 17 July 2010, ESET detected another driver “in the wild" - jmidebs.sys - which was very similar to the already known mrxcls.sys, but had been created just three days before it was discovered. This driver was backed with a new certificate - this time from Jmicron.

Until recently it was unclear what the purpose of this file was, but popular opinion held that it was related to Stuxnet. One theory is that the Stuxnet C&C was trying to replace the old version with the Realtek certificate with a new one. In doing so, the authors of the worm were either hoping to prevent it being picked up by antivirus programs, or were replacing a certificate which had been blocked.

Unfortunately, this theory has not been confirmed - Jmidebs.sys has never been detected anywhere. A new version of Stuxnet capable of installing the file has also not been found.

This is the official history of Stuxnet. However, as I mentioned above, in the course of our research we have discovered new evidence which will be discussed below.

Previously unknown drivers
rtniczw.sys
While analyzing a user incident involving Duqu, we discovered something new – something that could, potentially, affect the whole Stuxnet story as we know it.

A strange file was discovered on the victim’s computer, which was detected by our antivirus engine as Rootkit.Win32.Stuxnet.a. This verdict was supposed to correspond to the known file mrxcls.sys described above, but the detected file’s name and checksum were different!

The file was rtniczw.sys, 26,872 bytes in size, MD5 546C4BBEBF02A1604EB2CAAAD4974DE0.

The file was a little larger than mrxcls.sys, which had a Realtek digital signature. This implied that rtniczw.sys also had a digital signature. We managed to get a copy of the file, and we were amazed to find that it used the same Realtek certificate, but with a different file signing date from mrxcls.sys: rtniczw.sys was signed on 18 March 2010, while the mrxcls driver had been signed on 25 January of the same year.

In addition, rtniczw.sys used a registry key and configuration data block that was not used in Stuxnet. Stuxnet used the key “MRxCls” and the value “Data”, while in the case of rtniczw.sys, the key was “rtniczw” and the value was “Config”.

Detailed analysis of the code found in rtniczw.sys identified no other differences from the ‘reference’ driver: this was the same mrxcls.sys file, created in the same year, on the same day and hour – on 1 January 2009.

We searched for additional information about other users who had the same file, but were unable to find anything! Moreover, we could find no information at all about the file’s name (rtniczw.sys) or its MD5 in any search engine. The file had been identified only once: it had been sent for scanning to VirusTotal from China in May 2011.

Apparently, the system that we were studying had been infected in late August 2011. It should be noted that we did not find a Stuxnet infection on the system: no additional files from the Stuxnet kit had been found. However, we did find Duqu files.

We came to the conclusion that there could be other driver files similar to the “reference” file mrxcls.sys, which are not among known variants of Stuxnet.

rndismpc.sys
A check in our malware collection helped identify another interesting file that was included in the collection over a year ago. The file is named rndismpc.sys, it is 19,968 bytes in size, MD5 9AEC6E10C5EE9C05BED93221544C783E.



This turned out to be another driver, with functionality very nearly identical to that of mrxcls.sys apart from the following exceptions:

rndismpc.sys uses a registry key that is different from the keys used by both mrxcls and rtniczw – it is the key “rndismpc” with the value “Action”;
it uses an encryption key that is different from that used by mrxcls/rtniczw – 0x89CF98B1;
the file’s compilation date is 20 January 2008, i.e. a year before mrxcls/rtniczw were created.
Like rtniczw.sys, the file rndismpc.sys had never been encountered on our users’ machines. We do not know which malicious program installed it or which main module it was supposed to work with.

The connecting link: mrxcls.sys —> jmidebs.sys —>Duqu drivers
The data obtained and the available information about the drivers used in Duqu (see The Mystery of Duqu, Part One and Part Two) can be summed up in the table below:

Name Size Compi-
lation date Main module Encryption key Registry key Value Device
name
rndismpc.sys 19968 20.01.
2008 Unknown 0x89CF98B1 rndismpc “Action” “rndismpc”
mrxcls.sys 19840 01.01.
2009 Stuxnet.a 0xAE240682 MRxCls “Data” “MRxClsDvX”
mrxcls.sys (signed) 26616 01.01.
2009 Stuxnet.b/.c 0xAE240682 MRxCls “Data” “MRxClsDvX”
rtniczw.sys (signed) 26872 01.01.
2009 Unknown 0xAE240682 rtniczw “Config” “RealTekDev291”
jmidebs.sys (signed) 25502 14.07.
2010 Unknown 0xAE240682 jmidebs “IDE” {3093983-109232-29291}
<name>.sys* Different 03.11.
2010 Duqu 0xAE240682 <name> “FILTER” {3093AAZ3-1092-2929-9391}
<name>.sys* Different 17.10.
2011 Duqu 0x20F546D3 <name> “FILTER” {624409B3-4CEF-41c0-8B81-7634279A41E5}

*Known Duqu drivers have unique file names for each of the variants. Their functionality, however, is absolutely identical.

According to our analysis, jmidebs.sys is the connecting link between mrxcls.sys and the drivers later used in Duqu.

The code of mrxcls and jmidebs drivers is largely similar. Some small differences may be due to different settings and minimal changes in the source code, while the point of the code remains the same.

However, more significant changes can be found in several functions:

The service function which obtains addresses of API functions: The version in mrxcls uses the function MmGetSystemRoutineAddress for this purpose and the respective text names of the addresses of incoming API functions. The version in jmidebs calls its own functions to obtain API addresses using hash-sums of their names. The same functions are used in Duqu drivers, while the list of functions’ hashes is twice as long.
The function which creates stubs to inject PNF DLL into processes: The mrxcls version uses a stub with a total size of 6332 bytes. The jmidebs and Duqu drivers use stubs with a total size of 7061 bytes. The code used in the stub modules for these drivers is identical, but has different compilation dates.
Mrxcls (Stuxnet) jmidebs Duqu
API RtlGetVersion, KeAreAllApcsDisabled, obtained by calling MmGetSystemRoutineAddress RtlGetVersion, KeAreAllApcsDisabled, PsGetProcessSessionId, PsGetProcessPeb obtained with their own functions Similar to jmidebs, 4 more functions added
Injected EXE 6332 Jan 01 22:53:23 2009 7061 Jul 14 13:05:31 2010 7061 Different compilation dates

Driver evolution
We have mapped out the links between known drivers whose evolution and key stages of development are easy to track.

Driver evolution from 2008 to 2011

rndismpc.sys, rtniczw.sys and jmidebs.sys
As you can see from the diagram, it is not known which malicious program interacted with the following three drivers: rndismpc.sys, rtniczw.sys and jmidebs.sys. The obvious question would be: were they used in Stuxnet? In our opinion, the answer would have to be ‘no’.

First of all, if they had been used in Stuxnet, they would have left a far bigger footprint than the individual cases we have detected. Secondly, there hasn’t been a single variant of Stuxnet that is capable of interacting with these drivers.

The file rtniczw.sys was signed on 18 March 2010, but on 14 April 2010 the Stuxnet authors created a new variant of the worm that made use of the “reference” mrxcls.sys. It is obvious that rtniczw.sys was intended for some other use. The same can be said of jmidebs.sys. We believe that the three drivers are only indirectly related to Stuxnet and can safely be erased from Stuxnet history.

Then there is another question: could these drivers have been used with Duqu?

There is no clear-cut answer here. Although all known variations of Duqu are from the period November 2010-October 2011, we believe there were earlier versions of the Trojan spy created to steal information. The three drivers in question could easily have been used in early versions of Duqu or with other Trojans based on the Stuxnet/Duqu platform. Like Duqu, those Trojans were most probably used in targeted attacks before the appearance of Stuxnet (dating back to at least 2008), both while it was active and after its C&C was shut down. They were likely to have been parallel projects, and Stuxnet was subsequently based on that accumulated experience and the code that had already been written. It seems highly unlikely that this was the only project that its authors were involved in.

The driver creation process
Let’s try to imagine what the driver creation process looks like. A few times a year the authors compile a new version of a driver file, creating a reference file. The primary purpose of this file is to load and execute a main module, which is created separately. It could be Stuxnet, or Duqu or something else.

When it is necessary to use a driver for a new module, the authors use a dedicated program to modify information in the driver’s “reference” file, i.e. its name and service information as well as the registry key and its value.

It’s important to note that they tweak ready-made files and don’t create a new one from scratch. This means they can make as many different driver files as they like, each having exactly the same functionality and creation date.

Depending on the aim of the attack and the Trojan’s victim, several driver files can then be signed with legitimate digital certificates whose origins remain unknown.

Conclusion
From the data we have at our disposal, we can say with a fair degree of certainty that the “Tilded” platform was created around the end of 2007 or early 2008 before undergoing its most significant changes in summer/autumn 2010. Those changes were sparked by advances in code and the need to avoid detection by antivirus solutions. There were a number of projects involving programs based on the “Tilded” platform throughout the period 2007-2011. Stuxnet and Duqu are two of them – there could have been others, which for now remain unknown. The platform continues to develop, which can only mean one thing – we’re likely to see more modifications in the future.
bron

quote:

Researchers Release Exploits for Critical Infrastructure Software

MIAMI, Florida — A group of researchers has discovered serious security holes in six top industrial control systems used in critical infrastructure and manufacturing facilities and, thanks to exploit modules they released on Thursday, have also made it easy for hackers to attack the systems before they’re patched or taken offline.

The vulnerabilities were found in widely used programmable logic controllers (PLCs) made by General Electric, Rockwell Automation, Schneider Modicon, Koyo Electronics and Schweitzer Engineering Laboratories.

PLCs are used in industrial control systems to control functions in critical infrastructure such as water, power and chemical plants; gas pipelines and nuclear facilities; as well as in manufacturing facilities such as food processing plants and automobile and aircraft assembly lines.

The vulnerabilities, which vary among the products examined, include backdoors, lack of authentication and encryption, and weak password storage that would allow attackers to gain access to the systems. The security weaknesses also make it possible to send malicious commands to the devices in order to crash or halt them, and to interfere with specific critical processes controlled by them, such as the opening and closing of valves.

As part of the project, the researchers worked with Rapid7 to release Metasploit exploit modules to attack some of the vulnerabilities. Metasploit is a tool used by computer security professionals to test if their networks contain specific vulnerabilities. But hackers also use the same exploit tool to find and gain access to vulnerable systems.

“We felt it was important to provide tools that showed critical infrastructure owners how easy it is for an attacker to take control of their system with potentially catastrophic results,” said Dale Peterson, founder of DigitalBond, the SCADA security company that led the research.

quote:

The vulnerabilities were discovered by a team of six researchers as part of DigitalBond’s Project Basecamp. The researchers included Reid Wightman, who works for DigitalBond, and five independent researchers who volunteered their time to examine the systems — Dillon Beresford, Jacob Kitchel, Ruben Santamarta and two unidentified researchers whose companies didn’t want them publicly associated with the work.

The vulnerable products include:

General Electric D20ME
Koyo/Direct LOGIC H4-ES
Rockwell Automation/Allen-Bradley ControlLogix
Rockwell Automation/Allen-Bradley MicroLogix
Schneider Electric Modicon Quantum
Schweitzer SEL-2032 (a communication module for relays)

The researchers were asked to focus on several attack categories, based on vulnerabilities previously discovered in other PLCs — such as ones Beresford found last year in popular PLCs made by Siemens.

Those included a hardcoded password, a backdoor inadvertently left in the system by company engineers and lack of strong authentication gateways that would prevent a non-legitimate user from sending malicious commands to the Siemens PLC.

It was a PLC made by Siemens that was targeted by the Stuxnet worm, a sophisticated piece of malware discovered last year that was designed to sabotage Iran’s uranium enrichment program. During a talk at S4 on Wednesday, industrial control system security expert Ralph Langner — one of the leading experts on Stuxnet — described how a read/write capability the Siemens programmers put in their system was leveraged by the attackers to capture legitimate data on the Siemens system in order to play it back to operator monitors so that administrators at the targeted plant would see only legitimate data on their screens and think the plant was functioning normally while it was being sabotaged.

Of the systems discussed on Thursday, the General Electric D20ME was the most expensive PLC the researchers examined — costing about $15,000 — and had the most vulnerabilities. Wightman referred to his findings on the system as a “bloodbath” and said it took him just 16 hours to uncover the most glaring vulnerabilities.

He found that the system used no authentication to control the uploading of “ladder logic” to program the PLC. Backdoors in the system also allowed him to list processes, see where in memory they lived and to read and write to memory. He also had access to the configuration file, which listed, among other things, usernames and passwords that would allow an attacker to gain access to the system using legitimate credentials. Basic buffer overflow flaws in the system could also be used to crash it.

While a number of the systems the group tested used vulnerable web servers, the GE system did not have one at all. “Thank goodness, because if there was [one] I’m sure it would be done poorly, given everything else,” Wightman said.

The GE PLC is nearly two decades old but is still used in electric substations for power generation and in other key critical infrastructure systems. GE has said that it plans to release a new, more secure, version of the product this year, but it’s unclear whether that version fixes any of the vulnerabilities uncovered by the researchers. The company has said in a product bulletin published in 2010 that it has “no plans to develop additional cyber security features in previous generation D20 products due to limitations in the hardware and software platforms,” which leaves current customers using those systems potentially open to attack.

A GE spokesman said he couldn’t comment on the specific vulnerabilities uncovered until the company had more time to examine them.

“We want to take a look at the data they have and what are exactly the claims and make sure we investigate the product,” said Greg McDonald, spokesman for GE Digital Energy Business. He said he didn’t know offhand if the new version the company is working on fixes any of the vulnerabilities disclosed by the researchers.

The researchers found that the Koyo Direct Logic system, like the GE system, does not encrypt communication or require digitally signed messages, allowing an attacker to intercept commands and replay them to the PLC to take control of it. A web server used with the device also lacks basic authentication, allowing an attacker to reconfigure it to change basic settings such as the IP address and email alerts.

The Koyo system, however, is slightly more secure than the GE system, in that it at least requires a passcode for downloading and uploading ladder logic to the device. But Wightman said the system requires that the passcode start with the letter “A” and contain 7 digits between 0 and 9, making it easy to crack it by rapidly testing possible passwords, a method known as “bruteforcing.” Wightman said his group hopes to have a Metasploit module to bruteforce the passcode by Valentine’s Day.

“Just because I love that day and I want the vendors to love that day, too,” he said.

The Modicon Quantum system, another expensive key system for critical infrastructure that costs about $10,000, also has no authentication to prevent someone from uploading ladder logic and has about 12 backdoor accounts hard coded into it that have read/write capability. The system also has a web server password that is stored in plaintext and is retrievable via an FTP backdoor.

The Rockwell/Allen-Bradley and Schweitzer systems had similar vulnerabilities.

Wightman’s talk was not without controversy. Kevin Hemsley, a senior security analyst for the DHS’s Industrial Control System Computer Emergency Response Team and who was present at the conference, raised the issue that Wightman and his group hadn’t disclosed the vulnerabilities to the vendors in advance of his talk so that they could be prepared with patches or mitigation techniques.

Wightman and Peterson said they wanted to avoid the kind of situation that Beresford ran into last year when Siemens issued statements to customers downplaying the vulnerabilities he’d found and then swooped in at the last minute before his scheduled presentation to persuade him to cancel it until the company had more time to prepare patches.


“I didn’t want a vendor to jump out in front of the announcement with a PR campaign to convince customers that it wasn’t an issue they should be concerned with,” Wightman said.

Peterson added that “a large percentage of the vulnerabilities” the researchers found were basic vulnerabilities that were already known to the vendors, and that the vendors had simply “chosen to live with” them rather than do anything to fix them.

“Everyone knows PLC’s are vulnerable, so what are we really disclosing?” he said. “We’re just telling you how vulnerable they are.”

Marty Edwards, director of DHS’s Control Systems Security Program, wouldn’t comment on the release of the exploits and vulnerability information other than to say that the department “does not encourage the release of sensitive vulnerability information until a validated solution is available for distribution.”

“To better secure our nation’s critical infrastructure, DHS always supports the coordinated disclosure of vulnerability information—after we have provided actionable solutions and recommendations to our industry partners,” Edwards said in a statement.

Another DHS official attending the conference said that in releasing exploits before vendors and customers could mitigate them, the researchers were exposing the systems to attack by low-level hackers who are looking to cause mayhem.

“We have so many of these little scriptkiddies that are looking at these things and that are associating themselves with these anarchist groups,” said the official, who talked to Wired on condition that his name not be used since he was not authorized to speak to the press. “They want to create problems, and they’re just trying to figure out how. And that’s very concerning.”

quote:

Op vrijdag 17 februari 2012 12:28 schreef J0kkebr0k het volgende:
@YuckFou: Wist niet dat jij een vrouw bent

quote:

Op vrijdag 17 februari 2012 18:53 schreef ChungLingSoo het volgende:
Sowieso schaamteloze TVP omdat dit mijn terrein betreft.

quote:

Op vrijdag 17 februari 2012 19:25 schreef J0kkebr0k het volgende:
Wel grappig overigens.... een homo die het retedruk heeft

Geintje natuurlijk.

quote:

Op vrijdag 17 februari 2012 21:15 schreef ChungLingSoo het volgende:

[..]

Computervirussen, hun werking en verspreiding zijn dingen waar ik me o.a. in specialiseer.
daarnaast zijn vrienden van mij PLC/SCADA programmers, dus we hebben dit allemaal wel een
beetje gevolgd
Nogmaals, het was alleen een TVP, dat Israel/UA of Rusland/China hier achter zit wordt nu
wel algemeen aangenomen. Ik wil alleen even kijken welke kant de discussie op gaat

quote:

Op vrijdag 17 februari 2012 22:41 schreef dadgad het volgende:
Hey YuckFou, wat is dat?

quote:

Op vrijdag 17 februari 2012 23:30 schreef ChungLingSoo het volgende:
Ik ben hier al ZO veel langer dan jij, dus ik laat me echt niet afschrikken

quote:

Op zaterdag 18 februari 2012 02:26 schreef J0kkebr0k het volgende:
kansloze Chinees.. je weet geen kont van dit virus.... Maar je bent een virus-kenner.... Kom op... Bewijs jezelf...meestal jank je als een kleuter..... Dus ben benieuwd.

quote:

HBGary wanted to suppress Stuxnet research

HBGaryStuxnt

It is no secret that in recent days, Anonymous Operatives have released a cache of HBGary Federal internal emails to the public. Crowdleaks has discovered that within these communications, Aaron Barr received a copy of Stuxnet (a computer worm that targets the types of industrial control systems ICS that are commonly used in infrastructure supporting facilities) from McAfee on July 28, 2010.

In an effort to confirm this was in fact Stuxnet, Crowdleaks has decompiled some of the source code, which can be found here. Throughout the following emails it is revealed that HBGary Federal may have been planning to use Stuxnet for their own purposes.

SPOILER

Om spoilers te kunnen lezen moet je zijn ingelogd. Je moet je daarvoor eerst gratis Registreren. Ook kun je spoilers niet lezen als je een ban hebt.

quote:

Crowdleaks.org had a software engineer (whose name has been withheld) look at the Stuxnet binaries inside of a debugger and offer some insight on the worm. She informed us that most of the worms’ sources were using code similar to what is already publically available. She noted that the only remarkable thing about it was the 4 windows 0 days and the stolen certificates.

She says:

“A hacker did not write this, it appears to be something that would be produced by a team using a process, all of the components were created using code similar to what is already publically available. That is to say it’s ‘unremarkable’. This was created by a software development team and while the coders were professional level I am really not impressed with the end product, it looks like a picture a child painted with finger paints.”

When asked what type of organization likely wrote it, she stated:

“Probably a corporation by request of a government, it was clearly tested and put together by pro’s. It really looks like outsourced work.”

quote:

char __cdecl sub_10300();
void __stdcall DriverReinitializationRoutine(PDRIVER_OBJECT DriverObject, int a2, unsigned int a3);
NTSTATUS __stdcall DriverEntry(PDRIVER_OBJECT DriverObject, PUNICODE_STRING RegistryPath);
int __stdcall sub_1048A(int a1);
int __cdecl sub_10542();
// int __usercall sub_1056C<eax>(int a1<esi>);
// int __userpurge sub_105A0<eax>(int a1<ebx>, SIZE_T a2<edi>, int a3<esi>, const void *a4);
// int __usercall sub_105E4<eax>(LSA_UNICODE_STRING *a1<ecx>, int a2<edi>, int a3<esi>);
ULONG __thiscall sub_10638(LSA_UNICODE_STRING *this, ULONG a2, int a3);
// void __userpurge sub_1076E(int a1<ebx>, PVOID *a2);
signed int __fastcall sub_107A2(int a1, int a2);
int *__cdecl sub_107E8();
bool __stdcall sub_10886(int a1);
int __stdcall sub_108BE(const char *a1);
int __cdecl sub_1098E();
// signed int __usercall sub_109B0<eax>(int a1<edi>);
int __cdecl sub_10A3A();
// int __usercall sub_10A8A<eax>(int a1<edi>, int *a2<esi>);
// int __usercall sub_10AE2<eax>(int a1<esi>);
// int __usercall sub_10B36<eax>(int a1<esi>);
int __thiscall sub_10B68(int this);
int __stdcall sub_10BA2(int, int); // weak
signed int __cdecl sub_10BE8();
// int __userpurge sub_10BEC<eax>(int a1<ebp>, int a2, int a3);
// signed int __usercall sub_10C22<eax>(int a1<eax>);
signed int __stdcall sub_10CFE(int a1, int a2);
// void __usercall sub_10D7E(int a1<eax>);
// int __usercall sub_10DA8<eax>(int a1<ecx>, int a2<edi>, int a3<esi>);
void __stdcall sub_10DCC(int a1, HANDLE Handle, int a3);
void __stdcall NotifyRoutine(int a1, HANDLE Handle, int a3);
// int __userpurge sub_10FC4<eax>(int result<eax>, int a2);
RTL_GENERIC_TABLE *__cdecl sub_10FE6();
// PVOID __usercall sub_11028<eax>(int a1<eax>, RTL_GENERIC_TABLE *a2<edi>);
// signed int __usercall sub_11066<eax>(int a1<eax>, RTL_GENERIC_TABLE *a2<edi>);
// signed int __userpurge sub_110C0<eax>(RTL_GENERIC_TABLE *a1<eax>, int *a2);
bool __stdcall CompareRoutine(int a1, int a2, int a3);
PVOID __stdcall AllocateRoutine(int a1, SIZE_T NumberOfBytes);
void __stdcall FreeRoutine(int a1, PVOID P);
// int __usercall sub_1118A<eax>(int a1<ebx>, int a2<esi>);
// int __userpurge sub_111B4<eax>(int a1<eax>, int a2<ebx>, int a3);
// signed int __userpurge sub_11242<eax>(int a1<eax>, int a2, int a3);
// PVOID __userpurge sub_113C2<eax>(int a1<edi>, int a2, int a3);
// void __userpurge sub_1141E(int a1<eax>, int a2<ecx>, int a3<ebx>, int a4, int a5);
void __fastcall sub_114EC(int a1, int a2, int a3, int a4, int a5);
LONG_PTR __stdcall sub_11522(int a1, int a2, int a3, int a4, int a5);
PVOID __stdcall sub_11578(int a1);
PVOID __stdcall sub_11598(int a1);
// signed int __userpurge sub_115CC<eax>(const void *a1<eax>, int a2<ebx>, int a3);
signed int __thiscall sub_11718(int this, int a2, const void *a3);
__int32 __stdcall sub_1174A(int a1, int a2);
// char __usercall sub_117A8<al>(WCHAR *a1<eax>, int a2<ecx>);
// PVOID __usercall sub_1182C<eax>(ULONG a1<esi>);
// int __usercall sub_11864<eax>(HANDLE *a1<edi>);
signed int __stdcall sub_118E2(unsigned int a1, int a2);
char __fastcall sub_119AE(int a1, int a2);
// char __usercall sub_11A08<al>(int a1<edi>);
// int __userpurge sub_11A4A<eax>(int a1<eax>, int a2<ebx>, unsigned int a3);
// const char *__usercall sub_11ABC<eax>(const char *result<eax>, int a2<ecx>);
int __stdcall sub_11B04(int a1, const char *a2, unsigned int a3, int a4, int a5);
int *__cdecl sub_11C14();
int __stdcall sub_11CCC(int a1);
char __stdcall sub_11D46(int a1, unsigned int a2);
// NTSTATUS __userpurge sub_11D62<eax>(LSA_UNICODE_STRING *a1<eax>, PUNICODE_STRING ValueName, int a3);
int __stdcall sub_11DD6(int, PUNICODE_STRING ValueName, int); // idb
// int __usercall sub_11EC6<eax>(char a1<al>, int a2<ecx>, unsigned int a3<esi>);
int __stdcall sub_11F42(int, int, HANDLE Handle); // idb
// int __userpurge sub_11FC0<eax>(int a1<esi>, int a2, int a3);
int __stdcall sub_12000(HANDLE Handle, PVOID ProcessInformation); // idb
// int __userpurge sub_12094<eax>(int a1<ebx>, int a2<edi>, int a3);
// LONG_PTR __usercall sub_120CC<eax>(PVOID Object<ecx>, LONG_PTR result<eax>);
int __cdecl sub_120DE(int a1);
int __cdecl sub_1210F(int a1, unsigned int a2);
// signed int __usercall sub_1216B<eax>(int a1<eax>, unsigned int a2<ebx>);
signed int __cdecl sub_121E1(int a1, int a2, int a3);
signed int __cdecl sub_122B3(int a1, unsigned int a2);
bool __cdecl sub_122D0(int a1, unsigned int a2, int a3, int a4);
// signed int __usercall sub_12323<eax>(unsigned int a1<eax>, int a2, int a3, unsigned __int16 a4);
signed int __cdecl sub_1236B(int a1, int a2);
// NTSTATUS __stdcall ZwQuerySystemInformation(SYSTEM_INFORMATION_CLASS SystemInformationClass, PVOID SystemInformation, ULONG SystemInformationLength, PULONG ReturnLength);
// void *__cdecl memcpy(void *, const void *, size_t);
// void *__cdecl memset(void *, int, size_t);
// int _SEH_epilog(void); weak
int nullsub_1(); // weak
int nullsub_2(); // weak
int sub_124FE(); // weak
int nullsub_3(); // weak
// KIRQL __fastcall KfAcquireSpinLock(PKSPIN_LOCK SpinLock);
// KIRQL __stdcall KeGetCurrentIrql();
// void __fastcall KfReleaseSpinLock(PKSPIN_LOCK SpinLock, KIRQL NewIrql);
// NTSTATUS __stdcall ZwReadFile(HANDLE FileHandle, HANDLE Event, PIO_APC_ROUTINE ApcRoutine, PVOID ApcContext, PIO_STATUS_BLOCK IoStatusBlock, PVOID Buffer, ULONG Length, PLARGE_INTEGER ByteOffset, PULONG Key);
// NTSTATUS __stdcall ZwClose(HANDLE Handle);
// NTSTATUS __stdcall ZwOpenFile(PHANDLE FileHandle, ACCESS_MASK DesiredAccess, POBJECT_ATTRIBUTES ObjectAttributes, PIO_STATUS_BLOCK IoStatusBlock, ULONG ShareAccess, ULONG OpenOptions);
// NTSTATUS __stdcall ZwQueryInformationFile(HANDLE FileHandle, PIO_STATUS_BLOCK IoStatusBlock, PVOID FileInformation, ULONG Length, FILE_INFORMATION_CLASS FileInformationClass);
// BOOLEAN __stdcall PsGetVersion(PULONG MajorVersion, PULONG MinorVersion, PULONG BuildNumber, PUNICODE_STRING CSDVersion);
// int __cdecl stricmp(const char *, const char ;
// NTSTATUS __stdcall PsSetLoadImageNotifyRoutine(PLOAD_IMAGE_NOTIFY_ROUTINE NotifyRoutine);
// PVOID __stdcall ExAllocatePool(POOL_TYPE PoolType, SIZE_T NumberOfBytes);
// void __fastcall IofCompleteRequest(PIRP Irp, CCHAR PriorityBoost);
// NTSTATUS __stdcall IoCreateDevice(PDRIVER_OBJECT DriverObject, ULONG DeviceExtensionSize, PUNICODE_STRING DeviceName, ULONG DeviceType, ULONG DeviceCharacteristics, BOOLEAN Exclusive, PDEVICE_OBJECT eviceObject);
// BOOLEAN __stdcall RtlDeleteElementGenericTable(PRTL_GENERIC_TABLE Table, PVOID Buffer);
// PKTHREAD __stdcall KeGetCurrentThread();
// PVOID __stdcall RtlLookupElementGenericTable(PRTL_GENERIC_TABLE Table, PVOID Buffer);
// void __stdcall RtlInitializeGenericTable(PRTL_GENERIC_TABLE Table, PRTL_GENERIC_COMPARE_ROUTINE CompareRoutine, PRTL_GENERIC_ALLOCATE_ROUTINE AllocateRoutine, PRTL_GENERIC_FREE_ROUTINE FreeRoutine, PVOID TableContext);
// PVOID __stdcall RtlInsertElementGenericTable(PRTL_GENERIC_TABLE Table, PVOID Buffer, CLONG BufferSize, PBOOLEAN NewElement);
// WCHAR __stdcall RtlUpcaseUnicodeChar(WCHAR SourceCharacter);
// NTSTATUS __stdcall ZwAllocateVirtualMemory(HANDLE ProcessHandle, PVOID *BaseAddress, ULONG ZeroBits, PULONG AllocationSize, ULONG AllocationType, ULONG Protect);
// void __stdcall RtlInitUnicodeString(PUNICODE_STRING DestinationString, PCWSTR SourceString);
// void __stdcall IoRegisterDriverReinitialization(PDRIVER_OBJECT DriverObject, PDRIVER_REINITIALIZE DriverReinitializationRoutine, PVOID Context);
// void __stdcall ExFreePoolWithTag(PVOID P, ULONG Tag);
// void __stdcall KeInitializeMutex(PRKMUTEX Mutex, ULONG Level);
// LONG __stdcall KeReleaseMutex(PRKMUTEX Mutex, BOOLEAN Wait);
// NTSTATUS __stdcall KeWaitForSingleObject(PVOID Object, KWAIT_REASON WaitReason, KPROCESSOR_MODE WaitMode, BOOLEAN Alertable, PLARGE_INTEGER Timeout);
// NTSTATUS __stdcall ZwQueryValueKey(HANDLE KeyHandle, PUNICODE_STRING ValueName, KEY_VALUE_INFORMATION_CLASS KeyValueInformationClass, PVOID KeyValueInformation, ULONG Length, PULONG ResultLength);
// NTSTATUS __stdcall ZwOpenKey(PHANDLE KeyHandle, ACCESS_MASK DesiredAccess, POBJECT_ATTRIBUTES ObjectAttributes);
// int __stdcall KeUnstackDetachProcess(_DWORD); weak
// int __stdcall KeStackAttachProcess(_DWORD, _DWORD); weak
// NTSTATUS __stdcall ZwQueryInformationProcess(HANDLE ProcessHandle, PROCESSINFOCLASS ProcessInformationClass, PVOID ProcessInformation, ULONG ProcessInformationLength, PULONG ReturnLength);
// int __stdcall ObOpenObjectByPointer(_DWORD, _DWORD, _DWORD, _DWORD, _DWORD, _DWORD, _DWORD); weak
// int __stdcall PsLookupProcessByProcessId(_DWORD, _DWORD); weak
// LONG_PTR __fastcall ObfDereferenceObject(PVOID Object);
// signed int __usercall sub_12A24<eax>(int a1<esi>);
signed int __cdecl sub_12A95(int a1);
// bool __usercall sub_12D37<eax>(int a1<eax>, int a2);
int __thiscall sub_12D71(void *this);
// signed int __usercall sub_13343<eax>(int a1<eax>, unsigned int a2);
// int __usercall sub_133BF<eax>(int a1<eax>, int a2, int a3);
// int __usercall sub_13409<eax>(int a1<eax>, int a2, int a3, int a4);
// int __usercall sub_1356E<eax>(unsigned int *a1<eax>, int a2<ebx>, int a3<edi>, int a4, int a5, int a6);
int __thiscall sub_1369C(void *this);
signed int __cdecl sub_136F8(int a1, int a2, int a3);
signed int __cdecl sub_138BE(int a1, unsigned int a2);
bool __cdecl sub_138DB(int a1, unsigned int a2, int a3, int a4);
int __cdecl sub_1392E(int a1);
// signed int __usercall sub_13A4B<eax>(unsigned int a1<eax>, int a2, int a3, unsigned __int16 a4);
// signed int __usercall sub_13B3A<eax>(int a1<eax>, unsigned int a2<ebx>);
// int __usercall sub_13BF1<eax>(unsigned int a1<eax>, int a2<ecx>, int a3, int a4, int a5);
// signed int __usercall sub_13C66<eax>(int a1<eax>, int a2<edx>, int a3<ecx>, unsigned int a4);
int __cdecl sub_13C92(int a1, char a2, int a3);
// int __usercall sub_13CC0<eax>(int a1<eax>, int a2<edx>);
// signed int __usercall sub_13D8E<eax>(int a1<eax>, int a2, int a3, unsigned int a4, int (__cdecl *a5)(_DWORD, _DWORD, _DWORD));

//----- (00010300) --------------------------------------------------------
char __cdecl sub_10300()
{
LSA_UNICODE_STRING DestinationString; // [sp+8h] [bp-18h]@1
char v2; // [sp+10h] [bp-10h]@1
HANDLE Handle; // [sp+14h] [bp-Ch]@2
int v4; // [sp+18h] [bp-8h]@1
char v5; // [sp+1Fh] [bp-1h]@1

RtlInitUnicodeString(&DestinationString, L"\\SystemRoot\\System32\\hal.dll");
v4 = 0;
sub_105E4(&DestinationString, (int)&v4, (int)&v2);
v5 = v4 == 0;
if ( v2 )
{
v2 = 0;
ZwClose(Handle);
}
return v5;
}

//----- (0001034C) --------------------------------------------------------
void __stdcall DriverReinitializationRoutine(PDRIVER_OBJECT DriverObject, int a2, unsigned int a3)
{
if ( !KeGetCurrentIrql() )
{
if ( a3 <= 0x65 )
{
if ( !sub_10542() )
{
if ( sub_10300() )
sub_10A3A();
else
IoRegisterDriverReinitialization(DriverObject, DriverReinitializationRoutine, 0);
}
}
}
}

//----- (000103AA) --------------------------------------------------------
NTSTATUS __stdcall DriverEntry(PDRIVER_OBJECT DriverObject, PUNICODE_STRING RegistryPath)
{
signed int v2; // eax@2
LSA_UNICODE_STRING DestinationString; // [sp+Ch] [bp-24h]@11
unsigned int i; // [sp+14h] [bp-1Ch]@3
CPPEH_RECORD ms_exc; // [sp+18h] [bp-18h]@1

ms_exc.disabled = 0;
dword_14624 = 128;
dword_1461C = (int)ExAllocatePool(0, 0x200u);
if ( dword_1461C )
{
byte_14628 = 1;
for ( i = (unsigned int)&unk_14380; i < (unsigned int)&unk_14384; i += 4 )
{
if ( *(_DWORD i )
(*(void (**)(void))i)();
}
v2 = 0;
}
else
{
v2 = -1073741823;
}
if ( !v2 )
{
if ( !sub_109B0((int)RegistryPath) )
{
RtlInitUnicodeString(&DestinationString, &SourceString);
if ( !IoCreateDevice(DriverObject, 0, &DestinationString, 0x22u, 0x100u, 0, (PDEVICE_OBJECT &RegistryPath) )
{
DriverObject->MajorFunction[0] = (PDRIVER_DISPATCH)sub_10BA2;
DriverObject->MajorFunction[2] = (PDRIVER_DISPATCH)sub_10BA2;
DriverObject->MajorFunction[14] = (PDRIVER_DISPATCH)sub_10BA2;
RegistryPath[3].Buffer = (PWSTR)((unsigned int)RegistryPath[3].Buffer & 0xFFFFFF7F);
IoRegisterDriverReinitialization(DriverObject, (PDRIVER_REINITIALIZE)DriverReinitializationRoutine, 0);
}
}
}
return 0;
}
// 10BA2: using guessed type int __stdcall sub_10BA2(int, int);
// 1461C: using guessed type int dword_1461C;
// 14624: using guessed type int dword_14624;
// 14628: using guessed type char byte_14628;

//----- (0001048A) --------------------------------------------------------
int __stdcall sub_1048A(int a1)
{
int v1; // edi@5
int result; // eax@7
int (*v3)(void); // edi@11
int v4; // [sp+Ch] [bp-128h]@6
__int16 v5; // [sp+120h] [bp-14h]@9
int v6; // [sp+130h] [bp-4h]@3

*(_BYTE a1 = 1;
if ( !KeGetCurrentIrql() )
{
sub_1056C((int)&v6);
if ( sub_10886(0) || sub_10886(1) )
return 0;
v1 = v6;
if ( sub_10886(2) )
{
memset(&v4, 255, 0x11Cu);
v4 = 284;
if ( !*(_DWORD v1 )
return -1073741823;
result = (*(int (__stdcall **)(int )v1)(&v4);
if ( result )
return result;
if ( !v5 )
return *(_DWORD (v1 + 4) != 0 ? 0xC0000001 : 0;
}
v3 = *(int (**)(void))(v1 + 4);
if ( v3 )
{
if ( (unsigned __int8)v3() )
*(_BYTE a1 = 0;
return 0;
}
return -1073741823;
}
*(_BYTE a1 = 0;
return 0;
}

//----- (00010542) --------------------------------------------------------
int __cdecl sub_10542()
{
int result; // eax@1
char v1; // [sp+7h] [bp-1h]@1

v1 = 0;
result = sub_1048A((int)&v1);
if ( !result )
result = (v1 != 0 ? 0x3FFFFFFF : 0) - 1073741823;
return result;
}

//----- (0001056C) --------------------------------------------------------
int __usercall sub_1056C<eax>(int a1<esi>)
{
int v1; // ecx@2

*(_DWORD a1 = 0;
if ( !(dword_146A4 & 1) )
{
dword_146A4 |= 1u;
sub_107E8();
sub_107A2(v1, (int)nullsub_1);
}
byte_14614 = 0;
*(_DWORD a1 = &dword_14694;
return a1;
}
// 124FA: using guessed type int nullsub_1();
// 14614: using guessed type char byte_14614;
// 14694: using guessed type int dword_14694;
// 146A4: using guessed type int dword_146A4;

//----- (000105A0) --------------------------------------------------------
int __userpurge sub_105A0<eax>(int a1<ebx>, SIZE_T a2<edi>, int a3<esi>, const void *a4)
{
PVOID v4; // eax@1
char v5; // zf@1

v4 = ExAllocatePool(0, a2);
v5 = *(_DWORD a1 == 0;
*(_DWORD a3 = v4;
*(_DWORD (a3 + 4) = a2;
*(_DWORD (a3 + 8) = v4;
*(_DWORD (a3 + 12) = a2;
if ( v5 )
{
if ( *(_DWORD a3 )
{
if ( a4 )
memcpy(*(void **)a3, a4, a2);
}
else
{
*(_DWORD a1 = -1073741823;
}
}
return a3;
}

//----- (000105E4) --------------------------------------------------------
int __usercall sub_105E4<eax>(LSA_UNICODE_STRING *a1<ecx>, int a2<edi>, int a3<esi>)
{
char v3; // zf@1
NTSTATUS v4; // eax@2
OBJECT_ATTRIBUTES ObjectAttributes; // [sp+8h] [bp-20h]@2
struct _IO_STATUS_BLOCK IoStatusBlock; // [sp+20h] [bp-8h]@2

v3 = *(_DWORD a2 == 0;
*(_BYTE a3 = 0;
*(_DWORD (a3 + 4) = 0;
if ( v3 )
{
ObjectAttributes.ObjectName = a1;
ObjectAttributes.Length = 24;
ObjectAttributes.RootDirectory = 0;
ObjectAttributes.Attributes = 576;
ObjectAttributes.SecurityDescriptor = 0;
ObjectAttributes.SecurityQualityOfService = 0;
v4 = ZwOpenFile((PHANDLE)(a3 + 4), 0x80100000u, &ObjectAttributes, &IoStatusBlock, 1u, 0x60u);
*(_DWORD a2 = v4;
*(_BYTE a3 = v4 == 0;
}
return a3;
}

//----- (00010638) --------------------------------------------------------
ULONG __thiscall sub_10638(LSA_UNICODE_STRING *this, ULONG a2, int a3)
{
char v3; // bl@1
ULONG result; // eax@4
HANDLE v5; // ecx@6
ULONG v6; // edi@6
ULONG v7; // esi@6
NTSTATUS v8; // eax@7
int v9; // eax@17
int v10; // eax@18
void **v11; // eax@21
void *v12; // eax@22
char FileInformation; // [sp+10h] [bp-28h]@7
ULONG v14; // [sp+18h] [bp-20h]@7
void *v15; // [sp+1Ch] [bp-1Ch]@7
ULONG Length; // [sp+28h] [bp-10h]@1
HANDLE Handle; // [sp+2Ch] [bp-Ch]@3
struct _IO_STATUS_BLOCK IoStatusBlock; // [sp+30h] [bp-8h]@1

v3 = 0;
IoStatusBlock.Information = 0;
sub_105E4(this, (int)&IoStatusBlock.Information, (int)&Length);
if ( IoStatusBlock.Information )
goto LABEL_2;
if ( (_BYTE)Length )
{
v8 = ZwQueryInformationFile(Handle, &IoStatusBlock, &FileInformation, 0x18u, FileStandardInformation);
v6 = v14;
v5 = v15;
v7 = v8;
}
else
{
v5 = Handle;
v6 = Length;
v7 = -1073741823;
}
IoStatusBlock.Information = v7;
if ( v7 )
goto LABEL_9;
if ( v5 || v6 > a2 )
goto LABEL_31;
v9 = (int)ExAllocatePool(0, 0x10u);
if ( v9 )
v10 = sub_105A0((int)&IoStatusBlock.Information, v6, v9, 0);
else
v10 = 0;
sub_1076E(a3, (PVOID v10);
v3 = 0;
if ( IoStatusBlock.Information )
{
LABEL_2:
if ( (_BYTE)Length != v3 )
{
LOBYTE(Length) = v3;
ZwClose(Handle);
}
return IoStatusBlock.Information;
}
v11 = *(void ***)(a3 + 4);
if ( !v11 )
goto LABEL_31;
v12 = *v11;
if ( !(_BYTE)Length )
return -1073741823;
v7 = ZwReadFile(Handle, 0, 0, 0, &IoStatusBlock, v12, v6, 0, 0);
if ( v7 )
{
LABEL_9:
if ( (_BYTE)Length != v3 )
{
LOBYTE(Length) = v3;
ZwClose(Handle);
}
return v7;
}
if ( IoStatusBlock.Information != v6 )
{
LABEL_31:
if ( (_BYTE)Length != v3 )
{
LOBYTE(Length) = v3;
ZwClose(Handle);
}
result = -1073741823;
}
else
{
if ( (_BYTE)Length )
{
LOBYTE(Length) = 0;
ZwClose(Handle);
}
result = 0;
}
return result;
}

//----- (0001076E) --------------------------------------------------------
void __userpurge sub_1076E(int a1<ebx>, PVOID *a2)
{
PVOID *v2; // esi@1

v2 = *(PVOID **)(a1 + 4);
if ( a2 != v2 )
{
if ( v2 )
{
if ( *v2 )
ExFreePoolWithTag(*v2, 0);
ExFreePoolWithTag(v2, 0);
}
*(_DWORD (a1 + 4) = a2;
}
}

//----- (000107A2) --------------------------------------------------------
signed int __fastcall sub_107A2(int a1, int a2)
{
signed int result; // eax@5

if ( !byte_14628 )
goto LABEL_9;
if ( !dword_1461C )
goto LABEL_9;
if ( dword_14624 <= dword_14620 )
goto LABEL_9;
_ECX = &dword_14620;
_EAX = 1;
__asm { lock xadd [ecx], eax }
if ( dword_14624 > _EAX )
{
*(_DWORD (dword_1461C + 4 * _EAX) = a2;
result = 0;
}
else
{
LABEL_9:
result = 1;
}
return result;
}
// 1461C: using guessed type int dword_1461C;
// 14620: using guessed type int dword_14620;
// 14624: using guessed type int dword_14624;
// 14628: using guessed type char byte_14628;

//----- (000107E8) --------------------------------------------------------
int *__cdecl sub_107E8()
{
int v0; // eax@2
char v2; // [sp+4h] [bp-20h]@3

dword_14694 = 0;
dword_14698 = 0;
dword_1469C = 0;
dword_146A0 = 0;
if ( !sub_10886(0) )
{
v0 = sub_1098E();
if ( v0 )
{
if ( !sub_121E1((int)&v2, v0, 1) )
{
dword_14694 = sub_1236B((int)&v2, -899745608);
dword_14698 = sub_1236B((int)&v2, -1332885072);
dword_1469C = sub_1236B((int)&v2, -2007787012);
dword_146A0 = sub_1236B((int)&v2, 1516803388);
}
}
}
return &dword_14694;
}
// 14694: using guessed type int dword_14694;
// 14698: using guessed type int dword_14698;
// 1469C: using guessed type int dword_1469C;
// 146A0: using guessed type int dword_146A0;

//----- (00010886) --------------------------------------------------------
bool __stdcall sub_10886(int a1)
{
ULONG MinorVersion; // [sp+0h] [bp-8h]@1
ULONG MajorVersion; // [sp+4h] [bp-4h]@1

MajorVersion = 0;
MinorVersion = 0;
PsGetVersion(&MajorVersion, &MinorVersion, 0, 0);
return MajorVersion == 5 && a1 == MinorVersion;
}

//----- (000108BE) --------------------------------------------------------
int __stdcall sub_108BE(const char *a1)
{
ULONG v1; // edi@3
PVOID v2; // esi@6
int v4; // edi@17
PVOID v5; // [sp-8h] [bp-3Ch]@5
ULONG v6; // [sp-4h] [bp-38h]@5
PVOID P; // [sp+10h] [bp-24h]@3
int SystemInformation; // [sp+20h] [bp-14h]@1
char *v9; // [sp+24h] [bp-10h]@3
int v10; // [sp+28h] [bp-Ch]@13
ULONG SystemInformationLength; // [sp+2Ch] [bp-8h]@1

SystemInformationLength = 0;
SystemInformation = 0;
if ( ZwQuerySystemInformation(SystemModuleInformation, &SystemInformation, 0, &SystemInformationLength) != -1073741820
|| !SystemInformationLength )
return 0;
v9 = 0;
sub_105A0((int)&v9, SystemInformationLength, (int)&P, 0);
v1 = 0;
if ( v9 )
{
if ( P )
{
v6 = 0;
v5 = P;
LABEL_9:
ExFreePoolWithTag(v5, v6);
}
return 0;
}
v2 = P;
if ( ZwQuerySystemInformation(SystemModuleInformation, P, SystemInformationLength, (PULONG)&SystemInformation) )
{
if ( !v2 )
return 0;
LABEL_8:
v6 = v1;
v5 = v2;
goto LABEL_9;
}
if ( *(_DWORD v2 <= 0u )
goto LABEL_8;
v10 = 0;
v9 = (char v2 + 30;
while ( stricmp((const char v2 + v10 + *(_WORD v9 + 32, a1) )
{
v10 += 284;
v9 += 284;
++v1;
if ( v1 >= *(_DWORD v2 )
{
v1 = 0;
goto LABEL_8;
}
}
v4 = *((_DWORD v2 + 71 * v1 + 3);
ExFreePoolWithTag(v2, 0);
return v4;
}

//----- (0001098E) --------------------------------------------------------
int __cdecl sub_1098E()
{
int result; // eax@1

result = sub_108BE(dword_124C0);
if ( !result )
result = sub_108BE(dword_124D0);
return result;
}

//----- (000109B0) --------------------------------------------------------
signed int __usercall sub_109B0<eax>(int a1<edi>)
{
signed int result; // eax@8

if ( byte_14390 )
{
sub_11EC6(0, (int)&dword_14391, 0x278u);
byte_14390 = 0;
}
if ( !word_14395 )
{
if ( (unsigned int)*(_WORD a1 + 2 <= 0xC8 )
{
memset((void &word_14395, 0, 0xC8u);
memcpy((void &word_14395, *(const void **)(a1 + 4), *(_WORD a1);
}
}
if ( dword_14391 & 1 && InitSafeBootMode || dword_14391 & 2 && (_BYTE)KdDebuggerEnabled )
result = -1073741823;
else
result = 0;
return result;
}
// 125E4: using guessed type void *InitSafeBootMode;
// 14390: using guessed type char byte_14390;
// 14391: using guessed type int dword_14391;

//----- (00010A3A) --------------------------------------------------------
int __cdecl sub_10A3A()
{
int result; // eax@1
char v1; // [sp+8h] [bp-8h]@1
int v2; // [sp+Ch] [bp-4h]@1

v2 = 0;
sub_10A8A((int)&v1, &v2);
result = v2;
if ( !v2 )
{
sub_10AE2((int)&v2);
result = sub_10C22(v2);
if ( !result )
{
sub_10B36((int)&v1);
sub_1056C((int)&v1);
result = PsSetLoadImageNotifyRoutine((PLOAD_IMAGE_NOTIFY_ROUTINE)NotifyRoutine);
}
}
return result;
}

//----- (00010A8A) --------------------------------------------------------
int __usercall sub_10A8A<eax>(int a1<edi>, int *a2<esi>)
{
int v2; // eax@2
int v3; // ecx@4

*(_DWORD a1 = 0;
if ( !(dword_146B0 & 1) )
{
v2 = *a2;
dword_146B0 |= 1u;
dword_146AC = v2;
}
if ( !(dword_146B0 & 2) )
{
dword_146B0 |= 2u;
sub_11C14();
sub_107A2(v3, (int)nullsub_3);
}
if ( dword_146AC )
*a2 = dword_146AC;
else
*(_DWORD a1 = &dword_146A8;
byte_14615 = 0;
return a1;
}
// 12508: using guessed type int nullsub_3();
// 14615: using guessed type char byte_14615;
// 146A8: using guessed type int dword_146A8;
// 146AC: using guessed type int dword_146AC;
// 146B0: using guessed type int dword_146B0;

//----- (00010AE2) --------------------------------------------------------
int __usercall sub_10AE2<eax>(int a1<esi>)
{
int v1; // ecx@2

*(_DWORD a1 = 0;
if ( !(dword_14690 & 1) )
{
dword_14668 = 0;
dword_14690 |= 1u;
byte_14664 = 1;
memset(&Mutex, 0, sizeof(Mutex));
KeInitializeMutex(&Mutex, 0);
sub_107A2(v1, (int)sub_124FE);
}
byte_14616 = 0;
*(_DWORD a1 = &byte_14664;
return a1;
}
// 124FE: using guessed type int sub_124FE();
// 14616: using guessed type char byte_14616;
// 14664: using guessed type char byte_14664;
// 14668: using guessed type int dword_14668;
// 14690: using guessed type int dword_14690;

//----- (00010B36) --------------------------------------------------------
int __usercall sub_10B36<eax>(int a1<esi>)
{
int v1; // ecx@2

*(_DWORD a1 = 0;
if ( !(dword_1468C & 1) )
{
dword_1468C |= 1u;
sub_10FE6();
sub_107A2(v1, (int)nullsub_2);
}
byte_14617 = 0;
*(_DWORD a1 = &Table;
return a1;
}
// 124FC: using guessed type int nullsub_2();
// 14617: using guessed type char byte_14617;
// 1468C: using guessed type int dword_1468C;

//----- (00010B68) --------------------------------------------------------
int __thiscall sub_10B68(int this)
{
int result; // eax@3
int v2; // [sp+0h] [bp-4h]@1

v2 = this;
if ( *(_DWORD (*(_DWORD (this + 96) + 12) == 2242560 )
{
result = sub_11CCC(this);
}
else
{
if ( *(_DWORD (*(_DWORD (this + 96) + 12) == 2242564 )
{
sub_10AE2((int)&v2);
result = sub_10C22(v2);
}
else
{
result = -1073741822;
}
}
return result;
}

//----- (00010BE8) --------------------------------------------------------
signed int __cdecl sub_10BE8()
{
return 1;
}

//----- (00010BEC) --------------------------------------------------------
int __userpurge sub_10BEC<eax>(int a1<ebp>, int a2, int a3)
{
int v3; // edi@1
int v4; // esi@1

*(_DWORD (a1 - 4) = -1;
v4 = *(_DWORD (a1 + 12);
v3 = *(_DWORD (a1 - 28);
if ( v3 != 259 )
{
if ( v3 )
*(_DWORD (v4 + 28) = 0;
*(_DWORD (v4 + 24) = v3;
IofCompleteRequest((PIRP)v4, 0);
}
return _SEH_epilog();
}
// 12463: using guessed type int _SEH_epilog(void);

//----- (00010C22) --------------------------------------------------------
signed int __usercall sub_10C22<eax>(int a1<eax>)
{
int v1; // edi@1
int v2; // eax@3
unsigned int v3; // esi@3
int v4; // ecx@3
signed int v6; // esi@6
int v7; // edi@9
struct _KMUTANT *v8; // [sp+10h] [bp-20h]@1
ULONG v9; // [sp+14h] [bp-1Ch]@1
LSA_UNICODE_STRING ValueName; // [sp+18h] [bp-18h]@1
LSA_UNICODE_STRING DestinationString; // [sp+20h] [bp-10h]@1
char v12; // [sp+28h] [bp-8h]@2

v1 = a1;
RtlInitUnicodeString(&DestinationString, &word_14395);
RtlInitUnicodeString(&ValueName, &word_1445D);
v8 = (struct _KMUTANT (v1 + 8);
KeWaitForSingleObject((PVOID)(v1 + 8), 0, 0, 0, 0);
v9 = sub_11D62(&DestinationString, &ValueName, v1);
if ( v9 )
{
RtlInitUnicodeString((PUNICODE_STRING)&v12, &word_14471);
v9 = sub_10638((LSA_UNICODE_STRING &v12, dword_14539, v1);
if ( v9 )
{
LABEL_6:
v6 = -1073741823;
goto LABEL_7;
}
}
v2 = *(_DWORD (v1 + 4);
v3 = *(_DWORD (v2 + 4);
sub_11EC6(dword_1453D, *(_DWORD v2, v3);
if ( sub_11D46(v4, v3) )
{
KeReleaseMutex(v8, 0);
return -1073741823;
}
v6 = v9;
if ( !v9 )
{
v7 = *(_DWORD (v1 + 4);
if ( v7 && *(_DWORD (v7 + 4) > 0u )
{
v6 = 0;
goto LABEL_7;
}
goto LABEL_6;
}
LABEL_7:
KeReleaseMutex(v8, 0);
return v6;
}
// 14539: using guessed type int dword_14539;
// 1453D: using guessed type int dword_1453D;

//----- (00010CFE) --------------------------------------------------------
signed int __stdcall sub_10CFE(int a1, int a2)
{
int v2; // eax@1
int v3; // edi@1
int v4; // esi@1
int v5; // eax@2
signed int v6; // edi@5
int v8; // [sp+10h] [bp-4h]@1

v3 = a1;
v4 = 0;
v8 = 0;
KeWaitForSingleObject((PVOID)(a1 + 8), 0, 0, 0, 0);
v2 = (int)ExAllocatePool(0, 0x10u);
if ( v2 )
{
v5 = sub_105A0((int)&v8, *(_DWORD (*(_DWORD (a1 + 4) + 4), v2, **(const void ***)(a1 + 4));
v3 = a1;
v4 = 0;
}
else
{
v5 = 0;
}
sub_1076E(a2, (PVOID v5);
if ( v8 == v4 )
{
if ( *(_DWORD (v3 + 4) == v4 )
v6 = -1073741823;
else
v6 = 0;
}
else
{
v6 = v8;
}
KeReleaseMutex((PRKMUTEX)(a1 + 8), v4);
return v6;
}

//----- (00010D7E) --------------------------------------------------------
void __usercall sub_10D7E(int a1<eax>)
{
PVOID *v1; // edi@2

if ( *(_BYTE a1 )
{
v1 = *(PVOID **)(a1 + 4);
*(_BYTE a1 = 0;
if ( v1 )
{
if ( *v1 )
ExFreePoolWithTag(*v1, 0);
ExFreePoolWithTag(v1, 0);
}
}
}

//----- (00010DA8) --------------------------------------------------------
int __usercall sub_10DA8<eax>(int a1<ecx>, int a2<edi>, int a3<esi>)
{
int v4; // eax@1
int v5; // [sp+0h] [bp-4h]@1

v5 = a1;
sub_10FC4(a3, (int)&v5);
*(_DWORD a2 = *(_DWORD (a3 + 8) + *(_DWORD a3;
v4 = v5;
*(_DWORD (a2 + 4) = v5;
*(_DWORD (a3 + 8) += v4;
return a3;
}

//----- (00010DCC) --------------------------------------------------------
void __stdcall sub_10DCC(int a1, HANDLE Handle, int a3)
{
int v3; // ecx@9
int v4; // esi@9
int v5; // ebx@12
int v6; // ecx@12
int v7; // eax@14
int i; // [sp+10h] [bp-50h]@4
unsigned int v9; // [sp+14h] [bp-4Ch]@9
RTL_GENERIC_TABLE *v10; // [sp+18h] [bp-48h]@8
int v11; // [sp+1Ch] [bp-44h]@8
int v12; // [sp+20h] [bp-40h]@9
char v13; // [sp+24h] [bp-3Ch]@8
int v14; // [sp+28h] [bp-38h]@8
int v15; // [sp+2Ch] [bp-34h]@9
int v16; // [sp+30h] [bp-30h]@9
int v17; // [sp+34h] [bp-2Ch]@11
int v18; // [sp+38h] [bp-28h]@11
int v19; // [sp+3Ch] [bp-24h]@4
char v20; // [sp+40h] [bp-20h]@7
WCHAR *v21; // [sp+44h] [bp-1Ch]@11
char v22; // [sp+4Ch] [bp-14h]@14
int v23; // [sp+54h] [bp-Ch]@9
unsigned int v24; // [sp+58h] [bp-8h]@9
int v25; // [sp+5Ch] [bp-4h]@9

if ( sub_117A8(L"KERNEL32.DLL", a1) )
{
sub_1174A((int)Handle, a3);
}
else
{
if ( !sub_10542() )
{
i = 0;
sub_11F42((int)&v19, (int)&i, Handle);
if ( !i )
{
if ( v19 == *(_DWORD (a3 + 4) )
{
if ( !(dword_14391 & 4) || !v20 )
{
sub_10B36((int)&v10);
sub_11066((int)Handle, v10);
v13 = 1;
v14 = 0;
sub_10AE2((int)&v11);
if ( !sub_10CFE(v11, (int)&v13) )
{
v3 = *(_DWORD v14;
v24 = *(_DWORD (v14 + 4);
v23 = v3;
v25 = 0;
v15 = 0;
v16 = 0;
sub_10FC4((int)&v23, (int)&v12);
sub_10DA8(v3, (int)&v15, (int)&v23);
sub_10FC4((int)&v23, (int)&v9);
v4 = v25;
if ( v25 <= v24 )
{
if ( !v12 )
{
v21 = 0;
v17 = 0;
v18 = 0;
for ( i = 0; i < v9; ++i )
{
v5 = v4 + v23;
v25 = v4 + 16;
v12 = v4 + v23;
sub_10DA8(v3, (int)&v21, (int)&v23);
sub_10DA8(v6, (int)&v17, (int)&v23);
v4 = v25;
if ( v25 > v24 )
break;
if ( sub_117A8(v21, a1) )
{
v7 = sub_111B4((int)&v15, (int)&v22, *(_DWORD (v5 + 12));
sub_11522((int)Handle, a3, v12, (int)&v17, v7);
}
}
}
}
}
sub_10D7E((int)&v13);
}
}
}
}
}
}
// 124E0: using guessed type wchar_t aKernel32_dll[13];
// 14391: using guessed type int dword_14391;

//----- (00010F80) --------------------------------------------------------
void __stdcall NotifyRoutine(int a1, HANDLE Handle, int a3)
{
if ( KeGetCurrentIrql() <= 1u )
{
if ( Handle )
sub_10DCC(a1, Handle, a3);
}
}

//----- (00010FC4) --------------------------------------------------------
int __userpurge sub_10FC4<eax>(int result<eax>, int a2)
{
int v2; // ecx@1

v2 = *(_DWORD (result + 8);
if ( (unsigned int)(v2 + 4) <= *(_DWORD (result + 4) )
*(_DWORD a2 = *(_DWORD (v2 + *(_DWORD result);
*(_DWORD (result + 8) = v2 + 4;
return result;
}

//----- (00010FE6) --------------------------------------------------------
RTL_GENERIC_TABLE *__cdecl sub_10FE6()
{
memset(&Table, 0, sizeof(Table));
byte_14658 = -1;
dword_14654 = 0;
dword_1465C = 0;
dword_14660 = 0;
RtlInitializeGenericTable(
&Table,
(PRTL_GENERIC_COMPARE_ROUTINE)CompareRoutine,
(PRTL_GENERIC_ALLOCATE_ROUTINE)AllocateRoutine,
(PRTL_GENERIC_FREE_ROUTINE)FreeRoutine,
0);
return &Table;
}
// 14654: using guessed type int dword_14654;
// 14658: using guessed type char byte_14658;
// 1465C: using guessed type int dword_1465C;
// 14660: using guessed type int dword_14660;

//----- (00011028) --------------------------------------------------------
PVOID __usercall sub_11028<eax>(int a1<eax>, RTL_GENERIC_TABLE *a2<edi>)
{
PKSPIN_LOCK v2; // ecx@1
PVOID v3; // esi@1
PVOID v4; // eax@1
char v5; // zf@1
KIRQL v6; // dl@2
int Buffer; // [sp+8h] [bp-18h]@1
PKSPIN_LOCK SpinLock; // [sp+1Ch] [bp-4h]@1

quote:

Op zaterdag 18 februari 2012 16:05 schreef J0kkebr0k het volgende:
Uhm... mijn post van vannacht sloeg idd helemaal nergens op en was nogal kansloos! Laten we het er op houden dat ik net terug uit de kroeg was en straalbezopen achter FOK ben gaan zitten