first things first:
It was working when I used it last time (which is about more than a month ago).
The Problem is, that no command which is from an extension is working, it seems like no extension is loaded.
Only the default commands do work (like version etc.)
The output of the command "Version" is:
Extension DLL chain:
dbghelp: image 6.2.9200.16384, API 6.1.6, built Sat Nov 20 12:57:48 2010
[path: C:\Windows\system32\dbghelp.dll]
ext: (Not loaded)
wow64exts: (Not loaded)
exts: (Not loaded)
uext: (Not loaded)
ntsdexts: (Not loaded)
It says that no extensions were loaded, but the folder winext does exist in my system32 folder (C:\Windows\System32\winext), where the extensions are located in (as far as I know).
Commands like !gle do not work :/
I really have no Idea what I can do, please help me :)
Does the DBGTOOLS definition in your IDA.CFG point to the x86 WinDBG installation directory?
The following comes from IDA Pro's help:
Windbg debugger plugin has the following configuration options:
- The Debugging Tools folder: This should be configured to point to the same
folder where Microsoft Debugging Tools are installed. The plugin will try to
guess where the tools are, but if it fails, a manual intervention will be
required. If this option is not set, then the plugin will try to use dbgeng.dll
from MS Windows system folder, while normal debug operations will work,
extensions will not.
This information indicates that if IDA Pro is using dbgeng.dll from the Windows system folder, the extensions command (like !gle) will not work.
If you have already setup the DBGTOOLS to point to your WinDbg (x86 version) directory correctly in your /cfg/ida.cfg but IDA Pro is still using dbgeng.dll from your Windows system folder, then probably your IDA context is not configured to analyze the IBM PC processor. This may happen when you launch IDA Pro and click the 'Go' button directly to work on your own and start the WinDbg debugger.
Check the DBGTOOLS in the ida.cfg, you will find it is wrapped by #ifdef __PC__ #endif.
The __PC__ will only gets defined by IDA Pro if you are analyzing a Windows EXE file for example. Give a try to launch the WinDbg from the IDA Pro menu after you have successfully disassembled a Windows EXE file and see what happens.
If this still hasn't been answered your problem is most likely that you didn't uncomment the DBG Tools line in the ida.cfg file.
I just fixed this myself. hope this helps.
Also the other guys are correct as well. make sure you are escaping with double back slashes "\\" and make sure you pointing to the (x86) directory.
Related
While I am setting up MinGW-W64 (from sourceforge) exe file (for Windows 10) for C++, it shows a message that it was not downloaded correctly. My best guess is that I have a Anaconda/Jupyter setup having MinGW-W64, and it is making all the fuss. How to set it up for both C++ (VS Code / Code lite) and Python/Jupyter/Anaconda?
Make sure you don't mix versions in environment variables like PATH.
Maybe your download was bad?
Or you may have an antivirus software preventing the installation...
You could try a standalone MinGW-w64 build from https://winlibs.com/, which doesn't requite installation - just extract the archive and point VSCode to it.
On Windows, trying something with gtk+. I have downloaded Msys2, along with gtk+3.0.
Successfully compiled all the gtk+3.0 examples in the msys2 mingw-w64 terminal.
Now I want to move a bit further to try work without the msys environment.
I opened up cmd and navigated to where the example executables are compiled. Then I fired them up by typing "example.exe".
libgio-2.0-0.dll missing, not surprised. I go back to check the PATH environment of the msys environment, PATH=/mingw64/bin/:/usr/local/bin:/usr/bin/:/bin:/c/Windows/System32:..blablabla
So in the cmd environment I did set PATH=%PATH%;pathto/mingw64/bin; and run example.exe again.
This time it gave a very strange error cannot find entrypoint inflateValidate (in dll libpng16-16.dll)
So I checked, indeed there was no inflateValidate function in the dll. it seemed to me that something thought the function is in the dll and tried to call it but because it doesn't exist so it failed. What I don't understand is that why did it not fail in the msys environment but failed in the windows environment. And does that bring any impact to me if I am going to ship any gtk application? I thought simply distributing the relevant dll would be enough.
I have tried instead of adding the mingw64/bin path to the PATH variable, but copying the required dll the the execute location 1 by 1, but at the end it still gave the same error.
I have also tried to search for other libpng*.dll in my computer, none of them contained the inflateValidate function.
If anyone know whats going on please shed some light to the question.
I might be very late to the party but I ran into the same issue yesterday (missing the inflateValidate symbol) and after checking the contents of the zlib1.dll file could ascertain that the function is just not there.
I downloaded another version (specifically this one https://sourceforge.net/projects/uqm-mods/files/latest/download, though I am in no way affiliated to this project) and saw that the inflateValidate symbol was indeed declared, so I suppose that the zlib bundled with your files is not up to date with the libpng requirements.
This solved my problem. I hope it solves yours too.
I want to load MSEC.dll in windbg Version 6.12.0002.633 X86.
when I use the command !load MSEC.dll
it says:
The call to LoadLibrary(MSEC.dll) failed, Win32 error 0n127
"The specified procedure could not be found."
Please check your debugger configuration and/or network access.
I changed the version to 6.11 and I also installed visual studio 12 run time with version 12 but it doesn't work!
Is there any way to handle this issue?
When we extract Bang Exploitable (!Exploitable) it creates 2 Folders:
x64
x86
Open the folder as per your Project Bit Size. Now inside that folder, you will get 2 another folders:
Release
Debug
Copy the files from release folder to the folder that contains the executable of windbg.
Sometimes you may also need to change the version of windbg for making it compatible with bang exploitable.
Download
http://download.microsoft.com/download/A/6/A/A6AC035D-DA3F-4F0C-ADA4-37C8E5D34E3D/setup/WinSDKDebuggingTools/dbg_x86.msi
I had the same issue (winxp sp3, windbg 6.12..., !exploitable 1.6). Installing CRT 11 runtime did not work for me. So, the only solution I've found is to use the older version of !exploitable (1.0.6), you can download it here: https://msecdbg.codeplex.com/releases/view/28935
I spent all morning trying to figure this out.
Codeplex was retired in 2021 and this assembly appears to be abandoned by MS so it's difficult to find information.
The site I'm linking to below indicates that you need the Visual C++ 2012 redistributable installed on the target machine to remove this issue.
The same site also statically linked the required files in the source code and rebuilt with VS2017. I downloaded the altered DLL and am now able to load msec.dll with the full path to the assembly in the command.
https://blog.didierstevens.com/2018/07/17/exploitable-crash-analyzer-statically-linked-crt/
usually I deploy my Java apps as a bundle which contains the JVM, so there's no need to install a JVM on the system.
Btw: This is no jnlp applet, this is a normal Swing Application.
I did this using ant's fx:deploy. This already works for 64bit systems.
My problem is, that I want to deploy this application to a 32bit system and don't get it to work.
Here's what I did:
I've set up a clean Windows 7 (32bit) instance and installed a 32bit JVM. Now i ran my ant script to build a bundled Java app and it built a App.exe.
But when I tried to start this exe by double clicking, I get the following message box
If I click OK, I get another message box
After this the app is terminated.
I did not find anything searching the web relating to bundling for 32/64 bit systems.
So I would be very glad if someone can point me in the right direction.
Many thanks in advance!
Greetings, -chris-
Looks like a known bug fixed for an upcoming JavaFX version (currently known as 2.2.40):
RT-25715 The Windows launcher generated by the packager fails to load msvcr100.dll on 32-bit OS
RT-22610 .exe created by fx:deploy can't be executed due to missing msvcr100.dll
On the bug case, the user mentions a work-around:
If I give a try to the workaround documented in RT-22610, which is to copy runtime\jre\bin\msvcr100.dll side to my application's launcher binary, it fixes it.
I think the bug is fixed in JDK 8, so another possible work-around is to download a JDK 8 early access release and use the packaging tools from there to package a Java 7 application (though I have never tried that and am not sure if it would work).
Just a small modification to #jewelsea's Fix:
copying msvcr100.dll into the app/ folder instead putting it right next to the exe also works, and at least it is somewhat hidden away then.
If you're generating an MSI you can hack the WXS file used by WIX to automatically copy msvcr100.dll into the app folder. Making FX Deploy verbose will tell you where it's putting the temporary WXS file you can copy and modify and use to override the WXS like you would the program icon for example.
I have installed the new version of Windows debugging tools and I got a AdPlus.exe. I don't know if there are any changes but I remember when I installed it sometime ago on another computer, what i got was a ADPlus as vbscript file ( and not an executable). In the installation directory I still see there is a vbscript file but does any one know what is the difference between executable and vbscript. Thanks
According to this "what's new" article, they seem to be pretty much the same in that the vbs can still be used if you don't have .net framework 2.0 installed on the machine. That's not to say that there isn't something extra in the tool. You could find out by checking out adplus.doc in that same folder.