Monday 28 August 2017

Mobile Forensics

Mobile Forensics Service
What is Mobile Forensics?
Mobile forensics is a scientific methodology used for investigating the evidence of a crime or accident on a suspect's mobile device including smartphones and smart watches. More than 75% of digital evidence is from mobile devices, so mobile forensics is key to successful investigation of crimes in today's digital world.
There are diverse mobile phone manufacturers as well as OS platforms. There is also a huge number of apps and private data on mobile phones. Some of the data may even be encrypted. We have been in the security business since 1996 and are best equipped to handle a mobile forensic investigation.
Our Mobile Forensics service
Data Extraction
Supports all kinds of extraction methods
Memory chip, memory card and USIM
Extraction of selected partion
1GB / min performance
Data Analysis
Parsing and recovery of various file systems
FAT12 / 16 / 31, exFAT, NTFS, EXT3 / 4, HFS+, EFS,YAFS, FSR, XSR
Decrypting encrypted data
Data Viewers - DB, Hex, Plist, Text, Multimedia
Data visualization - social relations, timeline, maps
Screen unlock / bypass / reset - Pattern, PIN, password
Advanced filtering
Mobile Forensic Service
One-stop mobile forensic service
Evidence inspection, extraction, analysis and recovery
Reporting on case investigation
Consultation with professional forensic analyst
Cooperation with government investigation agencies
Mobile Forensic Process 

Monday 21 August 2017

SPM Notes

Click to download

UNIT I
Conventional Software Management : The waterfall model, conventional software Management performance.
Evolution of Software Economics : Software Economics, pragmatic software cost estimation.
UNIT II
Improving Software Economics : Reducing Software product size, improving software processes, improving team effectiveness, improving automation, Achieving required quality, peer inspections.
The old way and the new : The principles of conventional software engineering, principles of modern software management, transitioning to an iterative process.
UNIT III
Life cycle phases : Engineering and production stages, inception, Elaboration, construction, transition phases.
Artifacts of the process : The artifact sets, Management artifacts, Engineering artifacts, programmatic artifacts. Model based software architectures : A Management perspective and technical perspective.
UNIT IV
Work Flows of the process : Software process workflows, Inter trans workflows.Checkpoints of the Process : Major Mile Stones, Minor Milestones, Periodic status assessments. Iterative Process Planning : Work breakdown structures, planning guidelines, cost and schedule estimating, Interaction planning process, Pragmatic planning.
Project Organizations and Responsibilities : Line-of-Business Organizations, Project Organizations, evolution of Organizations.Process Automation : Automation Building Blocks, The Project Environment.
UNIT V
Project Control and Process instrumentation : The server care Metrics, Management indicators, quality indicators, life cycle expectations pragmatic Software Metrics, Metrics automation. Tailoring the Process : Process dicriminants, Example.
Future Software Project Management : Modern Project Profiles Next generation Software economics, modern Process transitions. Case Study : The Command Center Processing and Display System-Replacement(CCPDS-R)
Reference – Software Project Management – SPM notes pdf – SPM pdf notes – SPM Pdf – SPM Notes
1. Software Project Management, Walker Royce, Pearson Education, 1998
2. Software Project Management, Bob Hughes & Mike Cotterell, fourth edition,Tata Mc- Graw Hill,2006
Text books – Software Project Management – SPM notes pdf – SPM pdf notes – SPM Pdf – SPM Notes
1. Applied Software Project Management, Andrew Stellman & Jennifer Greene,O’Reilly, 2006
2. Head First PMP, Jennifer Greene & Andrew Stellman, O’Reilly,2007
3. Software Engineering Project Managent, Richard H. Thayer & Edward Yourdon, second edition, Wiley India, 2004.
4. Agile Project Management, Jim Highsmith, Pearson education, 2004
5. The art of Project management, Scott Berkun, O’Reilly, 2005.
6. Software Project Management in Practice, Pankaj Jalote, Pearson Education,2002.

ONE simulator 


The main intention of this article is to give an introduction to the ONE (Opportunistic Network Environment) simulator to the beginners in Windows platforms. Since the ONE provides very less documentation I hope this article may be useful to the beginners who aim to do their research work in Delay Tolerant Networks. 

To start with download the ONE simulator from the link given below. It is better to download one.1.4.1 or above.
  http://www.netlab.tkk.fi/tutkimus/dtn/theone 
Don’t forget to subscribe to the mailman link in the ONE page. Once you are subscribed you can clear any of your doubts with one of the best research community in DTN. 

Here are the steps below to make yourself familiar with ONE.


Setting Java Path Variable
After downloading you get a folder like one_1.4.1. Copy it to any directory in your system. Now, don’t expect to find a .exe because that is not how it starts. 

