moved to markdown extension (#9522)
This commit is contained in:
Evan Carroll
radare
parent
70bd99da25
commit
c12418f05f
35
doc/android
35
doc/android
|
|
@ -1,35 +0,0 @@
|
|||
r2 on android
|
||||
=============
|
||||
Install NDK in archlinux x86-64
|
||||
- Enable multilib repo in pacman.conf
|
||||
- pacman -S lib32-glibc lib32-zlib
|
||||
|
||||
To build r2 for android you need to install the NDK:
|
||||
|
||||
http://developer.android.com/tools/sdk/ndk/index.html
|
||||
|
||||
Edit ~/.r2androidrc to setup the paths to your ndk
|
||||
|
||||
sys/android-shell.sh
|
||||
./configure --with-compiler=android --with-ostype=android --prefix=/data/radare2 --without-pic --with-nonpic
|
||||
make -j 4
|
||||
|
||||
To compile for android-x86
|
||||
|
||||
export NDK_ARCH=x86
|
||||
|
||||
To package:
|
||||
|
||||
mkdir
|
||||
make install DESTDIR=/usr
|
||||
|
||||
Build farm
|
||||
|
||||
See sys/android-shell.sh and sys/android-build.sh
|
||||
|
||||
sys/android-shell.sh sys/android-build.sh arm-static
|
||||
|
||||
Environment:
|
||||
|
||||
NDK_ARCH=arm|x86
|
||||
STATIC_BUILD=0|1
|
||||
|
|
@ -0,0 +1,34 @@
|
|||
r2 on android
|
||||
=============
|
||||
|
||||
Install NDK in archlinux x86-64
|
||||
- Enable multilib repo in pacman.conf
|
||||
- pacman -S lib32-glibc lib32-zlib
|
||||
|
||||
To build r2 for android you need to install the NDK:
|
||||
|
||||
http://developer.android.com/tools/sdk/ndk/index.html
|
||||
|
||||
Edit `~/.r2androidrc` to setup the paths to your ndk
|
||||
|
||||
sys/android-shell.sh
|
||||
./configure --with-compiler=android --with-ostype=android --prefix=/data/radare2 --without-pic --with-nonpic
|
||||
make -j 4
|
||||
|
||||
To compile for android-x86
|
||||
|
||||
export NDK_ARCH=x86
|
||||
|
||||
To package:
|
||||
|
||||
mkdir
|
||||
make install DESTDIR=/usr
|
||||
|
||||
Build farm, see `sys/android-shell.sh` and `sys/android-build.sh`
|
||||
|
||||
sys/android-shell.sh sys/android-build.sh arm-static
|
||||
|
||||
Environment:
|
||||
|
||||
NDK_ARCH=arm|x86
|
||||
STATIC_BUILD=0|1
|
||||
|
|
@ -2,17 +2,17 @@ Brainfuck support for r2
|
|||
========================
|
||||
|
||||
Plugins for brainfuck:
|
||||
- asm.bf - brainfuck assembler and disassembler
|
||||
- debug.bf - debugger using bfvm
|
||||
- anal.bf - code analysis for brainfuck
|
||||
- bp.bf - breakpoints support (experimental)
|
||||
- `asm.bf` - brainfuck assembler and disassembler
|
||||
- `debug.bf` - debugger using bfvm
|
||||
- `anal.bf` - code analysis for brainfuck
|
||||
- `bp.bf` - breakpoints support (experimental)
|
||||
|
||||
To debug a brainfuck program:
|
||||
|
||||
$ r2 -D bf bfdbg:///tmp/bf
|
||||
r2 -D bf bfdbg:///tmp/bf
|
||||
|
||||
> dc # continue
|
||||
> x@scr # show screen buffer contents
|
||||
> dc # continue
|
||||
> x@scr # show screen buffer contents
|
||||
|
||||
The debugger creates virtual sections for code, data, screen and input.
|
||||
|
||||
|
|
@ -23,10 +23,15 @@ TODO
|
|||
|
||||
Hello World
|
||||
===========
|
||||
|
||||
```
|
||||
>+++++++++[<++++++++>-]<.>+++++++[<++++>-]<+.+++++++..+++.[-]
|
||||
>++++++++[<++++>-] <.>+++++++++++[<++++++++>-]<-.--------.+++
|
||||
.------.--------.[-]>++++++++[<++++>- ]<+.[-]++++++++++.
|
||||
```
|
||||
|
||||
```
|
||||
$ cat << EOF
|
||||
>+++++++++[<++++++++>-]<.>+++++++[<++++>-]<+.+++++++..+++.[-]>++++++++[<++++>-] <.>+++++++++++[<++++++++>-]<-.--------.+++.------.--------.[-]>++++++++[<++++>- ]<+.[-]++++++++++.
|
||||
EOF
|
||||
```
|
||||
27
doc/debug
27
doc/debug
|
|
@ -1,27 +0,0 @@
|
|||
Conditional breakpoints
|
||||
=========================
|
||||
conditional breakpoints are implemented in the following way:
|
||||
- when a breakpoint is hit, the condition is run as a normal command
|
||||
- if the command returns a value different from zero, execution continue,
|
||||
- otherwise, execution is stopped at the breakpoint
|
||||
|
||||
Examples of conditional breakpoints
|
||||
======================================
|
||||
1.) ignore breakpoint at address 0x4000ce for five times:
|
||||
f times=5
|
||||
(dec_times,f times=`?vi times-1`,?= times)
|
||||
db 0x4000ce
|
||||
dbC 0x4000ce .(dec_times)
|
||||
dc
|
||||
2.) execute until rax==0x31c0 at address 0x4000ce
|
||||
e cmd.hitinfo=0
|
||||
(break_rax,f reg_rax=`dr rax`,f test=`?vi reg_rax-0x31c0`,?= test)
|
||||
db 0x4000ce
|
||||
dbC 0x4000ce .(break_rax)
|
||||
dc
|
||||
3.) perform a register tracing dump at address 0x4000ce
|
||||
e cmd.hitinfo=0
|
||||
(trace_rax,dr rax,?= 1)
|
||||
db 0x4000ce
|
||||
dbC 0x4000ce .(trace_rax)
|
||||
dc > trace.txt
|
||||
|
|
@ -29,15 +29,15 @@ well as setting up profiles. (??profiles??)
|
|||
The functionality lives in the following files:
|
||||
(?? why so many files? can this be simplified??)
|
||||
|
||||
libr/reg/arena.c // ?? used by anal and debugger
|
||||
libr/reg/cond.c // condition registers
|
||||
libr/reg/double.c // support for double-precision floating point numbers
|
||||
libr/reg/profile.c // ?? used by anal and debugger
|
||||
libr/reg/reg.c // top-level register specific code (all of r2)
|
||||
libr/reg/value.c // dealing with register values
|
||||
libr/reg/t/p.c // test code for printing general-purpose registers
|
||||
libr/reg/t/regdiff.c // ?? test code for?
|
||||
libr/reg/t/test.c // test code for register handling
|
||||
libr/reg/arena.c // ?? used by anal and debugger
|
||||
libr/reg/cond.c // condition registers
|
||||
libr/reg/double.c // support for double-precision floating point numbers
|
||||
libr/reg/profile.c // ?? used by anal and debugger
|
||||
libr/reg/reg.c // top-level register specific code (all of r2)
|
||||
libr/reg/value.c // dealing with register values
|
||||
libr/reg/t/p.c // test code for printing general-purpose registers
|
||||
libr/reg/t/regdiff.c // ?? test code for?
|
||||
libr/reg/t/test.c // test code for register handling
|
||||
|
||||
|
||||
## libr/bp
|
||||
|
|
@ -47,27 +47,27 @@ with breakpoints on any given architecture. It handles managing the list of
|
|||
breakpoints and more.
|
||||
|
||||
Radare supports a multitude of different types of breakpoints.
|
||||
(?? is there a list? sw, hw, and trace? anything else??)
|
||||
(`??` is there a list? sw, hw, and trace? anything else??)
|
||||
|
||||
libr/bp/bp.c // main breakpoint management code
|
||||
libr/bp/io.c // setting and reseting(??) breakpoints
|
||||
libr/bp/parser.h // header for breakpoint parser (??)
|
||||
libr/bp/parser.c // code for breakpoint parser (??)
|
||||
libr/bp/plugin.c // breakpoint plugin management
|
||||
libr/bp/traptrace.c // traptrace (??)
|
||||
libr/bp/watch.c // watch points (mostly not implemented)
|
||||
libr/bp/bp.c // main breakpoint management code
|
||||
libr/bp/io.c // setting and reseting(??) breakpoints
|
||||
libr/bp/parser.h // header for breakpoint parser (??)
|
||||
libr/bp/parser.c // code for breakpoint parser (??)
|
||||
libr/bp/plugin.c // breakpoint plugin management
|
||||
libr/bp/traptrace.c // traptrace (??)
|
||||
libr/bp/watch.c // watch points (mostly not implemented)
|
||||
|
||||
For architecture specific-handling, "bp" delegates various functionality to
|
||||
plugins. The interface for these plugins is much simpler than other plugins
|
||||
used in the radare debugger -- they only define which byte sequences represent
|
||||
valid breakpoints for a given architecture.
|
||||
|
||||
libr/bp/p/bp_arm.c // ARM64, ARM, Thumb, Thumb-2 (big/little endians)
|
||||
libr/bp/p/bp_bf.c // Brainfuck!
|
||||
libr/bp/p/bp_mips.c // MIPS, big/little endian
|
||||
libr/bp/p/bp_ppc.c // PowerPC, big/little endian
|
||||
libr/bp/p/bp_sh.c // SuperH
|
||||
libr/bp/p/bp_x86.c // int3...
|
||||
libr/bp/p/bp_arm.c // ARM64, ARM, Thumb, Thumb-2 (big/little endians)
|
||||
libr/bp/p/bp_bf.c // Brainfuck!
|
||||
libr/bp/p/bp_mips.c // MIPS, big/little endian
|
||||
libr/bp/p/bp_ppc.c // PowerPC, big/little endian
|
||||
libr/bp/p/bp_sh.c // SuperH
|
||||
libr/bp/p/bp_x86.c // int3...
|
||||
|
||||
|
||||
## libr/debug/debug.c
|
||||
|
|
@ -76,17 +76,17 @@ The main top-level debugger functionality lives here. It aims to abstract away
|
|||
the common code flow and integration into radare while delegating more nuanced
|
||||
system interactions to plug-ins.
|
||||
|
||||
libr/debug/arg.c // used by the anal engine (??)
|
||||
libr/debug/desc.c // code for handling file descriptors inside an inferior
|
||||
libr/debug/esil.c // ESIL related debugging code (??)
|
||||
libr/debug/map.c // top-level API for dealing with memory maps
|
||||
libr/debug/pid.c // top-level API for dealing with processes
|
||||
libr/debug/plugin.c // top-level debugger plugin API handling
|
||||
libr/debug/reg.c // top-level code for register r/w and display
|
||||
libr/debug/signal.c // top-level functions for signals
|
||||
libr/debug/snap.c // code for saving, restoring, showing memory snapshots
|
||||
libr/debug/trace.c // top-level tracing API (counting insn hits, etc)
|
||||
libr/debug/t/main.c // test code for the debugger API
|
||||
libr/debug/arg.c // used by the anal engine (??)
|
||||
libr/debug/desc.c // code for handling file descriptors inside an inferior
|
||||
libr/debug/esil.c // ESIL related debugging code (??)
|
||||
libr/debug/map.c // top-level API for dealing with memory maps
|
||||
libr/debug/pid.c // top-level API for dealing with processes
|
||||
libr/debug/plugin.c // top-level debugger plugin API handling
|
||||
libr/debug/reg.c // top-level code for register r/w and display
|
||||
libr/debug/signal.c // top-level functions for signals
|
||||
libr/debug/snap.c // code for saving, restoring, showing memory snapshots
|
||||
libr/debug/trace.c // top-level tracing API (counting insn hits, etc)
|
||||
libr/debug/t/main.c // test code for the debugger API
|
||||
|
||||
## libr/core/cmd_debug.c
|
||||
|
||||
|
|
@ -109,8 +109,8 @@ plug-in API defined in r_debug.h.
|
|||
|
||||
A debugger plug-in capable of debugging brainfuck code!
|
||||
|
||||
libr/debug/p/bfvm.c // Brainfuck VM implementation
|
||||
libr/debug/p/bfvm.h
|
||||
libr/debug/p/bfvm.c // Brainfuck VM implementation
|
||||
libr/debug/p/bfvm.h
|
||||
|
||||
|
||||
### libr/debug/p/debug_bochs.c
|
||||
|
|
@ -137,61 +137,61 @@ thus much of the code within this plug-in is shared. The parts that are not
|
|||
shared are implemented by platform-specific functions that are provided in the
|
||||
following files:
|
||||
|
||||
// architecture-specific debugger code
|
||||
libr/debug/p/native/arm.c // unused?
|
||||
|
||||
// code for handling backtracing
|
||||
libr/debug/p/native/bt.c
|
||||
libr/debug/p/native/bt/fuzzy-all.c
|
||||
libr/debug/p/native/bt/generic-x64.c
|
||||
libr/debug/p/native/bt/generic-x86.c
|
||||
|
||||
// architecture-specific register handling
|
||||
libr/debug/p/native/drx.c // x86-specific debug registers
|
||||
libr/debug/p/native/reg.c // cute include of the files below
|
||||
libr/debug/p/native/reg/kfbsd-x64.h
|
||||
libr/debug/p/native/reg/kfbsd-x86.h
|
||||
libr/debug/p/native/reg/netbsd-x64.h
|
||||
libr/debug/p/native/reg/netbsd-x86.h
|
||||
libr/debug/p/native/reg/windows-x64.h
|
||||
libr/debug/p/native/reg/windows-x86.h
|
||||
|
||||
// platform-specific debugger code on Linux
|
||||
libr/debug/p/native/linux/linux_debug.c // main linux-specific debugging code
|
||||
libr/debug/p/native/linux/linux_debug.h // including cute penguin ascii art
|
||||
|
||||
// architecture-specific register handling on Linux (?? what is this format??)
|
||||
libr/debug/p/native/linux/reg/linux-arm.h
|
||||
libr/debug/p/native/linux/reg/linux-arm64.h
|
||||
libr/debug/p/native/linux/reg/linux-mips.h
|
||||
libr/debug/p/native/linux/reg/linux-ppc.h
|
||||
libr/debug/p/native/linux/reg/linux-x64.h
|
||||
libr/debug/p/native/linux/reg/linux-x64-32.h
|
||||
libr/debug/p/native/linux/reg/linux-x86.h
|
||||
|
||||
// platform-specific debugger code on Windows
|
||||
libr/debug/p/native/w32.c // main code for win32 debugger plugin
|
||||
libr/debug/p/native/maps/windows.c // platform-specific memory map handling
|
||||
libr/debug/p/native/windows/windows_debug.c // !! nothing in here
|
||||
libr/debug/p/native/windows/windows_debug.h // !! nothing in here
|
||||
|
||||
// platform-specific debugger code on XNU (OSX/iOS/etc)
|
||||
libr/debug/p/native/darwin.c // !! not used by anything else
|
||||
libr/debug/p/native/maps/darwin.c // platform-specific memory map handling
|
||||
libr/debug/p/native/xnu/xnu_debug.c // main XNU-specific debugging code
|
||||
libr/debug/p/native/xnu/xnu_debug.h // including cute apple ascii art
|
||||
libr/debug/p/native/xnu/trap_arm.c // ARM family hardware bps (??)
|
||||
libr/debug/p/native/xnu/trap_x86.c // x86 family hardware bps (??)
|
||||
libr/debug/p/native/xnu/xnu_excthreads.c // additional XNU thread handling
|
||||
libr/debug/p/native/xnu/xnu_threads.c // XNU thread and register handling
|
||||
libr/debug/p/native/xnu/xnu_threads.h
|
||||
|
||||
// architecture-specific register handling on XNU (?? what is this format??)
|
||||
libr/debug/p/native/xnu/reg/darwin-x86.h
|
||||
libr/debug/p/native/xnu/reg/darwin-arm.h
|
||||
libr/debug/p/native/xnu/reg/darwin-ppc.h
|
||||
libr/debug/p/native/xnu/reg/darwin-arm64.h
|
||||
libr/debug/p/native/xnu/reg/darwin-x64.h
|
||||
// architecture-specific debugger code
|
||||
libr/debug/p/native/arm.c // unused?
|
||||
|
||||
// code for handling backtracing
|
||||
libr/debug/p/native/bt.c
|
||||
libr/debug/p/native/bt/fuzzy-all.c
|
||||
libr/debug/p/native/bt/generic-x64.c
|
||||
libr/debug/p/native/bt/generic-x86.c
|
||||
|
||||
// architecture-specific register handling
|
||||
libr/debug/p/native/drx.c // x86-specific debug registers
|
||||
libr/debug/p/native/reg.c // cute include of the files below
|
||||
libr/debug/p/native/reg/kfbsd-x64.h
|
||||
libr/debug/p/native/reg/kfbsd-x86.h
|
||||
libr/debug/p/native/reg/netbsd-x64.h
|
||||
libr/debug/p/native/reg/netbsd-x86.h
|
||||
libr/debug/p/native/reg/windows-x64.h
|
||||
libr/debug/p/native/reg/windows-x86.h
|
||||
|
||||
// platform-specific debugger code on Linux
|
||||
libr/debug/p/native/linux/linux_debug.c // main linux-specific debugging code
|
||||
libr/debug/p/native/linux/linux_debug.h // including cute penguin ascii art
|
||||
|
||||
// architecture-specific register handling on Linux (?? what is this format??)
|
||||
libr/debug/p/native/linux/reg/linux-arm.h
|
||||
libr/debug/p/native/linux/reg/linux-arm64.h
|
||||
libr/debug/p/native/linux/reg/linux-mips.h
|
||||
libr/debug/p/native/linux/reg/linux-ppc.h
|
||||
libr/debug/p/native/linux/reg/linux-x64.h
|
||||
libr/debug/p/native/linux/reg/linux-x64-32.h
|
||||
libr/debug/p/native/linux/reg/linux-x86.h
|
||||
|
||||
// platform-specific debugger code on Windows
|
||||
libr/debug/p/native/w32.c // main code for win32 debugger plugin
|
||||
libr/debug/p/native/maps/windows.c // platform-specific memory map handling
|
||||
libr/debug/p/native/windows/windows_debug.c // !! nothing in here
|
||||
libr/debug/p/native/windows/windows_debug.h // !! nothing in here
|
||||
|
||||
// platform-specific debugger code on XNU (OSX/iOS/etc)
|
||||
libr/debug/p/native/darwin.c // !! not used by anything else
|
||||
libr/debug/p/native/maps/darwin.c // platform-specific memory map handling
|
||||
libr/debug/p/native/xnu/xnu_debug.c // main XNU-specific debugging code
|
||||
libr/debug/p/native/xnu/xnu_debug.h // including cute apple ascii art
|
||||
libr/debug/p/native/xnu/trap_arm.c // ARM family hardware bps (??)
|
||||
libr/debug/p/native/xnu/trap_x86.c // x86 family hardware bps (??)
|
||||
libr/debug/p/native/xnu/xnu_excthreads.c // additional XNU thread handling
|
||||
libr/debug/p/native/xnu/xnu_threads.c // XNU thread and register handling
|
||||
libr/debug/p/native/xnu/xnu_threads.h
|
||||
|
||||
// architecture-specific register handling on XNU (?? what is this format??)
|
||||
libr/debug/p/native/xnu/reg/darwin-x86.h
|
||||
libr/debug/p/native/xnu/reg/darwin-arm.h
|
||||
libr/debug/p/native/xnu/reg/darwin-ppc.h
|
||||
libr/debug/p/native/xnu/reg/darwin-arm64.h
|
||||
libr/debug/p/native/xnu/reg/darwin-x64.h
|
||||
|
||||
|
||||
### libr/debug/p/debug_qnx.c
|
||||
|
|
|
|||
|
|
@ -0,0 +1,34 @@
|
|||
Conditional breakpoints
|
||||
=========================
|
||||
conditional breakpoints are implemented in the following way:
|
||||
|
||||
- when a breakpoint is hit, the condition is run as a normal command
|
||||
- if the command returns a value different from zero, execution continue,
|
||||
- otherwise, execution is stopped at the breakpoint
|
||||
|
||||
Examples of conditional breakpoints
|
||||
======================================
|
||||
|
||||
1. ignore breakpoint at address `0x4000ce` for five times:
|
||||
|
||||
f times=5
|
||||
(dec_times,f times=`?vi times-1`,?= times)
|
||||
db 0x4000ce
|
||||
dbC 0x4000ce .(dec_times)
|
||||
dc
|
||||
|
||||
2. execute until rax==0x31c0 at address `0x4000ce`
|
||||
|
||||
e cmd.hitinfo=0
|
||||
(break_rax,f reg_rax=`dr rax`,f test=`?vi reg_rax-0x31c0`,?= test)
|
||||
db 0x4000ce
|
||||
dbC 0x4000ce .(break_rax)
|
||||
dc
|
||||
|
||||
3. perform a register tracing dump at address `0x4000ce`
|
||||
|
||||
e cmd.hitinfo=0
|
||||
(trace_rax,dr rax,?= 1)
|
||||
db 0x4000ce
|
||||
dbC 0x4000ce .(trace_rax)
|
||||
dc > trace.txt
|
||||
|
|
@ -3,16 +3,17 @@ Building for the browser
|
|||
|
||||
# Install emscripten:
|
||||
|
||||
git clone git://github.com/kripken/emscripten.git
|
||||
export PATH=/path/to/emscripten:$PATH
|
||||
make clean
|
||||
git clone git://github.com/kripken/emscripten.git
|
||||
export PATH=/path/to/emscripten:$PATH
|
||||
make clean
|
||||
|
||||
|
||||
# Build radare
|
||||
|
||||
sys/emscripten.sh
|
||||
sys/emscripten.sh
|
||||
|
||||
|
||||
<!--
|
||||
|
||||
--- random notes ---
|
||||
|
||||
|
|
@ -30,3 +31,5 @@ emcc -O2 rax2.o ../../libr/util/libr_util.a -o rax2.js
|
|||
binr/rasm2/rasm2.js:
|
||||
|
||||
emcc -O2 -L.. -o rasm2.js ../../shlr/sdb/src/libsdb.a ../../libr/fs/p/grub/libgrubfs.a -lm $A/util/libr_util.a $A/asm/libr_asm.a rasm2.o ../../libr/util/libr_util.a ../../libr/parse/libr_parse.a ../../libr/db/libr_db.a ../../libr/syscall/libr_syscall.a ../../libr/asm/libr_asm.a ../../libr/lib/libr_lib.a ../../libr/db/libr_db.a ../../shlr/sdb/src/libsdb.a ../../libr/util/libr_util.a
|
||||
|
||||
-->
|
||||
|
|
@ -3,93 +3,105 @@ ESIL
|
|||
|
||||
# source https://github.com/radare/radare2/wiki/ESIL
|
||||
|
||||
ESIL stands for 'Evaluable Strings Intermedate Language'. It aims to describe a Forth-like representation for every opcode. Those representations can be evaluated in order to emulate code. Each element of an esil expression is separated by a comma. The VM can be described as this:
|
||||
```
|
||||
while ((word=haveCommand())) {
|
||||
if (word.isKeyword()) {
|
||||
esilCommands[word](esil);
|
||||
} else {
|
||||
esil.push (evaluateToNumber(word));
|
||||
}
|
||||
nextCommand();
|
||||
}
|
||||
```
|
||||
The esil commands are operations that pop values from the stack, performs some calculations and pushes the result in the stack (if any). They aim to cover all common operations done by CPUs, permitting to do binary operations, memory peeks and pokes, spawning a syscall, etc.
|
||||
ESIL stands for 'Evaluable Strings Intermedate Language'. It aims to describe a
|
||||
Forth-like representation for every opcode. Those representations can be
|
||||
evaluated in order to emulate code. Each element of an esil expression is
|
||||
separated by a comma. The VM can be described as this:
|
||||
|
||||
while ((word=haveCommand())) {
|
||||
if (word.isKeyword()) {
|
||||
esilCommands[word](esil);
|
||||
} else {
|
||||
esil.push (evaluateToNumber(word));
|
||||
}
|
||||
nextCommand();
|
||||
}
|
||||
|
||||
The esil commands are operations that pop values from the stack, performs some
|
||||
calculations and pushes the result in the stack (if any). They aim to cover all
|
||||
common operations done by CPUs, permitting to do binary operations, memory
|
||||
peeks and pokes, spawning a syscall, etc.
|
||||
|
||||
#### Use ESIL
|
||||
```
|
||||
[0x00000000]> e asm.esil = true
|
||||
```
|
||||
|
||||
[0x00000000]> e asm.esil = true
|
||||
|
||||
Syntax
|
||||
======
|
||||
An opcode is translated into a comma separated list of ESIL expressions.
|
||||
```
|
||||
xor eax, eax -> 0,eax,=,1,zf,=
|
||||
```
|
||||
|
||||
xor eax, eax -> 0,eax,=,1,zf,=
|
||||
|
||||
Memory access is defined by brackets.
|
||||
```
|
||||
mov eax, [0x80480] -> 0x80480,[],eax,=
|
||||
```
|
||||
|
||||
mov eax, [0x80480] -> 0x80480,[],eax,=
|
||||
|
||||
Default size is the destination of the operation. In this case 8bits, aka 1 byte.
|
||||
```
|
||||
movb $0, 0x80480 -> 0,0x80480,=[1]
|
||||
```
|
||||
Conditionals are expressed with the '?' char at the beginning of the expression. This checks if the rest of the expression is 0 or not and skips the next expression if doesn't matches. '$' is the prefix for internal vars.
|
||||
```
|
||||
cmp eax, 123 -> 123,eax,==,$z,zf,=
|
||||
jz eax -> zf,?{,eax,eip,=,}
|
||||
```
|
||||
|
||||
movb $0, 0x80480 -> 0,0x80480,=[1]
|
||||
|
||||
Conditionals are expressed with the '?' char at the beginning of the expression. This checks if the rest of the expression is 0 or not and skips the next expression if doesn't matches. `$` is the prefix for internal vars.
|
||||
|
||||
cmp eax, 123 -> 123,eax,==,$z,zf,=
|
||||
jz eax -> zf,?{,eax,eip,=,}
|
||||
|
||||
So.. if you want to run more than one expression under a conditional, you'll have to write it
|
||||
```
|
||||
zf,?{,eip,esp,=[],eax,eip,=,$r,esp,-=,}
|
||||
```
|
||||
|
||||
zf,?{,eip,esp,=[],eax,eip,=,$r,esp,-=,}
|
||||
|
||||
|
||||
The whitespace, newlines and other chars are ignored in esil, so the first thing to do is:
|
||||
```
|
||||
esil = r_str_replace (esil, " ", "", true);
|
||||
```
|
||||
Syscalls are specially handled by '$' at the beginning of the expression. After that char you have an optional numeric value that specifies the number of syscall. The emulator must handle those expressions and 'simulate' the syscalls. (r_esil_syscall)
|
||||
|
||||
esil = r_str_replace (esil, " ", "", true);
|
||||
|
||||
Syscalls are specially handled by '$' at the beginning of the expression. After that char you have an optional numeric value that specifies the number of syscall. The emulator must handle those expressions and 'simulate' the syscalls. (`r_esil_syscall`)
|
||||
|
||||
Order of arguments
|
||||
==================
|
||||
As discussed on irc, current implementation works like this:
|
||||
|
||||
```
|
||||
a,b,- b - a
|
||||
a,b,/= b /= a
|
||||
```
|
||||
a,b,- b - a
|
||||
a,b,/= b /= a
|
||||
|
||||
This approach is more readable, but it's less stack-friendly
|
||||
|
||||
Special instructions
|
||||
====================
|
||||
|
||||
NOPs are represented as empty strings. Unknown or invalid instructions
|
||||
|
||||
Syscalls are implemented with the '0x80,$' command. It delegates the execution of the esil vm into a callback that implements the syscall for a specific kernel.
|
||||
Syscalls are implemented with the '0x80,$' command. It delegates the execution
|
||||
of the esil vm into a callback that implements the syscall for a specific
|
||||
kernel.
|
||||
|
||||
Traps are implemented with the `<trap>,<code>,$$` command. They are used to throw exceptions like invalid instructions, division by zero, memory read error, etc.
|
||||
Traps are implemented with the `<trap>,<code>,$$` command. They are used to
|
||||
throw exceptions like invalid instructions, division by zero, memory read
|
||||
error, etc.
|
||||
|
||||
Quick analysis
|
||||
==============
|
||||
Here's a list of some quick checks to retrieve information from an esil string. Relevant information will be probably found in the first expression of the list.
|
||||
```
|
||||
indexOf('[') -> have memory references
|
||||
indexOf("=[") -> write in memory
|
||||
indexOf("pc,=") -> modifies program counter (branch, jump, call)
|
||||
indexOf("sp,=") -> modifies the stack (what if we found sp+= or sp-=?)
|
||||
indexOf("=") -> retrieve src and dst
|
||||
indexOf(":") -> unknown esil, raw opcode ahead
|
||||
indexOf("$") -> accesses internal esil vm flags
|
||||
indexOf("$") -> syscall
|
||||
indexOf("$$") -> can trap
|
||||
indexOf('++') -> has iterator
|
||||
indexOf('--') -> count to zero
|
||||
indexOf("?{") -> conditional
|
||||
indexOf("LOOP") -> is a loop (rep?)
|
||||
equalsTo("") -> empty string, means: nop (wrong, if we append pc+=x)
|
||||
```
|
||||
|
||||
Here's a list of some quick checks to retrieve information from an esil string.
|
||||
Relevant information will be probably found in the first expression of the
|
||||
list.
|
||||
|
||||
indexOf('[') -> have memory references
|
||||
indexOf("=[") -> write in memory
|
||||
indexOf("pc,=") -> modifies program counter (branch, jump, call)
|
||||
indexOf("sp,=") -> modifies the stack (what if we found sp+= or sp-=?)
|
||||
indexOf("=") -> retrieve src and dst
|
||||
indexOf(":") -> unknown esil, raw opcode ahead
|
||||
indexOf("$") -> accesses internal esil vm flags
|
||||
indexOf("$") -> syscall
|
||||
indexOf("$$") -> can trap
|
||||
indexOf('++') -> has iterator
|
||||
indexOf('--') -> count to zero
|
||||
indexOf("?{") -> conditional
|
||||
indexOf("LOOP") -> is a loop (rep?)
|
||||
equalsTo("") -> empty string, means: nop (wrong, if we append pc+=x)
|
||||
|
||||
Common operations:
|
||||
|
||||
* Check dstreg
|
||||
* Check srcreg
|
||||
* Get destinaion
|
||||
|
|
@ -100,11 +112,16 @@ Common operations:
|
|||
|
||||
CPU Flags
|
||||
=========
|
||||
|
||||
CPU flags are usually defined as 1 bit registers in the RReg profile. and sometimes under the 'flg' register type.
|
||||
|
||||
ESIL Flags
|
||||
==========
|
||||
ESIL VM have an internal state flags that can are read only and can be used to export those values to the underlaying CPU flags. This is because the ESIL vm defines all the flag changes, while the CPUs only update the flags under certain conditions or specific instructions.
|
||||
|
||||
ESIL VM have an internal state flags that can are read only and can be used to
|
||||
export those values to the underlaying CPU flags. This is because the ESIL vm
|
||||
defines all the flag changes, while the CPUs only update the flags under
|
||||
certain conditions or specific instructions.
|
||||
|
||||
Those internal flags are prefixed by the '$' character.
|
||||
|
||||
|
|
@ -118,6 +135,7 @@ r - regsize ( asm.bits/8 )
|
|||
|
||||
Variables
|
||||
=========
|
||||
|
||||
1. No predefined bitness (should be easy to extend them to 128,256 and 512bits, e.g. for MMX, SSE, AVX, Neon)
|
||||
2. Infinite number (for SSA-form compatibility)
|
||||
3. Register names have no specific syntax. They are just strings
|
||||
|
|
@ -155,35 +173,41 @@ _TODO_
|
|||
|
||||
The x86 REP prefix in ESIL
|
||||
==========================
|
||||
ESIL specifies that the parsing control-flow commands are in uppercase. Bear in mind that some archs have uppercase register names. The register profile should take care to not reuse any of the following:
|
||||
```
|
||||
3,SKIP - skip N instructions. used to make relative forward GOTOs
|
||||
3,GOTO - goto instruction 3
|
||||
LOOP - alias for 0,GOTO
|
||||
BREAK - stop evaluating the expression
|
||||
STACK - dump stack contents to screen
|
||||
CLEAR - clear stack
|
||||
```
|
||||
|
||||
ESIL specifies that the parsing control-flow commands are in uppercase. Bear in
|
||||
mind that some archs have uppercase register names. The register profile should
|
||||
take care to not reuse any of the following:
|
||||
|
||||
3,SKIP - skip N instructions. used to make relative forward GOTOs
|
||||
3,GOTO - goto instruction 3
|
||||
LOOP - alias for 0,GOTO
|
||||
BREAK - stop evaluating the expression
|
||||
STACK - dump stack contents to screen
|
||||
CLEAR - clear stack
|
||||
|
||||
|
||||
Usage example:
|
||||
|
||||
rep cmpsb
|
||||
---------
|
||||
cx,!,?{,BREAK,},esi,[1],edi,[1],==,?{,BREAK,},esi,++,edi,++,cx,--,LOOP
|
||||
|
||||
cx,!,?{,BREAK,},esi,[1],edi,[1],==,?{,BREAK,},esi,++,edi,++,cx,--,LOOP
|
||||
|
||||
|
||||
Unimplemented/unhandled instructions
|
||||
====================================
|
||||
Those are expressed with the 'TODO' command. which acts as a 'BREAK', but displaying a warning message describing which instruction is not implemented and will not be emulated.
|
||||
|
||||
Those are expressed with the 'TODO' command. which acts as a 'BREAK', but
|
||||
displaying a warning message describing which instruction is not implemented
|
||||
and will not be emulated.
|
||||
|
||||
For example:
|
||||
```
|
||||
fmulp ST(1), ST(0) => TODO,fmulp ST(1),ST(0)
|
||||
```
|
||||
|
||||
fmulp ST(1), ST(0) => TODO,fmulp ST(1),ST(0)
|
||||
|
||||
Disassembly example:
|
||||
====================
|
||||
|
||||
```
|
||||
[0x1000010f8]> e asm.esil=true
|
||||
[0x1000010f8]> pd $r @ entry0
|
||||
|
|
@ -215,46 +239,55 @@ Disassembly example:
|
|||
Radare anal ESIL code example
|
||||
==============================
|
||||
|
||||
As an example implementation of ESIL analysis for the AVR family of microcontrollers there is
|
||||
a `avr_op` function in `/libr/anal/p/anal_avr.c` which contains information on how the
|
||||
instructions are expressed in ESIL and other opcode information such as cycle counts per instruction:
|
||||
As an example implementation of ESIL analysis for the AVR family of
|
||||
microcontrollers there is a `avr_op` function in `/libr/anal/p/anal_avr.c`
|
||||
which contains information on how the instructions are expressed in ESIL and
|
||||
other opcode information such as cycle counts per instruction:
|
||||
|
||||
````
|
||||
static int avr_op(RAnal *anal, RAnalOp *op, ut64 addr, const ut8 *buf, int len) {
|
||||
short ofst;
|
||||
int d, r, k;
|
||||
(...)
|
||||
short ofst;
|
||||
int d, r, k;
|
||||
(...)
|
||||
````
|
||||
|
||||
Variables d, r and k refer to "destination", "register" and "(k)onstant", respectively. They
|
||||
are used later on by ESIL string formatting function like for instance:
|
||||
|
||||
r_strbuf_setf (&op->esil, "0x%x,r%d,=", k, d);
|
||||
|
||||
Which in this case corresponds to the LDI (LoaD with immediate) instruction in AVR. As an example,
|
||||
the above ESIL string template will translate into the following when reversing in radare:
|
||||
Which in this case corresponds to the LDI (LoaD with immediate) instruction in
|
||||
AVR. As an example, the above ESIL string template will translate into the
|
||||
following when reversing in radare:
|
||||
|
||||
│ 0x00000080 30e0 0x0,r19,= ; LDI Rd,K. load immediate
|
||||
0x00000080 30e0 0x0,r19,= ; LDI Rd,K. load immediate
|
||||
|
||||
Or in non-ESIL format:
|
||||
|
||||
│ 0x00000080 30e0 ldi r19, 0x00 ; LDI Rd,K. load immediate
|
||||
0x00000080 30e0 ldi r19, 0x00 ; LDI Rd,K. load immediate
|
||||
|
||||
|
||||
Looking at other architectures which already have mature ESIL support such as x86 can help
|
||||
in understanding the syntax and conventions of radare's ESIL.
|
||||
Looking at other architectures which already have mature ESIL support such as
|
||||
x86 can help in understanding the syntax and conventions of radare's ESIL.
|
||||
|
||||
|
||||
Introspection
|
||||
=============
|
||||
To ease esil parsing we should have a way to express introspection expressions to extract the data we want. For example. We want to get the target address of a jmp.
|
||||
|
||||
The parser for the esil expressions should be implemented in an API to make it possible to extract information by analyzing the expressions easily.
|
||||
To ease esil parsing we should have a way to express introspection expressions
|
||||
to extract the data we want. For example. We want to get the target address of
|
||||
a jmp.
|
||||
|
||||
```
|
||||
> ao~esil,opcode
|
||||
opcode: jmp 0x10000465a
|
||||
esil: 0x10000465a,rip,=
|
||||
```
|
||||
We need a way to retrieve the numeric value of 'rip'. This is a very simple example, but there will be more complex, like conditional ones and we need expressions to get:
|
||||
The parser for the esil expressions should be implemented in an API to make it
|
||||
possible to extract information by analyzing the expressions easily.
|
||||
|
||||
> ao~esil,opcode
|
||||
opcode: jmp 0x10000465a
|
||||
esil: 0x10000465a,rip,=
|
||||
|
||||
We need a way to retrieve the numeric value of 'rip'. This is a very simple
|
||||
example, but there will be more complex, like conditional ones and we need
|
||||
expressions to get:
|
||||
|
||||
- opcode type
|
||||
- destination of jump
|
||||
|
|
@ -265,23 +298,34 @@ We need a way to retrieve the numeric value of 'rip'. This is a very simple exam
|
|||
API HOOKS
|
||||
=========
|
||||
|
||||
It is important for emulation to be able to setup hooks in the parser, so we can extend the parser to implement the analysis without having to write the parser again and again. This is, every time an operation is going to be executed we call a user hook which can be used to determine if rip is changing or if the instruction updates the stack.
|
||||
Later, at this level we can split that callback into several ones to have an event based analysis api that may be extended in js like this:
|
||||
esil.on('regset', function(){..
|
||||
esil.on('syscall', function(){esil.regset('rip'
|
||||
It is important for emulation to be able to setup hooks in the parser, so we
|
||||
can extend the parser to implement the analysis without having to write the
|
||||
parser again and again. This is, every time an operation is going to be
|
||||
executed we call a user hook which can be used to determine if rip is changing
|
||||
or if the instruction updates the stack.
|
||||
|
||||
we have already them. see hook_flag_read() hook_execute() hook_mem_read() ...
|
||||
Later, at this level we can split that callback into several ones to have an
|
||||
event based analysis api that may be extended in js like this:
|
||||
|
||||
return true if you want to override the action taken for a callback. for example. avoid mem reads in a region or mem writes to make all memory read only.
|
||||
esil.on('regset', function(){..
|
||||
esil.on('syscall', function(){esil.regset('rip'
|
||||
|
||||
return false or 0 if you want to trace esil expression parsing. aka emulation
|
||||
..
|
||||
we have already them. see `hook_flag_read()` `hook_execute()` `hook_mem_read()` ...
|
||||
|
||||
Other operations that require bindings to external functionalities to work. In this case r_ref and r_io. This must be defined when initializing the esil vm.
|
||||
* return true if you want to override the action taken for a callback. for
|
||||
example. avoid mem reads in a region or mem writes to make all memory read
|
||||
only.
|
||||
* return false or 0 if you want to trace esil expression parsing. aka emulation ..
|
||||
|
||||
Other operations that require bindings to external functionalities to work. In
|
||||
this case `r_ref` and `r_io`. This must be defined when initializing the esil vm.
|
||||
|
||||
* Io Get/Set
|
||||
Out ax, 44
|
||||
44,ax,:ou
|
||||
|
||||
Out ax, 44
|
||||
44,ax,:ou
|
||||
|
||||
* Selectors (cs,ds,gs...)
|
||||
Mov eax, ds:[ebp+8]
|
||||
Ebp,8,+,:ds,eax,=
|
||||
|
||||
Mov eax, ds:[ebp+8]
|
||||
Ebp,8,+,:ds,eax,=
|
||||
|
|
@ -1,5 +1,6 @@
|
|||
FLIRT
|
||||
=====
|
||||
|
||||
At the moment of writing r2 supports loading and finding FLIRT
|
||||
patterns, those files can be generated with the FLIRT tools from IDA.
|
||||
R2 doesn't yet supports creating those files. But it supports its
|
||||
|
|
@ -14,9 +15,7 @@ it is not possible to redistribute the .pat or the .sig files. It
|
|||
doesn't seems to have watermarks. However it's a bit unclear what
|
||||
licence the file generated should have. Mentioning the files should
|
||||
be free of copyrighted material (the original libs bytes). That said,
|
||||
there's a paragraph in the flirt paper:
|
||||
|
||||
https://www.hex-rays.com/products/ida/tech/flirt/in_depth.shtml
|
||||
there's a paragraph in [IDA F.L.I.R.T. Technology: In-Depth](https://www.hex-rays.com/products/ida/tech/flirt/in_depth.shtml)
|
||||
|
||||
|
||||
Create the .pat file
|
||||
|
|
@ -39,11 +38,10 @@ conflicts. Prepend a '+' on the lines you're sure you want to keep
|
|||
Using it with r2:
|
||||
-----------------
|
||||
|
||||
$ r2 -c 'zF libc.sig' staticbin
|
||||
|
||||
PROFIT.
|
||||
r2 -c 'zF libc.sig' staticbin
|
||||
|
||||
refs:
|
||||
flair/sigmake.txt
|
||||
flair/pat.txt
|
||||
|
||||
* flair/sigmake.txt
|
||||
* flair/pat.txt
|
||||
|
||||
|
|
@ -11,32 +11,32 @@ FreeBSD, as well as other BSD systems have some differences in the way commands
|
|||
Radare2 Dependencies:
|
||||
---------------------
|
||||
|
||||
# pkg install git gcc gmake patch pkgconf
|
||||
sudo pkg install git gcc gmake patch pkgconf
|
||||
|
||||
$ git clone https://github.com/radare/radare2
|
||||
$ cd radare2
|
||||
$ sys/install.sh /usr/local
|
||||
git clone https://github.com/radare/radare2
|
||||
cd radare2
|
||||
sys/install.sh /usr/local
|
||||
|
||||
Python Swig Bindings Dependencies:
|
||||
----------------------------------
|
||||
|
||||
# pkg install swig30 pkgconf vala
|
||||
sudo pkg install swig30 pkgconf vala
|
||||
|
||||
$ git clone https://github.com/radare/valabind
|
||||
$ cd valabind
|
||||
$ gmake
|
||||
$ sudo gmake install PREFIX=/usr/local
|
||||
git clone https://github.com/radare/valabind
|
||||
cd valabind
|
||||
gmake
|
||||
sudo gmake install PREFIX=/usr/local
|
||||
|
||||
Building Python Swig Bindings:
|
||||
------------------------------
|
||||
|
||||
$ git clone https://github.com/radare/radare2-bindings
|
||||
$ cd radare2-bindings
|
||||
$ export CC=cc
|
||||
$ export CXX=c++
|
||||
$ export SWIG=swig3.0
|
||||
$ export PKG_CONFIG_PATH=/usr/local/lib/pkgconfig
|
||||
$ ./configure --prefix=/usr/local
|
||||
$ cd python
|
||||
$ gmake CC=$CC CXX=$CXX
|
||||
$ sudo gmake install
|
||||
git clone https://github.com/radare/radare2-bindings
|
||||
cd radare2-bindings
|
||||
export CC=cc
|
||||
export CXX=c++
|
||||
export SWIG=swig3.0
|
||||
export PKG_CONFIG_PATH=/usr/local/lib/pkgconfig
|
||||
./configure --prefix=/usr/local
|
||||
cd python
|
||||
gmake CC=$CC CXX=$CXX
|
||||
sudo gmake install
|
||||
|
|
|
|||
|
|
@ -3,12 +3,14 @@ Connecting r2 with gdb
|
|||
|
||||
Running gdbserver
|
||||
-----------------
|
||||
$ gdbserver :2345 /bin/ls
|
||||
(gdb) target remote localhost:2345
|
||||
|
||||
$ gdbserver :2345 /bin/ls
|
||||
(gdb) target remote localhost:2345
|
||||
|
||||
Connecting from r2
|
||||
------------------
|
||||
$ r2 -D gdb gdb://127.0.0.1:2345
|
||||
|
||||
$ r2 -D gdb gdb://127.0.0.1:2345
|
||||
|
||||
|
||||
Supported implementations
|
||||
|
|
@ -26,34 +28,37 @@ r2 have support for connecting to remote GDB instances:
|
|||
|
||||
Supported Commands
|
||||
------------------
|
||||
|
||||
- read/write memory
|
||||
|
||||
Writing or reading memory is implemented through the m/M packet.
|
||||
Writing or reading memory is implemented through the m/M packet.
|
||||
|
||||
- read registers
|
||||
|
||||
Reading registers is currently implemented through the <g> packet of the gdb protocol.
|
||||
It returns the whole register profile at once.
|
||||
Reading registers is currently implemented through the <g> packet of the gdb protocol.
|
||||
It returns the whole register profile at once.
|
||||
|
||||
- write registers
|
||||
|
||||
There are two ways of writing registers. The first one is through the P packet.
|
||||
It works like this: `P<register_index>=<register_value>`
|
||||
The second one is the G packet, that writes the whole register Profile at once.
|
||||
The implementation first tries to use the newer P packet and if it receives a $00# packet (that says not implemented), it tries to write through the G packet.
|
||||
There are two ways of writing registers. The first one is through the P packet.
|
||||
It works like this: `P<register_index>=<register_value>`
|
||||
The second one is the G packet, that writes the whole register Profile at once.
|
||||
The implementation first tries to use the newer P packet and if it receives a $00# packet (that says not implemented), it tries to write through the G packet.
|
||||
|
||||
- stepping (but this is still the softstep mode and for an unknown reason it sill does not call th gdb_write_register function)
|
||||
|
||||
Supported Packets:
|
||||
- g : Reads the whole register Profile at once
|
||||
- G : Writes the whole register Profile at once
|
||||
- m : Reads memory
|
||||
- M : Writes memory
|
||||
- vCont,v : continues execution of the binary
|
||||
- P : Write one register
|
||||
|
||||
- `g` : Reads the whole register Profile at once
|
||||
- `G` : Writes the whole register Profile at once
|
||||
- `m` : Reads memory
|
||||
- `M` : Writes memory
|
||||
- `vCont,v` : continues execution of the binary
|
||||
- `P` : Write one register
|
||||
|
||||
TODO
|
||||
----
|
||||
|
||||
- Implement GDBserver to allow other apps use r2 debugger
|
||||
- Fix that usese the gdb internal stepping version
|
||||
- Fix softstep, that it finally recoils correct (it just have to reset the eip/rip)
|
||||
|
|
@ -3,14 +3,14 @@ r2 for Haiku
|
|||
|
||||
To compile for Haiku run configure in this way:
|
||||
|
||||
> HOST_CC=gcc-x86 CC=gcc-x86 ./configure --with-ostype=haiku --prefix=/boot/home/Apps/radare2
|
||||
HOST_CC=gcc-x86 CC=gcc-x86 ./configure --with-ostype=haiku --prefix=/boot/home/Apps/radare2
|
||||
|
||||
And then..
|
||||
|
||||
> HOST_CC=gcc-x86 make
|
||||
> make install
|
||||
> mv /boot/home/Apps/radare2/bin/* /boot/home/Apps/radare2/
|
||||
> rmdir /boot/home/Apps/radare2/bin/
|
||||
HOST_CC=gcc-x86 make
|
||||
make install
|
||||
mv /boot/home/Apps/radare2/bin/* /boot/home/Apps/radare2/
|
||||
rmdir /boot/home/Apps/radare2/bin/
|
||||
|
||||
To install r2-bindings you will need to install r2, valac, valabind and swig
|
||||
and copy/link libs to radare2/lib
|
||||
|
|
@ -1,49 +0,0 @@
|
|||
r_io/r_core-file fixing
|
||||
=======================
|
||||
|
||||
Conceptual things:
|
||||
------------------
|
||||
-in general only code from r_io should be used for io related stuff, io is NOT a core-task
|
||||
-wrappers are ok, but no re-implementations (there might be exceptions but those must be reasonable argued)
|
||||
-linkage is not argument -> use RIOBind
|
||||
-esil-custom reads and writes should use RIOBind too
|
||||
-if a file gets opened a RIODesc MUST be created
|
||||
-if a file gets opened in usual cases a RIOMap MUST be created
|
||||
-if a file gets opened in unsusual cases it's not necessary to create a RIOMap
|
||||
-if no RIOMap was created for a fd reading and writing from and to this fd is only possible via r_io_pread and r_io_pwrite
|
||||
-this is only an option if only 1 file can be opened for a task or if the fd will never see the user-land
|
||||
-Rahash2 for example won't need creating a RIOMap
|
||||
-if a file gets closed all RIOMaps for that belong to the fd MUST get destroyed
|
||||
-if a file gets closed the RIODesc MUST get destroyed
|
||||
-the cores primary task is to delegate the different parts of r2
|
||||
-creating a new RIOMap or RIODesc on file-opening is NOT a core-task
|
||||
-the same goes for destroying RIOMaps and RIODesc on closing a file
|
||||
-there is no need for a map-list in the core directly. core->io->maps is the only list to store maps (for the long run, functions that return a list with maps are ok)
|
||||
|
||||
Documentation:
|
||||
--------------
|
||||
There is no need for a huge documentation!!! But code with fundamental importance often needs a few lines on what it should do, its concept
|
||||
and sometimes a few lines of the code itself need some kind of 'justification' or explanation. libr/io/vio.c is a hardcore example for this
|
||||
RIO-code has fundamental importance, because everything will fail if io does not work correctly.
|
||||
This is needed to make bug-fixing easier, faster and better.
|
||||
|
||||
Need review:
|
||||
------------
|
||||
libr/io/io.c
|
||||
libr/core/file.c
|
||||
|
||||
Tasks:
|
||||
------
|
||||
-we should fix all the tests before doing this.
|
||||
-talk about ioneg
|
||||
-remove re-implemtations of r_io (middle)
|
||||
-implement r_io_open_at (easy) ; this should open a file, add a RIODesc and a RIOMap that maps the file to an offset that is passed as an arg
|
||||
-make r_io_open creating a new map (easy) ; this should open a file, add a RIODesc and a RIOMap that maps the file to 0
|
||||
-this means cleaning up r_core_file_open too (hard?)
|
||||
-implement r_io_open_no_map (easy) ; this should open a file and add a RIODesc. the file can only be accessed via r_io_pread and r_io_pwrite
|
||||
-make r_io_close destroy all maps that belong to the file that should be closed (easy)
|
||||
-this means cleaning up r_core_file_close too (hard?)
|
||||
-implement r_io_mwrite (hard); this should find all maps in a certain range, resolve their fds, RIODescs and paddr and then call pwrite
|
||||
-implement r_io_vwrite (hard); this should find all sections in a certain range, resolve the maddr that belongs to a vaddr and call mwrite, unsectioned area should be passed directly to mwrite
|
||||
-implement r_io_reopen (easy); keep the maps for a fd and reopen it, possibly with different permissions
|
||||
-this means cleaning up r_core_file_reopen too (hard?)
|
||||
|
|
@ -0,0 +1,55 @@
|
|||
`r_io/r_core-file` fixing
|
||||
=======================
|
||||
|
||||
Conceptual things:
|
||||
------------------
|
||||
|
||||
- in general only code from `r_io` should be used for io related stuff, io is NOT a core-task
|
||||
- wrappers are ok, but no re-implementations (there might be exceptions but those must be reasonable argued)
|
||||
- linkage is not argument -> use RIOBind
|
||||
- esil-custom reads and writes should use RIOBind too
|
||||
- if a file gets opened a RIODesc MUST be created
|
||||
- if a file gets opened in usual cases a RIOMap MUST be created
|
||||
- if a file gets opened in unsusual cases it's not necessary to create a RIOMap
|
||||
- if no RIOMap was created for a fd reading and writing from and to this fd is only possible via `r_io_pread` and `r_io_pwrite`
|
||||
- this is only an option if only 1 file can be opened for a task or if the fd will never see the user-land
|
||||
- Rahash2 for example won't need creating a RIOMap
|
||||
- if a file gets closed all RIOMaps for that belong to the fd MUST get destroyed
|
||||
- if a file gets closed the RIODesc MUST get destroyed
|
||||
- the cores primary task is to delegate the different parts of r2
|
||||
- creating a new RIOMap or RIODesc on file-opening is NOT a core-task
|
||||
- the same goes for destroying RIOMaps and RIODesc on closing a file
|
||||
- there is no need for a map-list in the core directly. core->io->maps is the only list to store maps (for the long run, functions that return a list with maps are ok)
|
||||
|
||||
Documentation:
|
||||
--------------
|
||||
|
||||
There is no need for a huge documentation!!! But code with fundamental
|
||||
importance often needs a few lines on what it should do, its concept and
|
||||
sometimes a few lines of the code itself need some kind of 'justification' or
|
||||
explanation. libr/io/vio.c is a hardcore example for this RIO-code has
|
||||
fundamental importance, because everything will fail if io does not work
|
||||
correctly. This is needed to make bug-fixing easier, faster and better.
|
||||
|
||||
Need review:
|
||||
------------
|
||||
|
||||
libr/io/io.c
|
||||
libr/core/file.c
|
||||
|
||||
Tasks:
|
||||
------
|
||||
|
||||
- we should fix all the tests before doing this.
|
||||
- talk about ioneg
|
||||
- remove re-implemtations of `r_io` (middle)
|
||||
- implement `r_io_open_at` (easy) ; this should open a file, add a RIODesc and a RIOMap that maps the file to an offset that is passed as an arg
|
||||
- make `r_io_open` creating a new map (easy) ; this should open a file, add a RIODesc and a RIOMap that maps the file to 0
|
||||
- this means cleaning up `r_core_file_open` too (hard?)
|
||||
- implement `r_io_open_no_map` (easy) ; this should open a file and add a RIODesc. the file can only be accessed via `r_io_pread` and `r_io_pwrite`
|
||||
- make `r_io_close` destroy all maps that belong to the file that should be closed (easy)
|
||||
- this means cleaning up `r_core_file_close` too (hard?)
|
||||
- implement (hard); this should find all maps in a certain range, resolve their fds, RIODescs and paddr and then call pwrite
|
||||
- implement (hard); this should find all sections in a certain range, resolve the maddr that belongs to a vaddr and call mwrite, unsectioned area should be passed directly to mwrite
|
||||
- implement `r_io_reopen` (easy); keep the maps for a fd and reopen it, possibly with different permissions
|
||||
- this means cleaning up `r_core_file_reopen` too (hard?)
|
||||
|
|
@ -3,11 +3,11 @@ How IO should work
|
|||
|
||||
* Maps
|
||||
|
||||
Used to select fd. Mapaddr..size
|
||||
Used to select fd. Mapaddr..size
|
||||
|
||||
* Sections
|
||||
|
||||
Used to specify vaddr<->paddr
|
||||
Used to specify vaddr<->paddr
|
||||
|
||||
Manually selecting fd is still valid and it should override maps fdselection. This is.. We need a way to tell r2 to view one fd or all of them. In case of having two files mapped on the same address space we will select the last opened.
|
||||
|
||||
|
|
@ -8,9 +8,9 @@ Compilation
|
|||
|
||||
There are different ways to build r2 for iOS, use the sys/ script you need:
|
||||
|
||||
* sys/ios-cydia.sh
|
||||
* sys/ios-static.sh
|
||||
* sys/ios-simulator.sh
|
||||
* `sys/ios-cydia.sh`
|
||||
* `sys/ios-static.sh`
|
||||
* `sys/ios-simulator.sh`
|
||||
|
||||
It is also possible to build r2 natively on your iDevice by following the standard `./configure ; make ; make install` steps. But if you own a Mac is better to use the XCode toolchain to get better build times.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,15 +1,15 @@
|
|||
Crosscompiling from OSX:
|
||||
========================
|
||||
|
||||
export PATH=/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin:$PATH
|
||||
export CC=`pwd`/sys/ios-sdk-gcc
|
||||
# set only for arm64, otherwise it is armv7
|
||||
export CPU=arm64
|
||||
# select ios sdk version
|
||||
export IOSVER=7.1
|
||||
./configure --prefix=/usr --with-ostype=darwin --with-compiler=ios-sdk --target=arm-unknown-darwin
|
||||
make -j4
|
||||
make install DESTDIR=/tmp/r2ios
|
||||
export PATH=/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin:$PATH
|
||||
export CC=`pwd`/sys/ios-sdk-gcc
|
||||
# set only for arm64, otherwise it is armv7
|
||||
export CPU=arm64
|
||||
# select ios sdk version
|
||||
export IOSVER=7.1
|
||||
./configure --prefix=/usr --with-ostype=darwin --with-compiler=ios-sdk --target=arm-unknown-darwin
|
||||
make -j4
|
||||
make install DESTDIR=/tmp/r2ios
|
||||
|
||||
|
||||
Natively compiling on iOS
|
||||
|
|
@ -19,31 +19,32 @@ SSH into your iDevice and run the following steps:
|
|||
|
||||
Setup SDK for ARMv6
|
||||
-------------------
|
||||
|
||||
1) Install 'APT 0.7 Strict' and OpenSSH packages from cydia.
|
||||
|
||||
apt-get coreutils install wget inetutils rsync git expat curl
|
||||
apt-get coreutils install wget inetutils rsync git expat curl
|
||||
|
||||
2) Download missing packages from lolcathost:
|
||||
|
||||
wget http://lolcathost.org/b/libgcc_4.2-20080410-1-6_iphoneos-arm.deb
|
||||
wget http://lolcathost.org/b/libSystem.dylib
|
||||
wget http://lolcathost.org/b/libgcc_4.2-20080410-1-6_iphoneos-arm.deb
|
||||
wget http://lolcathost.org/b/libSystem.dylib
|
||||
|
||||
3) Install them
|
||||
|
||||
dpkg -i libgcc_4.2-20080410-1-6_iphoneos-arm.deb
|
||||
apt-get install com.bigboss.20toolchain
|
||||
cp libSystem.dylib /usr/lib
|
||||
cd /usr/lib ; ln -sf libSystem.dylib libm.dylib
|
||||
apt-get install make vim gawk git
|
||||
dpkg -i libgcc_4.2-20080410-1-6_iphoneos-arm.deb
|
||||
apt-get install com.bigboss.20toolchain
|
||||
cp libSystem.dylib /usr/lib
|
||||
cd /usr/lib ; ln -sf libSystem.dylib libm.dylib
|
||||
apt-get install make vim gawk git
|
||||
|
||||
4) /var/include/sys/stat.h is broken.
|
||||
|
||||
Solution: add 'int foo[3];' after 'st_rdev' at line 178
|
||||
Solution: add 'int foo[3];' after 'st_rdev' at line 178
|
||||
|
||||
5) Get the varinclude tarball
|
||||
|
||||
wget lolcathost.org/b/varinclude.tar.gz
|
||||
tar xzvf varinclude.tar.gz -C /
|
||||
wget lolcathost.org/b/varinclude.tar.gz
|
||||
tar xzvf varinclude.tar.gz -C /
|
||||
|
||||
Compilation
|
||||
-----------
|
||||
|
|
|
|||
|
|
@ -82,6 +82,7 @@ Parsing
|
|||
Parsing is done by a state machine which reads the expression string and creates a keyvalue string that represents the ESIL instruction.
|
||||
|
||||
This is an example
|
||||
```
|
||||
switch (ch) {
|
||||
case '+':
|
||||
case '-':
|
||||
|
|
@ -93,3 +94,4 @@ This is an example
|
|||
}
|
||||
break;
|
||||
}
|
||||
```
|
||||
46
doc/macos.md
46
doc/macos.md
|
|
@ -25,29 +25,29 @@ After Mac OS X 10.6, binaries that need permissions to debug require to be signe
|
|||
|
||||
(Based on https://llvm.org/svn/llvm-project/lldb/trunk/docs/code-signing.txt)
|
||||
|
||||
- Launch /Applications/Utilities/Keychain Access.app
|
||||
- In Keychain Access select the "login" keychain in the "Keychains" list in the upper left hand corner of the window.
|
||||
- Select the following menu item:
|
||||
Keychain Access->Certificate Assistant->Create a Certificate...
|
||||
- Set the following settings
|
||||
Name = org.radare.radare2
|
||||
Identity Type = Self Signed Root
|
||||
Certificate Type = Code Signing
|
||||
- Click Create
|
||||
- Click Continue
|
||||
- Click Done
|
||||
- Click on the "My Certificates"
|
||||
- Double click on your new org.radare.radare2 certificate
|
||||
- Turn down the "Trust" disclosure triangle, scroll to the "Code Signing" trust pulldown menu and select "Always Trust" and authenticate as needed using your username and password.
|
||||
- Drag the new "org.radare.radare2" code signing certificate (not the public or private keys of the same name) from the "login" keychain to the "System" keychain in the Keychains pane on the left hand side of the main Keychain Access window. This will move this certificate to the "System" keychain. You'll have to authorize a few more times, set it to be "Always trusted" when asked.
|
||||
- In the Keychain Access GUI, click and drag "org.radare.radare2" in the "System" keychain onto the desktop. The drag will create a "~/Desktop/org.radare.radare2.cer" file used in the next step.
|
||||
- Switch to Terminal, and run the following:
|
||||
$ sudo security add-trust -d -r trustRoot -p basic -p codeSign -k /Library/Keychains/System.keychain ~/Desktop/org.radare.radare2.cer
|
||||
$ rm -f ~/Desktop/org.radare.radare2.cer
|
||||
- Drag the "org.radare.radare2" certificate from the "System" keychain back into the "login" keychain
|
||||
- Quit Keychain Access
|
||||
- Reboot
|
||||
- Run sys/install.sh (or follow the next steps if you want to install and sign radare2 manually)
|
||||
#. Launch /Applications/Utilities/Keychain Access.app
|
||||
#. In Keychain Access select the "login" keychain in the "Keychains" list in the upper left hand corner of the window.
|
||||
#. Select the following menu item:
|
||||
#. Keychain Access->Certificate Assistant->Create a Certificate...
|
||||
#. Set the following settings
|
||||
#. Name = org.radare.radare2
|
||||
#. Identity Type = Self Signed Root
|
||||
#. Certificate Type = Code Signing
|
||||
#. Click Create
|
||||
#. Click Continue
|
||||
#. Click Done
|
||||
#. Click on the "My Certificates"
|
||||
#. Double click on your new org.radare.radare2 certificate
|
||||
#. Turn down the "Trust" disclosure triangle, scroll to the "Code Signing" trust pulldown menu and select "Always Trust" and authenticate as needed using your username and password.
|
||||
#. Drag the new "org.radare.radare2" code signing certificate (not the public or private keys of the same name) from the "login" keychain to the "System" keychain in the Keychains pane on the left hand side of the main Keychain Access window. This will move this certificate to the "System" keychain. You'll have to authorize a few more times, set it to be "Always trusted" when asked.
|
||||
#. In the Keychain Access GUI, click and drag "org.radare.radare2" in the "System" keychain onto the desktop. The drag will create a "~/Desktop/org.radare.radare2.cer" file used in the next step.
|
||||
#. Switch to Terminal, and run the following:
|
||||
#. $ sudo security add-trust -d -r trustRoot -p basic -p codeSign -k /Library/Keychains/System.keychain ~/Desktop/org.radare.radare2.cer
|
||||
#. $ rm -f ~/Desktop/org.radare.radare2.cer
|
||||
#. Drag the "org.radare.radare2" certificate from the "System" keychain back into the "login" keychain
|
||||
#. Quit Keychain Access
|
||||
#. Reboot
|
||||
#. Run sys/install.sh (or follow the next steps if you want to install and sign radare2 manually)
|
||||
|
||||
As said before, the signing process can also be done manually following the next process. First, you will need to sign the radare2 binary:
|
||||
|
||||
|
|
|
|||
27
doc/maemo
27
doc/maemo
|
|
@ -1,27 +0,0 @@
|
|||
Build for maemo6 (Harmattan) N9 - N950
|
||||
========================================
|
||||
|
||||
* Install QtSDK
|
||||
|
||||
- http://qt.nokia.com/downloads/
|
||||
|
||||
* Configure mad (maemo development environment)
|
||||
|
||||
cd /usr/bin ; sudo ln -fs $HOME/QtSDK/Madde/bin/mad
|
||||
mad set harmattan-nokia-meego-api
|
||||
mad sh
|
||||
|
||||
* Compile
|
||||
|
||||
./configure --prefix=/usr --with-little-endian \
|
||||
--with-compiler=mad --with-ostype=gnulinux
|
||||
make
|
||||
|
||||
* Create the package
|
||||
|
||||
cd maemo
|
||||
make
|
||||
|
||||
* Install the package
|
||||
|
||||
dpkg -i radare2-*.deb
|
||||
|
|
@ -0,0 +1,27 @@
|
|||
Build for maemo6 (Harmattan) N9 - N950
|
||||
======================================
|
||||
|
||||
1. Install QtSDK
|
||||
|
||||
http://qt.nokia.com/downloads/
|
||||
|
||||
2. Configure mad (maemo development environment)
|
||||
|
||||
cd /usr/bin ; sudo ln -fs $HOME/QtSDK/Madde/bin/mad
|
||||
mad set harmattan-nokia-meego-api
|
||||
mad sh
|
||||
|
||||
3. Compile
|
||||
|
||||
./configure --prefix=/usr --with-little-endian \
|
||||
--with-compiler=mad --with-ostype=gnulinux
|
||||
make
|
||||
|
||||
4. Create the package
|
||||
|
||||
cd maemo
|
||||
make
|
||||
|
||||
5. Install the package
|
||||
|
||||
dpkg -i radare2-*.deb
|
||||
|
|
@ -12,12 +12,15 @@ following some sane and basic OO concepts.
|
|||
|
||||
Global picture
|
||||
--------------
|
||||
|
||||
```
|
||||
[Class]
|
||||
|
|
||||
|-- [Plugins] // shared among instances
|
||||
| \
|
||||
| \
|
||||
`------> [Instance] ----> [Liberation]
|
||||
```
|
||||
|
||||
* We need a construction/destruction API for plugins among instances
|
||||
- simplify code
|
||||
|
|
@ -29,7 +32,8 @@ Plugins are singletons. Or we will have to create factories for every class.
|
|||
|
||||
Lifecycle of the class
|
||||
----------------------
|
||||
Class
|
||||
|
||||
Class
|
||||
- new
|
||||
- as_new
|
||||
- init
|
||||
|
|
@ -7,7 +7,7 @@ Libraries can be compiled:
|
|||
- as shared libraries (so, dylib, dll) (DEFAULT)
|
||||
- as static libraries (a, lib, ..)
|
||||
|
||||
./configure-plugins --enable-shared --enable-dynamic
|
||||
./configure-plugins --enable-shared --enable-dynamic
|
||||
|
||||
LIBR_PLUGINS environment variable is honored as another search path for plugins
|
||||
|
||||
|
|
@ -16,8 +16,8 @@ Plugins can be:
|
|||
- compiled as shared
|
||||
- compiled as static (inside the related library)
|
||||
|
||||
libr/plugins/shared
|
||||
libr/plugins/static
|
||||
libr/plugins/shared
|
||||
libr/plugins/static
|
||||
|
||||
the configure-plugins script will regenerate the required Makefiles
|
||||
to build this stuff as defined.
|
||||
9
doc/qnx
9
doc/qnx
|
|
@ -1,9 +0,0 @@
|
|||
r2 on android
|
||||
=============
|
||||
|
||||
. ./bbndk-env.sh
|
||||
cd ~/radare2
|
||||
rm -f plugins.cfg
|
||||
./configure --with-compiler=qnx --with-ostype=qnx --prefix=/accounts/devuser/radare2 --without-pic --with-nonpic
|
||||
make -j 4
|
||||
|
||||
|
|
@ -0,0 +1,11 @@
|
|||
r2 on android
|
||||
=============
|
||||
|
||||
```
|
||||
. ./bbndk-env.sh
|
||||
cd ~/radare2
|
||||
rm -f plugins.cfg
|
||||
./configure --with-compiler=qnx --with-ostype=qnx --prefix=/accounts/devuser/radare2 --without-pic --with-nonpic
|
||||
make -j 4
|
||||
```
|
||||
|
||||
|
|
@ -3,12 +3,12 @@ RAPATCH
|
|||
|
||||
Human friendly text format to apply patches to binary files.
|
||||
|
||||
|
||||
Patch format
|
||||
------------
|
||||
|
||||
Those patches must be written in files and the syntax looks like the following:
|
||||
|
||||
```
|
||||
^# -> comments
|
||||
. -> execute command
|
||||
! -> execute command
|
||||
|
|
@ -17,14 +17,16 @@ OFFSET "string"
|
|||
OFFSET 01020304
|
||||
OFFSET : assembly
|
||||
+ {code}|"str"|0210|: asm
|
||||
```
|
||||
|
||||
Example scripts
|
||||
---------------
|
||||
This script will run the '?e ..' command in r2 and then write the string 'Hello' at 0x200 offset
|
||||
|
||||
# rapatch example
|
||||
:?e hello world
|
||||
0x200 "Hello"
|
||||
This script will run the `?e ..` command in r2 and then write the string 'Hello' at 0x200 offset
|
||||
```
|
||||
# rapatch example
|
||||
:?e hello world
|
||||
0x200 "Hello"
|
||||
```
|
||||
|
||||
Running rapatches
|
||||
-----------------
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
radare2 releasing rules
|
||||
Releasing rules
|
||||
=======================
|
||||
|
||||
The objective of this paper is to determine a set of rules to be done before
|
||||
|
|
@ -15,7 +15,7 @@ Before any release we have to:
|
|||
- Remove warnings
|
||||
|
||||
We dont want to fall in the warning nightmare of r1. Releases should contain
|
||||
no warnings with gcc -Wall or at least no dangerous ones.
|
||||
no warnings with `gcc -Wall` or at least no dangerous ones.
|
||||
|
||||
- Sync Vala APIs
|
||||
|
||||
|
|
@ -34,7 +34,7 @@ Before any release we have to:
|
|||
|
||||
The same codebase should be compilable on *nix and w32 systems without
|
||||
modifications. It should be also possible to build it with make threads,
|
||||
so using quadcore boxes with -j8 should be a good place for finding
|
||||
so using quadcore boxes with `-j8` should be a good place for finding
|
||||
race conditions in the build system.
|
||||
|
||||
- Remove commented code and review TODO/BUG/XXX comments
|
||||
|
|
@ -44,7 +44,7 @@ Before any release we have to:
|
|||
while refactoring code or re-doing-it from scratch. This code, should be
|
||||
reviewed and removed if necessary.
|
||||
|
||||
$ grep -r -e TODO -e XXX -e FIX libr
|
||||
$ grep -r -e TODO -e XXX -e FIX libr
|
||||
|
||||
- Graph per symbol-module dependency graph to identify unused/dupped/-
|
||||
simplificable use cases of the API for every module.
|
||||
|
|
@ -1,6 +1,7 @@
|
|||
Not-much-updated graph of relationships between the libr APIs
|
||||
=============================================================
|
||||
|
||||
```
|
||||
+--------+
|
||||
.-| config |
|
||||
/ +--------+
|
||||
|
|
@ -19,3 +20,4 @@ Not-much-updated graph of relationships between the libr APIs
|
|||
| plugins | +---------------+ |
|
||||
+-----.---+ |
|
||||
`---------------------------'
|
||||
```
|
||||
|
|
@ -3,10 +3,14 @@ ORACLE SOLARIS NOTES
|
|||
|
||||
Packages you need:
|
||||
------------------
|
||||
```
|
||||
pkg install gcc-3 gmake
|
||||
```
|
||||
|
||||
To compile it:
|
||||
--------------
|
||||
```
|
||||
./configure --without-debugger --without-gmp
|
||||
gmake
|
||||
gmake install
|
||||
```
|
||||
|
|
@ -5,17 +5,21 @@ TODO: explain bin.minstr
|
|||
|
||||
Config vars
|
||||
-----------
|
||||
```
|
||||
bin.strings = [true] - load strings from file
|
||||
bin.rawstr = [false] - load strings from unknown rbin
|
||||
```
|
||||
|
||||
Program args
|
||||
------------
|
||||
```
|
||||
rabin2 -z # list strings
|
||||
rabin2 -zz # list strings from raw binary (unknown rbin type)
|
||||
```
|
||||
|
||||
Examples
|
||||
--------
|
||||
|
||||
```
|
||||
r2 -e bin.rawstr=true
|
||||
r2 -z # do not load strings (same as bin.strings=false)
|
||||
r2 -zz # load strings even if unknown bin (same as bin.rawstr=true)
|
||||
|
|
@ -29,4 +33,5 @@ if (bin.strings) {
|
|||
loadStrings()
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
|
|
@ -13,37 +13,37 @@ which happens every 6 weeks. So in this case, as long as it's supposed to run on
|
|||
it is ok to just install the package from Termux unless you really want to track git master or
|
||||
develop for this platform.
|
||||
|
||||
$ apt install radare2
|
||||
sudo apt install radare2
|
||||
|
||||
Building from git
|
||||
-----------------
|
||||
|
||||
The packages required to build are:
|
||||
|
||||
$ apt install git make patch clang
|
||||
sudo apt install git make patch clang
|
||||
|
||||
Now you can clone the repo and build:
|
||||
|
||||
$ git clone --depth 1 https://github.com/radare/radare2
|
||||
$ cd radare2
|
||||
$ sys/termux.sh
|
||||
git clone --depth 1 https://github.com/radare/radare2
|
||||
cd radare2
|
||||
sys/termux.sh
|
||||
|
||||
Building with meson
|
||||
-------------------
|
||||
|
||||
If you want to build with meson:
|
||||
|
||||
$ apt install python
|
||||
$ pip install meson
|
||||
$ r2pm -i ninja
|
||||
sudo apt install python
|
||||
sudo pip install meson
|
||||
sudo r2pm -i ninja
|
||||
|
||||
And then you can run the build:
|
||||
|
||||
$ make meson
|
||||
make meson
|
||||
|
||||
To install:
|
||||
|
||||
$ make meson-symstall PREFIX=/data/data/com.termux/files/usr
|
||||
make meson-symstall PREFIX=/data/data/com.termux/files/usr
|
||||
|
||||
Updating
|
||||
--------
|
||||
|
|
@ -52,7 +52,7 @@ To update the repo and rebuild you can do a full and clean rebuild by just runni
|
|||
or opt for typing `make` or `make meson` and it will just build what has changed, is something
|
||||
fails please do a clean build like this:
|
||||
|
||||
$ git reset --hard
|
||||
$ git clean -xdf
|
||||
$ sys/termux.sh
|
||||
git reset --hard
|
||||
git clean -xdf
|
||||
sys/termux.sh
|
||||
|
||||
|
|
|
|||
|
|
@ -11,8 +11,6 @@ just an initial implementation which will get better in time.
|
|||
It is also possible to use the remote GDB interface to connect and
|
||||
debug Windows kernels without depending on Windows capabilities.
|
||||
|
||||
------8<--------------8<------------------8<------------------------
|
||||
|
||||
Enable WinDBG support on Windows Vista and higher like this:
|
||||
|
||||
bcdedit /debug on
|
||||
|
|
@ -4,13 +4,12 @@ Yara plugin
|
|||
Preliminary documentation on yara can be found here:
|
||||
[Yara User's Manual](https://b161268c3bf5a87bc67309e7c870820f5f39f672.googledrive.com/host/0BznOMqZ9f3VUek8yN3VvSGdhRFU/YARA-Manual.pdf)
|
||||
|
||||
The following is 'YARA in a nutshell' from this document:
|
||||
The following is [YARA in a nutshell](https://virustotal.github.io/yara/) from this document:
|
||||
|
||||
> YARA is a tool aimed at helping malware researchers to identify and classify malware
|
||||
families. With YARA you can create descriptions of malware families based on textual or
|
||||
binary information contained on samples of those families. These descriptions, a.k.a rules,
|
||||
consist patterns and a boolean expression which determines its
|
||||
logic. Rules can be
|
||||
consist patterns and a boolean expression which determines its logic. Rules can be
|
||||
applied to files or running processes in order to determine if it belongs to the described
|
||||
malware family.
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue