Sliding Window Protocols? - Part 3

In the third part of this article we shall discuss about the types of sliding window protocols and how these protocols can be extended?

1. Stop and Wait: 

- This one is the simplest type among all the sliding window protocols. 

- Under this type, we have the stop–and–wait ARQ protocol as the simplest implementation.

- Both the transmit window and the receive window is 1 packet and the number of possible sequence numbers required is 2 i.e., 1+1 = 2. 

- The packets sent by the transmitter are marked alternatively as odd and even. 

- Therefore, the ACK packets are in the series of odd, even, odd, even and so on. 

- Now, suppose the transmitter sends an odd packet and immediately without waiting for an odd ACK sends the next even packet. 

- In such a case, it would receive an ACK saying that an odd packet is expected. 

- This leaves the transmitter in a state of ambiguity i.e., whether the receiver got both the packets or none of them.

2. Go-Back-N ARQ: 

- This sliding window protocol has a fixed w_r  (fixed at 1) and w_r  which is always greater than one. 

- Here, the receiver will not accept any packet other than the expected one from the sequence. 

- If the packet gets damaged or lost during the transmission, then the packets following the lost ne will not be accepted by the receiver until and unless it receives the lost one after re-transmission. 

- This ensures minimum loss of 1 RTT (round trip time). 

- This is why it results in inefficiency in using this protocol on the links where the packet loss is quite frequent. 

- Suppose a 3 bit sequence number is being used as in typical HDLC. 

- This means number of sequence numbers is 8 starting from 0 to 7. 

- This also means we have 8 possibilities. 

- Enough ACK information is required by the transmitter for distinguishing between those packets. 

- If 8 packets are sent back to back by the transmitter without stopping for ACK, then it will find itself in the same doubt as in the stop-and-wait case.

3. Selective repeat ARQ: 

- This one is the most general case of the sliding window protocols. 

- It works with a receiver that is more capable of accepting packets having the sequence numbers greater than what the current n_r is and storing them till the gap is filled. 

- The advantage is that discarding data before re-transmission is not necessary.

Ways to extend these protocols

1. The above types of the sliding window protocols don’t talk about reordering the packets after receiving them all. This will ensure that they don’t appear in wrong order. If the long distance can be bounded, the protocols can be extended to support this feature. The maximum mis- ordering distance can be used to expand the sequence number modulus N.
2. Not acknowledging every packet is also possible after the sending an ACK up on not receiving packets. For example, every 2^nd packet is acknowledged in TCP.
3. Informing the transmitter immediately about the presence of gap in the packet sequence is quite common and so HDLC uses a packet called REJ packet for this purpose.
4. During the communication, the window sizes may change if their sum remains in the limit defined by N. usually the transmit window size is reduced for slowing down the transmission in order to keep with the speed of the links and preventing congestion or saturation. 

Sliding Window Protocols? - Part 2

As discussed in part 1 of this article, the sliding window protocol is a type of the packet based data transmission protocol. The sliding window protocols are used in regulating the reliability factor of the data transmission. 

In this second part we discuss about the motivation behind this protocol and how it actually operates. 

- There are a number of communication protocols based up on the automatic repeat request for regulating the error control. 

- In such protocols, it becomes necessary for the receiver for acknowledging about the packets it received. 

- If the receiver does not send an ACK to the transmitter within a specified time period, then the transmitter assumes that the packet might have got lost, re-transmits it. 

- It is obvious that if a transmitter does not receives an ACK for the packet it had sent cannot actually know if the packet got delivered correctly. 

- If, suppose corruption is detected during error detection process on the receiver’s side; the receiver will simply ignore this packet and hence, will not send any ACK to the transmitter. 

- Now in the same way, the receiver also does not know whether the ACK it sent was received by the transmitter or it got lost or damaged during the transmission.

-  In such a case, the re-transmission must be acknowledged by the receiver in order to prevent the continuous re-sending of the data by the transmission. 

- In other cases it is simply ignored.

How the protocol operates?

- The current sequence numbers say n_t and n_r is assigned to transmitter and receiver respectively. 

- Both of them have their window sizes say w_t and w_r respectively.

- In simple implementations of the protocols these sizes are fixed however, they may vary when it comes to the larger and complex implementations. 

- For making any progress, it is necessary that the size of the window must be more than zero. 

