FuckAv v2 | FASM | FUD | STRONG USG | NATIVE | SMALL STUB ( 4 - 5 KB )

FuckAv v2 | FASM | FUD | STRONG USG | NATIVE | SMALL STUB ( 4 - 5 KB ) - Printable Version

+- Hack Forums (https://hackforums.net)
+-- Forum: Marketplace (https://hackforums.net/forumdisplay.php?fid=105)
+--- Forum: Premium (https://hackforums.net/forumdisplay.php?fid=451)
+---- Forum: Cryptography and Encryption Market (https://hackforums.net/forumdisplay.php?fid=299)
+---- Thread: FuckAv v2 | FASM | FUD | STRONG USG | NATIVE | SMALL STUB ( 4 - 5 KB ) (/showthread.php?tid=5931816)

Pages: Pages 1 2 3 4 5 6

please note:

our service runs on tor you can download it here : https://www.torproject.org/download/download-easy.html.en

http://fuckavfcnkkvod2u.onion/

List of not supported software:

Spoiler (Click to View)
Runtime scan:
[Image: result.png]

(Jan 20, 2019 01:40 PM)frenchy440 Wrote: Hey, you should think about changing your title for "UD" in view of the results of the "runtime" scan.
GLWS 🤝

why put runtime in qoutes ?

the detection will be fixxed quickly.

(Jan 20, 2019 02:03 PM)J.P.Belmondo Wrote: Vouch for mehtevas always high quality products
dont hestitate to deal with this talented coder.

Thanks for your vouch.

RE: FuckAv v2 | FASM | FUD | STRONG USG | NATIVE | SMALL STUB ( 4 - 5 KB ) - RCE - Jan 20, 2019

Mapping PE, load linked dll , resolve IAT and without using any suspicious API will provide good stealthy with evading of AV memory scan , Implementing USG is a good idea to extend FUD time but i wonder how long it will be FUD after someone starting a big campaign or sending samples to distributed AV's?

Seems an interesting project i may try it later , GLWS 😁

(Jan 20, 2019 02:54 PM)Shad0Byte Wrote: Mapping PE, load linked dll , resolve IAT and without using any suspicious API will provide good stealthy with evading of AV memory scan , Implementing USG is a good idea to extend FUD time but i wonder how long it will be FUD after someone starting a big campaign or sending samples to distributed AV's?

Seems an interesting project i may try it later , GLWS 😁

this is a SIG scan from one of the stubs.

as you can see the USG is really doing a great job

non the less ur still missing a few parts for your crypter explanation.

btw ur VNC isnt c++ its delphi / borland.

(Jan 20, 2019 02:57 PM)mehtevas Wrote:

this is a SIG scan from one of the stubs.

as you can see the USG is really doing a great job

non the less ur still missing a few parts for your crypter explanation.

btw ur VNC isnt c++ its delphi / borland.

yep dont have time to write it all,
also it's not Delphi, its c++ but with a type of CLR hosting with Delphi.

(Jan 20, 2019 03:03 PM)Shad0Byte Wrote: yep dont have time to write it all,
also it's not Delphi, its c++ but with a type of CLR hosting with Delphi.

so its a mixxed application ?

(Jan 20, 2019 06:39 PM)abluka Wrote: its not fud and broke exe bad service

First, it's the sale thread, not support one.
You must know it's a loadpe, it won't work with every files. You might just contact him before sale trashing

(Jan 20, 2019 02:57 PM)mehtevas Wrote:

this is a SIG scan from one of the stubs.

as you can see the USG is really doing a great job

non the less ur still missing a few parts for your crypter explanation.

btw ur VNC isnt c++ its delphi / borland.

This is a very bad understanding of how AVs work, yeah you can encrypt everything or insert junk instructions and sig scanners and file comparison tools would see no similarity. AVs however don't just rely on that, they rely on imports, sections, resource, and other PE characteristics. Sigbench is only a simple tool for simple signatures, AVs do far more than that, we are not in 2005.

(Jan 20, 2019 07:00 PM)French Products Wrote: You must know it's a loadpe, it won't work with every files. You might just contact him before sale trashing

A proper LoadPE would support every file, there is no reason for it to not, and if there is a file it can't handle for some reason that is indeed fixable. PE binaries and process are not magical, they are all very well documented.

The only time where some LoadPEs can logical problems is if the original binary does not have relocation and the base address is occupied by something that is a) either not unmapable such as PEB or b) occupied by the crypter code itself, other than that all binaries should be supported. In fact, simply from reading the list of incompatible applications I already know what the loadPE OP used is doing wrong most likely.