The pre-requisite for running ONE is to have a jdk in your system. And for one_1.4.1 it is better to use jdk_1.7.0 or above. After downloading and installing jdk set the java path in Environment variables. If you are not familiar with setting the Java path, the steps are given below:

 Go to My Computer. Right Click on Properties. There you can find the Advanced System Settings ->Environment Variables -> System Variable->Path->Edit->C:\Program Files\Java\jdk1.7.0\bin  
 

 

 


 Don’t forget to separate the paths with a semicolon as shown in the figure.  


Compiling and running ONE 
After setting the Java path now we can compile the ONE. Since ONE is written completely in Java it is necessary to compile all the programs before running the simulator.  


When you got to the downloaded ONE folder you can see a list of folders each containing java files. In the ONE folder along with other folders you will see some .txt files also which are settings files. We’ll come to this later.

 

To compile the ONE simulator, now you have two ways.
1.      Double click on compile.bat OR
2.      Go to command prompt, give the path to the directory where you have saved ONE and type compile.bat and enter.
I suggest you to go with the second method because later when you start developing your own programs in ONE this will give errors on the prompt if you have any.
So once the compile.bat runs all the java files in the ONE get compiled. Before compiling you will only see .java files. Now you will get to see .class files also.

 

To run the ONE simulator also you have two ways.
1.      You can choose the GUI mode OR
2.      You can choose the batch mode.
Batch mode is recommended, but being a beginner it is better to go with GUI because it gives a feeling of what the simulation is.
I’ll explain the GUI first and then the batch mode.
To run the GUI double click on one.bat in your ONE folder or type one.bat in command prompt and enter. This will open up the GUI. Always remember this GUI is a running java code. So where is this code? You can find it in one_1.4.1\core\DTNSim.java. If you are a beginner don’t try to study the code at first. Try to learn more about running the ONE simulator. 

  

There will be a pause/play button on the top left side of GUI. Once you enter this the simulation starts.
On the top left corner you can see the Simulation clock. This is the clock of the simulator. By default it will run for 43200s. But in real it doesn’t take this much time, it is the time that the simulator is simulating according to it’s program.
You can also reduce the magnification by changing values in the field right to that magnification glass you see on top of the GUI.
Let’s have a closer look into the GUI. On the right side we have a section called nodes. You may see a lot of button below it like p0, p1 etc. These are the nodes that are running in the simulation. When you click each button it shows the location of that node on the map.
The map that the ONE simulator uses by default is the Helsinki city map. When you start developing your own programs you can change the maps also. That will be discussed in another article.
In the Event log section of the GUI the connections created, the messages transmitted etc can be seen.
These are some basics on the ONE GUI.
·         To run ONE in the batch mode. Type the following command in the command prompt.
one.bat –b 1

 

The real format of running in batch mode is:
one.bat –b <no:of times to run> <settings file path>
Let us understand what this means:
-b: this indicates that the simulation is to be run in the batch mode.
<no:of times to run>: this is always an integer and tells how many times this simulation is to be run. In our example we have given it as 1 because we need to run it only 1 time. There may be some cases where you may want to run your program for n number of times each with a different random seed. However as a beginner we will keep this value to 1.
<settings file path>: This give the path to the settings file that the simulator is running. By default the ONE uses the default_settings.txt as the settings file. You can see this in the one folder. If you need your own settings file, you can have that also. Give path to that file in this place of the command.

In the batch mode you will not be able to see the node’s location etc.
 
 Report Generation

Now after the ONE finishes the simulation where are the reports generated? Open the reports folder and the MessageStatsReport can be seen. In this report it is possible to see the delivery probability, average latency, overhead ratio etc for the current simulation. 


Settings
Let’s see more about the settings file. As an example we’ll take the default_settings.txt file.

#
# Default settings for the simulation
#
## Scenario settings
Scenario.name = default_scenario
Scenario.simulateConnections = true
Scenario.updateInterval = 0.1
# 43200s == 12h
Scenario.endTime = 43200
 
  The # in the file indicates comments.
·         Scenario.name: The value set for this is the name we give for current simulation. For each simulation this value should be changed, otherwise the reports generated for each simulation will be replaced with the new contents. So if you want separate report files for each simulation change names here.
·         Scenario.simulateConnection: this should be set to true for simulations. In some cases we may use external traces (like those downloaded from CRAWDAD); in such cases the value is set to false.
·         Scenario.updateInterval: This defines the interval in which the update() function in the MessageRouter.java file has to be called. As default it is set to 0.1s.
·         Scenario.endTime: The time for which the scenario is to be simulated. You can keep it to any number of seconds. By default it is kept to 43200s which is 12hrs.