- In a typical implementation, n_t denotes the packet to be transmitted. 

- Similarly n_r denotes the packet not received. 

- Both of these numbers increase with the time monotonically. 

- The receiver also has to keep an eye on the highest sequence number that has not been received yet. 

- We have another variable called n_s which is one number greater than the highest sequence number that has been received. 

- There are simple receivers which accept the packets only in the order of w_r = 1 which is nothing but same as the n_r. 

- But in some cases it can exceed 1. 

Now we can say that:

1.     Below n_r no packets have been received.

2.     Above n_s no packets have been received.

3.     It is only between n_r and n_s that some packets have been received.

- Whenever a packet is received, its variables are updated appropriately by the receiver and at the same time an ACK is transmitted with the updated value of n_r. 

- Similarly we have variable n_a used by the transmitter for tracking the highest ACK it has received. 

- Below n_a all the packets have been received but there is uncertainty about the packets between n_s and n_a i.e, the n_r. 

- There are certain rules that are always obeyed by the sequence numbers:

Ø  N_a ≤ n_r: The highest ACK the transmitter has received cannot exceed the highest n_r recorded by the receiver.

Ø  N_r ≤ n_s: The partially received packets’ end cannot be greater than the span of those fully received.

Ø  N_s ≤ n_t: The highest packet sent is always greater than the highest packet received.

Ø  N_t ≤ n_a + w_t: The highest ACK received and the window size set the limits for the highest packet sent.

What is meant by Deadlock? List the necessary conditions for arising deadlocks?

Consider two competing processes or actions in a situation where both of them wait for each other to be done and so neither of them ever finish. Such a situation is called a deadlock. 

- When the number of competing processes is exactly two, then it is said to be a ‘deadly embrace’. 

- The two involved competing actions tend to move towards some sort of tragedy which might be mutual extinction or mutual death. 

"In operating systems a situation occurs where two threads or processes enter the waiting state at the same time because of the resource that they both want is being used by some other process that also in waiting state for some resource being held by another process in waiting state and so on". 

- It so happens that the process is then unable to change its state since the resources it requires are being used by the other processes which is then keeping the process in waiting state indefinitely. 

- The system is now in a deadlock. 

- Systems such as the distributed systems, parallel computing systems, multi-processing systems face the problem of being in a deadlock quite often. 

- This is so because here the hardware and software locks are purposed for handling the resources that are shared and implementing the process synchronization. 

- Deadlocks may also occur in telecommunication systems because of the corrupt signals and their loss rather than resource contention. 

- A deadlock situation can be compared to problems such as that of the catch-22 or chicken or egg problem. 

- A deadlock can also occur in a circular chain pattern. 

- For example, consider a computer having 3 processes and corresponding 3 CD drives i.e., one held by each process. 

- Now all the three processes would be in a deadlock if they all request another drive.

Conditions for a Deadlock to arise

There are certain conditions that should be there for a deadlock to arise:

1. Mutual exclusion: There has to be at least one resource that cannot be shared. So that only one process would use at any given time.
2. Resource holding (or hold and wait): There should be at least one resource held by a process that in turn should be request more resources that are being held by other processes.
3. No preemption: Once the resources have been allocated, they should not de-allocated by the operating system. The condition is that the process holding the resource must release it voluntarily.
4. Circular wait: A circular chain of processes must be formed as explained in the earlier example.

"These 4 conditions for deadlock are collectively called the ‘Coffman conditions’. If any of these conditions is not met, a deadlock can’t occur".

- Handling a deadlock is an important capability of the operating systems. 

- However, there are many modern operating systems that still cannot avoid deadlocks. 

- On occurrence of a deadlock many non-standard approaches are followed by different operating systems for handling it. 

- Many of these approaches try to avoid at least one of the Coffman conditions (generally the 4^th one). 

- Below we discuss some of the approaches:

1. Ignoring deadlock
2. Detection
3. Prevention
4. Avoidance

- There is a second kind of deadlocks called the ‘distributed deadlock’ and it is common where concurrency control is used or we can say in the distributed systems. 

What are different aspects of error seeding?

There are so many issues associated with the so called bugs and errors! A good tester needs to be well aware about all the terms and issues associated with the errors and bugs.

Errors are the worst nightmare a tester and developer can get since an error might have a great potential to disrupt the functional of the whole of the software system or application and it may also introduce new error in a chain in to the program making it even more cumbersome to be tracked.

