Jump to content

Manko
 Share

Recommended Posts

@trancexx: Thanks for the vote of confidence, but I don't have the slightest idea how to work with bios/cmos. I saw some 16-bit code and some explanations that was WAY above my level... (Hurt my brains...) Also... Your thought for wraithdus dllcalls... My code is full of such things... (Not proud!) And ascendants recent discovery is likely due to such shortcuts... Or something worse... :)

@wraithdu: Thanks for the update! I will use it! ;P

@ascendant: Hey, man! Nice to see you! And MANY thanks for reporting an error! A rare occurance... Moore please!

...but you misunderstand, the sanitation part is getting rid of all my crappy and potentially dangerous code... ;)

It's most likely the arrayghost.... Can you give me info for duplicating the issue or can you run code through scite and give me error?

About detecting crashed app.... It's only Prodller itself that checks if it's deadlocked, when you use "Suspend all", so you won't end up with the whole computer frozen....

I'm glad your research/development is progressing! :)

/Manko [EDIT: Must show gratitude! Reporting errors rarely happen!]

Edited by Manko
Yes i rush things! (I sorta do small bursts inbetween doing nothing.) Things I have rushed and reRushed:* ProDLLer - Process manager - Unload viri modules (dll) and moore...* _WinAPI_ProcessListOWNER_WTS() - Get Processes owner list...* _WinAPI_GetCommandLineFromPID() - Get commandline of target process...* _WinAPI_ThreadsnProcesses() Much info if expanded - optional Indented "Parent/Child"-style Processlist. Moore to come... eventually...
Link to comment
Share on other sites

@trancexx: Thanks for the vote of confidence, but I don't have the slightest idea how to work with bios/cmos. I saw some 16-bit code and some explanations that was WAY above my level... (Hurt my brains...) Also... Your thought for wraithdus dllcalls... My code is full of such things... (Not proud!) And ascendants recent discovery is likely due to such shortcuts... Or something worse... :)

...

That's ok, I know how to work with cmos.

That 16 bit code that you mention is not what's important (it even almost makes no sense saying it's 16 bit code). What's important is that code is run through virtual dos machine where there is no distinction between kernel and user mode. That's why it's working. It's the same code but compiled to .com (not .exe).

And if you run it as it would normaly be run on 32 bit systems it would cause crash because it's not allowed from where you are (user mode). Privileged instruction is attempted and signaled in that case and application terminated.

My question was how to go around that without the driver used for that purposes.

About DllCall()... @error check must follow every DllCall() function because of returned array. That's the law. Otherwise you are risking unwanted termination every time you try to access that array.

Link to comment
Share on other sites

  • 5 months later...
  • 2 months later...
  • 3 months later...

New Version!

"Force Terminate!" is finalized.

Terminate with extreme prejudice!

Check out the other cool features too!

Most Recent changes...
; 0.494
; Change: Skipped fileinstall of driver. Some anti-virus reported it as suspicious behaviour... sigh...
; Change: Finally converted to 3.3.6.1. Had to change 3 things...
; Added: Kernel function for iterating threads. "Force Terminate!" is finalized.
; Fixed: Small bugfix...
; 0.493
; Added: More info on systemthreads.
; Added: "Force Terminate!" system threads!
; Added: Stop new procs from running! New processes are terminated before they have a chance to run any code.
; Added: Partial implementation of "kernel notification callbacks"-viewing/disabling... not all... yet... and only xp, now...
; Added: Set KernelService-starttype to "System" or "Boot" also.
; Change: "Ensure new processes visible" was VERY irritating, stopped it.
; Added: View Service-dependencies... Good for deciding if services are critical...
; Fixed: "Thread-list" - Choosing List Modules in context menu, did nothing... Now works for dlls... Maybe fix others?
; Fixed: Speedup of driver itteration, would crash in some cases. Redundancy of checking established.
; Fixed: Fix some functions forcing us out of "suspendall".
Yes i rush things! (I sorta do small bursts inbetween doing nothing.) Things I have rushed and reRushed:* ProDLLer - Process manager - Unload viri modules (dll) and moore...* _WinAPI_ProcessListOWNER_WTS() - Get Processes owner list...* _WinAPI_GetCommandLineFromPID() - Get commandline of target process...* _WinAPI_ThreadsnProcesses() Much info if expanded - optional Indented "Parent/Child"-style Processlist. Moore to come... eventually...
Link to comment
Share on other sites

Hey man, good to see you're still developing this nice system utility. Looks pretty nice.

Only, there's a little bug on my system.. When I click the 'Threads' button, the right listview panel begins to populate but freezes partway into it. I'm running it on Windows XP+SP3, tried running both the executable and the AutoIT script separately - both with the same deadlock. I have to End-Task the thing unfortunately.

