De oorsprong lijkt me zo goed als zeker:quote:Op woensdag 15 februari 2012 21:35 schreef YuckFou het volgende:
Dit is dan misschien een artikel wat wel lijkt te onderschrijven dat Stuxnet is gefabriceerd door de Israeli's , maar dan nog steeds geënt op het slopen van Iraanse Centrifuges...
Ik vraag me vnl af, kan het zo zijn dat dit " per ongeluk " in de Japanse centrales terecht is gekomen?quote:The covert American program, started in early 2008, includes renewed American efforts to penetrate Iran’s nuclear supply chain abroad, along with new efforts, some of them experimental, to undermine electrical systems, computer systems and other networks on which Iran relies. It is aimed at delaying the day that Iran can produce the weapons-grade fuel and designs it needs to produce a workable nuclear weapon.
http://www.nytimes.com/20(...)0natanz&st=cse&scp=1
?Nog veel leeswerk te doen.quote:The other technical mystery is that Tepco engineers suggested that the electric power inside the plant was knocked out by something other than the tsunami. I have pointed to this possibility early on, that the quake and control disruptions could have made the control computers vulnerable to the Stuxnet virus.
http://www.globalresearch.ca/index.php?context=va&aid=24364
Belangrijkste spelers op de markt ivm PLC zijn Siemens en Yokogawa.quote:Op vrijdag 17 februari 2012 11:36 schreef Resonancer het volgende:
Ik vraag me vnl af, kan het zo zijn dat dit " per ongeluk " in de Japanse centrales terecht is gekomen?
Voor het gemak is hier even overgeslagen dat Stuxnet zichzelf akelig goed kan verbergen, derhalve nergens sporen achter laat en zelfs de operators ervan kan overtuigen dat er niks aan de hand is...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."
Nou ben ik best wel een geek (nerd zelf volgens mn vriendjequote: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.
GE, Schneider, Siemens, ik denk dat met de hierboven genoemde merken zeg, 70/80% (eigen schatting) van de industrieële besturingen wel te maken heeft, en al die sturingen zijn dus in principe gevoelig voor hacks via Stuxnet of een variant ervan, scray thought, Anonymous heeft eerder te laten zien niet bang te zijn om de FBI, Visa en dat soort molochs aan te valen, wat als ze een eigen worm bij een nutsbedrijf weten in te brengen en om maar even een dwarsstraat te noemen, een powerplant in Washington DC voor een half uurtje platleggen?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.”
Dat is al een aantal jaar het gevalquote:Nou ben ik best wel een geek (nerd zelf volgens mn vriendje) maar ik moet hier even pas op de plaats maken, nieuwe drivers? speciaal gemaakt om dit/deze wormen functies te geven die nog niet bestaan, is dat nieuw? Of gebeurt dat ook bij andere wormen? Ik dacht dat wormen en aanverwante meestal gebruik maakten van bestaande DLL's en die op een manier gebruiken die oneigenlijk is, of gebeurt dit vaker?
Bron: http://www.security.nl/ar(...)wapenfabriek%22.htmlquote:"Stuxnet en Duqu afkomstig uit digitale wapenfabriek"
29-12-2011,10:16 doorRedactie
De Stuxnetworm en Duqu-virus zijn niet alleen door hetzelfde team gemaakt, ze zijn afkomstig van een speciaal platform voor supermalware dat sinds 2007 in ontwikkeling is. Dat stelt het Russische anti-virusbedrijf Kaspersky Lab in een technische analyse op het eigen weblog. "We denken dat Duqu en Stuxnet gelijktijdige projecten waren, ondersteund door hetzelfde ontwikkelteam", stellen Alexander Gostev en Igor Soumenkov.
Stuxnet was een zeer geavanceerde worm die verschillende Windows-lekken gebruikte om het Iraanse nucleaire programma te ontregelen. Duqu werd dit jaar ontdekt en zou gebruikt zijn om bij een select aantal organisaties en bedrijven in te breken en daar zeer vertrouwelijke gegevens te stelen.
Platform
Aan de hand van gevonden bestanden stellen de analisten dat voor de ontwikkeling van de malware een platform werd gebruikt, wat 'Tilded' wordt genoemd. De ontwikkelaars gebruikten voor een nog onbekende reden steeds bestandsnamen die met een "~d" begonnen. Verder denken de analisten dat er mogelijk nog één andere spyware module is, gebaseerd op hetzelfde platform dat van 2007-2008 dateert, en verschillende andere programma's, waarvan het doel en functionaliteit onduidelijk zijn en die tussen 2008 en 2010 werden ontwikkeld.
Tijdens de analyse van Duqu ontdekte Kaspersky Lab aanwijzingen die een directe relatie met Stuxnet hebben. Op dit moment zijn er vier Stuxnet drivers bekend die de worm gebruikt. De eerste aanpassing van de worm werd gemaakt in 2009 en gebruikte één driver, mrxcls.sys, zonder digitale handtekening.
In 2010 ontwikkelden de makers een tweede driver, mrxnet.sys, die de bestanden van de worm op USB-sticks verborg, en voorzagen de mrxnet.sys en mrxcls.sys drivers van gestolen digitale certificaten, die bij hardwarefabrikant Realtek werden buitgemaakt. Op 17 juli vorig jaar werd een andere driver ontdekt, jmidebs.sys, die erg veel leek op mrxcls.sys, maar gesigneerd was met een gestolen certificaat van hardwarefabrikant Jmicron.
Stuxnet
Op één van de computers die met het Duqu-virus besmet waren, werd een vreemd bestand ontdekt, wat de virusscanner als Rootkit.Win32.Stuxnet.a detecteerde. Dit zou moeten duiden op de mrxcls.sys driver, maar in dit geval waren de bestandsnaam en checksum van het vreemde bestand verschillend. De tot dan toe onbekende rtniczw.sys driver was iets groter dan mrxcls.sys en gebruikte ook een Realtek certificaat, maar de bestanden waren op een verschillende datum gesigneerd. Het nieuwe bestand werd op geen enkele andere computer aangetroffen. De enige andere referentie dateerde van mei dit jaar, toen iemand het bestand vanuit China voor controle naar VirusTotal stuurde.
"We kwamen tot de conclusie dat er andere driverbestanden konden zijn, gelijk aan het "referentiebestand" mrxcls.sys, die zich niet onder de bekende Stuxnet-varianten bevinden." Toen Kaspersky Lab hierop zocht, werd een ander bestand ontdekt dat een jaar geleden al aan de virusverzameling was toegevoegd. Dit bleek inderdaad een nieuwe Stuxnet-driver te zijn. Ook dit bestand, rndismpc.sys, was nog niet eerder op een andere machine aangetroffen.
De drie onbekende driver-bestanden, rndismpc.sys, rtniczw.sys en jmidebs.sys zijn volgens de virusbestrijder niet door Stuxnet gebruikt. "Waren ze door Stuxnet gebruikt, dan hadden ze een veel grotere afdruk achtergelaten dan de individuele gevallen die wij hebben ontdekt. Ten tweede is er geen enkele variant van Stuxnet die met deze drivers werkt", aldus de analisten. Die kunnen niet zeggen of de drivers dan wel door het Duqu-virus zijn gebruikt.
Toekomst
Aan de hand van de verzamelde informatie, stelt het anti-virusbedrijf dat het 'Tilded' platform eind 2007 of begin 2008 is ontwikkeld, voordat het in de zomer/herfst van vorig jaar de grootste veranderingen onderging. Die veranderingen zouden zijn aangewakkerd door ontwikkelingen in de code en de noodzaak om detectie door virusscanners te voorkomen.
"Er waren een aantal projecten tussen 2007 en 2011 waar programma's gebaseerd op het Tilded platform bij bij betrokken waren. Stuxnet en Duqu waren er twee van, er zouden er nog meer kunnen zijn, die tot nu toe nog onbekend zijn. Het platform blijft zich ontwikkelen, wat één ding kan betekenen, dat we in de toekomst waarschijnlijk meer aanpassingen zullen zien", besluiten de analisten.
Bron: http://www.security.nl/ar(...)ergeheim_lab%22.htmlquote:"Stuxnet gemaakt in supergeheim lab"
10-01-2012,13:31 doorRedactie
De zeer geavanceerde malware genaamd Duqu en Stuxnet, zijn gemaakt in een supergeheim laboratorium voor experimentele cyberwapens. Dat zegt Costin Raiu van anti-virusbedrijf Kaspersky Lab tegenover de Christian Science Monitor. De virusbestrijder deed uitgebreid onderzoek naar Duqu en ontdekte daarbij veel overeenkomsten met Stuxnet. Duqu werd ontwikkeld voor het stelen van zeer belangrijke gegevens, terwijl Stuxnet het Iraanse nucleaire programma ontregelde. "Het is net alsof ze een ionenkanon of zoiets ontwikkelen, alleen dan voor cyberoorlog. Dit zijn geen gewone wapens, maar de technisch meest geavanceerde wapens om cyberoorlog en cybersabotage te plegen."
Kaspersky Lab ontdekte dat Duqu en Stuxnet via een speciaal platform zijn ontwikkeld en dat er mogelijk nog meer varianten in omloop zijn. "Stel je voor dat je documenten wilt stelen", zegt Raiu. "Je hebt niet de sabotage mogelijkheden van Stuxnet nodig, dus die haal je eruit. In plaats daarvan gebruik je hetzelfde platform om gerichte malware te ontwikkelen, maar dan gericht op spionage. Dat is Duqu."
Atoombom
Beveiligingsexpert Ed Skoudis vergelijkt het met het Amerikaanse systeem voor het ontwikkelen van de atoombom. "Toen de VS de atoombom bouwde, was het niet de enige. We hadden een infrastructuur en platform om aanvullende wapens te bouwen." Volgens Skoudis beschikken de makers van Stuxnet over veel geld en slimme mensen. "Het is slim om dit soort wapens opnieuw te kunnen maken, en sommige achtergebleven vingerafdrukken laten dat zien."
Ook al wordt het software platform gebruikt voor Stuxnet en Duqu geïdentificeerd, zal dat nooit wijzen naar degene die de malware ook heeft gebouwd. "Ik denk niet dat het veel zal helpen", zegt Skoudis. "Maar deze ontdekking laat zien dat we meer van dit soort wapens kunnen verwachten, als er een militair doel zich voordat om het te gebruiken. We weten nu dat er een productiefaciliteit voor dit soort dingen is, en dat ze ook worden ingezet. Ik weet zeker dat we er meer zullen zien."
Ben ik ook nietquote:Op vrijdag 17 februari 2012 12:28 schreef J0kkebr0k het volgende:
@YuckFou: Wist niet dat jij een vrouw bent
Waar haal je dat uit ?quote:Op vrijdag 17 februari 2012 12:28 schreef J0kkebr0k het volgende:
@YuckFou: Wist niet dat jij een vrouw bent
[..]
Ah, ok. Homo dan.quote:Op vrijdag 17 februari 2012 18:49 schreef YuckFou het volgende:
[..]
Ben ik ook niet![]()
Verder kom ik er later op terug, zit zoals eerder gezegd in een retedrukke periode, maar probeer me tussen de bedrijven door in te lezen in de materie
Omdat hij het had over zijn vriendje, dus dacht even dat het een vrouw was. Maar ik zat er naast.quote:Op vrijdag 17 februari 2012 18:53 schreef ChungLingSoo het volgende:
[..]
Waar haal je dat uit ?
Sowieso schaamteloze TVP omdat dit mijn terrein betreft.
Wat is jouw terrein? homo zijn of virussen?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.
Computervirussen, hun werking en verspreiding zijn dingen waar ik me o.a. in specialiseer.quote:Op vrijdag 17 februari 2012 19:55 schreef YuckFou het volgende:
[..]
Wat is jouw terrein? homo zijn of virussen?
[..]
Hij wil je...quote:zooo kansloos
Ik ben echt een onverbeterlijke complotdenker eigenlijk. Nee, maar ik sta er achter.quote:Op maandag 6 februari 2012 19:39 schreef dadgad het volgende:
"Hun angst is dat wij wakker worden en de leugen inzien."
Cool&welkom!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
Een hele rake opmerking van jou die ik gepikt heb met bronvermelding omdat ik een nieuwe sig. nodig hadquote:
Ik ben hier al ZO veel langer dan jij, dus ik laat me echt niet afschrikkenquote:Op vrijdag 17 februari 2012 23:10 schreef YuckFou het volgende:
[..]
Cool&welkom!
Ik heb het bewust in [BNW] neergezet omdat hier wat richtinglozer gespeculeerd over kan worden over dingen, maar ik hou t graag reëel, dat anderen over wireless backdoors en andere bizarre zaken hier posten, mag, dat maakt dat je ook een andere kant op denkt dan alleen het "officieele" verhaal, zelf ben ik voorlopig druk genoeg met inlezen over Stuxnet en SCADA en dat kost sowieso veel tijd, maar mocht je wat nuttige aanvullingen hebben be my guest, en laat je niet afschrikken door t conspiracy sfeertje wat hier hangt, niet iedereen vermoed de mossad achter elke lantaarnpaal
[..]
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: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
[..]
Hij wil je...
[edit]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.
Wat een kansloze semi-rascistische opmerking.quote:
No you're not, we schelen een kleine 180.000 qua userregistratie, en ik loop voorquote: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
Mis ik iets? Kan je je toon een beetje matigen? Ik wilde een serieus topic, bullshit vecht je maar uit per PM [/MODmodus]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.
SPOILEROm 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.”Are we not savages, innately destined to maim and kill?
Blame it on the environment, heredity or evolution: we're still responsible
Our intelligence may progress at geometric rates
Yet socially we remain belligerent neonates
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_OBJECTeviceObject);
// 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 ( *(_DWORDi )
(*(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
*(_BYTEa1 = 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 ( !*(_DWORDv1 )
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() )
*(_BYTEa1 = 0;
return 0;
}
return -1073741823;
}
*(_BYTEa1 = 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
*(_DWORDa1 = 0;
if ( !(dword_146A4 & 1) )
{
dword_146A4 |= 1u;
sub_107E8();
sub_107A2(v1, (int)nullsub_1);
}
byte_14614 = 0;
*(_DWORDa1 = &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 = *(_DWORDa1 == 0;
*(_DWORDa3 = v4;
*(_DWORD(a3 + 4) = a2;
*(_DWORD(a3 + 8) = v4;
*(_DWORD(a3 + 12) = a2;
if ( v5 )
{
if ( *(_DWORDa3 )
{
if ( a4 )
memcpy(*(void **)a3, a4, a2);
}
else
{
*(_DWORDa1 = -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 = *(_DWORDa2 == 0;
*(_BYTEa3 = 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);
*(_DWORDa2 = v4;
*(_BYTEa3 = 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, (PVOIDv10);
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 ( *(_DWORDv2 <= 0u )
goto LABEL_8;
v10 = 0;
v9 = (charv2 + 30;
while ( stricmp((const charv2 + v10 + *(_WORD
v9 + 32, a1) )
{
v10 += 284;
v9 += 284;
++v1;
if ( v1 >= *(_DWORDv2 )
{
v1 = 0;
goto LABEL_8;
}
}
v4 = *((_DWORDv2 + 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)*(_WORDa1 + 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
*(_DWORDa1 = 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
*(_DWORDa1 = &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
*(_DWORDa1 = 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;
*(_DWORDa1 = &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
*(_DWORDa1 = 0;
if ( !(dword_1468C & 1) )
{
dword_1468C |= 1u;
sub_10FE6();
sub_107A2(v1, (int)nullsub_2);
}
byte_14617 = 0;
*(_DWORDa1 = &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, *(_DWORDv2, 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, (PVOIDv5);
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 ( *(_BYTEa1 )
{
v1 = *(PVOID **)(a1 + 4);
*(_BYTEa1 = 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);
*(_DWORDa2 = *(_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 = *(_DWORDv14;
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) )
*(_DWORDa2 = *(_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![]()
Er is een volkswijsheid die zegt dat dronken mensen de waarheid vertellen ....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![]()
Ooit weleens een aanvarinkje met ChunLingSoo gehad, denk dat ik dat even wilde laten weten ofzo
Excuses boys!
|
Forum Opties | |
---|---|
Forumhop: | |
Hop naar: |