Solved💡 Polyloader users

Posts 31–37 of 37 · Page 3 of 3
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
Quote Originally Posted by qazqaz112 View Post
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
So basically VMProtect saves us?
Quote Originally Posted by Yemiez View Post
I'd say they might have blacklisted some of the signatures the randomized hack has, alot of people are still 100% undetected using it.
encrypt those signatures please haha
Quote Originally Posted by shubek View Post
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]).
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.
Quote Originally Posted by qazqaz112 View Post
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
add me on skype i have couple questions on your approaches

- - - Updated - - -

Quote Originally Posted by Merccy2 View Post
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.
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 .
Quote Originally Posted by shubek View Post
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 .
Yes it changes the signature but it doesn't change the bytes of the detected code, if they found a way to ignore the junk code and still find the detected code it can detect it.

They might also check simpler things like if you have downloaded the zip and have it somewhere on your pc.
Check if in the same folder as the exe is the PolyLoader exe and ban based on that.

I don't know why some are detected and some are not.
Quote Originally Posted by shubek View Post
add me on skype i have couple questions on your approaches

Dont have skype, but feel free to add me on steam..

kennySex (Picture of myself as photo)
Posts 31–37 of 37 · Page 3 of 3
This thread is closed for replies.

Similar Threads

Tags for this Thread

None

Talk with us