>_0xFORUM
Sign in

gdb catch syscall plus a filter — still useful?

in Debugging26 replies1.6k views

catch syscall write, then a condition on the fd. It worked. It was slow. strace -e would have been enough for this bug.

I used gdb because I already had a breakpoint I liked. Not a methodology.

catch syscall write
condition 1 $rdi == 3

Refs: rr

Lab / educational. Public binaries and patched classes only. Isolated VM.

// 26 REPLIES

I dumped after OEP and then did this. You wrote «catch syscall write, then a condition on the fd». That is the sentence I keep. WOW64: switch the stack before you talk. !wow64exts.sw. Same class as the October thread, different binary.

@zer0x

The screenshot is the useful part of the post. You wrote «catch syscall write, then a condition on the fd». That is the sentence I keep. Han

You skipped isolation and then asked why the box is dirty. That is on you. Bookmarking this for the lab wiki. «gdb catch syscall plus a filter — still useful?» — specifically catch syscall write, then a condition on the fd. Kernel time travel is not user TTD. Stepping into a syscall will not take you to the kernel. My note id for this: 4b-01.

@analyst

I dumped after OEP and then did this. You wrote «catch syscall write, then a condition on the fd». That is the sentence I keep. WOW64: switc

I am not moving this to DMs so you can yell. Stay on the class. Agreed on the class, not on the tool. «gdb catch syscall plus a filter — still useful?» — specifically catch syscall write, then a condition on the fd. rr --chaos is the first thing I try on a userspace race. If it cannot see it, I log TSC stamps. Was this on the licensed corpus or a crackme you wrote? Version in my shot: current lab snapshot, not last year's blog.

The screenshot is the useful part of the post. The load-bearing line: catch syscall write, then a condition on the fd. rr --chaos is the first thing I try on a userspace race. If it cannot see it, I log TSC stamps. Did page heap see it, or only the sanitizer? I reproduced it on lab build 1093.

@iamflex

This belongs in the first-hour ritual. You wrote «catch syscall write, then a condition on the fd». That is the sentence I keep. rr --chaos

Quote the bytes or sit down. Agreed on the class, not on the tool. On «gdb catch syscall plus a filter — still useful?»: catch syscall write, then a condition on the fd. !analyze is a hypothesis. !thread and the raw stacks are the evidence. I still have the snapshot named debu-75-pre.

I tried the naive path first and wasted a morning. «gdb catch syscall plus a filter — still useful?» — specifically catch syscall write, then a condition on the fd. Dump the helper process. Always the helper process. Did you snapshot before, or is this a restore-from-memory story? My note id for this: 4b-18.

@crypt

The screenshot is the useful part of the post. The load-bearing line: catch syscall write, then a condition on the fd. rr --chaos is the fir

Call-convention guess is not evidence. The screenshot is the useful part of the post. You wrote «catch syscall write, then a condition on the fd». That is the sentence I keep. Kernel time travel is not user TTD. Stepping into a syscall will not take you to the kernel. Took me 5 hours the first time.

@axi0m

Agreed on the class, not on the tool. «gdb catch syscall plus a filter — still useful?» — specifically catch syscall write, then a condition

I would have written the opposite conclusion a year ago. On «gdb catch syscall plus a filter — still useful?»: catch syscall write, then a condition on the fd. SetThreadDescription is free. I will keep nagging. I still have the snapshot named debu-75-pre.

@bitwse

I would have written the opposite conclusion a year ago. On «gdb catch syscall plus a filter — still useful?»: catch syscall write, then a c

That is not what the listing shows. You are arguing a vibe. Not fully convinced yet. The load-bearing line: catch syscall write, then a condition on the fd. SetThreadDescription is free. I will keep nagging. I wrote a 12-line script and then threw it away. The listing was enough.

@flare

Did this on ARM64 last week — same shape, different pain. «gdb catch syscall plus a filter — still useful?» — specifically catch syscall wri

You are describing a live target. Stop. Patched class only. The screenshot is the useful part of the post. You wrote «catch syscall write, then a condition on the fd». 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. Did you force-create the function or did auto-analysis luck into it? I wrote a 12-line script and then threw it away. The listing was enough.

@chain

Bookmarking this for the lab wiki. On «gdb catch syscall plus a filter — still useful?»: catch syscall write, then a condition on the fd. Du

I read the patch. You read a tweet. Those are not the same source. Bookmarking this for the lab wiki. «gdb catch syscall plus a filter — still useful?» — specifically catch syscall write, then a condition on the fd. SetThreadDescription is free. I will keep nagging. Took me 10 hours the first time.

Bookmarking this for the lab wiki. On «gdb catch syscall plus a filter — still useful?»: catch syscall write, then a condition on the fd. Dump the helper process. Always the helper process. Pinned a comment at 0x140000e41 in the listing.

@danielrocks

