\documentclass[conference]{IEEEtran}
\IEEEoverridecommandlockouts
% The preceding line is only needed to identify funding in the first footnote. If that is unneeded, please comment it out.
\usepackage{cite}

\usepackage{amsmath,amssymb,amsfonts}

\usepackage{graphicx}
\usepackage{textcomp}
\usepackage{xcolor}
\usepackage{algorithm}  
\usepackage{algpseudocode}  
\usepackage{amsmath}
\usepackage{subfigure}
\usepackage{verbatim}
\def\BibTeX{{\rm B\kern-.05em{\sc i\kern-.025em b}\kern-.08em
    T\kern-.1667em\lower.7ex\hbox{E}\kern-.125emX}}
\begin{document}

\title{p-fuzz: an efficient greybox-fuzzing tool with parallel computing mechanism \\
{\footnotesize \textsuperscript{*}Note: Sub-titles are not captured in Xplore and
should not be used}
\thanks{Identify applicable funding agency here. If none, delete this.}
}

\author{\IEEEauthorblockN{1\textsuperscript{st} Given Name Surname}
\IEEEauthorblockA{\textit{dept. name of organization (of Aff.)} \\
\textit{name of organization (of Aff.)}\\
City, Country \\
email address}
\and
\IEEEauthorblockN{2\textsuperscript{nd} Given Name Surname}
\IEEEauthorblockA{\textit{dept. name of organization (of Aff.)} \\
\textit{name of organization (of Aff.)}\\
City, Country \\
email address}
\and
\IEEEauthorblockN{3\textsuperscript{rd} Given Name Surname}
\IEEEauthorblockA{\textit{dept. name of organization (of Aff.)} \\
\textit{name of organization (of Aff.)}\\
City, Country \\
email address}
\and
\IEEEauthorblockN{4\textsuperscript{th} Given Name Surname}
\IEEEauthorblockA{\textit{dept. name of organization (of Aff.)} \\
\textit{name of organization (of Aff.)}\\
City, Country \\
email address}
\and
\IEEEauthorblockN{5\textsuperscript{th} Given Name Surname}
\IEEEauthorblockA{\textit{dept. name of organization (of Aff.)} \\
\textit{name of organization (of Aff.)}\\
City, Country \\
email address}
\and
\IEEEauthorblockN{6\textsuperscript{th} Given Name Surname}
\IEEEauthorblockA{\textit{dept. name of organization (of Aff.)} \\
\textit{name of organization (of Aff.)}\\
City, Country \\
email address}
}

\maketitle

\begin{abstract}
Fuzz is an effective technology in software testing and security vulnerability detection. Unfortunately, fuzzing is an extremely compute-intensive job, which may cause thousands of computing hours to find a bug. Current novel works generally improve fuzzing efficiency by developping delicate algorithms. In this paper, we propose another direction of improvement in this filed, i.e., leveraging parallel computing to improve fuzzing effiency. In this way, we develop p-fuzz, a parallel fuzzing system that can utilize massive distributed computing resources to fuzz a single program. p-fuzz uses a no-sql database to share the fuzzing status such as seeds, covered paths, etc. All fuzzing nodes get jobs from the database, and update their fuzzing status to the database. We control the synchronization period to a coarse granularity so that the database will not be a bottleneck. P-fuzz is implemented based on AFL. We compare p-fuzz with AFL and XXX in our experiment. The result shows that we can easily gain a speedup of AFL by simply using 4 nodes, i.e., using 3X more resources. 
\end{abstract}

\begin{IEEEkeywords}
fuzz, parallel computing, AFL, vulnerability
\end{IEEEkeywords}

\section{Introduction}
Nowadays, software is applied widely in our life, which accompanied with the occurrence of security vulnerabilities. Attackers always utilize these bugs and errors in codes to make target crash or grab some sensitive data. Therefore, it is urgently needed for us to pay close attention to find an effective approach to test software.