This article is focussed up on one of the terms associated with the errors and bugs namely “error seeding”.

You must be quite familiar with what is actual seeding?
Seeding is the process of sowing seeds that when grow up will become plants. Similarly from the term “error seeding” itself we can make out that it is the process of adding or sowing the faults in the software program intentionally so that the rate of detection and the removal of the error can be evaluated.

About Error Seeding

- One thing should be kept in mind which is that the errors to be injected in to the program must be known otherwise it will again become a problem for the tester.

- In many of the cases the error seeding methodology is employed to calculate the number of the errors that are still remaining in the program code.

- The error is intentionally injected in to the source code of the software system or application for the purpose of determination of the rate of discovery of the error which is very crucial for the software testing process.

- Knowing the rate of error detection can help a tester know what’s wrong with the testing methodologies he/ she is using and how they can be improved up on.

Uses of Error Seeding Method

Apart from just being used for the determination of the detection rate, this methodology is helpful in the below mentioned tasks also:

1. It is used to evaluate the skills of the tester of error finding.
2. It is used for the evaluation the ability of the application to survive the errors persisting in it
3. It is used to determine the ease with which the discovered bugs can be fixed up without blocking the work flow of the software system or application.

Advantages and Disadvantages of Error seeding

- Error seeding involves the seeding in of the errors and bugs.

- After the seeding of the errors, several test cases are executed and the ratio between the artificial errors and the actual errors is calculated based on the total number of errors that are detected.

- Normal test cases that are designed for any other error detection methodology can be used for error seeding.

- However the error seeding methodology is quite inefficient as compared to other methodologies like mutation testing. But, it takes lesser time to be completed and is very economical to be carried out.

- However inefficient it may be, it is always a better option of the programs with a lengthier source code. The defects that are injected in to the code have non trivial severity.

- The percentage of the seeded defects injected during the testing can bethought of as a reasonable predictor of the effectiveness of the methodology.

What we can do to avoid browser incompatibility?

Malfunctioning of the web sites across various browsers has become a topic of utter annoyance.

Why it happens so that your web site functions perfectly well on one browser and at the same time fails to perform well in some other browser?
Why it appears to be missing some thing while it appears as proper on other browsers?

The root cause of all such errors and differences is the browser incompatibility.

WHAT IS BROWSER INCOMPATIBILITY & TOOLS FOR DETECTING BROWSER INCOMPATIBILITY

- There are various tools that can help you across detecting the browser incompatibility.

- Such tools check for the browser incompatibility by comparing the various snap shots of the web site operating under various web browsers.

- Different browsers and different browser versions all add up to the browser incompatibility.

- Browser incompatibility though cannot be eradicated fully; it can be at least reduced to a certain extent.

- Though the browser is only to be blamed for its incompatibility, the measures to reduce or avoid it can be taken from both sides.

- It can be done by improving either the standards of the browser or by taking care of the web site.

- If the web site in its design and code is good, incompatibility will be noticed less.

WHY INCOMPATIBILITY ARISES?

- It arises either because of the incompatibility of the web browser or because of the problems in the web site itself.

- So you need to focus on the design an implementation of your web site rather than bogging up yourself with the browser issues.

- Employing cutting edge HTML can also run you in to the incompatibility problems as the HTML standards usually are a way step ahead of what is supported by the web browsers.

- Till now, no such browser has been developed that will take in to consideration 100 percent HTML.

- No doubt there are certain browsers that are a bit close to this value than the others.

- Using latest versions and standards of the HTML is always not a good choice. So be wise when you choose the version of HTML for designing up your web site.

- Another fact to be kept in mind is that not all the web browsers are equally efficient in translating the HTML code in to formatted web sites.

- There are some browsers that may leave certain parts of the HTML code because they are not able to execute it and again you will have trouble with your browser compatibility.

- Also all the web browsers do not translate a web page in the same manner and don’t give the same results.

- Before you start building up your web site, check out the compatibility of the different browsers so that you will have an idea what all formats and standards they support and you can build your site according and simultaneously avoiding a bug deal of incompatibility.

- After you have finished developing your web site, have your pages validated. If you are getting errors in your web site try out the trail and error debugging method.

