Transcription
Tanushree Roy et al, / (IJCSIT) International Journal of Computer Science and Information Technologies, Vol. 3 (3) , 2012, 4427- 4433Windows Registry Forensics: An Imperative Stepin Tracking Data Theft via USB DevicesTanushree Roy, Aruna JainDepartment of I.T.Birla Institute of Technology, Mesra, Ranchi, IndiaAbstract— Owing to the increasing pace of occurrence ofcrimes in digital world, cyber forensic investigation isbecoming a burning topic in the field of information security.Registry is an important location in Windows system thatcontains footprints of user activities and other configurationdata, which may be valuable for forensic investigators incollecting potential evidences from the system. This work aimsto point out the significance of Registry Analysis, and attemptsto answer why it should be carried as a part of digital forensicinvestigation by demonstrating the role played by Registry intracking data theft from system to USB external devices.Keywords— Forensics Analysis, Registry Analysis, TrackingData Theft, USB footprints, Windows Forensics.I. INTRODUCTIONIn the recent years, with the development of Informationand Communication Technology (ICT) and rise in Internetusage, society’s dependence upon computers is increasingrapidly. With this growth of technology, the world is alsoseeing a substantial rise in the abuse of various kindsconducted with, through or by technology. According to theNorton Cyber Crime report-2011 by Symantec Corporation[9], about 1 million cyber crimes are occurring every dayacross the globe. According to the report, the total numberof victims in India is 29.9 million, which is approx. 80% ofthe online adults. The reason for this increasing abuse isattributed to the still-to-be-mature existing securityprocedures and the reluctance persistent among users inemploying security methods as an integral part of the wholesystem.As a result, cyber crimes are increasing and, cybercriminals are growing in sophistication as technology actsas a boon for them too. Thus, it becomes exceptionallycritical for the law enforcement officers and incidentresponders to understand computer systems and be able toexamine them effectively and efficiently.Cyber forensics is the branch of science that acts as atool for the investigators for investigating a computersystem or network alleged of being involved in criminalactivity and, gathering artifacts that may be used asevidence in the case and presented in the court of law.Due to its effective GUI and ease of use, MicrosoftWindows is one of the most popular operating system and,is; unfortunately the most attacked one too. As windowssource code is unavailable, forensic analysis of windowssystems becomes a challenging task for the investigators.Registry is one of the areas in a Windows system whereevidences can be found. This work aims to point out theimportance of Registry Analysis process carried inWindows Systems as a part of digital forensic investigationin today’s scenario. An offline registry parser developed asa part of this work will be used to generate registry keysfrom registry hives, extracted from the hard disk as a part ofpostmortem analysis.In this Information age, ownership of intellectualproperty is very precious and prized. Theft of intellectualproperty is one of major issues of concern, which canbecome a trouble not only for an individual, but for a wholeorganization. USB ports, as well as other ports that permitsone to attach a removable storage device, can act as apromising means to steal classified information. Any userwith a removable USB drive can attach the device to thesystem and copy critical information.In this paper we have discussed how by means of acareful investigation of the Registry files, data transfer toUSB devices be identified. We begin by stating the workdone by various researchers in section 2, and explain thestructure of the Windows Registry and how Registry treestructure is parsed from the hive file in an offline mode insection 3. In section 4 we will briefly discuss the footprintsleft on the system and Registry when a USB device isconnected. We finally show how to proceed in a caseinvolving data transfer from system to USB throughRegistry analysis.II. RELATED WORKDuring the past years, it has turn out to be absolutelylucid that Registry in Windows systems contains ampleamount of information for the use of incident respondersand forensic analysts alike. A great deal of information onhow to interpret various Registry data and settings havebeen provided by Carvey [1], Wong [13] and Farmer [4].As illustrated by Carvey, “Registry data consists of a wealthof information that the investigator can make use of tomake up his case”. Kim, et. al. [6] has listed some registrykeys that an investigator must check during aninvestigation. Chang, et. al. [2] has shown how to proceedin an investigation involving Windows systems, and listedsome of the registry areas that need attention in thepreliminary stages. Additional areas vital from a forensicviewpoint apart from Registry in Windows systems havebeen noted by Dashora, et. al. [3], such as event logs, RAM,Pagefile, slack space, etc.Manchanda, et. al. [7] have illustrated how the last-writetimes associated with every Registry key can be useful ingenerating a forensic timeline of the events that hasoccurred in a system.Documentation regarding the Registry internal structurehas been provided in detail by Russinovich [10]. Morgan[8] provided a comprehensive description of the Registry’sinternal data structures and format that is helpful ingenerating the registry tree from hive files.4427
Tanushree Roy et al, / (IJCSIT) International Journal of Computer Science and Information Technologies, Vol. 3 (3) , 2012, 4427- 4433III. METHODOLOGYA. The Windows RegistryWindows Registry is the “central hierarchical database”used to store information that is necessary to configure thesystem for one or more users, applications, and hardwaredevices [11]. It is the Heart and soul of Windows operatingsystem; every application that runs on Microsoft’soperating systems do absolutely nothing without consultingthe Registry first. When we double-click over a file,Windows consults the Registry to figure out what to dowith that file. When a new device is connected to thesystem, Windows assigns resources to the device based oninformation in the Registry and then stores the device’sconfiguration in the Registry.1) Registry Structure Overview: The Registry isorganized in a tree like structure which is equivalent to thefilesystem. For e.g., the keys and subkeys found within thefive main hives are comparable to folders and subfolders ofWindows filesystem, and a key’s value is similar to a fileinside a folder, a value’s name is analogous to a filename,its type resembles a file extension, and its data is like to theactual contents of a file. The registry structure is illustratedin figure 3.1.The registry value contains 3 parts; value name, valuetype and value data; as illustrated in figure 3.2.a Registry tree that has a key serving as the root or initialpoint of the tree. Subkeys and their values are below theroot. Table 1 below lists the Registry hives and their ondisk location for a Windows XP system. The path names ofall hives excluding for user profiles are coded into theconfiguration manager.Registry TEMHKLM\HARDWAREHKU\.DefaultHKU\ SID oflocal serviceaccount HKU\ SID ofnetwork serviceaccount HKU\ SID ofusername HKU\ SID ofusername ClassesHive file ile hive%SystemRoot%\System32\Config\Default\Documents Documents t\Documents a\Microsoft\Windows\UsrClass.datTable 1: Registry hive file locations2) Registry hive structure: A hive is logically dividedinto allocation units called blocks as disk is divided intoclusters. Typically a block is of size 4096 bytes (4 KB). Theinitial block of a hive is the base block. Remaining blockscontains bins, which contain BLOCKFigure 3.1: Registry Logical Structure as displayed by the Registry igure 3.3: Simplified illustration of Registry hive internal structure.Figure 3.2: Value FieldsPhysically, the Registry isn’t simply one large file butrather a set of discrete files called hives. Each hive containsThe base block contains global information about thehive, together with a signature—regf, that classifies the fileas a hive, sequence numbers, time-stamp that indicates thelast time a write operation commenced on the hive, the hiveformat version number, checksum value, and the hive file’sinternal file name (for eg., M).4428
Tanushree Roy et al, / (IJCSIT) International Journal of Computer Science and Information Technologies, Vol. 3 (3) , 2012, 4427- Contents“regf” signaturetimestamproot key offsetoffset to last hbin in the hivefile name (Unicode)*(size in bytes)Table 2: Important fields of base blockWindows organizes the Registry data that a hive storesin containers called cells. A cell can contain a key, a list ofsubkeys, a value, a security descriptor, or a list of keyvalues. A field at the beginning of a cell’s data describes thedata’s type. Bins also have headers that have a signature,hbin, a field that contains offset to the hive file of the binand the bin’s size.Cell TypesKey cellValue cellSecurity Descriptor cellnkvkskSub-key list celllf / lh / ri / liValue-list cellData cell––Signature0x6B6E0x6B760x6B730x666C / 0x686C /0x6792 / 0x696CN/A (No header)N/A (No header)Table 3: Cell types and their signatures3) Traversing the Registry Hive: The base block pointsto the first hbin structure that in turn comprise the offset tothe root key of the registry hive. All key/subkey in theregistry hive is having a signature NK. Key cell include anoffset to the value-list member containing the valuespresent under the keys and an offset to the related sub-keystructure that point to an LH, an LF or an RI cell.The LH or LF entry includes a member that holds a listof offsets to all the other sub-keys of the key. The value-listcontains pointers to value keys. The value entry containsinformation related to the value present under a key and theassociated data. If the data size contains a 1 in its MSB(0x80), the key contains inline data, i.e. – the offset to thedata is the actual data rather than an offset to the data. Incase of non-inline data, the offset to the data is the offset ofthe data cell. In case the first two bytes of the data cellcontain the signature ‘db’ (0x6264), it is a data cell withnon-contiguous data. This may be because the size of thedata is very large, and cannot be accommodated in a singlebin. The data is then spread over a number of bins. The nexttwo bytes then tell us how many bins the data is spreadover. Following these two bytes is a list of offsets to thedata cells that make up this data entry. The data from allthese cells can be concatenated to form the actual data ofthat particular value.B. Tools Used1) Collection of Registry hive files: Registry files areopened by the Kernel in restricted mode which means thatthey cannot be copied while the system is in use, except forthe User Registry Files (NTUSER.DAT) that are notcurrently loaded.A method was needed for extracting example RegistryFiles for research use. The chosen method was:i. Hive files are collected from several machines bybooting them from a Linux disc (as hive files arelocked while the Windows operating system isrunning).ii.ERUNT tool also may be used to obtain hive filesfrom a live system, without shutting-down thesystem.It is noted that, a collection method like listed above cancapture only the stable hives present in the hard-disk, andnot the volatile hives (the in-memory version of disk hives).2) Registry Examination: Analysis of the registry hive filescan be done manually using WinHex [12] or by parsing thehive using an offline parser. For the purpose of examinationan offline registry parser r parser.pl was developed inPerl based upon the available knowledge about the Registrystructure. The code was further modified to generatespecific keys related to USB devices, as explained in thefollowing section. Another utility regkey time.pl wasdeveloped, that listed the keys in a descending order of theirlast-write times.C. Footprints left by a USB Device1) setupapi.log: Since almost all devices now-a-days,are of the type “plug-and-play”, containing their associateddriver files written on the device firmware, the system caninstall them directly, ruling out need for a separateinstallation disk. Whenever such Plug-and-Play USBdevice is connected to a system, Plug-and-Play (PnP)manager receives this event and queries the devicedescription in its firmware, such as manufacturer, serial no,etc. Upon receiving the information, the PnP managerlocates device drivers and a set of Registry keys are created,as described below. Above events are recorded \setupappi.log) when the device getsconnected to the system for the first time.The device detail is not a part of memory area and thus,is not available when we make its clone.2) Registry Keys created: After the device is identified, aset of registry keys gets created as follows:i.HKEY LOCAL MACHINE\SYSTEM\ControlSet00x\Enum\USBSTOR\ device class \ deviceunique id \ii. HKEY LOCAL \{ disk devicesGUID }\iii. device class#device unique id#{disk devicesGUID} \iv. HKEY LOCAL \{ volume devices GUID }\v. STORAGE RemovableMedia#ParentId Prefix#{volume devices GUID} \vi. HKEY LOCAL eMedia\ ParentID Prefix \These keys contain details about the device id, driverdescription, manufacturer, friendly name, parented prefix,etc. When we connect the same USB to the system again, asub-key named control is created under the above keys. Asa result the time-stamp of these keys reflect the last time theUSB was connected to the system.3) Drive letter to which the device gets mounted: USBdevice when connected to the system gets assigned to adrive letter (G, H, etc.), which can be identified through thefollowingkey:HKEY LOCAL MACHINE\SYSTEM\MountedDevices4429
Tanushree Roy et al, / (IJCSIT) International Journal of Computer Science and Information Technologies, Vol. 3 (3) , 2012, 4427- 4433This key contains a value starting with \?\Volume\that contains binary data having ParentId Prefix in the form STORAGE RemovableMedia#ParentId Prefix#{volume devices GUID} . This data is also presentin the value \DosDevices\ drive letter , if thisUSB device was the last device mapped to that drive letter.4) Finding the user profile through which USB devicewas connected: The value present in the key\MountedDevices starting with \?\Volume\{ }occurs only once more in the ntuser.dat hive of the userprofile in which the USB device was connected. Using thisvalue, we can find out the user profile through which theUSB device was connected.5) Time the drive was last connected to the system: Thefirst time USB device was connected to a system is foundfrom the setupapi.log file and the corresponding registryentries. To associate this time with the actual time, Version\Time Zones, present in theSoftware hive is checked.6) To track if file opened or copied through explorer: Ifany file is opened through the explorer by double click onthe file name, an entry is created in the Registry lorer\RecentDocs\If file opened using open file menu or saved using saveas file menu in any application program, it is noted in nSaveMRUThese entries are present in the ntuser.dat registry hiveof the user profile identified in 4) above.7) File copy to USB through other modes: Analysis ofthe file MAC times: If file is transferred to USB using thecopy, cut or send-to context menu option, no registry entrygets created; and one has to examine both the system andUSB device file system to track the file copy.Whenever a file is accessed (i.e., copy, move, open oredit), their MAC (modified, accessed, created) times stAccessUpdate present in theSystem hive under the key ControlSet00x\Control\FileSystem\ is enabled, then MAC timesare not updated. By default this value is not present inWindows XP systems. The MAC times of the filessuspected of being copied is checked.8) Analysis of the USB device: Once we have identifiedthe user profile through which the USB device wasconnected, and it is established that files have been copiedto the USB, case can be established against that person, andhis USB device is confiscated for analysis. If the copiedfiles are present in the USB device then, their md5 hashvalues are compared to the values of original files. And iffiles are not present, then unallocated space is analyzed andfiles are recovered, if not overwritten till now.For tracking data transfer from system to USB devicesevaluating the performance we connected some USBdevices to a system for the first time and copied a few filesfrom system to USB using different modes. To be able tothe compare the changes, we took a snapshot of MACtimes, before and after files were copied from the system.Table 4 below shows the operations performed on the filesand the files’ original MAC times. Thereafter, the Registryfiles of the system were extracted and analyzed usingr parse.pl. The analysis process is discussed step bystep in section 4 for an USB device.DateDateOperationModified Date Created AccessedPerformedFeather2/28/20062/28/2006 12/13/2011Copy PasteTexture.bmp2:00 AM2:00 AM9:21 PMGone2/28/20062/28/2006 12/13/2011Send-toFishing.bmp2:00 AM2:00 AM9:21 PMOptionGreen2/28/20062/28/2006 12/13/2011MoveStone.bmp2:00 AM2:00 AM9:21 PM(Cut Paste)ie7beta2.log11/21/2011 11/21/2011 11/21/2011Rename4:47 PM4:43 PM4:47 PMii6.log11/21/2011 4/25/2006 11/21/2011Edit5:54 PM6:00 PM5:54 PMie7.log11/21/2011 11/21/2011 11/21/2011Open5:54 PM5:52 PM5:54 PM (double click)Prairie2/28/20062/28/2006 12/13/2011 Save throughWind.bmp2:00 AM2:00 AM9:21 PMSave-AsRiver2/28/20062/28/2006 12/13/2011 Open throughSumida.bmp2:00 AM2:00 AM9:21 PMexplorerTable 4: Files’ original MAC times and operations performed on themFile nameFor the sake of simplicity, this work we have assumedthat the system fingerprints were not removed deliberatelyby the user, and are present within the registry and otherlocations.IV. RESULTS AND DISCUSSIONSThe result of the systematic analysis for one USB deviceis follows:A. setupapi.log fileThe setupapi.log file is analyzed to find the entriesrelated to driver installations for the USB device whenconnected to the system for the first time. The figure 4.1below shows the entries created for the USB device inquestion. The device unique instance-id, ParentId prefixand the time-stamp values are highlighted.Figure 4.1 (a): Entries of setupapi.log for a “SanDisk Cruzer Blade” USBdrive with 4GB capacity was connected to the system for the first time.4430
Tanushree Roy et al, / (IJCSIT) International Journal of Computer Science and Information Technologies, Vol. 3 (3) , 2012, 4427- 4433C. Finding the drive the USB was mountedThe above USB was mapped to E: drive and we got thevalues as below.Figure 4.1 (b): Entries of setupapi.log for a “SanDisk Cruzer Blade” USBdrive with 4GB capacity was connected to the system for the first timeB. Registry entries in SYSTEM and ntuser.dat hiveThe registry keys retrieved for the device from theSystem hive using our parser is shown in figure 4.2.D. Finding the user profile through which USB device 693df12} was found in the ntuser.dat hive of theuser 1. This means the system user 1 must have connectedthe USB to the system.E. Time the drive was last connected to the systemThe time USB device was first connected to a systemcan be found from the setupapi.log file and thecorresponding entries in the Registry shows the last timethe USB device was connected to the system. To associatethis time with the actual time, the Registry e Zones, present in the Softwarehive is checked.F. Find if files were opened or copied to USBWe look for entries corresponding to the USB driveletter in the ntuser.dat hive of the identified user (if notdeleted explicitly) under the following keys (see figure 32\LastVisitedMRUFigure 4.2 (a): Registry values for the USB device in question.Figure 4.2 (b): Registry values for the USB device in question.Figure 4.3: An excerpt of the result showing values of RecentDocsRegistry key of the identified user.4431
Tanushree Roy et al, / (IJCSIT) International Journal of Computer Science and Information Technologies, Vol. 3 (3) , 2012, 4427- 4433H. Analysis of the confiscated USB deviceUpon knowing the user profile through which the USBdevice was connected, a case may be build up against theowner of that profile. After confiscating the USB devicefrom that person, a thorough analysis of device’s filesystem is done to find the copied files. We found the files inthe USB device and their MAC times were compared to theoriginal files.OperationPerformedCopy PasteSend-toOptionMove (Cut Paste)RenameEditFigure 4.4: An excerpt of the result showing values of OpenSaveMRURegistry key of the identified user.From the figure 4.4, it is evident that the files PrairieWind.bmp was opened from the system (C:\) then saved toUSB (E:\) while River Sumida.bmp was opened only. Thisfact is derived from the entry in OpenSaveMRU. Also thefiles ie7.log and ii6.log was accessed through explorer,found from entry in RecentDocs (figure 4.3). However, thefiles that were copied or moved to USB using the contextmenu option, has no entry is made in the Registry.G. Analysis of the file MAC timesWhen we access (i.e., copy, move, open or edit) a file,their MAC (modified, accessed, created) times getsupdated. The MAC times of the files suspected of beingcopied is checked and compared to the time obtainedthrough Registry analysis. It was observed from MACtimes of files in the system that, access times are changedfor the files in question and is same as the time the USBdevice was connected. Hence, it can be concluded that thesefiles were copied.OperationPerformedFeatherCopy een(CutStone.bmp Paste)File Sumida.bmpRenameEditOpen(double teAccessed5/4/201211:50 AM5/4/201211:55 AMFile Not nge5/4/201211:55 AM5/4/201211:56 AM5/4/201211:55 AMNochangeNochange5/4/201211:59 AMNochangeNochange5/4/201212:01 AMTable 5: Change in MAC times of files present in the ughexplorerDateModifiedSame asoldSame asoldSame asoldSame asoldTimeModifiedDateCreatedNew, timeof copyNew, timeof copySame asOldNew, timeof copyNew, timeof copySame asoldNew, timeof copyNew, timeof saveNew, timeof saveSame asoldNew, timeof copyDate AccessedSame as dateCreatedSame as dateCreatedNew, time ofmoveSame as dateCreatedSame as date timeModifiedAccess TimeNew, time ofsaveSame as dateCreatedTable 6: Comparison of MAC times of files found in USB with theoriginal files present in the system.Hence, from setupapi.log file, we found the time theUSB device (Unique ID- 200402033009D8D25377&0,ParentID Prefix- 7&251e0f1a&0) was connected to thesystem. The last write times of the corresponding registrykeys matched this time. This device was mapped to E: driveand has been connected to the system by User 1. The entriesin RecentDocs and OpenSaveMRU key establish the factthat those files were saved E: drive. Finally by analyzingthe MAC times of files, details of files copied is found.The table 7 below summarizes the steps followed ininvestigating this case and table 8 lists how to track thespecific file transfers.Sl.Action PerformedNo.1 Capture registry files from the systemFind the time the USB device was connected2to the systemCheck the first time the USB device was3connectedFind the drive letter to which the device was4 mounted, match with the time obtained instep 2 and step 3Find through which user profile the USB5drive was connected to the systemFind if files were opened or saved through6 explorer, match path with the drive letterobtained in step 4Find if the valueNtfsDisableLastAccessUpdate7is enabled; MAC time of files are checked ifvalue is set to 1Subject ofAnalysis–registry hiveSYSTEMSetupapi.logregistry hiveSYSTEMregistry hiventuser.datregistry hiventuser.datregistry hiveSYSTEM4432
Tanushree Roy et al, / (IJCSIT) International Journal of Computer Science and Information Technologies, Vol. 3 (3) , 2012, 4427- 4433Sl.No.8910111213Subject ofAnalysisMAC time ofFind if files were copied by other modesfiles presentin the systemUnallocatedCheck for deleted files in the systemspace of thesystemOnce it is established that files were copied, case is build upagainst the person using that identified user profile and hisUSB device is confiscated for analysisCheck for files in USB device, if foundMAC time ofcompare with original filefiles in USBUnallocatedIf files not found in the USB device, look inspace of USBdeleted spacedeviceEstablish file copy by comparing the hash values of originalfiles present in the system and files obtained from the USBAction PerformedTable 7: Steps followed in examining file copy to an USB.OperationPerformedTracking Method / Footprint Present InCopy PasteSend-to OptionMove (Cut Paste)RenameEditOpen(doubleclick)Save throughSave-AsOpen throughexplorerFile System analysis of system and USB,MAC times comparedFile System analysis of system and USB,MAC times comparedFile System analysis of system and USB,MAC times comparedFile System analysis of system and USB,MAC times comparedRecentDocs Registry keyRecentDocs Registry keyRecentDocs Registry keyOpenSaveMRU Registry keyTable 8: Tracking specific file 3]REFERENCESCarvey, H., The Windows registry as a forensic resource, DigitalInvestigation, vol. 2(3), pp. 201–205, Elsevier 2005.Chang, K., Kim, G., Kim, K. and Kim, W., Initial Case AnalysisUsing Windows Registry in Computer Forensics, Future GenerationCommunication and Networking, Volume 1, 6-8 Dec. 2007Page(s):564 – 569. [Online] DOI: 10.1109/FGCN.2007.151[Accessed 02/11/2011].Dashora, K., Tomar, D. S. and Rana, J. L., A Practical Approach forEvidence Gathering in Windows Environment, International Journalof Computer Applications, Volume 5(10), August 2010.Farmer, D. J., A Forensic Analysis of Windows Registry, Availableonline from yquick-reference.pdf, 2007.Farmer, D. J., A Windows Registry Quick Reference: for ners.com/forensics/contents/A Forensic Examination of the Windows Registry.pdf, 2009.Kim, Y. and Hong, D., Windows Registry and Hiding Suspects’Secret in Registry, In the Proceedings of the 2008 InternationalConference on Information Security and Assurance, IEEE 2008.Manchanda, M., Manchanda, V., Gupta, V., Bisht, M., ForensicInvestigation of Window Registry, International Transactions inApplied Sciences, Volume 2(1), pp. 11-21, January 2010.Morgan, T., D., The Windows NT Registry File Format df, June 2009.Norton Cyber Crime report, 2011, Symantec Corporation, /us/home homeoffice/html/cybercrimereport/, [accessed April 2012].Russinovich, M. E. and Solomon, D. A., Management Mechanismsin Windows Internals Covering Windows Server 2008 and WindowsVista, (Fifth Edition), Microsoft Press, 2009.Windows Registry information for advanced users, .microsoft.com/kb/256986, [accessed April 2012].WinHex, , WinHex: Computer Forensics & Data Recovery Software,Hex Editor & Disk Editor, Available online from http://www.xways.net/winhex/Wong, L. W., Forensic Analysis of the Windows Registry. icfocus.com/index.php?name Content&pid 73&page 1, 2007.V. CONCLUSION AND FUTURE SCOPEForensic investigations play a significant role in today'sworking and legal environments, and thus it should becarefully considered. The evidence provided in the registryis the most significant source of any investigation. Theactions performed on the computer gives the examiner aninsight of the system. Thus, a careful analysis of theWindows system Registry from a forensic point of view isthe need of the hour and a hot area of research in the presentscenario.This paper has gathered and verified the existingknowledge about the registry hive files. We also attemptedto exhibit the importance of registry analysis bydemonstrating how it can help an investigator to progress ina case of tracking data transfer from
generating a forensic timeline of the events that has occurred in a system. Documentation regarding the Registry internal structure has been provided in detail by Russinovich [10]. . Tanushree Roy et al, / (IJCSIT) International Journal of Computer Science and Information Technologies, Vol. 3 (3) , 2012, 4427- 4433 4427. III. METHODOLOGY A .
