This is code from the vDSO which is mapped by the kernel into every process, not from the wget binary. You could probably figure it out by inspecting the /proc/<pid>/maps file.
Here's what I have in IDA for gettimeofday from it:
.text:FFFFFFFFFF700D17 mov rbx, 0FFFFFFFFFFDFF000h
.text:FFFFFFFFFF700D1E lsl r11d, eax
Clever (some would say incomprehensible) misuse of x86 features could do this for you. The loop instruction will decrement the ecx register, jump if it's nonzero, and not modify flags. You can use this as a jump forward instruction as well, like this:
BB23: push %ecx
movl index, %ecx
movl $0x17, buf-4(,%ecx,4)
I just extracted the following list during my research of this paper:
"Reassembleable Disassembling" Shuai Wang, Pei Wang, and Dinghao Wu,
The Pennsylvania State University
The following list consits of all mentioned tools (dynamic and static), perhaps there is something useful:
UROBOROS (Static, x86/x64 ELF)
So the paper itself introduces UROBOROS. ...
that instrumentation is not easily possible because of JIT compilation of IL instructions.
Well it's actually the opposite. Tracing methods is quite easy - it would be difficult if we would like to trace fields usages. .NET assemblies contain rich type/method information that can be used to inspect/modify them. There's also a great library that does that ...
Before jumping straight to interesting articles and sources I'll start by defining the key words, just in case.
Static analysis : consists in analyzing the target binary file without executing it. Hence the static. Such analysis can be used in order to build a first draft of the application's Control Flow Graph, Call Graph, ...
For example, building the CFG ...
If you look at lib/Target/X86/X86InstrInfo.cpp in the LLVM source code you can see that they prefer the LAHF and SAHF instructions to PUSHF and POPF for speed reasons. These instructions don't deal with the overflow flag OF so this must be handled with separately.
alt_pushf: seto %al ; save OF to AL
The fastest and less cumbersome way I know is to make a copy of MyPinTool directory (under <pin dir>\source\tools\ and overwrite the file MyPinTool.cpp with your own code.
Open the MyPinTool.sln in Visual Studio and build your target. After that you can rename the DLL to whatever you want.
It is not an elegant solution but it gets the job done. In ...
You are correct, we should use INS_InsertPredicatedCall instead of INS_InsertCall in your case. It is quite intuitive to distinguish one from the other, consider the following code
xor eax, eax
mov edx, 0x1
cmp word [esp + 0x4], 0x5
cmovz eax, edx
whose C code is something likes
int cond(int input)
return input == 0x5 ? 1 : 0;
it is not clear if you are using windbg and you have a bunch of .dmp files that you want to auto analyze for access-violation if that is the case you could check this out
original contents of directory
-rw-rw-rw- 1 HP 0 96698 2016-01-29 21:27 CRASH.DMP
duplicating the same file 10 times to simulate a bunch of crash dumps
I think you are looking for ESIL which allow you to emulate code
Specifically aei to initialize the VM and aeip to set the pc to curseek. You can list registers using aer and set them with aer eax=1
You can find more info here and here
|Usage: ae[idesr?] [arg]ESIL code emulation
| ae [expr] evaluate ESIL expression
Yes, your Pintool written in C/C++ works fine for binaries (of x86 or x86-64 instruction set) generated from compilers of other languages. You can see this quotes in the file README of any Pin distribution
... the [instrumented] application can use any compiler.
Personally, I have used Pin to instrument binaries compiled by OCaml compiler (so the source ...
frida is cross-platform (OS X, Windows, Linux, iOS, Android) and also supports multiple architecture.
Soot can give you a Jimple IR of an apk and inject instrumentation into it. It's not dynamic though, although I don't see why it couldn't be used for data dependency analysis. Unless your target app does weird things with reflection or JNI you should still be able to perform the analysis you want.
There's a tutorial on using Soot with Dalvik executables ...
When dealing with multi-threaded program, you may end up getting instructions from different threads. You can for example check the current thread ID to make sure you're getting what you need.
Even if the program itself does not use threads, they may be created by system libraries. One of the most common examples is the TppWaiterpThread. RPC functions also ...
You can use de4dot (https://github.com/0xd4d/de4dot) to deobfuscate the binary. Static analysis of dotnet binaries can be done easily by using de4dot and then using ILSpy to create a visual studio project, then you can analyze the source code in visual studio. You can also use dnSpy which allows you to debug the binary easily.
About the instrumentation, a ...
On modern Linux systems, a syscall stub (vdso) is used to invoke the actual syscall. This is done so that the application binary does not need to know anything about the host CPU, and what mechanism is best or fastest for the CPU.
This can be seen from within GDB or via ldd.
linux-vdso.so.1 => (0x00007fff07fc3000)
Why not just use PIN_AddSyscallEntryFunction? This is an ABI-agnostic way of doing things, that lets you use PIN_GetSyscallArgument and related functions rather than manually inspecting the stack and register context.
You could also use INS_IsInterrupt at instrumentation time to gather the information at ...
First parameter of the constructor is the memory allocated for the object.
(Usually stored at r0 for ARM and thumb).
So the way to monitor it is simple: instrument all constructors of the class and watch the first constructor parameter.
CreateToolhelp32Snapshot() would help for creating a snapshot of program state, especially fuzzing a la this paper
Also, Peter Van Eeckhoutte covered what you're attempting to do in (in-memory fuzzing) in this blogpost
Both are outlined step by step
PIN_AddSyscallEntryFunction and PIN_AddSyscallExitFunction should do the trick. Link to the Documentation.
Snippet using theses APIs : (credits to Jurriaan Bremer)
void syscall_entry(THREADID thread_id, CONTEXT *ctx,
SYSCALL_STANDARD std, void *v)
printf("system-call: %d, arguments:",
Posting a 2nd answer for a different method, combining cmov to avoid a skip-1-instruction branch with @Ian Cook's nice lahf/sahf.
movl index, %ecx
seto %al # save OF to AL
lahf # save other flags to AH
movl $0x17, buf(,%ecx,0x4)
As you correctly mentioned, this is a pseudo C code which output a C-like code. This code can't be compiled since it's not a valid C code. This output can be shown using the pdc command.
radare2 contains plugins for decompilers like Snowman and retdec. You can read more about it and my answer here. With these decompilers you have high chances to success ...
A few of other approaches could be:
Using IDA's AppCall functionality. It isn't all too known a feature (and it should be!) but IDA makes an effort letting you use functions inside the binary in isolation. Check out the link for usage details.
Using a debugger. This may not be what you're asking about but you could easily provide register values and execute ...
If you have control over the original memory, and performance is not a concern, you can install an exception handler, and then mark the entire original memory region as "not accessible". For each access in the original region, the exception handler will gain control. At that point, you can copy the faulting instruction to a local buffer, save all registers,...
To my best knowledge, Frida has no support for non-android java applications.
For desktop java applications you are better of using Java agents or the lower level JVM-TI interface. There's also the pyspresso framework which uses the Java Debug Wire Protocol to debug java applications using a python code base.
Also have a look at this answer for more ideas....
I think that one option could be to use ptrace, for example you can use _dl_open() instead of LD_PRELOAD. Look at this example:
Another option could be to use gdb for do that, for example you have the possibility to set a pending breakpoint to foo and then run the program.
Another option ...
Carlos's answer is more of a workaround, but it's so much spot on. Getting all the right knobs right is an insane job. And even more so with version 3 that switched away from whatever native runtime the OS may have, and started to use their own.
After half a day reversing the examples, I could come up with this (I'm assuming a 64 bit Windows target, but it ...
I was able to find a blog which helped me configure Visual Studio 10 to develop my own tools. Here is the link to blog . The steps mentioned are generalized. But one thing I observed was that few directory names were different in my Pin installation. So please keep in mind to update those names. For some weird reasons I had to add "\LIBPATH:(path to ...
It seems that you're trying to run some code in the context of the binary before anything meaningful happens.
You should read some resources about ELF infection, for example on vxheavens or here.
But since you're trying to inject/execute s2e_rawmon_loadmodule from s2e, maybe you should just use a debugger instead, because I'm quite sure that this is not ...