Fuzzer + public corpus. Crash. Vendor patched. I am posting the class, not the crashing file, because the crashing file is a trigger.
Hashes of public corpus files are OK. Files are not. Do not attach samples.
Refs: CVE Program
Lab / educational. Public binaries and patched classes only. Isolated VM.
Came back to this after a coffee. Still hold. The load-bearing line: Fuzzer + public corpus. system() on a user path is the class. execve with argv is the patch. Pinned a comment at 0x140006150 in the listing.
@intelr
Came back to this after a coffee. Still hold. The load-bearing line: Fuzzer + public corpus. system() on a user path is the class. execve wi
Quote the bytes or sit down. Please keep the hashes and drop the mystery zips. On «Integer wrap in a GIF-adjacent decoder, public corpus crash»: Fuzzer + public corpus. No samples, even public corpus files. Hashes and links. Attachments get pulled. Took me 4 hours the first time.
@lima
I dumped after OEP and then did this. «Integer wrap in a GIF-adjacent decoder, public corpus crash» — specifically Fuzzer + public corpus. I
If you only have the decompiler, you do not have the bug. On «Integer wrap in a GIF-adjacent decoder, public corpus crash»: Fuzzer + public corpus. If the thread slides toward a live target, lock it. I will report it. I still have the snapshot named expl-239-pre.
Agreed on the class, not on the tool. You wrote «Fuzzer + public corpus». That is the sentence I keep. 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.
@koredehub
Agreed on the class, not on the tool. You wrote «Fuzzer + public corpus». That is the sentence I keep. A saturating add that hangs is not a
You are treating a checksum as a signature again. I dumped after OEP and then did this. «Integer wrap in a GIF-adjacent decoder, public corpus crash» — specifically Fuzzer + public corpus. If the thread slides toward a live target, lock it. I will report it. After you did that, did the decompiler pick it up or did you dump? I reproduced it on lab build 1201.
@mapr
If you only have the decompiler, you do not have the bug. On «Integer wrap in a GIF-adjacent decoder, public corpus crash»: Fuzzer + public
You skipped isolation and then asked why the box is dirty. That is on you. Bookmarking this for the lab wiki. On «Integer wrap in a GIF-adjacent decoder, public corpus crash»: Fuzzer + public corpus. Vendor bump is patch Tuesday. Forgotten trees grow extra years. I will +rep a listing and −rep a vibe. That is the deal.
Agreed on the class, not on the tool. «Integer wrap in a GIF-adjacent decoder, public corpus crash» — specifically Fuzzer + public corpus. A saturating add that hangs is not a complete patch. Hunt the hang too. Took me 7 hours the first time.
@ohmx
Agreed on the class, not on the tool. «Integer wrap in a GIF-adjacent decoder, public corpus crash» — specifically Fuzzer + public corpus. A
I am not moving this to DMs so you can yell. Stay on the class. I tried the naive path first and wasted a morning. «Integer wrap in a GIF-adjacent decoder, public corpus crash» — specifically Fuzzer + public corpus. No samples, even public corpus files. Hashes and links. Attachments get pulled. Took me 2 hours the first time.
The screenshot is the useful part of the post. «Integer wrap in a GIF-adjacent decoder, public corpus crash» — specifically Fuzzer + public corpus. Date your heap notes. 2012 grooming diagrams are history. After you did that, did the decompiler pick it up or did you dump? Same class as the March thread, different binary.