I was looking up something, and stumbled upon this code:
http://google.com/codesearch?q=kBrowserThreadNames
Where can I find the source for base::Thread?
(Thing is, in debugging something running under firefox.exe, I notice Gecko_IOThread is setting it's thread name in some kind of way and wanted to look up how.)
A quick Mozilla MXR lookup seems to indicate that it's defined in mozilla/ipc/chromium/src/base/thread.h
Edit:
I was also curious about the presence of Chronium code in Mozilla so I googled a bit and found this on the blog of Benjamin Smedberg the commiter of the code:
IPDL is a language which precisely
describes the messages that can be
passed between processes, and allows
developers to define a state machine
and error handling conditions for
messages and resources shared across
processes. IPDL layers on top of an
IPC stack that Mozilla copied from the
Chromium codebase
Just click your way into the code...
http://google.com/codesearch/p?hl=en#cFooKvxdTls/ipc/chromium/src/base/thread.cc&q=kBrowserThreadNames&d=2
Related
I am looking for a way to do things such as attach to a process, set breakpoints, view memory, and other things that gdb/lldb can do. I cannot, however, find a way to do these things.
This question is similar to this one, but for MacOS instead of Windows. Any help is appreciated!
Note: I want to make a debugger, not use one.
Another thing is that i dont want this debugger to be super complicated, all i need is just reading/writing memory, breakpoint handling, and viewing the GPR
If you really want to make your own debugger, another way to start would be to figure out how to cons up and parse the gdb-remote protocol packets (e.g. https://sourceware.org/gdb/onlinedocs/gdb/Remote-Protocol.html). That's the protocol gdb uses when remote debugging and lldb uses for everything but Windows debugging. On MacOS, lldb spawns a debugserver instance which does the actual debugging and controls it with gdb-remote protocol packets. On Linux, it uses the lldb-server tool that's part of the Linux lldb distribution for the same purpose.
The gdb-remote protocol has primitives for most of the operations you want to perform, launch a process, attach to a process, set breakpoints, read memory & registers and isolates you from a lot of the low-level details of controlling processes.
You can help yourself out by observing how lldb uses this protocol by running an lldb debug session with:
(lldb) log enable gdb-remote packets
But you might also have a look at the SB API's in lldb. The documentation is not as advanced as it should be but there are a bunch of examples in the examples/python directory of the lldb sources to get you started, and in general the API's are pretty straightforward and self-explanatory.
LLDB has an API that can be consumed from C++ or Python. Maybe this is what you’re looking for.
Unfortunately the documentation is fairly threadbare, and there don’t seem to be usage examples. This will therefore entail some reading of the source and a lot of trial and error.
If you want to write your own debugger, you'll need to obtain a task port to the process (task_for_pid), then you can read/write/iterate to virtual memory (mach_vm_read, mach_vm_write, mach_vm_region). To do breakpoints, you need to first set up an exception handler then you can manipulate the debug registers on threads (task_threads, thread_get_state, thread_set_state) and handle them in the exception handler.
Reference to some not all that correct debugger code I've written because breakpoints (especially instruction ones) are a bit involved.
MacDBG may be another lightweight reference but I haven't used it myself.
Well, if you want to write a debugger, take a look at the gdb/lldb source code. I'd suggest the latter, due to historical legacy in gdb that might cloud whatever is actually going on.
Use a debugger. Such as gdb or lldb for example. They have plenty of documentation to teach you the how bit, but for example gdb -p <pid of process> will attach gdb to a running process.
If you want to drive gdb for example from a C++ program, then launch it in a separate process (see fork and exec) with the aguments it needs (probably including the one to enable its machine parsable interface). Make sure you set up pipes to its stdin/stdout so you can read its output and send it commands.
If instead you want to write your own debugger from scratch then that is a huge undertaking. I suggest starting by reading the source of an existing open source debugger.
Whilst you could look at source code of another debugger, you may find it difficult to understand without the knowledge of the underlying concepts. Therefore, I recommend you start by obtaining a good grounding of the concepts with the following resources:
Mac OS X Sys Internals
Rather outdated now, but the original bible for the internals of Mac
Mac OS X and iOS Internals
Again, outdated but useful. This link is Jonathan Levin's (the author's) own site and he's now providing it for free, due to issues he had with the publisher. He's since purchased back the rights, making it available to all.
*OS Internals
The current bible of Mac Internals, also by Jonathan Levin. Books III and I have been published, with book II to follow shortly!
WebKit's Remote Debugging Protocol went 1.0 recently and I've been playing around with it a little, mostly out of curiosity and interest. I've thrown together a very basic recreation of Chrome's developer tools console as a replacement front-end, but I'm a little confused as to how I can execute code in a specific frame/window like Chrome's Dev Tools allow you to.
At the moment, I'm using the Runtime.evaluate method to execute my console input. This seems inadequate because of the aforementioned problem and it doesn't provide the command line API. I've discovered the Debugger.evaluateOnCallFrame method, which requires a callFrameID parameter. The only problem is, it doesn't seem possible to remotely acquire a list of callFrame objects to pass to this method.
I have a feeling I'm completely missing something here. Does anyone know the solution?
Have a look at the Debugger.paused event, which will give you an array of current call frames.
I can't be clearer than my title. :P
I want to run my program whenever a user renames a file in Windows Explorer (and only within the Explorer). Here's a simple mock up:
A simple link to a tutorial will be very helpful. I couldn't find anything. :/
Thank you in advance.
P.S. I'm new in C++
It looks like Windows API hooking may be your best bet. You'll want to intercept all calls related to Windows file renaming (i.e. MoveFile, MoveFileEx, SHFileOperation, possibly more). There are a few commercial and open source solutions; Microsoft Detours, Madshi's madCodeHook, and the free, open source EasyHook.
This approach, when done correctly, will allow you to capture all file renaming on a system.
I would avoid hooking APIs as much as possible. It gets really ugly really fast.
There are 2 ways I see that you can approach this.
Both ways have a few common factors:
The ReadDirectoryChangesW API. For a very good implementation of that API, see this
article
You will need to minimize your dependencies, so... Use a Microsoft compiler, link to the DLL runtime, stick to C as much as possible etc. This reduces problems. Loading things into the shell memory space is already problematic enough.
Method one is to use ReadDirectoryChangesW from an Explorer shell extension that does nothing else. Keep it minimal. I'm reasonably sure I saw a "do nothing" shell extension as an example in some of Microsoft's documentation.
Method two would be to package your code as a DLL and use a system hook to get your DLL loaded into Explorer only. The system hook should only load inside Explorer to prevent spurious notifications via ReadDirectoryChangesW.
Hope this helps and that you're not using it for something Evil.
How do I go about hooking/redirecting a function in a DLL (say, CreateThread from Kernel32.dll) loaded in the current process?
(I don't have control over which pieces of code call CreateThread, so it's not like I can just have the code something else instead.)
The language doesn't matter much; I'm guessing C/C++ would be the best choices for this.
Update:
I forgot to mention: I'm not looking for solutions that require the bundling of extra libraries into my program; I was looking for a manual way of doing the hooking (such as by rewriting the address of the function), not for using an external library to do this.
But thanks to those who mentioned an external library; sorry I didn't say this earlier.
there's MS library for this: Detours
(This most likely would have been more appropriate as a "comment" under the "Detours" answer, but, as my "reputation" isn't enough yet to add comments I guess, let me post it as an answer)
This post under this thread ("DirectShow question") mentions a replacement/home-grown alternative to Detours (with some rough code example as well) by Alessandro Angeli.
I've actually first found it quoted in another thread ("problem in hooking cocreateinstance") while also searching for COM component creation hooking/tracing (This second thread is more focused on cross-process hooking though).
Let me also add a link for WinAPIOverride32 (by Jacquelin Potier) for convenience here as well. It seems to have "developer designed GUI" :) but, no complaints at all as it is open source (as mentioned above).
Check out http://easyhook.codeplex.com/
It's an API Hooking framework.
Its open source, very easy to use!
I am trying to develop an IThumbnailProvider for use in Windows 7. Since this particular thumbnail would also be dependant on some other files in the same directory, I need to use something other than IInitializeWithStream to a path to work with, this being IInitializeWithItem. (Alternatively, I could use IInitializeWithFile, but that is even more frowned upon apparently.)
No matter what I do, I cannot get it to work. I have Microsoft's FileTypeVerifier.exe tool which gives the green light on using IInitializeWithItem, but when explorer calls it, it only seems to try IInitializeWithStream, ever. (This was tested by temporarily implementing said interface, and Beep()ing away in its Initialize()) Did I forget to configure something?
In short: how do I get this to work?
Okay, I finally found out what is the matter. To quote the Building Thumbnail Providers link on the MSDN website:
There are cases where initialization with streams is not possible. In scenarios where your thumbnail provider does not implement IInitializeWithStream, it must opt out of running in the isolated process where the system indexer places it by default when there is a change to the stream. To opt out of the process isolation feature, set the following registry value.
HKEY_CLASSES_ROOT
CLSID
{66742402-F9B9-11D1-A202-0000F81FEDEE}
DisableProcessIsolation = 1
I knew I was running out of process since I read elsewhere that thumbnailproviders ALWAYS ran out of process. But since that particular snippet is on almost -all- shell extension handlers, I interpreted it to be a overly happy copy-paste job, since it was -required- to run in-process the way I understood it.
And I was wrong. I hope this will help someone else in the near future. :)