[00:00.000 --> 00:10.920]  So, this presentation I will try to show you the project, what's the current state, the
[00:10.920 --> 00:14.920]  features, most used plugins and which are the main features.
[00:14.920 --> 00:20.640]  Okay, so first of all, a quick presentation, I'm Sergei Alvarez, everybody knows me by
[00:20.640 --> 00:25.680]  my nickname, which is Pancake, I'm the author of the tool, I live in Barcelona and I work
[00:25.680 --> 00:30.840]  at Now Secure, which is a company from US, which we basically use different static and
[00:30.840 --> 00:35.120]  dynamic instrumentation tools for analyzing applications and find out privacy issues,
[00:35.120 --> 00:39.600]  like identifying if the application is leaking data, stuff like that, and then generate some
[00:39.600 --> 00:47.040]  reports for the customers and developers to improve the quality of the applications.
[00:47.040 --> 00:52.280]  So I work as a senior mobile security analyst, I like command line tools, I like command
[00:52.280 --> 01:00.640]  text interfaces, I brought many open source software, so my first goal is basically publishing
[01:00.640 --> 01:07.400]  all the stuff that I'm doing, so I like free software, and I'm maintaining the whole
[01:07.400 --> 01:13.760]  R2 ecosystem nowadays, so I'm basically focusing on R2, but I also maintain R2-Quitra, R2-Frida
[01:13.760 --> 01:16.600]  and many other plugins that work with R2.
[01:16.600 --> 01:26.680]  We'll have to reduce the font size here, this slide is a little bit.
[01:26.680 --> 01:33.560]  So it's a 17-year-old project, so I started this tool basically as a forensic tool, I
[01:33.560 --> 01:38.440]  wanted to recover some files that are lost in a hard drive.
[01:38.440 --> 01:44.160]  The thing is that I was working as a forensic analyst, but I was not going to use the private
[01:44.160 --> 01:47.840]  software that was in the company, so I wrote a simple hexadecimal editor that was able
[01:47.840 --> 01:54.560]  to find some patterns in the disk, and then dump like a one megabyte from there.
[01:54.560 --> 01:59.120]  After this I was interested in participating in CTF and different competitions for reverse
[01:59.120 --> 02:03.920]  engineering, and I found out that there were so many tools that didn't really solve my
[02:03.920 --> 02:08.280]  problems, so starting by, for example, GDB, it was not possible to script it at the time
[02:08.280 --> 02:12.400]  and typing comments all the time, it was kind of tedious, and I just wanted to automate
[02:12.400 --> 02:13.400]  many things.
[02:13.400 --> 02:16.840]  Also, there was hexadecimal editors, but it was not possible to extend them with plugins
[02:16.840 --> 02:22.440]  or anything like this, and there was like disassemblers, but Object Dump is cool, but
[02:22.440 --> 02:28.840]  it's not interactive, and the only interactive tool was private, which is IDA, and anyway,
[02:28.840 --> 02:33.800]  there was no real ecosystem for open source to solve any of these problems at once.
[02:33.800 --> 02:38.000]  And there were so many little tools that were solving one problem, but not really being
[02:38.000 --> 02:41.240]  able to integrate with the rest of the ecosystem or other tools.
[02:41.240 --> 02:45.560]  So I decided to start picking ideas, picking tools, developing everything from scratch,
[02:45.560 --> 02:49.960]  that's why I did R2, because R2 is not depending on anything, so you can, you only depend on
[02:49.960 --> 02:53.960]  the postics like Slipsy, and all the rest of dependencies are written from scratch,
[02:53.960 --> 03:00.160]  like console handling, read line interface, all the socket interface, parsing libraries,
[03:00.160 --> 03:02.960]  disassembling things, etc.
[03:02.960 --> 03:10.360]  It's licensed under LGPL3, and yeah, I mean, the focus of the project is basically to read
[03:10.360 --> 03:12.800]  other tools and be useful for hackers.
[03:12.800 --> 03:18.360]  It's not going to be a general proposed solution for all the problems, because for example,
[03:18.360 --> 03:22.240]  I don't plan to write like disassemblers from scratch, I think that there are better projects
[03:22.240 --> 03:25.520]  for this, so I'm integrating them into R2.
[03:25.520 --> 03:31.840]  Same goes for like Lipoak, it's one of the tools that is able to use R2.
[03:31.840 --> 03:36.360]  It's fully written in C, I mainly focus on portability because I like the things that
[03:36.360 --> 03:38.360]  I write to run everywhere.
[03:38.360 --> 03:45.600]  So the only option nowadays is C, I mean, there is some rast haters around that, anyway.
[03:45.600 --> 03:51.040]  The thing is that R2 can be run, can be compiled into WebAssembly, so you can run R2 inside
[03:51.040 --> 03:55.000]  your browser, you can also build it in a statical link at single binary, so you can drop it
[03:55.000 --> 03:56.840]  in a router.
[03:56.840 --> 04:01.520]  This year I plan to port it to a UFE, so you can run R2 inside your bootloader, and then
[04:01.520 --> 04:05.800]  you can use an independent operating system to use R2, mount file systems, and things
[04:05.800 --> 04:07.440]  like that.
[04:07.440 --> 04:12.680]  So there is some really high constraints on all the code that are shipping R2, so there
[04:12.680 --> 04:17.360]  is like a CI that is basically verifying everything, there is like a 24-7 fuzzer that
[04:17.360 --> 04:22.440]  is running and finding bugs and fixing them, so my policies, I don't let bugs stay for
[04:22.440 --> 04:25.560]  more than one day.
[04:25.560 --> 04:31.240]  So the code cannot contain like setJAMP, or Abort, or Asserts, or anything like this,
[04:31.240 --> 04:38.120]  because if you are doing something in hot, you don't want things to crash or to break.
[04:38.120 --> 04:43.640]  So the idea is that all the code that is running in R2 must be used from a library, so I don't
[04:43.640 --> 04:47.520]  want to use like double variables, I don't want to depend on something that, if it's
[04:47.520 --> 04:53.480]  not parsing properly, I don't want to crash, I want the, if the Moloch is failing, I want
[04:53.480 --> 04:56.320]  the program to still run, things like this.
[04:56.320 --> 05:02.760]  So this is the main concern that I have when I write code for R2.
[05:02.760 --> 05:08.160]  It's developing a single repo, but it's separated in different models, so it's like a big project
[05:08.160 --> 05:12.680]  in one repository, but there is like a bunch of libraries, each library has like a bunch
[05:12.680 --> 05:18.560]  of plugins, and many of these plugins are integrated or exposed, interfaces for extending
[05:18.560 --> 05:20.160]  it with scripting languages.
[05:20.160 --> 05:26.360]  So at the end is basically like a different layers of capabilities that can be extended
[05:26.360 --> 05:29.080]  pretty easily at different layers.
[05:29.080 --> 05:32.280]  So there is like a common line interface, so you have like a prompt, you can type things,
[05:32.280 --> 05:38.000]  there is like a visual mode, which is basically a list of comments that you execute every
[05:38.000 --> 05:42.640]  time that you press a key, and then you have the panels mode, which is like you can make
[05:42.640 --> 05:47.960]  splits, you can have like different tabs, you can have like different frames and so on,
[05:47.960 --> 05:51.440]  and then there is web interfaces, there is some people writing graphical interfaces
[05:51.440 --> 05:55.920]  for it, like Yaito, which is the Qt interface for it.
[05:55.920 --> 06:01.240]  For scripting, the easiest way for scripting R2 is Ertopipe, which is basically the simplest
[06:01.240 --> 06:05.640]  interface for interfacing with anything, which is basically you run something, you pass a
[06:05.640 --> 06:10.360]  string with a comment, and then you get the output of the comment as a string, but there
[06:10.360 --> 06:17.520]  is also bindings for the CAPI, there's automated bindings for Python, for Rust, etc.
[06:17.520 --> 06:26.120]  And there is also support for using these bindings from different scripting languages.
[06:26.120 --> 06:29.200]  So what are the libraries implementing or exposing?
[06:29.200 --> 06:34.000]  So you have the IO library, which is basically abstracting the access to the IO, this basically
[06:34.000 --> 06:40.160]  defines how you access like a file, everything is abstract, this means that a file doesn't
[06:40.160 --> 06:45.720]  need to be anything physical, there is support, I mean you cannot map like a full file in
[06:45.720 --> 06:49.080]  memory and then work on it because this is abstracted by the IO.
[06:49.080 --> 06:56.160]  So you can map like a remote file in a running in a remote instance of R2, so you can run
[06:56.160 --> 07:01.440]  R2 as an instance, and then you can map for example like a ptrace backend, which is basically
[07:01.440 --> 07:06.480]  reading and writing memory from another process, and this is like another IO interface, and
[07:06.480 --> 07:08.560]  all that stuff is just the file descriptor.
[07:08.560 --> 07:13.760]  So when you have like one IO open, then you can map this file descriptor into separate
[07:13.760 --> 07:18.440]  maps, a map is basically a portion of the memory taken from the file descriptor, so
[07:18.440 --> 07:23.040]  you say that from this offset to this offset from this file descriptor will be mapped in
[07:23.040 --> 07:29.560]  this virtual address in the IO space of R2, and then there are IO banks, and IO banks
[07:29.560 --> 07:33.720]  are basically a bunch of maps, so you can have like separate memory spaces, like for
[07:33.720 --> 07:39.320]  example you want to relate like a thread local stretch, you can have like one IO space that
[07:39.320 --> 07:44.160]  only contains the contents of the thread local stretch, but then there is like another bank
[07:44.160 --> 07:49.240]  that contains all the memory layout of the processing memory, and you can do that just
[07:49.240 --> 07:54.240]  by typing comments, you can do this also by using the API, but anyway, it's also possible
[07:54.240 --> 08:01.320]  to create like SQL memory maps, memory layouts, for example B850 is like an architecture that
[08:01.320 --> 08:06.640]  is used for automobiles and things like that, and this architecture basically relies on
[08:06.640 --> 08:11.000]  having like some solid infrastructure, so you see there is some models that have like
[08:11.000 --> 08:15.080]  two CPUs executing the same code at the same time, and there is like a verification that
[08:15.080 --> 08:22.760]  two CPUs are doing exactly the same at runtime, and the memory of this CPU is basically SQL,
[08:22.760 --> 08:27.520]  so there is some references that are going backward, so you have like one instruction
[08:27.520 --> 08:32.680]  at the zero address that is referencing something up, and this something up is basically going
[08:32.680 --> 08:40.120]  to the negative of other space, and this negative other space is not 32-bit in size, it's 26
[08:40.120 --> 08:44.200]  for example, so you can basically configure this kind of things inside the R2, and you
[08:44.200 --> 08:49.920]  can basically get emulation, all the flags which are basically naming offsets in all
[08:49.920 --> 08:54.880]  these things and everything will be shaped properly, you can also define bit sizes memory
[08:54.880 --> 09:02.000]  spaces like 7-bit bytes and things like this, it's also able to pass binary formats, this
[09:02.000 --> 09:07.480]  works on any of the memory like I have said before, so you can pass from memory, you can
[09:07.480 --> 09:13.640]  pass from disk, there is support for the most known well-filed formats from console, binary,
[09:13.640 --> 09:22.400]  ROM, headers like Gameboy etc, but there is also for LFP, Makrokov etc, it's also parsing
[09:22.400 --> 09:29.040]  Dwarf, PDB and other debug information, this is only for getting like address of memory,
[09:29.040 --> 09:33.960]  making like a file name and so on, it's not really exporting all the structures and so
[09:33.960 --> 09:38.600]  on, but it's also possible to do that in the future, or using several libraries, it's
[09:38.600 --> 09:47.640]  also parsing like class information from SWIFT, Objective C or C++ binaries, and all that
[09:47.640 --> 09:52.480]  stuff is integrated inside the R2, so you can, it's subtracting all the information
[09:52.480 --> 09:59.840]  from all these final formats into single naming, so for example, imports in a PE is not the
[09:59.840 --> 10:04.640]  same as like an import in ELF, but for R2 is the same, so when you want to list what
[10:04.640 --> 10:08.800]  a binary is importing from other libraries, you can just use give me the imports, you
[10:08.800 --> 10:14.880]  don't have to use like different APIs or different comments depending on the file format, so
[10:14.880 --> 10:21.000]  it's unifying all the formats into a single naming, it's also supporting assembling and
[10:21.000 --> 10:26.800]  assembling, it's using like one API, so there is like a library that exposes an interface
[10:26.800 --> 10:32.800]  for doing this, and this library exposes plugins, so there's like plugins that are used by
[10:32.800 --> 10:38.240]  this API, and then you can basically implement like new architectures, like writing plugins
[10:38.240 --> 10:44.000]  for this library, but it's not only used for assembling and disassembling, which is basically
[10:44.000 --> 10:50.720]  text bytes, there is more low level detailed information, like you can, for some architectures
[10:50.720 --> 10:55.160]  you can get like a structure metadata, like which is the first operand, which is the size
[10:55.160 --> 10:59.600]  of the second argument, things like this, but it's also exposing a seal, a seal is like
[10:59.600 --> 11:05.520]  a very simple text interface for explaining what an instruction is doing at low level,
[11:05.520 --> 11:10.000]  it's kind of, it's very similar to fourth, like a stack based machine, and it's basically
[11:10.000 --> 11:17.360]  one statement separated by GOMA, so you have like O, GOMA, AX, GOMA equals, means that
[11:17.360 --> 11:21.160]  it will be pushing the number, then pushing the register name, and then pushing the operation,
[11:21.160 --> 11:28.280]  which is the equal, and then popping up from the operation to execute the statement.
[11:28.280 --> 11:34.480]  The reason for that is because there is so many ways to extend or to define an architecture,
[11:34.480 --> 11:39.360]  and there is some really fucked up things that can be done in so many architectures,
[11:39.360 --> 11:45.080]  so I was not going to define like extensible structures or doing some really complex things,
[11:45.080 --> 11:49.560]  because at the end I was always finding like something that was not compatible with another
[11:49.560 --> 11:54.360]  architecture, and I end up like saying, okay, I just can define like a comma separated string
[11:54.360 --> 11:58.600]  that it's just located in a single memory chunk, and I can just split it by comma and
[11:58.600 --> 12:00.800]  then emulate that.
[12:00.800 --> 12:05.160]  So there is a bunch of tools or libraries that can be, that are using a seal to extract
[12:05.160 --> 12:10.200]  this information, and then use that for emulation, use that for extracting information from a
[12:10.200 --> 12:16.120]  specific instruction, or even for the compiling.
[12:16.120 --> 12:21.760]  It's very portable, so it works on support debugging also, so you can do local and remote
[12:21.760 --> 12:22.760]  debugging.
[12:22.760 --> 12:30.200]  This means that you can run R2 as a local debugger in your Linux Mac or iOS device, but you can
[12:30.200 --> 12:34.720]  also attach to remote GDB or YDBG, et cetera.
[12:34.720 --> 12:38.800]  It's a functionality for searching for different patterns, so you can search for strings, access
[12:38.800 --> 12:44.720]  and model values, you can also find me something that is repeated multiple times, and then
[12:44.720 --> 12:48.280]  it will be finding like if there is any pattern that is repeated many times and give you the
[12:48.280 --> 12:54.000]  offset of these things, it's also able to generate function signatures, so by taking
[12:54.000 --> 12:58.120]  all the whole analysis for the program, it will identify all the functions, basic blocks,
[12:58.120 --> 13:02.800]  et cetera, and then you can generate like metadata for each of these functions, and
[13:02.800 --> 13:07.120]  this metadata can be imported again to search for this information in our binary.
[13:07.120 --> 13:12.200]  So you have like one binary with dwarf information, or the back symbols, then you can import this
[13:12.200 --> 13:16.760]  into a binary that is a stripet, and then you can basically identify these data structures
[13:16.760 --> 13:21.680]  or functions in another binary that is not containing this data.
[13:21.680 --> 13:28.720]  It's also possible to div code level, but you can also div data, you can find like using
[13:28.720 --> 13:33.080]  delta-diffing, so you have like two binaries that contain the same data, but in different
[13:33.080 --> 13:38.960]  offsets it will identify which offset is the stripet in the binary, and which is the main
[13:38.960 --> 13:44.360]  difference from that, it's not byte per byte level instruction checking.
[13:44.360 --> 13:48.960]  You can also div basic blocks, like you get the two control flow graphs, and then identifying
[13:48.960 --> 13:53.760]  which basic block is added, which removed, or if there is like a percentage of difference,
[13:53.760 --> 14:00.680]  so you can use that for bin-diffing, and you can also find differences like ABDIF for
[14:00.680 --> 14:06.320]  getting like there is new symbols removed, or things like that.
[14:06.320 --> 14:12.800]  I also took code from Grapp, a group, which is basically the bootloader, and I used that
[14:12.800 --> 14:19.080]  for parsing file systems, things that group is doing a lot of things for like assuming
[14:19.080 --> 14:23.440]  that the file system is correct, and R2 will never assume that anything is correct, so
[14:23.440 --> 14:28.400]  if there is like a corrupted file system I want to be able to mount it, so R2 is using
[14:28.400 --> 14:33.280]  this code basically for mounting file systems, you can have like a fake, or like a virtual
[14:33.280 --> 14:37.680]  file system interface in starter 2, and you can use that for mounting local or remote
[14:37.680 --> 14:38.680]  file systems.
[14:38.680 --> 14:41.880]  You can use R2-free, I will show that later, but I don't have time for showing it, but
[14:41.880 --> 14:47.200]  anyway, I will, you can use Freeda, which is like a tool for injecting code in remote
[14:47.200 --> 14:52.240]  applications, and you can use TCP or USB for communicating with that, and then Freeda can
[14:52.240 --> 14:57.000]  expose like an interface for accessing files remotely, so you can mount zips in a remote
[14:57.000 --> 15:01.920]  file system, extract the zip contents from one binary, pass the binary in local, mount
[15:01.920 --> 15:08.360]  that memory layout in local, and then whatever you would like to do with these things.
[15:08.360 --> 15:14.400]  Okay, obviously there is like a huge amount of things that can be done with that, so there
[15:14.400 --> 15:16.000]  is a need for a package manager.
[15:16.000 --> 15:21.560]  So I wrote R2-PM, it was like a 200 line shell script, so it's not really a big thing, but
[15:21.560 --> 15:25.720]  one year ago I decided to write it in C, so this way you can basically run the package
[15:25.720 --> 15:33.760]  manager anywhere, even in Windows, so it doesn't depend on anything that is not the same R2.
[15:33.760 --> 15:38.720]  So this package manager is basically pulling a zip repository, and this repository contains
[15:38.720 --> 15:43.320]  like scripts, and this script is basically defining a very simple way for installing
[15:43.320 --> 15:50.480]  and uninstalling, so it defines instructions for compiling and installing the plugin, and
[15:50.480 --> 15:55.440]  there is like basically a bunch of tools that are installed in your home, and also plugins
[15:55.440 --> 15:58.080]  that are loaded by R2.
[15:58.080 --> 16:03.880]  So the most common or most used plugins for R2 are, for example, about the compilers you
[16:03.880 --> 16:10.080]  have like R2-Dec, you have R2-Gidra, R2-Reddeck, so if you know Gidra for example, they provide
[16:10.080 --> 16:16.280]  like a compiler, there is like a part of the compiler which is written in C++, not in Java,
[16:16.280 --> 16:21.640]  and this code can be reused for writing at a compiler without depending on the whole Java
[16:21.640 --> 16:29.160]  thing, then there is Reddeck, which is the compiler based on LLVM and a bunch of parallel
[16:29.160 --> 16:34.840]  scripts that mess the thing, and they basically use the compiler toolchain to do the backward
[16:34.840 --> 16:42.040]  steps, to get from the binary disassembly to get like C like code for the compiling.
[16:42.040 --> 16:47.160]  Then you can also use the Aphora, there is support for signatures for IDA, there is like
[16:47.160 --> 16:53.000]  native signatures, there is like some repository of people writing this, and then there is
[16:53.000 --> 17:00.080]  support for Frida, if you know Frida, who knows Frida, where is your hand, okay, half
[17:00.080 --> 17:01.080]  of the room.
[17:01.080 --> 17:02.080]  Is that the compiler, right?
[17:02.080 --> 17:08.960]  No, Frida is a tool that basically injects code in a remote process, and then there
[17:08.960 --> 17:12.600]  is an agent that is running in a separate thread inside the process, so you can basically
[17:12.600 --> 17:17.960]  instrument the process at runtime, and you can basically inject JavaScript code or C
[17:17.960 --> 17:21.780]  or assembly inside the remote process and instrument that.
[17:21.780 --> 17:25.000]  You can use that for profiling, you can use that for modifying behavior, you can use that
[17:25.000 --> 17:30.320]  for tracing APIs, identifying when a specific function is called with some arguments, and
[17:30.320 --> 17:34.640]  then execute some code inside the remote process.
[17:34.640 --> 17:40.680]  Most people use JavaScript for doing this, but you can also use C with libgam or whatever,
[17:40.680 --> 17:46.560]  and yeah, we basically use that for dynamic instrumentation on iOS and Android applications.
[17:46.560 --> 17:50.520]  So you can use R2 Frida to have like a R2 interface for interfacing with Frida, which
[17:50.520 --> 17:56.560]  means that you don't need to type long JavaScript one-liners, you can also use R2 comments like
[17:56.560 --> 18:02.440]  which are pretty mnemonic and easy to type, if you know them, and there is also support
[18:02.440 --> 18:10.440]  for external assemblers like NuoGas or the Unicorn library, which is kind of like a stripping
[18:10.440 --> 18:18.640]  code from LVM, and there is also program solvers like Radius, SteelSol for Anger that are plugins
[18:18.640 --> 18:22.120]  that basically you define some constraints, you have like a function and you define, okay
[18:22.120 --> 18:25.560]  I want to know which are the arguments that I need to pass to this function to reach these
[18:25.560 --> 18:30.840]  specific others, like you want to know for example if it's possible to create like a
[18:30.840 --> 18:36.560]  buffer overflow in a specific variable in a local stack, or you want to define which,
[18:36.560 --> 18:40.120]  or you want to know which is the password that matches a specific crypto algorithm,
[18:40.120 --> 18:44.480]  so you can use that to define, okay, I want to know which is the amount, the block of
[18:44.480 --> 18:49.760]  bytes of one specific length that generate this hash, for example, things like that,
[18:49.760 --> 18:54.520]  and these won't be brute forcing, it's like using program solvers like Z3 and so on, so
[18:54.520 --> 18:59.600]  there is like different plugins that are integrated in R2 to use from R2 comments, and then you
[18:59.600 --> 19:05.400]  can define the preconditions, post-conditions, and the boundaries of the function to emulate.
[19:05.400 --> 19:08.240]  Then there is also support for parsing that structure, there is support for Kaitai, there
[19:08.240 --> 19:13.760]  is support for poke, this was integrated last week, because I didn't know it was possible
[19:13.760 --> 19:19.800]  to have like a library of poke, I was seeing it as a program, not a library, so it's integrated
[19:19.800 --> 19:25.680]  but it's not fully integrated, so I plan to continue integrating it to use like for disassembling,
[19:25.680 --> 19:30.400]  for parsing, headers, etc.
[19:30.400 --> 19:32.600]  So what can you do with R2 Frida?
[19:32.600 --> 19:38.920]  R2 Frida is basically, as I said before, it's front end for Frida, you can run scripts
[19:38.920 --> 19:45.000]  in your host, in your agent site, so you can write a JavaScript program that runs in R2,
[19:45.000 --> 19:49.520]  but it can be also loaded in the remote site, and you can load and unload plugins, so you
[19:49.520 --> 19:53.960]  can basically extend the R2 Frida comment set with JavaScript plugins that are loaded
[19:53.960 --> 19:56.040]  and unloaded at runtime.
[19:56.040 --> 20:00.160]  It's also scriptable with R2 Pipe, so you can write a program in Python, JavaScript,
[20:00.160 --> 20:06.400]  or the language you like, that interacts and automates comments and actions in the host
[20:06.400 --> 20:09.160]  site or the remote site of the Frida site.
[20:09.160 --> 20:14.040]  So you can spawn applications, you can attach to local remote processes, you can use different
[20:14.040 --> 20:18.120]  protocol or communication channels like USB, TCP, etc.
[20:18.120 --> 20:26.840]  You can remote the file systems, you can use that for interfacing with tracing APIs, profiling,
[20:26.840 --> 20:32.960]  and also supports extracting metadata from Java, Dalvik, Objective-C, and Swift support
[20:32.960 --> 20:36.680]  will be ready by the end of this year, because right now it's supported, but it's kind of
[20:36.680 --> 20:42.160]  like unstable, and the API is changing, so yeah, sort of like it will get better.
[20:42.160 --> 20:45.360]  So let's talk about R2 Pipe.
[20:45.360 --> 20:51.080]  Once the release, well, the first release that they did this year was the 5.8.0, I planned
[20:51.080 --> 20:56.360]  to keep ABA stable, actually I use ABDF in the CI, so every comment or pull request that
[20:56.360 --> 21:00.520]  people send to the project, they verify that it's ABA stable.
[21:00.520 --> 21:06.320]  This means that I'm not breaking the ABI, you can rebuild or update R2 without recompiling
[21:06.320 --> 21:10.040]  all the plugins or the tools that are using R2 libraries.
[21:10.040 --> 21:15.840]  This is pretty cool, and the thing is that I was having some kind of contract with myself
[21:15.840 --> 21:20.280]  that I don't break ABI, but this is something that you end up doing Ruby when code by hand,
[21:20.280 --> 21:25.920]  and having a tool that can automate this is great.
[21:25.920 --> 21:31.520]  But I wanted to have a runtime, something that you can run from R2, like interpreter,
[21:31.520 --> 21:38.560]  that is not a custom language or external library that needs to be integrated and it's
[21:38.560 --> 21:39.560]  really big.
[21:39.560 --> 21:44.560]  I was experimenting for some time with different languages and realizing that QuickJS is the
[21:44.560 --> 21:50.880]  only option, so even Lua is using setjump, so you cannot compile with Lua as a WebAssembly
[21:50.880 --> 21:51.880]  plugin.
[21:51.880 --> 21:55.560]  Also, if you want to use setjump with threads, it's kind of a mess.
[21:55.560 --> 22:00.360]  So I ended up picking QuickJS, which is the same JavaScript runtime that Frida is using.
[22:00.360 --> 22:04.840]  I picked the code from there, and as long as every comment in R2 is verifying with
[22:04.840 --> 22:08.960]  fuzzers, other sanitizers, and so on, I end up finding a lot of issues there.
[22:08.960 --> 22:16.280]  I sent like 12 patches to the project, so it's basically the fork that is used by Frida.
[22:16.280 --> 22:21.080]  So all these patches are upstream now, and the idea is basically that you can use TypeScript
[22:21.080 --> 22:26.120]  and JavaScript from R2, and you can write code like this.
[22:26.120 --> 22:30.480]  So you basically have an R2 pipe interface, but it's running inside R2.
[22:30.480 --> 22:36.800]  You can use this from WebAssembly, so you can basically open R2.online, and then you have
[22:36.800 --> 22:43.640]  a terminal that you can run R2, drag and drop a binary inside the browser, and use JavaScript
[22:43.640 --> 22:48.400]  to automate a bunch of actions for organizing the binary.
[22:48.400 --> 22:52.000]  Basically as I said before, you have a command that you run, and then you get the output
[22:52.000 --> 22:55.600]  of the command in exchange.
[22:55.600 --> 23:01.400]  As long as most of the comments in R2 speed out JSON, you can basically use the cmdj,
[23:01.400 --> 23:05.800]  which basically get the output of the command and pass the output as JSON.
[23:05.800 --> 23:10.520]  And then you get like a structure data that you can use for extracting it or processing
[23:10.520 --> 23:12.160]  it with the tools you like.
[23:12.160 --> 23:17.640]  I think that JavaScript and JSON are quite standard and useful nowadays, so you don't
[23:17.640 --> 23:22.040]  need to learn new things, but there is support for so many other languages.
[23:22.040 --> 23:27.680]  Like I said here, there is Python, support, Rust, Node.js, Rabi, Guile, Nivellisp, Haskell,
[23:27.680 --> 23:29.280]  Dlang, Swift, etc.
[23:29.280 --> 23:34.520]  So it's very easy to write this simple interface, and you can use basically different interfaces
[23:34.520 --> 23:39.960]  to communicate with R2, so you can use like a fork and a pipe, or you can also use like
[23:39.960 --> 23:44.360]  a TCP socket or an HTTP interface, WebSockets, whatever you like.
[23:44.360 --> 23:48.840]  And for the TypeScript thing, it's pretty cool, because I'm writing like a Type description
[23:48.840 --> 23:55.480]  that basically defines the APIs of R2, and also the structures that the commands are
[23:55.480 --> 23:57.520]  returning in JSON format.
[23:57.520 --> 24:02.320]  This means that you can get the JSON of a command, and then you can generate a schema
[24:02.320 --> 24:03.320]  out of that.
[24:03.320 --> 24:05.120]  And this schema can be used like a Types.
[24:05.120 --> 24:13.920]  So if you use TypeScript, ListServer, like the language service that autocompletes all
[24:13.920 --> 24:19.520]  the code, you can basically use that for using Type to autocomplete all the code.
[24:19.520 --> 24:24.640]  So for example, you can analyze function, you press P dot I, and then you get all the
[24:24.640 --> 24:28.800]  function name, you can get all the basic blocks, for each basic block you can use Type to get
[24:28.800 --> 24:35.680]  all the fields of this basic block, like the address, the amount of instructions, etc.
[24:35.680 --> 24:38.960]  And for each instruction, you can get the mnemonics, etc.
[24:38.960 --> 24:39.960]  And everything runs.
[24:39.960 --> 24:46.040]  I mean, you can use, like, Visual Studio Code, or NLVM, or whatever you like, or MX, I guess,
[24:46.040 --> 24:53.720]  that's also Supercell SP, and use that for automating and scripting using these languages.
[24:53.720 --> 25:01.200]  So R2 is able to visualize data and code in so many different ways, so all this, I mean,
[25:01.200 --> 25:09.240]  I can press E, so you can get the source code of the slides.
[25:09.240 --> 25:13.120]  So you can see here, this is the contents of the slide.
[25:13.120 --> 25:18.760]  So it's running a bunch of comments in R2, and the output is generated inside the visual
[25:18.760 --> 25:22.200]  mode that you saw before.
[25:22.200 --> 25:26.360]  So you can generate graphs, you can, from the control flow graph, you can also generate
[25:26.360 --> 25:31.920]  like a vertical horizontal line graph, like frame things, you can disassemble, you can
[25:31.920 --> 25:36.960]  render pictures in bit formats, in RGB format.
[25:36.960 --> 25:43.000]  You can also generate, like, different, like, comparing data and identifying which bytes
[25:43.000 --> 25:48.680]  are changing, by changing colors, you can define, like, a color for a specific bunch
[25:48.680 --> 25:49.680]  of addresses.
[25:49.680 --> 25:53.960]  So when you are disassembling, you can mark some regions, like, hot code, or this is,
[25:53.960 --> 25:58.800]  like, a portion of code that you're interested, and then you get headlights for one specific
[25:58.800 --> 26:03.520]  register, so you want to highlight SP, and then you get SP highlighted in the whole
[26:03.520 --> 26:05.800]  disassembly, things like that.
[26:05.800 --> 26:13.120]  But also, there is also UIs, but I'm, like, common line guys, so I prefer to use the shell.
[26:13.120 --> 26:17.640]  But there is, like, a Qt interface, but also I started to write, like, a new graphic interface
[26:17.640 --> 26:25.600]  using WX Widgets, because, I mean, Qt is great, because it's big, and it solves so many things,
[26:25.600 --> 26:31.960]  but I don't like the license, it's so huge, it's getting, like, really huge, and it's
[26:31.960 --> 26:36.840]  not handy for the kind of things that I like to do, so when I'm developing, I like to have
[26:36.840 --> 26:42.160]  fun, and I don't want to be suffering because of license, or companies that are developing
[26:42.160 --> 26:43.320]  things in the background.
[26:43.320 --> 26:54.440]  So I wrote so many UIs for it, too, like, in GTK, in using InBlip, also other HTML, CSS,
[26:54.440 --> 26:59.400]  for the web UI, because I do have, like, a web server inside, so at the end, I want to
[26:59.400 --> 27:05.280]  have fun, and I don't want to spend time, like, learning new APIs, and so on.
[27:05.280 --> 27:10.880]  So I'm writing, like, a WX Widgets API, a user interface, and the idea for this is to
[27:10.880 --> 27:17.680]  not follow the same flow, interaction flows that people use.
[27:17.680 --> 27:21.600]  So I want to have, like, a common line interface, but integrated in the UI.
[27:21.600 --> 27:25.240]  So I want to be able to have multiple windows using multiple sessions, or drag and drop
[27:25.240 --> 27:30.360]  things from one window to another one, instead of having, like, a big thing with panels and
[27:30.360 --> 27:33.240]  the common interaction ways.
[27:33.240 --> 27:34.960]  So what's the future?
[27:34.960 --> 27:38.200]  So there are short and long-term plans.
[27:38.200 --> 27:44.640]  It all depends on my time, because most of the things are maintained or done by me.
[27:44.640 --> 27:50.160]  There is a lot of contributors, but they come and live, so there is, like, not really a
[27:50.160 --> 27:55.320]  core developer team, or there is no really big plans for having, like, big organizations,
[27:55.320 --> 27:57.040]  there is, and so on.
[27:57.040 --> 28:01.320]  But the thing is that I want to be able to keep patching, like, stable releases.
[28:01.320 --> 28:05.920]  I want to have, like, ABA stability, mainly because there is some people or companies
[28:05.920 --> 28:09.640]  or users that are writing tools on top of this, and I don't want them to rewrite things
[28:09.640 --> 28:13.120]  every time that I make a release or break without updating this.
[28:13.120 --> 28:18.720]  I want to have, like, a create, so which is a Rust API that you can basically specify
[28:18.720 --> 28:23.520]  the version of R2 that you want to ship, and then this create will build R2 inside with
[28:23.520 --> 28:28.280]  a specific version, and then you can use your R2 statically linked inside your program.
[28:28.280 --> 28:34.240]  So you don't need to depend on system installations or depend on other things like that.
[28:34.240 --> 28:38.680]  I want to basically reduce the tech depth, because as long as I'm alone doing most of
[28:38.680 --> 28:40.720]  the things, I don't want to depend on humans.
[28:40.720 --> 28:44.320]  So I want to reduce the amount of things that are done manually.
[28:44.320 --> 28:49.720]  So for example, a friend of me brought, like, the flatback integration, so there is, like,
[28:49.720 --> 28:54.720]  a bot that basically detects when there is, like, a new release in R2 or in Yaito, and
[28:54.720 --> 28:58.240]  when this happens, it's basically pulling the code from all the projects, generating
[28:58.240 --> 29:03.320]  a changelog, generating a new build, and publishing that automatically.
[29:03.320 --> 29:10.600]  And you basically get, like, a graphical interface for Linux and Windows for free.
[29:10.600 --> 29:17.280]  I want to improve the code coverage and all the testing for fuzzing, and, yeah, I mean,
[29:17.280 --> 29:23.040]  there is, like, a lot of things that you can see, and if you have questions, please let
[29:23.040 --> 29:25.200]  me know after the talk with some beers.
[29:25.200 --> 29:28.200]  And I guess that everyone is hungry, so...
[29:28.200 --> 29:46.240]  Thank you so much guys.