4+1 Architecture

The "4+1" View Model of Software Architecture

It is a model for describing the architecture of software-intensive systems, based on the use of multiple, concurrent views. This use of multiple views allows to address separately the concerns of the various 'stakeholders' of the architecture: end-user, developers, systems engineers, project managers, etc., and to handle separately the functional and non functional requirements.

Software architecture deals with abstraction, with decomposition and composition, with style and esthetics. To describe software architecture, we use a model composed of multiple views or perspectives. In order to eventually address large and challenging architectures, the model proposed is made up of five main views.

• The logical view, which is the object model of the design (when an object-oriented design method is used),

• The process view, which captures the concurrency and synchronization aspects of the design,

• The physical view, which describes the mapping(s) of the software onto the hardware and reflects its distributed aspect,

• The development view, which describes the static organization of the software in its development environment.

The description of an architecture which is nothing but the decisions made can be organized around these four views, and then illustrated by a few selected use cases, or scenarios which become a fifth view. The architecture is in fact partially evolved from these scenarios.

ref:

Introducing the 4+1 view model - http://www.ibm.com/developerworks/wireless/library/wi-arch11/

Architectural Blueprints—The “4+1” View Model of Software Architecture - http://www.cs.ubc.ca/~gregor/teaching/papers/4+1view-architecture.pdf

"The 4+1 Vew Model of Architecture" by PHILIPPE B . KRUCHTEN - http://www.ics.uci.edu/~andre/ics223w2006/kruchten3.pdf

Understanding Software Architecture - http://www.ug.it.usyd.edu.au/~iango/home/ESA-Chapter-1.pdf

ShellCode

In computer security, a shellcode is a small piece of code used as the payload in the exploitation of a software vulnerability. It is called "shellcode" because it typically starts a command shell from which the attacker can control the compromised machine. Shellcode is commonly written in machine code, but any piece of code that performs a similar task can be called shellcode. Because the function of a payload is not limited to merely spawning a shell, some have suggested that the name shellcode is insufficient.

The payload is the actual data, or the cargo, carried by the headers. When referring to a computer exploit, the payload is the effect caused by a virus or other malicious code executed by the exploit on the target computer. The payload of a virus may include moving, altering, overwriting, and deleting files, or other destructive activity.

ref:

Shellcode - http://en.wikipedia.org/wiki/Shellcode

Shellcode Tutorial - http://projectshellcode.com/?q=node/20

Windows Shellcode CodeProject - http://www.codeproject.com/Tips/60571/simple-windows-shellcode-invoke-message-box.aspx

Understanding Windows Shellcode - http://www.hick.org/code/skape/papers/win32-shellcode.pdf

Windows Syscall Shellcode - http://www.symantec.com/connect/articles/windows-syscall-shellcode

Windows Shellcode Mastery - http://www.blackhat.com/presentations/bh-europe-09/Caillat/BlackHat-Europe-09-Caillat-Wishmaster-slides.pdf

Shellcode Programming - http://www.l0t3k.org/programming/docs/shellcode/

Shellcoding for Linux and Windows - http://www.vividmachines.com/shellcode/shellcode.html

Writing Shellcode - http://www.safemode.org/files/zillion/shellcode/doc/Writing_shellcode.html

Linux Shellcode - http://www.tenouk.com/Bufferoverflowc/Bufferoverflow5.html

Designing Shellcode demystified - http://www.enderunix.org/docs/en/sc-en.txt

Network level polymorphic Shellcode detection - http://dcs.ics.forth.gr/Activities/papers/emulation.dimva06.pdf

Shellcode detection Library(x86 Shellcode detection and emulation (libEmu)) - http://libemu.carnivore.it/

Stack unwinding

When an exception is thrown and control passes from a try block to a handler, the C++ run time calls destructors for all automatic objects constructed since the beginning of the try block. This process is called stack unwinding. The automatic objects are destroyed in reverse order of their construction. (Automatic objects are local objects that have been declared auto or register, or not declared static or extern. An automatic object x is deleted whenever the program exits the block in which x is declared.)

If an exception is thrown during construction of an object consisting of subobjects or array elements, destructors are only called for those subobjects or array elements successfully constructed before the exception was thrown. A destructor for a local static object will only be called if the object was successfully constructed.

If during stack unwinding a destructor throws an exception and that exception is not handled, the terminate() function is called. The following example demonstrates this:

#include  using namespace std;  struct E {   const char* message;   E(const char* arg) : message(arg) { } };  void my_terminate() {   cout << "Call to my_terminate" <<>