Though the World Wide Web consortium has specified the standards for using HTML, you can very well invent your own and design your web site accordingly. But this has a disadvantage that the browser may reject the parts that cannot be executed and the appearance and functioning of your web site will be affected.

The basic difference between the two versions of a browser lies in the support they provide for the HTML. But on top of all it would be better if you pay attention to the browser compatibility while designing your web site. This will prevent you from running in to future issues regarding the incompatibility of the browser.

What is meant by content spoofing in detail?

Content spoofing is a rarely discussed topic and is much unheard by the many of us!
So let's evaluate the concepts of content spoofing in detail:

- Content spoofing has been categorized as an attack technique using which the attacker is able to inject a malicious code or payload in to the good content of a web site or a web application.

- This malicious payload or code is later thought of as being the legitimate content of that particular web site or web application which is a wrong interpretation.

- Content spoofing affects usually the web pages which have been built dynamically.

- Text only content spoofing is the technique in which the payload usually as text is passed in to the body of the web page or application in the form of a query string value.

- This approach usually takes effect on the pages of the web sites displaying some news entries and error pages.

- Such content is then later posted on the web site as its legitimate content.

- So when the users visit that particular link they perceive that the spoofed content is nothing but the legitimate content.

- In some cases it is possible that the pay load may exist on the web page for a longer time than estimated.

- Most of the web pages have been built dynamically with the sources from the HTML (hyper text mark up language).

- The attacker can easily change the content and when the particular web page is accessed by a browser, the location comes of the same domain as the user expected but the user does not come to know that the content is not legitimate instead it is shrouded one.

- As this is not enough to harm a web site, some attackers even manage to send malicious links to the users through emails and messages.

- In some cases the malicious links can be enforced up on the users following a cross site scripting attack.

- When the user clicks that link, he/ she visits the web page designed by the attacker with the malicious URL (uniform resource locator).

- The user will not come to know about this that he/ she is actually viewing am unauthentic web page.

- They will unknowingly believe that the spoofed content that they are viewing is purely authentic but this is not the case.

- Content spoofing does nothing but spoils the trust that the user has on the web site.

- The technique of content spoofing is being used like anything for the creation of fake web sites including fake login pages, press releases and defacement.

- Another point to be noted is that if you can fall victim to a cross site scripting attack, then the chances are that you may fall prey to content spoofing attacks as well.

- Content spoofing is a type of exploitation activity used by the hackers who have wrong intentions like presenting certain web pages to the user as if they are legitimate and not from an external source.

- This is somewhat similar to the SQL injection attacks. In both the cases the victims are defrauded like in phishing.

- Some attackers can even access the data base of a web application stored in a server and alter the contents.

- Content spoofing cannot be readily detected since there is large apparent difference between the actual and the spoofed content.

- The content spoofing carried out with the help of dynamic hyper text mark up language or DHTML is considered to be the most dangerous type since it can be used to form fake login pages.

- When any user inputs his sensitive data (can be a password, credit card number etc) in that page, the data goes directly to the attacker without the knowledge of the user that he has fallen victim to an identity theft.

What are different error handling defects?

Errors are a major headache to the software programmers, developers as well as testers. They cause the whole software system or application to falter, produce unexpected results and behave abnormally. Some errors cause more harm while some cause less, some are easy to discover whereas some are hideous, some are as active and disruptive like a volcano and others are dormant. Therefore error handling becomes an important factor in deciding the success of a program.

WHAT IS MEANT BY ERROR HANDLING?
- Error handling is the way of a program to handle the errors that disturb its functioning.
- The error handling procedure should be very strong and smart.
- Error handling requires a lot decision making.
- The error handling process like other processes also is a victim of defects.

STEPS IN ERROR HANDLING PROCESS & DEFECT CAUSING FACTORS

1. The main steps involved in an Error handling process are namely detection, anticipation and resolution of the errors that occur during the execution of the software program or application.

2. Some applications even employ programs called “error handlers” developed specially for handling the errors.

3. A software system or application is said to have good error handling capabilities if it is able to recover from the errors without causing the whole program to terminate or if it is not able to handle that error, properly terminates the program without causing any data loss.

4. Such forceful termination is nothing but an error handling defect.

5. The basic factors causing the run time errors are invalid input data and adverse function parameters.

6. Lack of memory is another defect causing factor.

