Jarkko Sakkinen
Posts
4819Following
319Followers
487OpenPGP: 3AB05486C7752FE1
@TartanLlama @ljs @nostarch
I'm not that interested on a debugger book because I've written at least couple of debuggers and profilers for internal use in some companies and also read the classic "Gray Hat Python" BUT as a future recommendation I'd buy immediately a spiritual successor of "Linkers and Loaders".
There's been some binary analysis books after but they are not enjoyable read like Linkers and Loaders is bit historical tidbits etc. They are more like tutorials. You should check this book out some day if you've never read. I guarantee you will enjoy it (by Stephen Levy from 1999).
I just wish someone would write a great book about binary formats because I enjoy that stuff almost a hobby ;-) Like now that eBPF even has ELF profile, would be great to go through from IBM mainframe times to that and some discussion how they have been modernized for more modern languages. It's a total treasure zone of great lore.
I'm not that interested on a debugger book because I've written at least couple of debuggers and profilers for internal use in some companies and also read the classic "Gray Hat Python" BUT as a future recommendation I'd buy immediately a spiritual successor of "Linkers and Loaders".
There's been some binary analysis books after but they are not enjoyable read like Linkers and Loaders is bit historical tidbits etc. They are more like tutorials. You should check this book out some day if you've never read. I guarantee you will enjoy it (by Stephen Levy from 1999).
I just wish someone would write a great book about binary formats because I enjoy that stuff almost a hobby ;-) Like now that eBPF even has ELF profile, would be great to go through from IBM mainframe times to that and some discussion how they have been modernized for more modern languages. It's a total treasure zone of great lore.
1
0
0
Jarkko Sakkinen
repeated
repeated
Sy Brand
TartanLlama@mastodon.socialA wrote a book on how debuggers work!
It guides you through writing a complete native debugger from scratch.
Available Spring 2025 from @nostarch (probably not with this cover)
14
8
3
Jarkko Sakkinen
jarkko
Edited 1 year ago
One add to #C 's memory safety is that you can almost decompile it in your head so that it is trivial to map even raw binary to meaningful language statements. I like that Ghidra and Rizin have decompilers but I almost never use them because I do not NEED them for anything. Especially since the return of frame pointers assembly simple and awesome again.
Also reviewing C code is factors easier than any other programming language I'm aware or because you don't have to guess how statements translate.
In most more modern systems you really have to do research sometimes because of unnecessarily complex language constructs and vast amount of generated code, meaning that there are filters obfuscating how the final machine language code is generated.
Finally, like with any software, more complex shit you produce, more likely you are gong to hit to bugs. This applies also to GCC and LLVM.
Also reviewing C code is factors easier than any other programming language I'm aware or because you don't have to guess how statements translate.
In most more modern systems you really have to do research sometimes because of unnecessarily complex language constructs and vast amount of generated code, meaning that there are filters obfuscating how the final machine language code is generated.
Finally, like with any software, more complex shit you produce, more likely you are gong to hit to bugs. This applies also to GCC and LLVM.
0
0
1
@beandev I ended up wrapping it like https://codeberg.org/jarkko/clonectl/src/branch/main/src/main.rs
0
0
1
Jarkko Sakkinen
jarkko
@beandev I find this maybe a bit more robust and it has pretty good backing given the byte code alliance: https://github.com/bytecodealliance/cap-std
1
0
1
@rjzak I wonder if it would be possible to take a script of rizin commands and compile them into a Python script which would execute equivalent steps using capstone etc. modules. It could skip commands (perhaps marking a comment to the script), which are infeasible to support in this context. Then it would be easy to prototype analysis in Rizin and finally turn that into custom analysis which could be then further refined by tuning the script. This would be a great feature for CI.
Another thing I'm wondering could Rizin take advantage of eBPF capabilities of Linux kernel and use probes in the run-time debugger. It is easy to create BPF ring buffers for an application to deliver customized data from kernel (I've done this once).
Another thing I'm wondering could Rizin take advantage of eBPF capabilities of Linux kernel and use probes in the run-time debugger. It is easy to create BPF ring buffers for an application to deliver customized data from kernel (I've done this once).
1
0
0
Jarkko Sakkinen
jarkko
@oleksandr @gromit @vbabka I'll put that to the same queue as compiler flags. Thank you!
Cannot say anything before testing the patch because Murphy's law clearly states if you judge without testing you always get it wrong ;-)
Cannot say anything before testing the patch because Murphy's law clearly states if you judge without testing you always get it wrong ;-)
0
0
1
Jarkko Sakkinen
jarkko
0
0
1
@vbabka after some testing and "unfixing" mbsync bug [1] I don't think it is yet ready for production use but sure going to try the latest main every once in a while and might even fix a bug or something.
Normally I hate the whole "Rust fork scene" but in the case of IMAP sync there would be really an actual need for a modern robust alternative. Maybe even something that would handle both IMAP and EWS in the same package. And also email is somewhat fuzzy data to make deductions of so a strong type system can actually make a difference here.
[1] https://social.kernel.org/notice/AkX1oAnWFMXja3uN84
Normally I hate the whole "Rust fork scene" but in the case of IMAP sync there would be really an actual need for a modern robust alternative. Maybe even something that would handle both IMAP and EWS in the same package. And also email is somewhat fuzzy data to make deductions of so a strong type system can actually make a difference here.
[1] https://social.kernel.org/notice/AkX1oAnWFMXja3uN84
1
0
1
Jarkko Sakkinen
jarkko
@laamaa I did one test track with polyend couple of years ago but got frustrated of 1.6 fw envelope glitches. Planning to do some new stuff with 1.8 but I need to switch the encoder first, which unfortunately went loose (duh) ;-) New encoder has been waiting on table already for some months...
https://soundcloud.com/triplaespresso/sivutie
https://soundcloud.com/triplaespresso/sivutie
1
0
0
Jarkko Sakkinen
jarkko
@rjzak Personally I think that this can be at most taken as a guideline. In some cases Python could be also the best possible solution. It also requires less heavy CI than many other options. E.g. I could imagine doing a real-time embedded system based on MicroPython, and take full control of GC and flush it only in planned call sites.
0
0
0
Jarkko Sakkinen
jarkko
One critical angle towards #AI from my side is that software engineering is not about producing code.
Even if I wrote all my code in Notepad and slowed my productivity down on purpose let's say to 10%, it would not affect much to my ability to deliver all that much.
The thing is that analysis is the key with minimum amount of false positives, and AI is not an #algorithm.
Even if I wrote all my code in Notepad and slowed my productivity down on purpose let's say to 10%, it would not affect much to my ability to deliver all that much.
The thing is that analysis is the key with minimum amount of false positives, and AI is not an #algorithm.
0
0
2