Skip to content

Commit

Permalink
Merge branch 'master' into doc-env-vars
Browse files Browse the repository at this point in the history
  • Loading branch information
wargio authored Dec 4, 2024
2 parents c0b2bfc + 1a9b7b7 commit d4f35c5
Show file tree
Hide file tree
Showing 121 changed files with 3,699 additions and 3,007 deletions.
1 change: 0 additions & 1 deletion _quarto.yml
Original file line number Diff line number Diff line change
Expand Up @@ -51,7 +51,6 @@ book:
- src/basic_commands/print_modes.md
- src/basic_commands/flags.md
- src/basic_commands/write.md
- src/basic_commands/zoom.md
- src/basic_commands/yank_paste.md
- src/basic_commands/comparing_bytes.md
- src/basic_commands/sdb.md
Expand Down
34 changes: 34 additions & 0 deletions examples/hello_world/hello_world.c
Original file line number Diff line number Diff line change
@@ -0,0 +1,34 @@
#include <stdio.h>
#include <stdlib.h>
#include <string.h>

/*
* This is simple hello_world program made for education purposes.
* Licensed under CC-BY-SA 4.0 license.
*
* In order to compile executable run:
*
* gcc -o hello_world hello_world.c
*
*/

int main(int argc, char* argv[])
{
const char *str1 = "Hello ";
const char *str2 = "world!";

size_t str1_size = strlen(str1);
size_t str2_size = strlen(str2);

char *output = malloc(str1_size + str2_size + 1);
if (output)
{
strcpy(output, str1);
strcat(output, str2);

puts(output);
free(output);
}

return 0;
}
29 changes: 8 additions & 21 deletions src/analysis/calling_conventions.md
Original file line number Diff line number Diff line change
Expand Up @@ -5,42 +5,28 @@ It is used also as a guide for basic function prototype and type propagation.

```
[0x00000000]> afc?
Usage: afc[agl?]
| afc convention Manually set calling convention for current function
| afc Show Calling convention for the Current function
| afcr[j] Show register usage for the current function
| afca Analyse function for finding the current calling convention
| afcf[j] [name] Prints return type function(arg1, arg2...), see afij
| afck List SDB details of call loaded calling conventions
| afcl List all available calling conventions
| afco path Open Calling Convention sdb profile from the given path
| afcR Register telescoping using the calling conventions order
Usage: afc[lor] # Calling convention
| afc [<convention>] # Set/Get calling convention for current function
| afcl[j*kl] # List all available calling conventions
| afco <db_path> # Open Calling Convention sdb profile from given path
| afcr[j] # Show register usage for the current function
[0x00000000]>
```

To list all available calling conventions for current architecture using `afcl` command

```
[0x00000000]> afcl
swift
amd64
amd64syscall
ms
reg
swift
```

The default calling convention for a particular architecture/binary is defined with
`analysis.cc` for user-mode calls and `analysis.syscc` for syscalls.

To display a function prototype of standard library functions you have the `afcf` command

```
[0x00000000]> afcf printf
int printf(const char *format)
[0x00000000]> afcf fgets
char *fgets(char *s, int size, FILE *stream)
```

All this information is loaded via sdb under `/librz/analysis/d/cc-[arch]-[bits].sdb`