By the way - when are you gonna put 'tip' text on the Buttons (GUICtrlSetTip)? I still don't touch most because I haven't the slightest idea of what will happen if I click them :mellow:

Link to comment
Share on other sites

So... we meet again. Will you be shooting me soon?

Go figures you'd find a bug I can't readily reproduce?! Again! :P

I do XPsp3 too... And it works here...

Are you using any funky security apps that might be interfering?

If so I could install and see...

Does it atleast get past the systemthreads?

Well you are right again... I should do tips... No knowing which button blows up your puter otherwise. :mellow:

/Manko

Edited by Manko
Yes i rush things! (I sorta do small bursts inbetween doing nothing.) Things I have rushed and reRushed:* ProDLLer - Process manager - Unload viri modules (dll) and moore...* _WinAPI_ProcessListOWNER_WTS() - Get Processes owner list...* _WinAPI_GetCommandLineFromPID() - Get commandline of target process...* _WinAPI_ThreadsnProcesses() Much info if expanded - optional Indented "Parent/Child"-style Processlist. Moore to come... eventually...
Link to comment
Share on other sites

Okay, I tracked down the issue. It has to do with this function call:

$mlret = DllCall($hDll, "str*", "GetModuleNameFromAddress", "int", $threads[$i][1], "int", $threads[$i][4])

It *only* locks up when the Process ID # for the process 'CTxfispi.exe' is reached. This appears to be an audio driver for my SB X-FI PCI-Express sound card.

When I put in a test for the Process ID, and avoided the function call for that specific process, everything else populated correctly.

Link to comment
Share on other sites

New Version!

G'day Manko

Love the program it's helped me out many many times when I'm hunting for virus on computers.

I'm getting an error with this version though. :P

It keeps giveing me

" Could not aquire DRIVER handle! "

BTW Can I suggest you make this a "msgbox" as the first few times I missed it as I was doign other things. Also it's a critical error that stops the program so deserves something better than a tool tip. :mellow:

The same error orrcurs if I run your precompiled version, one I've compiled or from SciTE.

I did do a little error checking but I have no idea what to look at in this area.

$test1 = My_Service_Create("skeleton", "Skeleton Driver", @ScriptDir & "\skeleton.sys", $SERVICE_KERNEL_DRIVER, $SERVICE_DEMAND_START, $SERVICE_ERROR_IGNORE, 0)
$test2 = _Service_Start("skeleton")
MsgBox(0,"Start Service", "Test1 = " & $test1 & @CR & "Test2 = " & $test2)
$hColdBoot = DllCall("kernel32.dll", "int", "CreateFile", "str", "\\.\skeleton", "dword", 0xc0000000, _
        "dword", 0, "dword", 0, "dword", 3, "dword", 0, "dword", 0)
If $hColdBoot[0] < 1 Then
    ToolTip(@LF & "   Could not aquire DRIVER handle!   " & @LF)
    Sleep(3000)
    Exit
Else
    $hColdBoot = $hColdBoot[0]
EndIf

The Msgbox returns

Test1 = 1

Test2 = 0

Not sure if that helps.

Any ideas or things you can suggest I check.

Thanks

Link to comment
Share on other sites

Ascend4nt: Wow! Yet again you come to the rescue! I'll check into it. I'll download and see if I can check. Otherwise I'll beg for a copy... :mellow:

storme: I had to skip fileinstalling the "skeleton.sys"-driver cause some anti-virus complained of suspicious behaviour.

Now you have to manually copy all files to the same dir. Especially the .exe, .dll and .sys has to be in same dir even though it's compiled.

Still got problems?

And yes, I will make them msgboxes again. I changed all msgboxes because they don't work if one suspends certain procs...

...but as these notifications occur before that scenario, it should not be a problem.

Thanks!

/Manko

Yes i rush things! (I sorta do small bursts inbetween doing nothing.) Things I have rushed and reRushed:* ProDLLer - Process manager - Unload viri modules (dll) and moore...* _WinAPI_ProcessListOWNER_WTS() - Get Processes owner list...* _WinAPI_GetCommandLineFromPID() - Get commandline of target process...* _WinAPI_ThreadsnProcesses() Much info if expanded - optional Indented "Parent/Child"-style Processlist. Moore to come... eventually...
Link to comment
Share on other sites

storme: I had to skip fileinstalling the "skeleton.sys"-driver cause some anti-virus complained of suspicious behaviour.

Now you have to manually copy all files to the same dir. Especially the .exe, .dll and .sys has to be in same dir even though it's compiled.

Still got problems?

Yep saw the comment about that. It is a shame. :party:

All I did to start with was extract the files from your zip file and click the EXE file.

I.E. everything that you supplied was there in the one directory. :party:

Actually becauce I don't trust EXE files I used your source first then when it didn't work I tried the pre-compiled version. :mellow:

I also tried it from my laptop and it gives the same error.