Fuzzing is an effective method to test bugs or find security vulnerabilities in software. To test a program, a fuzzing tool usually first generates a lot of different test cases. Then it uses each test case as input to run the target and monitor whether the execution get some exceptions. In this way, it detects  bugs or security vulnerabilities. Many big companies use fuzzing in their software testing, such as Microsoft [sage], Google [oss], Amazon [Cloud9] etc.   Fuzzing is popular in research and security community [AFL]. Thousands of security vulnerabilities are desceovered by fuzzing [AFL, CVE list]. According to the knowledge and information acquired from the target programs, fuzzing can be divied into white-box fuzzing, black-box fuzzing, and greybox fuzzing. A white-box fuzzer has full knowledge of the source code (eg. internal logic and structure) and uses the control structure of the procedural design to derive test cases. Fuzzers that use symbolic execution [] to accurately direct the execution path of a program execution can also be classified into white-box fuzzing. In contrast, The black-box fuzzer doesn’t have any knowledge of target program, thus it generates test cases randomly and swiftly. The grey-box fuzzer try to combine the efficiency and effectiveness of black-box fuzzers and white-box fuzzers, which masters limited knowledge of the internal working of target programs. Currently, grey-box fuzzing is practical and widely used in testing and vulnearability detection as it is lightweight, fast and easy-to-use []. In this paper, we focus on improving grey-box fuzzing.

Greybox-fuzzing usually have three stages: (1) it select a seed from the seed list and mutate the seed to generate a group of test cases, (2) it feed the program with each test case and run it to collect the execution information (paths, branches, etc.), and (3) it uses the execution information to select new seeds from test cases (test case that trigger new branch is selected as seed).  A typical greybox-fuzzing tool is American Fuzzy Lop (AFL) []. In AFL, the  information it collect during each run is executed branches. It compress the branches into a 64K bitmap to make bitmap access fast. 

Like AFL, greybox fuzzing is simple and effective. However, greybox-fuzzing is still compute-intensive and cost a lot of CPU hous to fully test a program. For example, it usually takes several days or even several months to find the bug of a program. Current researches mainly forcus on improving the algorithms to make fuzzing faster []. CollAFL solves the bitmap confliction problem of AFL and make seed selection sensitive to all new branches. ...

Unlike all those works, we see this efficiency problem of greybox fuzzing in a different point of view. Instead of trying to improve a single fuzzing instrance, we try to parallize fuzzing instrances to accelerate a single fuzzing job. In this way, we can trade resource and energe for time in software testing. Our method is based on two facts. First, parallel computing is ubiquitous nowdays. We can get massive cheap computing resource easily (e.g., by using the Amazon spot instance). Second, time is much valuable in software testing and security. Consider the situation a newly developped software is about to be release. It is worth to speed more cost to make the release on schedule. Besides, parallel fuzzing optimzation is orthogonal with algorithm improve approaches. Any improved fuzzing algorithm can be easily applied in our parallel fuzzing system. 

Current parallel fuzzing approaches are either too old or have drawbacks. Grid fuzzer leverage grid computing to parallel fuzz jobs []. It distribute fuzzing tasks statically. This method is not suitable for greybox fuzzing as work cannot be statically distributed as the feedback mechanism of greybox fuzzing. XXX presents a distributed fuzzing framework which can manage the computing resources in a cluster and schedule the resources to many submitted fuzzing jobs. However, this work  is not intend to accelerate a single fuzzing job. XXX and XXX can parallel AFL to fuzz a single software with distributed nodes. However, they only parallel the random mutation part of ALF and fail to parallel the certain mutation part.

In this paper, we intend to design a fully parallelized greybox fuzzer and take the advantages of distributed computing nodes to speedup the fuzzing process of a software. The challenges are (1) how to distributed work load to different nodes, (2) how to synchronize fuzzing status, e.g., seeds, shared data structures, etc., and (3) 

What we do 



Furthermore, existing fuzzers have been effective mainly in discovering superficial vulnerabilities and fail to uncover the vulnerabilities in deep paths without valid guidance. Through collecting the feedback information of target programs, grey-box fuzzers show the competitiveness of mutating test cases with valid guidance. It is implemented by lightweight instrumentation or other mechanisms to get program execution feedback, such as code coverage for the fuzzing process. American Fuzz Lop(AFL)  is a state-of-the-art grey-box fuzzer whose principles are speed, reliability, and ease of use. AFL instruments the compiled program to get the edge coverage information. It adopts a deterministic strategy and non-deterministic strategy to generate test cases by mutating input seeds. The “interesting” change will be recorded for further detecting. 
Several works achieved significant results based on making an extension of the AFL. Böhme et al. designed AFL-fast which assigned more mutation energy to interesting paths. Gan et al introduced CollAFL which mitigated the path collisions by providing more accurate coverage information.  Böhme also implemented a directed grey-box fuzzing tool AFLGO  towards the dangerous locations which tend to produce vulnerabilities. All of these extensions gained higher coverage and found more bugs than AFL. Zhang et al. leverage hardware mechanism (Intel Processor Trace) to collect branch information, and feed this information back to the fuzzing process. 