The following is the output of the above example:

In try block In constructor of A In constructor of B In destructor of B In destructor of A Call to my_terminate

In the try block, two automatic objects are created: a and b. The try block throws an exception of type const char*. The handler catch (const char* e) catches this exception. The C++ run time unwinds the stack, calling the destructors for a and b in reverse order of their construction. The destructor for a throws an exception. Since there is no handler in the program that can handle this exception, the C++ run time calls terminate(). (The function terminate() calls the function specified as the argument to set_terminate(). In this example, terminate() has been specified to call my_terminate().)

ref:

http://en.wikipedia.org/wiki/Call_stack

http://www.devx.com/tips/Tip/5687

http://c2.com/cgi/wiki?UnwindingTheStack

Detecting the Remote Desktop Services(RDP) Environment

Detect Remote Desktop Services(RDP)

To optimize performance, it is good practice for applications to detect whether they are running in a Remote Desktop Services client session. For example, when an application is running on a remote session, it should eliminate unnecessary graphic effects, as described in Graphic Effects. If the user is running the application in a local environment, it is not as critical for the application to optimize its behavior.

The following example shows a function that returns TRUE if the application is running in a remote session and FALSE if the application is running on the console.

sample code:

#include windows.h

#pragma comment(lib, "user32.lib")

BOOL IsRemoteSession(void)

{

return GetSystemMetrics( SM_REMOTESESSION );

}

ref:

http://msdn.microsoft.com/en-us/library/aa380798

code to detect if an application is running under terminal server -

http://stackoverflow.com/questions/295415/how-do-i-tell-if-my-application-is-running-in-an-rdp-session

How to test the reachability of a VPN-Connection? -

http://www.codeproject.com/KB/IP/SimpleLineTester.aspx

Detect Internet Connection

Actually, there is no single function for determining if a machine is  connected to the Internet, and it is impossible to reliably determine what  is happening without side effects - such as automatic network connections  taking place. What you can do is reliably detect when there definitely  isn't an Internet Link: in the absence of any dial up or LAN connection the  system is definitely off line.   

Some techniques include:  

1. IsNetworkAlive() If you are targeting system with IE5 or later, this is the best API call  yet it even listens for traffic on a LAN. There is a secondary function  IsDestinationReachable() which tries to resolve the hostname and ping it.  This does not work through firewalls, and overestimates speed as the max  the LAN card can support, rather than the actual point to point bandwidth.  

2. RasEnumConnections() A reliable technique for modems and direct dial up networking, but not for  situations where Internet access is via a LAN. You should dynamically load  "RasEnumConnectionA" from "RASAPI32.DLL", as LAN installations of Windows  may not include the library.  

3. InternetGetConnectedState() This Wininet /IE4 function call can distinguish between modem and LAN, but  can't handle complex LAN+autodial router situations. It is "offline state  aware". Important: handling of the offline flage changed for IE5 -it  returns TRUE for connected'  even when off line, but signals the flags in  the LPDWORD parameter.  

4. InternetCheckConnection() A Winnet/IE4 function call. This is meant to determine if a URL is  reachable- in practice it is pretty unreliable and best voided.  

5. NT SP4, NT5: The IP helper API can tell you which network interface to  use to connect to a supplied IP address, and what the bandwidth and current  status of that link is  

6. Using the Offline flag which is part of IE4 to allow users to manually  control the online/offline state of applications. This flag is stored in  the registry and can be manipulated via some funcions calls  These calls mostly determine the presence or absence of network connections  -not Internet access, so can't handle a home network sharing a dial up  connection, or two laptops connected directly to each other.   The global offline state flag of IE4 (and hence win98, NT5) and the call to  test it - InternetGetConnectedState()- look the best long term options, but  will take time to become universal. The IP Helper APIs even let you find  out how much traffic is going over a link, but only detect the 'loopback'  interface on Windows 98, so is not a lot of use. Wouldn't a  'GetSpeedToHost() function call be great?   

Finally, whatever technique you use, when it's time to talk to a remote  site, always add timeouts or a cancel button. Even a quick functions like  gethostbyname() can lock up an app if something in the network chain is  broken.  

ref:

How to test the reachability of a VPN-Connection? - http://www.codeproject.com/KB/IP/SimpleLineTester.aspx

Get UserName from SessionId

#include windows.h

#include vector

#include string

#include wtsapi32.h

#pragma comment(lib, "WtsApi32.lib")

//
typedef std::basic_string tstring;

