Search the Community

Salutari! Mi-am cumparat acest laptop ( HP Notebook - 15-r214ng (ENERGY STAR) Troubleshooting | HP® Support ) din germania cu win8.1 Nu imi place windows 8.1 asa ca am instalat win 7 ultimate oem hp 86biti si nu reusesc sa gasesc niciun driver care sa fie compatil cu win7. Driverele de pe site oficial imi eroare, zice ca nu sunt compatile cu OS. O rezolvare sau o idee. Multumesc.

XP is a little more complicated than newer systems due to the use of a single driver for both port and miniport; however, getting the original pointers is fairly straight forward depending on how you do it. IRP_MJ_SCSI & DriverStartIo - Method 1 (Windows XP) A common method is to programmatically disassemble the miniport's DriverEntry, looking for the code which initializes the driver's object, then you can extract and calculate the addresses from "mov [esi+30h], offset" and "mov [esi+74h], offset" for DriverStartIo and IRP_MJ_SCSI respectively. The obvious problem with this method is the initialization code may not be in DriverEntry, but a sub function called from it (it may even be necessary to follow jumps). It's also not guaranteed that the instruction will use esi as the pointer to the driver object or an immediate for the function address, in fact you're probably going to have to account for quite a few different instructions. IRP_MJ_SCSI & DriverStartIo - Method 2 (Windows XP) In my tests, it was possible to simply call the DriverEntry of the miniport driver with the parameters from your own driver entry, thus having the miniport set up your driver's object as if it were its own. The only issue with this method is if the driver uses GsDriverEntry (it usually does), the entry point will be invalidated after the driver is initialized, so you cannot call it. To deal with GsDriverEntry you'd first need to load the original image from disk, then search until you reach an unconditional relative jump (this is the offset to real entry point and you can use it to calculate the same address within the loaded driver). IRP_MJ_SCSI (Windows Vista+) On newer systems, things are wonderfully easier: There's no DriverStartIo field and you can initialize all the major functions in your DriverObject with a call to AtaPortInitialize, ScsiPortInitialize, or StorPortInitialize which are all exported from the relevant port drivers (ataport.sys, scsiport.sys, or storport.sys). Bypassing Inline Hooks Although not many bootkits actually perform inline hooking on miniports, it's worth taking care of. You'll need to read a the original miniport or port driver's file into memory, then do a bit of pointer math to calculate the addresses of IRP_MJ_SCSI or DriverStartIo within the clean image. I'm not too sure of the best way to call the clean functions, but here are 2 viable methods to chose from. Trampoline Usually a hook is placed within the first few bytes of a function, so you can simply read and relocate the first few bytes from the clean function into a buffer, then append it with a jump to the same offset within the real driver(this is the same way a hooking engine would call the unhooked version of a function). Manual Mapping A more difficult but effective method is to manually map a clean copy of the driver into memory, then relocate it so that all absolute instructions will reference the real driver, meaning you don't have to worry about initializing any global variables or such. Creating a Clean Call Path Due to the fact a lot of bootkits run persistence threads for replacing any driver object hooks which get removed, you don't want to unhook the real driver but instead create a parallel one, so you can maintain your own hook-free call path. Step 1 (XP & Vista) Get the device object for the boot disk miniport, this is usually \Device\Harddisk0\Dr0 Use the size field of the device object to allocate some non paged memory and copy the entire object (this is your clean miniport). Set the DriverObject field to point to your own driver's object, in which you've set the IRP_MJ_SCSI and DriverStartIo field appropriately (DriverStartIo can be skipped on Vista+). Step 2 (XP Only) Set the DeviceExtension field of your clean miniport device object to point to directly after its device object (DeviceObject + sizeof(DEVICE_OBJECT)). Get the address stored at offset 0x5C into your clean miniport's device extension and check it's valid (this is the address of the corresponding port's device extension). Read the addresses stored at offset 0x0C into the port's device extension (this is the address of the port's device object). Use the size field of the port's device object to allocate some non paged memory and copy the entire object (this is your clean port). Set the DeviceExtension field of your clean port's device object to point to directly after its device object (DeviceObject + sizeof(DEVICE_OBJECT)). Set the DriverObject field of your clean port's device object to point to your own driver's object, in which you've set the IRP_MJ_SCSI field appropriately. Change offset 0x5C into your clean miniport's device extension to contain the address of the clean port's device extension. Set offset 0x0C into the clean port's device extension to contain the address of the clean port's device object. Using the Clean Path You're going to need to build a raw SCSI request which is pretty complicated; however, the Chinese are already a step ahead, so you can look to this example for help (This request can be issued by passing the clean miniport device object and the IRP to IofCallDriver). It's important to note that miniport drivers are PnP, so if you don't create any devices (IoCreateDevice): the driver will be unloaded as soon as DriverEntry returns, if you do: the driver can't be unloaded at all. Although it's not recommended, you can set the driver back to a legacy driver by setting the AddDevice pointer within the driver's extension to 0, allowing the driver to be unloaded normally. Conclusion This concludes my 3 part series, any feedback in the comments would be greatly appreciated and will be taken into consideration when I create a whitepaper version of the series in a few weeks. Other resources of note Debugging TDL4 Subverting Bootkits using the Crash Dump Driver Stack Exposing Bootkits With BIOS Emulation Source

