[antisocial]

I contacted him about this some time ago when Darkforums was down, so i did not get the time to send in the report.

Report is about @ExploitSeller - /Thread-Selling-iOS-26-0day-Exploit-Selling - /Thread-Selling-0day-Android-16-Exploit-Exploit-Chain-Selling?highlight=android

So i wondered when i saw ONE single person having both a android AND a IOS full chain RCE for sale, so i contacted him.

I got a proof of concept video, so i inspected it, first of all it looks like all of the terminal logs are straight out of a holy wood movie, not realistic for an actual exploit, and looks AI generated. - https://qu.ax/15hId

Now to the actual dumb logic behind this exploit, he shows very logical commands, until he shows "scp root@156.xxx.xxx.xxx:/var/mobile/Library/Files/media/abc.jpg /home/kali/Desktop/iOS/downloads/" - first of all scp is never installed by default on any jailbroken IOS device. And this command broken down would NOT transfer the actual picture from the kali instance onto the iphone that does not just have an SCP running and able to be used there, it tries to PULL the image FROM the iphone onto the kali desktop. So it is basically running a SCP command to connect to the SAME device and then transfer that to a remote host that it does not know about? And it tries to save this picture in /home/kali but that folder is on the Kali instance, not the IOS phone?? basically they typed a command ON THE IPHONE that should actually be typed from the laptop. It simply does not work that way. And on top of all of this "var/mobile/Library/Files/media/abc.jpg" is not the real image path on Darwin im pretty sure they are usually like "/var/mobile/Media/DCIM" or "/var/mobile/Library/Photos" 

Now to the actual timing of these messages, these have ACTUAL time.sleep(0.3) events it does NOT go that exact in timing it is more instant on pwn stuff, at-least not that type of timing. All of these things are hard-coded and hard-coded timings of it. Basically the intervals between each log are unrealistic for an ACTUAL exploit.

And legit NOBODY writes a real kernel exploit like this: "[+] Injecting malicious code... Done!" 

And printing "Establishing persistent backdoor" serves no other function then to trick a viewer.

He cleared chats, but he simply tried to completely ignore my argument that that scp command is not possible.

He claims that he is just the broker not the developer/researcher, but any zero-day broker should have their own team of researchers to both verify, and research it themselves to confirm, and most brokers HAVE THAT, and that is NEEDED if you claim to have a full chain RCE for both Android AND IoS.

And he also said that " SandMan, [22/12/2025 23:41]
The developer we were in contact with has now stopped selling exploits anonymously, so I have to work with a new developer, but last week we sold the exploit shellcode to a client, and the client is using the exploit by integrating it with their agent. " - meaning he sells the same 0day AND the same shellcode to MULTIPLE people? as soon as two or three people use an exploit, it usually gets caught by Apple's analytics team or security teams. Making that 2.5M$ investment fully worthless for everyone else. And if its sold to multiple people it would be legit burning Apple's telemetry actively. And no legitimate buyers pay $2.5M for a non-exclusive 0day thats being shared

https://qu.ax/MP8iB - "Shellcode contains only the executable file of the exploit, not the full exploit." - this is technically false. He is basically saying the shellcode is a standalone executable "product", thats just completely restarted.

He then goes on to use the excuse: "The developer we were in contact with has now stopped... I have to work with a new developer.", which is pathetic and if the old developer is gone, why is he using the old developer's fake video to sell the new developer's product?

He claims that this sold shellcode was used by the group he sold it to and it worked? well full chain IOS 0days are VERY VERY rare, like there pops-up maybe 1-2 a year max.

And in the actual market, high-value exploits like $2M-$7M would NEVER be sold to "many people". Any broker would always buy exclusive rights to keep the method secret for as long as possible. No one pays millions for a "shared" tool, thats just not logical at all.

And this whole "developer description of the exploit" is also 100% AI, both something you can realize and see manually and systematically - https://qu.ax/LwT1J

More proofs: https://qu.ax/DxlHO - https://qu.ax/x20B2 - https://qu.ax/5UTzh - https://qu.ax/zJoOI - https://qu.ax/hOPk5 - tg id: 6375562859

THE VIDEO THAT HE SENT: https://qu.ax/Y6jlC

Code:

SandMan, [16/12/2025 22:29]
I am just seller, the developer is someone else.

SandMan, [22/12/2025 22:18]
Do you want any exploit?

x, [22/12/2025 22:18]
I do not trust it enough, sorry.

SandMan, [22/12/2025 22:19]
I have PoC if you need

x, [22/12/2025 22:34]
Please do send then.

SandMan, [22/12/2025 22:48]
iOS 26 Exploit PoC
ZeroClick

x, [22/12/2025 23:00]
this command is not logical

x, [22/12/2025 23:00]
so you are running a scp command to connect to the SAME device and then
transfer that to a remote host that it does not know about?