## Interface-specific settings:
# type : which interface class the interface belongs to
# For different types, the sub-parameters are interface-specific
# For SimpleBroadcastInterface, the parameters are:
# transmitSpeed : transmit speed of the interface (bytes per second)
# transmitRange : range of the interface (meters)
# "Bluetooth" interface for all nodes
btInterface.type = SimpleBroadcastInterface
# Transmit speed of 2 Mbps = 250kBps
btInterface.transmitSpeed = 250k
btInterface.transmitRange = 10
# High speed, long range, interface for group 4
highspeedInterface.type = SimpleBroadcastInterface
highspeedInterface.transmitSpeed = 10M
highspeedInterface.transmitRange = 1000
 
We can set interfaces as we like. The set of interfaces supported by ONE are given in interfaces folder.
·         Type: For a scenario we can give specific names to the interfaces we want. For example I want a Bluetooth type interface and a high speed interface. For distinguishing between the two I name the first as btInterface and the other highspeedInterface. The ONE should now understand the difference between two. We keep the type of both interfaces as SimpleBroadcastInterface and vary the parameters for each interface.
For example: we know Bluetooth won’t have a high transmission range and speed and so we keep their values low:

o    btInterface.transmitSpeed = 250k
o   btInterface.transmitRange = 10
      Also we need a high speed and long range interface and so it’s values we keep different.
o   highspeedInterface.transmitSpeed = 10M
o   highspeedInterface.transmitRange = 1000
Note that transmitSpeed and transmitRange are parameters for SimpleBroadcastInterface. For other interfaces there maybe other parameters.
 Thus with the same type of interfaces we can create as many different interfaces with different features.
Scenario.nrofHostGroups: We can define any number of node groups. In the default file they have used 6 node groups. If you need no specific group, keep this value as 1. 
For each group we can have specific settings. These are given in the table above.
# Common settings for all groups

Group.movementModel = ShortestPathMapBasedMovement

Group.router = EpidemicRouter

Group.bufferSize = 5M
Group.waitTime = 0, 120

# All nodes have the bluetooth interface
Group.nrofInterfaces = 1
Group.interface1 = btInterface
Group.speed = 0.5, 1.5
Group.msgTtl = 300
Group.nrofHosts = 40

You may wish to keep some settings common for all groups. That can be specified as above.
  • movementModel: In the above example all groups use ShortestPathMapBasedMovement as the movement model. The movement models that ONE supports can be found in the movements folder. If some group wants to use another movement model simple do:
Group<ID>.movementModel = <The class name of the movement model>
  • router: The routing protocol that all group of nodes use is set as Epidemic routing protocol. The routing protocols already implemented in ONE can be seen in routing folder.
  • bufferSize: The default buffer size for all the nodes is kept as 5M in this example.
  • waitTime: This is the minimum and maximum wait times (seconds) after reaching destination. In our example min is 0s and max is 120s for all groups.
  • nrofInterfaces : The number of interfaces used by groups. In the example all groups use only 1 interface.
  • interface<ID>: the interface ID used. If we want Bluetooth features that we defined first, then Group.interface1 = btInterface.
What if some group uses two interfaces then the two can be specified by:
Group.interface2 = highspeedInterface.
  • speed: this defines the max and min speed in which the nodes must move. In the example it is given as 0.5-1.5m/s. All the values in this field should be in m/s. (0.5-1.5m/s is generally taken as speed for pedestrians)
  • msgTtl: The TTL value of messages for the group. This should be specified in minutes.
  • nrofHosts: This field specifies the number of nodes in each group. It is kept 40 in this example.

# group1 (pedestrians) specific settings

Group1.groupID = p


# group2 specific settings

Group2.groupID = c

# cars can drive only on roads

Group2.okMaps = 1

# 10-50 km/h

Group2.speed = 2.7, 13.9


# another group of pedestrians

Group3.groupID = w


# The Tram groups

Group4.groupID = t

Group4.bufferSize = 50M

Group4.movementModel = MapRouteMovement

Group4.routeFile = data/tram3.wkt

Group4.routeType = 1

Group4.waitTime = 10, 30

Group4.speed = 7, 10

Group4.nrofHosts = 2

Group4.nrofInterfaces = 2

Group4.interface1 = btInterface

Group4.interface2 = highspeedInterface


Group5.groupID = t

Group5.bufferSize = 50M

Group5.movementModel = MapRouteMovement

Group5.routeFile = data/tram4.wkt

Group5.routeType = 2

Group5.waitTime = 10, 30

Group5.speed = 7, 10

Group5.nrofHosts = 2


