|
|
Run-->ixepress
Good luck !
|
|
|
.forever wrote:
DackWizard wrote:
Vẫn boot được mà .Chỉ tội là được giữa chừng thì đơ thôi, boot bằng các đĩa khác như hirend boot thì vẫn ngon
có khi đĩa cài đặt để lâu ngày bị xước nên file trên đĩa hỏng dẫn đến ko boot được cũng nên...
PS: ko muốn cài lại win thì hãy repair HDH. Thời gian repair bằng thời gian setup (vậy nên Setup lại thì hơn )
Đã thử trên cả đĩa win cũ lẫn mới đều không được .Chạy fe9 vẫn ngon .Có lẽ mình sẽ thử cách của bạn freeze_love xem sao .Bây giờ phải kiếm cái winPE đã ..hix nếu không được đành format luôn cả Linux đi cài lại
|
|
|
kelakent wrote:
Trước đây mình cũng từng dính vụ như thế nhưng sau đó cài lại Win là hết. Còn ko cài lại được thì chưa gặp bao giờ. Bạn thử chỉnh lại BIOS xem.
Vẫn boot được mà .Chỉ tội là được giữa chừng thì đơ thôi ,boot bằng các đĩa khác như hirend boot thì vẫn ngon
|
|
|
bolzano_1989 wrote:
Vào đây tham khảo hướng dẫn, lần sau nhớ tự search :
http://www.virusvn.com/forum/showthread.php?t=194
Cám ơn đã giúp đỡ nhưng nếu cái đó thì tui cũng biết + Đã search rồi nhưng vẫn chưa khắc phục được .
Vấn đề của tôi có lẽ là do del nhầm file hệ thống nào đó vì chuyện này chỉ xảy ra sau khi tui del và file (ko nhớ rỗ vì con víu nó down cả ổ về -->del tuốt ) .Máy tôi chưa vào được win chỉ đến boot screen chuẩn bị vào thì die .
Mong tiếp tục giúp đỡ .
|
|
|
Máy em mới bị dính virus sau khi diệt bằng tay xó nhầm mấy file hệ thống thì máy không boot được vào win nữa .
Sau khi sài goole thì em backup lại file NTLBR thì máy boot được đến Boot screen thì lại restart liên tục không chạy được nữa.
Bây giờ thì đến cài lại cũng không được vì khi boot bằng CD được 1 doạn thì đơ luôn .Các bác có cách nào giúp em với.
(Chắc do máy em sài chung win+fe9 nên ảnh hưởng đến boot bằng CD Em không muốn phải cài lại win ..hix )
|
|
|
Không bác nào giúp em sao hix...........nản
|
|
|
Đây là link project code :
http://www.rohitab.com/discuss/index.php?act=attach&type=post&id=2695
|
|
|
Em đã thử viết chương trình kết nối tới kênh MIRC trong Delphi,java hay Winsock rồi cũng cách như dưới đây đều được .Giờ thử viết trên CAyncSocket của MFC không hiểu sao không được .Bác nào có kinh nghiệm về vấn đề này giúp em với .
It look like this:
in MyClientSocket.cpp
Code:
void CMyClientSocket::OnReceive(int nErrorCode)
{
// TODO: Add your specialized code here and/or call the base class
if(nErrorCode==0){
((CClientDlg*)Dlg)->OnReceive();
}
CAsyncSocket::OnReceive(nErrorCode);
}
void CMyClientSocket::OnConnect(int nErrorCode)
{
// TODO: Add your specialized code here and/or call the base class
if(nErrorCode==0){
((CClientDlg*)Dlg)->OnConnect();
}
CAsyncSocket::OnConnect(nErrorCode);
}
void CMyClientSocket::OnClose(int nErrorCode)
{
// TODO: Add your specialized code here and/or call the base class
if(nErrorCode==0){
((CClientDlg*)Dlg)->OnClose();
}
CAsyncSocket::OnClose(nErrorCode);
}
//----------------------------------------------
In ClientDlg.cpp
//--------------------------------------------------------------------------
Code:
void CClientDlg::OnConnect()
{ UpdateData(TRUE);
if(!connect.Connect(LPCTSTR(m_SERVER),UINT(m_PORT)))
{
AfxMessageBox("Connection false !");
}
ConnectMIRC();
}
void CClientDlg::OnReceive()
{
char *pBuf =new char [1025];
CString strData;
int iLen;
iLen=connect.Receive(pBuf,1024);
if(iLen==SOCKET_ERROR)
{
AfxMessageBox("Could not Recieve");
}
else
{
pBuf[iLen]=NULL;
strData=pBuf;
m_RECEIVED.AddString(strData);
if(strData.Find("PING")==0)
{
strData.Right(strData.GetLength()-4);
SendMess("PONG"+strData);
m_RECEIVED.AddString("PONG"+strData);
UpdateData(FALSE);
delete pBuf;
}
}
}
//----------------------------------------------------------------------------
void CClientDlg::OnClose()
{
connect.Close();
AfxMessageBox("Disconnected !");
m_RECEIVED.AddString("DisConnected !");
}
void CClientDlg::OnBdisconnect()
{
OnClose();
}
void CClientDlg::OnBsend()
{
UpdateData();
SendToMIRC(m_MESSAGE);
m_RECEIVED.AddString("U <<"+m_MESSAGE);
m_MESSAGE="";
UpdateData(FALSE);
}
void CClientDlg::OnBconnect()
{
OnConnect();
}
//-----------------------------------------------------------------------
//---------------------------------------------------------------------------------------
void CClientDlg::ConnectMIRC()
{ CString temp;
UpdateData();
temp="NICK "+m_NICK;
if (SendMess(temp) == SOCKET_ERROR)
{
AfxMessageBox("Error !Can't send Nick'sauthen to server");
}
temp="USER "+m_NICK+" \"hotmail.com\" "+"\""+m_SERVER+"\" :"+m_NICK;
if (SendMess(temp) == SOCKET_ERROR)
{
AfxMessageBox("Error !USER'sauthen can't send");
}
temp="JOIN #"+m_CHANNEL;
if (SendMess(temp) == SOCKET_ERROR)
{
AfxMessageBox("Error !Channel'sauthen can't send\r\n");
}
temp="MODE #"+m_CHANNEL;
if (SendMess(temp) == SOCKET_ERROR)
{
AfxMessageBox("Error !MODE'sauthen can't send!\r\n");
}
temp="PRIVMSG #"+m_CHANNEL+" :Hi all ! I come back!";
if (SendMess(temp) == SOCKET_ERROR)
{
AfxMessageBox("Error !Message can't send\r\n");
}
UpdateData(FALSE);
}
//---------------------------------------------------------------------------------------
void CClientDlg::SendToMIRC(CString mess)
{
if (SendMess("PRIVMSG #"+mess) == SOCKET_ERROR)
{
AfxMessageBox("Error !Message can't send");
}
}
//---------------------------------------------------------------------------------------
//-----------------------------------------------------------------------------------
int CClientDlg::SendMess(CString mess)
{
int iLen,iSent;
// Get the length of the message
iLen = mess.GetLength();
// Send the message
iSent = connect.Send(LPCTSTR(mess), iLen);
return iSent;
}
//-------------------------------------------------------------------------------
|
|
|
StarGhost wrote:
DackWizard wrote:
mình nghĩ là hook bàn phím cũng được chứ ,vì khi chạy console thì Global hay local hook là như nhau ta cứ bắt tất rồi đổ ra .Còn tạo thread mình nghĩ chắc là không được vì nếu con trỏ nó đang dợi bạn nhập vào (ngắt bp) thì làm sao thread nào có thể can thiệp được vào
dể dổ thông tin nhận từ server ra được (mình nghĩ vậy đó) .
ps :Để mình thử cách non-blocking sys call xem
--> Rồi bạn hook cho mình xem. Mình tự hỏi không biết bạn đã làm việc với hooking trên linux bao giờ chưa.
--> Hì, bạn có biết POSIX threads trong Linux được implemented theo kiểu gì không vậy? Là kernel-level threads bạn ạ, tức là thread scheduling là do kernel. Mình lại tự hỏi không biết bạn đã thử chưa mà kết luận vậy.
Hay lắm !Mình sẽ thử Nhưng mình đưa ra đây là để thảo luận xem cách nào hợp lí nhất thôi nhưng rõ ràng là Hook
không có lí gì là không được đúng kho?Chỉ tại do nó có vẻ đao to búa lớn so với một chương trình như thế này nên có lẽ sẽ là cách cuối cùng được chọn.Mong mọi người tiếp tục góp ý .
ps :Mình cũng mới tìm hiểu về linux chưa lâu còn phải học hỏi nhièu
|
|
|
StarGhost wrote:
Bạn hiểu hook là gì mà lại đưa nó vào đây? Có ít nhất 2 cách để giải quyết vấn đề keyboard. Thứ nhất là dùng non-blocking system calls, thứ hai là dùng threads, bạn chọn cái nào cũng được.
p/s: tiện thể nếu được, bạn giải thích dùm tại sao cái lỗi h_addr lại dẫn đến thông báo lỗi như ở trên, để anh em trên này tiện tham khảo.
mình nghĩ là hook bàn phím cũng được chứ ,vì khi chạy console thì Global hay local hook là như nhau ta cứ bắt tất rồi đổ ra .Còn tạo thread mình nghĩ chắc là không được vì nếu con trỏ nó đang dợi bạn nhập vào (ngắt bp) thì làm sao thread nào có thể can thiệp được vào
dể dổ thông tin nhận từ server ra được (mình nghĩ vậy đó) .
ps :Để mình thử cách non-blocking sys call xem
|
|
|
StarGhost wrote:
Gợi ý cho bạn: đây là lỗi đặt tên variable, và lỗi này dẫn đến một sự trùng hợp khá lý thú, chứ thường thì nó cũng không nghiêm trọng đến vậy. Mình để bạn tự tìm hiểu nhé, có vậy mới giúp bạn hiểu rõ hơn về chương trình của mình. Bạn viết được từng đấy code thì chắc cũng debug được.
p/s: bạn có thể thử thay tên tất cả các variables rồi recompile xem. Mà kể cũng lạ, bạn compile và chạy được trên Kubuntu mới thật là tài.
Thanks bác Lỗi đó nằm ở thàng h_addr .
Tiện đây cho em hỏi luôn : nếu muốn chát ở trên console thật khó vì nó có mỗi cái ngắt bàn phím .Sau mỗi nó dợi ta
nhập từ bàn phím vào dùng scan thì ta không thể nhận được thông tin từ bên kia ,tức là nếu muốn chát được thì mỗi bên phải gõ đều đặn một câu lần lượt . Ai có giải pháp nào ko? Hay là hook?
|
|
|
Em có viết một chương trình chát nho nhỏ để chạy trong chế độ console trên linux .Khi dịch rồi chạy trên Kubuntu 7.10 thì
chát được nhưng khi chuyển sang Fedora 9 vẫn dịch được nhưng nó lại báo lỗi Failed to connect with server: Address family not supported by protocol
là sao?( Đã thử vài Sever vẫn vậy)
Mong các bác xem giúp em
Code:
/* Basic IRC client run incommand line (for console LFS :d)
Author DarkWizard */
#include <stdio.h>
#include <sys/socket.h>
#include <arpa/inet.h>
#include <stdlib.h>
#include <string.h>
#include <pthread.h>// To create 2 thread seperate paralel
#include <unistd.h>
#include <netinet/in.h>
#include <netdb.h> /* hostent struct, gethostbyname() */
#define BUFFSIZE 255
char channel[30];
char mess[125];
int sock;
//---------------------------------------------------------------------------------------------------
void Die(char *mess)
{
perror(mess);
exit(1);
}
void InputThread(void* ptr){
//-------type message in here------------------------------
printf("\nType ur message:\n");
scanf("%s",mess);
fprintf(stdout,"U :");
fprintf(stdout,mess);
fprintf(stdout,"\n");
//
SendMessage(sock,channel,mess);
}
void SendMessage(int sock,char* channel,char* mess){
char msg[135];
strcpy(msg,"");
strcat(msg,"PRIVMSG #");
strcat(msg,channel);
strcat(msg," :");
strcat(msg,mess);
strcat(msg,"\n");
if (send(sock, msg, strlen(msg), 0) != strlen(msg)) {
Die("Mismatch in number of sent bytes");
}
}
int main(int argc, char *argv[]) {
struct sockaddr_in MIRCclient;
struct hostent *host;
struct in_addr h_addr;/* internet address */
char buffer[BUFFSIZE];
pthread_t thread1; //Thread struct
int received = 0;
char NICK[30];
//----------------------------------------------------
if (argc <3) {
fprintf(stderr, "USAGE: MIRC Client <server_ip> <port><channel>\n");
exit(1);
}
/* Create the TCP socket */
if ((sock = socket(PF_INET, SOCK_STREAM, IPPROTO_TCP)) < 0) {
Die("Failed to create socket");
}
/* Construct the server sockaddr_in structure */
memset(&MIRCclient, 0, sizeof( MIRCclient)); /* Clear struct */
MIRCclient.sin_family = AF_INET; /* Internet/IP */
//''''''serverinfo
if ((host = gethostbyname(argv[1])) == NULL) {
fprintf(stderr, "%s don't exist \n", argv[1]);
exit(1);
}
h_addr.s_addr = *((unsigned long *) host->h_addr_list[0]);
fprintf(stdout, "Ur server %s :%s\n", argv[1],inet_ntoa(h_addr));
//'''''''
MIRCclient.sin_addr.s_addr = inet_addr( inet_ntoa(h_addr)); /* IP address */
MIRCclient.sin_port = htons(atoi(argv[2])); /* server port */
/* Establish connection */
if (connect(sock,
(struct sockaddr *) &MIRCclient,
sizeof(MIRCclient)) < 0) {
Die("Failed to connect with server");
}
printf("Enter ur nick :\n");
scanf("%s",NICK);
//Authenticate to server
strcpy(mess,"");//reset mess
strcat(mess,"NICK ");
strcat(mess,NICK);
strcat(mess,"\n");
if (send(sock, mess, strlen(mess), 0) != strlen(mess)) {
Die("Ur nick can't send to server");
}
//...............................
strcpy(mess,"");
strcat(mess,"USER ");
strcat(mess,NICK);
strcat(mess," @_wsmail.com ");
strcat(mess,argv[1]);
strcat(mess," :");
strcat(mess,NICK);
strcat(mess,"\n");
strcat(mess,"\n");
if (send(sock, mess, strlen(mess), 0) != strlen(mess)) {
Die("Ur nick can't send to server");
}
if(strlen(argv[3])>0){
fprintf(stdout,"Ur default channel is :");
fprintf(stdout,argv[3]);
fprintf(stdout,"\n");
strcpy(channel,argv[3]);
}else{
printf("enter Ur Room to join:\n");
scanf("%s",channel);
}
//Join ur Room
strcpy(mess,"");
strcat(mess,"JOIN #");
strcat(mess,channel);
strcat(mess,"\n");
if (send(sock, mess, strlen(mess), 0) != strlen(mess)) {
Die("Ur channel can't send to server");
}
//..............................
strcat(mess,"");
strcat(mess,"MODE #");
strcat(mess,channel);
strcat(mess,channel);
strcat(mess," :");
strcat(mess,"\n");
if (send(sock, mess, strlen(mess), 0) != strlen(mess)) {
Die("Ur channel Mode can't send to server");
}
//-------------------------------------------------------------------
if ((received = recv(sock, buffer, BUFFSIZE, 0)) < 0) {
Die("Failed to receive initial bytes from client");
}
fprintf(stdout,buffer);
SendMessage(sock,channel,"Hi All !");
//----------------------------------------------------------------------
while(1){
//Run inputThread
pthread_create( &thread1, NULL,InputThread,NULL);
pthread_join( thread1, NULL);
/* Receive the text from the server */
fprintf(stdout, "Received: ");
/* Receive message */
if ((received = recv(sock, buffer, BUFFSIZE, 0)) < 0) {
Die("Failed to receive initial bytes from client");
}
//......................................
fprintf(stdout,buffer);
if(strcmp(strtok(buffer," "),"PING")==0){
strcpy(mess,"");
strcat(mess,"PONG ");
strcat(mess,strtok(NULL," "));
strcat(mess,"\n");
send(sock, mess, strlen(mess), 0);
}
fprintf(stdout, "\n");
}
close(sock);
exit(0);
}
//-------------------------------------------------
./run.sh
code:
Code:
#!/bin/sh
gcc -lpthread MIRC-Client.c
./a.out irc.dal.net 6667 SmallCode_ws
//-------------------------------
kq :
Ur server irc.dal.net :66.252.19.86
Failed to connect with server: Address family not supported by protocol
Các bác xem hộ em phát
|
|
|
Mình Đang tìm hiểu về kĩ thuật Dll Injection gặp bài báo cảm thấy khá hay và bổ ích muốn chia sẻ cùng mọi người
Do trình độ tiếng anh cũng chỉ đủ dùng nên không dám dịch ->đành post nguyên lên cho anh em( cũng hi vọng
cao thủ trong diễn đàn dịch cho anh em tham khảo (anh Mod or anh con mắt lé chẳng hạn )
//------------------------------------------------------------------------------------------------------
Wolves In Sheep's Clothing: Malicious DLLs Injected Into Trusted Host Applications
The injection of malicious dynamic link libraries ("DLLs" into trusted host applications can be considered one of the trojan scene's most recent hypes. This article provides you with the background knowledge to understand several common injection techniques and helps you to assess the potential dangers arising from DLL injections.
1. Dynamic Link Libraries are ... ?
Just in case you don't know what we are talking about. Dynamic link libraries are a feature of the Windows OS. They can be described as code libraries (containing executable routines) that are separately saved as files with the extension .dll. Because DLLs do not constitute stand-alone programs they cannot be independently executed but have to be loaded by another application before they become active. Usually, a DLL is loaded into the memory by an application that wants to use it. By contrast, trojan DLLs are "injected" into other applications ("hosts" and try to abuse them. After the injection has been finished a trojan DLL can be considered a part ("module" of the host application ("process". Although the trojan DLL is a mere module of the host process it can perform the same actions like a nasty stand-alone trojan executable.
2. Are there really DLL trojans "in the wild"?
Definitely. It started about two years ago with firewall leaktests like "Firehole". The aforementioned leaktest injected a harmless DLL into a trusted application with internet access in order to demonstrate the limitations of personal firewalls' outbound filtering capabilities. As far as we know, the first publicly released DLL trojans were Setiri and Optix Lite (Special Edition) Firewall Bypass. These trojans were followed by Assasin 2, Aphex FTP, Beast 2, Coldfusion, Institution FWB, Nuclear Uploader and several others. It can be taken for granted that countless second class trojan coders will try to understand the concept of DLL injection in order to create their own super-stealthy, firewall-tunneling Uebertrojans.
3. What's so special about DLL trojans?
From a trojan coder's perspective, DLL trojans offer many advantages:
(a) Stealth
DLL trojans are relatively stealth. This is because they do not show up in the Windows Task-Manager which merely lists processes but not modules (DLLs).
Fortunately, there are several advanced process monitors like "TaskInfo", "System Analyzer", "Process Explorer" (a freeware tool from Sysinternals) and "APM - Advanced Process Manipulation" (a freeware tool from DiamondCS) which allow a computer user to inspect the modules loaded by a process. It is still difficult to detect a DLL trojan though because (i) there are dozens if not hundreds of modules to inspect (unless you already know the infected process) and (ii) there is no easy way to determine whether a DLL is malicious or not (e.g., the DLL trojan may look like a harmless Microsoft DLL).
Moreover, DLL trojans cannot be easily exposed by a firewall (see below). In case that a DLL trojan fails to bypass a firewall and triggers an alert the ordinary user may not expect to have found a trojan but to have experienced a relatively harmless "phone home" originating from a trusted application.
A DLL trojan's filename may be invisible. For instance, the DLL trojan Nuclear Uploader offers basic root kit functionality: it injects itself into the Windows Explorer and hides certain filenames (e.g., the trojan files) from the user.
(b) Hard To Kill
It can be quite difficult to get rid of a DLL trojan if it is injected into a critical system process which cannot be terminated. For instance, the DLL trojan Beast 2 injects itself into the winlogon.exe process. (It is still possible to remove this trojan if you reboot the computer in "Safe Mode" or unload the DLL from the winlogon.exe process with the help of a tool like Trojan Hunter.) Other DLL trojans infect almost every process they can find in order to complicate their removal.
(c) Firewall Tunneling Capabilities
DLL trojans have the capability to tunnel not only routers and port-based firewalls but also personal firewalls (with application filtering rules). This is because DLL trojans can be injected into trusted host applications. In principle, there are two types of firewall tunneling DLL trojans: server DLLs and client DLLs.
Server DLLs are acting like a standard trojan. They open a port and passively listen for incoming connections. Server DLLs are usually injected into trusted server applications which are expressly allowed to listen. For instance, a server DLL may be injected into into a web server, ftp server or any other application for which a firewall rule has been created that allows incoming connections. A tight firewall rule set may help to prevent server DLLs from abusing trusted server applications. For example, a web server which is only permitted to listen on a single port cannot be easily infected by a DLL trojan because generally the DLL trojan will be unable to share the permitted port with the infected application. However, there are numerous server applications (like filesharing tools) for which it is not possible to create such a tight firewall rule set.
Client DLLs (so-called reverse trojans) are not listening for incoming connections but actively establish outgoing connections. Usually, client DLLs are injected into trusted client applications (like web browsers, email programs or FTP clients) which are allowed to connect to the web. For example, a client DLL may abuse the iexplore.exe process in order to connect to "www.remote-control.heaven.org". This means that an outgoing connection is established from local port 1024-5000 to remote port 80. It is not possible to create a tight firewall rule set in order to avoid outgoing connections via local port 1024-5000 since outgoing connections cannot be restricted to a single local port: the Windows OS dynamically assigns local ports to applications which want to establish outgoing connections. (It is also not feasible to disallow any connections to remote port 80 because this would make it impossible to surf the web.)
In principle, modern personal firewalls like Outpost 2 or Sygate Pro 5 have the ability to warn a user if a DLL is injected into a trusted application like Internet Explorer. However, the alert messages are usually inexpressive (and annoying because in most cases not DLL trojans but completely harmless DLLs are loaded into the trusted application). See also http://www.securityfocus.com/bid/9312/discussion/
4. Common Injection Techniques
Basically, there are two ways to inject a DLL trojan into a trusted host application. These ways are called dynamic & static DLL injection.
(a) Dynamic DLL Injection
This shady technique is the most frequently used way to activate DLL trojans: a loader application, which belongs to the DLL trojan, injects the trojan DLL into a host application which is already running or which has previously been started by the loader.
Technically speaking, the loader application allocates a memory region inside the host process, writes into this memory region and forces the host process to load the trojan DLL. The key functions used to perform the injection are VirtualAllocEx, WriteProcessMemory and CreateRemoteThread. Trojan coders Aphex and Rezmond made the VX community happy by publishing the respective source codes. Moreover, there are several injection tools (Aphex Inject, Nuclear Inject etc.) which allow even script kiddies to inject DLL trojans into trusted host applications. Fortunately, these tools are detected as malware by many AV scanners.
We have called the dynamic injection technique "shady" because we believe that there is generally no legit reason to hijack other applications and perform functions like CreateRemoteThread. In other words, standard applications should not use this technique at all. If they do, they are highly suspicious. (This does not apply to certain system level applications.) In the last part of this article, we will make you familiar with two security tools that can prevent applications from (ab)using the function CreateRemoteThread.
(Please note that it is also possible to use the function SetWindowsHookEx for injecting DLLs. However, we do not know any trojans using this technique.)
(b) Static DLL Injection
Static DLL injection is a less frequently used but highly effective and dangerous technique to inject DLL trojans into trusted host applications. Broadly speaking, static DLL injection means that the code required to load the trojan DLL is patched directly into the host application. In other words, the host application is permanently infected and will load the trojan DLL (in addition to other harmless DLLs) each time it is started.
Static DLL injection has the "advantage" that a primitive loader application (and a conspicuous autostart entry in the registry) are not required. In addition, it is not necessary to use shady functions like CreateRemoteThread in order to have the DLL loaded (i.e., the standard LoadLibrary function can be used).
Consequently, it can be very hard to determine whether an application has been infected by means of static DLL injection. Primary targets for static DLL injection are applications which are traded via filesharing networks etc. In particular, internet applications like ftp clients & servers, webcam tools, filesharing clients and instant messengers are endangered. Other potential targets for static DLL injection are standard Microsoft applications like Internet Explorer or Outlook (Express). Fortunately, those applications which are monitored by the Windows System File Protection can be less easily infected. Moreover, firewalls which perform MD5 signature checks, will alert the user if an existing application has been modified by static DLL injection.
We feel that it is difficult to say whether there are few or many statically infected host applications "in the wild". This is mainly because most static DLL injections will remain undetected. We know for sure, however, that trojan coders are trying to perfect this injection technique: the source code for an automatic static injection tool has already been revealed. Fortunately, this particular source code is buggy and uses viral code so that the patched target application will be detected by AV scanners.
(c) Final Note
This article is not meant to be a tutorial for trojan coders. Therefore, we do not publish the source codes for dynamic DLL injection. Moreover, we do not discuss the particulars of static DLL injection (like entry point wwwection and wwwection from jumps). However, we would like to clarify that neither dynamic nor static DLL injection require any sophisticated programming skills. It takes virtually no time to compile the source code for a dynamic DLL injector and also static DLL injection can be done within less than a minute. Therefore, we believe that these injection techniques are not merely a theoretical threat.
We have collected/prepared a modest selection of trojan samples which demonstrate both injection techniques. The samples can be sent to AV/AT software producers upon request. Anybody else is invited to try the above-mentioned APM tool from DiamondCS which allows you to dynamically inject DLLs into running processes.
5. How do AV/AT scanners detect DLL trojans?
Well ... they rarely do! Please note that users of DLL trojans are not stupid. It is common practice not to use a DLL trojan right "out of the box" since the standard distribution package (i.e., a bundle of files containing the loader application, the DLL trojan, etc.) is detected by almost every AV/AT scanner. Consequently, DLL trojans are frequently hexedited and protected with an executable compressor or crypter. An undetectable custom loader takes care for the injection.
For this reason, we believe that a good AV/AT scanner must be able to detect not only the standard distribution package or the loader application but the DLL trojan itself. We therefore compiled a sample test with a few DLL trojans stemming from our new test archive. (The new test archive which covers a reasonable selection of DLL trojans will be used for any future comparisons.)
The above mini archive contains a number of compressed/crypted DLLs. Moreover, there are DLL trojans which have been hexedited or increased in size. Finally, we modified or compressed the resource section of several trojans.
(a) AV Scanners /w Unpacking Support
Kaspersky Anti-Virus and McAfee VirusScan were chosen as representatives of a class of AV scanners with unpacking support.
Kaspersky did a relatively good job and detected 20 out of 22 DLL trojans. However, it failed to detect the malware samples packed with PKLite and Armadillo. This suffices to make any DLL trojan a gatecrasher. In addition, there are already many trojan users who employ advanced camouflage techniques (like patching and entry point obfuscation) which make an AV scanner like Kaspersky almost useless.
McAfee performed significantly worse than Kaspersky. It missed more than 50% of the malware samples. One thing that we found especially annoying is that the scanner failed to detect DLL trojans with a modified resource section (e.g., DLL trojans with a replaced icon). Although the resource section of a file can be easily modified with tools like "Resource Hacker" McAfee still uses such "weak" signatures in order to detect trojans. An excellent example of illusive security ...
__________________________________
Scan engine v4.2.40 for Win32.
Virus data file v4283 created Aug 06 2003
Scanning for 77927 viruses, trojans and variants.
Options:
TESTDIR\*.* /ALL /SECURE /L /PANALYZE /PROGRAM /REPORT ZZZ_ERGEBNIS.TXT
ORG.AphexFTP.UPX.dll ... Found the BackDoor-AHZ trojan !!!
ORG.Beast201.notpacked.dll ... Found the BackDoor-AMQ trojan !!!
ORG.Coldfusion108.NotPacked.dll ... Found the BackDoor-AOP.svr trojan !!!
PECompact150.Coldfusion108.dll ... is OK.
Petite22.AphexFTP.dll ... Found trojan or variant BackDoor-AHZ !!!
Petite22.RESCCOMPR7.Beast201.dll ... is OK.
Petite22.Weak8.Beast201.dll ... is OK.
PKLite3211.AphexFTP.dll ... is OK.
RESOURCE.ICONREPL.Assasin20.NotPacked.dll ... is OK.
RESOURCE.RESCCOMPR.Beast201.Petite22.dll ... is OK.
tELock098.Coldfusion108.dll ... is OK.
UNPACKED.AphexFTP.dll ... Found trojan or variant BackDoor-AHZ !!!
UPX190b.Coldfusion108.dll ... is OK.
ADDBYTE.10034.Coldfusion108.NotPacked.dll ... Found trojan or variant BackDoor-AOP.svr !!!
Armadillo301.Coldfusion108.Hexedited.dll ... is OK.
ASPack212.Coldfusion108.dll ... is OK.
ASProtect11.Coldfusion108.dll ... is OK.
HEX.AphexFTP.UNPACKED.dll ... Found trojan or variant BackDoor-AHZ !!!
HEX.Coldfusion108.NotPacked.dll ... Found trojan or variant BackDoor-AOP.svr !!!
HEX.SimpleRename.Beast201.notpacked.dll ... Found trojan or variant BackDoor-AMQ !!!
JDPack101.Coldfusion108.hexedited.dll ... is OK.
Netwalker.Coldfusion108.Win98.dll ... is OK.
Summary report
File(s)
Total files: ........... 22
Clean: ................. 13
Possibly Infected: ..... 9
_________________________________
(b) Memory scanners
Because even prominent AV scanners with unpacking support are not able to reliably detect DLL trojans we tried a memory scanner instead. TDS-3 from DiamondCS was our premier choice. The good thing is that TDS-3 is able to automatically detect the Beast 2.01 trojan in memory if you enable the option "Object Memory Scan".
[img]http://home.arcor.de/scheinsicherheit/screenshots/tdsdll1.jpg
[/img]
The bad thing is that TDS-3 did not automatically detect any other DLL trojans in memory, not even the widely-spread Assasin 2.0. It is necessary to open the TDS-3 process viewer and manually scan the modules of every active process in order to detect trojan DLLs. This procedure is quite uncomfortable and time consuming.
In addition, TDS-3 failed to detect a hexedited Beast 2.01 trojan because it uses a string containing the trojan's name as a signature (i.e., TDS-3 uses the most insecure signature you can possibly imagine).
Note: According to our experience, other memory scanners like BoClean or TrojanHunter do not use "stronger" signatures than TDS-3. We believe that any of these AT products could significantly improve its performance if their makers kept an eye on signature quality. (N.B.: TDS-3 uses different signatures for file scanning. Unfortunately, it does not have an unpacking engine and, therefore, its file scanner detected only 6 out of 22 DLL trojans. )
(c) Conclusion
There is currently no reason to believe that an AV/AT scanner will reliably protect you from DLL trojans.
6. How can I protect myself?
It goes without saying that the exclusive use of software stemming from trustworthy sources (not including filesharing networks, IRC channels, Newsgroups, and e-mail attachments) will significantly reduce the risk of being infected by any trojan. In addition (or alternatively) you may consider some of the following options:
(a) Be extra careful when using filesharing networks. Reconsider twice whether it is wise to grant internet access to an application which you have downloaded from a non-trustworthy source.
(b) Surf a little bit. Thereafter, close the Internet Explorer (but do not close the internet connection). Open a process monitor like Process Explorer or APM. If you can still see a task called "iexplore.exe" (i.e., a hidden Internet Explorer window is still open) you may be infected. In such case you can inspect the modules loaded by iexplore.exe (or any other suspicious process) in order to determine the name of the malicious DLL. If you are in doubt you may ask for expert help in a computer security forum.
(c) Use a freeware tool like TCPView (from Sysinternals) and check any open ports on your computer system. Make sure that you exactly know why a port is open.
(d) Use a personal firewall and create a tight firewall rule set. Stop any applications from phoning home.
(e) Create a firewall rule set which blocks your standard browser. Use alternative browsers like Opera, Mozilla or Firebird instead.
(f) Check out a security tool called "System Safety Monitor". It will help you to block dynamic DLL injection by means of "CreateRemoteThread" and "SetWindowsHookEx".
(g) Alternatively check out "Tiny Personal Firewall". This firewall uses sandbox technology and will inform you if dynamic DLL injection takes place. (Please note that Tiny Personal Firewall is quite difficult to configure.)
(h) Use a freeware tool like Autostart Explorer (from Mischel Internet Security) and check your autostart entries. Use several AV/AT scanners. Be careful and good luck ...
//----------------------------
source : http://home.arcor.de/scheinsicherheit/dll.htm
|
|
|
THE LAST LEAF wrote:
Hehe, vừa mới post bài lúc sáng đã được bác quan tâm rồi, đúng là khó qua mặt cao thủ RE. Đúng là leaf api hook sử dụng một đoạn code rất nhỏ trong của libdasm .Chính thế nên viết 1 dll đơn giản mà kích thước file phình to quá đáng, đó là nhược điểm đang khắc phục. Về phương thức sử dụng thì leaf api hook học theo madCodehook của madshi (cho người dùng dễ sử dụng) nhưng ko hề dùng madshi madCodehook. Còn neji thì quả thật tớ chưa biết là gì .
Cám ơn bác quan tâm!
Thanks bác nhiều nha
|
|
|
quanta wrote:
/hvaonline/posts/list/13874.html
Link này của bác Quanta xịn lắm đáy bận phải cố ngâm cứu kĩ vào khi nào hiểu thì mới nói tiếp được
|
|
|
Anh tinh mắt quá Cám ơn anh mod đã nhắc nhở
Em post 1 con bằng Delphi được chứ?(Đùa thui)
|
|
|
This post is set hidden by a moderator because it may be violating forum's guideline or it needs modification before setting visible to members.
|
|
|
Hôm nay em vào torrentz.com tìm vài tài liệu UML thì được biết tin Mininova bị DDos (mấy ngày rồi thì phải )
post lên cho mọi người xem thử :
from:
http://www.mininova.org/get/2011062
http://torrentfreak.com/mininova-hit-by-massive-ddos-attack-090307/
Mininova Hit By Massive DDoS Attack
Written by Ernesto on March 07, 2009
Mininova, one of the leading BitTorrent sites, has been suffering from a massive DDoS attack over the past few days. Originating rom a botnet spanning three continents, the attacks vary in strength and are causing the site to be completely inaccessible at times. The Mininova team is working on a solution.
mininovaDDoS attacks are not an unusual event for BitTorrent sites, with smaller sites suffering the effects more often than they’d like. However, to take out one of the big players requires some serious power, and that is exactly what Mininova is up against right now.
Mininova co-founder Niek confirmed to TorrentFreak that they have been suffering from a DDoS attack over the past few days. The site is currently being pounded by a botnet of hundreds of computers which is slowing the site down significantly and at times making it completely inaccessible.
Niek said that he has no idea who’s behind the attack or why they chose to target Mininova. This is not the first time the site has had to deal with a Denial of Service attack, but they haven’t witnessed one of this magnitude before.
It started on Thursday originating from three different continents, but seemed to wear off in the hours that followed. Today it’s back in full force. Mininova is used to serving millions of visitors a day, but even they are not equipped to handle an attack like this.
Today’s attack originates from Germany and Argentina and is 2 Gbit strong. The DDos attack is maxing out the entire uplink and is hard to filter since it uses UDP connections.
Niek told TorrentFreak that they are working on a solution at the moment, and he hopes things will be back to normal soon.
Traffic graph of one of the uplinks last Thursday
|
|
|
Cms ơn anh tư dưng bây giờ bật máy lên nó lại vào đươc rồi ,lạ thật .Chac là do khi khởi động OS nó load thiếu gói nào đó
Thanks very much!
|
|
|
Cám ơn anh DuyMinh da nhiệt tình giúp đỡ em cài đặt thành công trên Win . Nếu anh nào đã gặp trương hợp tương tự trên Linux thì giúp em nha :d
|
|
|
Em mới bắt đầu tìm hiểu về Joomla .Em vừa cài Joomla bản 1.5.9 trên ubuntu chạy Apache server PhP 5
Lúc cài đặt xong thì chạy bình thường vào http://localhost/joomla Ok và còn cài được cả một số template cho nó nữa
Nhưng không hiểu sao khi khởi động lại máy thì không vào được nữa Apache2b sever vẫn It work ! Nhưng vào
http://localhost/joomla thì The requested URL was not found on this server. .Mong mọi người giúp
|
|
|
|
|
|
|