Part 1 .: https://rstforums.com/forum/98013-bootkit-disk-forensics-1-a.rst As I explained in the previous article: DriverStartIo is used by older miniports to actually perform the disk I/O, it takes 2 parameters (a device object and an IRP), exactly the same as IoCallDriver does. The call to DriverStartIo is done with IoStartPacket; however, the device object passed is not that of the miniport, but instead a device associated with the port the target disk is connected to (in my case IdePort1). IRP_MJ_SCSI points to IdePortDispatch in atapi.sys, by disassembling it we can see exactly how the required device object is retrieved from the DeviceExtension field of the miniport's device object. The call logic is something like this: Get the miniport's device extension from its device object (passed to us in the call). Get IdePort1's device extension from offset 0x5C into the miniport's device extension. Get IdePort1's device object from offset 0x0C into its device extension. Call IoStartPacket with the IRP and IdePort1's device object. As both the miniport and IdePort devices are created by atapi.sys, the DriverObject field of both devices' objects point to the same driver object; thus, hooking DriverStartIo is as simple as replacing the address in the driver's object. Detecting DriverStartIo hook with WinDbg For basic DriverStartIo hook detection we can simply follow the same process as for major function hooks: First, we find the boot disk and list it's stack. As I explained in the previous article, modifications made by TDL4 will cause the !drvobj and !devobj commands to think the object is invalid, it's not. You will probably want to check each driver object in the stack (for the invalid DeviceObject you can again use "dt _DEVICE_OBJECT <address>" to find the DriverObject field). With most bootkits, the lowest level driver is always the one hooked, so I'll use this in my example. You can see here that DriverStartIo isn't hooked because the address resolve to its proper symbol; however, this isn't actually the real driver object. Earlier i explained that IoStartPacket is always called with the device object of IdePort1, not the disk miniport: This means that when IoStartPacket called DriverStartIo internally, it does so by getting the driver object from the DriverObject field of IdePort1's device object, then getting the DriverStartIo field from that. Obviously this means that to hook DriverStartIo, one could simply just create a copy of atapi's driver object, with the DriverStartIo field modified, then set the DriverObject field of IdePort1's device object to point to the new, malicious driver object (this way on IdePort1 will point to the hooked driver, the rest will point to the original). As it happens TDL4 actually does the opposite, it hooks the real atapi driver object, then replaces the DriverObject field of the disk miniport's device object with the address of an identical driver object, without the DriverStartIo field modified.). If you know what you're looking for, fake driver objects are easy to detect. All devices created by a driver should point the same driver object, so simply enumerating the devices created by the miniport's driver then making sure all the DriverObject fields point to the same address is all that's needed. This can be done a multitude of ways. Method 1: DrvObj The fake driver object will have the same name as the real one (in my case "\driver\atapi"), all you need to do is type "!drvobj \driver\atapi 2" to get the real driver's object (this is a downside of TDL4 hooking the real driver object instead of a spoofed one). Method 2: NextDevice Starting with the miniport device, enumerate devices using "dt _DEVICE_OBJECT <address>" and the NextDevice field of each device's object. We're looking for any DriverObject field that dosen't match that of the miniport (this is the real driver object). Method 3: DeviceExtension This is the least reliable way, as the device extension could change from system to system, but as I mentioned earlier: you can find IdePort1's device extension at offset 0x5C isn't the miniport's device extension, then from IdePort1's device extension you can find its device object at offset 0x0C (IdePort1's device object will point to the real driver object). We can actually find the DeviceObject in a single commands using this overly complicated WinDbg-C++ syntax: "dt _DEVICE_OBJECT poi(poi(@@C++(((nt!_DEVICE_OBJECT *)<address>)->DeviceExtension)+0x5C)+0x0C)", where "<address>" is the miniport device object. Source

