Showing posts with label techniques. Show all posts
Showing posts with label techniques. Show all posts
Friday, September 29, 2017
Test Estimation Techniques
Test Estimation Techniques
Estimation very important thing in project, estimation nothing but estimating the effort that is require to test particular thing, estimation is more of a time required to test the software application. There are certain level of formulas and techniques which help to estimate the software effort required to test the particular piece of software.
As we know time is very important in IT industries, as we do each and every thing by define the certain time span. Sometime estimation can also go wrong, there are some unavoidable circumstances which can cause the delay. Means that even you do estimation but you cannot sure that everything will go as you estimate.
Let�s move ahead, I will tell you how you can estimate the time and effort required to evaluate any software. Basically estimation is mostly done by the QA manager some time it is also done by QA Team, but estimation is not done Junior QA. You might thing why not junior QA? So the reason is to estimate testing effort required, QA manager use his past experience and as based on those past experience QA manager estimate the time required for the testing. Estimation all comes from the past experience on similar project and resources available for testing.
Let�s start, suppose there is a software project and we have to estimate the testing effort for that particular project. Let consider we are developing the software by using waterfall model. And client want this project in 12 month. So there are 6 phases in waterfall model. And testing phase is 4th so if we have 12 month and 6 phase then each phase will have 2 months,
So we would get 2 month for testing. Now we have to estimate and divide these two month to testing activities. We know in testing there are three main activity which are Test Planning, Test Design and Test case executions. So will we divide these two month in these three activity so each activity will get the 1/3 month time for each. Means two month means 60 day by excluding Saturday Sunday we would get 40 days. Means for each activity we would get approximately 13 days.
There equation as of now is 13 day for test planning, 13 day for test design and 13 days for test case execution. Not only the time but we have to consider the resources available for test. Let�s say we have 2 resources. Consider each resource will work for 8 hour a day means 2 resources X 13 day X 8 hours = so we will get 208 hour for each activity. So this is how we can get the hour for each activity.
But we know there many unexpected circumstances which can occurs, once of them is someone is got the better opportunity and he is leaving the project. So this may happens now a days peoples are switching the job very frequently. So QA manager also need to take care of such a situation, for this situation QA manager should allocate sometime for Knowledge transfer. Let�s say for KT around 8 to 15 % should be allocated. So from 208 +208+208 = 624 hours we need to allocate around 12% time for KT, it also depends on complexity of the project. 12% comes around 60 hour�s means we would get only 564 hours for all testing activity.
There are also sub-activity in testing phase, like in planning, design and execution we have following sub-activities.
- Requirement gathering
- Test Scenario creation
- Test Case Creation
- Test Data collection and Creation
- Review
Above all few sub-activities, again these activities can varies as per the company. We for each phase we get 188 hour (564 hours divided by 3) each. So we need to allocate the time to above mentioned points which is depends on the complexity of the functionality. By having detail knowledge of functionality and its complexity you can allocate the time for above mentioned point. And if possible put some buffer time as we know sometime or many time development activity gets delayed.
I hope you might some idea of how to estimate for testing. Its bit confusion but if you try to understand it then definitely you will get this easily.
Author : MAHENDRA BHISE
download file now
Labels:
estimation,
techniques,
test
Thursday, September 7, 2017
ebook gratuito Programming Linux Anti Reversing Techniques
ebook gratuito Programming Linux Anti Reversing Techniques