Group6.groupID = t

Group6.bufferSize = 50M

Group6.movementModel = MapRouteMovement

Group6.routeFile = data/tram10.wkt

Group6.routeType = 2

Group6.waitTime = 10, 30

Group6.speed = 7, 10

Group6.nrofHosts = 2


In this section, each group is defined and group specific settings are kept.
  • Group1.groupID: We can specify an id for each group. In the example for first group it is p. That is why in GUI mode you were able to see p0,p1 etc. Like this we can define an ID for each group.
The first group in the example doesn’t use any specific settings and use the settings that we kept for the whole group.
  • Group2: Group2 has defined a parameter called okMaps. There are many routes that the nodes can follow. The Group 1 did not specify any value means the nodes in that group can follow all the routes in the map. Such type of nodes can be kept as pedestrians as pedestrians tend to take all routes. The group2 uses only route 1 which is roads. To understand the indexes for each route, it is given in default_settings.txt file.

MapBasedMovement.mapFile1 = data/roads.wkt
MapBasedMovement.mapFile2 = data/main_roads.wkt
MapBasedMovement.mapFile3 = data/pedestrian_paths.wkt

MapBasedMovement.mapFile4 = data/shops.wkt
  • Group 2 also wants another value for speed and defines this as Group2.speed = 2.7,3.9
  • Group4, 5 and 6: They use different values for movement models, routes, buffer, number of nodes etc.
## Message creation parameters

# How many event generators

Events.nrof = 1

# Class of the first event generator

Events1.class = MessageEventGenerator

# (following settings are specific for the MessageEventGenerator class)

# Creation interval in seconds (one new message every 25 to 35 seconds)

Events1.interval = 25,35

# Message sizes (500kB - 1MB)

Events1.size = 500k,1M

# range of message source/destination addresses

Events1.hosts = 0,125

# Message ID prefix

Events1.prefix = M

Messages can be generated or can be loaded from an external text file. For beginners we’ll discuss about messages being generated. In some cases we can use different events for message generation. Here only 1 event is used and so we keep Events.nrof =1.
The class of event is MessageEventGenerator, other classes can be seen in input folder in ONE.
The interval in which messages are to be generated has to be defined. It is by default kept as 25-35s.
Events1.interval = 25,35
The message size is to be defined: Events1.size = 500k,1M
Now, the source/destination addresses that are valid to where the messages go is to be defined: Events1.hosts = 0,125
In this example we have a total of 126 nodes (40(p group)+(40 c group) +(40 w group)+ (6 from three t groups)), so we keep the values as 0,125. If we were having 50 nodes then it will 0,49 and so on.

In some cases some routing protocols have their own specific settings. For example:
SprayAndWaitRouter.nrofCopies = 6
# Reports - all report names have to be valid report classes
# how many reports to load
Report.nrofReports = 1
# length of the warm up period (simulated seconds)
Report.warmup = 0

# default directory of reports (can be overridden per Report with output setting)
Report.reportDir = reports/
# Report classes to load

Report.report1 = MessageStatsReport

We can specify the number of reports we want for each simulation. The reports available in ONE are given in the report folder. The MessageStatsReport.java can be seen in this folder. This report contains the delivery rate, average latency etc.
What if we need two reports, say MessageDeliveryReport. Then the settings has to be defined as below:
Report.nrofReports = 2
Report.report1 = MessageStatsReport
Report.report2 = MessageDeliveryReport

We have seen that in batch mode we can run the simulation for any number of times. We can change the settings for each parameter for each run by using a semicolon in the default_settings.txt. For example:
Scenario.name = [simulation1;simulation2;simulation3]
Group.router = [EpidemicRouter;ProphetRouter;SprayAndWaitRouter]

After we change the two parameters like this and then run from cmd: one.bat –b 3

ONE will run for three times and for each time it will take different values separated using semicolon.

Thus we will get three reports in the reports folder:
simulation1_MessageStatsReport.txt (Ran with Epidemic routing)
simulation2_MessageStatsReport.txt (Ran with Prophet routing)
simulation3_MessageStatsReport.txt (Ran with Spray and Wait routing)

How to use a separate settings file?

In some cases we may wish to use a separate settings file. We can create another file and give the path of the file in the command prompt. The ONE uses all the values used in this file. Those values missing in this file will be taken from the default_settings.txt file.

Let us create a file called test.txt. This file uses only one group of nodes.
Scenario.name = test

Scenario.nrofHostGroups = 1
Group.nrofHosts = 100
Events1.hosts = 0,99
Now we run the ONE as below:
One.bat –b 1 test.txt
The parameters that are not defined in the test.txt will be taken from the default_settings.txt.