Nevertheless, there are some common challenges in single-computer structure fuzzing.

\begin{itemize}
\item The fuzzing process contains too many tedious mutations.
\item The fuzzing efficiency and effectiveness are relatively low because of executing too much-repeated work.
\end{itemize}
In order to address the challenges, many researchers leverage parallel computing technology to speed up the fuzzing process. Parallel computing indicates a type of computation where many calculations are executed simultaneously. It collects a group of computing resources to decompose the heavy fuzzing task. Test cases produce by mutation are allocated to each computer, which balances the system workload. Some researchers have proceeded works about parallel or distributed fuzzing. Xie using grid computing for large scale fuzzing in 2010, which reduce almost two-thirds of fuzzing time. It was implemented by dividing fuzzing jobs into tasks, storing them in a server and scheduling remote clients to download them. Lian et al.  proposed a dynamic resource-aware approach for parallel fuzzing. Some distributed fuzzing tools based on the parallel function of AFL are implemented in the client-server model. The clients synchronize their queue to server continuously which benefit from each other's work.


Despite the parallel computing technology accelerate the fuzzing process, it faces several challenges and difficulties:
\begin{itemize}
\item The client computers are always fuzzing same test cases caused the concurrency and race. 
\item The transferring speed is limited while the quantity of common resources is large enough.
\item Fixed synchronizing time entails the response latency to a new test case.
\item All clients share the same seeds get from the server. The approach tires clients and entails the low resources utilization of test cases.
\end{itemize}
By summarizing these research above, we propose a parallel fuzzing platform —p-fuzz, which not only alleviates the problems but also speeds up the fuzzing process by leveraging abundant parallel resources. 


\section{background}

\subsection{Parallel computing technology}

Parallel computing specifies a type of computation where many calculations are executed simultaneously. According to different granularities, parallel computing can be classified into bit-level, instruction-level, data-level, and task-level parallelism. 
 The task-level parallelism means a large job can be divided into several small tasks, and each node of parallel computers gets a piece of the task and execute it. In this paper, we talk about task-level parallelism.

The origin of parallel computing technology dates back to 1950s. John Cocke and Daniel Slotnick discuss the use of parallelism in numerical calculations. In the 1970s, The e-mail was invented and became the earliest and most successful example of a large-scale distributed application in ARPANET. By demanding and increase exponentially, distributed and parallel computing became its own branch of computer science in the 1980s.
In the 1990s, client-server architecture appeared and became popular. After 2000, With the big data era coming, grid computing and cloud compu{}ting provided various, massive and prompt services by their extraordinary computing ability. Nowadays, supercomputer plays an important role in computing. It handles a wide range of computationally intensive tasks in various fields.

To be specific. a distributed parallel application always falls into one of several basic architectures: client-server, three-tier, n-tier, or peer-to-peer and database-centric Architecture. Database-centric architecture specifies the software architecture in which databases is a core of the whole system. The architecture provides reliability, performance, and capacity, and scalability. We implement the p-fuzz platform with the help of database-centric architecture, and details of implementation are discussed in section \ref{alogrithm}.

\subsection{The details about AFL}
In this section, we will discuss fuzzing techniques and AFL in detail. These limitations motivate us to propose our p-fuzz. 
American Fuzzy Lop(AFL) is an instrumentation-guided grey-box fuzzer. The fuzzer stays brute-force that makes the fuzzing process keep speed. 
AFL is designed for such goals, i.e,
\begin{itemize}
\item Speed: adopting an appropriate instrument approach not only gives guidance to fuzzing but also keeps its native speed.
\item Rock-solid reliability, it adapts to real-world targets.
\item Simplicity. AFL is simple and user-friendly.
\end{itemize}
There are two things we need to care about: the \textbf{seed} and \textbf{bitmap}.
\subsubsection{Seed}
Seed indicates the test cases which trigger the fuzzer to traverse new interesting paths. A queue is maintained to store the seeds. The high-quality corpus of candidate files will be selected as interesting seeds for further rounds.