And yes, I will make them msgboxes again. I changed all msgboxes because they don't work if one suspends certain procs...

...but as these notifications occur before that scenario, it should not be a problem.

I understand. :P Edited by storme
Link to comment
Share on other sites

@storme:I think I might have fixed tghe issue you reported. Try it! (As a sideeffect it seems you can run multiple copies of ProDLLer now. Don't know if that is good...)

Also I have changed to Messageboxes. :mellow:

@Ascend4nt:I have done tooltips for the buttons now. Hope you'all won't be afraid to test them now! :P

I have been unsuccessful at repeating your problem as of yet. Though I have tried 6 copies of the file you mentioned...

/Manko

; 0.494
; Fixed: Skeleton service not loading properly under unknown circumstances... Reported by storme. Fixed?
; Added: Tooltips for buttons. Hope it enboldens users. There is no selfdestruct... almost... Muahhahahaha!
Edited by Manko
Yes i rush things! (I sorta do small bursts inbetween doing nothing.) Things I have rushed and reRushed:* ProDLLer - Process manager - Unload viri modules (dll) and moore...* _WinAPI_ProcessListOWNER_WTS() - Get Processes owner list...* _WinAPI_GetCommandLineFromPID() - Get commandline of target process...* _WinAPI_ThreadsnProcesses() Much info if expanded - optional Indented "Parent/Child"-style Processlist. Moore to come... eventually...
Link to comment
Share on other sites

I made dll and all but the skeleton of the driver myself, yes, in assembler, and that is the problem... the assembler i use does not support 64-bit. There is a 64-bit version of masm, but there are problems...

Hmm... You're not even supposed to be able to run it in 64-bit...

@trancexx: I'm sorry. That day is sadly far off right now...

/Manko

Yes i rush things! (I sorta do small bursts inbetween doing nothing.) Things I have rushed and reRushed:* ProDLLer - Process manager - Unload viri modules (dll) and moore...* _WinAPI_ProcessListOWNER_WTS() - Get Processes owner list...* _WinAPI_GetCommandLineFromPID() - Get commandline of target process...* _WinAPI_ThreadsnProcesses() Much info if expanded - optional Indented "Parent/Child"-style Processlist. Moore to come... eventually...
Link to comment
Share on other sites

Manko, thanks for those much-needed tooltips :mellow:

Hopefully the driver I directed your way will help.. though I don't know how you could actually test it effectively without loading it into memory. Or are you able to load it? (I figured it wouldn't load without the actual soundcard present).

If you still can't find the issue on you're own, you're gonna have to give me some sort of debug output version of the DLL (at least for that function) so we could see where things are going.

I just did a test myself on the driver with my NTQuery experimental module, and was able to read most everything I've been experimenting with, except I was unable to get TEB/TIB basic info for 22 of 27 threads (even with SEDEBUG privilege).

Things I tested successfully: Traversing through memory using VirtualQueryEx to find DLL/EXE load locations, Reading and interpreting PEB, LDR_DATA, MODULE_INFO_NODE's and other minor misc data.

Link to comment
Share on other sites

Well, Manko.. turns out the problem had to do with a deadlocked/crashed driver!! I rebooted my machine and re-ran ProDLLer, and it worked flawlessly this time.

I'm also able to get info on all the threads now through NtQuery* functions. (I suppose there may have been a few threads still working when it crashed?)

Anyhow, I reproduced the problem and the issue arose again. As odd as it sounds, TrueCrypt crashes the audio driver when I dismount a drive. Its weird because all the programs that rely on audio run flawlessly even afterwards.

So, the only real 'problem' with ProDLLer is that it somehow does something in that DLL that tries to access a hung/crashed executable. I've seen this problem before, if you recall, with my Full-Screen Crash Recovery program. (I had to figure out which functions and operations were safe to perform on a hung application.)

Since I was still able to get all the information about modules, heaps, and other stuff from the process memory, I'm guessing the issue might have to do with the (crashed) threads (the ones that weren't reporting back basic info (0) when I used 'NtQueryInformationThread'). I'm not sure if you use something similar in your DLL, but whatever you are using, you might need to either add error checking (not that I'd ever accuse you of not using such things :mellow:), or somehow check for problem threads..?

*oh, and another thing - I couldn't terminate the darn audio driver either, through task manager, with ProDLLer, or 'DTaskManager'. A reboot worked though *shrug*

Edited by Ascend4nt
Link to comment
Share on other sites

@storme:I think I might have fixed tghe issue you reported. Try it! (As a sideeffect it seems you can run multiple copies of ProDLLer now. Don't know if that is good...)

Also I have changed to Messageboxes. :P

Sorry, not fixed but different. :mellow:

Now I get a message "Couldn't start skeleton.sys so I can not aquire DRIVER handle!" :party:

If I can help in anyway let me know.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...