Home Upgrade Search Memberlist Extras Hacker Tools Award Goals Help Wiki Contact

Poll: how long?
This poll is closed.
30 minutes
20.00%
1 20.00%
1 hour
20.00%
1 20.00%
2 hours
0%
0 0%
8 hours
0%
0 0%
24 hours
20.00%
1 20.00%
2 days
0%
0 0%
1 week
0%
0 0%
1 month
0%
0 0%
+1 month
40.00%
2 40.00%
Total 5 vote(s) 100%
* You voted for this item. [Show Results]

c++ Crypter SC+exe, AES with CBC mode Polymorphic Encryption 100% FUD

how long will it take you to pull one out?
(Aug 19, 2024 12:23 PM)SovietBastard Wrote:  how long will it take you to pull one out?

Perhaps you could be more specific about what it is we should vote for.

The poll says: "How long". Are you asking how long it takes for us to pull somehing out and show how long it is?

That's disgusting. ^^
(Aug 19, 2024 06:31 PM)James Clown Wrote:  Perhaps you could be more specific about what it is we should vote for.

The poll says: "How long". Are you asking how long it takes for us to pull somehing out and show how long it is?

That's disgusting. ^^

my friend, how long will it take u to write a FUD crypted... i dont expect many to answer less than 1 month
what conditions are we talking about? just static evasion or runtime? if runtime, what would be executed?
(Aug 19, 2024 08:23 PM)ttbr0 Wrote:  what conditions are we talking about? just static evasion or runtime? if runtime, what would be executed?

conditions are those of a corp or big infra, runtime evasion, must perform basic standard data exfiltration, must be able to privesc, must keep persistence for at least 1/2 weeks, etc etc...
(Aug 19, 2024 08:35 PM)SovietBastard Wrote:  conditions are those of a corp or big infra, runtime evasion, must perform basic standard data exfiltration, must be able to privesc, must keep persistence for at least 1/2 weeks, etc etc...

if you say corp or big infra, does that imply edr? if so, does that then imply a soc/blue team? those circumstances are far beyond the scope of what a crypter does. evasion of human analysts is the job of the operator. i dont agree on some of these requirements being the job of a crypter.
(Aug 19, 2024 09:15 PM)ttbr0 Wrote:  if you say corp or big infra, does that imply edr? if so, does that then imply a soc/blue team? those circumstances are far beyond the scope of what a crypter does. evasion of human analysts is the job of the operator. i dont agree on some of these requirements being the job of a crypter.

HOW LONG WILL IT TAKE YOU TO WRITE 100% FUD CRYPTER? i don't care what is being executed, that's the malware job, what im asking is CAN YOU WRITE 100% FUD CRYPTER? either YES or NO, if YES, HOW LONG WILL IT TAKE YOU?


(Aug 19, 2024 08:23 PM)ttbr0 Wrote:  what conditions are we talking about? just static evasion or runtime? if runtime, what would be executed?

again, it doesn't matter what is being executed, that is the job of the malware, not the crypter, the crypter only has one role, crypt the malware, so the above requirements do not matter in the context, the evasion or execution is not the crypter field... do crypters really execute payloads? not really... ...
i would never be able to write a crypter, kind of too complex i guess
(Aug 20, 2024 07:20 AM)SovietBastard Wrote:  HOW LONG WILL IT TAKE YOU TO WRITE 100% FUD CRYPTER? i don't care what is being executed, that's the malware job, what im asking is CAN YOU WRITE 100% FUD CRYPTER? either YES or NO, if YES, HOW LONG WILL IT TAKE YOU?



again, it doesn't matter what is being executed, that is the job of the malware, not the crypter, the crypter only has one role, crypt the malware, so the above requirements do not matter in the context, the evasion or execution is not the crypter field... do crypters really execute payloads? not really... ...

youre attempting to tie the meaning of "crypter fud" with actions that will raise detections that are beyond the responsibilities of the crypter. imo the crypter is only supposed to protect the malware from any detection until the first few moments of execution. beyond that, any action is the responsibility of the payload and the operator. any further features in the stub is counter intuitive and unnecessary, even potentially detrimental because it may bring about undesirable side effects that may increase detection. keep it simple and disposable. the crypter is not meant to facilitate data exfiltration, that is nonsensical.

that being said, a simple crypter is relatively simple to develop but that depends on how fast you write code and how well you want it to scale. its simple to write a quick and dirty crypter within a week but one that supports multiple file types with unique metamorphed stubs on every crypt with infra that has a pipeline to automatically deploy machines with av to test could take many many months to engineer and develop.
(Aug 21, 2024 04:15 AM)ttbr0 Wrote:  youre attempting to tie the meaning of "crypter fud" with actions that will raise detections that are beyond the responsibilities of the crypter. imo the crypter is only supposed to protect the malware from any detection until the first few moments of execution. beyond that, any action is the responsibility of the payload and the operator. any further features in the stub is counter intuitive and unnecessary, even potentially detrimental because it may bring about undesirable side effects that may increase detection. keep it simple and disposable. the crypter is not meant to facilitate data exfiltration, that is nonsensical.