\subsubsection{Bitmap}
Before talking about bitmap, we need to define the “new branch”. If there are three basic blocks A, B, C in a program, the tuple (AB, BC) describes a branch transition. A new branch indicates a branch transition which doesn’t appear before.  
In AFL, if a new branch is triggered by a test case, it is considered as a new path. All of the branches information is recorded in the bitmap. Bitmap describes the coverage of fuzzing, which stored in shared memory. the index of a bitmap is produced by previous basic block and current basic block. How to index a branch transition is shown as following. \emph{A} and \emph{B} represent previous basic block and current basic block respectively.
\begin{equation}
(A\oplus B)\%BITMAP\_SIZE\label{eq1}
\end{equation}

However, AFL is inaccurate because of the path collision caused by an infinite space of bitmap. It prevents AFL from discovering potential paths that lead to new crashes. 

\subsection{The discussion of parallel mechanism in fuzzing}
In fact, if you only put a single job on a multi-core system or a multi-machine computing group, you will be underutilizing the hardware. At this time, parallel the computing resources can make full use of hardware and bring profit to low-efficiency fuzzing process. We will discuss how to make parallelization in this section.

\subsubsection{A Naïve approach}

\begin{algorithm}  
\begin{algorithmic} %每行显示行号  
        \caption{123}
                \State $int i = 0$  
                \State $scanf("\%d",\&i)$  
                    \If{$i > 0$}  
 						\If{$i<100000 \&\& i>=1000$}  
  						\If{$i>=5000 \&\& i<10000$}  
 			  				\If{$i>=7000 \&\& i<8000$}  
  			  				\If{$i>=7500 \&\& i<=7599$}  
   			  				\If{$i>=7545 \&\& i<7571$}  
								\State $ printf("win")$   
                   		 \EndIf 
                   		 \EndIf 
                   		 \EndIf 
                   		 \EndIf 
                   		 \EndIf 
                    \EndIf  
 
\end{algorithmic}  
\end{algorithm} 

A naïve approach to improve the efficiency of fuzzing is starting a group of fuzzers. However, the approach fails to produce a satisfying result and occupy resources,
we take a simple experiment to show this case. As is shown in algorithm.1 the simple program contains 6 levels branches. 
If we only run a single AFL engine, it reaches the “win” location in 2 minutes and 34s. Compared with the single engine, we run two engines in two cores simultaneously, the time of reaching “win” location keeps at the same level.

Also, we respectively run an AFL engine and two AFL engines in two cores on a target program “uniq” in lava-m, and compare their bitmap density. In one hour, a single engine and two engines get same results. Both of them hit 214 new branches, which are shown in bitmaps.



\subsubsection{Previous parallel fuzzing application}

There are two fuzzing tools extent the parallel function in AFL.
One is Roving, which is implemented by running multiple copies of AFL on multiple machines in a cluster, all of them fuzzing the same target. It benefits from the client-server structure which shares crashes, hangs, and queues of each client. Every 300 seconds, the client update the fuzzing environment by uploading and downloading changes. The whole framework is scheduled by the central server. 

The other is distributed fuzzing. The main work of distributed fuzzing is similar to roving, and the difference of them is implementation. the sharing data is handled by PHP scripts in fuzzing server. All of the target projects are stored in a server. Clients download  1 or more projects(according to CPU cores) and AFL fuzzes program from the server.
New queue and hangs and crashes produced by a client will be synchronized to the server and downloaded by other clients in fixed time gap.

Although the two frameworks utilize the computing resources and parallel the fuzzing progresses, which makes each client benefits from each other's work, they have drawbacks as below.
\begin{itemize}
\item As time goes by, the seeds, queues, crashes and hangs entail the synchronizing speed slower and slower.
\item This kind of sharing mechanism makes all of the clients always fuzzing the same seeds.
\item The server accepts all data from clients updated, which will result in security problems.
\end{itemize}
\subsection{Concurrency and data race}
In parallelization computing, some uncontrolled accesses to shared data happen simultaneously, which results in race conditions. Data races are race conditions occur at memory access level, which are the most common causes of the concurrency errors and bugs.   

A data race occurs when two actions are accessing the same memory, and at least one of the two accesses is a write, and the sequence of accesses is not assured by synchronization primitives.  
To prevent memory access from data race, some methods such as lock, semaphore, and mutex are adopted. The database always adopts transactions to solve some level of data races after recovery from a crash to maintain the atomicity, consistency, isolation, and durability.

