![]() |
|
Convinced All The Crypters Here are Garbage - Printable Version +- Hack Forums (https://hackforums.net) +-- Forum: Marketplace (https://hackforums.net/forumdisplay.php?fid=105) +--- Forum: Bazaar (https://hackforums.net/forumdisplay.php?fid=450) +---- Forum: Marketplace Discussions (https://hackforums.net/forumdisplay.php?fid=163) +---- Thread: Convinced All The Crypters Here are Garbage (/showthread.php?tid=5792776) Pages: Pages
1
2
|
RE: Convinced All The Crypters Here are Garbage - Fulya Donmez - Jan 31, 2018 (Jan 31, 2018 11:47 AM)Win64Worm Wrote: SmokeLoader isnt even that good lmao, its one of the cheapest bots theres around Which one is better than smoke? RE: Convinced All The Crypters Here are Garbage - 05317832892 - Jan 31, 2018 Problem is most of the shit on here is C&P. mehtevas, AriesCoder and Friedrich Nietzsche are legit. The rest is just C# public RunPE bs. It's easy to tell if a crypter is shit, just look at their sales thread, if its proxy sell horse shit, they will promote their fancy "vbc" or "runasm" injection or their file pumper (like why the fuck is this even a thing? you want to make your file small with low entropy and normalised sections, not huge with 90% .data 7.9 entropy), or their startup methods. Real coders promote the shit that matters, syscall extraction, stub size, API bypasses, heuristics. RE: Convinced All The Crypters Here are Garbage - Marriot170 - Feb 1, 2018 (Jan 31, 2018 02:59 PM)ʀᴏᴏᴛᴇᴅ Wrote: Problem is most of the shit on here is C&P. Thank you for existing and for saying the right things. This post should be pinned for view in the cryptography section.. Almost every other .NET crypter here is based off Aeonhack's runPE. Then they use ConfuserEx and call it 'ADVANCED USG'. RE: Convinced All The Crypters Here are Garbage - 05317832892 - Feb 2, 2018 (Feb 1, 2018 05:38 PM)Marriot170 Wrote: Thank you for existing and for saying the right things. Lol my crypter is 100% asm so I can do a lot of black magic. It uses sysenter on native x32 machines and transition on x64 to evade all ring-3 hooks, doesn’t map ntdll or rely on the in memory one provided by winloader. The engine is about 100 asm instructions, very small. It’s stored xor’d in .data. I just jump to it once the pre req has completed. It’s not position independent though because it relies on known offsets. Most shitty crypters will AES the binary or use some other high entropy blaintent bs, because I’m working with asm I can encode the PE in the junk asm operand values, for example: Code mov eax,0Will be encoded as Code \xB8 \x00 \x00 \x00 \x00However if I want to store a PE file, I split it up into dwords (4 byte sections) and xor each against a fixed key, then use the value as the operand for a junk code instruction. Examples of instructions that can work for this are as follows: -JMP (and it’s variations) -CALL -MOV (and some of its variations) -ADD -SUB -OR -AND -PUSH Most of them have a ratio of 1:4 so only around 25% size increase in return for valid normal (ish) entropy heuristically correct file. It also doubles up as junk code that’s never executed. One odd thing I have noticed in using this technique though is that there’s no limitations on jmp and call instructions, usually they should only point to somewhere in the range of (PE Base address + Total virtual size) however AVs have no problem with a series of hard coded jumps to high/low memory locations. My stub also has self modifying code within .text, it calls virtual protect against the base of .text to allow modifications, it then modified the values in the xor decryption routines. There are 2 decryption routines, 1 for the engine, 1 for the payload PE file. These are fairly obvious if you look disassemble however the self modifying code will modify the xor values. If you look at the binary in IDA, you can see the decryption routine, however at run-time, the “hardcoded” key used to decode is altered via self modification from a different section of code. This causes confusion for an beginner analyst as he will see only 1 xref to the engine code but the xor doesn’t actually work because the key is invalid. Oh and there’s a shit ton of anti-debug / anti-automation / anti-sandbox. All under 15kb, FUD. I’ve basically just given all the retards on here a blueprint for a good crypter, too bad none of them know a language other than vb.net RE: Convinced All The Crypters Here are Garbage - 0x0F0C - Feb 2, 2018 (Feb 2, 2018 08:55 AM)ʀᴏᴏᴛᴇᴅ Wrote: However if I want to store a PE file, I split it up into dwords (4 byte sections) and xor each against a fixed key, then use the value as the operand for a junk code instruction. Great Work ! , but some AVs (like Comodo / Kaspersky / Avira /Avast /Bitdefender ) disassemble the code and check if it's junk code . they check if you assign value to register and dont use them , check validity of MOV/JMP/Call Addresses ..... . And you should have full code disassembler in your stub right ? RE: Convinced All The Crypters Here are Garbage - 05317832892 - Feb 2, 2018 (Feb 2, 2018 09:37 AM)ivdz Wrote: Great Work ! , but some AVs (like Comodo / Kaspersky / Avira /Avast /Bitdefender ) disassemble the code and check if it's junk code . The last part is incorrect in my experience, when I have junk code that jumps to fake addresses it doesn't cause detection. I encode it like mov eax,BYTES xor eax,BYTES mov BYTES, eax add [BYTES],eax So it is junk code however interlaced references make it look fine. Code global _startThen I opened up in hxd and changed the call to an invalid address https://www.virustotal.com/#/file/e57c8d042f467ea92332d42e7819488dbefc272b9338173ad3010a542d063484/detection 2/65, neither of those detections are as a result of the jump By contrast here is the identical code with the call left intact and valid https://www.virustotal.com/#/file/820eee4d875b32fdc6418fc2da8efae59a12b13e56bdefa1411f90212e262cd8/detection 3/65 ironically RE: Convinced All The Crypters Here are Garbage - 0x0F0C - Feb 2, 2018 (Feb 2, 2018 10:14 AM)ʀᴏᴏᴛᴇᴅ Wrote: Then I opened up in hxd and changed the call to an invalid addressi did a lot of test in this topic there is no detection because the file is small , if you add APIs and a lot of junk code like that, AVs go nuts RE: Convinced All The Crypters Here are Garbage - 05317832892 - Feb 2, 2018 (Feb 2, 2018 12:58 PM)ivdz Wrote: i did a lot of test in this topic What kind of APIs do you use? Does execution ever reach the junk code in your stub? RE: Convinced All The Crypters Here are Garbage - 0x0F0C - Feb 2, 2018 (Feb 2, 2018 01:15 PM)ʀᴏᴏᴛᴇᴅ Wrote: What kind of APIs do you use? Does execution ever reach the junk code in your stub? it doesn't matter , any apis will trigger them . And yeah , i tested both situations. RE: Convinced All The Crypters Here are Garbage - 05317832892 - Feb 2, 2018 (Feb 2, 2018 01:31 PM)ivdz Wrote: it doesn't matter , any apis will trigger them . And yeah , i tested both situations. Any variation in the sizes of the data encoded? Have you tried hiding it in export names? RE: Convinced All The Crypters Here are Garbage - ganstephanos - Feb 2, 2018 (Jan 30, 2018 06:01 PM)Blanc0 Wrote: Private use, targeted machines Get a private crypt/crypter done/made. |