Tabla de contenidos
Preface
Why Read This Book?
Topics Not Covered
Prerequisites
Code and Command Output
Chapter 1: Introductions
Introducing �Trouble�
Using CMake
The Code
Compiling
Executing
Accessing the Shell
Chapter 2: Compiler Options
-g
Recovering the Bind Shell Password with Hexdump
Recovering the Bind Shell Password with GDB
The Debugging Information in IDA
Removing the Debugging Information
Case Study: XOR DDOS
-s
SYMTAB vs. DYNSYM
Finding the Bind Shell Password Using .symtab
Case Study: The FILE Symbol
Examing Trouble After -s
-fvisibility
Looking at FUNC symbols
Hiding FUNC symbols
-O
Corrected Block Tiny Encryption Algorithm (XXTEA)
-Os
-O3
-funroll-loops
-static
Resolving Functions at Runtime
ltrace
LD_PRELOAD
Using musl
Chapter 3: File Format Hacks
The Strip Utility
Removing the Section Headers Table
Little Endian or Big Endian?
The Sections Are a Lie
Flipping the Executable Bit
Lying with .init
Hiding the Entry Point
Mixing the Symbols
Chapter 4: Fighting Off String Analysis
Code Reorganization
Stack Strings
XOR Stack String
Function Encryption
Computing the Function�s Size Using a Linker Script
Decryption Logic
Encryption Logic
Creating a Cryptor
Implementing the Cryptor
Analyzing the Cryptor
Chapter 5: Obstructing Code Flow Analysis
Indirect Function Calls
Signals
Early Return
Jump Over an Invalid Byte
Jump! Jump!
Always Follow the Conditional
Overlapping Instructions
Chapter 6: Evading the Debugger
Trace Me
Trapping the Debugger
Becoming Attached
madvise
prctl
Detection Before main()
Computing Function Checksums
Conclusion: All That We Fall For
Notes
Proyecto: https://github.com/antire-book
download file now
Labels:
anti,
ebook,
gratuito,
linux,
programming,
reversing,
techniques
Stealing data with baiting techniques
Stealing data with baiting techniques
In the previous post a general idea of a baiting attack has been described and some techiques how to persuade victims to use malicious application have been explained. In this post concrete implementation and architecture of data stealing system will be desribed in details.
Functionality of malicious thread
When a malicious thread starts it creates a hidden folder called System backup in a Public user directory where several important text files will be generated and used to control the further process. Most users dont know how to reveal hidden files and dont even feel a need to check them, Public users folder is rarely used by anyone and it is not protected by administrator permissions which makes it possible for your program to work without any permission before running it. Also, System backup is a folder name that creates a sense of trust and false security and user is afraid to alter that folder to avoid making unwanted changes on his �system backup�. In this folder three text files will be created. After a program starts, the list of paths of all interesting files is created in a first file named list_of_files.txt. The files that are considered are usually smaller files that contain key data like .xls, .txt, .doc, .docx, .odt, .ppt or .pdf files. You can also try adding photos extensions to it, but then you should put a priority on smaller files to be stolen first. The second files called list_of_backup.txt contains the list of paths of stolen files which is updated as the data is being stolen. After a list of all interesting files (list_of_files.txt) is generated, a program randomly stores all data in a number of zip files with maximum size of 25 MB which is a limitation for email being sent by Gmail service. Those zip files are also stored in System backup folder. From array of fake email accounts a program chooses one to send and one to receive that zip file and after the message is sent that zip is deleted and paths of all files that were previously stored in it are added to list_of_backup.txt. Once the game is first started an intriguing interface asks a player to white his name or nickname to start playing and that name is stored in the third text file called index.txt. Although it cannot be guaranteed that a player writes his real name and that his nickname should give any clue of his identity this information is important to make sorting by victims name possible after files from all sources are obtained. In addition to a victims name a counter that stores the number of zips sent from that computer is also written in index.txt file, which makes it easier to monitor data and create reports send to emails. That counter is increased with every email sent.
Unexpected thread interruption
Stealing files from computer takes time, from ten minutes to several hours, depending on number and type of files that are being stolen. It is therefore highly unlikely that the victim will keep playing your game until the malicious thread is completed. The main purpose of list of paths of stolen files and index.txt is to make it possible to continue an attack once the game is restarted. Firstly, the nickname or name of your victims will be stored from the first session so it will not be asked again and counting of sent zip files will not start from zero. Secondly, the files that have been stolen and have not been moved to different path will not be stolen again. Once the application restarts, a program recreates list_of_files.txt document and lists paths of all files of specified format that are found on computer and not listed in list_of_backup.txt files. Zip files from previous session are deleted and,zip files with max size of 25 MB are randomly created and the thread continues until they are all sent or its interrupted.
Creating reports
While running application whose purpose is to obtain the documents, it is important that they are easily sortable and that they come with easily readable and unambigious report. Of course your emails should contain the attachment with vital data, but subject title and message are also very important. The title and content of message should not tell the real purpose of those emails. The title should be: New report from the computer of <victim> named info_<serial number of zip>.zip and the message should be: You have received a new report from the computer of <victim>. This is a list of scanned files.
Obtaining stolen data
download file now
Labels:
baiting,
data,
stealing,
techniques,
with
Subscribe to:
Posts (Atom)