```
Expand All @@ -58,6 +44,7 @@ cc.ms.ret=rax

`cc.x.argi=rax` is used to set the ith argument of this calling convention to register name `rax`

`cc.x.argn=stack` means that all the arguments (or the rest of them in case there was `argi` for any `i` as counting number) will be stored in the stack from left to right
`cc.x.argn=stack` means that all the arguments (or the rest of them in case there was `argi` for any `i` as
counting number) will be stored in the stack from left to right

`cc.x.argn=stack_rev` same as `cc.x.argn=stack` except for it means argument are passed right to left
440 changes: 242 additions & 198 deletions src/analysis/code_analysis.md

Large diffs are not rendered by default.

27 changes: 16 additions & 11 deletions src/analysis/cpu_platform_profiles.md
Original file line number Diff line number Diff line change
Expand Up @@ -5,7 +5,8 @@
The computer ecosystem, especially in embedded systems is vast and growing and is thus
diverse and is full of trivial differences. CPUs and development boards differ by minor and sometimes
large differences in their design, ports, MMIO registers and other peripherals. Rizin handles these
differences by storing the data regarding each CPUs and platforms in [SDB](https://book.rizin.re/basic_commands/sdb.html?highlight=SDB#sdb) files in a standard format, instead of hardcoding them with each of the
differences by storing the data regarding each CPUs and platforms in [SDB](../basic_commands/sdb.md)
files in a standard format, instead of hardcoding them with each of the
disassembler plugins. This information will be parsed and added as flags and comments during the analysis
loop and will show up in the disassembly and other places, making reverse engineering on those particular
chips ets is much easier. This also helps in easy addition of a new port, in maintenance and in user-friendliness.
Expand All @@ -15,9 +16,9 @@ chips ets is much easier. This also helps in easy addition of a new port, in mai
### CPU profiles

All the specifics pertaining to a CPU is written down in a CPU profile. It is designed in a way that allows you
to enter CPU specefic values like: size of the RAM (`RAM_SIZE`), size of the ROM (`ROM_SIZE`) and many more.
CPU profiles can be selected using the configuration variable `asm.cpu`. Firstly, Rizin checks whether the
a CPU profile exists for the selected CPU and architecture. If it exists, Rizin generates the filepath of the
to enter CPU specific values like: size of the RAM (`RAM_SIZE`), size of the ROM (`ROM_SIZE`) and many more.
CPU profiles can be selected using the configuration variable `asm.cpu`. Firstly, Rizin checks whether the CPU profile
exists for the selected CPU and architecture. If it exists, Rizin generates the filepath of the
profile and gets to a stage where it's ready to be loaded up. During analysis (`aa`), it's loaded up and the values are
parsed and handled. CPU profiles also allow you to add information regarding the IO and extended IO registers of a CPU.
The information pertaining to the IO and extended IO registers are added as flags at their corresponding offsets.
Expand All @@ -37,10 +38,11 @@ PORTB=io
```
Here, `PINB` is the name and `io` is the type of the port and this will be added as a
flag at the offset `0x03`. The type can be `ext_io` if it's an extended IO register, as well. Both will be added
as [flags](https://book.rizin.re/basic_commands/flags.html?highlight=flags#flags) and the only difference between
them is that they will be added in different [flagspaces](https://book.rizin.re/refcard/intro.html?highlight=flagspa#flagspaces).
as [flags](../basic_commands/flags.md) and the only difference between them is that they will be added in different
[flagspaces](../refcard/intro.md).

CPU profiles also support mapping the ROM. According the `ROM_ADDRESS` and `ROM_SIZE`, a [section](https://book.rizin.re/basic_commands/sections.html?highlight=section#sections) named `.rom` will be added during analysis.
CPU profiles also support mapping the ROM. According to the `ROM_ADDRESS` and `ROM_SIZE`,
a [section](../basic_commands/sections.md) named `.rom` will be added during analysis.

#### Adding CPU profiles

Expand All @@ -53,12 +55,13 @@ by the variable `cpus` in the corresponding architecture's disassembler plugin (
the SDB file in the directory, add the entry in the `meson.build` of the same directory and build again. Choose
the right CPU and architecture and analyze again (`aa`) to load up the CPU profile.

For reference, you can see the previously added CPU profile of ATmega16 here: [librz/asm/cpus/avr-ATmega16.sdb.txt](https://github.com/rizinorg/rizin/blob/dev/librz/asm/cpus/avr-ATmega16.sdb.txt).
For reference, you can see the previously added CPU profile of ATmega16 here:
[librz/asm/cpus/avr-ATmega16.sdb.txt](https://github.com/rizinorg/rizin/blob/dev/librz/asm/cpus/avr-ATmega16.sdb.txt).

### Platform profiles

Platform profiles are designed with an idea to support adding information that is pertaining to a specific board
or a micro controller. For example, most of the Raspberry Pi-s use a specific Broadcom chip and its peripherals
or a microcontroller. For example, most of the Raspberry Pi-s use a specific Broadcom chip and its peripherals
like registers and interrupts will be the same for all Raspberry Pi-s. These profiles can be selected using the
configuration variable `asm.platforms` and is loaded during analysis (`aa`). If you run `e asm.platform=?`, you
can see the supported platforms by the selected architecture and CPU.
Expand All @@ -75,7 +78,8 @@ AUX_MU_IO_REG.address=0x7e215040
AUX_MU_IO_REG.comment=Mini UART I/O Data
```

Just like in CPU profiles, the `name` will be added as a flag and the `comment` as a [comment](https://book.rizin.re/disassembling/adding_metadata.html?highlight=Comment#adding-metadata-to-disassembly) (`CCu`).
Just like in CPU profiles, the `name` will be added as a flag and the `comment` as a
[comment](../disassembling/adding_metadata.md) (`CCu`).

#### Adding platform profiles

Expand All @@ -87,4 +91,5 @@ the `RzAsmPlugin` definition corresponding architecture's disassembler plugin. Y
CPU is it's not already added. Then, add the entry in the `meson.build` of the same directory and build again.
Choose the right CPU, architecture and platform and analyze again (`aa`).

You can also check out the platform profiles that were previously added at [librz/asm/platforms/arm-arm1176-bcm2835.sdb.txt](https://github.com/rizinorg/rizin/blob/dev/librz/asm/platforms/arm-arm1176-bcm2835.sdb.txt).
You can also check out the platform profiles that were previously added at
[librz/asm/platforms/arm-arm1176-bcm2835.sdb.txt](https://github.com/rizinorg/rizin/blob/dev/librz/asm/platforms/arm-arm1176-bcm2835.sdb.txt).
14 changes: 7 additions & 7 deletions src/analysis/emulation.md
Original file line number Diff line number Diff line change
Expand Up @@ -5,14 +5,14 @@ the core difference between static analysis and dynamic analysis. As many alread
know, static analysis suffers from the path explosion problem, which is impossible
to solve even in the most basic way without at least a partial emulation.

Thus many professional reverse engineering tools use code emulation while
performing an analysis of binary code, and rizin is no different here.
Thus, many professional reverse engineering tools use code emulation while
performing an analysis of binary code, and Rizin is no different here.

For partial emulation (or imprecise full emulation) rizin uses its own
[ESIL](../disassembling/esil.md) intermediate language and virtual machine.
For partial emulation (or imprecise full emulation) Rizin uses its own RzIL intermediate language, designed
to replace current [ESIL](../disassembling/esil.md).

Rizin supports this kind of partial emulation for all platforms that
implement ESIL uplifting (x86/x86_64, ARM, arm64, MIPS, PowerPC, SPARC, AVR, 8051, Gameboy, ...).
implement ESIL uplifting (x86/x86_64, ARM, arm64, MIPS, PowerPC, SPARC, AVR, 8051, Game Boy, ...).

One of the most common usages of such emulation is to calculate
indirect jumps and conditional jumps.
Expand Down Expand Up @@ -66,7 +66,7 @@ To manually setup the ESIL imprecise emulation you need to run this command sequ
- a sequence of `aer` commands to set the initial register values.

While performing emulation, please remember, that ESIL VM cannot emulate external calls
or system calls, along with SIMD instructions. Thus the most common scenario is to
or system calls, along with SIMD instructions. Thus, the most common scenario is to
emulate only a small chunk of the code, like encryption/decryption, unpacking or
calculating something.

Expand All @@ -79,7 +79,7 @@ The commands interface for ESIL VM is almost identical to the debugging one:
- `aesue <ESIL expression>` to step until some specified ESIL expression met
- `aec` to continue until break (Ctrl-C), this one is rarely used though, due to the omnipresence of external calls

In visual mode, all of the debugging hotkeys will work also in ESIL emulation mode.
In visual mode, all the debugging hotkeys will work also in ESIL emulation mode.

Along with usual emulation, there is a possibility to record and replay mode:

Expand Down
115 changes: 59 additions & 56 deletions src/analysis/graphs.md
Original file line number Diff line number Diff line change
@@ -1,98 +1,101 @@
# Graph commands

When analyzing data it is usually handy to have different ways to represent it in order to get new perspectives to allow the analyst to understand how different parts of the program interact.
When analyzing data it is usually handy to have different ways to represent it in order to get new perspectives to
allow the analyst to understand how different parts of the program interact.

Representing basic block edges, function calls, string references as graphs show a very clear view of this information.

Rizin supports various types of graph available through commands starting with `ag`:

```
[0x00005000]> ag?
|Usage: ag<graphtype><format> [addr]
| Graph commands:
| aga[format] Data references graph
| agA[format] Global data references graph
| agc[format] Function callgraph
| agC[format] Global callgraph
| agd[format] [fcn addr] Diff graph
| agf[format] Basic blocks function graph
| agi[format] Imports graph
| agr[format] References graph
| agR[format] Global references graph
| agx[format] Cross references graph
| agg[format] Custom graph
| ag- Clear the custom graph
| agn[?] title body Add a node to the custom graph
| age[?] title1 title2 Add an edge to the custom graph
Output formats:
| <blank> Ascii art
| * rizin commands
| d Graphviz dot
| g Graph Modelling Language (gml)
| j json ('J' for formatted disassembly)
| k SDB key-value
| t Tiny ascii art
| v Interactive ascii art
| w [path] Write to path or display graph image (see graph.gv.format and graph.web)
Usage: ag<?> # Analysis graph commands
| aga <format>=ascii # Data reference graph
| agA <format>=ascii # Global data references graph
| agc <format>=ascii # Function callgraph
| agC <format>=ascii # Global callgraph
| agCi <format>=ascii # Inter-procedual control flow graph
| agF <format>=ascii # Control flow graph (without calls)
| agf <format>=ascii # Basic blocks function graph
| agi <format>=ascii # Imports graph
| agr <format>=ascii # References graph
| agR <format>=ascii # Global references graph
| ags <format>=ascii # Normal graph
| agl <format>=ascii # Line graph
| agx <format>=ascii # Cross-references graph
| agI <format>=ascii # RzIL graph of the instruction at the current offset.
| agg <format>=ascii # Custom graph
| ag- # Clear the custom graph
| agn[-] # Managing custom graph nodes
| age[-] # Managing custom graph edges
| agw <graphtype>=dataref <path> [-global] # Write to path or display graph image (see graph.gv.format)
Formats:
| ascii # Ascii art
| cmd # rizin commands
| dot # Graphviz dot
| gml # Graph Modelling Language
| json # json
| json_disasm # json formatted disassembly
| sdb # SDB key-value
| interactive # Interactive ascii art
```

The structure of the commands is as follows: `ag <graph type> <output format>`.

For example, `agid` displays the imports graph in dot format, while `aggj`
For example, `agi dot` displays the imports graph in dot format, while `agg json`
outputs the custom graph in JSON format.

Here's a short description for every output format available:

### Ascii Art ** (e.g. `agf`)
### Ascii Art (e.g. `agf`)

Displays the graph directly to stdout using ASCII art to represent blocks and edges.

_Warning: displaying large graphs directly to stdout might prove to be computationally expensive and will make rizin not responsive for some time. In case of doubt, prefer using the interactive view (explained below)._
_Warning: displaying large graphs directly to stdout might prove to be computationally expensive and will make Rizin
not responsive for some time. In case of doubt, prefer using the interactive view (explained below)._

### Interactive Ascii Art (e.g. `agfv`)
### Interactive Ascii Art (e.g. `agf interactive`)

Displays the ASCII graph in an interactive view similar to `VV` which allows to move the screen, zoom in / zoom out, ...

### Tiny Ascii Art (e.g. `agft`)
### Graphviz dot (e.g. `agf dot`)

Displays the ASCII graph directly to stdout in tiny mode (which is the same as reaching the maximum zoom out level in the interactive view).
Prints the dot source code representing the graph, which can be interpreted by programs such as
[graphviz](https://graphviz.gitlab.io/download/) or online viewers like [webgraphviz](http://www.webgraphviz.com/).

### Graphviz dot (e.g. `agfd`)

Prints the dot source code representing the graph, which can be interpreted by programs such as [graphviz](https://graphviz.gitlab.io/download/) or online viewers like [this](http://www.webgraphviz.com/)

### JSON (e.g. `agfj`)
### JSON (e.g. `agf json`)

Prints a JSON string representing the graph.

- In the case of the `f` format (basic blocks of function), it will have detailed information about the function and will also contain the disassembly of the function (use `J` format for the formatted disassembly.

- In the case of the `f` format (basic blocks of function), it will have detailed information about the function and
will also contain the disassembly of the function (use `J` format for the formatted disassembly).
- In all other cases, it will only have basic information about the nodes of the graph (id, title, body, and edges).

### Graph Modelling Language (e.g. `agfg`)
### Graph Modelling Language (e.g. `agf gml`)

Prints the GML source code representing the graph, which can be interpreted by programs such as [yEd](https://www.yworks.com/products/yed/download)
Prints the GML source code representing the graph, which can be interpreted by programs such as
[yEd](https://www.yworks.com/products/yed/download)

### SDB key-value (e.g. `agfk`)
### SDB key-value (e.g. `agf sdb`)

Prints key-value strings representing the graph that was stored by sdb (rizin's string database).
Prints key-value strings representing the graph that was stored by sdb (Rizin's string database).

### R2 custom graph commands (e.g. `agf*`)
### Rizin custom graph commands (e.g. `agg`)

Prints rizin commands that would recreate the desired graph. The commands to construct the graph are `agn [title] [body]` to add a node and `age [title1] [title2]` to add an edge.
Prints rizin commands that would recreate the desired graph. The commands to construct the graph are
`agn [title] [body]` to add a node and `age [title1] [title2]` to add an edge.
The `[body]` field can be expressed in base64 to include special formatting (such as newlines).

To easily execute the printed commands, it is possible to prepend a dot to the command (`.agf*`).

### Web / image (e.g. `agfw`)

Rizin will convert the graph to dot format, use the `dot` program to convert it to a `.gif` image and then try to find an already installed viewer on your system (`xdg-open`, `open`, ...) and display the graph there.
To easily execute the printed commands, it is possible to prepend a dot to the command (`.agg`).

The extension of the output image can be set with the `graph.extension` config variable. Available extensions are `png, jpg, gif, pdf, ps`.
### Web / image (e.g. `agw`)

_Note: for particularly large graphs, the most recommended extension is `svg` as it will produce images of much smaller size_
Rizin will convert the graph to dot format, use the `dot` program to convert it to a `.gif` image and then try to find
an already installed viewer on your system (`xdg-open`, `open`, ...) and display the graph there.

If `graph.web` config variable is enabled, rizin will try to display the graph using the browser (_this feature is experimental and unfinished, and
disabled by default._)
The extension of the output image can be set with the `graph.gv.format` config variable. Available extensions are
`png, jpg, pdf, ps, svg, json`.

_Note: for particularly large graphs, the most recommended extension is `svg` as it will produce images of much
smaller size_
Loading

0 comments on commit d4f35c5

Please sign in to comment.