I took for example well known trojan wollf v1.6 (www.xfocus.org)
[b]Now, let start:[b]
Wollf is already packed by an old version of UPX, so we unpack and pack it again by newest version
of UPX. Now we are using PE tool and we will find this info about our trojan:
Entry Point: 00024FD0h Image Base: 00400000h
Let us open wollf.exe in Hiew, go to disassemble mode (F4/Decode), go to address Entry Point + Image Base = 00424FD0h, for doing this press Goto (F5) and type ".00424FD0" (you need this dot before address, because it is a virtual address). Now we see something like this:
Now we have to find place for our patch, scroll down a couple of pages and you'll see a lot of place with zeros. I choose address 00425147. For edit press F3/F2. OEP = Entry Point + Image Base
I took for example well known trojan wollf v1.6 (www.xfocus.org)
[b]Now, let start:[b]
Wollf is already packed by an old version of UPX, so we unpack and pack it again by newest version
of UPX. Now we are using PE tool and we will find this info about our trojan:
Entry Point: 00024FD0h Image Base: 00400000h
Let us open wollf.exe in Hiew, go to disassemble mode (F4/Decode), go to address Entry Point + Image Base = 00424FD0h, for doing this press Goto (F5) and type ".00424FD0" (you need this dot before address, because it is a virtual address). Now we see something like this:
Now we have to find place for our patch, scroll down a couple of pages and you'll see a lot of place with zeros. I choose address 00425147. For edit press F3/F2. OEP = Entry Point + Image Base
And last thing we should do, we open the file in PE tool and change Entry Point: Entry Point = Offset - Image Base = 00425161 - 00400000 = 0025161h
Now, if you can unpack the file with UPX, then I suppose you did it right. (don't forget to backup
your file or you'll have to make this patch again.)
I tested patched file on McAfee Virusscan Pro 7.03, it doesn't detect our trojan. Enjoy.
Thanks after reading it 4 times i think i understand it
phaeton
Jan 28 2004, 01:05 AM
Thanks for the infos Progressor, I will try this out, but is there a way of hiding a .sys file from AVs?
Krogoth
Jan 28 2004, 08:29 AM
i'll give upx a try, thanks --Elite--. nice piece of info Progressor. i'll read first and then try as suggested but need McAfee AV for the installation in my box for this experiment. thank you.
Progressor
Jan 28 2004, 11:34 AM
QUOTE
Thanks for the infos Progressor, I will try this out, but is there a way of hiding a .sys file from AVs?
In this case you'll have to find an exact signature used by AV for detection and change it. I don't know another way.
phaeton
Jan 28 2004, 02:26 PM
Should I use SoftIce for that?
Progressor
Jan 29 2004, 09:53 AM
QUOTE
Should I use SoftIce for that?
No, only HEX editor and/or disassembler.
oYost
Jan 30 2004, 01:53 PM
Hello all, I am trying all thats method for patch my fxsvc.exe, but i have some problems : First I tryed with upx, all the switches (1,2,3..) and its detected all the time by KAV, so i used morphine with a random value for -b: (is this good?), still detected then i wanted to use AVP Offset but it makes me bugging... If somebody can help me, its nice. Sorry for my poor english ^^
Progressor
Jan 30 2004, 04:12 PM
QUOTE (oYost @ Jan 30 2004, 01:53 PM)
Hello all, I am trying all thats method for patch my fxsvc.exe, but i have some problems : First I tryed with upx, all the switches (1,2,3..) and its detected all the time by KAV, so i used morphine with a random value for -b: (is this good?), still detected then i wanted to use AVP Offset but it makes me bugging... If somebody can help me, its nice. Sorry for my poor english ^^
Did you use UPX and Morphine separately or together? I'm pretty sure that if you use UPX and Morphine no antivirus will detect your trojan.
eXist
Jan 31 2004, 07:04 AM
Side note, with the new version of UPX, it won't allow you to pack "protected" executables, such as FTP servers, such as Serv-U. If you're having this problem try morphine or AsPack.
peter_BB
Jan 31 2004, 10:48 AM
i tested it, i used upx and morphine and now no av detects it anymore
=k3Rn=
Jan 31 2004, 11:30 AM
Nice - sounds good ! I'll have a test on it too and post later wether i got success.
greetz =k3Rn=
oYost
Jan 31 2004, 12:49 PM
Hum, can u explain how have you done, me i type : upx -9 fxsvc.exe and morphine -b:1F000000 fxsvc.exe it says me : OutputFile: fxsvc.exe (214528) Work completed!
But its still detect by KAV..help plz
=k3Rn=
Jan 31 2004, 01:03 PM
So, i wanted to have a short test trying to compress an exe file serveral time like --elite-- explained in his posting.
I took scan1000.exe (since it gets detected as hacktool by most av-programs) When i try to compress it with upx, i get the following error message: "upx: scan1000.exe: CantPackException: file is possibly packed/protected (try --force" Then i tryed it with force mode - got this error: "upx: scan1000.exe: NotCompressibleException"
Anyone knows what could be done now - why this happens?
---
Ok, now i tryed to modify it with morphine 1.2 - this worked - norton av 2003 doesn't detect it anymore and the executable still works. But F-Secure on my other computer still detects it! (but for any reason it now says webdav exploit - weird)
Anyone got a solution?
---
What i could try is encrypt it once more with morphine.
QUOTE
What's more, Morphine allows you to encrypt one file several times! But be sure you're using -b option (see usage) when doing this.
Can someone please explain me what the -b parameter is for? I must admit i don't know what is meant by image base addsess.
QUOTE
Usage: morphine.exe [-q] [-b:ImageBase] [-o:OutputFile] InputFile -q be quiet (no console output) -b:ImageBase specify image base in hexadecimal string (it is rounded up to next 00010000 multiple) -o:OutputFile specify file for output (InputFile will be rewritten if no OutputFile given)
greetz =k3Rn=
miezmiez
Jan 31 2004, 03:34 PM
QUOTE (Steffan @ Jan 7 2004, 04:39 PM)
But I found a way U may like...
1. compress the .exe 2. use Morphine.exe and make it stealth
If somebody oculd post the offset found by avpoffset for fxsvc.exe and the trojandropper Stealth Batch, i will appreciate.
Thank for your help
d00m
Feb 1 2004, 01:32 AM
I found this text file in my archive....enjoy
QUOTE
--=[ Beating signature-based antiviral technologies('Anatomy of a ghost') ]=--
[PREFACE]
Are Trojans lame? Well, many people think so ... if you hack a winstation or winserver and place a Trojan on it, it is unlikely to be there for long due to antiviral software, tripwire security and its inherent visibility (Netstat -a) ... even if it does go undetected a firewall is likely to render it unreachable.
This guide is aimed at the Trojan writer and shows how to make your Trojan code pass antiviral scans, this is essential for securing access to a computer system by installing a backdoor after penetration, and also gives notes on surviving a re-format of the hard disk. (Yes, you can still keep a machine trojanised even after a standard re-format) but for some reason few Trojans implement ANY of the survival measures outlined here - make sure yours does as your freedom and continued access may rely on it.
Technically, not all back doors are Trojans ... A Trojan is a program that gets the user to voluntarily install it by masquerading as a legitimate application. This requires consent and the abuse of trust, a real system cracker will gain some limited level of access to a machine *without* consent using commonly known holes in various software (MSOE, MSIE, Netbios, ICQ and mIRC have always been good examples of this) and use that level of access to implant a piece of code that gives them further access. Where consent isn't required this code can be more accurately termed a back-door, however we will use the term Trojan in this article as it is a word that everyone is familiar with.
[CHAPTER-1] - Beating The Antivirus Threat
How do AV signatures work ~~~~~~~~~~~~~~~~~~~~~~~~~
An antivirus program will search a given .exe .dll .vxd ... etc for a sequence of bytes that it recognises, this sequence is called the 'Signature' and is unique to the Trojan. Signatures are taken from the actual CODE of a malicious program not any text, this is because if a Trojan included the phrase 'Superlamer Trojan v2.oo' this could be considered unique enough to identify the Trojan, but could also be modified using an editor and so cannot be relied upon for detection, it is much harder to modify the actual code of a Trojan.
The identifying 'signature' is more likely to be a sequence of bytes that are found in the code and are not likely to appear in any other programs.
Typical encrypted code ~~~~~~~~~~~~~~~~~~~~~~
[HEADER][ENCRYPTED BODY]
When the header is executed it performs a decryption of the body, typically a bitwise XORing of the bytes. By the time execution reached the body, the body has been decrypted and is in a machine-runable form.
Weaknesses: 1. The decryption header cannot be encrypted for obvious reasons, it has to be machine-runable or it will be rejected as garbage. 2. The decryption header can be used as a 'signature' by antiviral products. 3. Once the body has been decrypted the whole code is in its vulnerable form in memory and can be seen by AV
Forming a plan ~~~~~~~~~~~~~~
It should be obvious that to prevent antivirus programs from alerting the administrator to the presence of our Trojan we must somehow also encrypt the header, but how?
<Pause here and think>
Obfuscation is a good word Obfuscation is the act of making something deliberately complicated or in order to confuse. Obfuscation is NOT encryption, as an obfuscated item still makes sense when looked at hard enough.
since a given computer instruction is very small (between one and three bytes) we can obfuscate the code by inserting rubbish between each instruction, the rubbish must be readable (i.e., make sense to the computer) but must not actually change anything,
An example of this is in the following 'human' instructions:
one step forward. one step to the right. two steps forward one step to the right
between any of the instructions we can place 'Hop on one foot', 'sing a song', 'wave your hands' ... and we will still get where we want to be, it just takes longer and just breaks up the pattern.
In fact, we can insert anything from a table of 'pointless' things to do:
[Jump up and down] [hop on one leg] [walk forwards one step, then backwards one step] [its just a jump to the left, and then a step to the right] [put your hands on your hips] [recite a poem, walk in a complete circle, roll your eyes]
And we can KEEP adding these 'pointless' instructions to the list until the list gets unbearably long and confusing ... they can be inserted at any point, thus even breaking up other instructions. The net result is garbage ... but if we follow the garbage, we finally get to a point that is (two steps to the right, and three steps forward of where we started)
Luckily, computers are good at this, they have an instruction that does noting but waste time 'NOP' which means 'No Operation) and others can be created:
PUSH AX POP AX
and...
PUSH AX PUSH BX POP AX POP BX SWAP BX, AX
armed with a table of these, we can start obfuscating the header to ensure that AV will not find a signature more than 3 bytes (If you think 3 bytes is enough for a signature please feel free to search your hard drive for 'any file *.* containing' 3 random characters.)
The problem is, some of the NO-Operation code is longer than three characters, and this is a real give-away, no program would ever contain these silly sequences ... and if the AV vendor had a list of them they could simple use those as the signatures - which is why we don't use them straight out of the tin.
Insert random LARGE stupidity between each real instruction of the header Then go back and insert lots of medium-sized stupidity at random safe points then put *LOTS* of '3 byte and less' stupidity at random safe points
Now, since even the no-effect sequences also contain sub-sequences, the permutations of 'silly code' are large and impossible to detect without a rather clever AI.
The main problem is, that since each instruction can occupy 1,2 or 3 bytes ... it is difficult to know where it is safe to insert some useless garbage (We don't want to break an instruction in half or the code won't run) So, we must use a method of construction that allows the safe points to be obvious.
The best way to do this is by forcing every instruction to be word-aligned (Occupy 4 bytes)
Where each II-II-... is a complete instruction ... we can now see that it is possible to insert new garbage after any fourth byte without breaking an instruction.
(GG-GG-... indicates an instruction forming part of a garbage sequence)
We can then remove the leading 00's from each of the words (4 byte sequences) leaving a correctly formatted (And horribly obfuscated) header.
II-II GG GG II-II-II GG GG-GG GG-GG GG II GG-GG-GG-GG GG GG GG-GG-GG II GG-GG-GG II-II
This will run, because it is correct machine code ... but it makes little sense and has no predictable signature greater than three bytes (By now that search of your hard drive for 'any file *.* containing' 3 random characters should have finished, and will show nicely that 3 bytes just isn't enough to uniquely identify a file)
So we win ... our code can obfuscate itself.
The anatomy and chronology ~~~~~~~~~~~~~~~~~~~~~~~~~~
We start with the basic file ... on our home machine ...
WA means Word Aligned (i.e. left-padded with 00's) ( everything in brackets is neither obfuscated nor encrypted ) < everything in angular brackets is obfuscated > [ everything is square brackets is encrypted ]
We run the code with the command parameter -obfuscate only
The Obfuscator takes the WA decrypter and obfuscates it with multiple passes from the WA garbagetable, and then tidies it up (Removes Word-Alignment to produce an executable version) and replaces its original decrypter with this new version.
<decrypter with new key> (obfuscator)(Trojan)(encrypter)(WA decrypter)(WA garbagetable)
The Trojan doesn't run (remember, we ran it with -obfuscateonly)
The encrypter runs and re-encrypts the body with a random key
We just created a unique Trojan ... from: (decrypter) [(obfuscator)(Trojan)(encrypter)(WA decrypter)(WA garbagetable)] to: <decrypter> [(obfuscator)(Trojan)(encrypter)(WA decrypter)(WA garbagetable)]
the decrytion header is scrambled beyond recognition, and the body is encrypted with a new key there are NO identifiable features.
It can now be inserted into the target machine undetected by AV.
Every time it runs in the target machine it will transform itself, thus making it impossible to find by signature ... if the Trojan FINDS files to infect for itself, then YOU will even lose it. (Not a nice scenario if you accidentally infect yourself)
If the Trojan was a true viral entity (IE, infects files, boot disks, etc ...) then you would have a very nasty little outbreak of compromised machines. This, of course, would be unethical.
Surviving the a re-format ~~~~~~~~~~~~~~~~~~~~~~~~~
There are many viruses out there that survive a format by placing a copy of themselves in the MBR (Master Boot Record) of a drive ... this can raise an alarm on a machine with BootSector protection built into the BIOS, however ... on all major BIOSes there ways to detect if this is in operation by looking at the CMOS, the Trojan can then decide for itself whether to attempt an infection of the MBR.
I am not going to give specifics on how this is done ... a casual look at MBR Resident viral code will supply the code needed, and a brief look at some of the common BIOS will show you how to read (But not change) the MBR protection status.
Note to the wise:
Unless you have a multiboot manager such as LILO you should always use the command 'fdisk /mbr' to reset the Master Boot Record after a reformat. If you have a DDO (Dynamic Drive Overlay ... you should still 'fdisk /mbr' and then re-install the DDO)
Laughing at FireWall security ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Check my paper on 'LSP Trojans -v- Firewalls' and its companion 'Anatomy of LSP malware'
"MalWare that aggressively occupies the lowest level in the Winsock's TCP/IP protocol stack (Transport SPI) can completely negate firewall security on a local machine, and also become parasitic to legitimate services allowed through a corporate gateway firewall."
A local firewall can be defeated using an LSP shielded socket, or by making the whole Trojan an LSP. A corporate firewall can be defeated by using an LSP in 'socket promiscuous' mode. PacketLoggers can also be defeated this way.
Exception to this is logging functionality built into the .vxd driver for a network card - This is so rare I've never seen it done, but I'm sure someone somewhere should have thought of it by now.
This is also a watertight way of ensuring that socket-enumerators (Such as the 'netstat -a' command cannot see any port opened by your Trojan)
NOTE: Hacking was made illegal in the UK in 1990 (Read 'computer misuse act 1990' or mail me for a copy) Please check your countries local, state or federal laws regarding the creation and use of 'malicious' software.
Intent is not always required for a successful prosecution: Be advised that in some paranoid countries the crafting of a virus or Trojan 'whether it was intended for distribution or not', is a criminal offence.
If in doubt seek legal guidance or simply don't bother.
The author takes no responsibility for your actions, this paper was written to highlight the insecurity of current commercial solutions to the ever growing viral/Trojan threat. It is written to be provocative and may be viewed by some as an incitement to commit crime, however the article constitutes a guide those wishing to produce a 'proof of concept' (in a country where it is legal for them to do so) and is aimed solely at those administrators wishing to demonstrate the vulnerabilities of their current security solutions.
This article can be distributed freely provided that due credit is given.
=================> However, have you thought about the delivery system ?
Oh, that old chestnut! *grin*
The infection vector is of course the hackers art and warrants not only a book to itself, but a whole library.
Obviously, asking the person to install it is rather lame and doesn't constitute 'hacking' To get a backdoor into a persons machine you actually need to be just a little more sophisticated.
Exploiting/forcing shares (netbios attacks) are well documented and I think one of the best explanations of this I ever saw was at the DEFCon conference when he gave a fun-filled talk on the inherent vulnerability of shares, netbios and registries.
Another method would be exploiting buffer overflow conditions to place your code on the heap ... this will most often send the attacked machine flying off into J-Space, but when it reboots its all yours, and lets face it, normally a post-infection reboot is what you wanted anyhow.
MSIE, MSOE, mIRC, pIRCh, iFTPd, ICQ, ICU, RogueSpear, UO and even the netbios itself have all been vulnerable to this in various forms ... the list is too huge to mention. And when they fix one, very often another emerges keeping the hacker in ready supply of methods of entry.
The thing to remember is that an exploitable buffer-overflow often only gives you a small number of bytes to play with, so good ASM ability is need to get the best (or anything) out of them.
Normal what would happen is this ... you have a buffer and it is surrounded by code:
[BUFFER][CRAP][CODE][ERROR HANDLER]
When we sent it too much data to handle correctly, the buffer should truncate it (Here we send the string 'toomuchdatafortheapplicationtohandle') and the application truncates ...
[BUFFER][CRAP][CODE][ERROR HANDLER] toomuc.
By screwing the buffer with an incorrectly formatted communication (Or by lying about its length) we can overflow the buffer and overwrite sections of the program, this obviously crashes the application:
When the program calls its error handler for the buffer (This could also be a parsing routine or some other function) it executes the code we placed there. In this case, instead of running the ERROR HANDLER it runs NASTYCODE and then probably (But not necessarily) crashes.
Typically we only have a small number of bytes in which to write our 'nastycode' due to the amount of space wasted overflowing the buffer and then the padding needed to put the nastycode in the right memory locations. Certainly not enough code to make a Trojan.
So what can we do? Well ... we can make it attempt to grab a file from a URL and execute it ... or make it simply open an unpassworded fileshare giving us access to their drives, maybe we just want to wipe their drives ... its up to the cracker.
A point to note:
A CR/LF/NULL etc ... must not exist in the string you are sending as it will most likely (Depending on the app) terminate the buffer early, and your code will not be written entirely.
Since code often needs a 10 13 or 00 byte somewhere, it is wise to write your code first, and then try XORing it with different values till you find one that removes all 00, 10 and 13's from your code. The first few instructions in your code would then be dedicated to unXOR'ing the rest in a simple loop. This way you get the code in fully, and it unwraps before execution.
Man, there are so many ways of doing this, and they are the basis for a hackers secret lil exploits library. I think there are very few machines out there that I cant get into with a common or custom sploit. e.g. I recently found two in the 'scour exchange' code prior to it closing down.
And anyone that runs ICQ is a fool (I mean that in a nice way) as it still has more exploitable holes than I've ever seen in a web application.
PS. If you find exploits, keep them to yourself ... otherwise you will just result in a new version of the software and the potential loss of your advantage.
BTW, the real fun starts when there's a sploit in an OCX ... as suddenly you find lots of software suffering in very similar ways.
To find heap buffer overflows, get NuMega softice and start probing around in common applications. There is some ad/marketing software currently inserted in MANY programs that has a *very* tight exploit but I find its just 4 bytes bigger than I need to open an unrestricted passwordless fileshare ... and SO many machines have the software.
So many opportunities,
For a good PUBLIC example of a 'sploit complete with proof-of-concept code to try it out, see the IE3 and IE4 buffer hole's in the way they parsed certain resource types.
I think this post is probably long and confusing ... ummm, but I can't be bothered to read it back and neaten it up - hope I didn't miss the point completely. *grin*
================>
>>A CR/LF/NULL etc ... must not exist in the string you are >>sending as it will most likely (Depending on the app) >>terminate the buffer early, and your code will not be written >>entirely.
I know a Null would do this, but a CRLF ?
SSS
================>
Yes, it depends on what the app you are overflowing uses as a message delimiter. That is why I say it is application specific.
It is wholly possible that there is an app out there that buffers and parses a stream where commands are delimited with a '!' character ... in which case a premature '!' in the string would cause your code to become split and the two halves parsed separately, thus your overflow would not happen, or would not properly locate the infection in memory (Perfectly starting at the entry point of a routine to be called in the near future)
NULLs and CRLF's are simple the more common ones.
Take IRC, messages are delimited by CRLF ... some incorrect, oversized string attempting to overflow the expected maximum of 512bytes could not contain the CRLF sequence as it would prematurely end the line ... so if your code had these as nuisance bytes in your ASM, then you would have to use some kind of mechanism for avoiding them (Change your code, or XOR the bytes)
Is that clear, or am I just mumbling?
> Nope, its clear, just fine. Your over clarifying > things a bit in the other posts Some of us > aren't all that lame you know.
And some of them are (I mention no names, but they know who they are
> I was more interested in examples of typical > apps / cases in which the CR-LF thing would > mess up, irc is one you mentioned...have you > met up with such others ?
Thousands ... anything that delimits with a CR/LF will split and parse each delimited section separately
We are talking expected protocol here, not buffer. The buffer is almost always a Zero-Terminated string (Unless it is fixed length) But the protocol can be anything, and many protocols that sent readable text delimit on a CRLF, particularly those services that are interactive.
Try telneting to your mailer or to the httpdaemon, they are CR/LF delimited services. The exception being in http's MIME urlformencoded requests. so CRLF delimits discrete messages to the parser and a Zero marks the buffer end.
> I know about buffer overflows in *nix, do you have > any data on them in Windows ? Do they work, how > effective are they, anything unique about them ? > That's of course, apart from the peculiarities of > each program we would find by using a disassembler > (softice, w32 etc).
Unique about them? They are all unique in how much code you can push, reliability, how much padding is needed ... etc ...
The are VERY effective (Providing you can get your code to complete BEFORE the program goes spinning off into J-Space)
> I really should learn Win 32 ASM, how different > is it from standard 386 - Pentium DOS ASM ?
Win32 ASM ??? Heh ... don't say that man - if MS owns the instruction set then Linux runs on top of Win32. ROFL.
The pentium and the 386 have different instruction sets, but the differences are minor and well documented. Your standard 80x86 set will be fine, just remember that you are 32bit.
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.