\section{methodology}\label{alogrithm}
To improve the fuzzing speed and make full use of computing resources, we design p-fuzz, which is a parallel fuzzing framework.

\subsection{The algorithm of balancing workloads}

\begin{figure}[htbp]
\centering
\subfigure[The example of distributing workloads by previous works ]{\includegraphics[width=4cm,height=3.8cm]{figcarryboxa.png}}
\subfigure[The example of distributing workloads by p-fuzz]{\includegraphics[width=4cm,height=3.8cm]{figcarryboxb.png}}
\caption{Example of distributing workloads}
\label{figcarrybox}
\end{figure}


Hardware resources and fuzzing tasks are two entities of parallel fuzzing. And the most important work is to distribute fuzzing tasks to hardware resources appropriately.
previous studies show us two drawbacks in tackling this work:
\begin{itemize}
\item Underutilizing the hardware resources, which burdens the single core with many fuzzing tasks.
\item Sharing all information including(seeds, queues, crashes and hangs) with each of client, which may results all computing cores do repeated work and doesn’t fully reflect the advantages of parallel. This case is depicted in Fig.\ref{figcarrybox}(a).
\end{itemize}

To make full use of hardware resources and enhance fuzzing efficiency, we schedule the fuzzing tasks to balance workload with the help of Database-centric architecture as Fig.\ref{figcarrybox}(b). Database-centric architecture put a database as a core of the whole system, and other hardware resources act as clients to communicate with the database. 
The p-fuzz framework is designed based on the database-centric architecture as shown in Fig.\ref{figoverview}.
We deploy a server with a database to communicate with other hardware resources. Also, we mark the sharing records with flags and time stamps in the database, to differentiate whether this record is occupied by a client. 
Furthermore, we start services to monitor the server which can not only schedule the fuzzing tasks, but also solve the race problem from parallelization. 
In this way, all of the hardware resources get different seeds and do different tasks in the scheduling of p-fuzz mechanism. 


\begin{figure}[htbp]
\centerline{\includegraphics[width=8cm,height=6cm]{figoverview.png}}
\caption{the framework overview of p-fuzz}
\label{figoverview}
\end{figure}

\subsection{Immediate response to update}
Different from roving and distributed fuzzing which synchronizes the sharing data in a fixed time gap, p-fuzz updates the new seeds and bitmap data to the database when AFL produces them. 

When a test case triggers a new interesting path in the fuzzing process, the test case will be uploaded as a record in the database.
Also, the bitmap stored in the database will be updated in time when a client find of a new path.

It’s a prompt action to make all clients in the system get the information immediately.


\subsection{Data race handling}
\subsubsection{Flag:two clients want to access the same seed simultaneously.}

As above mentioned, we sharing seeds each AFL produced by storing them into a database. Different clients access to different seeds to enhance the fuzzing efficiency. However, when two clients access to a seed simultaneously, a data race happen. The same seed fuzzed repeatedly will produce a similar result.

To alleviate this case, we set a flag with seeds, which marks whether this seed is fuzzing by a client. If the flag is “1”, the client will choose other seeds to fuzz.

\subsubsection{Service:some clients update bitmap in the database simultaneously}

We store the bitmap as a record in the database for sharing. A data race happen as shown in Fig.\ref{figbitmap}. some bitmaps with “1” or “0” represent the path uncovered or covered. There are two clients updating their new bitmaps together(Fig.\ref{figbitmap}(b)(c)). If we do not control the updating process, information will get lost which is shown in Fig.\ref{figbitmap}(d).

To alleviate this case, we start a service in the server to maintain the sequence of updating. The service builds a queue to store the bitmap temporarily. When bitmaps come up together, they are enqueued according to the time order. The database merges these bitmaps in the queue one by one so that the bitmap maintains all necessary information.
\begin{figure}[htbp]
\centering
\subfigure[the origin bitmap]{\includegraphics[width=2cm,height=1.7cm]{figbit1.png}}
\subfigure[the bitmap updated from client1]{\includegraphics[width=2cm,height=1.7cm]{figbit2.png}}
\subfigure[the bitmap updated from client2]{\includegraphics[width=2cm,height=1.7cm]{figbit3.png}}
\subfigure[the final bitmap]{\includegraphics[width=2cm,height=1.7cm]{figbit4.png}}
\caption{race of updating bitmap from different clients}
\label{figbitmap}
\end{figure}