// Get current sessions
bool EnumSessionIds(std::vector& list)
{
list.clear();

WTS_SESSION_INFO *pSI = NULL;
DWORD dwSICount;

BOOL bRes = WTSEnumerateSessions(WTS_CURRENT_SERVER_HANDLE, 0, 1, &pSI, &dwSICount);
if (bRes == 0)
return false;

for (unsigned int i = 0; i < pbuffer =" NULL;" bres =" WTSQuerySessionInformation(WTS_CURRENT_SERVER_HANDLE," bres ="=" username =" pBuffer;" pbuffer =" NULL;" bres =" WTSQuerySessionInformation(WTS_CURRENT_SERVER_HANDLE," bres ="=" domain =" pBuffer;"> sessionIds;
bool bRes = EnumSessionIds(sessionIds);
if (!bRes)
{
// error
return 0;
}

// enum sessions
std::vector::iterator iter;
for (iter = sessionIds.begin(); iter != sessionIds.end(); iter++)
{
// print session domain
tstring domain;
GetSessionDomain(*iter, domain);
_tprintf(_T("Session Domain = %s\n"), domain.c_str());

// print session username
tstring username;
GetSessionUserName(*iter, username);
_tprintf(_T("Session UserName = %s\n"), username.c_str());
}

return 0;
}

ref:

Windows-based application over Terminal Services using WtsAPI32 -

http://www.codeproject.com/KB/winsdk/LiviuBirjegaCode3.aspx

REST vs SOAP

SOAP (Simple Object Access Protocol) and REST (Representational State Transfer) provide mechanisms for requesting information from endpoints (SOAP) or from resources (REST). Perhaps the best way to think of these technologies is as a method of making a remote procedure calls against a well-defined API. SOAP has a more formal definition mechanism called WSDL (Web Services Definition Language) and is a bit more complex to implement. REST uses the standard HTTP request and response mechanism, simplifying implementation and providing for a looser coupling of the client and server. Note that REST also supports the transfer of non-XML messages such as JSON (JavaScript Object Notation

Which is better, REST or SOAP?

This is one of the most common questions I get about REST, and it is probably the least fair. Both REST and SOAP are often termed "Web services," and one is often used in place of the other, but they are totally different approaches. REST is an architectural style for building client-server applications. SOAP is a protocol specification for exchanging data between two endpoints.

Comparing REST with the remote procedure call (RPC) style of building client-server applications would be more accurate. RPC is a style (rather than a protocol, which is what SOAP is) of building client-server applications in which a proxy (generally generated from metadata) is used in the client's address space to communicate with the server and the proxy's interface mimics the server's interface. Although SOAP doesn't require the RPC style, most modern SOAP toolkits are geared toward (at least they default to) using RPC.

In contrast to RPC, REST lacks the metadata-generated proxy (see the next question for more information), which means that the client is less coupled to the service. Also, because REST relies on the semantics of HTTP, requests for data (GET requests) can be cached. RPC systems generally have no such infrastructure (and even when performing RPC using SOAP over HTTP, SOAP responses can't be cached because SOAP uses the HTTP POST verb, which is considered unsafe). SOAP intentionally eschews HTTP, specifically to allow SOAP to work over other protocols, so it's actually a little disingenuous to call SOAP-based services Web services.

My perspective is that both REST and SOAP can be used to implement similar functionality, but in general SOAP should be used when a particular feature of SOAP is needed, and the advantages of REST make it generally the best option otherwise.

ref:

Rest vs Soap -

http://blogs.msdn.com/b/swiss_dpe_team/archive/2008/11/28/rest-vs-soap.aspx

http://msdn.microsoft.com/en-us/magazine/dd942839.aspx

Soap vs Rest discussions - http://blogs.msdn.com/b/zainnab/archive/2007/12/16/rest-vs-soap-decision-decisions-decisions.aspx

Introduction to Restful Webservices - http://msdn.microsoft.com/en-us/magazine/dd315413.aspx

Web Services, Part 1: SOAP vs. REST - http://www.ajaxonomy.com/2008/xml/web-services-part-1-soap-vs-rest

Stefan Tilkov: REST vs SOAP - http://www.innoq.com/blog/st/2006/06/30/rest_vs_soap_oh_no_not_again.html

Roots of REST vs SOAP - http://www.prescod.net/rest/rest_vs_soap_overview/

REST vs SOAP from StackOverflow -http://stackoverflow.com/questions/209905/rest-and-soap

Giving SOAP a REST -http://www.devx.com/DevX/Article/8155

Http Message Length

The transfer-length of a message is the length of the message-body as it appears in the message; that is, after any transfer-codings have been applied. When a message-body is included with a message, the transfer-length of that body is determined by one of the following (in order of precedence):

1.Any response message which "MUST NOT" include a message-body (such as the 1xx, 204, and 304 responses and any response to a HEAD request) is always terminated by the first empty line after the header fields, regardless of the entity-header fields present in the message.

2.If a Transfer-Encoding header field (section 14.41) is present and has any value other than "identity", then the transfer-length is defined by use of the "chunked" transfer-coding (section 3.6), unless the message is terminated by closing the connection.

3.If a Content-Length header field (section 14.13) is present, its decimal value in OCTETs represents both the entity-length and the transfer-length. The Content-Length header field MUST NOT be sent if these two lengths are different (i.e., if a Transfer-Encoding

     header field is present). If a message is received with both a      Transfer-Encoding header field and a Content-Length header field,      the latter MUST be ignored. 

4.If the message uses the media type "multipart/byteranges", and the transfer-length is not otherwise specified, then this self- delimiting media type defines the transfer-length. This media type MUST NOT be used unless the sender knows that the recipient can parse it; the presence in a request of a Range header with multiple byte- range specifiers from a 1.1 client implies that the client can parse multipart/byteranges responses.

       A range header might be forwarded by a 1.0 proxy that does not        understand multipart/byteranges; in this case the server MUST        delimit the message using methods defined in items 1,3 or 5 of        this section. 

5.By the server closing the connection. (Closing the connection cannot be used to indicate the end of a request body, since that would leave no possibility for the server to send back a response.)

For compatibility with HTTP/1.0 applications, HTTP/1.1 requests containing a message-body MUST include a valid Content-Length header field unless the server is known to be HTTP/1.1 compliant. If a request contains a message-body and a Content-Length is not given, the server SHOULD respond with 400 (bad request) if it cannot determine the length of the message, or with 411 (length required) if it wishes to insist on receiving a valid Content-Length.

All HTTP/1.1 applications that receive entities MUST accept the "chunked" transfer-coding (section 3.6), thus allowing this mechanism to be used for messages when the message length cannot be determined in advance.

Messages MUST NOT include both a Content-Length header field and a non-identity transfer-coding. If the message does include a non- identity transfer-coding, the Content-Length MUST be ignored.

When a Content-Length is given in a message where a message-body is allowed, its field value MUST exactly match the number of OCTETs in the message-body. HTTP/1.1 user agents MUST notify the user when an invalid length is received and detected.

Chunked transfer encoding

From Wikipedia, the free encyclopedia

Chunked transfer encoding is a data transfer mechanism in the Hypertext Transfer Protocol (HTTP) that allows HTTP data to be reliably delivered between a web server and a clientapplication, usually a web browser, without knowing in advance of transmission the size of the entire message body. This is achieved by splitting the data payload of the message in small parts (chunks) and transmitting with each chunk its size. The data transfer is terminated by a final chunk of length zero. This makes it possible to transmit dynamically generated content in web pages. The chunked method is only available in version 1.1 of the HTTP protocol (HTTP/1.1).

Without chunked transfer encoding, the size of data delivered in HTTP responses must be indicated by the Content-Length header field to allow clients to determine the end of transmission.

Format

If a Transfer-Encoding field with a value of chunked is specified in an HTTP message (either a request sent by a client or the response from the server), the body of the message consists of an unspecified number of chunks, a terminating last-chunk, an optional trailer of entity-header fields, and a final CRLF sequence.

Each chunk starts with the number of octets of the data it embeds expressed in hexadecimal followed by optional parameters (chunk extension) and a terminating CRLF (carriage returnand line feed) sequence, followed by the chunk data. The chunk is terminated by CRLF. If chunk extensions are provided, the chunk size is terminated by a semicolon followed with the extension name and an optional equal sign and value.

The last chunk is a zero-length chunk, with the chunk size coded as 0, but without any chunk data section.

The final chunk may be followed by an optional trailer of additional entity-header fields that are normally delivered in the HTTP header to allow the delivery of data that can only be computed after all chunk data has been generated. The sender may indicate in a Trailer header field which additional fields it will send in the trailer after the chunks.

[edit]Example

[edit]Encoded response

HTTP/1.1 200 OK Content-Type: text/plain Transfer-Encoding: chunked  25 This is the data in the first chunk  1C and this is the second one  3 con 8 sequence 0  

[edit]Anatomy of encoded response

The first two chunks contain explicit \r\n characters in the chunk data.

"This is the data in the first chunk\r\n"      (37 chars => hex: 0x25) "and this is the second one\r\n"               (28 chars => hex: 0x1C) "con"                                          (3  chars => hex: 0x03) "sequence"                                     (8  chars => hex: 0x08) 

The response ends with a zero-length last chunk: "0\r\n" and the final "\r\n".

[edit]Decoded data

This is the data in the first chunk and this is the second one consequence

Http Message Overview

Http Status Codes

Status Codes

HTTP status codes are returned by web servers to describe if and how a request was processed. The codes are grouped by the first digit:

1xx - Informational

Any code starting with '1' is an intermediate response and indicates that the server has received the request but has not finished processing it. For example, IIS initially replies with 100 Continue when it receives a POST request and then with 200 OK once it has been processed

2xx - Successful

These codes are used when a request has been successfully processed. For example, the value 200 is used when the requested resource is being returned to the HTTP client in the body of the response message.

3xx - Redirection

Codes starting with a '3' indicate that the request was processed, but the browser should get the resource from another location. Some examples are:

302	The requested resource has been temporarily moved and the browser should issue a request to the URL supplied in the Location response header.
304	The requested resource has not been modified and the browser should read from its local cache instead. The Content-Length header will be zero or absent because content is never returned with a 304 response

4xx - Client Error

The server returns these codes when they is a problem with the client's request. Here are some examples:

401	Anonymous clients are not authorized to view the requested content and must provide authentication information in the WWW-Authenticate request header.
404	The requested resource does not exist on the server

5xx - Server Error

A status code starting with the digit 5 indicates that an error occurred on the server while processing the request. For example:

500	An internal error occurred on the server. This may be because of an application error or configuration problem
503	The service is currently unavailable, perhaps because of essential maintenance or overloading

Http Authentication

Here is a typical transaction between an HTTP client and an HTTP server running on the local machine (localhost). It comprises the following steps.

1. The client asks for a page that requires authentication but does not provide a user name and password. Typically this is because the user simply entered the address or followed a link to the page.

2. The server responds with the 401 response code and provides the authentication realm.

3. At this point, the client will present the authentication realm (typically a description of the computer or system being accessed) to the user and prompt for a user name and password. The user may decide to cancel at this point.

4. Once a user name and password have been supplied, the client adds an authentication header (with value base64encode(username+":"+password)) to the original request and re-sends it.

5. In this example, the server accepts the authentication and the page is returned. If the user name is invalid or the password incorrect, the server might return the 401 response code and the client would prompt the user again.

Note: A client may pre-emptively send the authentication header in its first request, with no user interaction required.

Http Encoding

When an HTTP client is reading a response message from a server it needs to know when it has reached the end of the message. This is particularly important with persistent (keep alive) connections, because a connection can only be re-used by another HTTP transaction after the response message has been fully received. The following sections describe the four ways in which an HTTP server can indicate the end of the response message:

Connection Closed by Server

The connection can be closed at the end of the response message by the server, but this prevents connections being re-used.

Content-Length Header

The length of the content after the response headers can be specified in bytes with the Content-Length header

Implied Content Length

Some types of responses, such as 304, are defined to never have content and therefore the client can assume that the response message is terminated by the double CRLF after the headers.

Chunked Encoding

The content can be broken up into a number of chunks; each of which is prefixed by its size in bytes. A zero size chunk indicates the end of the response message. If a server is using chunked encoding it must set theTransfer-Encoding header to "chunked".

Chunked encoding is useful when a large amount of data is being returned to the client and the total size of the response may not be known until the request has been fully processed. An example of this is generating an HTML table of results from a database query. If you wantedto use the Content-Length header you would have to buffer the whole result set before calculating the total content size. However, with chunked encoding you could just write the data one row at a time and write a zero sized chunk when the end of the query was reached.

ref:

Http Wiki - http://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol

Http header fields - http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html

How to find ed of Http response - http://www.httpwatch.com/httpgallery/chunked/

HttpMessage structure - http://web-sniffer.net/

Http Message - http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html

Http Authentication – http://en.wikipedia.org/wiki/Basic_access_authentication

HTTP Status Codes and Errors -http://www.httpwatch.com/httpgallery/errors/

http 1.1 RFC - http://www.w3.org/Protocols/rfc2616/rfc2616.html

http over TLS RFC - http://tools.ietf.org/html/rfc2818

ssl 3.0 RFC - http://tools.ietf.org/html/draft-ietf-tls-ssl-version3-00