W7x86: Immunity Debugger - Driverlib.py commando werkt niet

[sh4d0wman]

Ik heb een probleem met driverlib.py binnen Immunity Debugger. In mijn boek staat de volgende instructie welke ik probeer uit te voeren binnen mijn VM:

Try loading the driver beep.sys into Immunity Debugger. Once loaded, use the debugger’s PyShell and enter the following code:

*** Immunity Debugger Python Shell v0.1 ***
Immlib instanciated as 'imm' PyObject
READY.
>>> import driverlib
>>> driver = driverlib.Driver()
>>> driver.getDeviceNames()
['\\Device\\Beep']
>>>

Probleem: dit lukt tot en met import maar het daar op volgende commando werkt niet:

>>>driver = driverlib.Driver()
Traceback (most recent call last):
File "<console>", line 1, in <module>
File "C:\Program Files\Immunity Inc\Immunity Debugger\Libs\driverlib.py", line 35, in __init__
if not self.module.isAnalysed:
AttributeError: 'NoneType' object has no attribute 'isAnalysed'

Enig google werk geeft aan:
"NoneType means that instead of an instance of whatever Class or Object you think you're working with, you've actually got None. That usually means that an assignment or function call up above failed or returned an unexpected result."

Ik ben geen coder dus dit helpt mij niet heel veel verder. Mijn gok zou zijn dat de return-code van isAnalysed om de een of andere reden niet begrepen wordt. Zie code hieronder.

Immunity draait als admin en de error kom ik verder nergens online tegen. Ik zal dus wel iets verkeerd doen

De code welke stuk gaat op regel 35:

Python:

#!/usr/bin/env python

"""
Immunity Static Driver Analysis for Immunity Debugger

(c) Immunity, Inc. 2004-2006


U{Immunity Inc.<http://www.immunityinc.com>} Debugger Driver Library for python


"""

__VERSION__ = '1.0'

from immutils import *
from immlib   import *

import struct

class Driver:
    
    def __init__(self):
        
        # Globals
        self.imm                          = Debugger()
        self.IOCTLDispatchFunction        = None
        self.IOCTLDispatchFunctionAddress = 0x00000000
        self.IOCTLCodes                   = []
        self.IOCTLCodesLanding            = {}
        self.deviceNames                  = []
        self.module                       = self.imm.getModule( self.imm.getDebuggedName() )
        
        # Do some quick setup
        if not self.module.isAnalysed:
            self.imm.analyseCode( self.module.getCodebase() )

