Ret2libsanity

joined 1 year ago
[–] Ret2libsanity@lemmy.world 1 points 1 year ago

I develop mostly in C and largely for creating shellcode.

I have run into very weird issues with clang relocating code and data segments even when using a custom linker script

[–] Ret2libsanity@lemmy.world 4 points 1 year ago (2 children)

I feel that.

I still favor gcc over clang

[–] Ret2libsanity@lemmy.world 2 points 1 year ago

Til. Thanks for sharing this

[–] Ret2libsanity@lemmy.world 0 points 1 year ago (1 children)

Def curl and wget!

Zsh is great but I ended up falling back to bash for simplicity.

 

I’ll start:

  • Tmux
  • vim
  • ghidra
  • okteta (hex editor)
  • speedcrunch (calculator with bit manipulation)
  • python3 with IPython for nice reply and embed(), pwntools
[–] Ret2libsanity@lemmy.world 1 points 1 year ago

I thought I was going to hate this as another useless tool.

And while that’s still mostly true - I do see the vision here. And the clean c code and man page docs makes this a win for me.

Simple utility that does what it says. I also like the single char status output.

[–] Ret2libsanity@lemmy.world -1 points 1 year ago

I’m not sure I completely understand the question.

But vendor / custom UEFI implementations could obviously pass around whatever structures they want.

The EFI RUNTIME services - for example - could expose custom functions in a proprietary UEFI implementation. Though in my experience this usually is not the case.

Grub should run as an EFI bootloader binary after core UEFI is done. Afaik there is no particular ring / exception level required here. It could vary depending on UEFI implantation.

on android arm32/64 devices I obviously don’t see grub, but core EFI handles and services are not modified much. If anything it’s just expanded to support the next bootloader stage and handle stuff like key combos to select next boot image