\subsubsection{Time stamp:a client quits fuzzing accidently but doesn’t finish a complete fuzzing round}
as above mentioned, we set a flag to mark whether the seed is occupied by a client. However, in parallel computing, a client sometimes quit with errors or other accidents. At this time, the flag is “1” but the fuzzing process of the corresponding seed isn’t finished. 

To solve this problem, we put a time stamp when the flag is set to “1”. We also monitor if the fuzzing is overtime by the current time minus the time stamp. This mechanism assures exceptions won’t disturb the parallel fuzzing.




\section{implementation}\label{implementation}
\subsection{Workflow}
The workflow of p-fuzz is shown below:
\begin{itemize}

\item Setting up the database in the server machine
\item Configuring the services
\item Starting afl in each clients
\item Getting the results

\end{itemize}

\subsection{Server}
The server machine is the core of the whole system. We deploy a MongoDB database on the server to store the sharing data. 
\begin{figure}[htbp]
\centering
\subfigure[the seed collection in the database]{\includegraphics[width=8cm,height=1cm]{figdbseed.png}}
\subfigure[the bitmap collection in the database]{\includegraphics[width=8cm,height=0.8cm]{figdbbitmap.png}}

\caption{the two collections of database}
\label{figdatabase}
\end{figure}

\subsubsection{MongoDB}
MongoDB is an open-source document database, which with high performance, high availability and automatic scaling.

As shown in Fig.\ref{figdatabase}(a)(b), We set two collections in the database. One is “seed”, the first row is the key to the collection which is a hash value of file name , the second row records the content of seed, the third row is flag to mark whether the seed is being fuzzed, and the last row is timestamp, which is used to mark when the fuzzing start.

The other is “bitmap”, the first row is the key of the collection is a hash value of file name, the second row records the sharing bitmap.

\subsubsection{Service}
As shown in Fig.\ref{figservice}, we start a service in the server to maintain the sequence of updating. The service binding with server keeps running and records the time of each bitmap coming. When bitmaps from several clients are sent to the server together, the service put them into a queue according to the time order. The queue provides bitmaps to the database to merge them into latest state continuously. 

\begin{figure}[htbp]
\centerline{\includegraphics[width=8cm,height=3cm]{figservice.png}}
\caption{the workflow of service}
\label{figservice}
\end{figure}


\subsection{Client}
We choose several computers in a local area network as clients. We deploy p-fuzz client, which is a parallel fuzzing AFL version on each client, and put the same program to being fuzzed. At the start of fuzzing, each client downloads a seed from the central database. When the fuzzing engine finds some interesting paths, it updates these new seeds to the central database. Furthermore, the write and read in fuzzing is conducted by updating or downloading records to or from the central database. We achieve sharing data in parallel fuzzing by this mechanism

\section{experiment}
\subsection{experiment setup}
\subsection{comparison in crashes and branches}
\subsection{comparison in speed}

\section{discussion}
\subsection{limitation}
\subsection{future work}
\section{conclusion}

\begin{equation}
a+b=\gamma\label{eq}
\end{equation}

Be sure that the 
symbols in your equation have been defined before or immediately following 
the equation. Use ``\eqref{eq}'', not ``Eq.~\eqref{eq}'' or ``equation \eqref{eq}'', except at 
the beginning of a sentence: ``Equation \eqref{eq} is . . .''

\subsection{\LaTeX-Specific Advice}

Please use ``soft'' (e.g., \verb|\eqref{Eq}|) cross references instead
of ``hard'' references (e.g., \verb|(1)|). That will make it possible
to combine sections, add equations, or change the order of figures or
citations without having to go through the file line by line.

Please don't use the \verb|{eqnarray}| equation environment. Use
\verb|{align}| or \verb|{IEEEeqnarray}| instead. The \verb|{eqnarray}|
environment leaves unsightly spaces around relation symbols.

Please note that the \verb|{subequations}| environment in {\LaTeX}
will increment the main equation counter even when there are no
equation numbers displayed. If you forget that, you might write an
article in which the equation numbers skip from (17) to (20), causing
the copy editors to wonder if you've discovered a new method of
counting.