x, [22/12/2025 23:04]
And the intervals between each log are unrealistic for an actual exploit.

SandMan, [22/12/2025 23:18]
1. Understanding the Execution Flow of the iOS 0-Day Exploit

The PoC represents a structured exploitation chain targeting a
previously undisclosed (0-day) vulnerability in iOS 26. The execution
flow is carefully designed based on comprehensive research and internal
validation, ensuring a logical and practical sequence for successful
exploitation.

Exploit Phases Overview:
Initial Access: The PoC leverages a memory corruption vulnerability
within the iMessage processing stack, which allows remote code execution
upon payload delivery.
Payload Execution: After successful injection, the exploit uses
privilege escalation techniques to gain root access, bypassing security
mechanisms such as PAC (Pointer Authentication Codes) and AMFI (Apple
Mobile File Integrity).
Persistence: The PoC incorporates methods to establish persistence
without user interaction, ensuring continued access even after reboot or
re-authentication.
Each step is necessary to demonstrate the exploit’s effectiveness while
maintaining operational security and integrity. We are happy to provide
additional insights or detailed step-by-step analysis to align
expectations with the technical aspects of the exploit.

2. Justification for the Print Statements in the PoC
We acknowledge the concern regarding the verbosity of the output in the
PoC. However, the print statements serve several critical purposes:
Execution Traceability: They provide a transparent view of the
exploit’s progress, ensuring each step is documented for validation and
debugging purposes.
Operational Security: By logging key points, we can monitor
success/failure rates across different test environments without
exposing unnecessary technical details.
Demonstration Clarity: The PoC is structured to be self-explanatory for
internal review and documentation purposes, enabling stakeholders to
understand each stage without deep technical intervention.
If required, we can provide a refined version of the PoC with minimized output to focus purely on the exploit’s core actions.
3. Device Information Extraction Validation
The PoC does indeed retrieve critical device information, including but not limited to:
Device model (e.g., iPhone 17)
iOS version (26)

Security policies and entitlements active on the device
If there are specific attributes expected to be retrieved beyond the
current scope, we can extend the PoC to capture additional system
details as per your requirements. However, it is important to note that
certain system-level details are obfuscated or protected within newer
iOS versions, and our current approach prioritizes stealth and minimal
footprint.

4. Establishing the Authenticity of the 0-Day Exploit
We assure you that this PoC is not fabricated, and it has undergone
rigorous testing under multiple scenarios to confirm its viability. As a
0-day exploit, disclosure is handled with extreme caution, and every
step included in the PoC has been validated in controlled environments.
To further demonstrate the PoC’s legitimacy, we are prepared to:
Conduct a live demonstration under mutually agreed conditions to showcase the exploit in real-time.
Provide a detailed technical report, including memory dumps, logs, and forensic evidence of the exploit’s success.
Share a sanitized version of the PoC (under NDA if necessary) for independent verification within your security teams.
We are committed to maintaining transparency while ensuring the exploit remains within responsible disclosure guidelines.

SandMan, [22/12/2025 23:18]
Justification from the developer's side

x, [22/12/2025 23:19]
Still does not explain the obvious incorrect use of scp

x, [22/12/2025 23:20]

x, [22/12/2025 23:20]
And that is straight up AI generated

SandMan, [22/12/2025 23:22]
If you are interested in purchasing the exploit, please send me all
your questions and I will get the answers from the developer and provide
them to you.

If you think this is fake, then there is no point in talking further.

x, [22/12/2025 23:22]
I don't think i know, and we BOTH know it.

x, [22/12/2025 23:22]
This is very poorly constructed scam

SandMan, [22/12/2025 23:23]
You are free to think whatever you want.

x, [22/12/2025 23:24]
No if it really is real then properly explain the obvious inconsistencies

x, [22/12/2025 23:24]
That scp command would obviously fail?

SandMan, [22/12/2025 23:29]
I've sent your question to the developer and will let you know as soon as I hear back.

x, [22/12/2025 23:30]
Sounds good, and it is really unprofessional of a 0day developer to give a AI generated description of a exploit?

x, [22/12/2025 23:34]
And it is not good for you're reputation to be working with such unprofessionalism.

SandMan, [22/12/2025 23:41]
The developer we were in contact with has now stopped selling exploits
anonymously, so I have to work with a new developer, but last week we
sold the exploit shellcode to a client, and the client is using the
exploit by integrating it with their agent.

x, [22/12/2025 23:41]
I'm 90% sure of this developer being a fraud, and a 0day should not be sold to multiple individuals?

SandMan, [22/12/2025 23:44]
Don't worry, I only deal with new developers through escrow.
Source code sells to just one person, shellcode sells to many.

[KaruHunters]

@ Tanaka broo?

[Knox]

@ExploitSeller any respond ?

[antisocial]

@ Knox - the guy has been online multiple times since the post of this scam report and has most definitely seen it.

[Knox]

Banned .