Recently I was trying to learn more about Windows Kernel. I downloaded right symbols
for my sys(win7 x64 free). I run IDA and open ntoskrnl.exe. IDA asked whether to attach pdb file. But most of functions were not resolved - sub_XXXXXX. So I ran Windbg, I unassembled randomly chosen function which has to be in ntoskrnl - KiSystemCall64. And it show output.
But there is no such function in IDA(or it was not resolved). To sum up, using the same symbols, functions which are unassembled in WinDBg, are not resolved(no sign of them) in IDA(and vice versa).
I would appreciate any help, suggestions from You.
Did you analyze the module after you loaded symbols for it? In the Modules window, right click the kernel and choose "Load debug symbols." After that's done, right click the module again and choose, "Analyze module."
-scott
Related
I am trying to compile a cuda program which uses cusparse library. I am getting linking error:
kernel.cu.obj : error LNK2019: unresolved external symbol _cusparseSetMatIndexBase#8 referenced in function _main
And a lot of error of same kind related to cusparse library. I have included "cusparse_v2.h".
How do i link cusparse library in visual studio 2010 during compilation?
The general instructions for linking libraries is not specific to CUDA. So you may want to learn more about using MS VS. Anyway, the steps are like this:
Make sure you have opened the project that you want to work on.
Select View...Property Pages (from the menu) A new dialog box will open up.
On the left hand side of this dialog box, select Linker to open up it's sub-menu
Under linker, select Input
Now, on the pane on the right, observe the first item which is "Additional Dependencies". I believe cudart.lib should already be present there.
Click to the right of cudart.lib You can now type in new libraries to be added. Type a space (to separate from cudart.lib) and type cusparse.lib
Now click "Apply" in the lower right corner of the dialog box.
That should be all that's needed, if your project/solution file is already set up using a cuda template. If cudart.lib is not present, or your project/solution files do not already comprehend cuda, that is a separate issue. In that case I would recommend starting over, by cloning a project from the Samples, and building your project using that as a starting point. It will then pick up all the proper directories to search as well as the cuda build rules. Since all the main cuda libraries (cudart, cublas, cufft, cusparse, etc.) are all in the same location, the same search path should pick any of them up as needed.
If you wanted to link another library, such as cublas.lib, for example, you could follow a similar sequence, replacing cusparse.lib above with cublas.lib
Note that with newer versions of CUDA (e.g. CUDA 7.5) it will be necessary to build a 64-bit project only (follow the above steps when modifying the x64 project properties.) CUDA 7.5 and beyond are dropping support for 32-bit projects.
I fixed it by following steps:
Add cuda path:
Go: "Configuration Properties->Linker->General->Additional Libary Directories" and add $(CudaToolkitLibDir) to the list.
Add cuda realtime library:
Go: "Solution Properties->Linker->Input->Additional Dependencies" and add cudart.lib to the list.
Add cublas library:
Go: "Solution Properties->Linker->Input->Additional Dependencies" and add cublas.lib to the list.
Changing platform to x64:
Go: "Configuration Properties->Platform" and set it to x64.
Run cmd.exe as administrator.
Type in and run the following two lines of command:
netsh winsock reset catalog
netsh int ip reset reset.log hit
It may say that a reboot is required, but actually that is not necessary.
Try to debug your application again, the problem should be solved.
I try to analyze a dll file with my poor assembly skills, so forgive me if I couldn't achieve something very trivial. My problem is that, while debugging the application, I find the code I'm looking for only in debug session, after I stop the debugger, the address is gone. The dll doesn't look to be obfuscated, as many of the code is readable. Take a look at the screenshot. The code I'm looking for is located at address 07D1EBBF in debug376 section. BTW, where did I get this debug376 section?
So my question is, How can I find this function while not debugging?
Thanks
UPDATE
Ok, as I said, as soon as I stop the debugger, the code is vanished. I can't even find it via sequence of bytes (but I can in debug mode). When I start the debugger, the code is not disassembled imediately, I should add a hardware breakpoint at that place and only when the breakpoint will be hit, IDA will show disassembled code. take a look at this screenshot
You see the line of code I'm interested in, which is not visible if the program is not running in debug mode. I'm not sure, but I think it's something like unpacking the code at runtime, which is not visible at design time.
Anyway, any help would be appreciated. I want to know why that code is hidden, until breakpoint hit (it's shown as "db 8Bh" etc) and how to find that address without debugging if possible. BTW, could this be a code from a different module (dll)?
Thanks
UPDATE 2
I found out that debug376 is a segment created at runtime. So simple question: how can I find out where this segment came from :)
So you see the code in the Debugger Window once your program is running and as you seem not to find the verry same opcodes in the raw Hex-Dump once it's not running any more?
What might help you is taking a Memory Snapshot. Pause the program's execution near the instructions you're interested in to make sure they are there, then choose "Take memory snapshot" from the "Debugger" Menu. IDA will then ask you wether to copy only the Data found at the segments that are defined as "loder segments" (those the PE loader creates from the predefined table) or "all segments" that seem to currently belong to the debugged program (including such that might have been created by an unpacking routine, decryptor, whatever). Go for "All segments" and you should be fine seeing memory contents including your debug segments (a segment
created or recognized while debugging) in IDA when not debugging the application.
You can view the list of segements at any time by pressing Shift+F7 or by clicking "Segments" from View > Open subviews.
Keep in mind that the programm your trying to analyze might choose to create the segment some other place the next time it is loaded to make it harder to understand for you what's going on.
UPDATE to match your second Question
When a program is unpacking data from somewhere, it will have to copy stuff somewhere. Windows is a virtual machine that nowadays get's real nasty at you when trying to execute or write code at locations that you're not allowed to. So any program, as long as we're under windows will somehow
Register a Bunch of new memory or overwrite memory it already owns. This is usually done by calling something like malloc or so [Your code looks as if it could have been a verry pointer-intensive language... VB perhaps or something object oriented] it mostly boils down to a call to VirtualAlloc or VirtualAllocEx from Windows's kernel32.dll, see http://msdn.microsoft.com/en-us/library/windows/desktop/aa366887(v=vs.85).aspx for more detail on it's calling convention.
Perhaps set up Windows Exception handling on that and mark the memory range als executable if it wasn't already when calling VirtualAlloc. This would be done by calling VirtualProtect, again from kernel32.dll. See http://msdn.microsoft.com/en-us/library/windows/desktop/aa366898(v=vs.85).aspx and http://msdn.microsoft.com/en-us/library/windows/desktop/aa366786(v=vs.85).aspx for more info on that.
So now, you should take a step trough the programm, starting at its default Entrypoint (OEP) and look for calls tho one of those functions, possibly with the memory protection set to PAGE_EXECUTE or a descendant. After that will possibly come some sort of loop decrypting the memory contents, copying them to their new location. You might want to just step over it, depending on what your interest in the program is by justr placing the cursor after the loop (thick blue line in IDA usually) and clicking "Run to Cursor" from the menu that appears upon right clicking the assembler code.
If that fails, just try placing a Hardware Breakpoint on kernel32.dll's VirtualAlloc and see if you get anything interestin when stepping into the return statement so you end up wherever the execution chain will take you after the Alloc or Protect call.
You need to find the Relative Virtual Address of that code, this will allow you to find it again regardless of the load address (pretty handy with almost all systems using ASLR these days). the RVA is generally calculated as virtual address - base load address = RVA, however, you might also need to account for the section base as well.
The alternative is to use IDA's rebasing tool to rebase the dll to the same address everytime.
Is it possible to add code to a current binary in IDA and then save then to recompile the binary? I've looked over Google, but no suggestions as to whether IDA can do this. If not, whats the best to add some pretty heavy modifications to obsolete firmware?
Would I have to load in additional classes/functions from a file?
You can't recompile your source data file with IDA (the program's 'Create an EXE file' tool found in its main main doesn't do anything - It's basically stubbed with a message box telling the used that the selected output file type is not supported).
Your only option might be to compile your code with the source file's compiler, add a new segment to the source file's image where you dump your custom (compiled)code and patch the appropriate locations in the original code (.text) segment to call into your code. Have no clue if IDA supports the kind of static patching required for steps #2 and #3, but you'll probably find other tools to help you with that (you could start with OllyDbg).
I haven't ever tried to do anything of that sort before, so take my suggestion with a pinch of salt. I have however seen various binaries that have arbitrary segments attached to them.
EDIT: Take a look at this question while you are at it - IDA pro asm instructions change
when i have to do small updates on my binary, i like hexedit, kinda nice & options are easy. (small updates ;) )
I am a new one to Common Lisp (using Clozure Common Lisp under Microsoft Windows), who is familiar with c and python before. So maybe the questions are stupid here, but be patient to give me some help.
1) What's is the usual way to run a common lisp script?
Now, I wrote a bat file under windows to call ccl exe(wx86cl.exe) and evaluate (progn (load "my_script_full_path") (ccl:quit)) every time when I want to "run" my script. Is this a standard way to "run" a script for common lisp?
Any other suggestion about this?
2) What's the difference between (require 'cxml) and (asdf:operate 'asdf:load-op :cxml)?
They are seems to be the same for my script, which one should I use?
3) ignore it, not a clear question
4) When I want to load some library (such as require 'cxml), it always takes time(3s or even 5s) to load cxml every time when I "run" my script, there is also much log to standard output I show below, it seems like checking something internal. Does it means I have to spent 3-5s to load cxml every time when I want to run a simple test? It seems like a little inefficient and the output is noisy. Any suggestion?
My Script
(require 'cxml) (some-code-using-cxml)
And the output
; Loading system definition from D:/_play_/lispbox-0.7/quicklisp/dists/quicklisp/software/cxml-20101107-git/cxml.asd into #<Package "ASDF0">
;;; Checking for wide character support... yes, using code points.
; Registering #<SYSTEM "cxml-xml">
......
some my script output
---EDIT TO ADD MORE----
5) I must say that I almost forget the way of dumping image to accelerate the loading speed of lisp library. So, what is the normal process for us to develop a (maybe very simple) lisp script?
Base on the answer of what I got now, I guess maybe
a) edit your script
b) test it via a REPL environment, SLIME is a really good choice, and there should be many loop between a <==> b
c) dump the image to distribute it?( I am no sure about this)
6) Furthermore, what is the common way/form for us to release/distribute the final program?
For a lisp library, we just release our source code, and let someone else can "load/require" them.
For a lisp program, we dump a image to distribute it when we confirm that all functions go well.
Am I right?
What form do we use in a real product? Do we always dump all the thing into a image at final to speed up the loading speed?
1) Yes, the normal way to run a whole programme is to use a launcher script. However, windows has much, much better scripting support these days than just the bat interpreter. Windows Scripting Host and PowerShell ship as standard.
1a) During development, it is usual to simply type things in a the REPL (Read-Eval-Print-Loop, i.e. the lisp command line), or to use something like SLIME (for emacs or xemacs) as a development environment. If you don't know what they are, look them up. You may wish to use Cygwin to install xemacs, which will give you access to a range of linux-ish tools.
2) Require is, IIRC, a part of the standard. ASDF is technically not, it is a library that operates to make libraries work more conveniently. ASDF has a bunch of features that you will eventually want if you really get into writing large Lisp programmes.
3) Question unclear, pass.
4) See 1a) - do your tests and modifications in a running instance, thus avoiding the need to load the library more than once (just as you would in Python - you found the python repl, right?). In addition, when your programme is complete, you can probably dump an image which has all of your libraries pre-loaded.
Edit: additional answers:
5) Yes
6) Once you have dumped the image, you will still need to distribute the lisp binary to load the memory image. To make this transparent to the user, you will also have to have a loader script (or binary) to run the lisp binary with the image.
You don't have to start the lisp from scratch and load everything over again each time you want to run a simple test. For more efficient development, interactively evaluate code in the listener (REPL) of a running lisp environment.
For distribution, I use Zachary Beane's Buildapp tool. Very easy to install and use.
Regarding distribution -
I wrote a routine (it's at home and unavailable at the moment) that will write out the current image as a standard executable and quit. It works for both CLISP and SBCL.
I can rummage it up if you like.
From debugging the program I only know that before clicking a button a set of known data isn't in memory (confirmed by memory search) and after clicking it the data is in memory (all the time a different location).
How can I find the code that generates this data?
One of the major problems (which might be important to know) is that it is a .net-Program (which I can't analyze with Reflector because it is obfuscated). So I'm analyzing the assembly generated by .NET (in Olly / Immunity / IDA).
If it is .Net you could debug the IL code. It is not easy though, but it should be possible to find the il intruction that writes the sequence into memory.
Try debugging tools for windows with the so called SOS extension.
You could also try if it would be possible to generate say C# code from the obfuscated assemblies for debugging. But this will most certainly not better readable code than IL.
Add Cheat Engine to your toolkit.
If you can get the address it will write to you could right click it and choose "Find out what writes to this address".
P.S. For a reverse effect you can select an instruction in the memory view, right click and choose "Find out what addresses this instruction access".