that being said, a simple crypter is relatively simple to develop but that depends on how fast you write code and how well you want it to scale. its simple to write a quick and dirty crypter within a week but one that supports multiple file types with unique metamorphed stubs on every crypt with infra that has a pipeline to automatically deploy machines with av to test could take many many months to engineer and develop.

LOL, I must emphasize that your recent response appears to sidestep the primary objective of the discussion, which is to thoroughly analyze the core issue at hand. In order to facilitate a constructive dialogue, it is essential to address the specific points raised rather than redirecting the conversation towards peripheral themes, this approach not only enhances clarity but also fosters a more productive exchange of ideas, allowing us to reach a consensus or actionable solutions more efficiently, i REALLY encourage you to revisit the salient aspects of the topic for a more substantive interaction moving forward. You did not answer to OP question btw...
(Aug 21, 2024 04:46 AM)super_sayan Wrote:  LOL, I must emphasize that your recent response appears to sidestep the primary objective of the discussion, which is to thoroughly analyze the core issue at hand. In order to facilitate a constructive dialogue, it is essential to address the specific points raised rather than redirecting the conversation towards peripheral themes, this approach not only enhances clarity but also fosters a more productive exchange of ideas, allowing us to reach a consensus or actionable solutions more efficiently, i REALLY encourage you to revisit the salient aspects of the topic for a more substantive interaction moving forward. You did not answer to OP question btw...

its important to clarify and understand all details for a task before knowing what specifics are needed to implement a particular tool and its features. what i have deemed as critical details i have asked for elaboration yet there seems to be disagreements about what constitutes as important pushes back on the conclusions i can make to give an answer, which i have given as an estimate. yet strangely enough you are here using fluff statements and words to put me on the spot to get me to give an answer but not providing your own? so i am here to return your favor, why dont you give us an answer to the question?
(Aug 21, 2024 05:09 AM)ttbr0 Wrote:  its important to clarify and understand all details for a task before knowing what specifics are needed to implement a particular tool and its features. what i have deemed as critical details i have asked for elaboration yet there seems to be disagreements about what constitutes as important pushes back on the conclusions i can make to give an answer, which i have given as an estimate. yet strangely enough you are here using fluff statements and words to put me on the spot to get me to give an answer but not providing your own? so i am here to return your favor, why dont you give us an answer to the question?

😆😆 LMAO i dying ... so funny seeing you trying to correct or collide with SB 🤯, do you even know who the guy is? holy mother, im sure you don't.... if he used the real nickname or just the group is member of, believe me you would stop arguing anything comes out of his mouth and will make you raise your eyebrows over your head... and no, i don't know about crypters, but if you write in PM to SB, maybe he could be generous and teach you something... my answer to SB question is "+1 month" because i don't know much about crypters, see? at least i got a response back, wbu?
(Aug 21, 2024 04:15 AM)ttbr0 Wrote:  youre attempting to tie the meaning of "crypter fud" with actions that will raise detections that are beyond the responsibilities of the crypter. imo the crypter is only supposed to protect the malware from any detection until the first few moments of execution. beyond that, any action is the responsibility of the payload and the operator. any further features in the stub is counter intuitive and unnecessary, even potentially detrimental because it may bring about undesirable side effects that may increase detection. keep it simple and disposable. the crypter is not meant to facilitate data exfiltration, that is nonsensical.

that being said, a simple crypter is relatively simple to develop but that depends on how fast you write code and how well you want it to scale. its simple to write a quick and dirty crypter within a week but one that supports multiple file types with unique metamorphed stubs on every crypt with infra that has a pipeline to automatically deploy machines with av to test could take many many months to engineer and develop.

😆😆😆 my god, that is cringe AF, i will tell you a secret, someone here is making fun of you and you r playing very bad... first rule of a good BH? please answer me this question, what is the first rule for a BH? LOL... pay attention to OP question semantics, he "almost" made it clear, you're not very good at semantic analysis do you?
(Aug 22, 2024 10:35 PM)blyat1337 Wrote:  So much yapping. I already have my full PIC crypter with anti emulation/VM and undetected execution method on every EDR possible.
Took me 1 week of 2 hours a day.

The polyengine took also 1 week.
Overall, it produces 100% unique code every single time.

what do you think about polymorphic vs metamorphic? polymorphic transforms the code so bypasses signature detection, metamorphic bypasses both signature+behavior detection, i feel like building a polymorphic crypter is not easy task, but metamorphic is really complex, what do you think? you seem to be knowledgeable and reasonable guy
(Aug 23, 2024 06:06 AM)blyat1337 Wrote:  Let me start by telling you something straightforward: with crypting, you want to perform less work in order to get more done. Clearly, this isn't functional in the $20/month or $50/month crypters that individuals are attempting to sell here, as those involve "manually" eliminating detections.

For months on end, no one is going to spend 6-7 hours a day by hand "removing" portions of the code in order to "bypass" Defender just to receive $60 for a lifetime license.