{\BibTeX} does not work by magic. It doesn't get the bibliographic
data from thin air but from .bib files. If you use {\BibTeX} to produce a
bibliography you must send the .bib files. 

{\LaTeX} can't read your mind. If you assign the same label to a
subsubsection and a table, you might find that Table I has been cross
referenced as Table IV-B3. 

{\LaTeX} does not have precognitive abilities. If you put a
\verb|\label| command before the command that updates the counter it's
supposed to be using, the label will pick up the last counter to be
cross referenced instead. In particular, a \verb|\label| command
should not go before the caption of a figure or a table.

Do not use \verb|\nonumber| inside the \verb|{array}| environment. It
will not stop equation numbers inside \verb|{array}| (there won't be
any anyway) and it might stop a wanted equation number in the
surrounding equation.

\subsection{Some Common Mistakes}\label{SCM}
\begin{itemize}
\item The word ``data'' is plural, not singular.
\item The subscript for the permeability of vacuum $\mu_{0}$, and other common scientific constants, is zero with subscript formatting, not a lowercase letter ``o''.
\item In American English, commas, semicolons, periods, question and exclamation marks are located within quotation marks only when a complete thought or name is cited, such as a title or full quotation. When quotation marks are used, instead of a bold or italic typeface, to highlight a word or phrase, punctuation should appear outside of the quotation marks. A parenthetical phrase or statement at the end of a sentence is punctuated outside of the closing parenthesis (like this). (A parenthetical sentence is punctuated within the parentheses.)
\item A graph within a graph is an ``inset'', not an ``insert''. The word alternatively is preferred to the word ``alternately'' (unless you really mean something that alternates).
\item Do not use the word ``essentially'' to mean ``approximately'' or ``effectively''.
\item In your paper title, if the words ``that uses'' can accurately replace the word ``using'', capitalize the ``u''; if not, keep using lower-cased.
\item Be aware of the different meanings of the homophones ``affect'' and ``effect'', ``complement'' and ``compliment'', ``discreet'' and ``discrete'', ``principal'' and ``principle''.
\item Do not confuse ``imply'' and ``infer''.
\item The prefix ``non'' is not a word; it should be joined to the word it modifies, usually without a hyphen.
\item There is no period after the ``et'' in the Latin abbreviation ``et al.''.
\item The abbreviation ``i.e.'' means ``that is'', and the abbreviation ``e.g.'' means ``for example''.
\end{itemize}
An excellent style manual for science writers is \cite{b7}.

\subsection{Authors and Affiliations}
\textbf{The class file is designed for, but not limited to, six authors.} A 
minimum of one author is required for all conference articles. Author names 
should be listed starting from left to right and then moving down to the 
next line. This is the author sequence that will be used in future citations 
and by indexing services. Names should not be listed in columns nor group by 
affiliation. Please keep your affiliations as succinct as possible (for 
example, do not differentiate among departments of the same organization).

\subsection{Identify the Headings}
Headings, or heads, are organizational devices that guide the reader through 
your paper. There are two types: component heads and text heads.

Component heads identify the different components of your paper and are not 
topically subordinate to each other. Examples include Acknowledgments and 
References and, for these, the correct style to use is ``Heading 5''. Use 
``figure caption'' for your Figure captions, and ``table head'' for your 
table title. Run-in heads, such as ``Abstract'', will require you to apply a 
style (in this case, italic) in addition to the style provided by the drop 
down menu to differentiate the head from the text.

Text heads organize the topics on a relational, hierarchical basis. For 
example, the paper title is the primary text head because all subsequent 
material relates and elaborates on this one topic. If there are two or more 
sub-topics, the next level head (uppercase Roman numerals) should be used 
and, conversely, if there are not at least two sub-topics, then no subheads 
should be introduced.

\subsection{Figures and Tables}
\paragraph{Positioning Figures and Tables} Place figures and tables at the top and 
bottom of columns. Avoid placing them in the middle of columns. Large 
figures and tables may span across both columns. Figure captions should be 
below the figures; table heads should appear above the tables. Insert 
figures and tables after they are cited in the text. Use the abbreviation 
``Fig.~\ref{fig}'', even at the beginning of a sentence.

