Leaderboard

Schimbai numele din ida.exe in orice.exe, prima data uite te in stringuri dupa chestii interesante"Shift+F12" p.s. Exista sanse ca parola sa fie plain text in fisier/memorie - ruleaza programu - deschide procexp, click dreapta pe procesul tau > Properties >Strings - alegi Image si dai save (salvezi stringurile din fisier) -alegi Memory si dai save (salvezi stringurile din memorie) uitate prin cele 2 fisiere dupa orice poate semana a parola (plain text, hex, base64) Daca crezi ca isi ia parola de pe server te poti uita dupa conxiunile procesului din procexp>TCP/IP, pentru a vedea ce trimite/primeste cauta wireshark

Network programming in python This is a quick guide/tutorial on socket programming in python. Socket programming python is very similar to C. To summarise the basics, sockets are the fundamental "things" behind any kind of network communications done by your computer. For example when you type www.google.com in your web browser, it opens a socket and connects to google.com to fetch the page and show it to you. Same with any chat client like gtalk or skype. Any network communication goes through a socket. In this tutorial we shall be programming tcp sockets in python. You can also program udp sockets in python. Before you begin This tutorial assumes that you already have a basic knowledge of python. So lets begin with sockets. Creating a socket This first thing to do is create a socket. The socket.socket function does this. Quick Example : 1 2 3 4 5 6 7 8 #Socket client example in python import socket #for sockets #create an AF_INET, STREAM socket (TCP) s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) print 'Socket Created' Function socket.socket creates a socket and returns a socket descriptor which can be used in other socket related functions The above code will create a socket with the following properties ... Address Family : AF_INET (this is IP version 4 or IPv4) Type : SOCK_STREAM (this means connection oriented TCP protocol) Error handling If any of the socket functions fail then python throws an exception called socket.error which must be caught. 1 2 3 4 5 6 7 8 9 10 11 12 13 #handling errors in python socket programs import socket #for sockets import sys #for exit try: #create an AF_INET, STREAM socket (TCP) s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) except socket.error, msg: print 'Failed to create socket. Error code: ' + str(msg[0]) + ' , Error message : ' + msg[1] sys.exit(); print 'Socket Created' Ok , so you have created a socket successfully. But what next ? Next we shall try to connect to some server using this socket. We can connect to www.google.com Note Apart from SOCK_STREAM type of sockets there is another type called SOCK_DGRAM which indicates the UDP protocol. This type of socket is non-connection socket. In this tutorial we shall stick to SOCK_STREAM or TCP sockets. Connect to a Server We connect to a remote server on a certain port number. So we need 2 things , IP address and port number to connect to. So you need to know the IP address of the remote server you are connecting to. Here we used the ip address of google.com as a sample. First get the IP address of the remote host/url Before connecting to a remote host, its ip address is needed. In python the getting the ip address is quite simple. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 import socket #for sockets import sys #for exit try: #create an AF_INET, STREAM socket (TCP) s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) except socket.error, msg: print 'Failed to create socket. Error code: ' + str(msg[0]) + ' , Error message : ' + msg[1] sys.exit(); print 'Socket Created' host = 'www.google.com' try: remote_ip = socket.gethostbyname( host ) except socket.gaierror: #could not resolve print 'Hostname could not be resolved. Exiting' sys.exit() print 'Ip address of ' + host + ' is ' + remote_ip Now that we have the ip address of the remote host/system, we can connect to ip on a certain 'port' using the connect function. Quick example 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 import socket #for sockets import sys #for exit try: #create an AF_INET, STREAM socket (TCP) s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) except socket.error, msg: print 'Failed to create socket. Error code: ' + str(msg[0]) + ' , Error message : ' + msg[1] sys.exit(); print 'Socket Created' host = 'www.google.com' port = 80 try: remote_ip = socket.gethostbyname( host ) except socket.gaierror: #could not resolve print 'Hostname could not be resolved. Exiting' sys.exit() print 'Ip address of ' + host + ' is ' + remote_ip #Connect to remote server s.connect((remote_ip , port)) print 'Socket Connected to ' + host + ' on ip ' + remote_ip Run the program $ python client.py Socket Created Ip address of www.google.com is 74.125.236.83 Socket Connected to www.google.com on ip 74.125.236.83 It creates a socket and then connects. Try connecting to a port different from port 80 and you should not be able to connect which indicates that the port is not open for connection. This logic can be used to build a port scanner. OK, so we are now connected. Lets do the next thing , sending some data to the remote server. Free Tip The concept of "connections" apply to SOCK_STREAM/TCP type of sockets. Connection means a reliable "stream" of data such that there can be multiple such streams each having communication of its own. Think of this as a pipe which is not interfered by data from other pipes. Another important property of stream connections is that packets have an "order" or "sequence". Other sockets like UDP , ICMP , ARP dont have a concept of "connection". These are non-connection based communication. Which means you keep sending or receiving packets from anybody and everybody. Sending Data Function sendall will simply send data. Lets send some data to google.com 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 import socket #for sockets import sys #for exit try: #create an AF_INET, STREAM socket (TCP) s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) except socket.error, msg: print 'Failed to create socket. Error code: ' + str(msg[0]) + ' , Error message : ' + msg[1] sys.exit(); print 'Socket Created' host = 'www.google.com' port = 80 try: remote_ip = socket.gethostbyname( host ) except socket.gaierror: #could not resolve print 'Hostname could not be resolved. Exiting' sys.exit() print 'Ip address of ' + host + ' is ' + remote_ip #Connect to remote server s.connect((remote_ip , port)) print 'Socket Connected to ' + host + ' on ip ' + remote_ip #Send some data to remote server message = "GET / HTTP/1.1\r\n\r\n" try : #Set the whole string s.sendall(message) except socket.error: #Send failed print 'Send failed' sys.exit() print 'Message send successfully' In the above example , we first connect to an ip address and then send the string message "GET / HTTP/1.1\r\n\r\n" to it. The message is actually an "http command" to fetch the mainpage of a website. Now that we have send some data , its time to receive a reply from the server. So lets do it. Receiving Data Function recv is used to receive data on a socket. In the following example we shall send the same message as the last example and receive a reply from the server. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 #Socket client example in python import socket #for sockets import sys #for exit #create an INET, STREAMing socket try: s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) except socket.error: print 'Failed to create socket' sys.exit() print 'Socket Created' host = 'www.google.com'; port = 80; try: remote_ip = socket.gethostbyname( host ) except socket.gaierror: #could not resolve print 'Hostname could not be resolved. Exiting' sys.exit() #Connect to remote server s.connect((remote_ip , port)) print 'Socket Connected to ' + host + ' on ip ' + remote_ip #Send some data to remote server message = "GET / HTTP/1.1\r\n\r\n" try : #Set the whole string s.sendall(message) except socket.error: #Send failed print 'Send failed' sys.exit() print 'Message send successfully' #Now receive data reply = s.recv(4096) print reply Here is the output of the above code : $ python client.py Socket Created Ip address of www.google.com is 74.125.236.81 Socket Connected to www.google.com on ip 74.125.236.81 Message send successfully HTTP/1.1 302 Found Location: http://www.google.co.in/ Cache-Control: private Content-Type: text/html; charset=UTF-8 Set-Cookie: expires=; expires=Mon, 01-Jan-1990 00:00:00 GMT; path=/; domain=www.google.com Set-Cookie: path=; expires=Mon, 01-Jan-1990 00:00:00 GMT; path=/; domain=www.google.com Set-Cookie: domain=; expires=Mon, 01-Jan-1990 00:00:00 GMT; path=/; domain=www.google.com Set-Cookie: expires=; expires=Mon, 01-Jan-1990 00:00:00 GMT; path=/; domain=.www.google.com Set-Cookie: path=; expires=Mon, 01-Jan-1990 00:00:00 GMT; path=/; domain=.www.google.com Set-Cookie: domain=; expires=Mon, 01-Jan-1990 00:00:00 GMT; path=/; domain=.www.google.com Set-Cookie: expires=; expires=Mon, 01-Jan-1990 00:00:00 GMT; path=/; domain=google.com Set-Cookie: path=; expires=Mon, 01-Jan-1990 00:00:00 GMT; path=/; domain=google.com Set-Cookie: domain=; expires=Mon, 01-Jan-1990 00:00:00 GMT; path=/; domain=google.com Set-Cookie: expires=; expires=Mon, 01-Jan-1990 00:00:00 GMT; path=/; domain=.google.com Set-Cookie: path=; expires=Mon, 01-Jan-1990 00:00:00 GMT; path=/; domain=.google.com Set-Cookie: domain=; expires=Mon, 01-Jan-1990 00:00:00 GMT; path=/; domain=.google.com Set-Cookie: PREF=ID=51f26964398d27b0:FF=0:TM=1343026094:LM=1343026094:S=pa0PqX9FCPvyhBHJ; expires=Wed, 23-Jul-2014 06:48:14 GMT; path=/; domain=.google.com Google.com replied with the content of the page we requested. Quite simple! Now that we have received our reply, its time to close the socket. Close socket Function close is used to close the socket. 1 s.close() Thats it. Lets Revise So in the above example we learned how to : 1. Create a socket 2. Connect to remote server 3. Send some data 4. Receive a reply Its useful to know that your web browser also does the same thing when you open www.google.com This kind of socket activity represents a CLIENT. A client is a system that connects to a remote system to fetch data. The other kind of socket activity is called a SERVER. A server is a system that uses sockets to receive incoming connections and provide them with data. It is just the opposite of Client. So www.google.com is a server and your web browser is a client. Or more technically www.google.com is a HTTP Server and your web browser is an HTTP client. Now its time to do some server tasks using sockets. Programming socket servers OK now onto server things. Servers basically do the following : 1. Open a socket 2. Bind to a address(and port). 3. Listen for incoming connections. 4. Accept connections 5. Read/Send We have already learnt how to open a socket. So the next thing would be to bind it. Bind a socket Function bind can be used to bind a socket to a particular address and port. It needs a sockaddr_in structure similar to connect function. Quick example 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 import socket import sys HOST = '' # Symbolic name meaning all available interfaces PORT = 8888 # Arbitrary non-privileged port s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) print 'Socket created' try: s.bind((HOST, PORT)) except socket.error , msg: print 'Bind failed. Error Code : ' + str(msg[0]) + ' Message ' + msg[1] sys.exit() print 'Socket bind complete' Now that bind is done, its time to make the socket listen to connections. We bind a socket to a particular IP address and a certain port number. By doing this we ensure that all incoming data which is directed towards this port number is received by this application. This makes it obvious that you cannot have 2 sockets bound to the same port. There are exceptions to this rule but we shall look into that in some other article. Listen for incoming connections After binding a socket to a port the next thing we need to do is listen for connections. For this we need to put the socket in listening mode. Function socket_listen is used to put the socket in listening mode. Just add the following line after bind. 1 2 s.listen(10) print 'Socket now listening' The parameter of the function listen is called backlog. It controls the number of incoming connections that are kept "waiting" if the program is already busy. So by specifying 10, it means that if 10 connections are already waiting to be processed, then the 11th connection request shall be rejected. This will be more clear after checking socket_accept. Now comes the main part of accepting new connections. Accept connection Function socket_accept is used for this. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 import socket import sys HOST = '' # Symbolic name meaning all available interfaces PORT = 8888 # Arbitrary non-privileged port s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) print 'Socket created' try: s.bind((HOST, PORT)) except socket.error , msg: print 'Bind failed. Error Code : ' + str(msg[0]) + ' Message ' + msg[1] sys.exit() print 'Socket bind complete' s.listen(10) print 'Socket now listening' #wait to accept a connection - blocking call conn, addr = s.accept() #display client information print 'Connected with ' + addr[0] + ':' + str(addr[1]) Output Run the program. It should show $ python server.py Socket created Socket bind complete Socket now listening So now this program is waiting for incoming connections on port 8888. Dont close this program , keep it running. Now a client can connect to it on this port. We shall use the telnet client for testing this. Open a terminal and type $ telnet localhost 8888 It will immediately show $ telnet localhost 8888 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. Connection closed by foreign host. And the server output will show $ python server.py Socket created Socket bind complete Socket now listening Connected with 127.0.0.1:59954 So we can see that the client connected to the server. Try the above steps till you get it working perfect. We accepted an incoming connection but closed it immediately. This was not very productive. There are lots of things that can be done after an incoming connection is established. Afterall the connection was established for the purpose of communication. So lets reply to the client. Function sendall can be used to send something to the socket of the incoming connection and the client should see it. Here is an example : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 import socket import sys HOST = '' # Symbolic name meaning all available interfaces PORT = 8888 # Arbitrary non-privileged port s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) print 'Socket created' try: s.bind((HOST, PORT)) except socket.error , msg: print 'Bind failed. Error Code : ' + str(msg[0]) + ' Message ' + msg[1] sys.exit() print 'Socket bind complete' s.listen(10) print 'Socket now listening' #wait to accept a connection - blocking call conn, addr = s.accept() print 'Connected with ' + addr[0] + ':' + str(addr[1]) #now keep talking with the client data = conn.recv(1024) conn.sendall(data) conn.close() s.close() Run the above code in 1 terminal. And connect to this server using telnet from another terminal and you should see this : $ telnet localhost 8888 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. happy happy Connection closed by foreign host. So the client(telnet) received a reply from server. We can see that the connection is closed immediately after that simply because the server program ends after accepting and sending reply. A server like www.google.com is always up to accept incoming connections. It means that a server is supposed to be running all the time. Afterall its a server meant to serve. So we need to keep our server RUNNING non-stop. The simplest way to do this is to put the accept in a loop so that it can receive incoming connections all the time. Live Server So a live server will be alive always. Lets code this up 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 import socket import sys HOST = '' # Symbolic name meaning all available interfaces PORT = 5000 # Arbitrary non-privileged port s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) print 'Socket created' try: s.bind((HOST, PORT)) except socket.error , msg: print 'Bind failed. Error Code : ' + str(msg[0]) + ' Message ' + msg[1] sys.exit() print 'Socket bind complete' s.listen(10) print 'Socket now listening' #now keep talking with the client while 1: #wait to accept a connection - blocking call conn, addr = s.accept() print 'Connected with ' + addr[0] + ':' + str(addr[1]) data = conn.recv(1024) reply = 'OK...' + data if not data: break conn.sendall(reply) conn.close() s.close() We havent done a lot there. Just put the socket_accept in a loop. Now run the server program in 1 terminal , and open 3 other terminals. From each of the 3 terminal do a telnet to the server port. Each of the telnet terminal would show : $ telnet localhost 5000 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. happy OK .. happy Connection closed by foreign host. And the server terminal would show $ python server.py Socket created Socket bind complete Socket now listening Connected with 127.0.0.1:60225 Connected with 127.0.0.1:60237 Connected with 127.0.0.1:60239 So now the server is running nonstop and the telnet terminals are also connected nonstop. Now close the server program. All telnet terminals would show "Connection closed by foreign host." Good so far. But still there is not effective communication between the server and the client. The server program accepts connections in a loop and just send them a reply, after that it does nothing with them. Also it is not able to handle more than 1 connection at a time. So now its time to handle the connections , and handle multiple connections together. Handling Connections To handle every connection we need a separate handling code to run along with the main server accepting connections. One way to achieve this is using threads. The main server program accepts a connection and creates a new thread to handle communication for the connection, and then the server goes back to accept more connections. We shall now use threads to create handlers for each connection the server accepts. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 import socket import sys from thread import * HOST = '' # Symbolic name meaning all available interfaces PORT = 8888 # Arbitrary non-privileged port s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) print 'Socket created' #Bind socket to local host and port try: s.bind((HOST, PORT)) except socket.error , msg: print 'Bind failed. Error Code : ' + str(msg[0]) + ' Message ' + msg[1] sys.exit() print 'Socket bind complete' #Start listening on socket s.listen(10) print 'Socket now listening' #Function for handling connections. This will be used to create threads def clientthread(conn): #Sending message to connected client conn.send('Welcome to the server. Type something and hit enter\n') #send only takes string #infinite loop so that function do not terminate and thread do not end. while True: #Receiving from client data = conn.recv(1024) reply = 'OK...' + data if not data: break conn.sendall(reply) #came out of loop conn.close() #now keep talking with the client while 1: #wait to accept a connection - blocking call conn, addr = s.accept() print 'Connected with ' + addr[0] + ':' + str(addr[1]) #start new thread takes 1st argument as a function name to be run, second is the tuple of arguments to the function. start_new_thread(clientthread ,(conn,)) s.close() Run the above server and open 3 terminals like before. Now the server will create a thread for each client connecting to it. The telnet terminals would show : $ telnet localhost 8888 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. Welcome to the server. Type something and hit enter hi OK...hi asd OK...asd cv OK...cv The server terminal might look like this $ python server.py Socket created Socket bind complete Socket now listening Connected with 127.0.0.1:60730 Connected with 127.0.0.1:60731 The above connection handler takes some input from the client and replies back with the same. So now we have a server thats communicative. Thats useful now. Conclusion By now you must have learned the basics of socket programming in python. You can try out some experiments like writing a chat client or something similar. When testing the code you might face this error Bind failed. Error Code : 98 Message Address already in use When it comes up, simply change the port number and the server would run fine. If you think that the tutorial needs some addons or improvements or any of the code snippets above dont work then feel free to make a comment below so that it gets fixed. Sursa: https://www.binarytides.com/python-socket-programming-tutorial/