Ninety percent of crypters scam or plan to scam after working for a month or two, or they just keep milking a dead cow by selling highly detectable software, because manual is DEAD and simply too hard to maintain.

AI engines are currently the largest problem; Defender is a prime example. What's worse is that every file that is executed or dropped to disk is instantly transmitted to their labs where it is automatically analyzed, categorized, and flagged by DEFENDER (If it is known malware) - This can happen as fast as 10 minutes, chrome flagging is even faster, 2-5 minutes. Because of its strength, the AI engine will be able to identify and flag any additional occurrences of the same stub and they will be categorized as the same group.

Therefore, it only takes one file execution to FLAG a "base" stub and flag any subsequent iterations as well. The AI takes into consideration a lot of factors: Resources, Import hashing, entropy and a lot more.

So why engage in a losing war? Why not put AI to use for your own benefit? Why not host your PIC loader on actual files/ real files? The DEFENDER/other AV database will flag it as "legit" because it is in their database of "good samples" /downloaded samples.

Such files are infinite, and if you use a good Poly engine, you won't even need to work for longer than five minutes.. Morphing PIC shellcode is a lot simpler then morphing a whole PE, and even worse, morphing a whole PE will bring a lot of anomalies which you want to avoid, AI eats them for breakfast.

That is my 2cents.
I don't bother with metamorphic myself, because it is too much for such a simple task which can be achieved by what I specified, as far as runtime it is not the job of a crypter.

If the coder of your malware is an idiot, you will be detected.
You can look at some great malware writers like rhadamanthys, lummac2, xloader. Such software does not require a meta engine for runtime, simply because it was written with evasion in mind.

Heck if you are a real threat actor, you will never use premade software, you write it yourself or pay big $$ for others to do it for you.
People like that are not here, and I am... just a, visitor)

thank you for the reply, yeah, almost always they pull out they're own shit, it is better of course! as i said, you're one of the few if not the only one who sounds knowledgeable here


(Aug 23, 2024 06:06 AM)blyat1337 Wrote:  Let me start by telling you something straightforward: with crypting, you want to perform less work in order to get more done. Clearly, this isn't functional in the $20/month or $50/month crypters that individuals are attempting to sell here, as those involve "manually" eliminating detections.

For months on end, no one is going to spend 6-7 hours a day by hand "removing" portions of the code in order to "bypass" Defender just to receive $60 for a lifetime license.

Ninety percent of crypters scam or plan to scam after working for a month or two, or they just keep milking a dead cow by selling highly detectable software, because manual is DEAD and simply too hard to maintain.

AI engines are currently the largest problem; Defender is a prime example. What's worse is that every file that is executed or dropped to disk is instantly transmitted to their labs where it is automatically analyzed, categorized, and flagged by DEFENDER (If it is known malware) - This can happen as fast as 10 minutes, chrome flagging is even faster, 2-5 minutes. Because of its strength, the AI engine will be able to identify and flag any additional occurrences of the same stub and they will be categorized as the same group.

Therefore, it only takes one file execution to FLAG a "base" stub and flag any subsequent iterations as well. The AI takes into consideration a lot of factors: Resources, Import hashing, entropy and a lot more. Just imagine how strong it is, it has billions of samples, millions new every day.

So why engage in a losing war? Why not put AI to use for your own benefit? Why not host your PIC loader on actual files/ real files? The DEFENDER/other AV database will flag it as "legit" because it is in their database of "good samples" /downloaded samples.

Such files are infinite, and if you use a good Poly engine, you won't even need to work for longer than five minutes.. Morphing PIC shellcode is a lot simpler then morphing a whole PE, and even worse, morphing a whole PE will bring a lot of anomalies which you want to avoid, AI eats them for breakfast.

That is my 2cents.
I don't bother with metamorphic myself, because it is too much for such a simple task which can be achieved by what I specified, as far as runtime it is not the job of a crypter.

If the coder of your malware is an idiot, you will be detected. The job of the crypter is to be a PERFECTLY RUNTIME FUD EXECUTOR, THAT IS ALL. Execute the payload, what happens after, is issue of malware.
You can look at some great malware writers like rhadamanthys, lummac2, xloader. Such software does not require a meta engine for runtime, simply because it was written with evasion in mind.

Heck if you are a real threat actor, you will never use premade software, you write it yourself or pay big $$ for others to do it for you.
People like that are not here, and I am... just a, visitor)

i tried to text u in PM but requires upgrade, what a weird thing, btw... i was about to ask u if u r on exploitdotin


Possibly Related Threads...
Thread / Author Replies Views Last Post
by rspower1 hour ago 29 912 1 hour ago
Last Post: roxroot2222
by The Truman ShowAug 3, 2026 10:36 AM 19 847 Aug 3, 2026 10:36 AM
Last Post: indigo22
[The Brotherhood] by HackersMar 16, 2026 08:48 AM 9 474 Mar 16, 2026 08:48 AM
Last Post: Hackers