Thursday, January 30, 2014
OMFW 2013 Slides
In case you missed it, I put up my slides for my OMFW 2013 talk "Every Step You Take: Profiling the System". You can find them here on google docs. Some of the animations may not render properly, even if played, but you get the idea. If you want to see the cyboxer plugin, send me an email (jamie.levy {at} gmail . com).
Tuesday, July 16, 2013
Volatility News
Things have been busy lately, but I want to let you know about some important items that are coming up quickly:
Andrew Case and I will teach our course in Digital Forensics and Incident Response again this summer at Black Hat Vegas. This course will cover enough material to take someone from knowing practically nothing about digital forensics (disk and memory) to a point where s/he can comfortably conduct his/her own investigations. There is limited time to sign up, so reserve your seat while you can!
You can hear Andrew talk about Digital Forensics and Incident Response on the Healthy Paranoia podcast from July 7th, 2013.
The 1st Annual Volatility Plugin Contest deadline is quickly approaching! Don't miss this opportunity to win over $2000 in cash and prizes and contribute to the top memory forensics framework by writing a plugin for the Volatility Framework and submitting it to volcon2013@memoryanalysis.net by August 1st, 2013.
We will have our 4th public offering of our official Windows Malware and Memory Forensics training in the Netherlands September 9-13, 2013. This will be our only offering outside the US for this year. Past offerings of our course have been well received and were recently described as the "... perfect combination of incident response, malware analysis and Windows internals." Don't miss out on your chance to take this course and learn not only how to become a Volatility superuser, but how to apply cutting edge memory and malware analysis methodologies against your worst adversary.
The Open Memory Forensics Workshop (OMFW) call for papers has been announced. If you want to give a talk on memory forensics related topics, please get your submission in by September 1st, 2013. OMFW is a half-day workshop that will be held one day prior to the Open Source Digital Forensics Conference in Chantilly, VA. This workshop is fast-paced, to the point, highly technical and intended to raise the bar for analysts who realize the importance of memory forensics when faced with a highly skilled adversary. Not only will you learn a lot and get to meet all the movers and shakers in the space, but your $50 registration fee is entirely donated to charity! Last year all proceeds went to the National Center for Missing and Exploited Children. So don't delay: there really is limited seating and it does go quickly. Make sure to register your seat now!
The Volatility team will be at the Open Source Digital Forensics Conference discussing The State of Volatility. Come by and see us there :-)
We will have our 5th public offering of the official Windows Malware and Memory Forensics training in Reston, VA November 11-15th, 2013. If you missed the last offering in June, this is your chance to take this course and learn from the developers themselves. As I've stated before, this class includes real-world scenarios that are reinforced with hands-on labs. We cover more than "just one tool" as some detractors like to say. We cover methodologies that will actually help you where some tools fail. You will have a deep enough understanding to investigate even the most skilled adversaries who know how to break common tools in order to hide. Don't be fooled and don't be left behind. Accept no imitations and make sure to take this class.
All students who take the official Volatility training receive a certificate of completion, with CPE credits that can be used for certification renewal. In addition to this, we are constantly updating the course with new material and past students are given updated materials for FREE. What more can you ask for? If you are interested in Volatility training, drop us a line at voltraining [[ at ]] memoryanalysis.net
If you want to see co-trainers MHL and Andrew Case (attrc) in action, I managed to find a couple of videos of their previous talks on youtube:
July 27-30th, 2013: Blackhat Vegas
Andrew Case and I will teach our course in Digital Forensics and Incident Response again this summer at Black Hat Vegas. This course will cover enough material to take someone from knowing practically nothing about digital forensics (disk and memory) to a point where s/he can comfortably conduct his/her own investigations. There is limited time to sign up, so reserve your seat while you can!
You can hear Andrew talk about Digital Forensics and Incident Response on the Healthy Paranoia podcast from July 7th, 2013.
August 1st, 2013: Volatility Plugin Contest
The 1st Annual Volatility Plugin Contest deadline is quickly approaching! Don't miss this opportunity to win over $2000 in cash and prizes and contribute to the top memory forensics framework by writing a plugin for the Volatility Framework and submitting it to volcon2013@memoryanalysis.net by August 1st, 2013.
September 9-13th, 2013: Volatility Training in the Netherlands
We will have our 4th public offering of our official Windows Malware and Memory Forensics training in the Netherlands September 9-13, 2013. This will be our only offering outside the US for this year. Past offerings of our course have been well received and were recently described as the "... perfect combination of incident response, malware analysis and Windows internals." Don't miss out on your chance to take this course and learn not only how to become a Volatility superuser, but how to apply cutting edge memory and malware analysis methodologies against your worst adversary.
November 4th, 2013: Open Memory Forensics Workshop (OMFW)
The Open Memory Forensics Workshop (OMFW) call for papers has been announced. If you want to give a talk on memory forensics related topics, please get your submission in by September 1st, 2013. OMFW is a half-day workshop that will be held one day prior to the Open Source Digital Forensics Conference in Chantilly, VA. This workshop is fast-paced, to the point, highly technical and intended to raise the bar for analysts who realize the importance of memory forensics when faced with a highly skilled adversary. Not only will you learn a lot and get to meet all the movers and shakers in the space, but your $50 registration fee is entirely donated to charity! Last year all proceeds went to the National Center for Missing and Exploited Children. So don't delay: there really is limited seating and it does go quickly. Make sure to register your seat now!
November 5th, 2013: Open Source Digital Forensics Conference
The Volatility team will be at the Open Source Digital Forensics Conference discussing The State of Volatility. Come by and see us there :-)
November 11-15th, 2013: Volatility Training in Reston, VA
We will have our 5th public offering of the official Windows Malware and Memory Forensics training in Reston, VA November 11-15th, 2013. If you missed the last offering in June, this is your chance to take this course and learn from the developers themselves. As I've stated before, this class includes real-world scenarios that are reinforced with hands-on labs. We cover more than "just one tool" as some detractors like to say. We cover methodologies that will actually help you where some tools fail. You will have a deep enough understanding to investigate even the most skilled adversaries who know how to break common tools in order to hide. Don't be fooled and don't be left behind. Accept no imitations and make sure to take this class.
All students who take the official Volatility training receive a certificate of completion, with CPE credits that can be used for certification renewal. In addition to this, we are constantly updating the course with new material and past students are given updated materials for FREE. What more can you ask for? If you are interested in Volatility training, drop us a line at voltraining [[ at ]] memoryanalysis.net
If you want to see co-trainers MHL and Andrew Case (attrc) in action, I managed to find a couple of videos of their previous talks on youtube:
Friday, April 19, 2013
Upcoming Events and Trainings
I have several speaking and training events that are coming up this year that may be of interest to others in the community:
I will be speaking at the New York Banker's Association's upcoming Annual Technology, Compliance & Risk Management Forum on May 16th, 2013 on the topic of Incident Response and Digital Forensics. If you plan to attend I'll see you there!
Also we (Volatility) are holding our third run of Windows Malware and Memory Forensics in Reston, VA from Monday June 10th through Friday, June 14th 2013. This training will not disappoint even the most proficient of forensic/malware analysts. It includes real-world scenarios that are reinforced with hands-on labs. All students will leave with skills and confidence to conduct investigations involving RAM samples from acquisition to the final report. Students also leave with more than just being Volatility power users, they leave with a deeper knowledge of memory forensics and malware analysis methodologies. Such knowledge is integral regardless of what tools you choose for future investigations, be they open source or commercial, and much more powerful than simply "run this tool, the output is colored red so it's bad". You'll leave the class with knowledge that will help you to figure out if something really is "bad" or not. There are still a few seats left for this training, so if you are interested you should register soon. Send an email to voltraining [at] memoryanalysis.net for registration information.
If you are looking for a course that covers both disk and memory forensics, Andrew Case and I will teach our course in Digital Forensics and Incident Response again this summer at Black Hat Vegas. This course runs from July 27th through July 30th 2013 and will cover enough material to take someone from knowing practically nothing about digital forensics to a point where s/he can comfortably conduct his/her own investigations.
Also we (Volatility) will hold another run of Windows Malware and Memory Forensics in the Netherlands from Monday September 9th through Friday, September 13th 2013. Details will appear soon on the Volatility Labs blog.
Planning for the Open Memory Forensics Workshop (OMFW) is in progress. You should plan to attend if you want to know what's new and hot in the memory forensics space. OMFW is likely to take place on November 4th, 2013 one day prior to the Sleuth Kit and Open Source Digital Forensics Conference. Final details will appear soon on the Volatility Labs blog.
I will be speaking at the New York Banker's Association's upcoming Annual Technology, Compliance & Risk Management Forum on May 16th, 2013 on the topic of Incident Response and Digital Forensics. If you plan to attend I'll see you there!
Also we (Volatility) are holding our third run of Windows Malware and Memory Forensics in Reston, VA from Monday June 10th through Friday, June 14th 2013. This training will not disappoint even the most proficient of forensic/malware analysts. It includes real-world scenarios that are reinforced with hands-on labs. All students will leave with skills and confidence to conduct investigations involving RAM samples from acquisition to the final report. Students also leave with more than just being Volatility power users, they leave with a deeper knowledge of memory forensics and malware analysis methodologies. Such knowledge is integral regardless of what tools you choose for future investigations, be they open source or commercial, and much more powerful than simply "run this tool, the output is colored red so it's bad". You'll leave the class with knowledge that will help you to figure out if something really is "bad" or not. There are still a few seats left for this training, so if you are interested you should register soon. Send an email to voltraining [at] memoryanalysis.net for registration information.
If you are looking for a course that covers both disk and memory forensics, Andrew Case and I will teach our course in Digital Forensics and Incident Response again this summer at Black Hat Vegas. This course runs from July 27th through July 30th 2013 and will cover enough material to take someone from knowing practically nothing about digital forensics to a point where s/he can comfortably conduct his/her own investigations.
Also we (Volatility) will hold another run of Windows Malware and Memory Forensics in the Netherlands from Monday September 9th through Friday, September 13th 2013. Details will appear soon on the Volatility Labs blog.
Planning for the Open Memory Forensics Workshop (OMFW) is in progress. You should plan to attend if you want to know what's new and hot in the memory forensics space. OMFW is likely to take place on November 4th, 2013 one day prior to the Sleuth Kit and Open Source Digital Forensics Conference. Final details will appear soon on the Volatility Labs blog.
Monday, January 14, 2013
Windows Malware and Memory Forensics Training in The Windy City!
Cross posted from the Volatility Labs Blog:
The next journey to the center of Windows Memory Forensics starts in Chicago this March!
We are pleased to announce the second public offering of the Windows Malware and Memory Forensics Training by The Volatility Project. This is the only memory forensics course officially designed, sponsored, and taught by the Volatility developers. One of the main reasons we made Volatility open-source is to encourage and facilitate a deeper understanding of how memory analysis works, where the evidence originates, and how to interpret the data collected by the framework's extensive set of plugins. Now you can learn about these benefits first hand from the developers of the most powerful, flexible, and innovative memory forensics tool.
Appraisal from your peers who attended the first course this past December:
Please see the following details about the upcoming training event:
Dates: Monday, March 18th through Friday, March 22nd 2013
Location: Downtown Chicago, IL (exact location will be shared upon registration)
Instructors: Michael Ligh (@iMHLv2), Andrew Case (@attrc), Jamie Levy (@gleeda)
For more information about the course, view the Volatility Training Flyer (to download a copy of the PDF, click File > Download). To request a link to the online registration site or to receive a detailed course agenda/outline, please send an email voltraining [at] memoryanalysis.net.
The 1st Annual Volatility Framework Plugin Contest
Cross posted from the Volatility Labs Blog:
We are pleased to announce the 1st Annual Volatility Plugin Contest. This contest is inspired and modeled after the Hex-Rays Plugin Contest. As in the case of IDA, Volatility was designed with the belief that talented analysts should only be limited by their creativity not the tools they use. In this spirit, Volatility has a flexible architecture that can be extended in numerous ways: analysis plugins (operating system plugins, application plugins, etc), volshell commands, address spaces, profiles, or user interfaces. This contest is intended to inspire people to demonstrate their creativity, become a memory analysis pioneer, win the admiration of your peers, and give back to the community.
The contest is straightforward: Create an innovative and useful extension to The Volatility Framework and win the contest!
- 1st place wins one free seat at any future Windows Malware and Memory Forensics Training *or* 1500 USD cash
- 2nd place wins 500 USD cash
- 3rd place wins 250 USD cash
- 4th and 5th place wins Volatility swag (T-shirts, Stickers, etc)
Everyone but the Volatility core developers can participate.
Rules of Engagement
- The goal of the contest is to create innovative, interesting, and useful extensions for The Volatility Framework. While extensions written in Python are preferred, extensions written in other languages will also be considered.
- The submitted extensions should work with the Volatility 2.2 (or greater) release and should have been implemented after the initial contest announcement (1/14/2013).
- The top 5 winners of the contest will get the prizes mentioned above.
- Volatility core developers are not eligible.
- Submissions should be sent to volcon2013@memoryanalysis.net. The submission should include the source code, a short description of how the extension is used, and a signed "Individual Contributor License Agreement".
- By submitting an entry, you declare that you own the copyright to the source code and are authorized to submit it.
- All submissions should be received no later than August 1, 2013. The winner will be announced the following week. We recommend submitting early. In the case of similar submissions, preference will be shown to early submissions.
- The Volatility Project core developers will decide the winners based on the following criteria: creativity, usefulness, effort, completeness, submission date, and clarity of documentation.
- In order to collect the cash prizes, the winner will need to provide a legal picture identification and bank account information within 30 days of notification. The bank transfer will be made within two weeks after the winner is authenticated.
- Group entries are allowed; the prize will be paid (or seat will be registered, if the training option is desired) to the person designated by the group.
- Upon approval from the winners, their names/aliases will be listed on the "Volatility Hall of Fame" web page for the world to admire.
- Selected contestants may also be asked to present their work at the 2013 Open Memory Forensics Workshop or have their research featured on the Volatility Labs Blog.
Acknowledgements
A special thanks goes out to the Hex-Rays team for providing the inspiration and template for this contest.
Tuesday, November 13, 2012
Windows Memory Forensics Training for Analysts by Volatility Developers
We are pleased to announce the first public offering of the Windows Memory Forensics for Analysts training course. This is the only memory forensics course officially designed, sponsored, and taught by the Volatility developers. One of the main reasons we made Volatility open-source is to encourage and facilitate a deeper understanding of how memory analysis works, where the evidence originates, and how to interpret the data collected by the framework's extensive set of plugins. Now you can reap these benefits first hand from the developers of the most powerful, flexible, and innovative memory forensics tool.
Please see the following details about the upcoming training event:
Dates: Monday, December 3rd through Friday, December 7th 2012
Location: Reston, Virginia (exact location will be shared upon registration)
Instructors: Michael Ligh (@iMHLv2), Andrew Case (@attrc), Jamie Levy (@gleeda). Please see the VolatilityTeam wiki page for brief bios.
Overview:
The ability to perform digital investigations and incident response is becoming a critical skill for many occupations. Unfortunately, digital investigators frequently lack the training or experience to take advantage of the volatile artifacts found in physical memory. Volatile memory contains valuable information about the runtime state of the system, provides the ability to link artifacts from traditional forensic analysis (network, file system, registry), and provides the ability to ascertain investigative leads that have been unbeknownst to most analysts. Malicious adversaries have been leveraging this knowledge disparity to undermine many aspects of the digital investigation process with such things as anti-forensics techniques, memory resident malware, kernel rootkits, encryption (file systems, network traffic, etc), and Trojan defenses. The only way to turn-the-tables and defeat a creative digital human adversary is through talented analysts.
This course will demonstrate why memory forensics is a critical component of the digital investigation process and how investigators can gain the upper hand. The course will consist of lectures on specific topics in Windows memory forensics followed by intense hands-on exercises to put the topics into real world contexts. Exercises will require analysis of malware in memory, kernel-level rootkits, registry artifacts found in memory, signs of data exfiltration, and much more. This course is your opportunity to learn these invaluable skills from the researchers and developers that have pioneered the field. This is also the only memory forensics training class that is authorized to teach Volatility, officially sponsored by The Volatility Project, and taught directly by the Volatility developers.
Who should attend?
This course is intended for malware analysts, reverse engineers, incident responders, digital forensics analysts, law enforcement officers, federal agents, system administrators, corporate investigators, or anyone who wants to develop the skills necessary to combat advanced adversaries.
Course Prerequisites
This is a 5-day course composed of both classroom learning and hands-on training exercises and scenarios. All course material, lunches, and coffee breaks will be provided (If you have unique dietary restrictions, please make them known during registration).
Course Requirements
In order to fully participate in the course, students are required to bring a properly pre-configured laptop. Students are encouraged to bring laptops that can run both Linux and Windows, where either instance is virtualized based on student preference. It is the student's responsibility to make sure the laptop is configured prior to the beginning of the course. There is no time built into the course schedule to help people configure machines, so please make sure your laptop has been properly configured before showing up for class.
Minimum Hardware Requirements:
2.0 GHz CPU
4 GB of RAM
20 GB of disk space
DVD-ROM drive
USB 2.0 ports
Wireless Network Interface Card
Software Requirements:
Python 2.6 or 2.7
Microsoft Windows Debugger
VMware Workstation 6/Fusion 3 or higher
7-Zip (or ability to decompress zip, gzip, rar, etc)
Wireshark
Additional free/open-source tools or libraries may be required to complete hands-on exercises. More information will be shared upon registration.
Course Fee:
The cost of the course is $3500. Law enforcement, government, and educational discounts are available.
Registration:
To obtain information on registration, please email voltraining [ @ ] memoryanalysis.net.
Other Course Benefits:
Students will be supporting open source development (Volatility)
Preparation for the Advanced Memory Analyst Certification (AMAC)
Please see the following details about the upcoming training event:
Dates: Monday, December 3rd through Friday, December 7th 2012
Location: Reston, Virginia (exact location will be shared upon registration)
Instructors: Michael Ligh (@iMHLv2), Andrew Case (@attrc), Jamie Levy (@gleeda). Please see the VolatilityTeam wiki page for brief bios.
Overview:
The ability to perform digital investigations and incident response is becoming a critical skill for many occupations. Unfortunately, digital investigators frequently lack the training or experience to take advantage of the volatile artifacts found in physical memory. Volatile memory contains valuable information about the runtime state of the system, provides the ability to link artifacts from traditional forensic analysis (network, file system, registry), and provides the ability to ascertain investigative leads that have been unbeknownst to most analysts. Malicious adversaries have been leveraging this knowledge disparity to undermine many aspects of the digital investigation process with such things as anti-forensics techniques, memory resident malware, kernel rootkits, encryption (file systems, network traffic, etc), and Trojan defenses. The only way to turn-the-tables and defeat a creative digital human adversary is through talented analysts.
This course will demonstrate why memory forensics is a critical component of the digital investigation process and how investigators can gain the upper hand. The course will consist of lectures on specific topics in Windows memory forensics followed by intense hands-on exercises to put the topics into real world contexts. Exercises will require analysis of malware in memory, kernel-level rootkits, registry artifacts found in memory, signs of data exfiltration, and much more. This course is your opportunity to learn these invaluable skills from the researchers and developers that have pioneered the field. This is also the only memory forensics training class that is authorized to teach Volatility, officially sponsored by The Volatility Project, and taught directly by the Volatility developers.
Who should attend?
This course is intended for malware analysts, reverse engineers, incident responders, digital forensics analysts, law enforcement officers, federal agents, system administrators, corporate investigators, or anyone who wants to develop the skills necessary to combat advanced adversaries.
Course Prerequisites
- It is recommended that students have some experience with the Volatility Framework.
- Students should possess a basic knowledge of digital investigation tools and techniques.
- Students should be comfortable with general troubleshooting of both Linux and Windows operating systems (setup, configuration, networking)
- Students should be familiar with popular system administration tools (i.e. Sysinternals Utilities)
- Student should be both familiar and comfortable with using the command line
- Student should have a basic understanding of Python or similar scripting language
This is a 5-day course composed of both classroom learning and hands-on training exercises and scenarios. All course material, lunches, and coffee breaks will be provided (If you have unique dietary restrictions, please make them known during registration).
Course Requirements
In order to fully participate in the course, students are required to bring a properly pre-configured laptop. Students are encouraged to bring laptops that can run both Linux and Windows, where either instance is virtualized based on student preference. It is the student's responsibility to make sure the laptop is configured prior to the beginning of the course. There is no time built into the course schedule to help people configure machines, so please make sure your laptop has been properly configured before showing up for class.
Minimum Hardware Requirements:
2.0 GHz CPU
4 GB of RAM
20 GB of disk space
DVD-ROM drive
USB 2.0 ports
Wireless Network Interface Card
Software Requirements:
Python 2.6 or 2.7
Microsoft Windows Debugger
VMware Workstation 6/Fusion 3 or higher
7-Zip (or ability to decompress zip, gzip, rar, etc)
Wireshark
Additional free/open-source tools or libraries may be required to complete hands-on exercises. More information will be shared upon registration.
Course Fee:
The cost of the course is $3500. Law enforcement, government, and educational discounts are available.
Registration:
To obtain information on registration, please email voltraining [ @ ] memoryanalysis.net.
Other Course Benefits:
Students will be supporting open source development (Volatility)
Preparation for the Advanced Memory Analyst Certification (AMAC)
Monday, November 12, 2012
ACSAC 2012
I will be teaching a full day course on Windows Forensics and IR at Annual Computer Security Applications Conference (ACSAC) on December 4th at the Buena Vista Palace Hotel & Spa in Orlando, FL. There is still time to sign up for the conference and/or training and it looks like a good program this year.
Saturday, September 29, 2012
Week 3 of the Month of Volatility Plugins posted!
Cross listed from Andrew Case's blog:
I was writing to announce that week 3 of the month of Volatility plugins is finished, and we now have five more in-depth blog posts covering Windows and Linux internals and rootkit detection as well as a bonus plugin that analyzes Internet Explorer browsing history. These have all been posted on the Volatility Labs blog.
Post 1: Detecting Malware Hooks in the Windows GUI Subsystem
This Windows focused post covers detecting malware hooks in the Windows GUI subsystem, including message hooks and event hooks, and what effects these hooks can have on a compromised system.
http://volatility-labs.blogspot.com/2012/09/movp-31-detecting-malware-hooks-in.html
Post 2: Shellbags in Memory, SetRegTime, and TrueCrypt Volumes
This Windows focused post covers finding and recovering shellbags from memory, the forensics importance of shellbags, and analyzes the effects of anti-forensics on shellbag timestamps. It concludes with covering the traces left in shellbags by TrueCrypt.
http://volatility-labs.blogspot.com/2012/09/movp-32-shellbags-in-memory-setregtime.html
Post 3: Analyzing USER Handles and the Win32k.sys Gahti
This Windows focused post introduces two new plugins, one named gahti that determines the various different types of USER objects on a system and another named userhandles which traverses the handle table entries and associates them with the owning processes or threads
http://volatility-labs.blogspot.com/2012/09/movp-33-analyzing-user-handles-and.html
Post 4: Recovering tagCLIPDATA: What's In Your Clipboard?
This Windows focused post covers recovery of the Windows clipboard from physical memory.
http://volatility-labs.blogspot.com/2012/09/movp-34-recovering-tagclipdata-whats-in.html
Post 5: Analyzing the 2008 DFRWS Challenge with Volatility
This Linux focused post analyzes the 2008 memory challenge with Volatility. It walks through the artifacts produced by the winning team and shows how to recover the same information with Volatility. It then shows plugins in Volatility that can recover artifacts not produced by the winning team.
http://volatility-labs.blogspot.com/2012/09/movp-35-analyzing-2008-dfrws-challenge.html
Bonus Post: HowTo: Scan for Internet Cache/History and URLs
This Windows focused post covers how to recover Internet Explorer's cache and history from a memory sample.
http://volatility-labs.blogspot.com/2012/09/howto-scan-for-internet-cachehistory.html
If you have any questions or comments on the posts, please leave a comment on the respective post on the Volatility Labs blog.
Friday, September 21, 2012
Week 2 of the Month of Volatility Plugins posted!
It's been an exciting week in the Volatility community. We've just finished our second week of Month of Volatility Plugins (MoVP) blogposts, released Volatility 2.2 RC2 for testing, fixed a few minor bugs and now we're gearing up for our third week of posts and the upcoming Open Memory Forensics Workshop (OMFW). Here is a list of this week's posts, compiled by Andrew Case:
We hope you've enjoyed this week's series. Stay tuned, we have much more in store!
I was writing to announce that week 2 of the month of Volatility plugins is finished, and we now have five more in-depth blog posts covering Windows and Linux internals and rootkit detection. These have all been posted to the new Volatility Labs blog.
Post 1: Atoms (The New Mutex), Classes and DLL Injection
This Windows focused post covers investigating malware and understanding infections by analyzing the atom tables.
http://volatility-labs.blogspot.com/2012/09/movp-21-atoms-new-mutex-classes-and-dll.html
Post 2: Malware in your Windows
This Windows focused post covers enumerating and analyzing windows in the GUI subsystem.
http://volatility-labs.blogspot.com/2012/09/movp-22-malware-in-your-windows.html
Post 3: Event logs and Service SIDs
This Windows focused post demonstrates recovering event logs from memory and calculating service SIDs.
http://volatility-labs.blogspot.com/2012/09/movp-23-event-logs-and-service-sids.html
Post 4: Analyzing the Jynx rootkit and LD_PRELOAD
This Linux focused post covers analyzing the Jynx rootkit as well as generic methods for analyzing LD_PRELOAD based rootkits.
http://volatility-labs.blogspot.com/2012/09/movp-24-analyzing-jynx-rootkit-and.html
Post 5: Investigating In-Memory Network Data with Volatility
This Linux focused post goes through each of the Linux Volatility plugins related to recovering network data from memory, such as network connections, packets, and the routing cache.
http://volatility-labs.blogspot.com/2012/09/movp-25-investigating-in-memory-network.html
If you have any questions or comments on the posts, please leave a comment on the respective post on the Volatility Labs blog.
We hope you've enjoyed this week's series. Stay tuned, we have much more in store!
Friday, September 14, 2012
Week 1 of the Month of Volatility Plugins posted!
I'm going to borrow from Andrew's blog here to let you know about our Month of Volatility Plugins:
Future Volatility posts will appear on our official blog (http://volatility-labs.blogspot.com/). Also you might want to follow our project on twitter: @Volatility for updates and news. See you at OMFW!
I was writing to announce that week 1 of the month of Volatility plugins is finished, and we now have five in-depth blog posts covering Windows and Linux internals and rootkit detection. These have all been posted to the new Volatility Labs blog.
Post 1: Logon Sessions, Processes, and Images
This Windows focused post covers linking processes to their logon session, detecting hidden processes using session structures, and determining the loaded the drivers mapped into each session.
http://volatility-labs.blogspot.com/2012/09/movp-11- logon-sessions-processes-and. html
Post 2: Window Stations and Clipboard Malware
This Windows focused post covers enumerating and analyzing window stations and clipboard monitoring malware.
http://volatility-labs.blogspot.com/2012/09/movp-12- window-stations-and-clipboard. html
Post 3: Desktops, Heaps, and Ransomware
This Windows focused post covers finding rogue desktops used to hide applications and created by ransomware, linking threads to desktops, analyzing the desktop heap for memory corruptions, and profiling heap allocations to locate USER objects.
http://volatility-labs.blogspot.com/2012/09/movp-13- desktops-heaps-and-ransomware. html
Post 4: Average Coder Rootkit, Bash History, and Elevated Processes
This Linux focused post covers analyzing the Average Coder rootkit, recovering .bash_history from memory, even when faced with anti-forensics, and finding elevated processes.
http://volatility-labs.blogspot.com/2012/09/movp-14- average-coder-rootkit-bash. html
Post 5: KBeast Rootkit, Detecting Hidden Modules, and sysfs
This Linux focused post covers analyzing the KBeast rootkit, finding modules unlinked from the module list, and the forensic values of sysfs.
http://volatility-labs.blogspot.com/2012/09/movp-15- kbeast-rootkit-detecting- hidden.html
If you have any questions or comments on the posts, please leave a comment on the respective post on the Volatility Labs blog.
Future Volatility posts will appear on our official blog (http://volatility-labs.blogspot.com/). Also you might want to follow our project on twitter: @Volatility for updates and news. See you at OMFW!
Saturday, September 01, 2012
Job File Parser
While writing material for the Blackhat training course that Andrew Case and I gave this summer, I realized that there did not appear to be many tools that would parse job files. At that time, Harlan Carvey had written a blogpost on job files and had mentioned them in part of his timeline materials, but he had not yet released his Perl script (It has since been released here). This prompted me to write up a parser of my own in Python.
.job files consist of two sections: 1) Fixed Length and 2) Variable Length. The MSDN documentation is fairly good for letting us know how to parse out these sections.
So what does a .job file look like?
$ xxd At5.job 0000000: 0006 0100 e378 73f7 4d8b 2a45 a589 1cc5 .....xs.M.*E.... 0000010: fa64 cfd2 4600 cc00 0000 0000 3c00 0a00 .d..F.......<... 0000020: 2000 0000 0014 730f 0000 0000 0513 0400 .....s......... 0000030: 0200 e421 dc07 0700 0100 1000 0b00 1a00 ...!............ 0000040: 0000 0f00 0000 0400 6300 6d00 6400 0000 ........c.m.d... 0000050: 0f00 2f00 6300 2000 6e00 6f00 7400 6500 ../.c. .n.o.t.e. 0000060: 7000 6100 6400 2e00 6500 7800 6500 0000 p.a.d...e.x.e... 0000070: 0000 0700 5300 5900 5300 5400 4500 4d00 ....S.Y.S.T.E.M. 0000080: 0000 1e00 4300 7200 6500 6100 7400 6500 ....C.r.e.a.t.e. 0000090: 6400 2000 6200 7900 2000 4e00 6500 7400 d. .b.y. .N.e.t. 00000a0: 5300 6300 6800 6500 6400 7500 6c00 6500 S.c.h.e.d.u.l.e. 00000b0: 4a00 6f00 6200 4100 6400 6400 2e00 0000 J.o.b.A.d.d..... 00000c0: 0000 0800 0000 0000 0000 0000 0100 3000 ..............0. 00000d0: 0000 dc07 0700 1000 0000 0000 0000 0b00 ................ 00000e0: 1a00 0000 0000 0000 0000 0000 0000 0000 ................ 00000f0: 0000 feff ffff fd68 7377 0000 0000 0100 .......hsw...... 0000100: 0100 0416 10dd 78d9 b300 f7f0 9b20 9bd8 ......x...... .. 0000110: a0c4 5108 c943 d5c9 c64f 47ea 6052 0349 ..Q..C...OG.`R.I 0000120: 23e1 e1ab 6815 e8ef 219e 6d3b aa88 1360 #...h...!.m;...` 0000130: 706b c27b 2e44 9db1 4e89 81ca dd0a 869e pk.{.D..N....... 0000140: 2b61 .6..
We can see the first section of the job file below:
0000000: 0006 0100 e378 73f7 4d8b 2a45 a589 1cc5 .....xs.M.*E.... 0000010: fa64 cfd2 4600 cc00 0000 0000 3c00 0a00 .d..F.......<... 0000020: 2000 0000 0014 730f 0000 0000 0513 0400 .....s......... 0000030: 0200 e421 dc07 0700 0100 1000 0b00 1a00 ...!............ 0000040: 0000 0f00 ....
The fixed length section is pretty straightforward (I will only fill in a few):
0-2 : Product Info (0x600 - Vista)
2-4 : File Version (0x1)
4-20 : UUID ({F77378E3-8B4D-452A-A589-1CC5FA64CFD2})
20-22: Application Name Offset (0x46)
22-24: Trigger Offset (0xcc)
24-26: Error Retry Count (0x00)
26-28: Error Retry Interval (0x00)
28-30: Idle Deadline (0x3c)
30-32: Idle Wait (0xa)
32-36: Priority
36-40: Maximum Runtime
40-44: Exit Code (0x0)
44-48: Status (0x41305)
48-52: Flags
52-68: Run Date (Monday Jul 16 11:26:00.15 2012)
The variable length section actually contains sizes (denoted in red below) before some of the data members mentioned in the MSDN documentation:
0000 0400 6300 6d00 6400 0000 ...c.m.d... 0000050: 0f00 2f00 6300 2000 6e00 6f00 7400 6500 ../.c. .n.o.t.e. 0000060: 7000 6100 6400 2e00 6500 7800 6500 0000 p.a.d...e.x.e... 0000070: 0000 0700 5300 5900 5300 5400 4500 4d00 ....S.Y.S.T.E.M. 0000080: 0000 1e00 4300 7200 6500 6100 7400 6500 ....C.r.e.a.t.e. 0000090: 6400 2000 6200 7900 2000 4e00 6500 7400 d. .b.y. .N.e.t. 00000a0: 5300 6300 6800 6500 6400 7500 6c00 6500 S.c.h.e.d.u.l.e. 00000b0: 4a00 6f00 6200 4100 6400 6400 2e00 0000 J.o.b.A.d.d..... 00000c0: 0000 0800 0000 0000 0000 0000 0100 3000 ..............0. 00000d0: 0000 dc07 0700 1000 0000 0000 0000 0b00 ................ 00000e0: 1a00 0000 0000 0000 0000 0000 0000 0000 ................ 00000f0: 0000 feff ffff fd68 7377 0000 0000 0100 .......hsw...... 0000100: 0100 0416 10dd 78d9 b300 f7f0 9b20 9bd8 ......x...... .. 0000110: a0c4 5108 c943 d5c9 c64f 47ea 6052 0349 ..Q..C...OG.`R.I 0000120: 23e1 e1ab 6815 e8ef 219e 6d3b aa88 1360 #...h...!.m;...` 0000130: 706b c27b 2e44 9db1 4e89 81ca dd0a 869e pk.{.D..N....... 0000140: 2b61 .6..
Going over some of the data above we have:
Running instance count
Command Name Length (0x4 - includes ending '\x00')
Command Name (cmd )
Parameter length (0xf)
Parameter (/c notepad.exe )
Working Directory Length (0x0)
Working Directory (if Working Directory Length > 0)
User Name Length (0x7)
User Name (SYSTEM)
Comment Length (0x1e)
Comment (if Comment length > 0 - Created by NetScheduleJobAdd. )
User Data / Reserved data
Trigger count
Triggers
- Scheduled date (Jul 16 11:26:00.0 2012)
Job Signature
So I am releasing a job file parser script that can parse out almost all of these items mentioned above. You can find it here. The only things left off are the user/reserved data, some of the trigger data and the job signature sections. I have only tested this on 32 bit *nix systems, so let me know if you hit issues on another platforms. You can see an example output of the above job file below:
$ python jobparser.py -f At5.job Product Info: Windows Vista File Version: 1 UUID: {F77378E3-8B4D-452A-A589-1CC5FA64CFD2} Maximum Run Time: 72:00:00.0 (HH:MM:SS.MS) Exit Code: 0 Status: Properties not set Flags: TASK_FLAG_DONT_START_IF_ON_BATTERIES Date Run: Monday Jul 16 11:26:00.15 2012 Running Instances: 0 Application: cmd Parameters: /c notepad.exe Working Directory: Working Directory not set User: SYSTEM Comment: Created by NetScheduleJobAdd. Scheduled Date: Jul 16 11:26:00.0 2012
Here is some output of job files taken from a Windows 2008 machine:
$ python jobparser.py -d Tasks/ ************************************************************************ File: Tasks/At1.job Product Info: Windows Vista File Version: 1 UUID: {CE14B659-4115-4263-BFAD-A8318428AB68} Maximum Run Time: 72:00:00.0 (HH:MM:SS.MS) Exit Code: 0 Status: Properties not set Flags: TASK_FLAG_DONT_START_IF_ON_BATTERIES Date Run: Task not yet run Running Instances: 0 Application: notepad.exe Working Directory: Working Directory not set User: SYSTEM Comment: Created by NetScheduleJobAdd. Scheduled Date: Jul 17 02:20:00.0 2012 ************************************************************************ ************************************************************************ File: Tasks/At2.job Product Info: Windows Vista File Version: 1 UUID: {46F61E52-4581-49A9-9AD0-2244C206AEEB} Maximum Run Time: 72:00:00.0 (HH:MM:SS.MS) Exit Code: 0 Status: Properties not set Flags: TASK_FLAG_DONT_START_IF_ON_BATTERIES Date Run: Task not yet run Running Instances: 0 Application: notepad.exe Working Directory: Working Directory not set User: SYSTEM Comment: Created by NetScheduleJobAdd. Scheduled Date: Jul 16 14:20:00.0 2012 ************************************************************************
And here are a couple of XP Tasks, notice that one has "Running Instances" value of "1", this was copied when the command was currently running:
************************************************************************ File: Solitaire.job Product Info: Windows XP File Version: 1 UUID: {3824DDBB-A037-4016-B99A-28BD95D429AF} Maximum Run Time: 72:00:00.0 (HH:MM:SS.MS) Exit Code: 0 Status: Task has not run Flags: TASK_FLAG_INTERACTIVE, TASK_FLAG_DELETE_WHEN_DONE Date Run: Monday Aug 13 12:37:00.10 2012 Running Instances: 1 Application: C:\WINDOWS\system32\sol.exe Working Directory: C:\WINDOWS\system32 User: user Comment: Comment not set Scheduled Date: Aug 13 12:37:00.0 2012 ************************************************************************ ************************************************************************ File: Solitaire2.job Product Info: Windows XP File Version: 1 UUID: {3824DDBB-A037-4016-B99A-28BD95D429AF} Maximum Run Time: 72:00:00.0 (HH:MM:SS.MS) Exit Code: 0 Status: Task is ready to run Flags: TASK_FLAG_INTERACTIVE, TASK_FLAG_DELETE_WHEN_DONE Date Run: Monday Aug 13 12:37:00.10 2012 Running Instances: 0 Application: C:\WINDOWS\system32\sol.exe Working Directory: C:\WINDOWS\system32 User: user Comment: Comment not set Scheduled Date: Aug 13 12:37:00.0 2012 ************************************************************************
References:
[1] Windows Forensic Analysis 2nd Ed., Harlan Carvey
[2] .JOB File Format, http://msdn.microsoft.com/en-us/library/cc248285%28v=prot.13%29.aspx
[3] Windows Scheduler (at job) Forensics, http://computer-forensics.sans.org/blog/2009/09/16/windows-scheduler-at-job-forensics
Saturday, April 21, 2012
MBR Parser
With the increase in MBR infectors, I've decided to release a script I wrote that parses the MBR as well as hashes and disassembles the bootcode. I've found that MBR bootcode is pretty stable across systems of the same OS, so this script should allow you to quickly check for any discrepancies on a system.
You of course need Python and Distorm to use this script.
A shortened example output can be seen below:
$ python mbr_parser.py -f mbr.bin Disk signature: 96-80-96-80 Bootcode md5: 4ad444d4e7efce9485a94186c3f4b157 Bootcode Disassembly: 00000000: 33c0 XOR AX, AX 00000002: 8ed0 MOV SS, AX 00000004: bc007c MOV SP, 0x7c00 00000007: fb STI 00000008: 50 PUSH AX 00000009: 07 POP ES 0000000a: 50 PUSH AX 0000000b: 1f POP DS 0000000c: fc CLD 0000000d: 50 PUSH AX 0000000e: be007c MOV SI, 0x7c00 00000011: bf0006 MOV DI, 0x600 00000014: b90002 MOV CX, 0x200 00000017: f3a4 REP MOVSB 00000019: bf1e06 MOV DI, 0x61e 0000001c: 57 PUSH DI 0000001d: cb RETF 0000001e: b441 MOV AH, 0x41 00000020: b280 MOV DL, 0x80 00000022: bbaa55 MOV BX, 0x55aa 00000025: cd13 INT 0x13 00000027: 81fb55aa CMP BX, 0xaa55 0000002b: 7530 JNZ 0x5d 0000002d: f6c101 TEST CL, 0x1 00000030: 742b JZ 0x5d 00000032: be0008 MOV SI, 0x800 00000035: c7041000 MOV WORD [SI], 0x10 00000039: c744020600 MOV WORD [SI+0x2], 0x6 [snip] 000001b2: 0000 ADD [BX+SI], AL 000001b4: 002c ADD [SI], CH 000001b6: 44 INC SP 000001b7: 63 DB 0x63 ===== Partition Table #1 ===== Boot flag: 0x80 (Bootable) Partition type: 0x7 (NTFS) Starting Sector (LBA): 0x3f (63) Starting CHS: Cylinder: 0 Head: 1 Sector: 1 Ending CHS: Cylinder: 520 Head: 254 Sector: 63 Size in sectors: 0x7fb68a (8369802) ===== Partition Table #2 ===== Boot flag: 0x0 Partition type: 0x0 (Empty) Starting Sector (LBA): 0x0 (0) Starting CHS: Cylinder: 0 Head: 0 Sector: 0 Ending CHS: Cylinder: 0 Head: 0 Sector: 0 Size in sectors: 0x0 (0) ===== Partition Table #3 ===== Boot flag: 0x0 Partition type: 0x0 (Empty) Starting Sector (LBA): 0x0 (0) Starting CHS: Cylinder: 0 Head: 0 Sector: 0 Ending CHS: Cylinder: 0 Head: 0 Sector: 0 Size in sectors: 0x0 (0) ===== Partition Table #4 ===== Boot flag: 0x0 Partition type: 0x0 (Empty) Starting Sector (LBA): 0x0 (0) Starting CHS: Cylinder: 0 Head: 0 Sector: 0 Ending CHS: Cylinder: 0 Head: 0 Sector: 0 Size in sectors: 0x0 (0)
Update: Fixed output to 16bit assembly. Thanks for the feedback!
The script can be found here.
Friday, March 23, 2012
Upcoming Cybercrime Studies talk: For a Free Digital Society by Dr. Richard Stallman
Yet another interesting upcoming talk at John Jay College on Tuesday March 27, 2012:
Center for Cybercrime Studies
John Jay College of Criminal Justice
presents
For a Free Digital Society
Dr. Richard Stallman
President
Free Software Foundation
Abstract
Activities directed at ``including'' more people in the use of digital technology are predicated on the assumption that such inclusion is invariably a good thing. It appears so, when judged solely by immediate practical convenience. However, if we also judge in terms of human rights, whether digital inclusion is good or bad depends on what kind of digital world we are to be included in. If we wish to work towards digital inclusion as a goal, it behooves us to make sure it is the good kind.
Richard Stallman launched the free software movement in 1983 and started the development of the GNU operating system (see www.gnu.org) in 1984. GNU is free software: everyone has the freedom to copy it and redistribute it, with or without changes. The GNU/Linux system, basically the GNU operating system with Linux added, is used on tens of millions of computers today. Stallman has received the ACM Grace Hopper Award, a MacArthur Foundation Fellowship, the Electronic Frontier Foundation's Pioneer Award, and the Takeda Award for Social/Economic Betterment, as well as several honorary doctorates.
Date: Tuesday, March 27, 2012
Time: 1:30 PM
Location: L.61 Conference Center (New Building)
John Jay College of Criminal Justice
899 Tenth Avenue
New York, NY
RSVP: Nicole Daniels at 212-237-8920 or email ndaniels@jjay.cuny.edu. For additional information please contact Professor Doug Salane, Director of the Center for Cybercrime Studies, 212-237-8836 or email dsalane@jjay.cuny.edu.
For additional Center for Cybercrime Studies events visit our web site. Go to WWW.JJAY.CUNY.EDU , ACADEMICS, RESEARCH CENTERS and INSTITUTES.
Thursday, March 22, 2012
Differential EnScript
I know I haven't written much in the last few months; I've been busy. Even though I'm writing a blogpost today it's still going to be pretty short... this is because most of what I have to say has already been written up in documentation ahead of time. Today I'm releasing an EnScript that allows you to compare two disk images using various options. The purpose of this EnScript is to find differences on a machine after some event, such as infection, software installation etc. has taken place.
I'm also releasing the source in hopes that others will be able to troubleshoot or expand it themselves as needed. I offer no warranties for this script nor promises that it is beautiful code (in all reality this was written hastily out of necessity), this is "as-is" and has worked well enough for me for my purposes. Unlike most of my stuff, I actually took time to create a GUI for it, however, to make it easier to use. Information on how it works can be found in the documentation (pdf) so I will not cover it here. Hopefully someone out there will find it useful.
Please feel free to leave comments and suggestions here or by email. Here is the Differential.EnScript.
I'm also releasing the source in hopes that others will be able to troubleshoot or expand it themselves as needed. I offer no warranties for this script nor promises that it is beautiful code (in all reality this was written hastily out of necessity), this is "as-is" and has worked well enough for me for my purposes. Unlike most of my stuff, I actually took time to create a GUI for it, however, to make it easier to use. Information on how it works can be found in the documentation (pdf) so I will not cover it here. Hopefully someone out there will find it useful.
Please feel free to leave comments and suggestions here or by email. Here is the Differential.EnScript.
Friday, March 16, 2012
Upcoming Cybercrime Studies talk: Digital Forensic Crime Labs
I just wanted to take the time to announce the following upcoming talk at John Jay College next week:
The Center for Cybercrime Studies
John Jay College of Criminal Justice
Presents
Digital Forensic Crime Labs
Monique Mattei Ferraro
M.S., J.D., CISSP
Technology Forensics, LLC
Digital forensics labs throughout the country were set up and subsidized by United States Department of Justice. Most labs are administered by police or law enforcement agencies. In 2009, the National Academy of Science released “Strengthening Forensic Science in the United States: A Path Forward,” which made several recommendations. Among the recommendations were that criminal labs should be independent of police/law enforcement in order to retain an appearance of objectivity. This talk delves into the tensions between the recommendations and the practice, the ethical implications and current issues affecting digital forensics labs today.
Date: Wednesday, March 21, 2012
Time: 1:30 PM
Location: Haaren Hall, RM 630
899 Tenth Avenue
(10th Avenue and 59th Street)
RSVP: Nicole Daniels at 212-237-8920 or email ndaniels@jjay.cuny.edu. For additional information please contact Professor Doug Salane, Director of the Center for Cybercrime Studies, 212-237-8836 or email dsalane@jjay.cuny.edu.
For additional Center for Cybercrime Studies events visit our Web site (http://www.jjay.cuny.edu/
Tuesday, September 13, 2011
Volatility 2.0: Timeliner, RegistryAPI, evtlogs and more
Back in July I gave a talk at OMFW about extracting timeline data from a memory sample using the Volatility framework. Now has come the time to release the plugins that came along with that talk.
In addition to the plugins I have included a whitepaper on how these plugins were created and used. It is released more in hopes that people will see how to use the framework and be able to write their own plugins or extend existing ones.
I have included all these plugins in a zip file:
MHL's malware malware plugins (malware.py) are included only for convenience. You can also download them from his repository and check there for updates.
I would like to thank MHL and AW for their valuable feedback and Bertha M for extensive testing of the timeliner plugins. The links to the paper and plugins are below:
Timeliner Release Documentation (PDF)
timeliner plugins (ZIP)
Note: Any updates to these plugins will appear in my github repository first.
In addition to the plugins I have included a whitepaper on how these plugins were created and used. It is released more in hopes that people will see how to use the framework and be able to write their own plugins or extend existing ones.
I have included all these plugins in a zip file:
$ unzip -l timeliner_9-2011.zip
Archive: timeliner_9-2011.zip
Length Date Time Name
-------- ---- ---- ----
14455 09-28-11 14:40 volatility/plugins/timeliner.py
10789 09-27-11 09:24 volatility/plugins/evtlogs.py
147458 09-09-11 11:03 volatility/plugins/malware.py
13559 09-22-11 19:09 volatility/plugins/registryapi.py
8554 09-18-11 21:33 volatility/plugins/getsids.py
40993 09-22-11 16:29 volatility/plugins/getservicesids.py
-------- -------
235808 6 files
- evtlogs.py: plugin to parse Evt logs from XP/2K3
- registryapi.py: plugin for routine registry actions
- getservicesids.py: plugin to collect and calculate service SIDs (used with the new getsids and evtlogs
- timeliner.py: the timeline creating script that pulls everything together
MHL's malware malware plugins (malware.py) are included only for convenience. You can also download them from his repository and check there for updates.
I would like to thank MHL and AW for their valuable feedback and Bertha M for extensive testing of the timeliner plugins. The links to the paper and plugins are below:
Timeliner Release Documentation (PDF)
timeliner plugins (ZIP)
Note: Any updates to these plugins will appear in my github repository first.
Monday, August 08, 2011
Volatility 2.0 and OMFW
In case you missed it, Volatility 2.0 has been released! Please download it and test it out and let us know if you have any problems via the "issues area" of the Google Code project. We have lots of documentation and for those on Windows who don't like to install Python, there is a standalone executable available in the downloads section. Make sure to check out the FAQ wiki which contains information on what is supported and how to use MHL's malware plugins.
Some OMFW materials have been released:
Moyix's slides (pdf).
MHL's Stuxnet blogpost and slides.
My slides (google docs)
You can help with the development of Volatility by giving us suggestions for plugins, writing documentation or donating malware samples. Check out the FAQ for how to do all of the above.
Some OMFW materials have been released:
Moyix's slides (pdf).
MHL's Stuxnet blogpost and slides.
My slides (google docs)
You can help with the development of Volatility by giving us suggestions for plugins, writing documentation or donating malware samples. Check out the FAQ for how to do all of the above.
Saturday, April 30, 2011
Volatility 1.4 UserAssist plugin
From a computer forensics standpoint, userassist keys can provide a lot of information about user activity (see the Harlan's posts for more information).
After looking at Didier Steven's article on userassist keys for Windows 7 from Into the Boxes issue 0x0 and RegRipper, I decided to write up a plugin that would pull out UserAssist keys from all versions of windows for Volatility.
One thing I decided to add was an enumeration of GUIDs to human friendly folder names, which were obtained from here.
The plugin is available in my git repository. Simply download and place into your volatility/plugins directory and you're set.
Update: This plugin is now part of the core Volatility code
Example Output
Below you can see some snippets of output for Windows 7. The fields are pretty self explanatory, though you can read Didier Steven's article for more details. The hex dump is the actual data from which this information was parsed, just so you can verify it yourself.
Here you can see an example of output from Windows XP:
Shoutz to ikelos for helping me optimize this :-)
References:
Into the Boxes issue 0x0 http://intotheboxes.wordpress.com/2010/01/01/into-the-boxes-issue-0x0/
RegRipper http://regripper.wordpress.com/
After looking at Didier Steven's article on userassist keys for Windows 7 from Into the Boxes issue 0x0 and RegRipper, I decided to write up a plugin that would pull out UserAssist keys from all versions of windows for Volatility.
One thing I decided to add was an enumeration of GUIDs to human friendly folder names, which were obtained from here.
The plugin is available in my git repository. Simply download and place into your volatility/plugins directory and you're set.
Update: This plugin is now part of the core Volatility code
Example Output
Below you can see some snippets of output for Windows 7. The fields are pretty self explanatory, though you can read Didier Steven's article for more details. The hex dump is the actual data from which this information was parsed, just so you can verify it yourself.
$ ./vol.py -f win7.vmem --profile=Win7SP0x86 userassist --no-cache
Volatile Systems Volatility Framework 1.4_rc1
----------------------------
Registry: \??\C:\Users\admin\ntuser.dat
Key name: Count
Last updated: 2010-07-06 22:40:25
Subkeys:
Values:
REG_BINARY Microsoft.Windows.GettingStarted :
Count: 14
Focus Count: 21
Time Focused: 0:07:00.500000
Last updated: 2010-03-09 19:49:20
0000 00 00 00 00 0E 00 00 00 15 00 00 00 A0 68 06 00 .............h..
0010 00 00 80 BF 00 00 80 BF 00 00 80 BF 00 00 80 BF ................
0020 00 00 80 BF 00 00 80 BF 00 00 80 BF 00 00 80 BF ................
0030 00 00 80 BF 00 00 80 BF FF FF FF FF EC FE 7B 9C ..............{.
0040 C1 BF CA 01 00 00 00 00 ........
REG_BINARY UEME_CTLSESSION :
Count: 187
Focus Count: 1205
Time Focused: 6:25:06.216000
Last updated: 1970-01-01 00:00:00
0000 00 00 00 00 BB 00 00 00 B5 04 00 00 B4 90 60 01 ..............`.
0010 10 00 00 00 39 00 00 00 E9 67 28 00 7B 00 44 00 ....9....g(.{.D.
0020 36 00 35 00 32 00 33 00 31 00 42 00 30 00 2D 00 6.5.2.3.1.B.0.-.
0030 42 00 32 00 46 00 31 00 2D 00 34 00 38 00 35 00 B.2.F.1.-.4.8.5.
[snip]
REG_BINARY %windir%\system32\displayswitch.exe :
Count: 13
Focus Count: 19
Time Focused: 0:06:20.500000
Last updated: 2010-03-09 19:49:20
0000 00 00 00 00 0D 00 00 00 13 00 00 00 60 CC 05 00 ............`...
0010 00 00 80 BF 00 00 80 BF 00 00 80 BF 00 00 80 BF ................
0020 00 00 80 BF 00 00 80 BF 00 00 80 BF 00 00 80 BF ................
0030 00 00 80 BF 00 00 80 BF FF FF FF FF EC FE 7B 9C ..............{.
0040 C1 BF CA 01 00 00 00 00 ........
REG_BINARY %windir%\system32\calc.exe :
Count: 12
Focus Count: 17
Time Focused: 0:05:40.500000
Last updated: 2010-03-09 19:49:20
0000 00 00 00 00 0C 00 00 00 11 00 00 00 20 30 05 00 ............ 0..
0010 00 00 80 BF 00 00 80 BF 00 00 80 BF 00 00 80 BF ................
0020 00 00 80 BF 00 00 80 BF 00 00 80 BF 00 00 80 BF ................
0030 00 00 80 BF 00 00 80 BF FF FF FF FF EC FE 7B 9C ..............{.
0040 C1 BF CA 01 00 00 00 00 ........
........
REG_BINARY Z:\vmware-share\apps\odbg110\OLLYDBG.EXE :
Count: 11
Focus Count: 266
Time Focused: 1:19:58.045000
Last updated: 2010-03-18 01:56:31
0000 00 00 00 00 0B 00 00 00 0A 01 00 00 69 34 49 00 ............i4I.
0010 00 00 80 BF 00 00 80 BF 00 00 80 BF 00 00 80 BF ................
0020 00 00 80 BF 00 00 80 BF 00 00 80 BF 00 00 80 BF ................
0030 00 00 80 BF 00 00 80 BF FF FF FF FF 70 3B CB 3A ............p;.:
0040 3E C6 CA 01 00 00 00 00 >.......
REG_BINARY %ProgramFiles%\Microsoft SDKs\Windows\v7.0\Bin\vsstools\vshadow.exe :
Count: 0
Focus Count: 67
Time Focused: 0:06:12.811000
Last updated: 1970-01-01 00:00:00
0000 00 00 00 00 00 00 00 00 43 00 00 00 57 AE 05 00 ........C...W...
0010 00 00 80 BF 00 00 80 BF 00 00 80 BF 00 00 80 BF ................
0020 00 00 80 BF 00 00 80 BF 00 00 80 BF 00 00 80 BF ................
0030 00 00 80 BF 00 00 80 BF FF FF FF FF 00 00 00 00 ................
0040 00 00 00 00 00 00 00 00 ........
REG_BINARY %windir%\regedit.exe :
Count: 2
Focus Count: 8
Time Focused: 0:03:22.626000
Last updated: 2010-03-17 23:40:36
0000 00 00 00 00 02 00 00 00 08 00 00 00 8E 15 03 00 ................
0010 00 00 80 BF 00 00 80 BF 00 00 80 BF 00 00 80 BF ................
0020 00 00 80 BF 00 00 80 BF 00 00 80 BF 00 00 80 BF ................
0030 00 00 80 BF 00 00 80 BF FF FF FF FF 90 3A 93 3E .............:.>
0040 2B C6 CA 01 00 00 00 00 +.......
Here you can see an example of output from Windows XP:
$ ./vol.py -f XPSP3.vmem --profile=WinXPSP3x86 userassist --no-cache
Volatile Systems Volatility Framework 1.4_rc1
----------------------------
Registry: \Device\HarddiskVolume1\Documents and Settings\Administrator\NTUSER.DAT
Key name: Count
Last updated: 2010-11-24 16:35:34
Subkeys:
Values:
REG_BINARY UEME_CTLSESSION :
0000 91 52 5B 0E 1F 00 00 00 .R[.....
REG_BINARY UEME_CTLCUACount:ctor :
ID: 1
Count: 2
Last updated: 1970-01-01 00:00:00
0000 01 00 00 00 02 00 00 00 00 00 00 00 00 00 00 00 ................
REG_BINARY UEME_RUNPATH :
ID: 31
Count: 589
Last updated: 2010-11-24 16:30:49
0000 1F 00 00 00 52 02 00 00 A0 91 09 F4 F4 8B CB 01 ....R...........
REG_BINARY UEME_RUNPATH:D:\SETUP.EXE :
ID: 30
Count: 6
Last updated: 2010-09-20 15:02:47
0000 1E 00 00 00 0B 00 00 00 E0 85 39 E3 D4 58 CB 01 ..........9..X..
REG_BINARY UEME_RUNPIDL :
ID: 31
Count: 124
Last updated: 2010-11-24 14:19:29
0000 1F 00 00 00 81 00 00 00 50 78 79 9B E2 8B CB 01 ........Pxy.....
REG_BINARY UEME_RUNPIDL:%csidl2%\Microsoft Visual Basic 6.0 :
ID: 1
Count: 2
Last updated: 2009-05-12 02:28:10
0000 01 00 00 00 02 00 00 00 B0 1E DB 4A A9 D2 C9 01 ...........J....
REG_BINARY UEME_RUNPATH:C:\Program Files\Microsoft Visual Studio\VB98\VB6.EXE :
ID: 1
Count: 1
Last updated: 2009-05-12 02:28:10
0000 01 00 00 00 06 00 00 00 50 62 FC 4A A9 D2 C9 01 ........Pb.J....
REG_BINARY UEME_RUNPIDL:C:\Documents and Settings\All Users\Start Menu\Windows Update.lnk :
ID: 1
Count: 1
Last updated: 2009-05-12 02:28:36
0000 01 00 00 00 06 00 00 00 F0 D0 A1 5A A9 D2 C9 01 ...........Z....
REG_BINARY UEME_RUNPATH:C:\WINDOWS\system32\wupdmgr.exe :
ID: 31
Count: 2
Last updated: 2010-11-24 14:50:05
Shoutz to ikelos for helping me optimize this :-)
References:
Into the Boxes issue 0x0 http://intotheboxes.wordpress.com/2010/01/01/into-the-boxes-issue-0x0/
RegRipper http://regripper.wordpress.com/
Tuesday, April 05, 2011
What's the Difference? [A Brief Volatility 1.4 Plugin Tutorial]
So if you come to this blog, you've most likely heard of Volatility. You're probably also a user... maybe you've written some plugins, maybe not. Most people tend to fall into the latter category, though they may be be power users. Today I thought I'd go over a few things that might make it easier for people to start writing their own plugins for simple useful things, because even though the Volatility 1.4 isn't officially released doesn't mean that you can't enjoy it in the meantime :-)
A common way that people start their analysis is to look at differences in output of plugins that represent what the OS knows about (pslist/modules/connections/sockets etc) vs scanning for possible hidden/unlinked items. Examples of this can be seen in Jesse Kornblum's pstotal, Command Line Kung Fu's Making a Difference and MHL's psxview (which actually is very useful).
If you look at some of these examples, you might think to yourself that it's difficult to write a plugin to get a process difference, but it's really not! You can use inheritance to make your life easier.
PSList vs. PSScan2
Below is a complete plugin for printing out the difference between pslist and psscan2, which we will go over in detail.
First you need to import the plugin files that contain the classes you want to inherit into your plugin file. In this case PSList is defined in volatility/plugins/taskmods.py and PSScan2 is defined in volatility/plugins/filescan.py. You can see the import in lines (1-2). Now you have to define the class for your plugin (line 4). Try to give it a meaningful name for what it does, here we will name it PSDiff. Classes should be named in CamelCase. In the parentheses after the class name we will specify which classes we want to inherit. Since we want processes that are only found in psscan2 output, we will use the render_text output function of psscan2 without having to redefine it. Therefore, since we want for our new class to be more like psscan2, we choose this class to inherit. We specify it as filescan.PSScan2 because we had imported the plugin file as "filescan" and the class for pssscan2 is named "PSScan2".
Next on line 5, we add a description of what this plugin does as a multiline comment. Whatever you type here will appear in the help function when you run python vol.py [plugin] -h, or just python vol.py -h.
Lines 7-8 are the initialization and options section of the plugin. We are not adding any command line options to this plugin and are just initializing the PSScan2 class that we inherited.
Lines 10-19 define the calculate part of our plugin, or what we want the plugin to do. In this case we only want to print out processes that are found by psscan2 and not pslist, so should decide how to do that... Since processes should have unique process IDs (PIDs) to specify unique processes. So PIDs that are found in psscan2, but not in pslist will be printed.
Let's walk through the calculate function. First we gather all processes that pslist knows about (line 11). We call the taskmods.PSList class, give it our configuration (self._config) so that it can know what profile to use and call its calculate function, which returns eprocess objects (and really is just DllList's calculate function, but we'll ignore that for now). In line 12, we define an empty list to store PIDs from pslist in order to compare to psscan2's PIDs. Lines 13-14 collect all the PIDs pslist knows about.
Now lines 16-19 repeat the process for psscan2 except that instead of collecting PIDs into a list, we check to see if the PID we've encountered is already in the list of PIDs from pslist. If it isn't, then we yield the task that contains that PID so that it will be caught by psscan2's render_text function and output onto the screen.
The output? Here you can see what it looks like on a Windows 7 image:
The only difference in this case seems to be exited processes.
Here you can see a run on Moyix's ds_fuzz image:
Suppose you are concerned that a PID could have been overwritten somehow (DKOM). You could rewrite the plugin to use _EPROCESS offsets instead of PIDs for a check:
The changes are in lines 12, 14 and 18. The idea is the same as our PID plugin above, only with offsets. So we rename our list to offsets to make it clearer (line 12). We append the physical address of where our _EPROCESS object is found (line 14), this is because scanners like psscan2 only output physical addresses so we want to make sure that the addresses from pslist are the same. In line 18 we check to see if our _EPROCESS object offset found by psscan2 is already found by pslist and if not we yield it so that its information will be printed. Output is the same as what we saw above for our two test images.
Conclusion
So there you have it. You can use the same idea for comparing output from modules and modscan, connections and connscan2, sockets and sockscan or files and filescan etc... (I'm leaving this as an exercise for the reader ;-)).
You can check also out the references below for further reading on Python and Volatility. Make sure to read the Volatility Plugin Writers Guide that Mike Auty and Scudette put together.
Update: I just noticed that MHL also gave the Command Line Kung Fu crew a psdiff example. You can check out another way of doing things over there.
Update 2: I just updated the code to work with the current changes in the svn (we moved psscan2 to filescan).
References
Google Python Class http://code.google.com/edu/languages/google-python-class/
Python 2.7 Tutorial http://docs.python.org/tutorial/
Volatility Plugin Writers Guide http://code.google.com/p/volatility/wiki/PluginWritersGuide
A common way that people start their analysis is to look at differences in output of plugins that represent what the OS knows about (pslist/modules/connections/sockets etc) vs scanning for possible hidden/unlinked items. Examples of this can be seen in Jesse Kornblum's pstotal, Command Line Kung Fu's Making a Difference and MHL's psxview (which actually is very useful).
If you look at some of these examples, you might think to yourself that it's difficult to write a plugin to get a process difference, but it's really not! You can use inheritance to make your life easier.
PSList vs. PSScan2
Below is a complete plugin for printing out the difference between pslist and psscan2, which we will go over in detail.
1 import volatility.plugins.taskmods as taskmods
2 import volatility.plugins.filescan as filescan
3
4 class PSDiff(filescan.PSScan2):
5 """Print processes found in psscan2, but not in pslist"""
6
7 def __init__(self, config, *args):
8 filescan.PSScan2.__init__(self, config, *args)
9
10 def calculate(self):
11 pslist = taskmods.PSList(self._config).calculate()
12 pids = []
13 for task in pslist:
14 pids.append(task.UniqueProcessId.v())
15
16 psscan = filescan.PSScan2.calculate(self)
17 for task in psscan:
18 if task.UniqueProcessId.v() not in pids:
19 yield task
First you need to import the plugin files that contain the classes you want to inherit into your plugin file. In this case PSList is defined in volatility/plugins/taskmods.py and PSScan2 is defined in volatility/plugins/filescan.py. You can see the import in lines (1-2). Now you have to define the class for your plugin (line 4). Try to give it a meaningful name for what it does, here we will name it PSDiff. Classes should be named in CamelCase. In the parentheses after the class name we will specify which classes we want to inherit. Since we want processes that are only found in psscan2 output, we will use the render_text output function of psscan2 without having to redefine it. Therefore, since we want for our new class to be more like psscan2, we choose this class to inherit. We specify it as filescan.PSScan2 because we had imported the plugin file as "filescan" and the class for pssscan2 is named "PSScan2".
Next on line 5, we add a description of what this plugin does as a multiline comment. Whatever you type here will appear in the help function when you run python vol.py [plugin] -h, or just python vol.py -h.
Lines 7-8 are the initialization and options section of the plugin. We are not adding any command line options to this plugin and are just initializing the PSScan2 class that we inherited.
Lines 10-19 define the calculate part of our plugin, or what we want the plugin to do. In this case we only want to print out processes that are found by psscan2 and not pslist, so should decide how to do that... Since processes should have unique process IDs (PIDs) to specify unique processes. So PIDs that are found in psscan2, but not in pslist will be printed.
Let's walk through the calculate function. First we gather all processes that pslist knows about (line 11). We call the taskmods.PSList class, give it our configuration (self._config) so that it can know what profile to use and call its calculate function, which returns eprocess objects (and really is just DllList's calculate function, but we'll ignore that for now). In line 12, we define an empty list to store PIDs from pslist in order to compare to psscan2's PIDs. Lines 13-14 collect all the PIDs pslist knows about.
Now lines 16-19 repeat the process for psscan2 except that instead of collecting PIDs into a list, we check to see if the PID we've encountered is already in the list of PIDs from pslist. If it isn't, then we yield the task that contains that PID so that it will be caught by psscan2's render_text function and output onto the screen.
The output? Here you can see what it looks like on a Windows 7 image:
$ python vol.py -f win7.dd --profile=Win7SP0x86 psdiff
Volatile Systems Volatility Framework 1.4_rc1
Offset Name PID PPID PDB Time created Time exited
---------- ---------------- ------ ------ ---------- ------------------------ ------------------------
0x3eac6030 SearchProtocol 2448 1168 0x3ecf15c0 2010-06-16 23:30:52 2010-06-16 23:33:14
0x3eb10030 SearchFilterHo 1812 1168 0x3ecf1480 2010-06-16 23:31:02 2010-06-16 23:33:14
0x3f0576a0 svchost.exe 2836 508 0x3ecf15c0 2010-06-16 17:02:34 2010-06-16 17:08:43
0x3faa66e8 dllhost.exe 948 628 0x3ecf1540 2010-06-16 23:32:15 2010-06-16 23:32:21
0x3fbcf920 dllhost.exe 3776 628 0x3ecf11e0 2010-06-16 23:32:09 2010-06-16 23:32:15
The only difference in this case seems to be exited processes.
Here you can see a run on Moyix's ds_fuzz image:
$ python vol.py -f ds_fuzz_hidden_proc.img psdiff
Volatile Systems Volatility Framework 1.4_rc1
Offset Name PID PPID PDB Time created Time exited
---------- ---------------- ------ ------ ---------- ------------------------ ------------------------
0x0181b748 alg.exe 992 660 0x08140260 2008-11-15 23:43:25
0x0185dda0 cmd.exe 940 1516 0x081401a0 2008-11-26 07:43:39 2008-11-26 07:45:49
0x018af020 taskmgr.exe 808 620 0x08140280 2008-11-26 07:45:22 2008-11-26 07:45:40
0x019456e8 csrss.exe 592 360 0x08140040 2008-11-15 23:42:56
0x01946020 svchost.exe 828 660 0x081400c0 2008-11-15 23:42:57
0x019467e0 services.exe 660 616 0x08140080 2008-11-15 23:42:56
0x0194f658 svchost.exe 1016 660 0x08140100 2008-11-15 23:42:57
0x019533c8 svchost.exe 924 660 0x081400e0 2008-11-15 23:42:57
Suppose you are concerned that a PID could have been overwritten somehow (DKOM). You could rewrite the plugin to use _EPROCESS offsets instead of PIDs for a check:
1 import volatility.plugins.taskmods as taskmods
2 import volatility.plugins.filescan as filescan
3
4 class PSDiff(filescan.PSScan2):
5 """Print processes found in psscan2, but not in pslist"""
6
7 def __init__(self, config, *args):
8 filescan.PSScan2.__init__(self, config, *args)
9
10 def calculate(self):
11 pslist = taskmods.PSList(self._config).calculate()
12 offsets = []
13 for task in pslist:
14 offsets.append(task.obj_vm.vtop(task.obj_offset))
15
16 psscan = filescan.PSScan2.calculate(self)
17 for task in psscan:
18 if task.obj_offset not in offsets:
19 yield task
The changes are in lines 12, 14 and 18. The idea is the same as our PID plugin above, only with offsets. So we rename our list to offsets to make it clearer (line 12). We append the physical address of where our _EPROCESS object is found (line 14), this is because scanners like psscan2 only output physical addresses so we want to make sure that the addresses from pslist are the same. In line 18 we check to see if our _EPROCESS object offset found by psscan2 is already found by pslist and if not we yield it so that its information will be printed. Output is the same as what we saw above for our two test images.
Conclusion
So there you have it. You can use the same idea for comparing output from modules and modscan, connections and connscan2, sockets and sockscan or files and filescan etc... (I'm leaving this as an exercise for the reader ;-)).
You can check also out the references below for further reading on Python and Volatility. Make sure to read the Volatility Plugin Writers Guide that Mike Auty and Scudette put together.
Update: I just noticed that MHL also gave the Command Line Kung Fu crew a psdiff example. You can check out another way of doing things over there.
Update 2: I just updated the code to work with the current changes in the svn (we moved psscan2 to filescan).
References
Google Python Class http://code.google.com/edu/languages/google-python-class/
Python 2.7 Tutorial http://docs.python.org/tutorial/
Volatility Plugin Writers Guide http://code.google.com/p/volatility/wiki/PluginWritersGuide
Monday, April 04, 2011
OT: Maze Generator Update
Since my QC (venus) website is no longer active, I thought I'd put the files for a maze generator some place where they can be accessed, especially since I have received emails about it... Here is the original information that was on venus before it disappeared:
Maze Generator Using Disjoint Sets
I recently went through several files of mine that had been stored away from my undergrad days. So I thought I might share them. Someone might like them. I have not changed any of the code since it was first written. I have only changed the formatting of a couple of files to make them easier to read and modified the comment header slightly (also for readability). Everything is well commented, which was my style at the time :-) Hopefully I have not erased anything important as I was doing these modifications, but I have no patience to test it at the moment. Oh, and I added a GPL for my code only, just in case (though no one will really want this... :-P )
This particular project is from Prof Stewart Weiss' CS 335 class, and consisted of writing a program that would generate mazes. It was compiled under Visual Studio 6.0 C++. We had studied Disjoint Sets in our class and were allowed to use code from Mark Allen Weiss' book from which we were studying. In addition to printing out to a text file, for extra credit we could output a graphical representation of the maze. For this I used code from Owen L. Astrachan's book which I think is from CMU Graphics. Two example outputs can be seen below:
The idea is fairly simple. The maze is broken up into cells. We will use the idea of disjoint sets: in the beginning each cell is in its own set. Cells are randomly chosen to remove a wall (and one of the four walls is also randomly chosen) and as the wall is removed, the cell and its new neighbor are then placed in the same set. You keep doing this until all cells are within the first (entry) cell's set. At this point you have a maze.
You should make sure that once a cell is in the main (entry cell's) set, it should
never be picked again to remove wall. You also have to be careful not
to remove the outer border walls, thus creating alternate exits :-)
The disjoint sets class was modified from the original given in the book. There was a problem with the find() function so it was changed. Also, I added extra functions to make it fit with the maze class. I also created a vector of cells for the maze (see Cell class and Maze class below). I would have done things differently if I were doing writing this now, but this was in the beginning of my programming experience.
I created a Cell class to represent each cell of the maze. This way I could control the walls of the cells and keep track of which walls were still up or down when I printed out the maze.
Next I wrote a Maze class to keep track of all of the cells. At first I thought to implement this using a 2-dimensional array, but ultimately decided to use a linear vector (defined in DisjSets) folded onto itself. There is also a list used to contain all cells of the maze. This is not the maze itself, but rather the cells that have not yet been placed into the main set in order to create a maze. I did this to cut down on run time because you do not want to remove walls from cells that have already become part of the main set and randomly picking cells most likely leads to picking cells that have already been chosen (especially towards the end). So keeping a pool of possible choices was the only logical thing to do to cut down on run time.
Now for the main part of the program. At the time I was obsessed
with making the main() function as small as possible:
Granted it could have been smaller... :-) It basically loops forever creating mazes of whatever size (I think 50x60 is the max) is requested and stops when the user wants to leave. The code is NOT perfect. Just glancing over ASSN3Main.cpp, I see a buffer overflow error could occur in the getMazeInfo() function. Plus there were better ways now of dealing with the graphics. (Yes I COULD fix it, but then I would find other things and before you know it this would explode into a full time project...Ok. Maybe I'm exaggerating). Perhaps some day when I have more time I will rewrite this little application. It's kinda fun to create mazes...
I am releasing all of the code in gzip files as well as a precompiled executable. You can use 7zip to open the files. If you use the executable, you will see a message box saying something about how this was compiled with the student version and can't be used as commercial software or some such. Just push Ok and you're set. After you input the dimensions and the name of the output file to which you would like the maze saved, a graphical window will pop up. Click it with the mouse and the maze should display. You have to push ESC to get out of the graphical maze window.
Hopefully I have managed to include all of the code that is needed. Let me know if something is missing.
Maze Generator Using Disjoint Sets
I recently went through several files of mine that had been stored away from my undergrad days. So I thought I might share them. Someone might like them. I have not changed any of the code since it was first written. I have only changed the formatting of a couple of files to make them easier to read and modified the comment header slightly (also for readability). Everything is well commented, which was my style at the time :-) Hopefully I have not erased anything important as I was doing these modifications, but I have no patience to test it at the moment. Oh, and I added a GPL for my code only, just in case (though no one will really want this... :-P )
This particular project is from Prof Stewart Weiss' CS 335 class, and consisted of writing a program that would generate mazes. It was compiled under Visual Studio 6.0 C++. We had studied Disjoint Sets in our class and were allowed to use code from Mark Allen Weiss' book from which we were studying. In addition to printing out to a text file, for extra credit we could output a graphical representation of the maze. For this I used code from Owen L. Astrachan's book which I think is from CMU Graphics. Two example outputs can be seen below:
- Other outputs include (for the two unknowns,
- 5X5.txt
- 25X40.txt
- 40X30.txt
- unknown dimensions 1
- unknown dimensions 2
sorry I forgot what I punched in and have no patience to create more
mazes or count cells):
The idea is fairly simple. The maze is broken up into cells. We will use the idea of disjoint sets: in the beginning each cell is in its own set. Cells are randomly chosen to remove a wall (and one of the four walls is also randomly chosen) and as the wall is removed, the cell and its new neighbor are then placed in the same set. You keep doing this until all cells are within the first (entry) cell's set. At this point you have a maze.
You should make sure that once a cell is in the main (entry cell's) set, it should
never be picked again to remove wall. You also have to be careful not
to remove the outer border walls, thus creating alternate exits :-)
The disjoint sets class was modified from the original given in the book. There was a problem with the find() function so it was changed. Also, I added extra functions to make it fit with the maze class. I also created a vector of cells for the maze (see Cell class and Maze class below). I would have done things differently if I were doing writing this now, but this was in the beginning of my programming experience.
- Here are the disjoint sets files
- DisjSets.h
- DisjSets.cpp
I created a Cell class to represent each cell of the maze. This way I could control the walls of the cells and keep track of which walls were still up or down when I printed out the maze.
Next I wrote a Maze class to keep track of all of the cells. At first I thought to implement this using a 2-dimensional array, but ultimately decided to use a linear vector (defined in DisjSets) folded onto itself. There is also a list used to contain all cells of the maze. This is not the maze itself, but rather the cells that have not yet been placed into the main set in order to create a maze. I did this to cut down on run time because you do not want to remove walls from cells that have already become part of the main set and randomly picking cells most likely leads to picking cells that have already been chosen (especially towards the end). So keeping a pool of possible choices was the only logical thing to do to cut down on run time.
Now for the main part of the program. At the time I was obsessed
with making the main() function as small as possible:
int main(){
string resp;
while(true){
getMazeInfo();
cout<<"To quit press 'q', otherwise press a key"<<endl;
cin>>resp;
if(resp=="q")
break;
}//end while
return 0;
Granted it could have been smaller... :-) It basically loops forever creating mazes of whatever size (I think 50x60 is the max) is requested and stops when the user wants to leave. The code is NOT perfect. Just glancing over ASSN3Main.cpp, I see a buffer overflow error could occur in the getMazeInfo() function. Plus there were better ways now of dealing with the graphics. (Yes I COULD fix it, but then I would find other things and before you know it this would explode into a full time project...Ok. Maybe I'm exaggerating). Perhaps some day when I have more time I will rewrite this little application. It's kinda fun to create mazes...
- The main code:
- ASSN3Main.cpp
I am releasing all of the code in gzip files as well as a precompiled executable. You can use 7zip to open the files. If you use the executable, you will see a message box saying something about how this was compiled with the student version and can't be used as commercial software or some such. Just push Ok and you're set. After you input the dimensions and the name of the output file to which you would like the maze saved, a graphical window will pop up. Click it with the mouse and the maze should display. You have to push ESC to get out of the graphical maze window.
Hopefully I have managed to include all of the code that is needed. Let me know if something is missing.
Subscribe to:
Posts (Atom)