Recently I got the idea to play around with bypassing bootkit disk filters from an email i received, which highlighted that my MBR spoofing code was able to get underneath the driver of a popular forensics tool, preventing it from reading the real disk sectors. Although I believe disk forensics should not be done on a live system, instead the disk should be mounted on a clean system and examined from there, I thought it would be fun to write a tool for bypassing various bootkit drivers and then post my research. Another email I received requested that I show how one would detect the presence of such filters from WinDbg, So I will try to cover both. Disk Filtering - Old and New Driver Module As I've shown in a previous article, disk filtering is usually done by hooking the IRP_MJ_SCSI field of the miniport driver's object. Another common method is hooking DriverStartIo; however, this field is only used in the old-style driver model and is set to NULL on most Vista+ systems. The drivers used depend on whether you use SCSI or ATA based hardware, but because all drivers follow the same model, I will simply use an ATA system in my examples. Old Driver Model Pre-Vista disk drivers would have a single ATA channel driver known as atapi.sys, which would provide the functionality of both a port and miniport. If a disk required a custom miniport, the vendor would have to write their own miniport + port driver, which is no small task. When a device receives a request such as IRP_MJ_SCSI, it queues it to the disk via IoStartPacket, which eventually calls the address held by the DriverStartIo field of the driver's object; thus hooking DriverStartIo would intercept any disk I/O requests, not just IRP_MJ_SCSI. New Driver Model The new driver model provides a Microsoft supplied port driver (ataport.sys) and miniport driver (atapi.sys), which work together to make up the channel interface. The port driver provides basic functionality, whilst the miniport provides hardware specific functionality; so, if a vendor needs a custom miniport driver, they could simply write their own miniport to interface with the Microsoft supplied port driver. With the new model the IRP_MJ_SCSI field of atapi's driver object points to a function within ataport.sys (IdePortDispatch), which handles and queues requests using an internal mechanism instead of IoStartPacket, meaning bootkits hooking only IRP_MJ_SCSI and DriverStartIo can be bypassed using passthrough operations (even from usermode). TDL Warning Although TDL is no longer active, I should mention that it hijacks kdcom.dll (the COM debugger extension) in such a way that it prevents it from starting. If you attempt to enable kernel debugging via COM on a TDL infected system, it will be completely bricked following reboot (even safemode won't load). Detecting Major Function Hooks with WinDbg First things first you need to find which disk is your boot disk (it's up you you how you do this), but in most cases it will be \Device\Harddisk0\DR0. Once you've made sure WinDbg has the correct symbols loaded, use !devstack to display the device stack and find the bottom most device (the miniport). Here is a normal output: In the case of some TDL4 infections, the miniport driver object (\driver\atapi) will appear to be invalid (it's not), but it prevents the !devobj and !drvobj commands from working, so we'll have to get the driver object associated with the miniport by using dt _DEVICE_OBJECT on the lowest device's object. Now we can examine the driver object (specifically the dispatch table) for major function pointer hooks. On a clean system all the dispatch routines should have addresses which resolve to symbols in either the miniport, port or ntoskrnl. On TDL4 infected systems the !drvobj command won't work, so you'll have to use dds (iv'e shown how to use both below). Major functions on a clean system shown with !drvobj Major functions on a clean system shown with dds On an infected system (TDL4) we will see something similar to the below. ote: all the dispatch routines point to the same address, which resides in pool memory (not normal). In an attempt to trick av tools, Rovnix redirects the pointers to jumps it wrote to unused space at the end of atapi.sys, hence the addresses don't resolve to a function, only a module. If the driver dispatch table appears to be clean, the next thing to do is disassemble the address pointed to by IRP_MJ_SCSI (IRP_MJ_INTERNAL_DEVICE_CONTROL), as this is the dispatch routine which handles disk read/write requests and could be inline hooked. In my case IRP_MJ_SCSI points to ataport!IdePortDispatch. A example of a clean IRP_MJ_SCSI handler It may be difficult to detect inline hooks, especially if existing jump/calls are modified. One should compare the module in memory against its disk image, accounting for relocation and imports (the best way to do this would be to have a driver map the disk image into memory and relocate it to point to the original module, allowing you to simply compare the two). Coming Soon Part 2: Detecting DriverStartIo hooks and driver object spoofing. Source

I receive crash dumps containing pirated antiviruses all the time, however I felt the need to blog about it for once because it's actually so often and just comical to me at this point. I also haven't blogged in a little while. I'm not really here to discuss the pros & cons of antivirus software, it's obvious. What I will say however is it's also obvious that for any software you install regardless of its intended job, you're increasing your attack surface. Given the fact that most antiviruses are granted complete come/go access to the kernel, have the highest privileges, have various kernel-mode drivers, etc, your surface is increased just that much more. Let's take a look at this crash dump (unfortunately only a Small Memory dump...): 2: kd> .bugcheck Bugcheck code 00000024 Arguments 00000000`001904fb fffff880`085866a8 fffff880`08585f00 fffff880`016b1d82 Right, so we have our bug check - NTFS_FILE_SYSTEM (0x24). Big hint, if you see this bug check on a crash dump from a user, chances are it's 50/60% (or more) the fault of either the one security application they have installed (whatever the actual problem with the application is), or user error as far as installing more than one security applications go. It's generally a bad idea to pigeonhole a bug check with a single problem (because it's ridiculous to do so), but I'd personally say over the years 0x24 has been much more of a security software issue than anything else. 2: kd> .exr fffff880`085866a8 ExceptionAddress: fffff880016b1d82 (Ntfs!NtfsRemoveHashEntry+0x00000000000000c2) ExceptionCode: c0000005 (Access violation) ExceptionFlags: 00000000 NumberParameters: 2 Parameter[0]: 0000000000000000 Parameter[1]: ffffffffffffffff Attempt to read from address ffffffffffffffff By taking a look at the exception record structure, we can see the direct reason for the exception being thrown that caused the actual crash was an access violation occurring in Ntfs!NtfsRemoveHashEntry. Now that we know why, let's take a look at the context record using the address from our 3rd parameter in the .bugcheck output. 2: kd> .cxr fffff880`08585f00 rax=0000000000000000 rbx=fffff8a00224e050 rcx=0001000000000000 rdx=0000000000000000 rsi=000000001fdefdd9 rdi=fffffa80049be358 rip=fffff880016b1d82 rsp=fffff880085868e0 rbp=00000000000001d9 r8=00000000000003b2 r9=0000000000000000 r10=00000000000003b2 r11=fffff88008586910 r12=0000000000000001 r13=0000000000000000 r14=0000000000000001 r15=fffff8a003533ed0 iopl=0 nv up ei pl nz na po nc cs=0010 ss=0018 ds=002b es=002b fs=0053 gs=002b efl=00010206 Ntfs!NtfsRemoveHashEntry+0xc2: fffff880`016b1d82 397110 cmp dword ptr [rcx+10h],esi ds:002b:00010000`00000010=???????? On the instruction regarding Ntfs!NtfsRemoveHashEntry, we can see it was comparing the esi register to the memory at address rcx+10. rcx looks pretty bogus, and just to confirm: 2: kd> !pte 0001000000000000 // Or !pte rcx VA 0001000000000000 PXE at FFFFF6FB7DBED000 PPE at FFFFF6FB7DA00000 PDE at FFFFF6FB40000000 PTE at FFFFF68000000000 Unable to get PXE FFFFF6FB7DBED000 WARNING: noncanonical VA, accesses will fault ! So here's the reason why the exception was thrown, it was noncanonical. Now that we've also instructed the debugger to use the context record as the register context, we can run a k(b,nL,whatever) to get a more detailed stack in our case - even with a Small Memory dump: 2: kd> k *** Stack trace for last set context - .thread/.cxr resets it Child-SP RetAddr Call Site fffff880`085868e0 fffff880`016b224f Ntfs!NtfsRemoveHashEntry+0xc2 fffff880`08586970 fffff880`016b0a24 Ntfs!NtfsDeleteNormalizedName+0x7f fffff880`085869a0 fffff880`016b4cdb Ntfs!NtfsDeleteScb+0x1f4 fffff880`085869e0 fffff880`0162e343 Ntfs!NtfsRemoveScb+0x5b fffff880`08586a20 fffff880`016b2a3c Ntfs!NtfsPrepareFcbForRemoval+0x53 fffff880`08586a50 fffff880`01635a52 Ntfs!NtfsTeardownStructures+0xdc fffff880`08586ad0 fffff880`016c22d3 Ntfs!NtfsDecrementCloseCounts+0xa2 fffff880`08586b10 fffff880`01714d32 Ntfs!NtfsCommonClose+0x353 fffff880`08586be0 fffff800`02ae1561 Ntfs!NtfsFspCloseInternal+0x186 fffff880`08586cb0 fffff800`02d740ca nt!ExpWorkerThread+0x111 fffff880`08586d40 fffff800`02ac8be6 nt!PspSystemThreadStartup+0x5a fffff880`08586d80 00000000`00000000 nt!KxStartSystemThread+0x16 Not going to put comments, but rather just talk about it. We were starting a system thread which turned out to be a worker thread (as we can see from the ExpWorkerThread function), and from then on go throughout various NT file system calls. Given the fact that it's a worker thread dealing with NTFS tells us we're likely dealing with a driver requiring delayed processing, etc. As we're going through various NTFS calls, we can see we're preparing the File Control Block (FCB) and Stream Control Block (SCB) for removal and deletion. This also tells us if anything, it's a driver working actively with/for the file system. Looking at the loaded modules list for any drivers actively working with the file system, what do we find? Hint: A lot of Symantec/Norton kernel-mode drivers 2: kd> lmvm SRTSP64 start end module name fffff880`082d4000 fffff880`08394000 SRTSP64 (deferred) Image path: SRTSP64.SYS Image name: SRTSP64.SYS Timestamp: Tue Mar 29 22:46:12 2011 Here is Symantec's x64 Real Time Storage Protection (SRTSP) driver. This driver is used by Symantec's Auto-Protect feature, which is what scans files under various conditions. You can expect to find this kernel-mode driver on any system with NIS installed, so what's the big deal? The timestamp/date on the driver itself is from March 29th 2011. The time of the bug check is: Debug session time: Tue Feb 3 23:57:58.466 2015 (UTC - 5:00) Okay, so we have a kernel-mode driver from/for Norton that's approximately as of this blog post 3.8 years old. That's.... bad. To give the user the absolute ultimate benefit of the doubt, I for a split-second thought that perhaps maybe Symantec really has a kernel-mode driver regarding RTP that's 3.8 years old. Surely there may be hundreds of vulnerabilities, but it's possible.. right? Wrong. 2: kd> vertarget Windows 7 Kernel Version 7601 (Service Pack 1) MP (4 procs) Free x64 Product: WinNt, suite: TerminalServer SingleUserTS Personal Built by: 7601.18700.amd64fre.win7sp1_gdr.141211-1742 It's a Windows 7 x64 system, so let's create a test environment really quick and install the latest trial version of NIS. Ah, that's much better. Unfortunately, that wasn't the only out of date kernel-mode driver regarding Symantec loaded on this particular system. Let's keep comparing: 2: kd> lmvm SYMDS64 start end module name fffff880`01279000 fffff880`012ea000 SYMDS64 (deferred) Image path: SYMDS64.SYS Image name: SYMDS64.SYS Timestamp: Tue Dec 07 19:16:58 2010 Symantec's x64 Data Store (SymDS) driver. 2: kd> lmvm SYMEFA64 start end module name fffff880`014f4000 fffff880`015d8000 SYMEFA64 (deferred) Image path: SYMEFA64.SYS Image name: SYMEFA64.SYS Timestamp: Sun Mar 13 23:20:58 2011 Symantec's x64 Extended File Attributes driver. 2: kd> lmvm SYMEVENT64x86 start end module name fffff880`01dbf000 fffff880`01df5000 SYMEVENT64x86 (deferred) Image path: SYMEVENT64x86.SYS Image name: SYMEVENT64x86.SYS Timestamp: Thu Mar 24 19:02:36 2011 Symantec's x64 SymEvent driver. 2: kd> lmvm SRTSPX64 start end module name fffff880`01c2d000 fffff880`01c43000 SRTSPX64 (deferred) Image path: SRTSPX64.SYS Image name: SRTSPX64.SYS Timestamp: Tue Mar 29 22:46:18 2011 Symantec's x64 Real Time Storage Protection (SRTSP - PEL) driver. 2: kd> lmvm SYMNETS start end module name fffff880`01d58000 fffff880`01dbf000 SYMNETS (deferred) Image path: SYMNETS.SYS Image name: SYMNETS.SYS Timestamp: Tue Apr 19 18:33:31 2011 Symantec's Network Security WFP driver. Overall, we can see that all of these Symantec/Norton kernel-mode drivers are not their latest versions. Given the fact that the user's system bug checked Feb 2015 and many of its kernel-mode drivers are 3.8 years (or older) old, we know it's pirated. Remove pirated Norton, crashes stop. Surprise surprise. Moral of the story: If you really are going to pirate an antivirus, be sure it's actually as up to date as it would be if you paid for it. If you're running an antivirus with kernel-mode drivers from 3.8> years old, the amount of vulnerabilities you're vulnerable to that were patched years ago is pretty high. You're also opening yourself up to becoming infected with old malware that was invalidated if not further developed if it relied on certain EOP (or other) exploits to get around active protection. Also, as you can see here, chances are you'll bug check considering you're also subject to ~3.8> year old driver bugs that have since been patched. You could alternatively just buy the antivirus. Crazy, I know. source

Product Description Updating drivers is usually an initial step to avoid hardware failure, system instability and hidden security vulnerabilities. To update drivers regularly is also an effective way to enhance your overall PC performance, and maximize your gaming experience. While this process could be risky and frustrating if done manually, Driver Booster PRO is introduced to download and update drivers for you automatically with just one click. Based on cloud library, Driver Booster PRO can always be the first to identify outdated drivers, and download and update driver at an unrivaled speed. With the backup feature, it is an easy, effective and risk free solution to keep your drivers up-to-date Automatically Identify Outdated Drivers Download and Update Outdated Drivers with One Click Fast Driver Download and Update Speed Specialized Driver Tweaking for Top Gaming Experience Support More Comprehensive Hardware Devices Enjoy Priority to Update Outdated Drivers Promptly Backup Drivers for Safe Restore Enhance Hardware Functionality for Top Performance Automatically Update to the Latest Version. -> Download <- Deal Expires in: EXPIRED!

Te-ai s?turat dup? ce instalezi un sistem de operare Windows (7, Vista, XP) s? stai s? cau?i fiecare driver? Driver Pack solution este exact ceea ce ai nevoie. Îl rulezi imediat dup? prima bootare, selectezi driverele care vrei s? le instalezi ?i gata. F?r? stres, f?r? ore pierdute... Download: http://drp.su/download.htm ?tiu c? sun? de parc? fac publicitate. Primul post, ave?i mil?.