Because the next person will run them on a host. Hashes and links to the public corpus. Not files.
If you attach a sample I will remove it and we will talk. If you attach it twice, we will not talk.
Refs: CVE Program
Lab / educational. Public binaries and patched classes only. Isolated VM.
This matches a public n-day class from last patch Tuesday. You wrote «Because the next person will run them on a host». That is the sentence I keep. If you wrap memcpy, I want the check on every path. Took me 3 hours the first time.
@dump_the_core
This matches a public n-day class from last patch Tuesday. You wrote «Because the next person will run them on a host». That is the sentence
That insult was not a technical point. I am reporting it. This is the writeup I wanted when I was stuck. The load-bearing line: Because the next person will run them on a host. OOB read is a leak until proven otherwise. In the notes, not in a PoC. My note id for this: fc-01.
Please keep the hashes and drop the mystery zips. On «Why we do not attach crashing files even when they are public corpus»: Because the next person will run them on a host. A saturating add that hangs is not a complete patch. Hunt the hang too. Version in my shot: current lab snapshot, not last year's blog.
@axi0m
Please keep the hashes and drop the mystery zips. On «Why we do not attach crashing files even when they are public corpus»: Because the nex
I am reporting the sample-drop hint. Hash and corpus tag only. Good. Dated shot, version in the post. You wrote «Because the next person will run them on a host». That is the sentence I keep. system() on a user path is the class. execve with argv is the patch. Was this on the licensed corpus or a crackme you wrote? Version in my shot: current lab snapshot, not last year's blog.
@bitwse
Good. Dated shot, version in the post. You wrote «Because the next person will run them on a host». That is the sentence I keep. system() on
This is the kind of thread that should be a sticky and is not. You wrote «Because the next person will run them on a host». That is the sentence I keep. system() on a user path is the class. execve with argv is the patch. Took me 5 hours the first time.
@buffr
This is the kind of thread that should be a sticky and is not. You wrote «Because the next person will run them on a host». That is the sent
The graph hid it. The listing did not. Trust the listing. Not fully convinced yet. «Why we do not attach crashing files even when they are public corpus» â specifically Because the next person will run them on a host. A saturating add that hangs is not a complete patch. Hunt the hang too. If anyone DMs me a zip I will not open it. Hash in-thread.
This is the writeup I wanted when I was stuck. You wrote «Because the next person will run them on a host». That is the sentence I keep. Patched class only. Hunt the old immediate. Do not ask for a trigger file. I wrote a 12-line script and then threw it away. The listing was enough.
@cldsec
This is the writeup I wanted when I was stuck. You wrote «Because the next person will run them on a host». That is the sentence I keep. Pat
Stop flexing an IDA license. The question was the unwind info. Good. Dated shot, version in the post. You wrote «Because the next person will run them on a host». That is the sentence I keep. If the thread slides toward a live target, lock it. I will report it. Took me 6 hours the first time.
I disagree with the tone, not the bytes. «Why we do not attach crashing files even when they are public corpus» â specifically Because the next person will run them on a host. Canonicalize last. Concatenate after realpath is how .. comes back. Did you force-create the function or did auto-analysis luck into it? Same class as the October thread, different binary.
@danielrocks
I disagree with the tone, not the bytes. «Why we do not attach crashing files even when they are public corpus» â specifically Because the n
Calling the sticky 'priest talk' is how you earn a ban note. I want the listing, not the decompiler story. «Why we do not attach crashing files even when they are public corpus» â specifically Because the next person will run them on a host. Patched class only. Hunt the old immediate. Do not ask for a trigger file. My note id for this: fc-09.
@deltafx
I want the listing, not the decompiler story. «Why we do not attach crashing files even when they are public corpus» â specifically Because
This belongs in the first-hour ritual. The load-bearing line: Because the next person will run them on a host. Patched class only. Hunt the old immediate. Do not ask for a trigger file. Pinned a comment at 0x14000061f in the listing.
@eliashub
This belongs in the first-hour ritual. The load-bearing line: Because the next person will run them on a host. Patched class only. Hunt the
That is a vibe. I asked for a listing offset. I reproduced it twice before I believed you. The load-bearing line: Because the next person will run them on a host. Date your heap notes. 2012 grooming diagrams are history. Pinned a comment at 0x140006810 in the listing.
This is the kind of thread that should be a sticky and is not. On «Why we do not attach crashing files even when they are public corpus»: Because the next person will run them on a host. Patched class only. Hunt the old immediate. Do not ask for a trigger file. I still have the snapshot named expl-252-pre.
Also: OOB read is a leak until proven otherwise. In the notes, not in a PoC.
@freq
This is the kind of thread that should be a sticky and is not. On «Why we do not attach crashing files even when they are public corpus»: Be
If you cannot paste bytes, you do not have a counterexample. This is the writeup I wanted when I was stuck. The load-bearing line: Because the next person will run them on a host. No samples, even public corpus files. Hashes and links. Attachments get pulled. Did you snapshot before, or is this a restore-from-memory story? I wrote a 12-line script and then threw it away. The listing was enough.
Agreed on the class, not on the tool. The load-bearing line: Because the next person will run them on a host. No samples, even public corpus files. Hashes and links. Attachments get pulled. Same class as the March thread, different binary.
@hassanwise
Agreed on the class, not on the tool. The load-bearing line: Because the next person will run them on a host. No samples, even public corpus
You keep moving the goalposts. First it was the decoder, now it is the dump. I will argue the opposite and then probably agree. On «Why we do not attach crashing files even when they are public corpus»: Because the next person will run them on a host. Date your heap notes. 2012 grooming diagrams are history. If anyone DMs me a zip I will not open it. Hash in-thread.
@iamflex
I will argue the opposite and then probably agree. On «Why we do not attach crashing files even when they are public corpus»: Because the ne
Not fully convinced yet. On «Why we do not attach crashing files even when they are public corpus»: Because the next person will run them on a host. If the thread slides toward a live target, lock it. I will report it. If anyone DMs me a zip I will not open it. Hash in-thread.
@l0gic
I disagree with the tone, not the bytes. «Why we do not attach crashing files even when they are public corpus» â specifically Because the n
This is getting personal and it does not need to. This is the writeup I wanted when I was stuck. «Why we do not attach crashing files even when they are public corpus» â specifically Because the next person will run them on a host. If you wrap memcpy, I want the check on every path. Version in my shot: current lab snapshot, not last year's blog.
Good. Dated shot, version in the post. «Why we do not attach crashing files even when they are public corpus» â specifically Because the next person will run them on a host. Vendor bump is patch Tuesday. Forgotten trees grow extra years. I will +rep a listing and ârep a vibe. That is the deal.
Also: Date your heap notes. 2012 grooming diagrams are history.
@matrx
Good. Dated shot, version in the post. «Why we do not attach crashing files even when they are public corpus» â specifically Because the nex
That insult was not a technical point. I am reporting it. I dumped after OEP and then did this. «Why we do not attach crashing files even when they are public corpus» â specifically Because the next person will run them on a host. Canonicalize last. Concatenate after realpath is how .. comes back. Version in my shot: current lab snapshot, not last year's blog.
@zero
I want the listing, not the decompiler story. The load-bearing line: Because the next person will run them on a host. Canonicalize last. Con
If you cannot paste bytes, you do not have a counterexample. Good. Dated shot, version in the post. «Why we do not attach crashing files even when they are public corpus» â specifically Because the next person will run them on a host. If you wrap memcpy, I want the check on every path. Which build of the tool? I got burned mixing notes across versions. Took me 8 hours the first time.
I dumped after OEP and then did this. On «Why we do not attach crashing files even when they are public corpus»: Because the next person will run them on a host. If you wrap memcpy, I want the check on every path. I reproduced it on lab build 1112.
Also: Vendor bump is patch Tuesday. Forgotten trees grow extra years.
@black
I dumped after OEP and then did this. On «Why we do not attach crashing files even when they are public corpus»: Because the next person wil
Decompiler output is a hypothesis. Treat it like one. Came back to this after a coffee. Still hold. On «Why we do not attach crashing files even when they are public corpus»: Because the next person will run them on a host. Vendor bump is patch Tuesday. Forgotten trees grow extra years. I still have the snapshot named expl-252-pre.
@cloud
I disagree with the tone, not the bytes. «Why we do not attach crashing files even when they are public corpus» â specifically Because the n
I reproduced it twice before I believed you. The load-bearing line: Because the next person will run them on a host. system() on a user path is the class. execve with argv is the patch. I will +rep a listing and ârep a vibe. That is the deal.
This matches a public n-day class from last patch Tuesday. You wrote «Because the next person will run them on a host». That is the sentence I keep. Patched class only. Hunt the old immediate. Do not ask for a trigger file. I will +rep a listing and ârep a vibe. That is the deal.
The screenshot is the useful part of the post. You wrote «Because the next person will run them on a host». That is the sentence I keep. If the thread slides toward a live target, lock it. I will report it. Which build of the tool? I got burned mixing notes across versions. I reproduced it on lab build 1133.
Also: Patched class only. Hunt the old immediate. Do not ask for a trigger file.
@blk
I reproduced it twice before I believed you. The load-bearing line: Because the next person will run them on a host. OOB read is a leak unti
This belongs in the first-hour ritual. «Why we do not attach crashing files even when they are public corpus» â specifically Because the next person will run them on a host. OOB read is a leak until proven otherwise. In the notes, not in a PoC. Same class as the January thread, different binary.
@build
This belongs in the first-hour ritual. «Why we do not attach crashing files even when they are public corpus» â specifically Because the nex
That is a vibe. I asked for a listing offset. Same wall I hit last quarter. «Why we do not attach crashing files even when they are public corpus» â specifically Because the next person will run them on a host. If you wrap memcpy, I want the check on every path. I will +rep a listing and ârep a vibe. That is the deal.
Quietly the best note on this board this month. «Why we do not attach crashing files even when they are public corpus» â specifically Because the next person will run them on a host. If you wrap memcpy, I want the check on every path. I still have the snapshot named expl-252-pre.
@cloudx
Quietly the best note on this board this month. «Why we do not attach crashing files even when they are public corpus» â specifically Becaus
If you cannot paste bytes, you do not have a counterexample. This belongs in the first-hour ritual. «Why we do not attach crashing files even when they are public corpus» â specifically Because the next person will run them on a host. system() on a user path is the class. execve with argv is the patch. 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.
I disagree with the tone, not the bytes. «Why we do not attach crashing files even when they are public corpus» â specifically Because the next person will run them on a host. OOB read is a leak until proven otherwise. In the notes, not in a PoC. Did page heap see it, or only the sanitizer? Same class as the October thread, different binary.
@intelx
Not fully convinced yet. On «Why we do not attach crashing files even when they are public corpus»: Because the next person will run them on
Decompiler output is a hypothesis. Treat it like one. Good. Dated shot, version in the post. «Why we do not attach crashing files even when they are public corpus» â specifically Because the next person will run them on a host. If you wrap memcpy, I want the check on every path. Took me 4 hours the first time.
@labs
Agreed on the class, not on the tool. «Why we do not attach crashing files even when they are public corpus» â specifically Because the next
This belongs in the first-hour ritual. «Why we do not attach crashing files even when they are public corpus» â specifically Because the next person will run them on a host. A saturating add that hangs is not a complete patch. Hunt the hang too. Same class as the June thread, different binary.
@netrix
I dumped after OEP and then did this. «Why we do not attach crashing files even when they are public corpus» â specifically Because the next
Bookmarking this for the lab wiki. On «Why we do not attach crashing files even when they are public corpus»: Because the next person will run them on a host. Vendor bump is patch Tuesday. Forgotten trees grow extra years. I still have the snapshot named expl-252-pre.
@netsec
I ran this on a licensed corpus binary. The load-bearing line: Because the next person will run them on a host. Canonicalize last. Concatena
You keep moving the goalposts. First it was the decoder, now it is the dump. I reproduced it twice before I believed you. On «Why we do not attach crashing files even when they are public corpus»: Because the next person will run them on a host. Vendor bump is patch Tuesday. Forgotten trees grow extra years. Same class as the June thread, different binary.
@flarex
I reproduced it twice before I believed you. You wrote «Because the next person will run them on a host». That is the sentence I keep. OOB r
The graph hid it. The listing did not. Trust the listing. Came back to this after a coffee. Still hold. You wrote «Because the next person will run them on a host». That is the sentence I keep. Date your heap notes. 2012 grooming diagrams are history. I reproduced it on lab build 1395.
@freqx
Came back to this after a coffee. Still hold. You wrote «Because the next person will run them on a host». That is the sentence I keep. Date
Please keep the hashes and drop the mystery zips. You wrote «Because the next person will run them on a host». That is the sentence I keep. If the thread slides toward a live target, lock it. I will report it. I still have the snapshot named expl-252-pre.
@analytx
Please keep the hashes and drop the mystery zips. On «Why we do not attach crashing files even when they are public corpus»: Because the nex
You keep moving the goalposts. First it was the decoder, now it is the dump. I would have written the opposite conclusion a year ago. You wrote «Because the next person will run them on a host». That is the sentence I keep. Canonicalize last. Concatenate after realpath is how .. comes back. Pinned a comment at 0x1400049b4 in the listing.
Same wall I hit last quarter. The load-bearing line: Because the next person will run them on a host. Patched class only. Hunt the old immediate. Do not ask for a trigger file. Hash of the public file, or are we arguing a shape? I reproduced it on lab build 1196.
If you only have the decompiler, you do not have the bug. You wrote «Because the next person will run them on a host». That is the sentence I keep. Vendor bump is patch Tuesday. Forgotten trees grow extra years. I wrote a 12-line script and then threw it away. The listing was enough.
@danprodigy
I reproduced it twice before I believed you. The load-bearing line: Because the next person will run them on a host. A saturating add that h
You keep moving the goalposts. First it was the decoder, now it is the dump. This matches a public n-day class from last patch Tuesday. The load-bearing line: Because the next person will run them on a host. system() on a user path is the class. execve with argv is the patch. Same class as the October thread, different binary.
@kelnnode
If you only have the decompiler, you do not have the bug. You wrote «Because the next person will run them on a host». That is the sentence
That is a vibe. I asked for a listing offset. Agreed on the class, not on the tool. «Why we do not attach crashing files even when they are public corpus» â specifically Because the next person will run them on a host. A saturating add that hangs is not a complete patch. Hunt the hang too. Pinned a comment at 0x1400007a0 in the listing.
I will argue the opposite and then probably agree. The load-bearing line: Because the next person will run them on a host. No samples, even public corpus files. Hashes and links. Attachments get pulled. Which build of the tool? I got burned mixing notes across versions. I will +rep a listing and ârep a vibe. That is the deal.
@oladipupo
Bookmarking this for the lab wiki. On «Why we do not attach crashing files even when they are public corpus»: Because the next person will r
I am reporting the sample-drop hint. Hash and corpus tag only. I failed this exact class in January. On «Why we do not attach crashing files even when they are public corpus»: Because the next person will run them on a host. Canonicalize last. Concatenate after realpath is how .. comes back. Did page heap see it, or only the sanitizer? Pinned a comment at 0x1400069c5 in the listing.
@ismailtrend
Agreed on the class, not on the tool. You wrote «Because the next person will run them on a host». That is the sentence I keep. system() on
I am reporting the sample-drop hint. Hash and corpus tag only. Not fully convinced yet. The load-bearing line: Because the next person will run them on a host. Canonicalize last. Concatenate after realpath is how .. comes back. What did you key the join on â PID or process GUID? I wrote a 12-line script and then threw it away. The listing was enough.
@grey
Please keep the hashes and drop the mystery zips. You wrote «Because the next person will run them on a host». That is the sentence I keep.
Stop flexing an IDA license. The question was the unwind info. I dumped after OEP and then did this. On «Why we do not attach crashing files even when they are public corpus»: Because the next person will run them on a host. Canonicalize last. Concatenate after realpath is how .. comes back. I reproduced it on lab build 1349.
Came back to this after a coffee. Still hold. You wrote «Because the next person will run them on a host». That is the sentence I keep. If you wrap memcpy, I want the check on every path. Did page heap see it, or only the sanitizer? I reproduced it on lab build 1266.
@charleswise
Came back to this after a coffee. Still hold. You wrote «Because the next person will run them on a host». That is the sentence I keep. If y
This is getting personal and it does not need to. I disagree with the tone, not the bytes. «Why we do not attach crashing files even when they are public corpus» â specifically Because the next person will run them on a host. Canonicalize last. Concatenate after realpath is how .. comes back. Same class as the October thread, different binary.
@iam_sammy
Same wall I hit last quarter. The load-bearing line: Because the next person will run them on a host. Patched class only. Hunt the old immed
Calling the sticky 'priest talk' is how you earn a ban note. I dumped after OEP and then did this. The load-bearing line: Because the next person will run them on a host. system() on a user path is the class. execve with argv is the patch. Pinned a comment at 0x140002b58 in the listing.
@rr_or_gtfo
I tried the naive path first and wasted a morning. «Why we do not attach crashing files even when they are public corpus» â specifically Bec
Stop flexing an IDA license. The question was the unwind info. This is the writeup I wanted when I was stuck. You wrote «Because the next person will run them on a host». That is the sentence I keep. A saturating add that hangs is not a complete patch. Hunt the hang too. Same class as the October thread, different binary.
@hex_olga
Good. Dated shot, version in the post. «Why we do not attach crashing files even when they are public corpus» â specifically Because the nex
Please keep the hashes and drop the mystery zips. On «Why we do not attach crashing files even when they are public corpus»: Because the next person will run them on a host. No samples, even public corpus files. Hashes and links. Attachments get pulled. I will +rep a listing and ârep a vibe. That is the deal.
@babatunde_k
The screenshot is the useful part of the post. You wrote «Because the next person will run them on a host». That is the sentence I keep. If
Calling the sticky 'priest talk' is how you earn a ban note. I reproduced it twice before I believed you. The load-bearing line: Because the next person will run them on a host. OOB read is a leak until proven otherwise. In the notes, not in a PoC. If anyone DMs me a zip I will not open it. Hash in-thread.
I ran this on a licensed corpus binary. The load-bearing line: Because the next person will run them on a host. Canonicalize last. Concatenate after realpath is how .. comes back. I wrote a 12-line script and then threw it away. The listing was enough.
Came back to this after a coffee. Still hold. You wrote «Because the next person will run them on a host». That is the sentence I keep. Patched class only. Hunt the old immediate. Do not ask for a trigger file. Version in my shot: current lab snapshot, not last year's blog.
@patch
Came back to this after a coffee. Still hold. You wrote «Because the next person will run them on a host». That is the sentence I keep. Patc
Decompiler output is a hypothesis. Treat it like one. This belongs in the first-hour ritual. «Why we do not attach crashing files even when they are public corpus» â specifically Because the next person will run them on a host. Patched class only. Hunt the old immediate. Do not ask for a trigger file. Same class as the March thread, different binary.
@crypta
I reproduced it twice before I believed you. The load-bearing line: Because the next person will run them on a host. system() on a user path
That insult was not a technical point. I am reporting it. I will argue the opposite and then probably agree. On «Why we do not attach crashing files even when they are public corpus»: Because the next person will run them on a host. Date your heap notes. 2012 grooming diagrams are history. I reproduced it on lab build 1269.
Agreed on the class, not on the tool. «Why we do not attach crashing files even when they are public corpus» â specifically Because the next person will run them on a host. Canonicalize last. Concatenate after realpath is how .. comes back. Version in my shot: current lab snapshot, not last year's blog.
@derekconnect
This matches a public n-day class from last patch Tuesday. You wrote «Because the next person will run them on a host». That is the sentence
I am reporting the sample-drop hint. Hash and corpus tag only. I will argue the opposite and then probably agree. You wrote «Because the next person will run them on a host». That is the sentence I keep. system() on a user path is the class. execve with argv is the patch. Did you snapshot before, or is this a restore-from-memory story? If anyone DMs me a zip I will not open it. Hash in-thread.
@meshx
I tried the naive path first and wasted a morning. On «Why we do not attach crashing files even when they are public corpus»: Because the ne
Stop flexing an IDA license. The question was the unwind info. I failed this exact class in January. «Why we do not attach crashing files even when they are public corpus» â specifically Because the next person will run them on a host. Date your heap notes. 2012 grooming diagrams are history. My note id for this: fc-87.
I tried the naive path first and wasted a morning. «Why we do not attach crashing files even when they are public corpus» â specifically Because the next person will run them on a host. If you wrap memcpy, I want the check on every path. My note id for this: fc-66.
I reproduced it twice before I believed you. You wrote «Because the next person will run them on a host». That is the sentence I keep. OOB read is a leak until proven otherwise. In the notes, not in a PoC. My note id for this: fc-44.
Also: If you wrap memcpy, I want the check on every path.
@freshmode
I will argue the opposite and then probably agree. The load-bearing line: Because the next person will run them on a host. No samples, even
This is getting personal and it does not need to. Not fully convinced yet. «Why we do not attach crashing files even when they are public corpus» â specifically Because the next person will run them on a host. If you wrap memcpy, I want the check on every path. Pinned a comment at 0x1400022e1 in the listing.
@loader
This belongs in the first-hour ritual. «Why we do not attach crashing files even when they are public corpus» â specifically Because the nex
If you cannot paste bytes, you do not have a counterexample. If you only have the decompiler, you do not have the bug. You wrote «Because the next person will run them on a host». That is the sentence I keep. Vendor bump is patch Tuesday. Forgotten trees grow extra years. Which build of the tool? I got burned mixing notes across versions. I will +rep a listing and ârep a vibe. That is the deal.
@proxyx
This belongs in the first-hour ritual. «Why we do not attach crashing files even when they are public corpus» â specifically Because the nex
Not fully convinced yet. «Why we do not attach crashing files even when they are public corpus» â specifically Because the next person will run them on a host. A saturating add that hangs is not a complete patch. Hunt the hang too. After you did that, did the decompiler pick it up or did you dump? Took me 10 hours the first time.
@prosmart
Agreed on the class, not on the tool. «Why we do not attach crashing files even when they are public corpus» â specifically Because the next
The graph hid it. The listing did not. Trust the listing. This matches a public n-day class from last patch Tuesday. On «Why we do not attach crashing files even when they are public corpus»: Because the next person will run them on a host. Vendor bump is patch Tuesday. Forgotten trees grow extra years. I reproduced it on lab build 1054.
I tried the naive path first and wasted a morning. On «Why we do not attach crashing files even when they are public corpus»: Because the next person will run them on a host. Vendor bump is patch Tuesday. Forgotten trees grow extra years. Pinned a comment at 0x140002ec2 in the listing.
I can just drop the crashing file here, it is public corpus anyway. Stop being priests about attachments.
@flux
drop the crashing file
No. Hash + public corpus link. Attachments get pulled. You know this.
You are all cowards. Here is a mega link, password is in the DM. Run it on a host I do not care.
That is a sample drop and a host-run dare. Reported.
banned hannayara â live sample drop + telling people to run it on a host. Permanent. Thread stays as the record. Locked.
@emmyfresh
This is the kind of thread that should be a sticky and is not. The load-bearing line: Because the next person will run them on a host. syste
Decompiler output is a hypothesis. Treat it like one. The screenshot is the useful part of the post. «Why we do not attach crashing files even when they are public corpus» â specifically Because the next person will run them on a host. Vendor bump is patch Tuesday. Forgotten trees grow extra years. I will +rep a listing and ârep a vibe. That is the deal.
@heapx
I disagree with the tone, not the bytes. On «Why we do not attach crashing files even when they are public corpus»: Because the next person
That insult was not a technical point. I am reporting it. Please keep the hashes and drop the mystery zips. On «Why we do not attach crashing files even when they are public corpus»: Because the next person will run them on a host. system() on a user path is the class. execve with argv is the patch. I reproduced it on lab build 1168.
@richmondx
Not fully convinced yet. «Why we do not attach crashing files even when they are public corpus» â specifically Because the next person will
This is getting personal and it does not need to. I failed this exact class in January. «Why we do not attach crashing files even when they are public corpus» â specifically Because the next person will run them on a host. Canonicalize last. Concatenate after realpath is how .. comes back. I will +rep a listing and ârep a vibe. That is the deal.
I ran this on a licensed corpus binary. You wrote «Because the next person will run them on a host». That is the sentence I keep. No samples, even public corpus files. Hashes and links. Attachments get pulled. My note id for this: fc-26.
I reproduced it twice before I believed you. The load-bearing line: Because the next person will run them on a host. A saturating add that hangs is not a complete patch. Hunt the hang too. I wrote a 12-line script and then threw it away. The listing was enough.
@dfir
This matches a public n-day class from last patch Tuesday. The load-bearing line: Because the next person will run them on a host. system()
This is the kind of thread that should be a sticky and is not. The load-bearing line: Because the next person will run them on a host. system() on a user path is the class. execve with argv is the patch. Took me 8 hours the first time.
I failed this exact class in January. On «Why we do not attach crashing files even when they are public corpus»: Because the next person will run them on a host. Canonicalize last. Concatenate after realpath is how .. comes back. If anyone DMs me a zip I will not open it. Hash in-thread.
Also: Date your heap notes. 2012 grooming diagrams are history.
I disagree with the tone, not the bytes. On «Why we do not attach crashing files even when they are public corpus»: Because the next person will run them on a host. If the thread slides toward a live target, lock it. I will report it. If anyone DMs me a zip I will not open it. Hash in-thread.
@secbit
I ran this on a licensed corpus binary. You wrote «Because the next person will run them on a host». That is the sentence I keep. No samples
Stop flexing an IDA license. The question was the unwind info. Please keep the hashes and drop the mystery zips. On «Why we do not attach crashing files even when they are public corpus»: Because the next person will run them on a host. Patched class only. Hunt the old immediate. Do not ask for a trigger file. Took me 4 hours the first time.
@ibrahimvibe
Please keep the hashes and drop the mystery zips. On «Why we do not attach crashing files even when they are public corpus»: Because the nex
Agreed on the class, not on the tool. You wrote «Because the next person will run them on a host». That is the sentence I keep. system() on a user path is the class. execve with argv is the patch. I still have the snapshot named expl-252-pre.
Good. Dated shot, version in the post. «Why we do not attach crashing files even when they are public corpus» â specifically Because the next person will run them on a host. If you wrap memcpy, I want the check on every path. I still have the snapshot named expl-252-pre.
Also: If you wrap memcpy, I want the check on every path.
@labsec
Good. Dated shot, version in the post. «Why we do not attach crashing files even when they are public corpus» â specifically Because the nex
The graph hid it. The listing did not. Trust the listing. I dumped after OEP and then did this. You wrote «Because the next person will run them on a host». That is the sentence I keep. OOB read is a leak until proven otherwise. In the notes, not in a PoC. If anyone DMs me a zip I will not open it. Hash in-thread.
@slim_tony
Please keep the hashes and drop the mystery zips. On «Why we do not attach crashing files even when they are public corpus»: Because the nex
Please keep the hashes and drop the mystery zips. The load-bearing line: Because the next person will run them on a host. Canonicalize last. Concatenate after realpath is how .. comes back. Is the hang the incomplete patch, or a second bug? If anyone DMs me a zip I will not open it. Hash in-thread.
@smartken
I failed this exact class in January. On «Why we do not attach crashing files even when they are public corpus»: Because the next person wil
That insult was not a technical point. I am reporting it. Agreed on the class, not on the tool. On «Why we do not attach crashing files even when they are public corpus»: Because the next person will run them on a host. No samples, even public corpus files. Hashes and links. Attachments get pulled. Took me 12 hours the first time.
@stackx
Please keep the hashes and drop the mystery zips. The load-bearing line: Because the next person will run them on a host. Canonicalize last.
Calling the sticky 'priest talk' is how you earn a ban note. I disagree with the tone, not the bytes. «Why we do not attach crashing files even when they are public corpus» â specifically Because the next person will run them on a host. A saturating add that hangs is not a complete patch. Hunt the hang too. I will +rep a listing and ârep a vibe. That is the deal.
This is the kind of thread that should be a sticky and is not. «Why we do not attach crashing files even when they are public corpus» â specifically Because the next person will run them on a host. Date your heap notes. 2012 grooming diagrams are history. I still have the snapshot named expl-252-pre.
@threx
This is the kind of thread that should be a sticky and is not. «Why we do not attach crashing files even when they are public corpus» â spec
I am reporting the sample-drop hint. Hash and corpus tag only. I disagree with the tone, not the bytes. «Why we do not attach crashing files even when they are public corpus» â specifically Because the next person will run them on a host. system() on a user path is the class. execve with argv is the patch. Did you force-create the function or did auto-analysis luck into it? I will +rep a listing and ârep a vibe. That is the deal.
I still keep a paper notebook for this kind of note. «Why we do not attach crashing files even when they are public corpus» â specifically Because the next person will run them on a host. Canonicalize last. Concatenate after realpath is how .. comes back. I wrote a 12-line script and then threw it away. The listing was enough.
@vibeking
I still keep a paper notebook for this kind of note. «Why we do not attach crashing files even when they are public corpus» â specifically B
That is a vibe. I asked for a listing offset. Bookmarking this for the lab wiki. You wrote «Because the next person will run them on a host». That is the sentence I keep. Date your heap notes. 2012 grooming diagrams are history. Same class as the January thread, different binary.
@victor_lee
I disagree with the tone, not the bytes. «Why we do not attach crashing files even when they are public corpus» â specifically Because the n
This matches a public n-day class from last patch Tuesday. «Why we do not attach crashing files even when they are public corpus» â specifically Because the next person will run them on a host. Vendor bump is patch Tuesday. Forgotten trees grow extra years. I reproduced it on lab build 1347.
I want the listing, not the decompiler story. The load-bearing line: Because the next person will run them on a host. Canonicalize last. Concatenate after realpath is how .. comes back. I reproduced it on lab build 1376.
@white
This matches a public n-day class from last patch Tuesday. «Why we do not attach crashing files even when they are public corpus» â specific
The graph hid it. The listing did not. Trust the listing. Good. Dated shot, version in the post. «Why we do not attach crashing files even when they are public corpus» â specifically Because the next person will run them on a host. If you wrap memcpy, I want the check on every path. I will +rep a listing and ârep a vibe. That is the deal.