31–40 of 61 posts
It's 2025, and Apple clearly still hasn't incorporated fuzzers in their CI and QA. Perhaps I am giving them too much credit in assuming they have any QA in the first place.
I AirDropped the PoC to my vulnerable iPhone. It didn't cause a crash until I tried to edit it in the Photos app.
The DNG file did have the 01 byte at `2FD00` (from xxd or hexdump -C). However it didn't have a byte position `3E40B`. I tried searching and there is literally no entry at that position. I found a 02 value at 3e40 but not at 3e40b. Is this a typo?
Where did you find it to try and repro?
I AirDropped the PoC to my vulnerable iPhone. It didn't cause a crash until I tried to edit it in the Photos app.
I downloaded the image he provided ( https://www.dpreview.com/sample-galleries/4949897610/pentax-... ) The DNG file did have the 01 byte at `2FD00` (from xxd or hexdump -C). However it didn't have a byte position `3E40B`. I tried searching and there is literally no entry at that position. I found a 02 value at 3e40 but not at 3e40b. Is this a typo? Where did you find it to try and repro?
Earlier quoted context omitted.
I downloaded the image he provided ( https://www.dpreview.com/sample-galleries/4949897610/pentax-... ) The DNG file did have the 01 byte at `2FD00` (from xxd or hexdump -C). However it didn't have a byte position `3E40B`. I tried searching and there is literally no entry at that position. I found a 02 value at 3e40 but not at 3e40b. Is this a typo? Where did you find it to try and repro?
You need to click the link that says "RAW (33.0MB)". The filename should be "IMGP0847.DNG".
Did you find a 02 at 3E40B? I found 01 at 2FD00, but there was no 3E40B byte position entry.
I did find something similar at 00003e40: 00003e40 02 00 04 00 0a 00 00 00 30 01 00 00 00 00 00 00 |........0.......|
Earlier quoted context omitted.
You need to click the link that says "RAW (33.0MB)". The filename should be "IMGP0847.DNG".
Thanks immensely. Very important detail, Did you find a 02 at 3E40B? I found 01 at 2FD00, but there was no 3E40B byte position entry. I did find something similar at 00003e40: 00003e40 02 00 04 00 0a 00 00 00 30 01 00 00 00 00 00 00 |........0.......|
dd status=none if=IMGP0847.DNG bs=1 skip=0x3e40b count=1 | xxd
00000000: 02For iOS defense, enable Lockdown Mode and reboot daily to evict non-persistent malware, https://www.youtube.com/watch?v=fAhTPMmvrB0 > For me, there is only lockdown mode. That is the Apple Experience. iOS backups can be scanned for the presence of this CVE-2025-43300 DNG processing vulnerability, via OSS tool for iOS forensics, https://github.com/msuiche/elegant-bouncer | https://www.msuiche.com/posts/elegantbouncer-…
For iOS defense, enable Lockdown Mode and reboot daily to evict non-persistent malware, https://www.youtube.com/watch?v=fAhTPMmvrB0 > For me, there is only lockdown mode. That is the Apple Experience. iOS backups can be scanned for the presence of this CVE-2025-43300 DNG processing vulnerability, via OSS tool for iOS forensics, https://github.com/msuiche/elegant-bouncer | https://www.msuiche.com/posts/elegantbouncer-…
I would think mvt and related ioc repos would support these newer indicators,but sadly I'm not seeing that: https://docs.mvt.re/en/latest/iocs/
Traditional detection approaches like YARA rules, IOC matching, and signature-based systems fall apart when:
• You don’t have the actual malicious samples to create signatures from
• The attackers use polymorphic techniques that change file hashes
• The exploit leverages legitimate file format features in unexpected ways
• You need to detect future variants of the same technique
The Philosophy: Structure Over Signatures
ELEGANTBOUNCER takes a fundamentally different approach to threat detection. Instead of looking for specific byte patterns or known-bad indicators, it analyzes the structural properties of files that make exploits possible.