\begin{table}[htbp]
\caption{Table Type Styles}
\begin{center}
\begin{tabular}{|c|c|c|c|}
\hline
\textbf{Table}&\multicolumn{3}{|c|}{\textbf{Table Column Head}} \\
\cline{2-4} 
\textbf{Head} & \textbf{\textit{Table column subhead}}& \textbf{\textit{Subhead}}& \textbf{\textit{Subhead}} \\
\hline
copy& More table copy$^{\mathrm{a}}$& &  \\
\hline
\multicolumn{4}{l}{$^{\mathrm{a}}$Sample of a Table footnote.}
\end{tabular}
\label{tab1}
\end{center}
\end{table}

\begin{figure}[htbp]
\centerline{\includegraphics{fig1.png}}
\caption{Example of a figure caption.}
\label{fig}
\end{figure}

Figure Labels: Use 8 point Times New Roman for Figure labels. Use words 
rather than symbols or abbreviations when writing Figure axis labels to 
avoid confusing the reader. As an example, write the quantity 
``Magnetization'', or ``Magnetization, M'', not just ``M''. If including 
units in the label, present them within parentheses. Do not label axes only 
with units. In the example, write ``Magnetization (A/m)'' or ``Magnetization 
\{A[m(1)]\}'', not just ``A/m''. Do not label axes with a ratio of 
quantities and units. For example, write ``Temperature (K)'', not 
``Temperature/K''.

\section*{Acknowledgment}

The preferred spelling of the word ``acknowledgment'' in America is without 
an ``e'' after the ``g''. Avoid the stilted expression ``one of us (R. B. 
G.) thanks $\ldots$''. Instead, try ``R. B. G. thanks$\ldots$''. Put sponsor 
acknowledgments in the unnumbered footnote on the first page.

\section*{References}

Please number citations consecutively within brackets \cite{b1}. The 
sentence punctuation follows the bracket \cite{b2}. Refer simply to the reference 
number, as in \cite{b3}---do not use ``Ref. \cite{b3}'' or ``reference \cite{b3}'' except at 
the beginning of a sentence: ``Reference \cite{b3} was the first $\ldots$''

Number footnotes separately in superscripts. Place the actual footnote at 
the bottom of the column in which it was cited. Do not put footnotes in the 
abstract or reference list. Use letters for table footnotes.

Unless there are six authors or more give all authors' names; do not use 
``et al.''. Papers that have not been published, even if they have been 
submitted for publication, should be cited as ``unpublished'' \cite{b4}. Papers 
that have been accepted for publication should be cited as ``in press'' \cite{b5}. 
Capitalize only the first word in a paper title, except for proper nouns and 
element symbols.

For papers published in translation journals, please give the English 
citation first, followed by the original foreign-language citation \cite{b6}.

\begin{thebibliography}{00}
\bibitem{b1} G. Eason, B. Noble, and I. N. Sneddon, ``On certain integrals of Lipschitz-Hankel type involving products of Bessel functions,'' Phil. Trans. Roy. Soc. London, vol. A247, pp. 529--551, April 1955.
\bibitem{b2} J. Clerk Maxwell, A Treatise on Electricity and Magnetism, 3rd ed., vol. 2. Oxford: Clarendon, 1892, pp.68--73.
\bibitem{b3} I. S. Jacobs and C. P. Bean, ``Fine particles, thin films and exchange anisotropy,'' in Magnetism, vol. III, G. T. Rado and H. Suhl, Eds. New York: Academic, 1963, pp. 271--350.
\bibitem{b4} K. Elissa, ``Title of paper if known,'' unpublished.
\bibitem{b5} R. Nicole, ``Title of paper with only first word capitalized,'' J. Name Stand. Abbrev., in press.
\bibitem{b6} Y. Yorozu, M. Hirano, K. Oka, and Y. Tagawa, ``Electron spectroscopy studies on magneto-optical media and plastic substrate interface,'' IEEE Transl. J. Magn. Japan, vol. 2, pp. 740--741, August 1987 [Digests 9th Annual Conf. Magnetics Japan, p. 301, 1982].
\bibitem{b7} M. Young, The Technical Writer's Handbook. Mill Valley, CA: University Science, 1989.
\end{thebibliography}
\vspace{12pt}
\color{red}
IEEE conference templates contain guidance text for composing and formatting conference papers. Please ensure that all template text is removed from your conference paper prior to submission to the conference. Failure to remove the template text from your paper may result in your paper not being published.

\end{document}
