Scribd
Upload
33 views14 pages

Testing Meltdown Exploit Methodology

This document provides guidance on testing an existing exploit through static and dynamic testing methods. It recommends developing a test plan and following a testing methodology. For static testing, it advises reading the code to understand libraries, variables, methods, and comments. Dynamic testing involves debugging the exploit by running it end-to-end, examining registers, variables, memory, and disassembly to see how it works. Screenshots and diagrams can demonstrate the testing process. Meltdown is used as an example exploit to test.

Uploaded by

zeeshan.a.junaidi
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
33 views14 pages

Testing Meltdown Exploit Methodology

This document provides guidance on testing an existing exploit through static and dynamic testing methods. It recommends developing a test plan and following a testing methodology. For static testing, it advises reading the code to understand libraries, variables, methods, and comments. Dynamic testing involves debugging the exploit by running it end-to-end, examining registers, variables, memory, and disassembly to see how it works. Screenshots and diagrams can demonstrate the testing process. Meltdown is used as an example exploit to test.

Uploaded by

zeeshan.a.junaidi
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd

PUBLIC / CYHOEDDUS

IY4S733 - Advanced Security Concepts

Week 3 - Testing an Existing Exploit (Friday –


Part 2)

Josh Richards BSc (Hons) MSc MBCS


Faculty of Computing, Engineering and Science
University of South Wales
[Link]@[Link]

© University of South Wales


PUBLIC / CYHOEDDUS

Testing an existing exploit: A Meltdown Example


1. Testing Methodology

• Consider the exploit as the ‘Test Item’


• Use a Test Plan
• Use a Test Methodology
• In general your technical report should have a Methodology. This is the
process that you will follow to carry out your testing.
• You can create your own methodology or you can research and use
another methodology. For example using an IEEE International Standard
for Software Testing is a valid methodology to follow.
• You don’t have to use a ‘full’ testing standard. Use only relevant sections
for your scope.
PUBLIC / CYHOEDDUS

Test Plan Example


Having a test plan can lead you into a defined and orderly test procedure and can keep you in
scope of your requirement. That is what are you going to test and why?

Example Test Plan Table:


Table 1 - Meltdown Test Plan
PUBLIC / CYHOEDDUS

Demonstrating your Practical Testing in Your Report


• Demonstrate your practical testing with screenshots.

Figure 16 - Meltdown Kernel Memory Extraction

1. You will need to evidence that you have run the exploit on your
test machine with screenshots as above.
2. Provide an analysis of every screenshot you use to demonstrate
your understanding of what the test did. Example: You could
have a ‘Meltdown Run-Through’ title with a discussion directly
after your screenshot.
PUBLIC / CYHOEDDUS

Static Testing: Reading and understanding the code


syntax.
Libraries:
What Libraries are included in the exploit? Look them up. The libraries can sometimes
give an indication of what functions will be required in the code.
Variables:
What variables are declared at the start of the program? Understand the data type and
how they are used in the code.
Methods:
The methods are the testable items or the ‘Test Conditions’. What does the method do?
Start off with a high level understanding then work into the lower level code. Debugging
will reveal the ‘actions’ of the method during your dynamic testing, its inputs and
outputs.
PUBLIC / CYHOEDDUS

Static Testing: Reading and understanding the code


syntax.(cont..)

‘Main’ Method:
This is always the start point of any running program. All other methods declared
outside of the main method will at some point be called within ‘main’.
In line Comments
These are useful! Coders (the nice ones..) insert comments to help other developers or
testers understand their code. Understanding the comments used can help in
understanding what the code is doing.
PUBLIC / CYHOEDDUS

Static Testing: Using a Diagrams to explain your


analysis.
Example 1: High Level Overview of Meltdown POC
PUBLIC / CYHOEDDUS

Static Testing: Using Diagrams to explain your


analysis.

Example 2: Meltdown leak_bit Static Analysis


PUBLIC / CYHOEDDUS

Static Testing: Using Diagrams to explain your


analysis.
Example 3: Meltdown leak_bit function Attack Tree
PUBLIC / CYHOEDDUS

Dynamic Testing – Debugging Structure Based

Run Through
Run the exploit from start to finish. Does it work as intended? Verify your result against
another result from an online source. (there are plenty online for Spectre).
Debug Methods
Debugging methods should reveal how they work. Looking at registers, variables and
memory can reveal the critical components.
Look at the disassembly ( the Assembly code). This will gain some extra marks if your
analysis shows some understanding at this lower level.
Don’t debug everything! Remember the aim of your report is to identify the critical
components that demonstrate HOW the exploit exposes the vulnerability.
PUBLIC / CYHOEDDUS

Dynamic Testing: Visual Studio


PUBLIC / CYHOEDDUS

Dynamic Testing: Visual Studio


PUBLIC / CYHOEDDUS

Dynamic Testing: Visual Studio

Disassembly shows the corresponding assembly


language currently being executed

The Source code.

Memory Addresses and data

Use ‘Watch’ to monitor values of


a variable.
PUBLIC / CYHOEDDUS

Any Questions?

© University of South Wales

You might also like