Polyloader users

I was digging earlier this day on another site and i saw an example that you posted earlier this year



So the poly-loader create a new decryption process every time you try to compile using XOR format which also apply the source code to use the Decrypt.cpp to understand wtf is going on with this process yet it changes the format of the source code using these declarations, so the question is WHAT VALVE CAN DO TO SIGNATURE THIS HACK, if the compiler it self is changing the decryption format every time you compile. DAFUCK !! and how people reporting that this hack is VACing them O_O !!

Note: Please fix me if i'm wrong because i'm seriously trying to understand the issue here since your hack in my opinion is still safe and some problem occur due to the update (HINT: Users update versions fucked things up for other users [Please check the subtle aim updated version on the forum]).

Okay, i tested alot of different approaches on different accounts

Account 1 : Recompiled once in 3 days (NO VMPROTECT) - VAC
Account 2 : Recompiled once every day (NO VMPROTECT) - VAC
Account 3 : Recompiled every match (NO VMPROTECT) - VAC
Account 4 : Recompiled once in 3 days (VMPROTECT) - NOT VAC'ED
Account 5 : Recompiled once in 2 days (VMPROTECT) - NOT VAC'ED

Okay, i tested alot of different approaches on different accounts

Account 1 : Recompiled once in 3 days (NO VMPROTECT) - VAC
Account 2 : Recompiled once every day (NO VMPROTECT) - VAC
Account 3 : Recompiled every match (NO VMPROTECT) - VAC
Account 4 : Recompiled once in 3 days (VMPROTECT) - NOT VAC'ED
Account 5 : Recompiled once in 2 days (VMPROTECT) - NOT VAC'ED

Really easy, by using wildcards.

Take this example (the number in front is a random byte or smt)

89 detected
34 junk
75 junk
93 junk
56 detected
23 junk
95 detected
84 junk
19 junk
86 junk
38 junk
47 detected

Now you just scan for 89 * 56 * 95 * 47 (* is obvious a wildcard)
If you make this pattern large enough you won't get (m)any false positives.

add me on skype i have couple questions on your approaches

- - - Updated - - -



That means the cheats that we use in the polyloader to randomize it got signature out, but why some got caught and others didn't ?
as u said using wildcards will trigger these pattern of bytes to flag the user if he is using external assists but their something not logic here if the glow esp got signature out the whole scene should be VACed by now yet it didn't, further more isn't poly's work to change these pattern and randomize these junk to make things harder for the VAC system ? so for example:
89 * 56 * 95 * 47 is detected but in the next compile the byte should be different and it will be changed again and again since their is no static byte pattern by the poly so wildcard will be useless here as the pattern (well i dono ) will maybe look like this:

45 junk
34 junk
75 junk
93 junk
35 junk
23 junk
95 detected
84 junk
19 junk
86 junk
38 junk
47 detected
.
.
.

At last moral of the story what do you recommend for the scene about the polyGlow , Subaim , Trigger , and RCS will you encourage them to keep it going or you believe that these cheats got signature by the VAC system which will cause them VAC at the end (and yes guys i said cheats not PolyLoader since poly isn't a cheat -_- ffs).

Regards ShuBek !

Note:
1- Whether what will be your answer i'm seriously impressed by poly it got the potential to stay safe side for more than 1/2 a year and it's a freakin public cheats so JOB WELL DONE @Merccy2 Thanks .

2- Sorry for the bunch of questions up their :P .

add me on skype i have couple questions on your approaches