A Software application comprises of various small programs.These programs may conflict with each other during the run time. Similarly web applications also experience due to electrical noise and malware or undue pressure on the server.

ERROR HANDLING PROCESS
A software system or application can overcome these errors by its error handling process. But this error handling process also faces some risks from any defects in its source code. Thus we can define the error handling defects as the defects that reduce the efficiency of the error handling process.

1. On the initiation of the error handling process, the discrepancy between the expected behavior and actual behavior is identified.
2. Whenever there is some discrepancy in the behavior of the program, a defect is created.
3. The test script that was being executed at the time of encounter of the defect is tested.
4. This process is called defect creation.
5. After this, the discovered defect is verified i.e., whether or not the defect is valid.
6. A severity level is assigned to the defect.
7. This severity level indicates the impact and visibility of the defect on the program.
8. The defect can cause the core functionality to go out of order or stop working.
9. It can affect the operational environment.
10. Such defects prevent the user from accessing the features and functionalities of the software system or application.
11. Incorrect navigation links are also a defect.
12. According to the level of the severity the encountered errors can cause, they are assigned priorities.
13. This process is defect prioritization.
14. Several priority codes have been defined.
15. There are some defects that do not even allow the testing to take place.
16. Defects causing such errors are given the highest priority.
17. The defect is once again confirmed and this process is called defect confirmation.
18. After the defect confirmation the defect is analyzed, the affected code is redesigned, developed and tested again for any shortcomings.
19. This process following the defect confirmation is called defect resolution.
20. The defects after being resolved are once again reviewed by the developer and certain test scripts are run to confirm that the defect has been resolved.
21. After the verification the defect is closed.

What are the different fault injection methods?

In the context of software engineering, fault injection is a technique or methodology meant for improving the test coverage. This is usually done by introducing faults in the program source code in order to test the code paths. In particular it is done to test the error handling test paths that might otherwise be left un- followed and thus, untested. Fault injection technique is often used in combination with the stress testing.

Fault injection technique is considered to be one of the most important parts of developing robust software. To add to your knowledge, robustness testing or syntax testing or fuzz testing is also a kind of fault injection methodology which is commonly used to detect the potential vulnerabilities of the communication interfaces such as application programming interfaces, command line parameters and protocols.

The injected fault goes through a well defined cycle before it becomes an observable failure. After the fault is injected, the program or the application is executed. Upon execution, the injected fault may cause an error which is to be considered as an invalid state within the boundaries of the system. This error may cause many further errors within the boundaries of the system. In this way each error acts as an injected fault and propagates to the system boundaries and comes to observance. When the states of the errors are observed at the boundaries of the system they are known as failures. This whole mechanism is known as “fault – error – failure – cycle”.

This mechanism forms a key mechanism in the context of dependability. In 19s the fault injection technique was used to introduce faults at the level of hardware system. This type of fault injection method is known as HWIFI or hardware implemented fault injection. It tends to simulate failures within a hardware system. Soon after that it was found that faults could also be introduced in the software system and it could be helpful in accessing the software system more appropriately.

These fault injection techniques are collectively known as SWIFI or software implemented fault injection. Techniques for software implemented fault injection can be classified into two major categories namely:

Compile time injection:
This can be defined as an injection technique in which the source code is modified so that the simulated faults can be injected into the system. One popular method for doing this is “mutation testing” in which the existing code is changed so as to induce faults. The other technique is “code mutation” in which the faults produced are very similar to those added unintentionally by the programmers. Another technique which is modification of code mutation technique known as code insertion fault injection adds code rather than modifying the existing piece of code. This is done with the use of simple functions which take an existing value and perturb it using some logic into another value. Such functions are called perturbation functions.

Run time injection:
This technique can be defined as the technique which makes use of a software trigger to inject fault in the system which is executing. Using this technique faults can be injected in a variety of ways such as those listed below:

- Time based triggers
An interrupt is generated when the timer reaches a specified time. The interrupt handler associated with the timer will inject the fault.

- Interrupt based triggers
Software trap mechanisms and hardware exceptions are effectively used to generate a fault in the code of the system at a particular point. This gives instant access to a specific memory location.

- Corruption of memory space
- Syscall interposition techniques
- Network level fault injection

If the bug is found, what should be done ?