The Process Environment Block (PEB) is a wonderful thing, and I’d be lying if I told you that I didn’t love it. It has been present in Windows since the introduction of the Win2k (Windows 2000) and it has been improved through newer versions of Windows ever since. On earlier versions of Windows, it could be abused to do some nasty things like hiding loaded modules present within a process (to prevent them from being found – obviously this is not a beautiful thing though). What is this magic so-called “Process Environment (PEB)”? The PEB is a structure which holds data about the current process under it’s field values – some fields being structures themselves to hold even more data. Every process has it’s own PEB and the Windows Kernel will also have access to the PEB of every user-mode process so it can keep track of certain data stored within it. Where does this sorcery come from? The PEB structure comes from the Windows Kernel (although is accessible in user-mode as well). The PEB comes from the Thread Environment Block (TEB) which also happens to be commonly referred to as the Thread Information Block (TIB). The TEB is responsible for holding data about the current thread – every thread has it’s own TEB structure. Can the Thread Environment Block or the Process Environment Block be abused for malicious purposes? Of course they can! In fact, they have been abused for malicious purposes in the past but Microsoft has made many changes over the recent years to help prevent this. An example would be in the past where rootkits would inject a DLL into another running process, and then access the PEB structure of the current process they had injected into (the PPEB structure is a pointer to the PEB structure) so they could locate the list of loaded modules and remove their own module from the list… Thus hiding their injected module from view when someone enumerates the loaded modules of the affected process. This is known as memory patching because you would be modifying memory by patching the PEB. Microsoft’s mitigation for this behavior was to prevent the manual altering of the list which represents the loaded modules in user-mode – you can still access it for reading the data in user-mode though and you can still patch the memory from kernel-mode. This article will be split up into two different sections: theory and user-mode practical. Theoretical We’re going to take a look at the Thread Environment Block (TEB) structure using WinDbg. Since the TEB structure is available in user-mode, and used by user-mode Windows components such as NTDLL and KERNEL32, we won’t require kernel-debugging to query about the structure. Bear in mind that you will need to have your symbols correctly setup otherwise you will fail with the next upcoming steps, please see the following URL: https://msdn.microsoft.com/en-us/library/windows/desktop/ee416588(v=vs.85).aspx We’ll start by opening up WinDbg – I’ll be opening up the 64-bit version. WinDbg default view. Now we’ll open up notepad.exe. Once it is open, we can attach to notepad.exe in WinDbg by going to File -> Attach to a Process -> notepad.exe. Alternatively, you can use the default hot-key which should be F6. Attaching to a process via WinDbg. 1/2 Attaching to a process via WinDbg. 2/2 After doing this, the WinDbg command window will be displayed. The command window is the work-space we will have to enter commands at our own discretion to get back various desired results. For example, if we wish to manipulate something, or query information about something, we can do this with a command. WinDbg has a whole wide-range of commands available and you can learn more about that here: http://windbg.info/doc/1-common-cmds.html We’ll be using the dt instruction. “dt” stands for “Display Type” and can be used to display information about a specific data-type, including structures. In our case, it is more than appropriate because it supports structures and we need to find out information about the TEB structure. We can use the following instruction to query information about the TEB structure. dt ntdll!_TEB WinDbg command (dt) for the _TEB structure. We can see already that there are many fields of the structure, so many fields that they all don’t fit on the singular image view. However, if we look towards the very top of the structure, we’ll find the Process Environment Block’s field. Highlighting the ProcessEnvironmentBlock field of the _TEB structure. We can see that WinDbg is labelling the data-type for the field as “Ptr64 _PEB”. This simply means that the data-type is a pointer to the PEB structure (PPEB). Since we are debugging a 64-bit compiled program (notepad.exe since our OS architecture is 64-bit), the addresses are 8 bytes instead of 4 bytes like on a 32-bit environment, which is why “64” is appended to the “Ptr”. We can view the fields of the PEB structure with the following WinDbg command. dt ntdll!_PEB WinDbg command (dt) for the _PEB structure. The WinDbg output is below. 0:007> dt ntdll!_PEB +0x000 InheritedAddressSpace : UChar +0x001 ReadImageFileExecOptions : UChar +0x002 BeingDebugged : UChar +0x003 BitField : UChar +0x003 ImageUsesLargePages : Pos 0, 1 Bit +0x003 IsProtectedProcess : Pos 1, 1 Bit +0x003 IsImageDynamicallyRelocated : Pos 2, 1 Bit +0x003 SkipPatchingUser32Forwarders : Pos 3, 1 Bit +0x003 IsPackagedProcess : Pos 4, 1 Bit +0x003 IsAppContainer : Pos 5, 1 Bit +0x003 IsProtectedProcessLight : Pos 6, 1 Bit +0x003 IsLongPathAwareProcess : Pos 7, 1 Bit +0x004 Padding0 : [4] UChar +0x008 Mutant : Ptr64 Void +0x010 ImageBaseAddress : Ptr64 Void +0x018 Ldr : Ptr64 _PEB_LDR_DATA +0x020 ProcessParameters : Ptr64 _RTL_USER_PROCESS_PARAMETERS +0x028 SubSystemData : Ptr64 Void +0x030 ProcessHeap : Ptr64 Void +0x038 FastPebLock : Ptr64 _RTL_CRITICAL_SECTION +0x040 AtlThunkSListPtr : Ptr64 _SLIST_HEADER +0x048 IFEOKey : Ptr64 Void +0x050 CrossProcessFlags : Uint4B +0x050 ProcessInJob : Pos 0, 1 Bit +0x050 ProcessInitializing : Pos 1, 1 Bit +0x050 ProcessUsingVEH : Pos 2, 1 Bit +0x050 ProcessUsingVCH : Pos 3, 1 Bit +0x050 ProcessUsingFTH : Pos 4, 1 Bit +0x050 ProcessPreviouslyThrottled : Pos 5, 1 Bit +0x050 ProcessCurrentlyThrottled : Pos 6, 1 Bit +0x050 ReservedBits0 : Pos 7, 25 Bits +0x054 Padding1 : [4] UChar +0x058 KernelCallbackTable : Ptr64 Void +0x058 UserSharedInfoPtr : Ptr64 Void +0x060 SystemReserved : Uint4B +0x064 AtlThunkSListPtr32 : Uint4B +0x068 ApiSetMap : Ptr64 Void +0x070 TlsExpansionCounter : Uint4B +0x074 Padding2 : [4] UChar +0x078 TlsBitmap : Ptr64 Void +0x080 TlsBitmapBits : [2] Uint4B +0x088 ReadOnlySharedMemoryBase : Ptr64 Void +0x090 SharedData : Ptr64 Void +0x098 ReadOnlyStaticServerData : Ptr64 Ptr64 Void +0x0a0 AnsiCodePageData : Ptr64 Void +0x0a8 OemCodePageData : Ptr64 Void +0x0b0 UnicodeCaseTableData : Ptr64 Void +0x0b8 NumberOfProcessors : Uint4B +0x0bc NtGlobalFlag : Uint4B +0x0c0 CriticalSectionTimeout : _LARGE_INTEGER +0x0c8 HeapSegmentReserve : Uint8B +0x0d0 HeapSegmentCommit : Uint8B +0x0d8 HeapDeCommitTotalFreeThreshold : Uint8B +0x0e0 HeapDeCommitFreeBlockThreshold : Uint8B +0x0e8 NumberOfHeaps : Uint4B +0x0ec MaximumNumberOfHeaps : Uint4B +0x0f0 ProcessHeaps : Ptr64 Ptr64 Void +0x0f8 GdiSharedHandleTable : Ptr64 Void +0x100 ProcessStarterHelper : Ptr64 Void +0x108 GdiDCAttributeList : Uint4B +0x10c Padding3 : [4] UChar +0x110 LoaderLock : Ptr64 _RTL_CRITICAL_SECTION +0x118 OSMajorVersion : Uint4B +0x11c OSMinorVersion : Uint4B +0x120 OSBuildNumber : Uint2B +0x122 OSCSDVersion : Uint2B +0x124 OSPlatformId : Uint4B +0x128 ImageSubsystem : Uint4B +0x12c ImageSubsystemMajorVersion : Uint4B +0x130 ImageSubsystemMinorVersion : Uint4B +0x134 Padding4 : [4] UChar +0x138 ActiveProcessAffinityMask : Uint8B +0x140 GdiHandleBuffer : [60] Uint4B +0x230 PostProcessInitRoutine : Ptr64 void +0x238 TlsExpansionBitmap : Ptr64 Void +0x240 TlsExpansionBitmapBits : [32] Uint4B +0x2c0 SessionId : Uint4B +0x2c4 Padding5 : [4] UChar +0x2c8 AppCompatFlags : _ULARGE_INTEGER +0x2d0 AppCompatFlagsUser : _ULARGE_INTEGER +0x2d8 pShimData : Ptr64 Void +0x2e0 AppCompatInfo : Ptr64 Void +0x2e8 CSDVersion : _UNICODE_STRING +0x2f8 ActivationContextData : Ptr64 _ACTIVATION_CONTEXT_DATA +0x300 ProcessAssemblyStorageMap : Ptr64 _ASSEMBLY_STORAGE_MAP +0x308 SystemDefaultActivationContextData : Ptr64 _ACTIVATION_CONTEXT_DATA +0x310 SystemAssemblyStorageMap : Ptr64 _ASSEMBLY_STORAGE_MAP +0x318 MinimumStackCommit : Uint8B +0x320 FlsCallback : Ptr64 _FLS_CALLBACK_INFO +0x328 FlsListHead : _LIST_ENTRY +0x338 FlsBitmap : Ptr64 Void +0x340 FlsBitmapBits : [4] Uint4B +0x350 FlsHighIndex : Uint4B +0x358 WerRegistrationData : Ptr64 Void +0x360 WerShipAssertPtr : Ptr64 Void +0x368 pUnused : Ptr64 Void +0x370 pImageHeaderHash : Ptr64 Void +0x378 TracingFlags : Uint4B +0x378 HeapTracingEnabled : Pos 0, 1 Bit +0x378 CritSecTracingEnabled : Pos 1, 1 Bit +0x378 LibLoaderTracingEnabled : Pos 2, 1 Bit +0x378 SpareTracingBits : Pos 3, 29 Bits +0x37c Padding6 : [4] UChar +0x380 CsrServerReadOnlySharedMemoryBase : Uint8B +0x388 TppWorkerpListLock : Uint8B +0x390 TppWorkerpList : _LIST_ENTRY +0x3a0 WaitOnAddressHashTable : [128] Ptr64 Void +0x7a0 TelemetryCoverageHeader : Ptr64 Void +0x7a8 CloudFileFlags : Uint4B As we can see, there’s a lot of fields for the PEB structure. We’ll only be focusing on a select few of them during the practical sections though. Before we can continue, we need to briefly talk about how the Process Environment Block is actually found. It’s located at FS:[0x30] in the Thread Environment Block/Thread Information Block for 32-bit processes, and it’s located at GS:[0x60] for 64-bit processes. To start off, the third field of the PEB structure (“BeingDebugged”) can be read to determine if the current process is attached to via a debugger – this is one vector which is commonly closed by analysts who are debugging malicious software, because malicious software tends to keep a close-eye out for debuggers and other analysis tools to make things more difficult for malware analysts. There’s a routine from the Win32 API called IsDebuggerPresent (KERNEL32) and the routine works by checking the BeingDebugged field of the PEB structure. We can validate this by reverse-engineering kernel32.dll ourselves. IDA pseudo-code for IsDebuggerPresentStub (KERNEL32 – Windows 8+). As we can see, kernel32.dll has a routine named IsDebuggerPresentStub which calls IsDebuggerPresent. This is because the environment I’m getting these images from is Windows 10 64-bit, and Microsoft moved to using KernelBase.dll (introduced starting Windows 8). However, for backwards-compatibility, kernel32.dll is still pushed for usage by their documentation – and if they had dropped support for it then they would have to have moved more than they have across to a new module project, and there’d have been a lot of incompatible software for Windows 8+ at the time. Therefore, we need to take a look at KernelBase.dll. Disassembly for IsDebuggerPresent (KERNEL32 / KERNELBASE). Perfect! KernelBase.dll has an exported routine named IsDebuggerPresent. We’re going to debunk what the above disassembly is telling us. The address of the Process Environment Block is being moved into the RAX register. Since we’re looking at the 64-bit compiled version of KernelBase.dll, 64-bit registers are being used. The Process Environment Block is located at + 0x60 for 64-bit processes. The value from the BeingDebugged field under the Process Environment Block is being extracted and put into the EAX register. The data-type for the BeingDebugged field is UCHAR (which is one byte), and it’s offset is 0x002 – the first field of the PEB structure is located at 0x000 which means the third field (which is the BeingDebugged field) is located +2 bytes from this address. Since the RAX register is holding the address to the Process Environment Block, (RAX + 2) is performed to reach the address of the BeingDebugged field. Returning with the RETN instruction. Since the value for the BeingDebugged field of the PEB structure is held within the EAX register, the caller of the routine is going to return the value stored within the BeingDebugged field. A routine like IsDebuggerPresent (KERNEL32 / KERNELBASE) might be an obvious sign for a malware analyst who is taking a look at the API calls being made by a sample therefore some malware samples will manually access the PEB structure to check – doing this is stealthier and usually less-expected. The next fields we’re going to briefly talk about are the IsProtectedProcess and IsProtectedProcessLight fields of the Process Environment Block. These fields can be used to determine if the current process is “protected” or not, hence the “ProtectedProcess” key-word in the field names. In Windows, there’s multiple process protection mechanisms although the former (non-Light variant) has been around a lot longer than the Process Protection Light (PPL) variant. Standard process protection mechanism in Windows has been around since Windows Vista, however the PPL feature came into play starting Windows 8. Microsoft use these mechanisms to protect their own System processes from being abused by malicious software or forcefully shut-down by a third-party source (because for some Windows processes this can cause the system to bug-check/improperly function). If we can access these fields within the Process Environment Block, then we can check if the current process is protected or not by Windows. All of this is enforced from kernel-mode by the Windows Kernel using the undocumented and opaque EPROCESS structure, and you cannot write to these fields in the PEB structure and have the changes take effect because it won’t update the EPROCESS structure for the current process. The standard process protection mechanism is used by Windows system processes. This mechanism is enforced from within the Windows Kernel and it’s not supposed to be used by third-parties, and it helps prevent system processes from being exploited by attackers (or forcefully shut-down – the Operating System cannot function properly without it’s critical user-mode components). On top of this, Windows will set the state of various system processes to “critical”, and this is flag-based and will cause the system to be forcefully crashed (via a bug-check) if the “critical” processes become terminated. There are two different implementations for the “critical” state: critical processes and critical threads. Setting a process as critical will cause the bug-check once the process has been terminated, and setting a thread as critical will cause the bug-check once the thread has been terminated. Usually, the former is more appropriate because threads come and go regularly (e.g. spawn a new thread to handle an operation simultaneously and then the thread will be terminated once it returns back it’s status from the operation). Windows does not set “threads” as critical as far as I am aware, although it will set specific processes as critical (processes like csrss.exe). We’re going to take a look at how the process protection mechanism which is built-into Windows actually works very briefly using Interactive Disassembler and WinDbg. We can easily check using the following routines. PsIsProtectedProcess (NTOSKRNL) PsIsProtectedProcessLight (NTOSKRNL) Both of the above routines are undocumented but they are still exported by the Windows Kernel. Disassembly for PsIsProtectedProcess (NTOSKRNL). Looking at the disassembly of PsIsProtectedProcess, we can see that the TEST instruction is being used. The TEST instruction is used for a “bitwise operation”. However, we can also see that [RCX+6CAh] is the target. The PsIsProtectedProcess routine takes in one parameter only and it returns a BOOLEAN (UCHAR) – the parameter’s data-type should be a pointer to the EPROCESS structure for the target process being checked on. This tells us that the value stored in the RCX register will be the address of the PEPROCESS (EPROCESS*) for the target process, and it’s accessing the structure to read the value stored under an unknown field which symbolises if the process is or is not protected. The offset for where the field under the EPROCESS structure is located is 6CAh. This means that if you add on 0x6CA from the base address of the EPROCESS* for a process, you will land yourself at the address in which the value being checked in this routine is located at (for this environment only because the offsets regularly shift around and will vary between environment – due to patch updates and separate OS versions). We can check with WinDbg which field is for the 0xC6A offset. WinDbg command (dt) for the _EPROCESS structure, showing the Protection field. Nice! The field in the EPROCESS structure which holds data regarding process protection is named Protection and has a data-type of _PS_PROTECTION (which is a structure) – at-least for the standard process protection mechanism, we are yet to check on the Light variant. We can take a look at the _PS_PROTECTION structure with the dt instruction. WinDbg command (dt) for the _PS_PROTECTION structure. Now if we check the disassembly of the PsIsProtectedProcessLight routine, we can see if it uses the same mechanism to query the status. Disassembly for PsIsProtectedProcessLight (NTOSKRNL). It’s targeting the Protection field of the EPROCESS structure as well – the same field of the structure too. The only difference here is that PsIsProtectedProcess is and PsIsProtectedProcessLight are doing some different checks. In the PEB structure, there’s an entry named Ldr which has a data-type of _PEB_LDR_DATA. Within this structure, we have a field named InMemoryOrderModuleList which has a data-type of _LIST_ENTRY. Double linked lists are very common in Windows components such as in the Windows Kernel or lower-level user-mode components. There’s an instruction in WinDbg named !peb which can be used to enumerate data for the PEB of the currently debugged process. Below is an image of what the output will look like, focus only on the non-highlighted parts. WinDbg command (!peb) output. If we go through the InMemoryOrderModuleList, we can extract each entry and assign to a pointer of the LDR_DATA_TABLE_ENTRY structure using the CONTAINING_RECORD macro. Then we could view details about the current module enumerated using the linked lists… We will do this during the practical code section which is right about now. We’re going to be using the PEB for practical use in the next section. User-Mode In this section we’re going to be re-writing a few Win32 API routines in user-mode which rely on the Process Environment Block. GetModuleHandle – using the Ldr field of the PEB structure GetModuleFileName – using the ProcessParameters field of the PEB structure We need to make sure we’ve declared some structures. Depending on the header files you’re using, you may not need them. However if you do need them… typedef struct _UNICODE_STRING { USHORT Length; USHORT MaximumLength; WCHAR *Buffer; } UNICODE_STRING, PUNICODE_STRING; typedef const UNICODE_STRING *PCUNICODE_STRING; typedef struct _CLIENT_ID { PVOID UniqueProcess; PVOID UniqueThread; } CLIENT_ID, *PCLIENT_ID; typedef struct _RTL_USER_PROCESS_PARAMETERS { BYTE Reserved1[16]; PVOID Reserved2[10]; UNICODE_STRING ImagePathName; UNICODE_STRING CommandLine; } RTL_USER_PROCESS_PARAMETERS, *PRTL_USER_PROCESS_PARAMETERS; typedef struct _PEB_LDR_DATA { BYTE Reserved1[8]; PVOID Reserved2[3]; LIST_ENTRY InMemoryOrderModuleList; } PEB_LDR_DATA, *PPEB_LDR_DATA; typedef struct _LDR_DATA_TABLE_ENTRY { PVOID Reserved1[2]; LIST_ENTRY InMemoryOrderLinks; PVOID Reserved2[2]; PVOID BaseAddress; PVOID Reserved3[2]; UNICODE_STRING FullDllName; UNICODE_STRING BaseDllName; BYTE Reserved4[8]; PVOID Reserved5[3]; #pragma warning(push) #pragma warning(disable: 4201) // we'll always use the Microsoft compiler union { ULONG CheckSum; PVOID Reserved6; } DUMMYUNIONNAME; #pragma warning(pop) ULONG TimeDateStamp; } LDR_DATA_TABLE_ENTRY, *PLDR_DATA_TABLE_ENTRY; typedef struct _PEB { BYTE Reserved1[2]; BYTE BeingDebugged; BYTE Reserved2[1]; PVOID Reserved3[2]; PPEB_LDR_DATA Ldr; PRTL_USER_PROCESS_PARAMETERS ProcessParameters; PVOID Reserved4[3]; PVOID AtlThunkSListPtr; PVOID Reserved5; ULONG Reserved6; PVOID Reserved7; ULONG Reserved8; } PEB, *PPEB; typedef struct _TEB { NT_TIB NtTib; PVOID EnvironmentPointer; CLIENT_ID ClientId; PVOID ActiveRpcHandle; PVOID ThreadLocalStoragePointer; PPEB ProcessEnvironmentBlock; } TEB, *PTEB; The next thing you might want is a global definition for NtCurrentPeb(). This isn’t mandatory but it can be a bit helpful if you’d prefer to type NtCurrentPeb() instead of NtCurrentTeb()->ProcessEnvironmentBlock every-time you need to gain access to the PEB. I always preferred to type NtCurrentPeb() but that’s just me. #define NtCurrentPeb() \ NtCurrentTeb()->ProcessEnvironmentBlock What is NtCurrentTeb()? NtCurrentTeb() is a function which is packed within winnt.h, and it’ll return a pointer to the TEB structure at the correct address of where the TEB is located. NtCurrentTeb() will change depending on the configuration however for a 32-bit compilation, it will locate the TEB by using the __readfsdword macro, targeting 0x18 as the location. This means that the target location is actually FS:[0x18]. For a 64-bit compilation, __readgsqword will be used and the target location will be different. GetModuleHandle replacement HMODULE GetModuleHandleWrapper( WCHAR *ModuleName ) { PPEB ProcessEnvironmentBlock = NtCurrentPeb(); PPEB_LDR_DATA PebLdrData = { 0 }; PLDR_DATA_TABLE_ENTRY LdrDataTableEntry = { 0 }; PLIST_ENTRY ModuleList = { 0 }, ForwardLink = { 0 }; if (ProcessEnvironmentBlock) { PebLdrData = ProcessEnvironmentBlock->Ldr; if (PebLdrData) { ModuleList = &PebLdrData->InMemoryOrderModuleList; ForwardLink = ModuleList->Flink; while (ModuleList != ForwardLink) { LdrDataTableEntry = CONTAINING_RECORD(ForwardLink, LDR_DATA_TABLE_ENTRY, InMemoryOrderLinks); if (LdrDataTableEntry) { if (LdrDataTableEntry->BaseDllName.Buffer) { if (!_wcsicmp(LdrDataTableEntry->BaseDllName.Buffer, ModuleName)) { return (HMODULE)LdrDataTableEntry->BaseAddress; } } } ForwardLink = ForwardLink->Flink; } } } return 0; } The above routine does the following. Retrieves the PPEB Checks if the PPEB could be acquired or not Enumerates the InMemoryOrderModuleList Retrieves a pointer to the LDR_DATA_TABLE_ENTRY structure for each entry Returns the BaseAddress of the module if its a match based on module name buffer comparison with the parameter passed in GetModuleFileName wrapper WCHAR *GetModuleFileNameWrapper() { PPEB ProcessEnvironmentBlock = NtCurrentPeb(); if (ProcessEnvironmentBlock)if (ProcessEnvironmentBlock) { if (ProcessEnvironmentBlock->ProcessParameters) { if (ProcessEnvironmentBlock->ProcessParameters->ImagePathName.Buffer) { if (ProcessEnvironmentBlock->ProcessParameters->ImagePathName.Buffer) { return ProcessEnvironmentBlock->ProcessParameters->ImagePathName.Buffer; } } } } return NULL; } The above routine does the following. Retrieves the PPEB (pointer to the PEB) Checks if the PPEB could be acquired or not Checks if it can access the ProcessParameters field Returns the ImagePathName buffer (it’s a UNICODE_STRING so the Buffer field is a wchar_t*) All of this has been known for an extremely long time now but for those of you which have only just got into Windows Internals and started studying areas like the Process Environment Block, this could help clear things up for you quickly and put an end to some confusion. As always, thanks for reading. NtOpcode Sursa: https://ntopcode.wordpress.com/2018/02/26/anatomy-of-the-process-environment-block-peb-windows-internals/

By BALAJI N November 26, 2017 ATM Penetration testing, Hackers have found different approaches to hack into the ATM machines. Programmers are not restricting themselves to physical assaults, for example, money/card catching, skimming, and so forth they are investigating better approaches to hack ATM programming. An ATM is a machine that empowers the clients to perform keeping money exchange without setting off to the bank. Utilizing an ATM, a client can pull back or store the money, get to the bank store or credit account, pay the bills, change the stick, redesign the individual data, and so on. Since the ATM machine manages money, it has turned into a high need focus for programmers and burglars. In this article, we will perceive how do an ATM functions, security arrangements used to secure the ATMs, diverse sorts of infiltration testing to break down ATM security and a portion of the security best practices which can be utilized to evade ATM hack. Articol complet: https://gbhackers.com/advanced-atm-penetration-testing-methods/

Mai era si prezentarea de la defcamp 2017: https://def.camp/wp-content/uploads/dc2017/Day 1_ Olga & Alexey_ATM every day trouble.pdf

bifeaza tu toate alea si descarca-l, desteptule