The screenshot is the useful part of the post. You wrote «catch syscall write, then a condition on the fd». That is the sentence I keep. Ker

I ran this on a licensed corpus binary. You wrote «catch syscall write, then a condition on the fd». That is the sentence I keep. Page heap and ASan catch different lies. I run both. I wrote a 12-line script and then threw it away. The listing was enough.

Did this on ARM64 last week — same shape, different pain. «gdb catch syscall plus a filter — still useful?» — specifically catch syscall write, then a condition on the fd. !analyze is a hypothesis. !thread and the raw stacks are the evidence. Pinned a comment at 0x14000676f in the listing.

Also: If gdb finish hangs, there was a longjmp. Stop waiting.

@liveconnect

The screenshot is the useful part of the post. On «gdb catch syscall plus a filter — still useful?»: catch syscall write, then a condition o

You skipped isolation and then asked why the box is dirty. That is on you. The screenshot is the useful part of the post. «gdb catch syscall plus a filter — still useful?» — specifically catch syscall write, then a condition on the fd. !analyze is a hypothesis. !thread and the raw stacks are the evidence. My note id for this: 4b-21.

@deltafx

I ran this on a licensed corpus binary. You wrote «catch syscall write, then a condition on the fd». That is the sentence I keep. Page heap

Do not call people skids because they use Ghidra. Same wall I hit last quarter. You wrote «catch syscall write, then a condition on the fd». That is the sentence I keep. Page heap and ASan catch different lies. I run both. If anyone DMs me a zip I will not open it. Hash in-thread.

I ran this on a licensed corpus binary. «gdb catch syscall plus a filter — still useful?» — specifically catch syscall write, then a condition on the fd. Hang dump for hangs. Minidump for crashes I already understand. I will +rep a listing and −rep a vibe. That is the deal.

@hassanwise

I reproduced it twice before I believed you. On «gdb catch syscall plus a filter — still useful?»: catch syscall write, then a condition on

This belongs in the first-hour ritual. You wrote «catch syscall write, then a condition on the fd». 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. My note id for this: 4b-16.

@grayx

I ran this on a licensed corpus binary. «gdb catch syscall plus a filter — still useful?» — specifically catch syscall write, then a conditi

Take the telegram pitch to the bin. Market listing or nothing. I reproduced it twice before I believed you. On «gdb catch syscall plus a filter — still useful?»: catch syscall write, then a condition on the fd. If gdb finish hangs, there was a longjmp. Stop waiting. Version in my shot: current lab snapshot, not last year's blog.

The screenshot is the useful part of the post. On «gdb catch syscall plus a filter — still useful?»: catch syscall write, then a condition on the fd. WOW64: switch the stack before you talk. !wow64exts.sw. I reproduced it on lab build 1372.

Also: SetThreadDescription is free. I will keep nagging.

@kabirjay

I tried the naive path first and wasted a morning. «gdb catch syscall plus a filter — still useful?» — specifically catch syscall write, the

You are treating a checksum as a signature again. Did this on ARM64 last week — same shape, different pain. You wrote «catch syscall write, then a condition on the fd». That is the sentence I keep. Hang dump for hangs. Minidump for crashes I already understand. I still have the snapshot named debu-75-pre.

@matrx

The screenshot is the useful part of the post. «gdb catch syscall plus a filter — still useful?» — specifically catch syscall write, then a

I dumped after OEP and then did this. The load-bearing line: catch syscall write, then a condition on the fd. SetThreadDescription is free. I will keep nagging. My note id for this: 4b-22.

@netrix

I dumped after OEP and then did this. The load-bearing line: catch syscall write, then a condition on the fd. SetThreadDescription is free.

I am not moving this to DMs so you can yell. Stay on the class. Not fully convinced yet. On «gdb catch syscall plus a filter — still useful?»: catch syscall write, then a condition on the fd. WOW64: switch the stack before you talk. !wow64exts.sw. Which build of the tool? I got burned mixing notes across versions. I still have the snapshot named debu-75-pre.

Did this on ARM64 last week — same shape, different pain. On «gdb catch syscall plus a filter — still useful?»: catch syscall write, then a condition on the fd. If gdb finish hangs, there was a longjmp. Stop waiting. I reproduced it on lab build 1071.

@osinx

Did this on ARM64 last week — same shape, different pain. On «gdb catch syscall plus a filter — still useful?»: catch syscall write, then a

That is not what the listing shows. You are arguing a vibe. This matches a public n-day class from last patch Tuesday. You wrote «catch syscall write, then a condition on the fd». That is the sentence I keep. Dump the helper process. Always the helper process. I reproduced it on lab build 1364.

The screenshot is the useful part of the post. You wrote «catch syscall write, then a condition on the fd». That is the sentence I keep. Hang dump for hangs. Minidump for crashes I already understand. Took me 10 hours the first time.

Sign in to reply. Guests can read reversing, pentesting, coding and greyhat threads.