Description

There are tools to build function call graphs based on parsing source code, for example, cscope.

This project aims to achieve a similar goal by directly parsing the disasembly (i.e. objdump) of a compiled binary. The assembly code is what the CPU sees, therefore more "direct". This may be useful in certain scenarios, such as gdb/crash debugging.

Detailed description and Demos can be found in the README file:

Supports x86 for now (because my customers only use x86 machines), but support for other architectures can be added easily.

Tested with python3.6

Goals

Any comments are welcome.

Resources

https://github.com/lhb-cafe/SymbolRelations

symrellib.py: mplements the symbol relation graph and the disassembly parser

symrel_tracer*.py: implements tracing (-t option)

symrel.py: "cli parser"

Looking for hackers with the skills:

python3 python assembly crash

This project is part of:

Hack Week 24

Activity

  • 12 months ago: huanxie started this project.
  • 12 months ago: michals liked this project.
  • 12 months ago: huanxie liked this project.
  • 12 months ago: hli added keyword "crash" to this project.
  • 12 months ago: hli added keyword "assembly" to this project.
  • 12 months ago: hli added keyword "python3" to this project.
  • 12 months ago: hli added keyword "python" to this project.
  • 12 months ago: hli originated this project.

  • Comments

    Be the first to comment!

    Similar Projects

    openQA log viewer by mpagot

    Description

    *** Warning: Are You at Risk for VOMIT? ***

    Do you find yourself staring at a screen, your eyes glossing over as thousands of lines of text scroll by? Do you feel a wave of text-based nausea when someone asks you to "just check the logs"?

    You may be suffering from VOMIT (Verbose Output Mental Irritation Toxicity).

    This dangerous, work-induced ailment is triggered by exposure to an overwhelming quantity of log data, especially from parallel systems. The human brain, not designed to mentally process 12 simultaneous autoinst-log.txt files, enters a state of toxic shock. It rejects the "Verbose Output," making it impossible to find the one critical error line buried in a 50,000-line sea of "INFO: doing a thing."

    Before you're forced to rm -rf /var/log in a fit of desperation, we present the digital antacid.

    No panic: The openQA Log Visualizer (Also known as the "VOMIT-B-Gone 9000")

    This is your web-based hazmat suit for handling toxic log environments. It bravely dives into the chaotic, multi-machine mess of your openQA test runs, finds all the related, verbose logs, and force-feeds them into a parser.

    image

    Goals

    Work on the existing POC openqa-log-visualizer and change it to something usable

    Resources

    openqa-log-visualizer


    Bring to Cockpit + System Roles capabilities from YAST by miguelpc

    Bring to Cockpit + System Roles features from YAST

    Cockpit and System Roles have been added to SLES 16 There are several capabilities in YAST that are not yet present in Cockpit and System Roles We will follow the principle of "automate first, UI later" being System Roles the automation component and Cockpit the UI one.

    Goals

    The idea is to implement service configuration in System Roles and then add an UI to manage these in Cockpit. For some capabilities it will be required to have an specific Cockpit Module as they will interact with a reasource already configured.

    Resources

    A plan on capabilities missing and suggested implementation is available here: https://docs.google.com/spreadsheets/d/1ZhX-Ip9MKJNeKSYV3bSZG4Qc5giuY7XSV0U61Ecu9lo/edit

    Linux System Roles: https://linux-system-roles.github.io/


    pudc - A PID 1 process that barks to the internet by mssola

    Description

    As a fun exercise in order to dig deeper into the Linux kernel, its interfaces, the RISC-V architecture, and all the dragons in between; I'm building a blog site cooked like this:

    • The backend is written in a mixture of C and RISC-V assembly.
    • The backend is actually PID1 (for real, not within a container).
    • We poll and parse incoming HTTP requests ourselves.
    • The frontend is a mere HTML page with htmx.

    The project is meant to be Linux-specific, so I'm going to use io_uring, pidfs, namespaces, and Linux-specific features in order to drive all of this.

    I'm open for suggestions and so on, but this is meant to be a solo project, as this is more of a learning exercise for me than anything else.

    Goals

    • Have a better understanding of different Linux features from user space down to the kernel internals.
    • Most importantly: have fun.

    Resources