Test cases are written to detect if a feature of an application is working correctly. It is a document which consists of input, action and expected output. After a bug is found, the developers are informed about the bug and are asked to fix it. After it gets fixed, the module is re-tested and it is checked whether it has not created any problem.

- Information of the bug and its severity.
- Bug identifier.
- Bug status.
- Application name.
- The name of the module, function, object etc. where the bug occurred.
- Environment factors.
- Test case name and identifier.
- One line bug description.
- Full bug description.
- If the bug is not covered by test case, steps are described again.
- Names of file used in test.
- Severity level
- Can the bug be reproduced.
- Tester name and test date.
- Name of developer.
- Description of cause of the problem.
- Description of the fix.
- Date of fix.
- Application version that contains the fix.
- Description about tester.
- Date of retest.
- Results of retest.
- Requirements of regression testing.
- Tester who has done regression tests.
- Results of regression testing.

Sometimes, the software is so buggy that it becomes impossible to test it. In order to handle this type of situation, the testers should report whatever bugs they are coming across, focusing more on critical bugs. It depicts deeper problems in the software development process.

Regression Testing – what is it, and what is the need

Often when a bug is detected in a software product all the energy of a developer is concentrated on that particular bug that he sometimes forgets the big picture which results in introduction of many more errors into the program. This is where regression testing comes into picture. Regression testing is any type of software testing that seeks to uncover software errors by partially retesting a modified program. In regression testing systematic selection of appropriate minimum suite of tests needed to adequately cover the affected change is done. Often it is extremely difficult for a programmer to figure out how a change in one part of the software will echo in other parts of the software hence regression testing includes rerunning previously run tests and checking whether previously fixed faults have re-emerged.
For identification of regression the most accepted practice is that once a bug is located and fixed, a test that exposes the bug is recorded and regularly retested after subsequent changes from the program. Although this can be done through manual testing procedures but often automated testing tools are used for this. Such test suites contain software tools that allow the testing environment to execute all the regression test cases automatically. In some cases these suites are re-run at specific intervals and any failures are reported. Regression testing is an integral any present day software development method. Extensive, repeatable and automated testing of the entire software is done at every stage in the software development cycle. Traditionally in the corporate world, regression testing is performed by the software quality assurance team after development team has completed work. As a consequence of introduction of new bugs, program maintenance requires far more system testing per statement written than any other programming. Theoretically, after each fix one must run the entire batch of test cases previously run against the system, to ensure that it has not been damaged in an obscure way. In practice, such regression testing is very costly.
The biggest challenge faced by this kind of regression testing is that these tend to be very fragile. Fragile in the sense that even a trivial change in the application often causes the tests to report “failures” that actually indicate that the script needs to be updated to deal with the change in the application. This causes inconvenience because it often takes more time and effort to maintain these automated regression tests that it would have taken to just execute them manually.
Concluding the discussion it should be mentioned the programmer should be aware when it is useful to use regression testing and when it’s a waste of resources. If your testing mission is to unleash as many defects as possible then maybe regression testing is not a good choice but when the purpose is to demonstrate the ruggedness of some specific features of the product on a relatively stable and mature application then automated testing is the right choice for you.

Antivirus Software - Signature based detection

Antivirus software is a computer program that detects, prevents, and takes action to disarm or remove malicious software programs, such as viruses and worms. Computer viruses are software programs that are deliberately designed to interfere with computer operation, record, corrupt, or delete data, or spread themselves to other computers and throughout the Internet.

There are several methods which antivirus software can use to identify malware :

Signature Based Detection

It is the most common method that anti-virus software uses to identify malware. This method is somewhat limited by the fact that it can only identify a limited amount of emerging threats, e.g. generic, or extremely broad, signatures.
Advantages :
- The signatures are easy to develop and understand if you know what network behavior you're trying to identify.
- The events generated by a signature-based IDS can very precisely inform you about what caused the alert.
- Signature based rules are based on Pattern matching, and with modern day systems pattern-matching can be performed very quickly.
- If your network is only having DNS, HTTP and SMTP traffic, all other signatures can be removed from the policy files.

Disadvantages :
- Signature based IDS can only detect known attacks, a signature must be created for every attack, and 0-day attacks cannot be detected.
- Signature based IDS systems are also prone to false positives since they are commonly based on regular expressions and string matching.
- Since they are based on pattern match, signatures usually don't work that great against attacks with self-modifying behavior.