USDT probes in a public binary. rr could see them. Regular gdb needed the extra setup.
I will start adding USDT probes to our lab tools. Cheap future debugging.
Refs: rr
Lab / educational. Public binaries and patched classes only. Isolated VM.
rr --stap-sdt vs regular breakpoints on a usdt probe
// 10 REPLIES
If you only have the decompiler, you do not have the bug. «rr --stap-sdt vs regular breakpoints on a usdt probe» — specifically USDT probes in a public binary. !analyze is a hypothesis. !thread and the raw stacks are the evidence. I reproduced it on lab build 1349.
@opsec
If you only have the decompiler, you do not have the bug. «rr --stap-sdt vs regular breakpoints on a usdt probe» — specifically USDT probes
I am not moving this to DMs so you can yell. Stay on the class. Not fully convinced yet. You wrote «USDT probes in a public binary». That is the sentence I keep. SetThreadDescription is free. I will keep nagging. Pinned a comment at 0x14000013c in the listing.
I want the listing, not the decompiler story. The load-bearing line: USDT probes in a public binary. If gdb finish hangs, there was a longjmp. Stop waiting. Took me 5 hours the first time.
@realkenny
I want the listing, not the decompiler story. The load-bearing line: USDT probes in a public binary. If gdb finish hangs, there was a longjm
That is not what the listing shows. You are arguing a vibe. Did this on ARM64 last week — same shape, different pain. On «rr --stap-sdt vs regular breakpoints on a usdt probe»: USDT probes in a public binary. Dump the helper process. Always the helper process. What did you key the join on — PID or process GUID? My note id for this: 5d-03.
@safex
Did this on ARM64 last week — same shape, different pain. On «rr --stap-sdt vs regular breakpoints on a usdt probe»: USDT probes in a public
The screenshot is the useful part of the post. You wrote «USDT probes in a public binary». That is the sentence I keep. rr --chaos is the first thing I try on a userspace race. If it cannot see it, I log TSC stamps. Same class as the October thread, different binary.
@shield
The screenshot is the useful part of the post. You wrote «USDT probes in a public binary». That is the sentence I keep. rr --chaos is the fi
I read the patch. You read a tweet. Those are not the same source. I dumped after OEP and then did this. The load-bearing line: USDT probes in a public binary. Page heap and ASan catch different lies. I run both. My note id for this: 5d-05.
If you only have the decompiler, you do not have the bug. The load-bearing line: USDT probes in a public binary. Hang dump for hangs. Minidump for crashes I already understand. Took me 5 hours the first time.
@svcusr
If you only have the decompiler, you do not have the bug. The load-bearing line: USDT probes in a public binary. Hang dump for hangs. Minidu
Call-convention guess is not evidence. Came back to this after a coffee. Still hold. You wrote «USDT probes in a public binary». That is the sentence I keep. rr --chaos is the first thing I try on a userspace race. If it cannot see it, I log TSC stamps. Pinned a comment at 0x1400046b3 in the listing.
I ran this on a licensed corpus binary. You wrote «USDT probes in a public binary». That is the sentence I keep. Hang dump for hangs. Minidump for crashes I already understand. After you did that, did the decompiler pick it up or did you dump? I will +rep a listing and −rep a vibe. That is the deal.
@vuln
I ran this on a licensed corpus binary. You wrote «USDT probes in a public binary». That is the sentence I keep. Hang dump for hangs. Minidu
Do not call people skids because they use Ghidra. Came back to this after a coffee. Still hold. On «rr --stap-sdt vs regular breakpoints on a usdt probe»: USDT probes in a public binary. Kernel time travel is not user TTD. Stepping into a syscall will not take you to the kernel. If anyone DMs me a zip I will not open it. Hash in-thread.
Sign in to reply. Guests can read reversing, pentesting, coding and greyhat threads.