
Cyber Security Research Company - https://xitter.cf/t.co/7cy1LNOEWJ - @patchhawk_ - @RedSpider_78
Seoul, S.Korea
Joined June 2022
- Tweets155
- Following126
- Followers504
- Likes198
78ResearchLab retweeted
PatchHawk looks for security fixes in software updates. For selected cases, we share the code change and steps to reproduce the bug: github.com/78ResearchLab/Pat…
Follow @patchhawk_ for more fixes explained through code. #PatchHawk #78ResearchLab
78ResearchLab retweeted
FreeType later changed SHZ, the instruction that moves points in a glyph. It now picks the right set of points and stops at the end of that set. The two cards show the code. This fix came after 2.14.3. github.com/freetype/freetype…
78ResearchLab retweeted
In Docker, we used a small program to load Mozilla's font through FreeType's public FT_Load_Glyph API. ASan found no issue with 2.14.2, but caught a read past the end of a buffer in 2.14.3. Mozilla also reported a write past a buffer. bugzilla.mozilla.org/show_bu…
78ResearchLab retweeted
The change is easy to miss. In 2.14.2, FreeType made room for the glyph's existing points, plus four more. In 2.14.3, it only made room for four. That wasn't enough for some glyphs made from other glyphs. github.com/freetype/freetype…
78ResearchLab retweeted
FreeType 2.14.3 introduced a font rendering bug (CVE-2026-10701). Mozilla reproduced a Firefox crash on Linux by loading a specially made font with medium or full hinting enabled. The bug starts with a check that reserves too little memory.
78ResearchLab retweeted
The groundwork's done. Now the treasure hunt begins. 🏴☠️🐕
We dug into DOGGIE's inner systems, mapping where the weak spots hide. 🔍
Journey log → blog.78researchlab.com/3f9db…
Robot Security, one layer at a time — the 78Lab way.
@78_lab
#UNITREE #robotics #RobotDog #quadrupedrobot
78ResearchLab retweeted
PatchHawk finds security-relevant fixes in release diffs. Selected PoCs include write-ups, repro steps, and pre/post comparisons: github.com/78ResearchLab/Pat…
Follow @patchhawk_ for more fixes explained with real code and verifiable PoCs. #PatchHawk #78ResearchLab
78ResearchLab retweeted
The PoC is now public: github.com/78ResearchLab/Pat…
It includes the 345-byte JXL input, Docker reproduction scripts, 0.11.1/0.11.2 djxl logs, and the Valgrind trace. The README states the tested 32-bit scope and limitations.
78ResearchLab retweeted
Upstream named the fix in v0.11.2: github.com/libjxl/libjxl/rel…
Patch: github.com/libjxl/libjxl/pul…
PatchHawk flagged the arithmetic change; its PoC attempt was incomplete, so we verified the CLI and Valgrind results manually.
78ResearchLab retweeted
The native 32-bit CLI exited 139 on 0.11.1. Version 0.11.2 returned a frame-creation error for the same file; a 256×256 control decoded on both. We did not establish code execution or a downstream network path.
78ResearchLab retweeted
Before the fix, PackedImage::Create() allocated after unchecked size arithmetic. The decoder’s output callback then wrote beyond that buffer. The patch calls VerifyDimensions() first and rejects wrapped stride or total size. The card shows the actual code change.
78ResearchLab retweeted
The JXL file holds an 8×8 cropped frame on a 32,768×10,923 canvas. djxl --disable_output still decodes to float RGB pixels. Packed storage would need 4,295,098,368 bytes (2³² + 131,072), which wraps in 32-bit size_t.
78ResearchLab retweeted
libjxl 0.11.2 checks packed-image size before allocation. In our native 32-bit djxl test, a 345-byte JXL file crashed 0.11.1; Valgrind recorded invalid 4-byte writes. 0.11.2 rejects the same file.
78ResearchLab retweeted
PatchHawk finds security-relevant fixes in release diffs. Selected PoCs include write-ups, repro steps, and pre/post comparisons: github.com/78ResearchLab/Pat…
Follow @patchhawk_ for more fixes explained with real code and verifiable PoCs. #PatchHawk #78ResearchLab
78ResearchLab retweeted
Both reproductions use FFmpeg's CLI entry points and are packaged in Docker. They show sanitizer-detected writes; we did not demonstrate code execution or an unsanitized crash.
Ogg PoC: github.com/78ResearchLab/Pat…
Filter PoC: github.com/78ResearchLab/Pat…
78ResearchLab retweeted
That leftover multiplication matters. delay=12180 passes the new 9.0.2 check. In our x86-64 sanitizer build, it overflows and ASan catches a 4-byte heap write just before analysis_buf. The same input faults on 9.0.1. For this build, the 9.0.2 check is incomplete.
78ResearchLab retweeted
Now the filter. On 9.0.1, firequalizer=delay=30000 overflows the FIR-length calculation under UBSan. 9.0.2 rejects that value. But a later signed multiplication, nsamples_max * 2, is still there.
Patch: github.com/FFmpeg/FFmpeg/com…
78ResearchLab retweeted
There's a catch to that Ogg result: FFmpeg's default allocation limit rejects the >4 GB file on both versions. We had to raise -max_alloc to 8 GiB to reach the 9.0.1 fault. The file is sparse, but parsing it still takes real memory and time.
78ResearchLab retweeted
In the Ogg demuxer, buf_realloc() doubled an unsigned buffer size without checking the limit first. Near UINT_MAX/2, that can wrap. On 9.0.1, our raised-limit run hit an ASan invalid write (WRITE of size 31895). On 9.0.2, it returns ENOMEM.
Patch: github.com/FFmpeg/FFmpeg/com…








