I would like to experiment a bit with TCMalloc on Windows. I have built the VisualStudio solution which is part of the gperftools package I downloaded. But when I run any of the test apps which also came with the download, say tcmalloc_minimal_unittest.exe, all the memory allocation calls go to the standard malloc. Has anybody seen this already and knows what I should do? Many thanks.
Ok, I answer my own question. This may be useful to someone else. I was seeing on the VS debugger that the CRT malloc was invoked, but looking at the assembler code I see that the beginning of the function is patched, showing a jump to Perftools_malloc. So, apparently, instead of presenting a different API, TCMalloc hooks into regular calls to the CRT.
Related
I installed LiteIDE and GDB. I opened my Go project in LiteIDE and added a breakpoint to some point in the code. Then i switched back to terminal and ran the project binary that was supposed to envoke the breakpoint and nothing happened. What am i doing wrong?
You have to actually launch the executable from the IDE for breakpoints to mean anything.
Also keep in mind that gdb is mostly meaningless with Go 1.3.x and even more so with 1.4 (dev).
From https://golang.org/doc/gdb:
GDB does not understand Go programs well. The stack management, threading, and runtime contain aspects that differ enough from the execution model GDB expects that they can confuse the debugger, even when the program is compiled with gccgo. As a consequence, although GDB can be useful in some situations, it is not a reliable debugger for Go programs, particularly heavily concurrent ones. Moreover, it is not a priority for the Go project to address these issues, which are difficult. In short, the instructions below should be taken only as a guide to how to use GDB when it works, not as a guarantee of success.
In time, a more Go-centric debugging architecture may be required.
I use this package https://github.com/gostart/debug/ and so far it is the best solution that I have found.
Hope this helps.
I'm playing around with LLVM under Windows, just trying to understand it a little better by building some sample programs. Currently, I'm looking at HowToUseJIT. I noticed that when I run 64-bit, I get an entry point with what seems to be some pretty really crazy code. It saves rsi, rdi and xmm6-xmm15 on the stack; then sets rax and rcx; then restores all of the previously-saved values before finally calling the next function in the call chain.
Is there a good reason for this? Or does it suggest that LLVM on Windows x64 is not quite ready for prime-time?
EDIT: This was with LLVM 2.8. I just downloaded what's currently on the 2.9 branch and it doesn't show the same behavior.
It depends. All the register saves are due to Win64 ABI, when they are callee-saved and thus should be properly saved / restored.
The reason why they noop loads / stores are not eliminated is might due to fast instruction selector used by default for JIT. It will get you the binary code really fast but sacrificing the quality.
Try to switch to normal codegen to check whether the problem still exist.
Is it possible to decompile a Mac kernel extension?
In theory it is possible to decompile any binary code.
Kernel extensions are a little bit tricky because
a) they're C++, so virtual methods make the code harder to follow.
b) linking happens differently in kernel extensions, so any decompiler would need be specially designed to handle kernel extensions in order to find dependencies and symbol names.
you can use gdb (as nate c suggested) to inspect the assembly code of a kernel extension. i'm not aware of any decompilers for kernel extensions specifically.
you can use the kextload tool to create a symbols file that you can load into gdb. this will let you see decoded symbol names for functions, &c. there's a crash (haha get it?) tutorial here: http://praveenmatanam.wordpress.com/2008/05/22/kext-debugging-on-mac/
why do you want to do this?
It is no problem to decompile 32bit kext's using the hexrays decompiler.
Decompiling c++ code, means you have to define your structs in the right way: when an object has virtual methods, the first item in the object will be a pointer to the object's vtable.
if you declare the vtable in IDA or hexrays as well, and make sure all the types of the function pointers are correct, hexrays will produce quite readable code.
But chances are that the parts of the kext you are interested in were written in C-like C++, and you don't need to worry about that at all.
For reversing 64-bit kexts, acquire ida pro and x64 Decompiler (any of mac/lin/win).
Also, you can usually debug a kext (without symbols) using lldb remote setup. (gdb is gone.)
If you happen to work for a large security shop, do the song-and-dance: sign an NDA, give rights to first born and just get the OSX source.
Also, here's a large list of decompilers:
https://en.wikibooks.org/wiki/X86_Disassembly/Disassemblers_and_Decompilers
I'm in an Assembly class focusing on the intel 8086 architecture (all compiling / linking / execution comes from running DOS on win7 via DOS-Box).
I've finished programming the latest assignment, but as I have yet to program any program successfully the first time through, I am now stuck trying to debug my code.
I have visual studio 2010 and was wondering if there was some built in feature that would help me debug my assembly code, specifically, I'm looking to track the value of a variable.
Failing that, instructions pointing to a DOS-Box debugger (and instructions!) would be much appreciated. (I think I've been able to run codeview debug, but I couldn't figure out how to do what I was looking for).
You are generating 16-bit code, you have to break into a museum to find better tooling. Try Borland's, maybe the debugger included with Turbo C.
Yes, indeed, you can use the debugger in VS to examine pretty much everything. Irvine's site has a section specifically on using the debugger here. You can examine registers, use the watch window, etc. He also has a guide for highlighting asm keywords if you need that.
Edit: as Hans pointed out, if you are using 16-bit instead of 32-bit protected, you'll need different tools. There are several choices, listed here.
Borland's tools for DOS were called tasm, tlink, and tdebug.
How do I use GDB to debug a program which do not have debugging symbols on a 32-bit x86 processor? Inspecting the function arguments, local variables, resolving pointers would be useful to know how to do.
The intention is not really to use this for reverse engineering, as I'm sometimes just too lazy to install the debugging symbols and would be great to know how to get some basic information out of gdb.
To start out, you can do;
gdb "whatever"
break __libc_start_main
r
that will setup a breakpoint in libc's crt0 code and allow you to break before main, even if the target binary is totally stripped.
That will get you to a running state at a breakpoint before most user code. You can then single step, dissasemble, dump memory etc... to your heart's content.
This works on all platforms, the fact your asking about IA-32 / x86 does not matter.
Without debugging symbols, you can only debug at the ASM level. Ok you get a bit more information, but you're not going to get very far unless you understand a bit of ASM and the code the compiler generates. This will let you do a simple inspection of local variables etc if you know what you're doing.
If you have the source, it's going to be far easier just to recompile it.
All you can do is look at registers and the contents of the stack - you'll have to do everything by inferring what things are used for, as Draemon mentions.
Well, the absolutely most important thing is that you be able to unwind the stack. There are three ways this can be ensured:
Build debugging symbols with -g
On systems that do C++ exception unwinding via tables (probably anything ELF these days?), the -funwind-tables flag will tell it to generate such tables regardless of language, and GDB can use these tables (at least, with x86 linux it can).
Or, failing those, at least make sure that -fomit-frame-pointer isn't enabled