def getIOCTLCodes( self ):
        """
        Useful function to root out IOCTL codes from a driver. 
        This is also a big part of automating ioctlizer.

De import code welke is aangeroepen op regel 35:

Python:

def isAnalysed(self,address):
        """
            Check if module is already analysed

            @type  Address: DWORD
            @param Address: Address from module

            @rtype: DWORD
            @return: 1 if module already analysed        
            """
        ret = debugger.is_analysed(address)

        if ret == -1:
            return 0
        else:
            return ret

[sh4d0wman]

Nieuwe dag, nieuwe informatie Zie de details.

Mijn vraag zal worden bijgesteld naar:
- Hoe kan ik een driver openen in Immunity?
- Hoe kan ik automatisch IOCTL's dumpen van een driver? Dat is mijn uiteindelijke doel.
(ik kan ze al onderscheppen maar mis dan IOCTLS welke niet worden aangeroepen).
In het ergste geval kan het handmatig via IDA maar heb het liever automatisch.

Details van vandaag:

Bij het laden van de driver in Imunnity komt de volgende melding:

beep.sys Entry Point Not Found
The procedure entry point ntoskrnl.ExiAcquireFastMutex could not be located in the dll HAL.dll

Het probleem is dus niet het script maar het laden van de driver in Immunity Debugger.

Na enig speurwerk kom ik op de volgende link: http://reverseengineering...ding-a-driver-in-immunity

Echter als ik dit uitvoer werkt het nog niet.

You need to edit the IMAGE_SUBSYSTEM from IMAGE_SUBSYSTEM_NATIVE to IMAGE_SUBSYSTEM_WINDOWS_GUI or _CUI

- Open ollydbg
- Use "view -> file" to modify subsystem charecteristics to console or gui instead of native
0000012C 0300 DW 0003 ; Subsystem = IMAGE_SUBSYSTEM_WINDOWS_CUI
- Save and confirm the change:
C:\>fc /b c:\WINDOWS\system32\drivers\beep.sys c:\myollymodbeep.sys
Comparing files C:\WINDOWS\SYSTEM32\DRIVERS\beep.sys and C:\MYOLLYMODBEEP.SYS
0000012C: 01 03

C:\>"f:\odbg110\OLLYDBG.EXE" c:\myollymodbeep.sys

ollydbg will now be able to load the driver (imports from hal etc will not be resolved but you can see the correct disassembly if you do alt+e (executable window) select beep.sys right click follow entry

[Thralas]

sh4d0wman schreef op vrijdag 03 juni 2016 @ 14:07:
Ik ben geen coder dus dit helpt mij niet heel veel verder. Mijn gok zou zijn dat de return-code van isAnalysed om de een of andere reden niet begrepen wordt. Zie code hieronder.

Nee. Toch tijd om even een crash course python tussendoor te doen?

code:

AttributeError: 'NoneType' object has no attribute 'isAnalysed'

Met daarbij de desbetreffende regel:

code:

if not self.module.isAnalysed:

Ofwel, module is hier het NoneType in plaats van een geldig object. Verder debuggen op regel 32, waar module zou moeten worden geset, maar self.imm.getModule() blijkbaar None retourneert.

Maar de waarschijnlijke oorzaak had je inmiddels al gevonden...

sh4d0wman schreef op zaterdag 04 juni 2016 @ 09:55:
- Hoe kan ik een driver openen in Immunity?

Precies zoals je ieder andere executable of library laadt?

- Hoe kan ik automatisch IOCTL's dumpen van een driver? Dat is mijn uiteindelijke doel.
(ik kan ze al onderscheppen maar mis dan IOCTLS welke niet worden aangeroepen).
In het ergste geval kan het handmatig via IDA maar heb het liever automatisch.

Immunity is natuurlijk 'gewoon' een user mode debugger, dus at best kun je een statische analyse doen; laat dat nou net iets zijn waarin Olly (& co) niet echt voor bedoeld zijn.

Maar ik heb even gespiekt in je boek, blijkbaar zou dat stukje python het werk voor je doen. Als je dat niet werkend krijgt kun je overwegen het met IDAPython proberen uit te werken...

Je probleem is inherent lastig, een driver bevat immers geen metadata die je de precieze ioctl interface geeft, dus dan kun je enkel met een zo goed mogelijk heuristiek proberen op te lossen en dat is wat Immunity ook lijkt te doen.

Bij het laden van de driver in Imunnity komt de volgende melding:

[...]

Echter als ik dit uitvoer werkt het nog niet.

Wat bedoel je met werkt het nog niet?

Wat zie je wel/niet? Kan Immunity de boel wel disassemblen na de wijziging?

[sh4d0wman]

Bedankt Thralas, ik zal morgen (maandag) nog eens even verder testen met de input die je mij hebt gegeven. Update volgt...

[sh4d0wman]

Ik heb weinig ervaring met Immunity en debugging dus ik weet niet echt waar ik ben in de debugger

Hier een korte beschrijving van wat ik heb gedaan:

Als ik beep.sys open met IDA open kom ik netjes in de DriverEntry terecht en kan ik met enige pijn en moeite ontcijferen wat er ongeveer gebeurd.
Met Immunity verschijnt de melding "Entry Point Not Found, ntoskrnl.ExiAcquireFastMutex could not be located in HAL.dll", en de optie voor "pass exception". In "CPU main thread Window" zie ik een ascii string LdrpSnapIAT en rechtsonder referenties naar Hal.dll

Kies ik voor "pass exception" dan is bij elke driver dezelfde output in "CPU main thread" window. Als ik een DLL laad en naar "CPU main" kijk dan snap ik de code enigzins en is deze per DLL verschillend.

Alt + E geeft geen modules weer alleen een zwart scherm. Hier is dus geen beep.sys te zien, de wijziging met LordPE maakt geen verschil (de url uit mijn start post).
Als ik een normale DLL in laad en ALT+E dan staat hier o.a. loaddll.exe in en diverse DLLs.

Als ik in main thread kies voor "search for all referenced text strings" dan is deze strings lijst uniek per DLL zoals verwacht. Echter bij het laden van een driver komen dezelfde strings. Hier zijn dus geen references naar beep te vinden.

Indien ik hal.dll in de debugger open krijg ik dezelfde foutmelding (Entry Point Not Found) maar na pass exception is Executable Modules gevuld en zie ik dezelfde strings als in de driver. Dus openen van een driver lijkt in hal.dll te eindingen.

Ik heb een voorbeeld gevonden van dynamic analysis waar men attached aan de userland executable en vanaf daar vanuit modules de driver [naam.sys] inladen, daarvan valt de assembly enigzins te volgen voor mij. Statische voorbeelden kan ik nergens vinden maar wel meer klachten over het boek hehe.

Hopelijk was hier iets van te maken. Anders blijf ik eerst maar even bij fuzzen en wanneer ik weer meer heb geleerd onderneem ik een poging met IDA en scripting.

[Rupie]

Op verzoek van de TS verplaatst naar BV