- Vol-users - volatilityfoundation.org

A Week of Volatility Events in October in Arlington, VA

by Andrew Case

We are very excited to announce that we (The Volatility Foundation) are hosting a week of Volatility events in October in Arlington, VA! The week will start with our From the Source event on Monday October 21st. FTS is a one-day conference with speakers across two tracks, and we have chosen speakers from across the industry who have recently published ground-breaking research in the areas of memory forensics, malware analysis, threat intelligence, and other related technical fields. The day will conclude at the International Spy Museum where we have booked out the entire venue for our attendees to network and enjoy. All proceeds from this event will be donated to Connect Our Kids, a 501(c)(3) nonprofit that is pioneering technology to find families, build connections, and create community for children in the foster care system. From Tuesday the 22nd through Friday the 25th, we will be hosting the first offering of our popular Malware and Memory Forensics with Volatility training that is focused exclusively on Volatility 3. This event will allow attendees to be in the first set of students to learn Volatility 3 directly from the core development team. We have also significantly updated the course curriculum and created many new labs. Those who register for this training will receive complimentary access to FTS. Full details of both events can be found here: https://volatilityfoundation.org/from-the-source-memory-forensics-training/ Please let us know if you have any questions, and we are looking forward to seeing many of our community members in October! -- The Volatility Team

7 months, 4 weeks

1
0
0 0

The 12th Annual Volatility Plugin Contest is Open!

by Andrew Case

The 2024 Volatility Plugin Contest is officially open for submissions! This is your opportunity to directly contribute to the open-source forensics community and put groundbreaking capabilities into the hands of digital investigators. Gain industry-wide visibility for your work, contribute to an important open-source project, and win cash, swag, and other great prizes! The contest is designed to encourage research and development in the field of memory analysis – a critical field given the prevalence of memory-only payloads, malware, and rootkits. Submissions will be accepted until December 31, 2024. Full details can be found on our announcement page: https://volatilityfoundation.org/volatility-plugin-contest/ We are looking forward to another year of creative submissions! -- The Volatility Team

8 months, 1 week

1
0
0 0

In-person Malware and Memory Forensics Training with Volatility 3!

by Andrew Case

We are very excited that, for the first time, we are hosting an in-person, public offering of our popular Malware and Memory Forensics Training focused solely on Volatility 3! This training takes place October 22–25, 2024, in Arlington, VA. This course will allow students to learn the latest version of the Volatility framework directly from members of the core development team. Students will also be the first to experience many new lecture sessions and labs that have been incorporated into the course. As an added bonus, students who register for this in-person training will receive a complimentary pass to our “From the Source” event taking place on October 21, 2024. For full information on the course and From the Source, please see our recent blog post: https://volatilityfoundation.org/in-person-malware-and-memory-forensics-tra… We are looking forward to seeing many of our community members this October in Arlington! -- The Volatility Team

8 months, 4 weeks

1
0
0 0

Announcing From The Source from the Volatility Foundation

by Andrew Case

In celebration of the 10th anniversary of The Art of Memory Forensics and our recent push for Volatility 3 feature parity, we are excited to announce that we are hosting the first Volatility Foundation conference, From the Source (FTS) , which will be held in Arlington, VA on October 21, 2024! This event is an intimate one-day summit offering a unique opportunity to connect in person with pioneering researchers and practitioners who work on the most advanced digital investigations. The conference agenda consists of two parallel tracks: one track is focused on the “makers” who build the open-source tools relied upon by modern digital investigators; the second track highlights the “hunters” who have discovered some of the biggest intrusions of the past year. Unlike most conferences in cybersecurity these days, we wanted to return the focus to the people who actually do the technical work! Be sure to follow @Volatility on social media, as we will be announcing an exciting roster of talks over the next couple of weeks. Join industry-leading digital investigators from commercial, academic, and government organizations from around the world who are looking for technical content about digital investigations. As a non-profit charitable event, 100% of the proceeds of the registration fee will be donated to “Connect Our Kids”, which leverages technology to help vulnerable children and their families. As contributors to Volatility and members of the Volatility community, we wanted to extend an early VIP registration in appreciation of the years of contributions and support! - To register for From The Source: https://events.humanitix.com/from-the-source-hosted-by-the-volatility-found… - Use access code VOLCOMMUNITY17 to obtain a discounted, early access rate. - Note that the early registration discount will expire on July 15, 2024. - There are a limited number of tickets, so register early! For the remainder of the week following the summit, the Volatility core development team will also be hosting the first offering of the Malware & Memory Forensics Training course in person that is focused exclusively on Volatility 3. - To register for the Malware & Memory Forensics Training on Volatility 3: https://events.humanitix.com/malware-and-memory-forensics-training-on-volat…. - It may show it is Sold out; just choose the “Join waitlist” option to begin the registration process. - Registration for this in-person training includes a complimentary pass to the conference. Please let me know if you have any questions or concerns.. We hope you will consider attending, and we look forward to seeing you! -- The Volatility Team

9 months, 3 weeks

1
0
0 0

New Blog Post: Memory Forensics R&D Illustrated: Recovering Raw Sockets on Windows 10+

by Andrew Case

We just published a new blog post that details our effort to recover raw sockets on Windows 10+ systems. This included reversing of the Windows network stack, verification of recovery across all operating system versions, and creation of a new Volatility 3 plugin that automates the recovery. https://volatility-labs.blogspot.com/2023/08/memory-forensics-r-d-illustrat… We hope that you enjoy it! -- The Volatility Team

1 year, 8 months

1
0
0 0

Volatility Training headed to Amsterdam in October!

by Andrew Case

We are excited to announce that our Malware and Memory Forensics training course is headed to Amsterdam in October! Complete details can be found on our blog post announcing the course: https://volatility-labs.blogspot.com/2023/06/malware-and-memory-forensics-t… This course is completely updated to cover the latest malware and threats against Windows 10 and 11 as well as the latest versions of Linux and Apple Silicon devices. If you would like to see an example of the research presented in this course, then check out our recent blog post on detecting hidden services in Windows 10+ memory samples: https://volatility-labs.blogspot.com/2023/03/memory-forensics-r-d-illustrat… We hope to see many of you October! PS: We will be in Vegas this summer, so please let us know if you would like to meet up with some of the developers! -- The Volatility Team

1 year, 10 months

1
0
0 0

LSU is hiring Applied Cybersecurity Professors

by Andrew Case

The Computer Science department at Louisiana State University (LSU) is currently hiring for many faculty positions related to applied cyber security. Courses taught inside this department include reverse engineering, malware analysis, binary exploitation, memory forensics and other intensive courses related to incident response and offensive security. Ideal candidates will have significant experience with deeply technical areas of cybersecurity. LSU was recently granted the CAE-CO designation and is one of only 21 schools nation-wide to hold it as it is the most technical designation granted by NSA and DHS. The department also runs a large SFS program for cyber security students. If you are interested in one of these positions, then please see the following link. I also ask my industry contacts to please spread the word within academic communities that you have access to: https://lsu.wd1.myworkdayjobs.com/en-US/LSU/job/3325-Patrick-F-Taylor-Hall/… The cybersecurity effort at LSU has strong support from the highest levels of the school and is rapidly expanding – so now is the perfect time to join. PS: I am not employed by LSU, but do work very closely with the CS department to ensure the courses are relevant to industry and rigorous enough for students to leave with real-world, hands-on experience. If you have questions related to the position, then please direct them to Dr. Golden Richard at LSU: https://www.cct.lsu.edu/~golden/ Thanks, Andrew

2 years

1
0
0 0

New Volatility Blog Post: Detecting Hidden Windows Services

by Andrew Case

We just published a blog post on creating new Volatility 3 plugins to detect hidden services on Windows: https://volatility-labs.blogspot.com/2023/03/memory-forensics-r-d-illustrat… The post covers background on how malware abuses services, how services are tracked on a live system, and how we developed our new plugins. Feedback and comments encouraged! — The Volatility Team

2 years, 1 month

1
0
0 0

FTK Imager

by wd s

Is it still true FTK Imager does not get a complete capture? I remember it was a problem for years. Some of my colleagues promote using it.

2 years, 2 months

4
3
0 0

The Return of In-Person Volatility Malware and Memory Forensics Training!

by Andrew Case

We are excited to announce that we are resuming our in-person training course! The first in-person course of 2023 will take place May 8–12 in Reston, VA. We are also exploring potential venues for a Fall 2023 course in Europe. Full information on the course, including the many new updates being added for 2023, can be found on our blog post here: https://volatility-labs.blogspot.com/2023/01/the-return-of-in-person-volati… We are really looking forward to resuming in-person training, and we hope to see many of you in Reston. Please let us know if you have any questions. -- The Volatility Team

2 years, 2 months

1
0
0 0

Gauging interest in a return to in-person Memory Forensics trainings

by Andrew Case

Hello All, We are writing to gauge interest in our team resuming in-person Malware and Memory Forensics trainings. We have not held one of these since early 2020 but have started to receive inquiries about when they would return. To help with our decision making, we have put together a survey to help shape a potential in-person training in the USA in the Fall. If you have interest in attending this course, or if would like to suggest alternative options, then please fill out the survey here: https://www.memoryanalysis.net/training-2022-survey The survey will close next Friday on April 29th. We would like to note that our self-paced, online training will remain in place even when in-person trainings resume. https://volatility-labs.blogspot.com/2021/01/malware-and-memory-forensics-t… Please let us know if you have any questions or concerns. Also, our mailing lists were having issues so we needed to resend this message. We apologize if you receive it multiple times. Thanks, The Volatility Team

2 years, 12 months

1
0
0 0

Gauging interest in a return to in-person Memory Forensics trainings

by Andrew Case

Hello All, We are writing to gauge interest in our team resuming in-person Malware and Memory Forensics trainings. We have not held one of these since early 2020 but have started to receive inquiries about when they would return. To help with our decision making, we have put together a survey to help shape a potential in-person training in the USA in the Fall. If you have interest in attending this course, or if would like to suggest alternative options, then please fill out the survey here: https://www.memoryanalysis.net/training-2022-survey The survey will close next Friday on April 29th. We would like to note that our self-paced, online training will remain in place even when in-person trainings resume. https://volatility-labs.blogspot.com/2021/01/malware-and-memory-forensics-t… Please let us know if you have any questions or concerns. Thanks, The Volatility Team

3 years

1
0
0 0

DFRWS USA 2022 Call for Papers

by Andrew Case

The Call for Papers for the 2022 DFRWS USA conference is open! Since 2005, DFRWS has been one of the main venues for publishing cutting edge research and techniques related to memory forensics. It is also a great venue to publish a peer-reviewed paper in an academic setting that understands the value of memory forensics and malware analysis. If you are interested in submitting, then please see this year's CFP: https://dfrws.org/dfrws-usa-2022-call-for-papers-is-open/ Thanks, Andrew

3 years, 4 months

1
0
0 0

Memory Forensics R&D Illustrated: Detecting Mimikatz's Skeleton Key Attack

by Andrew Case

We (the Volatility team) are often asked about what the memory forensics R&D process looks like, and how the abuse of an API by malware or a new code injection technique can be successfully uncovered by a Volatility plugin. To illustrate this process, we just published a blog post that takes you from analyzing a potent target - the Skeleton Key attack of Mimikatz - through developing a new Volatility 3 plugin that can automatically detect it: https://volatility-labs.blogspot.com/2021/10/memory-forensics-r-illustrated… Feedback and comments are greatly appreciated. We hope you enjoy the post!

3 years, 6 months

1
0
0 0

Malware and Memory Forensics Training Goes Virtual!

by Andrew Case

We are very excited to announce that our malware and memory forensics training course is now available online! Full information can be found here: https://volatility-labs.blogspot.com/2021/01/malware-and-memory-forensics-t… This course deeply covers all aspects of memory analysis and ensures that you are ready to take on modern threats. If you have any questions then please let us know. - The Volatility Team

4 years, 2 months

1
0
0 0

New Blog Post: When Anti-Virus Engines Look Like Kernel Rootkits

by Andrew Case

We just posted a new writeup on a common analysis task required when investigating real world systems - deciphering hooks placed by AV/EDR vs those placed by malware The post can be found here: https://volatility-labs.blogspot.com/2020/05/when-anti-virus-engines-look-l… Please let us know if you have any questions or comments, and we hope you enjoy the read!

4 years, 11 months

1
0
0 0

Digital Surveillance and Cyber-Espionage at Scale

by Andrew Case

At a recent Volexity Cyber Security Session, Steven Adair gave a presentation on how OceanLotus lures and targets its victims, including malware, fake news websites and organizations, and fake social media campaigns. If you want to see what real nation-state level targeting looks like then check out his talk: https://www.volexity.com/company/resources/digital-surveillance-and-cyberes…

5 years

1
0
0 0

My recorded talk on Windows 10 DFIR challenges

by Andrew Case

Windows 10 brought about significant changes in how file system and memory analysis must be performed. I explore all of these changes in a recorded talk at the last Volexity CyberSecurity Session: https://www.volexity.com/company/resources/windows-10-dfir-challenges-andre… There is no signup required to watch or any other marketing nonsense, just the video and the accompanying slides. Feedback and questions are welcome, and I hope you enjoy!

5 years

1
0
0 0

We (Volexity) are looking for a Malware Reverse Engineer

by Andrew Case

We at Volexity are looking for a Malware Reverse Engineer to join our team. The ideal candidate will have several years of experience in analyzing real-world malware and attacker toolsets as well as be familiar with the wider threat-intel and DFIR landscapes. The job description can be found on our website: https://www.volexity.com/company/careers/malware-reverse-engineer/ Volexity was founded by leading experts in the threat intelligence realm as well as several of the core Volatility developers. This includes Michael Ligh and myself. Our work centers on providing products, services, and training related to memory analysis, incident response, and threat intel. Our main client focus is highly targeted organizations across private industry, government, and NGOs. Highlights of several of our efforts are on our blog, such as the recent Exchange vulnerability: https://www.volexity.com/blog/2020/03/06/microsoft-exchange-control-panel-e… Digital targeting of China's minority Uyghur population: https://www.volexity.com/blog/2019/09/02/digital-crackdown-large-scale-surv… And attack campaigns related to the 2016 United States election: https://www.volexity.com/blog/2016/11/09/powerduke-post-election-spear-phis… If this type of work interests you, then please submit your information on the career page linked above. Please do NOT reply to this email with your resume/application.

5 years, 1 month

1
0
0 0

Memory Forensics Training by the Volatility Team headed to San Diego!

by Andrew Case

We wanted to remind everyone that we are now about two months away from our first public west coast training in several years. This is the timeframe where we start to get many requests so if you want a guaranteed spot then please reach out to us ASAP. We will be in San Diego the week of March 9th for five days of Malware and Memory Forensics training led by the Volatility Team. Full information can be found here: https://volatility-labs.blogspot.com/2019/10/volatility-malware-and-memory-… If you can’t join us in San Diego then we will also be hosting 3 other public trainings this year: - April 20-24, Herndon, VA - September 21-25, Amsterdam, NL - October 12-16, Herndon, VA And if you missed some of our last emails, we recently announced the Volatility 3 Public Beta: https://volatility-labs.blogspot.com/2019/10/announcing-volatility-3-public… As well as the results of the 2019 Volatility Plugin and Analysis Contests: https://volatility-labs.blogspot.com/2019/11/results-from-2019-volatility-c… Please reach out to us if you have any questions, and we look forward to meeting many new students and Volatility users this year!

5 years, 3 months

1
0
0 0

Announcing the Volatility 3 Public Beta!

by Andrew Case

Two weeks ago, at OSDFCon, we presented the first beta release of Volatility 3, and we are now happy to announce this release officially! Volatility 3 is a complete rewrite of the framework and enables many new types of analysis. The first full release is slated for next summer, and we are hoping to inspire many community members to join us in developing, testing, and documenting the framework from now until then. Full details of the beta release, as well as ongoing and future work, can be found on our blog post: https://volatility-labs.blogspot.com/2019/10/announcing-volatility-3-public… Please let us know if you have any questions or comments. You can send those here or on our new Slack server: https://www.volatilityfoundation.org/slack — The Volatility Team

5 years, 5 months

1
0
0 0

Volatility training headed to San Diego, Herndon, and Europe in 2020!

by Andrew Case

We are very excited to announce our public training lineup for 2020! For the first time since 2016, we will be headed to the west coast - San Diego in March! We will also be running courses in Herndon in April and October and in Europe in September. Full information on the course, including locations, dates, and how to register can be found on our blog post: https://volatility-labs.blogspot.com/2019/10/volatility-malware-and-memory-… We looking forward to meeting many new students this year! — The Volatility Team

5 years, 6 months

1
0
0 0

Volatility 3 Public Beta and OSDFCon

by AAron Walters

Volatility Contributors, Many of you may have noticed that in a couple of weeks we will be giving a talk at OSDFCon titled “Volatility 3 Public Beta: The Insider’s Preview”. This presentation will be the first public introduction and pre-release of Volatility 3. A major motivation for this talk was to inspire and engage those members of the community who want to help us get Volatility 3 ready for its official launch! Getting to this initial milestone, while supporting users of the current stable version, has only been possible because of our amazing community! We are grateful for the contributions and for your patience over the last couple of years. As a show of appreciation, Volexity is hosting a special event on the evening of October 15th for the contributors of the Volatility Project. If you have contributed to the project at some point over the last 12 years and are attending OSDFCon or happen to be in the Northern Virginia area on the evening of October 15, please send me a note off list. Our goal is to get an initial head count by Tuesday, October 1st. We look forward to hearing from you! AAron Walters The Volatility Foundation

5 years, 6 months

1
0
0 0

Announcing the BSidesNOLA 2019 Speaker Lineup!

by Andrew Case

We are very excited to announce the speaker lineup for BSidesNOLA 2019! This year we will have 15 speakers across 3 tracks. The topics covered span digital forensics, malware analysis, threat hunting, penetration testing, and more. Full information on each talk and presenter can be found at: www.bsidesnola.com You will also find registration, venue, and sponsorship information there as well. Please register early, if possible, as it greatly helps us in the planning of the event. We will be announcing the keynote speaker next week so be sure to look for that! We hope to see you all on October 26th!

5 years, 7 months

1
0
0 0

Windows 10 DFIR Challenges

by Andrew Case

If you are going to be in the Reston, VA area on Sept 25th, then you should consider coming out to our meet up. I will be presenting my recent talk from BSides Las Vegas, “Windows 10 DFIR Challenges”, and Steven Adair will be giving his RSA talk on “Digital Surveillance and Cyberespionage at Scale”. Not to mention, many of the Volatility developers will also be hanging out. It would be great to catch up. Full information can be found here: https://www.meetup.com/Volexity-Cyber-Sessions/events/264350470/ Thanks, Andrew

5 years, 7 months

1
0
0 0

Announcing BSidesNOLA 2019!

by Andrew Case

We are very happy to announce that Security BSidesNOLA 2019 will take place on Saturday, October 26th! This will be our 7th year, and we are hoping to again break our attendance record. We have switched venues to a beautiful hotel inside the French Quarter that we believe will allow for our best event yet. Registration and the CFP are both now open. Full details can be found at http://www.bsidesnola.org. We are also actively looking for sponsors. If you or your company are interested, then please email bsidesnola(a)gmail.com for a sponsorship packet. We are looking forward to seeing you all in October! — The BSidesNOLA Team

5 years, 8 months

1
0
0 0

Upcoming Memory Forensics Trainings in Herndon and London

by Andrew Case

We wanted to send a quick reminder that our final public training offerings for 2019 are rapidly approaching. The first will be in London during the week of September 9-13th and the second will be in Herndon during the week of October 14-18th. Please contact us ASAP if you wish to attend either of these classes. Full information can be found here: https://volatility-labs.blogspot.com/2018/11/malware-and-memory-forensics-t… - The Volatility Team

5 years, 8 months

1
0
0 0

Volatility 3 Public Beta: The Insider’s Preview

by AAron Walters

If you are interested in learning more about Volatility 3 and getting access to the first public pre-release, please vote for the Volatility Development Team’s OSDFCon submission (#26. Volatility 3 Public Beta: The Insider’s Preview). Voting ends 6/26/2019. https://www.surveymonkey.com/r/osdfconvoting2019 OSDFCON SUBMISSION DETAILS Volatility 3 Public Beta: The Insider’s Preview Since its initial public release over a decade ago, Volatility has attracted one of the largest and most active communities of users and developers in the digital forensics industry. As a result of those contributions, it has become the world’s most advanced and widely used memory forensics platform. In the digital forensics research community, Volatility has served as the foundation of a thriving ecosystem that continues to facilitate the rapid transition of cutting-edge technologies into the hands of digital investigators across the globe. During the same period, the industry has continued to evolve the way that operating systems are developed, deployed, and maintained. Similarly, the skillsets of memory analysts and their preferred work flows have changed to meet a world with increasingly large volumes of complex data. To address these challenges, the Volatility development team has been actively architecting and developing an entirely new version of the framework, while simultaneously supporting users of the current stable version. This presentation will be the first public introduction and pre-release of Volatility 3. It will highlight how this new framework compares to previous versions of Volatility and other Volatility-based tools. The discussion will also highlight many new features and describe our new contributor focused license. Finally, we will discuss ways the community can help contribute to the official launch of Volatility 3! Thanks, AAron Walters The Volatility Foundation

5 years, 10 months

1
0
0 0

1 day left for OSDFCon Submissions

by Brian Carrier

The CFP deadline is tomorrow for the 10th Annual Open Source Digital Forensics Conference (OSDFCon). The conference will be held on Oct 16, 2019. There are openings for: * 10-minute short talks * 35-minute in-person talks * 35-minute remote talks * 3-hour hands on workshops https://www.osdfcon.org/2019-event/2019-call-for-presentations/ Please submit your ideas about open source tools you've developed, used, or want to exist. The event is 1-day long with 400+ attendees. It's the biggest open source digital forensics event and the biggest DFIR event in the Metro DC region. All you need to submit is an abstract and then we'll crowd source the agenda. thanks, brian

5 years, 10 months

1
0
0 0

Upcoming Memory Forensics Training in Reston

by Andrew Case

We wanted to send a reminder that our next Malware and Memory Forensics training offering will be in Reston in April. We are about 8 weeks away now and already have a number of seats filled. Our courses in the Reston/Herndon area generally sell out early so please contact us ASAP if you wish to attend. Full information can be found here: https://volatility-labs.blogspot.com/2018/11/malware-and-memory-forensics-t… We are looking forward to meeting many of you there!

6 years, 2 months

1
0
0 0

Test

by Jamie Levy

This is just a test, ignore.

6 years, 3 months

1
0
0 0

Announcing our memory forensics trainings for 2019!

by Andrew Case

We are excited to announce our public Malware and Memory Forensics training offerings for 2019! We will be headed back to Herndon in the Spring and to Herndon and London in the Fall. Full details of the training, including a list of newly updated material, can be found on our blog post: https://volatility-labs.blogspot.com/2018/11/malware-and-memory-forensics-t… We deeply appreciate your continued support for Volatility and our trainings, and we are excited for another great year of open source memory forensics research and development. -- The Volatility Team

6 years, 4 months

1
0
0 0

Extending the LiME Format

by Joe Sylve

Since there seems to be a renewed interest in LiME and it's format, I think it's time that we extend the format to include the storage of optional metadata. Anything that can be collected at acquisition time saves the need for scanning and other possibly more complex processes during analysis. Formats like AFF4 are great, but are too complex to implement in the kernel. I'd like to crowdsource opinions on how the LiME format should be extended. When contributing thoughts please keep the following in mind. - Changes to the format should not break existing parsers - To minimize the number of future changes, the enhancements should be as flexible as possible. For example, I've heard rumors that the LiME format is being used in acquisition tools that target more than just Linux, so I'd prefer a generic key/value store for metadata rather than any hardcoded solution. - Whatever we collect during acquisition time (at least in LiME) must be easily accessible from a kernel module What are your thoughts? What metadata should be collected? Obvious answers that come to mind are DTB, kernel virtual base address, and KASLR slide, but I'm sure there are more.

6 years, 5 months

1
0
0 0

Volatility at OSDFCON!

by Andrew Case

We wanted to send a quick note that we will have a sponsor table tomorrow at OSDFCON. Please come by and see us during the day and also during the conference social at night. If you are a previous training course alumni and/or a past Volatility contributor then please stop by as we will have some special edition swag for you: https://twitter.com/volatility/status/1052210342577795073 We will also be raffling a free seat for one of our 2019 trainings offerings: https://twitter.com/volatility/status/1050769125080006658 We are looking forward to seeing many of you tomorrow!

6 years, 6 months

1
0
0 0

Memory Forensics training in Herndon in October

by Andrew Case

Our last public Malware and Memory Forensics training course for 2018 is coming up soon. The class will run from Monday, October 15th through Friday, October 19th. Information on the course can be found at the following URLs: https://volatility-labs.blogspot.com/2018/02/malware-and-memory-forensics-t… https://www.memoryanalysis.net/memory-forensics-training This has been our largest class of the year for the last several years and has sold out early. If you are planning to attend then please contact us ASAP.

6 years, 7 months

1
0
0 0

Deadline for Volatility Plugin Contest and Volatility Analysis Contest Approaching!

by Andrew Case

We wanted to send a reminder as the deadline for both the Volatility Analysis Contest AND the Volatility Plugin Contest is approaching: https://volatility-labs.blogspot.com/2018/05/the-6th-annual-volatility-plug… The Plugin contest gives you the opportunity to showcase your research and development skills. The Analysis Contest lets you showcase your memory forensics skills against malware and real-world IR situations. Both contests have a number of prizes and a bunch of swag ready for the winners. We hope to see many great submissions, and we look forward to reviewing them all! Thanks, The Volatility Team

6 years, 7 months

1
0
0 0

Volatility profile for Solaris & AIX

by Brent Muir

Hi list, Apologies for the cross-post. Has anyone created a Volatility profile for Solaris or AIX that they would be willing to share? I am also searching for a way/tool to image RAM from Solaris and AIX operating systems. If anyone has any experience in this area please get it touch. Thanks, Brent Muir

6 years, 9 months

1
0
0 0

Reliable Memory Acquisition for Windows, Linux, macOS

by AAron Walters

As members of the Volatility mailing list, you know that memory acquisition has proven to be one of the most important and precarious aspects of digital investigations. Over the years, you have seen the Volatility team spend a lot of time troubleshooting issues that were ultimately caused by failed or corrupted acquisition attempts. You have also seen our colleague, George M. Garner, lead spirited debates about the reliability of proposed acquisition tools and techniques. With George’s untimely passing last summer, the industry not only lost one of the most robust Window’s acquisition tools, but it also lost an industry thought leader who held the forensics community to a higher standard. Unfortunately, many investigators still blindly trust free and commercial acquisition tools without understanding the associated risks and limitations. While these tools may be readily accessible, many are unsupported or have been effectively abandoned by their original developers who have moved on to pursue other projects. As an example, Google’s GRR project recently disabled their memory forensics capabilities because it was introducing instabilities, and it wasn’t being actively maintained. A recent empirical study also showed that most open source or commercial Windows memory acquisition tools either failed to collect or crashed systems with modern security features enabled. We can also share countless stories of investigators and law enforcement officers returning to their labs only to discover that their memory acquisitions had failed. There is a growing need for a reliable and actively supported memory acquisition capability across Windows, Linux, and macOS. If you follow us on twitter (@volatility) or have taken our training classes within the last couple of years, you have heard about Volexity’s Surge Collect. Surge Collect provides a reliable and commercially supported collection capability with flexible storage options. Surge Collect can also be easily integrated with Tanium, Carbon Black, and other enterprise software agents. It is currently in use by many of the largest federal and local law enforcement agencies around the world. Surge Collect is also actively used by leading incident response firms, technology companies, telecommunication providers, universities, Fortune companies, and branches of the military. If you are looking for a commercially supported acquisition solution with dedicated development and support teams for Windows, Linux, and macOS, I recommend you check out Volexity’s Surge Collect. Hopefully, this will FINALLY give investigators a reliable and flexible acquisition capability they can depend on and allow the Volatility team to focus more of our time on developing exciting new memory analysis capabilities! Thanks, AAron Walters Original author of Volatility Founder of The Volatility Foundation

6 years, 10 months

1
0
0 0

Malware and Memory Forensics Training Headed to Amsterdam

by Andrew Case

The next stop for our training course is Amsterdam in September. This will be our only public offering in Europe in 2018. Historically our courses have sold out around a month in advance, so please contact us ASAP if you wish to attend. For our US-based students, we will be back in Herndon in October. Full information on both offerings can be found here: https://volatility-labs.blogspot.com/2018/02/malware-and-memory-forensics-t… We look forward to meeting many new Volatility users at these events!

6 years, 10 months

1
0
0 0

The 6th Annual Volatility Plugin Contest and the Inaugural Volatility Analysis Contest!

by Andrew Case

We are excited to announce that the 2018 Volatility Plugin Contest and the inaugural Volatility Analysis Contest are now accepting submissions until October 1, 2018. Winners of each contest will receive over $2,500 in cash prizes and the highly coveted Volatility swag (t-shirts, stickers, etc.)! Full details can be found on our blog post: https://volatility-labs.blogspot.com/2018/05/the-6th-annual-volatility-plug… Please let us know if you have any questions, and good luck to all!

6 years, 11 months

1
0
0 0

Yara rule repository for use with Volatility

by Alex Bryant

I've found several repositories of Yara rules for scanning fie systems, but so far, none written for scanning memory. Does anyone know of (or have) a Yara rule collection for memory images? Thanks! --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

6 years, 11 months

1
0
0 0

Announcing the BSidesNOLA 2018 Speaker Lineup!

by Andrew Case

We are very excited to announce that the speaker lineup for BSidesNOLA 2018 is out! We have some of the best speakers in the industry in order to cover a variety of topics in digital forensics, incident response, malware analysis, and more. The full lineup can be found here: www.bsidesnola.com <http://www.bsidesnola.com/> Please register ahead of time if you wish to attend ($15), and please spread the word to your coworkers and friends. — The BSidesNOLA Team

7 years

1
0
0 0

Hunting Memory in Volatility Unified Output via Splunk

by C B

To all concerned, A coworker and I have authored an ingestion tool for Splunk called Ta-Volatility, https://splunkbase.splunk.com/app/3919/, that takes json formatted unified_outputs from volatility. As it stands right now, it can handle over 160 plugins across windows, linux and mac, and we're adding more every day. We are adding unified outputs to the standard plugins that do not have them, github PR #501 <https://github.com/volatilityfoundation/volatility/pull/501>. The app will support the latest version of volatility (volatilityfoundation or mutedmouse's fork, https://github.com/mutedmouse/ta-volatility) The app's setup page describes the required folder structure. The source by default is "volatility" and the index is main by default, although you can set this by adding index=<yourindex> in the inputs.conf file. Below is a sample sankey visualization from an analyzed windows 10 system's ingested pslist plugin output. Enjoy and please let us know if there is anything you would like added (aside from charts and dashboards - those are coming 😀 ). V/r, Chris

7 years

1
0
0 0

Memory Forensics Training headed to Herndon and Amsterdam!

by Andrew Case

We are excited to announce our full list of public trainings for 2018! There will be three offerings this year, including two in Herndon (Spring and Fall) and one in Amsterdam in September. Full information, including updates to the course for the new year, can be found on our blog post: https://volatility-labs.blogspot.com/2018/02/malware-and-memory-forensics-t… <https://volatility-labs.blogspot.com/2018/02/malware-and-memory-forensics-t…> Our classes tend to sell out early so please contact us as soon as you have interest in a particular offering. We look forward to meeting many new students this year! — The Volatility Team

7 years, 1 month

1
0
0 0

Registration & the CFP for BSidesNOLA 2018 are open!

by Andrew Case

We are pleased to announce that registration and the Call for Papers for BSidesNOLA 2018 are now open! Full information can be found at: http://www.bsidesnola.com This will be our 6th year, and we are expecting continued growth in attendance - our goal is to eclipse 250 attendees this year. We have also changed venues to the world famous Roosevelt Hotel, which is only a 1 minute walk from the French Quarter. We hope to see everyone at the event, and we are looking forward to many great talk submissions. If you would like to help spread the event on Twitter, then please RT this announcement: https://twitter.com/BSidesNOLA/status/956545409589108737 Finally, we are also now seeking sponsors. If your company is interested then please email bsidesnola [AT] gmail.com or reply privately to this email. Thanks, The BSidesNOLA Team

7 years, 2 months

1
0
0 0

The results of the 2017 Volatility Contest are in!

by Andrew Case

We are excited to announce that the results of the 2017 Volatility Plugin Contest are in: https://volatility-labs.blogspot.com/2017/11/results-from-5th-annual-2017-v… We had many novel submissions this year across a wide variety of operating systems, malware detection strategies, and userland application artifacts. Thanks to everyone who submitted and contributed new capabilities to open source memory forensics! Thanks, The Volatility Team

7 years, 5 months

1
0
0 0

Technical Details on OceanLotus' Attacks Targeting ASEAN, Asian Nations, the Media, and Human Rights Groups

by Andrew Case

We just published a blog post detailing the infrastructure, initial infection strategies, and payloads of the resurgent OceanLotus threat group: https://www.volexity.com/blog/2017/11/06/oceanlotus-blossoms-mass-digital-s… A follow up post detailing the phishing activity and malware infrastructure is coming soon. Comments welcome! -- Thanks, Andrew (@attrc)

7 years, 5 months

1
0
0 0

Recovering php eval code from memory with volatility

by Valter Santos

Hi guys, I'm trying to recover a php script from a suspected system. The file was stored in a tmpfs filesystem and i cannot recover it. In the php process (running from cli) i can see references to the script but can't find the code. The suspected system in running Debian 8.9: Linux version 3.16.0-4-amd64 (gcc version 4.8.4 (Debian 4.8.4-1) ) #1 SMP Debian 3.16.43-2+deb8u5 (2017-09-19). I've tried to use linux_tempfs to recover /dev/shm from memory but got some errors with volatility with no success: # ~/bin/vol26 --plugins=profiles --profile=LinuxDebian89x64 -d -f memory.dump linux_tmpfs -S 4 -D dump/ [...] WARNING : volatility.debug : NoneObject as string: Invalid offset 0 for dereferencing name as String WARNING : volatility.debug : NoneObject as string: Invalid offset 0 for dereferencing name as String WARNING : volatility.debug : NoneObject as string: Invalid offset 0 for dereferencing name as String WARNING : volatility.debug : NoneObject as string: Invalid offset 0 for dereferencing name as String WARNING : volatility.debug : NoneObject as string: Invalid offset 0 for dereferencing name as String The php process has pid 1234, using volatility linux_dump_map on that process I see the following strings in dumped file task.1234.0x7f003ddf3000.vma: /dev/shm/script.php(1) : eval()'d code0x7f003ddf303f /dev/shm/script.php(1) : eval()'d code0x7f003ddf8e2e /dev/shm/script.php(1) : eval()'d code0x7f003ddf952a /dev/shm/script.php(1) : eval()'d code0x7f003ddfa588 /dev/shm/script.php(1) : eval()'d code0x7f003ddfa7f3 I'm stuck now trying to recover the php eval'd code, any ideas? Thanks Valter

7 years, 6 months

1
0
0 0

Malware & Memory Forensics Training in 2018!

by Andrew Case

We are excited to announce that two of our public trainings for 2018 have now been scheduled! The first will be in April in Herndon, VA: https://www.memoryanalysis.net/single-post/2017/09/30/New-Event-in-Herndon-… The second will be in Herndon in October: https://www.memoryanalysis.net/single-post/2017/09/30/New-Event-in-Herndon-… We are also in the process of scheduling public trainings in Australia for Q1 2018 and Europe for Q3. We will send out an update when these are confirmed, but please contact us if you would like to be placed on the notification list for either course. To see some of the recent updates to the course, be sure to check out our blog post: https://volatility-labs.blogspot.com/2017/06/our-newly-updated-memory-foren… Also, we are continuing to have many repeat students - for which we are very grateful! If you are a previous student and wish to attend again, then please inquire with us about the repeat-student discount. Finally, if you will be around during OSDFCON in a few weeks then let us know if you would like to meet up as most of the team will be in town. -- The Volatility Team

7 years, 6 months

1
0
0 0

TCPScan

by Nathan Subra

Hello vol-users! I'm working on a forensics case where I have multiple memory scrapes with strange volatility output. This has down some rabbit holes and I'm at the point where signs are pointing to anti-forensics. This has led me to dig into how pool tag scanning works and I've found several articles referencing a apparently still yet unreleased (mentioned in 2014, and 2016) Volatility plugin called TCPScan which uses an alternative method (which uses methods that are not detailed). You can find references to the plugin here: https://scudette.blogspot.com/2014/02/anti-forensics-and- memory-analysis.html https://findingbad.blogspot.com/2016/09/forensic-analysis- of-anti-forensic.html Does anyone have access to or can anyone put me in touch with anyone who has access to this plugin? Or can anyone talk to the methods that it uses to scan for connections? Thanks, Nate Subra

7 years, 7 months

2
1
0 0

Some Help Please! ELF Segments in Memory

by Bridgey theGeek

Hi all, Hoping somebody can provide some comments re ELF files in memory. My ultimate question is: How can I find the .bss section of an ELF file in memory? But I have a more specific one. Consider the following output from a Volatility plugin I wrote which aims to parse the segments: Volatility Foundation Volatility Framework 2.6 # First we grab the proc_maps which are mapped to the process of interest (in this case, Xorg)... # This mimics the linux_proc_maps plugin Parsing proc maps... /usr/lib/xorg/Xorg r-x start=0x55d4ddda4000 end=0x55d4ddfe0000 length=0x23c000 /usr/lib/xorg/Xorg r-- start=0x55d4de1e0000 end=0x55d4de1e2000 length=0x2000 /usr/lib/xorg/Xorg rw- start=0x55d4de1e2000 end=0x55d4de1ef000 length=0xd000 # Not listing anonymous maps for now. # The we parse the ELF header which is at the start of the first proc_map shown above Parsing elf_ehdr... Container({'e_flags': 0, 'e_shoff': 2401000, 'e_phoff': 64, 'e_shnum': 30, 'e_entry': 270368, 'e_version': 'EV_CURRENT', 'e_machine': 'EM_X86_64', 'e_phnum': 9, 'e_shentsize': 64, 'e_ident': Container({'EI_DATA': 'ELFDATA2LSB', 'EI_OSABI': 'ELFOSABI_SYSV', 'EI_VERSION': 'EV_CURRENT', 'EI_CLASS': 'ELFCLASS64', 'EI_ABIVERSION': 0, 'EI_MAG': [127, 69, 76, 70]}), 'e_type': 'ET_DYN', 'e_phentsize': 56, 'e_shstrndx': 29, 'e_ehsize': 64}) # This looks sane, so let's go to e_phoff (64) and read the program header Parsing segments... 0x55d4ddda4040 Segment<p_memsz=0x1f8, p_flags=0x5, p_offset=0x40, p_type=PT_PHDR, p_align=0x8, p_paddr=0x40, p_filesz=0x1f8, p_vaddr=0x40> 0x55d4ddda4078 Segment<p_memsz=0x1c, p_flags=0x4, p_offset=0x238, p_type=PT_INTERP, p_align=0x1, p_paddr=0x238, p_filesz=0x1c, p_vaddr=0x238> 0x55d4ddda40b0 Segment<p_memsz=0x23bdd4, p_flags=0x5, p_offset=0x0, p_type=PT_LOAD, p_align=0x200000, p_paddr=0x0, p_filesz=0x23bdd4, p_vaddr=0x0> 0x55d4ddda40e8 Segment<p_memsz=0x1f8f0, p_flags=0x6, p_offset=0x23c408, p_type=PT_LOAD, p_align=0x200000, p_paddr=0x43c408, p_filesz=0xdd98, p_vaddr=0x43c408> 0x55d4ddda4120 Segment<p_memsz=0x2e0, p_flags=0x6, p_offset=0x23dc78, p_type=PT_DYNAMIC, p_align=0x8, p_paddr=0x43dc78, p_filesz=0x2e0, p_vaddr=0x43dc78> 0x55d4ddda4158 Segment<p_memsz=0x44, p_flags=0x4, p_offset=0x254, p_type=PT_NOTE, p_align=0x4, p_paddr=0x254, p_filesz=0x44, p_vaddr=0x254> 0x55d4ddda4190 Segment<p_memsz=0x9904, p_flags=0x4, p_offset=0x1f2b50, p_type=PT_GNU_EH_FRAME, p_align=0x4, p_paddr=0x1f2b50, p_filesz=0x9904, p_vaddr=0x1f2b50> 0x55d4ddda41c8 Segment<p_memsz=0x0, p_flags=0x6, p_offset=0x0, p_type=PT_GNU_STACK, p_align=0x10, p_paddr=0x0, p_filesz=0x0, p_vaddr=0x0> 0x55d4ddda4200 Segment<p_memsz=0x1bf8, p_flags=0x4, p_offset=0x23c408, p_type=PT_GNU_RELRO, p_align=0x1, p_paddr=0x43c408, p_filesz=0x1bf8, p_vaddr=0x43c408> # These segments look sane, and in fact the values match what I see from `readelf --segments` against the Xorg binary on disk. # I ignore the first PT_LOAD segment because the p_flags and p_vaddr tell me the .bss isn't going to be in there. (As does the output from `readelf --segments`) # And I try to read the data pointed to by the p_vaddr of the second PT_LOAD Testing PT_LOAD at 0x55d4ddda40e8. # Let's re-print the segment to remind ourselves: 0x55d4ddda40e8 Segment<p_memsz=0x1f8f0, p_flags=0x6, p_offset=0x23c408, p_type=PT_LOAD, p_align=0x200000, p_paddr=0x43c408, p_filesz=0xdd98, p_vaddr=0x43c408> # So starting at the base address (0x55d4ddda4000) + p_vaddr (0x43c408) =0x55d4de1e0408, I should be able to read p_memsz (0x1f8f0) bytes, right? # Wrong... I can only read 0xebf7 (60,407) bytes before volatility reports an error Failed to read offset 0xebf8==60408 Notably, the starting offset, 0x55d4de1e0408, is in: /usr/lib/xorg/Xorg r-- start=0x55d4de1e0000 end=0x55d4de1e2000 length=0x2000 but of course is bigger than the size of the proc_map. I really do appreciate any comments you might have as to where my understanding is lacking! Adam

7 years, 9 months

1
0
0 0

KeyError int128 unsigned in dwarfpy when using Volatility for Android RAM dump

by baumgarr

Hello! I posted this question already, but i could not find it on the archive, so I am trying it again. I am doing some research on RAM extraction and analysis in Android (6 Marshmallow). I succeeded in compiling my own Kernel with enabled CONFIG_MODULE_LOAD and installing it onto my Nexus 5X. Creating the LiME module to extract the RAM was also successful, I could get a memory dump of the device on my computer. In a Hex-editor, I can see content of the RAM (boot pictures, text messages,…). I also asked this question at stackoverflow, it is better readable there due to formatting reasons: https://stackoverflow.com/questions/44807171/keyerror-int128-unsigned-in-dw… But now I have problems using Volatility 2.6. My steps so far: • get volatility git clone https://github.com/volatilityfoundation/volatility.git cd volatility/tools/linux • Adjust Makefile (I also had to uncomment #define RADIX_TREE_MAX_TAGS 2 in the module.o, otherwise I got an error during make) obj-m += module.o KDIR := /root/compile/msm/ CCPATH := /root/compile/msm/aarch64-linux-android-4.9/bin -include version.mk all: dwarf dwarf: module.c $(MAKE) ARCH=arm64 CROSS_COMPILE=$(CCPATH)/aarch64-linux-android- -C $(KDIR) \ CONFIG_DEBUG_INFO=y M=$(PWD) modules dwarfdump -di module.ko > module.dwarf make • Combine System.map (created during kernel compilation) and module.dwarf (created during make) and copy the .zip it into the overlays directory zip Nexus5X.zip module.dwarf ../../../System.map cp Nexus5X.zip ../../volatility/plugins/overlays/linux/ • run volatility python vol.py --profile=LinuxNexus5Xx64 -f /root/Documents/nexus-ram.dump linux_pslist The parameters are all correct - the profile exists, the file also and linux_pslist is a valid command. But even with other commands such as linux_cpuinfo, I get the following error: root@kali:~/compile/msm/volatility-2.6# python vol.py --profile=LinuxNexus5Xx64 -f /root/Documents/nexus-ram.dump linux_pslist Volatility Foundation Volatility Framework 2.6 Traceback (most recent call last): File "vol.py", line 192, in <module> main() File "vol.py", line 183, in main command.execute() File "/root/compile/msm/volatility-2.6/volatility/plugins/linux/common.py", line 64, in execute commands.Command.execute(self, *args, **kwargs) File "/root/compile/msm/volatility-2.6/volatility/commands.py", line 116, in execute if not self.is_valid_profile(profs[self._config.PROFILE]()): File "/root/compile/msm/volatility-2.6/volatility/plugins/overlays/linux/linux.py", line 216, in __init__ obj.Profile.__init__(self, *args, **kwargs) File "/root/compile/msm/volatility-2.6/volatility/obj.py", line 862, in __init__ self.reset() File "/root/compile/msm/volatility-2.6/volatility/plugins/overlays/linux/linux.py", line 227, in reset self.load_vtypes() File "/root/compile/msm/volatility-2.6/volatility/plugins/overlays/linux/linux.py", line 264, in load_vtypes vtypesvar = dwarf.DWARFParser(dwarfdata).finalize() File "/root/compile/msm/volatility-2.6/volatility/dwarf.py", line 71, in __init__ self.feed_line(line) File "/root/compile/msm/volatility-2.6/volatility/dwarf.py", line 162, in feed_line self.process_statement(**parsed) #pylint: disable-msg=W0142 File "/root/compile/msm/volatility-2.6/volatility/dwarf.py", line 225, in process_statement self.id_to_name[statement_id] = [self.base_type_name(data)] File "/root/compile/msm/volatility-2.6/volatility/dwarf.py", line 125, in base_type_name return self.tp2vol[data['DW_AT_name'].strip('"')] KeyError: '__int128 unsigned' Can you help me figuring out the error and how to solve it? Or any related work which did RAM extraction from Android > 5.0 ? The string "__int128 unsigned" is inside the module.dwarf two times. I posted the Module.dwarf here as it would be too big for this mail (it needs some time until the web page appears): http://chopapp.com/#b27ludkk Thanks in advance!

7 years, 9 months

1
0
0 0

Why is this user-space data only in kernel space? #linux

by Bridgey theGeek

Hi all, This is a "what don't I know?" question... I have a very simple C program: #include <gtk/gtk.h> #include <stdio.h> int main(int argc, char **argv) { GtkTextBuffer *buffer; buffer = gtk_text_buffer_new(NULL); gtk_text_buffer_set_text(buffer, "adam1adam2adam3", 15); printf("buffer: %p\n", buffer); getchar(); return 0; } Then the following to try and locate the strings in memory: ------------------------------------------------------------ $ strings --radix=d LinuxMint-17.3-Mate-x64-61951b91.vmem | fgrep adam1adam2adam3 >/tmp/s ------------------------------------------------------------ $ cat /tmp/s 195393652 adam1adam2adam3 204175816 adam1adam2adam3 851998836 adam1adam2adam3 ------------------------------------------------------------ $ ~/src/volatility/vol.py -f LinuxMint-17.3-Mate-x64-61951b91.vmem --profile LinuxMint173x64 linux_strings -s /tmp/s Volatility Foundation Volatility Framework 2.6 195393652 [kernel:88000ba57874] adam1adam2adam3 204175816 [kernel:88000c2b79c8] adam1adam2adam3 851998836 [kernel:880032c87874] adam1adam2adam3 ------------------------------------------------------------ Why on earth would the string only be located in Kernel space?? I've been digging into Gtk for quite some time now to try and solve this and think I understand that in Gtk, text is stored as GtkTextLineSegments. The memory for a GtkTextLineSegment is allocated via g_slice_alloc and the actual text copied to the allocated space via an ordinary memcpy (See: https://github.com/GNOME/gtk/blob/406db15066f121c2b9910691f92e58 41b30e0311/gtk/gtktextsegment.c#L190-L210) I've proved the text really is here by editing the text in the VMEM file in a hex editor and then resuming the VM - sure enough the text is updated to reflect the changes. I could just about understand the text being in Kernel space AND user space because perhaps its sent to the X server or something, but it appears to ONLY be in Kernel space. What don't I know?? Many thanks, Adam

7 years, 9 months

2
3
0 0

Problem with Virtualbox Dumps

by Thomas

Hi, using the current version from GitHub (-> git pull) I can’t analyze Virtualbox memory dump files anymore. I’m using Virtualbox v5.1.22 (current release). I’m using Cuckoo Sandbox (v2.0 and cuckoo-modified) and vol.py doesn’t recognize the memory.dmp files anymore. Neither within Cuckoo processing nor manually from the command line. My Virtual machine contains Windows 7 SP1 x86 Pro and the memory dumps could be analyzed successfully in the past. This happens when using all Win7 profiles. See some vol.py messages below. Taken from an older memory.dmp file which could be successfully analyzed by vol.py with cuckoo-modified when it was created in 2016. If needed I can share the memory dump (2,1 GB, zipped ~640 MB). Thomas 1) vol.py -f memory.dmp --profile=Win7SP1x86 pslist Volatility Foundation Volatility Framework 2.6 No suitable address space mapping found Tried to open image as: MachOAddressSpace: mac: need base LimeAddressSpace: lime: need base WindowsHiberFileSpace32: No base Address Space WindowsCrashDumpSpace64BitMap: No base Address Space VMWareMetaAddressSpace: No base Address Space WindowsCrashDumpSpace64: No base Address Space HPAKAddressSpace: No base Address Space VirtualBoxCoreDumpElf64: No base Address Space VMWareAddressSpace: No base Address Space QemuCoreDumpElf: No base Address Space WindowsCrashDumpSpace32: No base Address Space Win10AMD64PagedMemory: No base Address Space WindowsAMD64PagedMemory: No base Address Space LinuxAMD64PagedMemory: No base Address Space AMD64PagedMemory: No base Address Space IA32PagedMemoryPae: No base Address Space IA32PagedMemory: No base Address Space OSXPmemELF: No base Address Space MachOAddressSpace: MachO Header signature invalid LimeAddressSpace: Invalid Lime header signature WindowsHiberFileSpace32: No xpress signature found WindowsCrashDumpSpace64BitMap: Header signature invalid VMWareMetaAddressSpace: VMware metadata file is not available WindowsCrashDumpSpace64: Header signature invalid HPAKAddressSpace: Invalid magic found VirtualBoxCoreDumpElf64: ELF error: did not find any PT_NOTE segment with VBCORE VMWareAddressSpace: Invalid VMware signature: 0x464c457f QemuCoreDumpElf: ELF error: did not find any PT_NOTE segment with CORE WindowsCrashDumpSpace32: Header signature invalid Win10AMD64PagedMemory: Incompatible profile Win7SP1x86 selected WindowsAMD64PagedMemory: Incompatible profile Win7SP1x86 selected LinuxAMD64PagedMemory: Incompatible profile Win7SP1x86 selected AMD64PagedMemory: Incompatible profile Win7SP1x86 selected IA32PagedMemoryPae: Failed valid Address Space check IA32PagedMemory: Failed valid Address Space check OSXPmemELF: No PT_LOAD segments found FileAddressSpace: Must be first Address Space ArmAddressSpace: Profile does not have valid Address Space check 2) vol.py -f memory.dmp imageinfo Volatility Foundation Volatility Framework 2.6 INFO : volatility.debug : Determining profile based on KDBG search... Suggested Profile(s) : Win7SP1x86_23418, Win7SP0x86, Win7SP1x86 (Instantiated with Win7SP1x86) AS Layer1 : FileAddressSpace (/daten/cuckoo-modified/storage/analyses/44/memory.dmp) PAE type : No PAE DTB : 0x185000L KDBG : 0x293c504L Number of Processors : 0 Image Type (Service Pack) : 0 KUSER_SHARED_DATA : 0xffdf0000L 3) vol.py -f memory.dmp kdbgscan Volatility Foundation Volatility Framework 2.6 ************************************************** Instantiating KDBG using: /daten/cuckoo-modified/storage/analyses/44/memory.dmp WinXPSP2x86 (5.1.0 32bit) Offset (P) : 0x293c504 KDBG owner tag check : True Profile suggestion (KDBGHeader): Win7SP1x86_23418 Version64 : 0x293c4dc (Major: 15, Minor: 7601) PsActiveProcessHead : 0x8294fcb0 PsLoadedModuleList : 0x82956b90 KernelBase : 0x82813000 ************************************************** Instantiating KDBG using: /daten/cuckoo-modified/storage/analyses/44/memory.dmp WinXPSP2x86 (5.1.0 32bit) Offset (P) : 0x293c504 KDBG owner tag check : True Profile suggestion (KDBGHeader): Win7SP1x86 Version64 : 0x293c4dc (Major: 15, Minor: 7601) PsActiveProcessHead : 0x8294fcb0 PsLoadedModuleList : 0x82956b90 KernelBase : 0x82813000 ************************************************** Instantiating KDBG using: /daten/cuckoo-modified/storage/analyses/44/memory.dmp WinXPSP2x86 (5.1.0 32bit) Offset (P) : 0x293c504 KDBG owner tag check : True Profile suggestion (KDBGHeader): Win7SP0x86 Version64 : 0x293c4dc (Major: 15, Minor: 7601) PsActiveProcessHead : 0x8294fcb0 PsLoadedModuleList : 0x82956b90 KernelBase : 0x82813000 4) vol.py -f memory.dmp --profile=Win7SP1x86 vboxinfo Volatility Foundation Volatility Framework 2.6 ERROR : volatility.debug : Memory Image could not be identified as ['VirtualBoxCoreDumpElf64'] 5) file memory.dmp memory.dmp: ELF 64-bit LSB core file x86-64, version 1 (SYSV)

7 years, 10 months

1
1
0 0

Our newly updated training is headed to Herndon and London!

by Andrew Case

As we enter summer, we wanted to let everyone know that we only have two remaining public training classes for 2017. Full details of these classes, including all the newly updated material, can be found on our recent blog post: https://volatility-labs.blogspot.com/2017/06/our-newly-updated-memory-foren… Our classes have been selling out a good bit in advance so please let us know ASAP if you wish to attend.

7 years, 10 months

1
0
0 0

The 2017 Volatility Plugin Contest is live!

by Andrew Case

We are very excited to announce that our 5th annual Volatility Plugin Contest is now live, and we are accepting submissions until October 1st, 2017. We are giving away over $2,000 in prizes and swag - so get coding!!! Full details on our blog post: https://volatility-labs.blogspot.com/2017/04/the-5th-annual-2017-volatility… Please let us know if you have any questions and good luck to all!

8 years

1
0
0 0

vote for volatility

by Michael Chaves

Volatility is in the running for "Open Source Digital Forensic Software of the Year" in the Forensic4cast awards. Take a moment to vote Forensic 4:cast Awards <https://forensic4cast.com/forensic-4cast-awards/> https://forensic4cast.com/forensic-4cast-awards/ Mike Det. Michael Chaves Monroe CT Police Department 7 Fan Hill Road Monroe, CT 203.452.2831 x1307 (desk)

8 years

1
0
0 0

Meetups next week in Herndon and Reston

by Andrew Case

Hey All, We will be in the Reston/Herndon area next week for a training, and wanted to see if any Volatility users were interested in a meetup. We will be hanging out in Herndon on Wednesday (the 5th) late afternoon/night and Reston on Thursday. These will be informal meetups at a bar or similar type place. If you are interested in the specifics for a particular night then let us know and we can pass them along information. Hope to see some of you around! -- Thanks, Andrew (@attrc)

8 years

1
0
0 0

Two day Memory Forensics training in Montreal

by Andrew Case

We are pleased to announce that Michael Ligh (MHL) will be delivering a two day version of our Malware and Memory Forensics training at this year's NorthSec conference in Montreal: https://www.nsec.io/2017/01/malware-and-memory-forensics-training/ This will be our first public training of any kind in Canada, and the class is already quickly filling. If you have any questions please see the URL above or let me or MHL know.

8 years, 1 month

1
0
0 0

Mailing List Maintenance: Restored

by AAron Walters

Vol-users, All mailing list services have been restored. If you have any questions or experience any issues, please let me know. We apologize for any inconvenience and thank you for your patience. As a quick reminder, the new email address for the list will be: vol-users [at] lists [dot] volatilityfoundation [dot] org. You can manage your membership settings at the following URL: https://lists.volatilityfoundation.org. Thanks, AAron Walters The Volatility Foundation

8 years, 1 month

1
0
0 0

Mailing List Maintenance

by AAron Walters

Hi vol-users, After 10 years, it is finally time to move the Volatility mailing lists to their new home at the Volatility Foundation, lists.volatilityfoundation.org. The official cutover is currently scheduled for Friday, 3/10/2017, at 1100 EST. As a part of this process, we’re also performing a number of infrastructure and security upgrades. We anticipate this planned outage will take less than 12 hours. With the dramatic increase in spam over the last 10 years, we have relied heavily on automated classification and manual review to make sure none of those messages burden your inbox. Unfortunately, there have been circumstances where some users’ emails have been inadvertently filtered. In order to reduce the likelihood of this happening in the future, the list will now be configured to only accept messages from email addresses that are registered as members of the list. During the move, we will handle migrating existing users to the new systems. Once the move is complete, we will send an email notification that will also serve as a test message on the new platform. If you do not receive the notification email, please send me a note and we will work on getting the issue resolved! We appreciate your patience as we make this transition. The new email address for the list will be: vol-users [at] lists [dot] volatilityfoundation [dot] org. As a part of this transition, we have also decided to sunset the Volatility Developers mailing list (Vol-dev). Currently, almost all of the development conversations and issues are handled within the Volatility project page on Github: https://github.com/volatilityfoundation/volatility. We will be maintaining the Vol-dev mailing list archives for historical purposes. A special thanks to the Volexity team and our official training partner, memoryanalysis.net, for sponsoring the new infrastructure. Thanks, AAron Walters The Volatility Foundation

8 years, 1 month

1
0
0 0

Create Volatility Plugin

by ahmad ababneh

Dear All, I'm a beginner in Memory Forensics, I want to develop volatility plugin that searches a memory dumps to find records which inserted via C++ program. I'm created VType for the struct that used in the program but how to access the records in memory dump using volatility. thanks regards, Ahmad

8 years, 1 month

1
0
0 0

PAGE_EXECUTE_READWRITE

by Marcello Goletti

Hi list, I have a couple of questions that might be stupid but I am pretty new to memory forensics. -Is there a specific reason why the windows operating system would need a page to be marked Execute and Read/write? -IS DKOM used only in Windows OSs? Thanks!

8 years, 1 month

1
0
0 0

Upcoming memory forensics training in Herndon almost sold out

by Andrew Case

We wanted to send a quick note that our upcoming training in Herndon is likely going to sell out in the next week. Please contact us ASAP if you wish to attend: https://www.memoryanalysis.net/memory-forensics-training If you can't make this training, we also have public trainings later this year in London and back in Herndon. Both of these currently have spots available. We also have 1 (or possibly 2 depending on the week) private training slots left for 2017. Again, contact us ASAP if your organization would like a private training as the slots go pretty fast. If you have any questions then please let us know. -- Thanks, Andrew (@attrc)

8 years, 1 month

1
0
0 0

The BSides New Orleans keynote & speaker lineup!

by Andrew Case

Hello All, We are excited to announce the keynote and speaker lineup for BSidesNOLA 2017! http://www.bsidesnola.com This all-day event will take place on April 1st in the New Orleans CBD. It is a great time for learning, networking, and enjoying great food and drinks. It is $15 to attend, and this includes refreshments and a t-shirt. We had around 215 people attend last year, and expect more this year. If you have any questions then please let me know. -- Thanks, Andrew (@attrc)

8 years, 2 months

1
0
0 0

tagTHREADINFO seems wrong in Win10x64

by Bridgey theGeek

Hi all, I know in an ideal world I'd submit this as a pull request to the github project, but you'll see why I haven't. With the Win81U1x64 profile, the `windows` plugin is able to correctly report the associated PID: Window Handle: #20074 at 0xfffff90140819cf0, Name: Untitled - Notepad ClassAtom: 0xc12c, Class: - SuperClassAtom: 0xc12c, SuperClass: - pti: 0xfffff9014225b9b0, Tid: 2532 at 0xffffe00001dbe600 ppi: 0xfffff90140747010, Process: notepad.exe, Pid: 2528 However, using the Win10x64 profile it cannot, because tagWND.head.pti.ppi is 0x0. Window Handle: #10222 at 0xfffff90140a26ae0, Name: Untitled - Notepad ClassAtom: 0xc16d, Class: - SuperClassAtom: 0xc16d, SuperClass: - pti: 0xfffff90141fa3b20, Tid: 4652 at 0xffffe00014b9e380 ppi: 0x0, Process: -, Pid: - I'm pretty sure I've traced this to being that in tagWND.head.pti the offset to ppi is wrong. $ python vol.py -f Win10x64.vmem --profile Win10x64 volshell --SNIP-- >>> dt('tagTHREADINFO') 'tagTHREADINFO' (936 bytes) 0x0 : pEThread ['pointer64', ['_ETHREAD']] 0x8 : RefCount ['unsigned long'] --SNIP-- 0x168 : spklActive ['pointer64', ['tagKL']] 0x170 : pcti ['pointer64', ['tagCLIENTTHREADINFO']] 0x170 : ppi ['pointer', ['tagPROCESSINFO']] 0x178 : rpdesk ['pointer64', ['tagDESKTOP']] --SNIP-- You can see that `ppi`, the pointer to `tagPROCESSINFO`, is at 0x170 - the same as `pcti`. The pointer to the tagPROCESSINFO structure is actually at 0x178 - currently shown as `rpdesk`. If I modify `volatility/plugins/gui/vtypes/win8.py`, at line 197 from: 'ppi': [0x170, ['pointer', ['tagPROCESSINFO']]], to: 'ppi': [0x178, ['pointer', ['tagPROCESSINFO']]], the `windows` plugin now behaves itself: Window Handle: #10222 at 0xfffff90140a26ae0, Name: Untitled - Notepad ClassAtom: 0xc16d, Class: - SuperClassAtom: 0xc16d, SuperClass: - pti: 0xfffff90141fa3b20, Tid: 4652 at 0xffffe00014b9e380 ppi: 0xfffff90141fa5c10, Process: notepad.exe, Pid: 3692 And it's at this point where my understanding of the Volatility code breaks down and why I'm not comfortable submitting a pull request. I don't know how to implement an overlay for Win10 and what knock-on effect it might have. My *guess* would be that Microsoft has added an extra value to the tagTHREADINFO structure between Windows 8 and Windows 10 meaning the offset (within the tagTHREADINFO structure) has moved along 8 bytes (0x170 -> 0x178), but I don't know the rest of the structure well enough to confidently validate this theory. Perhaps one of the Volatility core developers does? Thanks, Adam

8 years, 2 months

1
0
0 0

OT: Sony Forensic Internships - Summer 2017

by Jared Greenhill

All, My Forensic team is hiring two paid Forensic Interns for the summer of 2017 in the Northern Virginia area. We are charged with directly supporting Sony's global SOC, which ends up touching many core facets of digital forensics and incident response including: memory analysis disk analysis mobile device forensics timeline investigations research and development projects data analytics If you are interested please feel free to apply directly on the job listing below. If you have any questions you can reach out to me directly. https://careers.sony.com/sony/?_3x3524903Z2U14Kdf8024bc-fbd2-4d8e-96d7-d7a5… I'll also be doing some recruiting at BSides New Orleans <http://www.securitybsides.com/w/page/113990746/BSidesNOLA%202017> on 4/1 where i'll be talking about a case study on Andromeda malware. Best Regards, Jared Greenhill (@jared703)

8 years, 2 months

1
0
0 0

Why is the address of this tagWND unreadable?

by Bridgey theGeek

Hi all, I feel like I'm missing something obvious. Consider the following from volshell. Profile is Win10x64 in case it matters; I'd already imported messagehooks (mh). >>> sc() Current context: System @ 0xffffe00012a61840, pid=4, ppid=0 DTB=0x1aa000 >>> for winsta, atom_tables in mh.calculate(): ... for desktop in winsta.desktops(): ... for wnd, _level in desktop.windows(desktop.DeskInfo.spwnd): ... if wnd.cbwndExtra == 8: ... break >>> wnd [tagWND spwndNext] @ 0xFFFFF90140A04AD0 >>> dt(wnd) [tagWND spwndNext] @ 0xFFFFF90140A04AD0 0x0 : head 18446736382507371216 0x28 : bActiveFrame 0 0x28 : bAnsiCreator 0 --SNIP-- 0x120 : bLinked 1 0x120 : bRedirectedForPrint 0 0x120 : bVerticallyMaximizedLeft 0 0x120 : bVerticallyMaximizedRight 0 >>> dt('tagWND', wnd.v()) ERROR: could not instantiate object Reason: Invalid Address 0xFFFFF90140A04AD0, instantiating tagWND >>> hex(wnd.v()) '0xfffff90140a04ad0L' >>> db(wnd.v()) Memory unreadable at fffff90140a04ad0 Why is the memory address unreadable? Is my error in assuming that object 'wnd' is made up of bytes located at 0xFFFFF90140A04AD0? Given the address is in Kernel space, I should be able to access it right? Any pointers appreciated! (Pardon the pun.) Adam

8 years, 2 months

2
2
0 0

The Release of Volatility 2.6

by Michael Ligh

This release improves support for Windows 10 and adds support for Windows Server 2016, Mac OS Sierra 10.12, and Linux with KASLR kernels. A lot of bug fixes went into this release as well as performance enhancements (especially related to page table parsing and virtual address space scanning). Here's the TL;DR: The release page, with standalone binary downloads for 64-bit Windows, Linux, and Mac: http://www.volatilityfoundation.org/26 Information on new Volatility 2.6 profiles: https://github.com/volatilityfoundation/volatility/wiki/2.6-Win-Profiles Python source code packages: https://github.com/volatilityfoundation/volatility/releases We look forward to working with you all in the new year! The Volatility Team

8 years, 3 months

1
0
0 0

BSidesNOLA 2017 Dates & CFP announced!

by Andrew Case

Hello All, We are excited to announce that the date for BSidesNOLA 2017 is set and that the CFP is live. BSidesNOLA will take place on April 1st, 2017 in downtown New Orleans. This will be our 5th year running, and we are expecting another sell out crowd. If you have never been before, it is a day full of infosec talks, networking, and contests along with plenty of local New Orleans food and drinks - all for $15. If you plan to submit to the CFP then please take your time in crafting your submission. We don't review the submissions until after the deadline ends so there is no benefit to submitting early. We also have a highly competitive CFP, and every year we have to reject 15 or more talks. Give us your best so this doesn't happen to you! Full information, including venue, how to register ($15 for all day), and the CFP details can be found at: http://www.securitybsides.com/w/page/113990746/BSidesNOLA If you have any questions then please contact us at bsidesnola [@@@] gmail.com. Thanks, The BSidesNOLA Team

8 years, 4 months

1
0
0 0

Volatility memory forensics training in April filling quickly

by Andrew Case

Our next public training in April in Reston is on pace to sell out pretty quickly. Please contact us ASAP if you wish to attend: http://www.memoryanalysis.net/memory-forensics-training Also, our private training slots for next year are filling fast as well. These are a great way to raise the skillset of your entire team up at once. We also have several add-ons that previous private training clients chose and found great value in - such as customization of content as well us building labs around memory samples from your own previous internal investigations (NDAs expected for this). Please contact us off list if interested in a private training. -- Thanks, Andrew (@attrc)

8 years, 4 months

1
0
0 0

Results from the 2016 Volatility Plugin Contest are in!

by Andrew Case

We are excited to announce that the results of the 2016 Volatility Plugin Contest are in: https://volatility-labs.blogspot.com/2016/12/results-from-2016-volatility-p… We received a record number of submissions this year, and we are looking forward to seeing these plugins be adopted in the field. Be sure to congratulate the winners on Twitter and LinkedIn and when you see them at conferences and trainings. We also wanted to thank Airbnb again for their donation of $999 to the prize pool. It is great to see organizations supporting open source research in the digital forensics and incident response fields. Thanks, The Volatility Team

8 years, 4 months

1
0
0 0

Reminder: 2016 Plugin Contest

by AAron Walters

In case you don’t follow us on twitter (@volatility), we wanted to send a quick reminder that the 2016 Volatility Plugin Contest will be ending on October 1, 2016. This is your chance to win over $3200 in cash and prizes! http://www.volatilityfoundation.org/2016 A special thanks to Airbnb (@airbnb) and Volexity (@volexity) for sponsoring this year’s contest! Thanks, AAron Walters The Volatility Foundation

8 years, 7 months

1
0
0 0

libewf on Windows (I know, I know!)

by Bridgey theGeek

Hi all, Because the universe hates me, I've been given an E01 of a RAM dump (from Win7SP1x64) and I have to use Windows to run Volatility. I have p99 of tAoMF in front of me. I tried the "Mount in FTK Imager and point to Z:\unallocated space" thing, but pslist showed only 1 entry which looked very corrupt. I don't have access to EnCase to mount it from there. So I'd like to use libewf. But can I even use it on Windows?? If I compile the library, how do I tell Volatility about the libewf.dll? Basically, how do I use Volatility with libewf on Windows? Thank you, Adam

8 years, 8 months

4
5
0 0

Fwd: [Vol-users] libewf on Windows (I know, I know!)

by Jared Greenhill

Bridgey, I haven't been in this EWF situation for memory yet but I'd probably try imagecopy first: vol.exe -f image.e01 --profile=<yourprofile> -O image.raw If that didn't work, I'd use Tom's #2 and load the .E01 in FTK imager and image that mounted volume. If that didn't work I'd try load the evidence into encase 7.x - right click on the evidence --> evidence --> device --> share --> Mount as Emulated Disk and then use FTK imager to image that mounted volume to .raw JG On Tue, Aug 16, 2016 at 11:03 AM, Tom Yarrish <tom(a)yarrish.com> wrote: > IIRC volatility should be able to handle an E01 file natively now (unless > that's a *nix only thing). But another option would be either 1) Arsenal > Image Mounter (which works much better than FTK, EnCase, etc IMO) or 2) Use > FTK to covert the E01 image to a RAW image file and then just run that > through volatility. > > Thanks, > Tom > > > PGP Key ID - B32585D0 > > On Tue, Aug 16, 2016 at 2:39 PM, Bridgey theGeek <bridgeythegeek(a)gmail.com > > wrote: > >> Hi all, >> >> Because the universe hates me, I've been given an E01 of a RAM dump (from >> Win7SP1x64) and I have to use Windows to run Volatility. >> >> I have p99 of tAoMF in front of me. >> >> I tried the "Mount in FTK Imager and point to Z:\unallocated space" >> thing, but pslist showed only 1 entry which looked very corrupt. >> >> I don't have access to EnCase to mount it from there. >> >> So I'd like to use libewf. But can I even use it on Windows?? If I >> compile the library, how do I tell Volatility about the libewf.dll? >> >> >> Basically, how do I use Volatility with libewf on Windows? >> >> Thank you, >> Adam >> >> _______________________________________________ >> Vol-users mailing list >> Vol-users(a)volatilityfoundation.org >> http://lists.volatilityfoundation.org/mailman/listinfo/vol-users >> >> > > _______________________________________________ > Vol-users mailing list > Vol-users(a)volatilityfoundation.org > http://lists.volatilityfoundation.org/mailman/listinfo/vol-users > >

8 years, 8 months

4
3
0 0

New Volatility Blog post: Automating Detection of Known Malware through Memory Forensics

by Andrew Case

We just put up a new blog post on automating detecting known malware with AV and Volatility - feedback encouraged! http://volatility-labs.blogspot.com/2016/08/automating-detection-of-known-m… Also, let us know if you will be in Vegas this week and want to meet up. -- Thanks, Andrew (@attrc)

8 years, 8 months

1
0
0 0

Request for advice on how to proceed with further analysis

by David Renz

Hello, I recently posted a message, where I asked how to create a profile which could be used with ArchLinux, but now I just solved this by having installed Lubuntu 16.04 (4.4.0-31-generic 64-bit), so that I was able to analyze my system's dumped memory using the pre-built Ubuntu 16.04 image I found on GitHub (the image I created by myself couldn't be used by Volatility, although I definitely followed each step precisely). The checks I performed confirmed my suspicion that my system would be compromised, as one can see by taking a look at the results I uploaded on GoogleDrive: https://drive.google.com/open?id=0B62Y5Qk_rdbWTnNYWlJRWXpsZUE E.g.: linux_check_afinfo Symbol Name Member Address ------------------------------------------ ------------------------------ ------------------ udplite6_seq_afinfo next 0xffffffff81effcc8 udplite6_seq_afinfo stop 0xffffffff81eff808 udplite4_seq_afinfo next 0xffffffff81efeac8 udplite4_seq_afinfo stop 0xffffffff81efbce8 udp4_seq_afinfo start 0xffffffff81efae00 udp4_seq_afinfo stop 0xffffffff81efa3a0 linux_check_inline_kernel Name Member Hook Type Hook Address ------------------------------------------------ ---------------- --------- ------------------ udp4_seq_afinfo stop JMP 0x0000000000000000 [A huge number of hooks shown by linux_check_syscall] Using the netstat plugin shows no result at all (none of the connections shown by using the normal Linux netstat command). Neither linux_lsmod nor linux_hidden_modules give any output as well. I assume that my system is infected by an ACPI rootkit, which is able to compromise both Linux and Windows systems. After having submitted the extracted the ACPI tables' code to malwr.com, where it gets executed on a Windows sandbox, it shows that the system gets manipulated in the following way: https://malwr.com/analysis/ODkxOThjOTk1MDAzNGE4M2JhOWNhNzk1ZTJjM2IyYWQ/ It might be interesting that the ACPI code of four different systems being used by me seems to have been manipulated in the same way, since the extracted code found on one of the other systems leads to the same result when submitting it to malwr.com. E.g., the link above shows the result for the analysis of ACPI code on my AMD 64-bit desktop computer (Asus-M4N68T-M LE mainboard), while the ACPI code extracted from my Lenovo G710 notebook leads to the same when executed on a Windows system: https://malwr.com/analysis/MjZkOGU4Y2ZmMGM5NDQ1Njg5OTc4NTVlOTQ5NThiMmY/ I guess everyone can see that the results show how the Windows system gets compromised for being able to monitor it and gaining remote access over it, if you take a look at the file and registry activities (just googling some of the file names makes that clear). Since a Linux system running on the same machine gets compromised as well, it would be reasonable to assume that this also takes place by the ACPI code's execution. Taking a look at the dmesg output, which I also uploaded on GoogleDrive, seems to confirm this assumption: [ 0.225468] ACPI: Added _OSI(Module Device) [ 0.225470] ACPI: Added _OSI(Processor Device) [ 0.225471] ACPI: Added _OSI(3.0 _SCP Extensions) [ 0.225472] ACPI: Added _OSI(Processor Aggregator Device) [ 0.227433] ACPI: Executed 1 blocks of module-level executable AML code [ 0.293448] ACPI: Interpreter enabled [ 0.293458] ACPI Exception: AE_NOT_FOUND, While evaluating Sleep State [\_S2_] (20150930/hwxface-580) [ 0.293469] ACPI: (supports S0 S1 S3 S4 S5) [ 0.293470] ACPI: Using IOAPIC for interrupt routing [ 0.293491] PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 0xe0000000-0xefffffff] (base 0xe0000000) [ 0.294509] PCI: MMCONFIG at [mem 0xe0000000-0xefffffff] reserved in ACPI motherboard resources [ 0.294522] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug [ 0.298938] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff]) [ 0.298943] acpi PNP0A03:00: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI] [ 0.299051] acpi PNP0A03:00: _OSC: platform does not support [PCIeHotplug PCIeCapability] [ 0.299099] acpi PNP0A03:00: _OSC: not requesting control; platform does not support [PCIeCapability] [ 0.299101] acpi PNP0A03:00: _OSC: OS requested [PCIeHotplug PME AER PCIeCapability] [ 0.299103] acpi PNP0A03:00: _OSC: platform willing to grant [PME AER] [ 0.299104] acpi PNP0A03:00: _OSC failed (AE_SUPPORT); disabling ASPM [ 8.647712] ACPI Warning: SystemIO range 0x0000000000000600-0x000000000000063F conflicts with OpRegion 0x0000000000000600-0x00000000000006FF (\_SB_.PCI0.SBRG.ASOC.SMRG) (20150930/utaddress-254) The extracted and disassembled ACPI code of my AMD system can be downloaded from here: https://drive.google.com/open?id=0B62Y5Qk_rdbWYzhPTHhHM1RxRTg So I would appreciate it, if anyone would have an idea on how to proceed with a further analysis. It would be interesting, if one would be able to see how exactly the ACPI code's execution interacts with the kernel in order to compromise the system. And of course it would be interesting to discover where the relevant network traffic gets forwarded to / comes in from (for remote access), since the checks I already performed showed that the networking structure got manipulated, so that the usage of Wireshark etc. won't show anything. Kind regards and thanks in advance David

8 years, 8 months

1
0
0 0

Arch (Antergos) 4.6.4-1-ARCH profile can't be used

by David Renz

Hello, I'm using Antergos with the 4.6.4-1 kernel and after dumping my computer's memory using lime worked without any problems, I went on creating a profile for my system according to the instructions on https://github.com/volatilityfoundation/volatility/wiki/Linux#using-the-pro…, while creating the system.map using "cp /proc/kallsyms /boot/System.map-4.6.4-1" (because there is no system.map in ArchLinux, as mentioned on https://github.com/volatilityfoundation/profiles/issues/13) Unfortunately I experience the same problem as described in the last link, since volatility gives an error message about this profile saying "*** Failed to import volatility.plugins.overlays.linux.linux (ValueError: too many values to unpack)". On the issue thread linked above someone gives the following answer: "Old issue, but could still be interesting. This is most likely due to kallsyms giving additional information on certain lines ([serio] or [kvm] for example), and Volatility on the other hand only expecting three space separated values: (str_addr, symbol_type, symbol) = line.strip().split() That's why before using the output of the kallsyms proc file to build a profile, some lines must be checked to fit the expected format." Now this answer doesn't really help me to solve the issue and create a working profile for my system. Does someone has any idea how I could proceed in order to do so? As far as I know, nobody was ever able to build a profile working for Arch, so I think this would be really helpful for many people. I uploaded the profile created by myself and the files I used for doing so on GoogleDrive, in case someone might even be able to create a profile using those files: https://drive.google.com/open?id=0B62Y5Qk_rdbWbWlDZ21VUEVrZGc Many thanks in advance and kind regards David

8 years, 8 months

1
0
0 0

Reading PV ELF coredumps from Xen into Volatlity

by Seborowski, Michael

Hello everyone, I apologize if this is not correctly described, but I have been trying to read Para-virtualized (PV) core dump files from a Xen Hypervisor. Now, I have managed to read the core dump when the VM is in HVM mode and read pfn values of a Ubuntu system with this external GitHub project (address space from Xenelf.py file): https://github.com/banne01/xen-core-velocity (after modifying line 126 to show elf_hdr instead of elf64_hdr to solve a weird error message). However, I cannot seem to figure out how the p2m values are properly read from a PV SUSE Linux Enterprise Server VM. There is a pfn value and a gmfn value in the p2m array of values which I cannot seem to read and interpret properly even if I specifically tell volatility to focus on just the pfn values. In addition, Volatility succeeds in instancing the address space for the SLES coredump but it still errors out after all the other address spaces have been exhausted. If anyone has any feedback or ways to point me in the right direction, could you let me know? Thanks, and best regards. Michael Seborowski

8 years, 8 months

2
1
0 0

Volatility at Black Hat, DFRWS and trainings coming to AMS & Reston

by Andrew Case

We wanted to send a quick update before heading to Vegas. If you will be around Black Hat during the pre-conference trainings and/or briefings, and want to meet up then let us know. Jamie and I will be around during the pre-conf trainings and then the whole team will be around for the briefings. Also, if you are headed to DFRWS, then be sure to check out Dr. Golden's talk on Analyzing Objective-C malware through memory forensics. This is some work that we did which will be headed to core Volatility soon after. And finally - we have upcoming trainings in Amsterdam and Reston that are quickly filling. If you wish to attend then please contact us ASAP in order to reserve a seat: http://www.memoryanalysis.net/#!memory-forensics-training/c1q3n -- Thanks, Andrew (@attrc)

8 years, 9 months

1
0
0 0

Re: Win2008R2SP1x64 is showing lack ofinformationwhenrunningplugins.

by Michael Ligh

Hi Kim, In this case, its not the overlays. I can tell because details for the two processes you /do/ see from psscan are all okay. If a bad overlay was the issue, your results would be all or nothing. Cheers - I may follow up with you off-list to offer a little other advice. Thanks, Michael On 7/25/16 11:40 AM, Kim Palechek wrote: > I don’t have access to the machine but I’m sure our Forensics guys do as they were the ones who retrieved the image for us. I’ll discuss with Steve on what he wants to do or if he wants to acquire another image. > > Thank you so much for getting back to me so quickly and for your help! I wasn’t sure if it was another issue with the overlays and x64 machines. > > > > > Kim Palechek, CISSP, CEH > IT Security Operations Specialist, (Information Security, Risk and Compliance) > 3M Information Technology > 3M Center, Bldg, 0224-04-E-21 > Phone: 736-6526 > kspalechek(a)mmm.com > > The absence of evidence is not the evidence of absence. > > On 7/25/16, 11:15 AM, "Michael Ligh" <michael.ligh(a)mnin.org> wrote: > > Hi Kim, > > Yes, unfortunately we're only able to enumerate 1 process in the linked > list. This typically happens when the acquisition tool fails to acquire > one or more pages of memory containing the necessary puzzle pieces (or > "links"). In some cases, if its a minor smearing issue, you can still > salvage some data by using psscan, which does a brute force scan of the > entire memory dump for processes (even if they aren't linked). However, > I noticed your psscan results only had 2 entries. This means the > acquisition tool failed to acquire a whole lot more than just a couple > pages. In the past, we've seen that happen quite a bit with DumpIt, FTK > Imager, and Memoryze. > > Do you still have access to the suspect machine by any chance? > > Thanks, > Michael > > On 7/25/16 11:07 AM, Kim Palechek wrote: > > Thank you so much for getting back so quickly. Below are the results of the kdbgscan. Encase is the tool used for acquisition. > > > > > > ************************************************** > > Instantiating KDBG using: Kernel AS Win2008R2SP1x64 (6.1.7601 64bit) > > Offset (V) : 0xf80001dfa110 > > Offset (P) : 0x1dfa110 > > KDBG owner tag check : True > > Profile suggestion (KDBGHeader): Win7SP1x64 > > Version64 : 0xf80001dfa0e8 (Major: 15, Minor: 7601) > > Service Pack (CmNtCSDVersion) : 1 > > Build string (NtBuildLab) : 7601.23418.amd64fre.win7sp1_ldr. > > PsActiveProcessHead : 0xfffff80001e31420 (1 processes) > > PsLoadedModuleList : 0xfffff80001e4f730 (52 modules) > > KernelBase : 0xfffff80001c0d000 (Matches MZ: True) > > Major (OptionalHeader) : 6 > > Minor (OptionalHeader) : 1 > > KPCR : 0xfffff80001dfbd00 (CPU 0) > > > > ************************************************** > > Instantiating KDBG using: Kernel AS Win2008R2SP1x64 (6.1.7601 64bit) > > Offset (V) : 0xf80001dfa110 > > Offset (P) : 0x1dfa110 > > KDBG owner tag check : True > > Profile suggestion (KDBGHeader): Win7SP0x64 > > Version64 : 0xf80001dfa0e8 (Major: 15, Minor: 7601) > > Service Pack (CmNtCSDVersion) : 1 > > Build string (NtBuildLab) : 7601.23418.amd64fre.win7sp1_ldr. > > PsActiveProcessHead : 0xfffff80001e31420 (1 processes) > > PsLoadedModuleList : 0xfffff80001e4f730 (52 modules) > > KernelBase : 0xfffff80001c0d000 (Matches MZ: True) > > Major (OptionalHeader) : 6 > > Minor (OptionalHeader) : 1 > > KPCR : 0xfffff80001dfbd00 (CPU 0) > > > > ************************************************** > > Instantiating KDBG using: Kernel AS Win2008R2SP1x64 (6.1.7601 64bit) > > Offset (V) : 0xf80001dfa110 > > Offset (P) : 0x1dfa110 > > KDBG owner tag check : True > > Profile suggestion (KDBGHeader): Win2008R2SP1x64 > > Version64 : 0xf80001dfa0e8 (Major: 15, Minor: 7601) > > Service Pack (CmNtCSDVersion) : 1 > > Build string (NtBuildLab) : 7601.23418.amd64fre.win7sp1_ldr. > > PsActiveProcessHead : 0xfffff80001e31420 (1 processes) > > PsLoadedModuleList : 0xfffff80001e4f730 (52 modules) > > KernelBase : 0xfffff80001c0d000 (Matches MZ: True) > > Major (OptionalHeader) : 6 > > Minor (OptionalHeader) : 1 > > KPCR : 0xfffff80001dfbd00 (CPU 0) > > > > ************************************************** > > Instantiating KDBG using: Kernel AS Win2008R2SP1x64 (6.1.7601 64bit) > > Offset (V) : 0xf80001dfa110 > > Offset (P) : 0x1dfa110 > > KDBG owner tag check : True > > Profile suggestion (KDBGHeader): Win2008R2SP0x64 > > Version64 : 0xf80001dfa0e8 (Major: 15, Minor: 7601) > > Service Pack (CmNtCSDVersion) : 1 > > Build string (NtBuildLab) : 7601.23418.amd64fre.win7sp1_ldr. > > PsActiveProcessHead : 0xfffff80001e31420 (1 processes) > > PsLoadedModuleList : 0xfffff80001e4f730 (52 modules) > > KernelBase : 0xfffff80001c0d000 (Matches MZ: True) > > Major (OptionalHeader) : 6 > > Minor (OptionalHeader) : 1 > > KPCR : 0xfffff80001dfbd00 (CPU 0) > > > > > > > > > > > > > > Kim Palechek, CISSP, CEH > > IT Security Operations Specialist, (Information Security, Risk and Compliance) > > 3M Information Technology > > 3M Center, Bldg, 0224-04-E-21 > > Phone: 736-6526 > > kspalechek(a)mmm.com > > > > The absence of evidence is not the evidence of absence. > > > > On 7/25/16, 10:53 AM, "Michael Ligh" <michael.ligh(a)mnin.org> wrote: > > > > Hi Kim, > > > > Could you run kdbgscan --profile=Win2008R2SP1x64 on it and paste the > > results? > > > > Also, do you know what tool was used for acquisition? My gut feeling is > > this is probably related to a bad capture, but I'll wait on the kdbgscan > > results to tell for sure. > > > > Thanks, > > Michael > > > > On 7/25/16 7:42 AM, Kim Palechek wrote: > > > I need some assistance with an issue that I recently came across. I am > > > trying to run volatility plugins against the image Win2008R2SP1x64 and > > > it doesn’t seem to be providing complete information. Below are a few > > > examples. Any ideas on the ‘lack of information’? > > > > > > > > > > > > > > > > > > $ *vol.py pstree* > > > > > > Volatility Foundation Volatility Framework 2.5 > > > > > > Name Pid PPid > > > Thds Hnds Time > > > > > > -------------------------------------------------- ------ ------ ------ > > > ------ ---- > > > > > > 0xfffffa8024e15040: 0 0 0 > > > ------ 1970-01-01 00:00:00 UTC+0000 > > > > > > > > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > > > > $ *vol.py psscan* > > > > > > Volatility Foundation Volatility Framework 2.5 > > > > > > Offset(P) Name PID PPID PDB > > > Time created Time exited > > > > > > ------------------ ---------------- ------ ------ ------------------ > > > ------------------------------ ------------------------------ > > > > > > 0x00000000023551b0 conhost.exe 13692 372 0x0000000058bbe000 > > > 2016-07-18 18:05:03 UTC+0000 2016-07-18 18:06:09 UTC+0000 > > > > > > 0x000000000235b060 WmiPrvSE.exe 4540 636 0x00000000b4803000 > > > 2016-07-18 18:06:51 UTC+0000 2016-07-18 18:08:23 UTC+0000 > > > > > > > > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > > > > > > > > > > $ *vol.py pslist* > > > > > > Volatility Foundation Volatility Framework 2.5 > > > > > > Offset(V) Name PID PPID Thds Hnds > > > Sess Wow64 Start Exit > > > > > > ------------------ -------------------- ------ ------ ------ -------- > > > ------ ------ ------------------------------ ------------------------------ > > > > > > 0xfffffa8024e15040 0 0 0 -------- > > > ------ 0 > > > > > > > > > > > > > > > > > > */Kim Palechek, CISSP, CEH > > > /*IT Security Operations Specialist, (Information Security, Risk and > > > Compliance) > > > 3M Information Technology > > > 3M Center, Bldg, 0224-04-E-21 > > > Phone: 736-6526 > > > kspalechek(a)mmm.com <mailto:kspalechek@mmm.com> > > > > > > > > > > > > The absence of evidence is not the evidence of absence. > > > > > > > 3M security scanners have not detected any malicious content in this message. > > > > To report this email as SPAM, please forward it to spam(a)websense.com > > > > 3M security scanners have not detected any malicious content in this message. > > To report this email as SPAM, please forward it to spam(a)websense.com >

8 years, 9 months

1
0
0 0

Re: Win2008R2SP1x64 is showing lack of informationwhen runningplugins.

by Michael Ligh

Hi Kim, Yes, unfortunately we're only able to enumerate 1 process in the linked list. This typically happens when the acquisition tool fails to acquire one or more pages of memory containing the necessary puzzle pieces (or "links"). In some cases, if its a minor smearing issue, you can still salvage some data by using psscan, which does a brute force scan of the entire memory dump for processes (even if they aren't linked). However, I noticed your psscan results only had 2 entries. This means the acquisition tool failed to acquire a whole lot more than just a couple pages. In the past, we've seen that happen quite a bit with DumpIt, FTK Imager, and Memoryze. Do you still have access to the suspect machine by any chance? Thanks, Michael On 7/25/16 11:07 AM, Kim Palechek wrote: > Thank you so much for getting back so quickly. Below are the results of the kdbgscan. Encase is the tool used for acquisition. > > > ************************************************** > Instantiating KDBG using: Kernel AS Win2008R2SP1x64 (6.1.7601 64bit) > Offset (V) : 0xf80001dfa110 > Offset (P) : 0x1dfa110 > KDBG owner tag check : True > Profile suggestion (KDBGHeader): Win7SP1x64 > Version64 : 0xf80001dfa0e8 (Major: 15, Minor: 7601) > Service Pack (CmNtCSDVersion) : 1 > Build string (NtBuildLab) : 7601.23418.amd64fre.win7sp1_ldr. > PsActiveProcessHead : 0xfffff80001e31420 (1 processes) > PsLoadedModuleList : 0xfffff80001e4f730 (52 modules) > KernelBase : 0xfffff80001c0d000 (Matches MZ: True) > Major (OptionalHeader) : 6 > Minor (OptionalHeader) : 1 > KPCR : 0xfffff80001dfbd00 (CPU 0) > > ************************************************** > Instantiating KDBG using: Kernel AS Win2008R2SP1x64 (6.1.7601 64bit) > Offset (V) : 0xf80001dfa110 > Offset (P) : 0x1dfa110 > KDBG owner tag check : True > Profile suggestion (KDBGHeader): Win7SP0x64 > Version64 : 0xf80001dfa0e8 (Major: 15, Minor: 7601) > Service Pack (CmNtCSDVersion) : 1 > Build string (NtBuildLab) : 7601.23418.amd64fre.win7sp1_ldr. > PsActiveProcessHead : 0xfffff80001e31420 (1 processes) > PsLoadedModuleList : 0xfffff80001e4f730 (52 modules) > KernelBase : 0xfffff80001c0d000 (Matches MZ: True) > Major (OptionalHeader) : 6 > Minor (OptionalHeader) : 1 > KPCR : 0xfffff80001dfbd00 (CPU 0) > > ************************************************** > Instantiating KDBG using: Kernel AS Win2008R2SP1x64 (6.1.7601 64bit) > Offset (V) : 0xf80001dfa110 > Offset (P) : 0x1dfa110 > KDBG owner tag check : True > Profile suggestion (KDBGHeader): Win2008R2SP1x64 > Version64 : 0xf80001dfa0e8 (Major: 15, Minor: 7601) > Service Pack (CmNtCSDVersion) : 1 > Build string (NtBuildLab) : 7601.23418.amd64fre.win7sp1_ldr. > PsActiveProcessHead : 0xfffff80001e31420 (1 processes) > PsLoadedModuleList : 0xfffff80001e4f730 (52 modules) > KernelBase : 0xfffff80001c0d000 (Matches MZ: True) > Major (OptionalHeader) : 6 > Minor (OptionalHeader) : 1 > KPCR : 0xfffff80001dfbd00 (CPU 0) > > ************************************************** > Instantiating KDBG using: Kernel AS Win2008R2SP1x64 (6.1.7601 64bit) > Offset (V) : 0xf80001dfa110 > Offset (P) : 0x1dfa110 > KDBG owner tag check : True > Profile suggestion (KDBGHeader): Win2008R2SP0x64 > Version64 : 0xf80001dfa0e8 (Major: 15, Minor: 7601) > Service Pack (CmNtCSDVersion) : 1 > Build string (NtBuildLab) : 7601.23418.amd64fre.win7sp1_ldr. > PsActiveProcessHead : 0xfffff80001e31420 (1 processes) > PsLoadedModuleList : 0xfffff80001e4f730 (52 modules) > KernelBase : 0xfffff80001c0d000 (Matches MZ: True) > Major (OptionalHeader) : 6 > Minor (OptionalHeader) : 1 > KPCR : 0xfffff80001dfbd00 (CPU 0) > > > > > > > Kim Palechek, CISSP, CEH > IT Security Operations Specialist, (Information Security, Risk and Compliance) > 3M Information Technology > 3M Center, Bldg, 0224-04-E-21 > Phone: 736-6526 > kspalechek(a)mmm.com > > The absence of evidence is not the evidence of absence. > > On 7/25/16, 10:53 AM, "Michael Ligh" <michael.ligh(a)mnin.org> wrote: > > Hi Kim, > > Could you run kdbgscan --profile=Win2008R2SP1x64 on it and paste the > results? > > Also, do you know what tool was used for acquisition? My gut feeling is > this is probably related to a bad capture, but I'll wait on the kdbgscan > results to tell for sure. > > Thanks, > Michael > > On 7/25/16 7:42 AM, Kim Palechek wrote: > > I need some assistance with an issue that I recently came across. I am > > trying to run volatility plugins against the image Win2008R2SP1x64 and > > it doesn’t seem to be providing complete information. Below are a few > > examples. Any ideas on the ‘lack of information’? > > > > > > > > > > > > $ *vol.py pstree* > > > > Volatility Foundation Volatility Framework 2.5 > > > > Name Pid PPid > > Thds Hnds Time > > > > -------------------------------------------------- ------ ------ ------ > > ------ ---- > > > > 0xfffffa8024e15040: 0 0 0 > > ------ 1970-01-01 00:00:00 UTC+0000 > > > > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > > $ *vol.py psscan* > > > > Volatility Foundation Volatility Framework 2.5 > > > > Offset(P) Name PID PPID PDB > > Time created Time exited > > > > ------------------ ---------------- ------ ------ ------------------ > > ------------------------------ ------------------------------ > > > > 0x00000000023551b0 conhost.exe 13692 372 0x0000000058bbe000 > > 2016-07-18 18:05:03 UTC+0000 2016-07-18 18:06:09 UTC+0000 > > > > 0x000000000235b060 WmiPrvSE.exe 4540 636 0x00000000b4803000 > > 2016-07-18 18:06:51 UTC+0000 2016-07-18 18:08:23 UTC+0000 > > > > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > > > > > > $ *vol.py pslist* > > > > Volatility Foundation Volatility Framework 2.5 > > > > Offset(V) Name PID PPID Thds Hnds > > Sess Wow64 Start Exit > > > > ------------------ -------------------- ------ ------ ------ -------- > > ------ ------ ------------------------------ ------------------------------ > > > > 0xfffffa8024e15040 0 0 0 -------- > > ------ 0 > > > > > > > > > > > > */Kim Palechek, CISSP, CEH > > /*IT Security Operations Specialist, (Information Security, Risk and > > Compliance) > > 3M Information Technology > > 3M Center, Bldg, 0224-04-E-21 > > Phone: 736-6526 > > kspalechek(a)mmm.com <mailto:kspalechek@mmm.com> > > > > > > > > The absence of evidence is not the evidence of absence. > > > > 3M security scanners have not detected any malicious content in this message. > > To report this email as SPAM, please forward it to spam(a)websense.com >

8 years, 9 months

1
0
0 0

Re: Win2008R2SP1x64 is showing lack of information when running plugins.

by Michael Ligh

Hi Kim, Could you run kdbgscan --profile=Win2008R2SP1x64 on it and paste the results? Also, do you know what tool was used for acquisition? My gut feeling is this is probably related to a bad capture, but I'll wait on the kdbgscan results to tell for sure. Thanks, Michael On 7/25/16 7:42 AM, Kim Palechek wrote: > I need some assistance with an issue that I recently came across. I am > trying to run volatility plugins against the image Win2008R2SP1x64 and > it doesn’t seem to be providing complete information. Below are a few > examples. Any ideas on the ‘lack of information’? > > > > > > $ *vol.py pstree* > > Volatility Foundation Volatility Framework 2.5 > > Name Pid PPid > Thds Hnds Time > > -------------------------------------------------- ------ ------ ------ > ------ ---- > > 0xfffffa8024e15040: 0 0 0 > ------ 1970-01-01 00:00:00 UTC+0000 > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > $ *vol.py psscan* > > Volatility Foundation Volatility Framework 2.5 > > Offset(P) Name PID PPID PDB > Time created Time exited > > ------------------ ---------------- ------ ------ ------------------ > ------------------------------ ------------------------------ > > 0x00000000023551b0 conhost.exe 13692 372 0x0000000058bbe000 > 2016-07-18 18:05:03 UTC+0000 2016-07-18 18:06:09 UTC+0000 > > 0x000000000235b060 WmiPrvSE.exe 4540 636 0x00000000b4803000 > 2016-07-18 18:06:51 UTC+0000 2016-07-18 18:08:23 UTC+0000 > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > > $ *vol.py pslist* > > Volatility Foundation Volatility Framework 2.5 > > Offset(V) Name PID PPID Thds Hnds > Sess Wow64 Start Exit > > ------------------ -------------------- ------ ------ ------ -------- > ------ ------ ------------------------------ ------------------------------ > > 0xfffffa8024e15040 0 0 0 -------- > ------ 0 > > > > > > */Kim Palechek, CISSP, CEH > /*IT Security Operations Specialist, (Information Security, Risk and > Compliance) > 3M Information Technology > 3M Center, Bldg, 0224-04-E-21 > Phone: 736-6526 > kspalechek(a)mmm.com <mailto:kspalechek@mmm.com> > > > > The absence of evidence is not the evidence of absence. >

8 years, 9 months

1
0
0 0

Shimcache plugin - no entries

by Erika Noerenberg

Hello all, I am analyzing a memory dump and looking at execution in a period of known bad activity, and have been able to gather quite a bit of information using volatility. For some reason though, shimcache and psscan return no results, although all the other plugins I've run (and volshell) have worked fine. I find it hard to believe that psscan for one can find no _EPROCESS structures, so I'm not sure what's happening. Also, in the results from the timeliner, I have several entries with blank shimcache entries like "macb,---------------,0,0,0,"[SHIMCACHE] "" during times I can correlate with shimcache entries on disk, so I know something is just not being picked up. Any ideas on why shimcache/psscan would produce no results? I'm not sure about the best way to track down the reason. Thanks! Erika

8 years, 9 months

5
5
0 0

Re: Problem with Windows 10 analysis

by Klaus Möller

On Donnerstag, 23. Juni 2016, 13:49:58 wrote Klaus Möller: > Hi, > > I've a problem with an image from a Microsoft Surface tablet. > I've verified that the OS is Windows 10 Pro 64Bit, After a few more hours, here's the "output" from netscan: $ vol.py --tz=CET --profile=Win10x64 -f /srv/evidence/memdump.mem --kdbg=0xf8033ca31a14 netscan Volatility Foundation Volatility Framework 2.5 Offset(P) Proto Local Address Foreign Address State Pid Owner Created ? 2016-06-06 18:03:41 CEST+0200 *:* 512 ? 0xe0008817c4c0 UDPv4 0.0.0.0:0 *:* 980 ?j? 2016-06-15 08:13:14 CEST+0200 0xe0008817c4c0 UDPv6 :::0 *:* 980 ?j? 2016-06-15 08:13:14 CEST+0200 0xe00088d67c90 UDPv6 ::1:16528 *:* 1168 ??q? 2016-06-15 14:19:21 CEST+0200 0xe00089d8f330 UDPv4 0.0.0.0:0 *:* 980 ?j? 2016-06-16 12:32:29 CEST+0200 0xe00089d8f330 UDPv6 :::0 *:* 980 ?j? 2016-06-16 12:32:29 CEST+0200 ? 2016-06-06 18:03:41 CEST+0200 *:* 512 ? ? 2016-06-06 18:03:41 CEST+0200 *:* 512 ? ? 2016-06-06 18:03:41 CEST+0200 *:* 512 ? same problems here: the command takes hours to complete and the output strings are garbled. Best regards, Klaus Möller, DFN-CERT -- Dipl. Inform. Klaus Moeller (Consulting Analysis Training Team) Phone: +49 40 808077-555, Fax: +49 40 808077-556 DFN-CERT Services GmbH, https://www.dfn-cert.de/, Phone +49 40 808077-555 Sitz / Register: Hamburg, AG Hamburg, HRB 88805, Ust-IdNr.: DE 232129737 Sachsenstrasse 5, 20097 Hamburg/Germany, CEO: Dr. Klaus-Peter Kossakowski Wir sind auf der it-sa: 18.-20.10.2016 http://www.it-sa.de

8 years, 10 months

1
0
0 0

Problem with Windows 10 analysis

by Klaus Möller

Hi, I've a problem with an image from a Microsoft Surface tablet. I've verified that the OS is Windows 10 Pro 64Bit, and "imageinfo" confirms that: Suggested Profile(s) : Win10x64 AS Layer1 : AMD64PagedMemory (Kernel AS) AS Layer2 : FileAddressSpace (/srv/evidence/memdump.mem) PAE type : No PAE DTB : 0x1ab000L KUSER_SHARED_DATA : 0xfffff78000000000L Image date and time : 2016-06-16 12:52:11 CEST+0200 Image local date and time : 2016-06-16 12:52:11 +0200 However, all comands take hours to complete, imageinfo took about an hour, kdbgscan was closer to 10 hours (I let it run through the night). $ ./vol.py --tz=CET --profile=Win10x64 -f /srv/evidence//memdump.mem kdbgscan Volatility Foundation Volatility Framework 2.5 ************************************************** Instantiating KDBG using: Unnamed AS Win10x64 (6.4.9841 64bit) Offset (V) : 0xf8033cb38a60 Offset (P) : 0x268d38a60 KdCopyDataBlock (V) : 0xf8033c9965d0 Block encoded : Yes Wait never : 0x1d323b0baac9580 Wait always : 0xf0e3591e003a646a KDBG owner tag check : False Profile suggestion (KDBGHeader): Win10x64 Service Pack (CmNtCSDVersion) : - Build string (NtBuildLab) : - PsActiveProcessHead : 0xb276fbddbd63c845 (0 processes) PsLoadedModuleList : 0xf249d7ddbd63c805 (0 modules) KernelBase : 0xfe52e3ddbd63c885 (Matches MZ: False) Major (OptionalHeader) : - Minor (OptionalHeader) : - ************************************************** Instantiating KDBG using: Unnamed AS Win10x64 (6.4.9841 64bit) Offset (V) : 0xf8033cb38a60 Offset (P) : 0x268d38a60 KdCopyDataBlock (V) : 0xf8033ca31a14 Block encoded : Yes Wait never : 0xf0e3591e003a646a Wait always : 0x1d323b0baac9580 KDBG owner tag check : True Profile suggestion (KDBGHeader): Win10x64 Version64 : 0xf8033cb38dc0 (Major: 15, Minor: 10586) Service Pack (CmNtCSDVersion) : 0 Build string (NtBuildLab) : 10586.306.amd64fre.th2_release_s PsActiveProcessHead : 0xfffff8033cb4d160 (91 processes) PsLoadedModuleList : 0xfffff8033cb52cd0 (202 modules) KernelBase : 0xfffff8033c874000 (Matches MZ: True) Major (OptionalHeader) : 10 Minor (OptionalHeader) : 0 KPCR : 0xfffff8033cb91000 (CPU 0) KPCR : 0xffffd001cc54a000 (CPU 1) KPCR : 0xffffd001cc5c9000 (CPU 2) KPCR : 0xffffd001cc648000 (CPU 3) I think the later part is the right one, but when I run pslist with the value for KdCopyDataBlock, I get something like this, using other options/values simply gives empty output. $ ./vol.py --tz=CET --profile=Win10x64 -f /srv/evidence/memdump.mem --kdbg=0xf8033ca31a14 psscan Volatility Foundation Volatility Framework 2.5 Offset(P) Name PID PPID PDB Time created Time exited ------------------ ---------------- ------ ------ ------------------ ------------------------------ ------------------------------ 0x0000c001edeb7bce 42...2 23...8 0x6b76ffffffd80000 5914-08-12 10:20:02 CET+0100 0x0000c001eed47b6e o 42...2 57...7 0x2b30fffffff00000 9767-04-28 16:32:54 CET+0100 0x0000e00087491680 4 0 0x00000000001ab000 2016-06-06 18:03:31 CEST+0200 0x0000e0008765d7c0 0?? 3600 3524 0x000000017ccc3000 2016-06-06 18:03:44 CEST+0200 0x0000e000876657c0 ??e? 3608 3600 0x000000017ccf8000 2016-06-06 18:03:44 CEST+0200 0x0000e00087f73080 7200 4812 0x00000001cbc8e000 2016-06-07 23:07:21 CEST+0200 0x0000e000897597c0 ??s? 372 4 0x0000000250219000 2016-06-06 18:03:31 CEST+0200 0x0000e0008a27f7c0 6012 5208 0x0000000200ad7000 2016-06-06 18:13:22 CEST+0200 0x0000e0008a2c45c0 ?;? 6088 700 0x00000001f4eeb000 2016-06-06 18:10:22 CEST+0200 0x0000e0008a3067c0 4260 6572 0x00000001edf60000 2016-06-06 23:16:37 CEST+0200 0x0000e0008cbc67c0 P??? 2564 700 0x0000000173299000 2016-06-06 18:03:41 CEST+0200 0x0000e0008cf997c0 ??|? 2780 700 0x000000013a0e0000 2016-06-06 18:03:41 CEST+0200 I can't say wether the addresses and pids (the first two ones look bad) are correct, but the process name field surely does not look good. Any ideas? Best regards, Klaus Möller, DFN-CERT -- Dipl. Inform. Klaus Moeller (Consulting Analysis Training Team) Phone: +49 40 808077-555, Fax: +49 40 808077-556 DFN-CERT Services GmbH, https://www.dfn-cert.de/, Phone +49 40 808077-555 Sitz / Register: Hamburg, AG Hamburg, HRB 88805, Ust-IdNr.: DE 232129737 Sachsenstrasse 5, 20097 Hamburg/Germany, CEO: Dr. Klaus-Peter Kossakowski Wir sind auf der it-sa: 18.-20.10.2016 http://www.it-sa.de

8 years, 10 months

1
0
0 0

IE / index.dat - DEST records?

by Andrew Case

Has anyone encountered DEST records in index.dat files? I looked at the source code and docs of open source tools that parse index.dat/MSHIST files and I don't see any reference to DEST records... I ask as I was digging around a memory sample that I generated to look at IE records, and saw this: 0x04517313 a7 c2 cf 11 bf f4 44 45 53 54 00 00 16 00 08 00 ......DEST...... 0x04517323 66 63 03 00 00 00 da 00 68 63 28 00 01 00 82 00 fc......hc(..... 0x04517333 00 00 c2 c5 41 6e 03 c7 d1 01 c2 cd 17 57 2d c7 ....An.......W-. 0x04517343 d1 01 01 00 00 00 00 00 00 00 00 00 00 00 3a 00 ..............:. 0x04517353 32 00 30 00 31 00 36 00 30 00 36 00 31 00 35 00 2.0.1.6.0.6.1.5. 0x04517363 32 00 30 00 31 00 36 00 30 00 36 00 31 00 36 00 2.0.1.6.0.6.1.6. 0x04517373 3a 00 20 00 56 00 61 00 41 00 41 00 41 00 40 00 :...S.a.l.t.r.@. 0x04517383 68 00 74 00 74 00 70 00 3a 00 2f 00 2f 00 77 00 h.t.t.p.:././.w. 0x04517393 77 00 77 00 2e 00 6e 00 62 00 63 00 2e 00 63 00 w.w...n.b.c...c. 0x045173a3 6f 00 6d 00 2f 00 00 00 4e 00 42 00 43 00 20 00 o.m./...N.B.C... 0x045173b3 54 00 56 00 20 00 4e 00 65 00 74 00 77 00 6f 00 T.V...N.e.t.w.o. 0x045173c3 72 00 6b 00 20 00 2d 00 20 00 53 00 68 00 6f 00 r.k...-...S.h.o. 0x045173d3 77 00 73 00 2c 00 20 00 45 00 70 00 69 00 73 00 w.s.,...E.p.i.s. 0x045173e3 6f 00 64 00 65 00 73 00 2c 00 20 00 53 00 63 00 o.d.e.s.,...S.c. 0x045173f3 68 00 65 00 64 00 75 00 6c 00 65 00 00 00 00 00 h.e.d.u.l.e..... The strings are in unicode, but you can see the DEST marker followed by binary timestamps, followed by the traditional hist format of DATEDATE:machine@URL .... If DEST records don't appear on disk, then maybe they are a memory-only data structure? I would like to convert carving for these into a Volatility plugin, but I want to make sure I understand any prior work on them first. -- Thanks, Andrew (@attrc)

8 years, 10 months

1
0
0 0

RDP activity in memory

by Jarle Thorsen

I'm analyzing a Vista SP2 system that was compromised via a Remote Desktop login (somehow the culprit had access to correct login credentials). Security.evtx only contains information about this single illegal login (and there is no indications that the eventlog was cleared) The strange thing is that carving though memory for network packets (using CapLoader) I find packets showing RDP traffic to additional IPs, not only the one found in Security.evtx Any help in trying to put some contex around these additional IPs found in memory, using volatility, or traditional disk forensics is highly appreciated! (The machine had only been running for about a week before the intrusion, so anything found in memory should in theory be backed up by information in eventlog) Jarle Thorsen

8 years, 10 months

2
1
0 0

Windows 7 Hibernation File

by Kevin Marker

All, I have a hibernation file from a Windows 7 machine that when I run hibinfo against it, I get the output below. Has anyone seen this before? I'm using the latest version of volatility from github, as of today. The command I used was vol.py -f hiberfil.sys --profile==Win7SP1x86 hibinfo. Other plugins fail as well. Converting the file to raw format using imagecopy and using other plugins didn't work either. Thanks for the help!Kevin No suitable address space mapping found Tried to open image as: MachOAddressSpace: mac: need base LimeAddressSpace: lime: need base WindowsHiberFileSpace32: No base Address Space WindowsCrashDumpSpace64BitMap: No base Address Space WindowsCrashDumpSpace64: No base Address Space HPAKAddressSpace: No base Address Space VMWareMetaAddressSpace: No base Address Space VirtualBoxCoreDumpElf64: No base Address Space VMWareAddressSpace: No base Address Space QemuCoreDumpElf: No base Address Space WindowsCrashDumpSpace32: No base Address Space AMD64PagedMemory: No base Address Space IA32PagedMemoryPae: No base Address Space IA32PagedMemory: No base Address Space OSXPmemELF: No base Address Space MachOAddressSpace: MachO Header signature invalid LimeAddressSpace: Invalid Lime header signature WindowsHiberFileSpace32: No xpress signature found WindowsCrashDumpSpace64BitMap: Header signature invalid WindowsCrashDumpSpace64: Header signature invalid HPAKAddressSpace: Invalid magic found VMWareMetaAddressSpace: VMware metadata file is not available VirtualBoxCoreDumpElf64: ELF Header signature invalid VMWareAddressSpace: Invalid VMware signature: 0x0 QemuCoreDumpElf: ELF Header signature invalid WindowsCrashDumpSpace32: Header signature invalid AMD64PagedMemory: Incompatible profile Win7SP1x86 selected IA32PagedMemoryPae: No valid DTB found IA32PagedMemory: No valid DTB found OSXPmemELF: ELF Header signature invalid FileAddressSpace: Must be first Address Space ArmAddressSpace: No valid DTB found

8 years, 10 months

3
2
0 0

linux_netstat

by Thomas Hungenberg

Hi, I've recently used linux_netstat with different Linux memory images and noticed that the destination port for established outgoing connections is always shown as "0". The source port for incoming connections is shown correctly. Any way to fix this and get the correct destination port for outgoing connections? Thanks, Thomas

8 years, 10 months

2
2
0 0

Re: [Vol-users] OSX and Volatility

by Andrew Case

Okay, is there anyway you can run the source version? The latest Volatility should support the profile you are trying. Thanks, Andrew (@attrc) On 06/03/2016 09:38 AM, Rob Hunter wrote: > Hi Andrew, > > This is the output I get . > regards, > Rob > > ./volatility_2.5_mac --plugins=./mac -f ../ram.dump mac_get_profile -d > Volatility Foundation Volatility Framework 2.5 > DEBUG : volatility.debug : Applying modification from > BasicObjectClasses > DEBUG : volatility.debug : Applying modification from BigPageTableMagic > DEBUG : volatility.debug : Applying modification from > ControlAreaModification > DEBUG : volatility.debug : Applying modification from ELF32Modification > DEBUG : volatility.debug : Applying modification from ELF64Modification > DEBUG : volatility.debug : Applying modification from ELFModification > DEBUG : volatility.debug : Applying modification from > EditBoxObjectClasses > DEBUG : volatility.debug : Applying modification from EditBoxVTypes > DEBUG : volatility.debug : Applying modification from HPAKVTypes > DEBUG : volatility.debug : Applying modification from > HandleTableEntryPreWin8 > DEBUG : volatility.debug : Applying modification from IEHistoryVTypes > DEBUG : volatility.debug : Applying modification from LimeTypes > DEBUG : volatility.debug : Applying modification from MachoModification > DEBUG : volatility.debug : Applying modification from MachoTypes > DEBUG : volatility.debug : Applying modification from MbrObjectTypes > DEBUG : volatility.debug : Applying modification from > PoolTagModification > DEBUG : volatility.debug : Applying modification from > PoolTrackTagOverlay > DEBUG : volatility.debug : Applying modification from > SSLKeyModification > DEBUG : volatility.debug : Applying modification from > UnloadedDriverVTypes > DEBUG : volatility.debug : Applying modification from > VMwareVTypesModification > DEBUG : volatility.debug : Applying modification from > VirtualBoxModification > DEBUG : volatility.debug : Applying modification from Win32KGahtiVType > DEBUG : volatility.debug : Applying modification from Win32Kx86VTypes > DEBUG : volatility.debug : Applying modification from > WinSyscallsAttribute > DEBUG : volatility.debug : Applying modification from > WinXP2003AddressObject > DEBUG : volatility.debug : Applying modification from WinXPSyscalls > DEBUG : volatility.debug : Applying modification from > XP2003x86BaseVTypes > DEBUG : volatility.debug : Applying modification from > XP2003x86TimerVType > DEBUG : volatility.debug : Applying modification from WindowsVTypes > DEBUG : volatility.debug : Applying modification from > AtomTablex86Overlay > DEBUG : volatility.debug : Applying modification from EVTObjectTypes > DEBUG : volatility.debug : Applying modification from > ObjectTypeKeyModification > DEBUG : volatility.debug : Applying modification from > ProcessAuditVTypes > DEBUG : volatility.debug : Applying modification from WindowsOverlay > DEBUG : volatility.debug : Applying modification from CallbackMods > DEBUG : volatility.debug : Applying modification from MalwarePspCid > DEBUG : volatility.debug : Applying modification from MalwareWSPVTypes > DEBUG : volatility.debug : Applying modification from TimerVTypes > DEBUG : volatility.debug : Applying modification from TokenXP2003 > DEBUG : volatility.debug : Applying modification from UserAssistVTypes > DEBUG : volatility.debug : Applying modification from > VadFlagsModification > DEBUG : volatility.debug : Applying modification from > VadTagModification > DEBUG : volatility.debug : Applying modification from WinAllTime > DEBUG : volatility.debug : Applying modification from > WinPEObjectClasses > DEBUG : volatility.debug : Applying modification from WinPEVTypes > DEBUG : volatility.debug : Applying modification from WinXPTrim > DEBUG : volatility.debug : Applying modification from WinXPx86Vad > DEBUG : volatility.debug : Applying modification from > WindowsObjectClasses > DEBUG : volatility.debug : Applying modification from XPOverlay > DEBUG : volatility.debug : Applying modification from > XPx86SessionOverlay > DEBUG : volatility.debug : Applying modification from AuditpolTypesXP > DEBUG : volatility.debug : Applying modification from > CmdHistoryObjectClasses > DEBUG : volatility.debug : Applying modification from > CmdHistoryVTypesx86 > DEBUG : volatility.debug : Applying modification from > CrashInfoModification > DEBUG : volatility.debug : Applying modification from > DumpFilesVTypesx86 > DEBUG : volatility.debug : Applying modification from HeapModification > DEBUG : volatility.debug : Applying modification from KDBGObjectClass > DEBUG : volatility.debug : Applying modification from > KPCRProfileModification > DEBUG : volatility.debug : Applying modification from MFTTYPES > DEBUG : volatility.debug : Applying modification from MalwareDrivers > DEBUG : volatility.debug : Applying modification from MalwareIDTGDTx86 > DEBUG : volatility.debug : Applying modification from MalwareKthread > DEBUG : volatility.debug : Applying modification from ServiceBase > DEBUG : volatility.debug : Applying modification from ShellBagsTypesXP > DEBUG : volatility.debug : Applying modification from > ShimCacheTypesXPx86 > DEBUG : volatility.debug : Applying modification from Win32KCoreClasses > DEBUG : volatility.debug : Applying modification from > XPHeapModification > Profile Shift Address > -------------------------------------------------- ------------- > DEBUG : volatility.debug : Voting round > DEBUG : volatility.debug : Trying <class > 'volatility.plugins.addrspaces.macho.MachOAddressSpace'> > DEBUG : volatility.debug : Trying <class > 'volatility.plugins.addrspaces.lime.LimeAddressSpace'> > DEBUG : volatility.debug : Trying <class > 'volatility.plugins.addrspaces.hibernate.WindowsHiberFileSpace32'> > DEBUG : volatility.debug : Trying <class > 'volatility.plugins.addrspaces.crashbmp.WindowsCrashDumpSpace64BitMap'> > DEBUG : volatility.debug : Trying <class > 'volatility.plugins.addrspaces.crash.WindowsCrashDumpSpace64'> > DEBUG : volatility.debug : Trying <class > 'volatility.plugins.addrspaces.hpak.HPAKAddressSpace'> > DEBUG : volatility.debug : Trying <class > 'volatility.plugins.addrspaces.elfcoredump.VirtualBoxCoreDumpElf64'> > DEBUG : volatility.debug : Trying <class > 'volatility.plugins.addrspaces.vmem.VMWareMetaAddressSpace'> > DEBUG : volatility.debug : Trying <class > 'volatility.plugins.addrspaces.vmware.VMWareAddressSpace'> > DEBUG : volatility.debug : Trying <class > 'volatility.plugins.addrspaces.elfcoredump.QemuCoreDumpElf'> > DEBUG : volatility.debug : Trying <class > 'volatility.plugins.addrspaces.crash.WindowsCrashDumpSpace32'> > DEBUG : volatility.debug : Trying <class > 'volatility.plugins.addrspaces.amd64.AMD64PagedMemory'> > DEBUG : volatility.debug : Trying <class > 'volatility.plugins.addrspaces.intel.IA32PagedMemoryPae'> > DEBUG : volatility.debug : Trying <class > 'volatility.plugins.addrspaces.intel.IA32PagedMemory'> > DEBUG : volatility.debug : Trying <class > 'volatility.plugins.addrspaces.osxpmemelf.OSXPmemELF'> > DEBUG : volatility.debug : Trying <class > 'volatility.plugins.addrspaces.standard.FileAddressSpace'> > DEBUG : volatility.debug : Succeeded instantiating > <volatility.plugins.addrspaces.standard.FileAddressSpace object at > 0x1179d3910> > DEBUG : volatility.debug : Voting round > DEBUG : volatility.debug : Trying <class > 'volatility.plugins.addrspaces.macho.MachOAddressSpace'> > DEBUG : volatility.debug : Trying <class > 'volatility.plugins.addrspaces.lime.LimeAddressSpace'> > DEBUG : volatility.debug : Trying <class > 'volatility.plugins.addrspaces.hibernate.WindowsHiberFileSpace32'> > DEBUG : volatility.debug : Trying <class > 'volatility.plugins.addrspaces.crashbmp.WindowsCrashDumpSpace64BitMap'> > DEBUG : volatility.debug : Trying <class > 'volatility.plugins.addrspaces.crash.WindowsCrashDumpSpace64'> > DEBUG : volatility.debug : Trying <class > 'volatility.plugins.addrspaces.hpak.HPAKAddressSpace'> > DEBUG : volatility.debug : Trying <class > 'volatility.plugins.addrspaces.elfcoredump.VirtualBoxCoreDumpElf64'> > DEBUG : volatility.debug : Trying <class > 'volatility.plugins.addrspaces.vmem.VMWareMetaAddressSpace'> > DEBUG : volatility.debug : Trying <class > 'volatility.plugins.addrspaces.vmware.VMWareAddressSpace'> > DEBUG : volatility.debug : Trying <class > 'volatility.plugins.addrspaces.elfcoredump.QemuCoreDumpElf'> > DEBUG : volatility.debug : Trying <class > 'volatility.plugins.addrspaces.crash.WindowsCrashDumpSpace32'> > DEBUG : volatility.debug : Trying <class > 'volatility.plugins.addrspaces.amd64.AMD64PagedMemory'> > DEBUG : volatility.debug : Trying <class > 'volatility.plugins.addrspaces.intel.IA32PagedMemoryPae'> > DEBUG : volatility.debug : Trying <class > 'volatility.plugins.addrspaces.intel.IA32PagedMemory'> > DEBUG : volatility.debug : Trying <class > 'volatility.plugins.addrspaces.osxpmemelf.OSXPmemELF'> > DEBUG : volatility.debug : Trying <class > 'volatility.plugins.addrspaces.standard.FileAddressSpace'> > DEBUG : volatility.debug : Trying <class > 'volatility.plugins.addrspaces.arm.ArmAddressSpace'> > ERROR : volatility.debug : Unable to find an OS X profile for the > given memory sample. > > > >> On 03 Jun 2016, at 16:30, Andrew Case <atcuno(a)gmail.com >> <mailto:atcuno@gmail.com>> wrote: >> >> As a quick check, can you verify that mac_get_profile matches the one >> you are using? Don't specify --profile when running it. >> >> Thanks, >> Andrew (@attrc) >> >> On 06/03/2016 03:09 AM, Rob Hunter wrote: >>> Hello list, >>> >>> I’m trying to use Volatility on an OSX memory dump. I was unable to >>> download mac memory reader as the site is offline. I’ve used osxpmem >>> from recall. >>> >>> The commands I used to perform the dump were: >>> >>> sudo kextutil MacPmem.kext >>> sudo ./osxpmem --format elf -o ./ram.dump >>> >>> I then moved ram.dump into my volatility directory >>> >>> To check my downloaded profile is included I’ve run the command >>> ./volatility_2.5_mac --plugins=./mac —imageinfo >>> and then I ran >>> >>> ./volatility_2.5_mac --plugins=./mac >>> --profile=MacElCapitan_10_11_4_15E65x64 -f ../ram.dump mac_pslist >>> >>> and got >>> >>> Volatility Foundation Volatility Framework 2.5 >>> Offset Name Pid Uid Gid PGID >>> Bits DTB Start Time >>> ------------------ -------------------- -------- -------- -------- >>> -------- ------------ ------------------ ---------- >>> No suitable address space mapping found >>> Tried to open image as: >>> MachOAddressSpace: mac: need base >>> LimeAddressSpace: lime: need base >>> WindowsHiberFileSpace32: No base Address Space >>> WindowsCrashDumpSpace64BitMap: No base Address Space >>> VMWareMetaAddressSpace: No base Address Space >>> WindowsCrashDumpSpace64: No base Address Space >>> HPAKAddressSpace: No base Address Space >>> VirtualBoxCoreDumpElf64: No base Address Space >>> QemuCoreDumpElf: No base Address Space >>> VMWareAddressSpace: No base Address Space >>> WindowsCrashDumpSpace32: No base Address Space >>> AMD64PagedMemory: No base Address Space >>> IA32PagedMemoryPae: No base Address Space >>> IA32PagedMemory: No base Address Space >>> OSXPmemELF: No base Address Space >>> MachOAddressSpace: MachO Header signature invalid >>> LimeAddressSpace: Invalid Lime header signature >>> WindowsHiberFileSpace32: PO_MEMORY_IMAGE is not available in profile >>> WindowsCrashDumpSpace64BitMap: Header signature invalid >>> VMWareMetaAddressSpace: VMware metadata file is not available >>> WindowsCrashDumpSpace64: Header signature invalid >>> HPAKAddressSpace: Invalid magic found >>> VirtualBoxCoreDumpElf64: ELF Header signature invalid >>> QemuCoreDumpElf: ELF Header signature invalid >>> VMWareAddressSpace: Invalid VMware signature: 0x4034b50 >>> WindowsCrashDumpSpace32: Header signature invalid >>> AMD64PagedMemory: Failed valid Address Space check >>> IA32PagedMemoryPae: Failed valid Address Space check >>> IA32PagedMemory: Failed valid Address Space check >>> OSXPmemELF: ELF Header signature invalid >>> FileAddressSpace: Must be first Address Space >>> ArmAddressSpace: Failed valid Address Space check >>> >>> >>> Apparently my OSXPmemElf signature is invalid. What can I do to dump >>> memory with a valid signature? Or does my problem lie elsewhere? >>> >>> Regards, >>> Rob >>> >>> >>> _______________________________________________ >>> Vol-users mailing list >>> Vol-users(a)volatilityfoundation.org <mailto:Vol-users@volatilityfoundation.org> >>> http://lists.volatilityfoundation.org/mailman/listinfo/vol-users >>> >

8 years, 10 months

1
0
0 0

OSX and Volatility

by Rob Hunter

Hello list, I’m trying to use Volatility on an OSX memory dump. I was unable to download mac memory reader as the site is offline. I’ve used osxpmem from recall. The commands I used to perform the dump were: sudo kextutil MacPmem.kext sudo ./osxpmem --format elf -o ./ram.dump I then moved ram.dump into my volatility directory To check my downloaded profile is included I’ve run the command ./volatility_2.5_mac --plugins=./mac —imageinfo and then I ran ./volatility_2.5_mac --plugins=./mac --profile=MacElCapitan_10_11_4_15E65x64 -f ../ram.dump mac_pslist and got Volatility Foundation Volatility Framework 2.5 Offset Name Pid Uid Gid PGID Bits DTB Start Time ------------------ -------------------- -------- -------- -------- -------- ------------ ------------------ ---------- No suitable address space mapping found Tried to open image as: MachOAddressSpace: mac: need base LimeAddressSpace: lime: need base WindowsHiberFileSpace32: No base Address Space WindowsCrashDumpSpace64BitMap: No base Address Space VMWareMetaAddressSpace: No base Address Space WindowsCrashDumpSpace64: No base Address Space HPAKAddressSpace: No base Address Space VirtualBoxCoreDumpElf64: No base Address Space QemuCoreDumpElf: No base Address Space VMWareAddressSpace: No base Address Space WindowsCrashDumpSpace32: No base Address Space AMD64PagedMemory: No base Address Space IA32PagedMemoryPae: No base Address Space IA32PagedMemory: No base Address Space OSXPmemELF: No base Address Space MachOAddressSpace: MachO Header signature invalid LimeAddressSpace: Invalid Lime header signature WindowsHiberFileSpace32: PO_MEMORY_IMAGE is not available in profile WindowsCrashDumpSpace64BitMap: Header signature invalid VMWareMetaAddressSpace: VMware metadata file is not available WindowsCrashDumpSpace64: Header signature invalid HPAKAddressSpace: Invalid magic found VirtualBoxCoreDumpElf64: ELF Header signature invalid QemuCoreDumpElf: ELF Header signature invalid VMWareAddressSpace: Invalid VMware signature: 0x4034b50 WindowsCrashDumpSpace32: Header signature invalid AMD64PagedMemory: Failed valid Address Space check IA32PagedMemoryPae: Failed valid Address Space check IA32PagedMemory: Failed valid Address Space check OSXPmemELF: ELF Header signature invalid FileAddressSpace: Must be first Address Space ArmAddressSpace: Failed valid Address Space check Apparently my OSXPmemElf signature is invalid. What can I do to dump memory with a valid signature? Or does my problem lie elsewhere? Regards, Rob

8 years, 10 months

2
1
0 0

Specifying additional profiles for the standalone mac version of volatility

by Rob Hunter

Dear list, Is it possible to extend the built in profiles for the standalone mac version of volatility with extra ones? I’ve downloaded the linux and mac profiles from github and tried putting them in a subdirectory as with the source code version on Linux i.e. volatility_2.5.mac.standalone/volatility/plugins/overlays/mac However they don’t show up in the profile list when I run volatility_2.5.mac.standalone —info Regards, Rob

8 years, 10 months

2
2
0 0

Password recovery from memory dump

by Massimo Canonico

Hi, thanks to your suggestion, I make great progresses but I still not get the target: localize the master password of an android app. I run the app and set a password as "mypassword2016". With yarascan I was able to see that this password is store in memory in unicode (I run "python vol.py linux_yarascan -W -A -Y "mypassword2016""). Then, I would like to see if there some "signature" that helps me to locate the password. So I decide to use volshell and see around the passwod, but I have no luck (see the attachment, where I showed that there is before and after of the two occurrences of the password "mypassword2016"). Of course I've repeated the same workflow for other two passwords, but I did not get anything that helps me to figure out if there is way to locate where the password is store. Do you have any suggestion, please? Thanks in advance, Massimo

8 years, 10 months

1
1
0 0

Re: [Vol-users] [Newbie] Searching for specific IP addresses in memory (Win2008 R2)

by Michael Ligh

Hi Laurent, Not necessarily. You're assuming that everything once in memory stays in memory...which isn't the case. If you have an IP and you pass it to ws2_32.connect() and then free or overwrite the memory containing the IP...the connection stays up and running just fine. It could also be swapped to the page file. MHL On 5/17/16 5:14 AM, Laurent LF wrote: > Thanks Michael, > > What I don't understand is that yarascan on the "IP to integer" value on > the full mem dump gives a result in the svchost process only and not > anywhere else. I should have at least two occurences, one in the svchost > process and one other in the System process, right ? > > Thanks, > > Laurent > > > On 2016-05-12 23:18, Michael Ligh wrote: >> I can't speak to whether its "normal" but its not surprising. The System >> process is the default home for threads that start in kernel mode. Thus >> any kernel driver using the winsock APIs for networking will make it >> appear as if the System process is responsible. Now combine that with a >> DLL that's implementing a particular service (and running inside >> svchost.exe process) who wants to communicate with its corresponding >> driver...it could send an IOCTL and say "go connect to this x.x.x.x IP >> address." In that case you could easily end up with a reference to the >> IP in svchost.exe. >> >> MHL >> >> On 5/10/16 2:34 PM, Laurent LF wrote: >>> Hi, >>> >>> I have progressed a bit on this. >>> I was first limiting my IP addresses searches on the process returned by >>> "netscan", which was "System" with pid=4. As I was convinced I should >>> have got some results within "System", I supposed I was wrong with the >>> syntax or the IP representation and made several other tries (IP as >>> string, little indian ordering as suggested by Andrew,...), still with >>> pid=4. I also made a few tries on the whole memory dump but with no >>> luck. It looks like I was doing something wrong because today I made >>> some tries again on full memory dump and finally found the IPs (Big >>> Indian ordering) in ... a "svchost" process. >>> >>> I still need to go deeper in the analysis (as far as my little knowledge >>> will allow me to go :-) ) but is it normal behavior to have netscan >>> reporting some connections linked with "System" when IP search with >>> yarascan on given IPs returns only a "svchost" process ? >>> Also, I was expecting to find references to the IPs in several memory >>> locations but only one occurence in this case, in the given svchost >>> process... >>> >>> Thanks, >>> Laurent >>> >>> >>> Le 10/05/2016 17:14, Michael Ligh a écrit : >>>> Also note yarascan only accesses available pages. The IP could be in a >>>> page that's swapped to the pagefile or in a page that's been >>>> freed/deallocated and is no longer referenced from any page >>>> table(s). In >>>> the later case, you could find it by extracting strings from the memory >>>> dump or by scanning with yara signatures across the memory dump file >>>> (i.e. not caring about virtual address spaces)...however if you find it >>>> in either of two methods, there's no way to trace the page back to its >>>> owner. >>>> >>>> MHL >>>> >>>> On 5/10/16 7:56 AM, Andrew Case wrote: >>>>> Hey, >>>>> >>>>> Did you try the IP hex value in reverse? It is likely that the IP >>>>> address is stored as little endian in memory. >>>>> >>>>> Thanks, >>>>> Andrew (@attrc) >>>>> >>>>> On 05/10/2016 05:15 AM, tech(a)nisteo.fr wrote: >>>>>> Hello, >>>>>> >>>>>> I am starting to play with Volatility (2.5) and I am currently >>>>>> working >>>>>> on a Win2008R2 image (memory dump with winpmem). I would like to >>>>>> understand what is causing some network connections initiated by the >>>>>> "System" process. >>>>>> netscan shows those connections and I would like to be able to find >>>>>> references to the IP addresses in the memory dump. I have tried >>>>>> "yarascan -Y" plugin with the IP string, with the IP to integer value >>>>>> (converted to Hex) but no luck finding IPs that , however, I can >>>>>> see in >>>>>> the netscan result... >>>>>> Either I am wrong with the yarascan syntax or there is something I >>>>>> don't >>>>>> know regarding how Win2008 stores IP... >>>>>> >>>>>> Any hints ? >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Laurent >>>>>> _______________________________________________ >>>>>> Vol-users mailing list >>>>>> Vol-users(a)volatilityfoundation.org >>>>>> http://lists.volatilityfoundation.org/mailman/listinfo/vol-users >>>>>> >>>>> _______________________________________________ >>>>> Vol-users mailing list >>>>> Vol-users(a)volatilityfoundation.org >>>>> http://lists.volatilityfoundation.org/mailman/listinfo/vol-users >>>>> >>> >>> > >

8 years, 11 months

2
4
0 0

Reading 'address' objects for Wow64 processes

by Bridgey theGeek

Hi all, Wondering if anybody's come across this scenario... I want to read an address from my_offset: my_address = obj.Object('address', offset=my_offset, vm=task_vm) However, for Wow64 the address should only be 4 bytes, but because we're analysing with a 64-bit profile, 'address' will cause 8 bytes to be parsed (right?). Do I need to replace it with something like: if profile_is_32bit or process_is_wow64: my_address = obj.Object('unsigned long', offset=my_offset, vm=task_vm) else: my_address = obj.Object('unsigned long long', offset=my_offset, vm=task_vm) Or do I need to start manually unpacking structs? Thanks, Adam

8 years, 11 months

2
1
0 0

OSDFCon CFP Reminder (now even for those who can't attend)

by Brian Carrier

The Call for Presentations for the Open Source Digital Forensics Conference (OSDFCon) ends on June 1 and we’ve just decided to have one presentation this year from someone who cannot physically attend the event. If you have a talk that you want to give about a tool you’ve developed or used, but don’t have the budget to travel to Virginia, then you can still submit. This is a test to see if we can open the event to more people. All we need for the submission is an abstract about your software, use cases, or experiences. Feel free to submit topics that were submitted in past years, but not chosen from the crowd sourcing. http://www.osdfcon.org/osdfcon-2016/2016-call-for-presentations/ We’re also looking for more hands-on workshops. A lot of attendees last year requested more hands on sessions, so if you can give a 3-hour workshop the day before, it would be a great way to get awareness for your software. thanks, brian

8 years, 11 months

1
0
0 0

Volatility capabilities to help an interesting research

by Yuval Lapidot

Hello dear volatility community, I am a ISE master student at Ben Gurion University in Israel. And I need you help. My research deals with extracting many features from a windows memory dump taken from vSphere snapshots. (Mostly Windows 2012 R2). In order to extract as many features as possible I am using volatility framework which helps me to receive the most basic features I need. I want to leverage volatility framework even more so I can extract more valuable features. Here is the list of features I want to try to extract from the memory: - Achieving the stack of all processes. or any thing that can be deduced by it, for example call sequence or function's parameters etc. - Gathering information about reading or writing actions that were happening while the snapshot was taken or before. - Find / detect usages of cryptography keys in the memory, especially asymmetric keys. - Find / detect changes in the registry. I hope this post is not too abstract, and that maybe you can help me start. I want to first know if what I am trying to do is even possible? Is volatility the right tool? If it is, where should I begin? Appreciate your help! Thanks, Yuval

8 years, 11 months

1
0
0 0

Re: [Vol-users] vm2dmp - alternative? (2008R2)

by Bridgey theGeek

That's great! Thank you so much :) On 24 May 2016 at 16:06, wyatt roersma <wyattroersma(a)gmail.com> wrote: > Yes I do. Here is the link the the exe and user guide. > https://drive.google.com/folderview?id=0Bz3L4ZnVlUY8TFdBcUljeTc4VFk > On May 24, 2016 7:13 AM, "Michael Ligh" <michael.ligh(a)mnin.org> wrote: > >> Wyatt - do you still have a copy of vm2dmp around? >> >> MHL >> >> On 5/24/16 5:55 AM, Bridgey theGeek wrote: >> > Hi all, >> > >> > I've been given a .vsv and a .bin from a Server 2008R2 box. >> > vm2dmp supposedly supported converting this into a raw image, but it >> > seems to have disappeared off the face of the planet. >> > >> > Does anybody have: >> > >> > a) A copy of vm2dmp that they're allowed to share. >> > and/or >> > b) Recommendations for an alternative tool. >> > >> > Thanks! >> > Adam >> > >> > >> > _______________________________________________ >> > Vol-users mailing list >> > Vol-users(a)volatilityfoundation.org >> > http://lists.volatilityfoundation.org/mailman/listinfo/vol-users >> > >> >>

8 years, 11 months

1
0
0 0

vm2dmp - alternative? (2008R2)

by Bridgey theGeek

Hi all, I've been given a .vsv and a .bin from a Server 2008R2 box. vm2dmp supposedly supported converting this into a raw image, but it seems to have disappeared off the face of the planet. Does anybody have: a) A copy of vm2dmp that they're allowed to share. and/or b) Recommendations for an alternative tool. Thanks! Adam

8 years, 11 months

2
1
0 0

[Newbie] Searching for specific IP addresses in memory (Win2008 R2)

by tech＠nisteo.fr

Hello, I am starting to play with Volatility (2.5) and I am currently working on a Win2008R2 image (memory dump with winpmem). I would like to understand what is causing some network connections initiated by the "System" process. netscan shows those connections and I would like to be able to find references to the IP addresses in the memory dump. I have tried "yarascan -Y" plugin with the IP string, with the IP to integer value (converted to Hex) but no luck finding IPs that , however, I can see in the netscan result... Either I am wrong with the yarascan syntax or there is something I don't know regarding how Win2008 stores IP... Any hints ? Thanks, Laurent

8 years, 11 months

4
4
0 0

[PLUGIN] Invoking other plugins

by P1kachu

Hello again, I managed to get something that guess the OS of a memory dump. I was planning to call imageinfo from it in the case of a Windows dump or get_mac_profile in case of an OSX dump (will figure out Linux later). So my questions are: - Does this kind of feature fits into Volatility, or do you prefer that the plugins follow the Single Responsability Principle ? - If not, what is the cleanest way to call a plugin from another one ? Thank you ! -- Stanislas 'P1kachu' Lejay EPITA - LSE If you're sleeping, you're doing it wrong.

8 years, 11 months

2
1
0 0

[PLUGINS] Basic requirement for a plugin to be recognized

by P1kachu

Hello, I am having some trouble loading a simple plugin with the '--plugins=.' option. It seems to be loaded (there were some errors that were fixed thanks to volatility displaying them) but it doesn't appear in the --info list. If I try this option in one of the community folder, it works (the plugins appear). What is the basic requirement for a plugin to be recognized, and what could I miss ? I started mine based on one from the community folder (CsabaBarta/usnjrnl.py) Thank you, -- Stanislas 'P1kachu' Lejay EPITA - LSE If you're sleeping, you're doing it wrong.

8 years, 11 months

4
3
0 0

windows plugin - handles - what don't I know?

by Bridgey theGeek

Hi all, Doing some work with the windows plugin for VistaSP1x86. I have the following two fragments from the output: Window Handle: #20130 at 0xfe817078, Name: ClassAtom: 0xc052, Class: ConsoleProgmanHandle SuperClassAtom: 0xc018, SuperClass: Edit pti: 0xfde11e90, Tid: 3432 at 0x839714e0 ppi: 0xff54be50, Process: explorer.exe, Pid: 2528 Visible: Yes Left: 82, Top: 456, Bottom: 379, Right: 473 Style Flags: WS_CHILD,WS_OVERLAPPED,WS_VISIBLE ExStyle Flags: WS_EX_LTRREADING,WS_EX_RIGHTSCROLLBAR,WS_EX_LEFT Window procedure: 0x7520d0d4 Window Handle: #100bc at 0xfe807390, Name: ClassAtom: 0xc052, Class: ConsoleProgmanHandle SuperClassAtom: 0xc018, SuperClass: Edit pti: 0xfe44d660, Tid: 2552 at 0x837c8778 ppi: 0xff54be50, Process: explorer.exe, Pid: 2528 Visible: No Left: 11, Top: 542, Bottom: 229, Right: 559 Style Flags: WS_CHILD,WS_OVERLAPPED ExStyle Flags: WS_EX_CLIENTEDGE,WS_EX_LTRREADING,WS_EX_RIGHTSCROLLBAR,WS_EX_LEFT Window procedure: 0x751f01c6 Both are from the same instance of explorer.exe. Viewing windows.py, it shows that the "Window Handle" is simply the value of: wnd.head.h Now consider this from volshell: >>> o1 = obj.Object('tagWND', offset=0xfe817078, vm=proc().get_process_address_space()) >>> dd(o1.head.h, length=4) fe8172a0 00020130 This seems logical: head.h is a void pointer. If we follow the pointer we get the handle: 20130. If I do the same with the other one: >>> o2 = obj.Object('tagWND', offset=0xfe807390, vm=proc().get_process_address_space()) >>> dd(o2.head.h, length=4) 000100bc 00000000 In this example, the handle is the VALUE of head.h, that is, you shouldn't follow the pointer. Volatility seems to know this because it displays the handles as 100bc rather than 0. I searched the Volatility code to see if I could find how this is being done, but I couldn't. So, how?? What rule don't I know?? Thanks!

8 years, 11 months

2
4
0 0

Investigate around a memory area

by Massimo Canonico

Hi all, I'm quite sure that there is a "standard procedure" in order to investigate a specific area of the memory once you found something useful in a specific address, but my research on volatility doc does not help me much. Here the problem. I was able to find out with yarascan and -W option (Andrew and Michael, thanks again!), where the password of a specific app is stored (see after my signature for the complete yarascan output). From this output, I can see that the password is stored from address 0xb2f771f0. I would like to see: - what is stored before the password - if this memory area is related to a specific file In other words, I would like to investigate how the app stored the password hoping that the password is always store with some criteria. Of course, I have several memory dumps, with different passwords set. The yarascan outputs (that shows me only something *after *the password) do not help me. Thanks in advance for all your help, Massimo (Here is the yarascan output. The password set is "mypassword2016") Task: ject.otr.app.im pid 1691 rule r1 addr 0xb2f771f0 0xb2f771f0 6d 00 79 00 70 00 61 00 73 00 73 00 77 00 6f 00 m.y.p.a.s.s.w.o. 0xb2f77200 72 00 64 00 32 00 30 00 31 00 36 00 00 00 00 00 r.d.2.0.1.6..... 0xb2f77210 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0xb2f77220 00 00 00 00 43 04 00 00 f0 4a b5 b2 00 00 00 00 ....C....J...... 0xb2f77230 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0xb2f77240 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0xb2f77250 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0xb2f77260 08 ff f9 b2 00 00 00 00 00 00 00 00 78 df fa b2 ............x... 0xb2f77270 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0xb2f77280 38 47 ef b2 f0 e8 d8 b2 68 76 f7 b2 00 00 00 00 8G......hv...... 0xb2f77290 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0xb2f772a0 00 00 00 00 00 ed f1 b2 68 9c f9 b2 00 00 00 00 ........h....... 0xb2f772b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0xb2f772c0 d8 e4 e2 b2 00 00 00 00 68 01 00 00 00 00 00 00 ........h....... 0xb2f772d0 00 00 00 00 ff ff ff ff ff ff ff ff ff ff ff ff ................ 0xb2f772e0 ff ff ff ff ff ff ff ff a6 02 00 80 68 01 00 40 ............h..@

8 years, 11 months

4
4
0 0

Re: [Vol-users] Analyzing memory from a QEMU snapshot

by Thomas Hungenberg

On 04.05.2016 19:11, Torres, Geoff (Cyber Security) wrote: > Hmmm... What does 'lqs2mem -l <snapshot_memfile>' show? $ lqs2mem -l snapshot.img Invalid QEMU-savevm magic Unrecogized file format $ file snapshot.img snapshot.img: QEMU suspend to disk image > When I run the lqs2mem tool, I don't get an ELF image (i.e. 'file <raw_image>' returns 'data'). But the image runs through volatility just fine. I got the ELF file from running "dump-guest-memory" on the QEMU console after loading the snapshot. - Thomas

8 years, 11 months

2
1
0 0

Analyzing memory from a QEMU snapshot

by Thomas Hungenberg

Hi, I was provided a suspend-to-disk snapshot image along with a copy of the virtual harddisk file from a QEMU/KVM-based Linux server for analysis. Analysis of the harddisk is done. Now I'd like to dump running processes etc. from the server's memory image. I loaded the snapshot into QEMU and used the QEMU monitor to dump a memory image using the 'dump-guest-memory' command. So now I have this: memory.img: ELF 64-bit LSB core file Intel 80386, version 1 (SYSV), SVR4-style Then, I set up a fresh VM with Debian Linux in the same version the virtual server was running. Next, I installed the kernel image and related files extracted from the virtual harddisk on this new VM to get a Linux system running exactly the same kernel version. On this VM, I created a Volatility profile using the files provided in /tools/linux/. Unfortunately, Volatility crashes when running imageinfo on the dumped memory image file: ========================================================================= $ python vol.py imageinfo -f /path/to/memory.img Volatility Foundation Volatility Framework 2.5 INFO : volatility.debug : Determining profile based on KDBG search... Suggested Profile(s) : No suggestion (Instantiated with Server_x64) AS Layer1 : QemuCoreDumpElf (Unnamed AS) AS Layer2 : FileAddressSpace (/path/to/memory.img) PAE type : No PAE DTB : -0x1L Traceback (most recent call last): File "vol.py", line 192, in <module> main() File "vol.py", line 183, in main command.execute() File "/opt/tools/volatility-master/volatility/commands.py", line 145, in execute func(outfd, data) File "/opt/tools/volatility-master/volatility/plugins/imageinfo.py", line 45, in render_text for k, t, v in data: File "/opt/tools/volatility-master/volatility/plugins/imageinfo.py", line 103, in calculate kdbg = volmagic.KDBG.v() File "/opt/tools/volatility-master/volatility/obj.py", line 748, in __getattr__ return self.m(attr) File "/opt/tools/volatility-master/volatility/obj.py", line 730, in m raise AttributeError("Struct {0} has no member {1}".format(self.obj_name, attr)) AttributeError: Struct VOLATILITY_MAGIC has no member KDBG ========================================================================= When running other Volatility Plugins on the memory image with the created profile, it says "No suitable address space mapping found": ========================================================================= $ python vol.py linux_netstat -f /path/to/memory.img --profile=Server_x64 Volatility Foundation Volatility Framework 2.5 No suitable address space mapping found Tried to open image as: MachOAddressSpace: mac: need base LimeAddressSpace: lime: need base WindowsHiberFileSpace32: No base Address Space WindowsCrashDumpSpace64BitMap: No base Address Space WindowsCrashDumpSpace64: No base Address Space HPAKAddressSpace: No base Address Space VirtualBoxCoreDumpElf64: No base Address Space VMWareMetaAddressSpace: No base Address Space QemuCoreDumpElf: No base Address Space [...] ========================================================================= Any suggestions? What am I missing? - Thomas

8 years, 11 months

6
12
0 0

Recover password from memory dump

by Massimo Canonico

Hi all, I'm new on volatility so sorry if this question does not fit the purpose of this mailing list. I was starting play with LiME (Linux Memory Extract)[1] and I was able to dump a memory image of an Android Emulator where ChatSecure[2] was running. ChatSecure asked a master password at the first run and this password is stored by using a library called CacheWord [3]. Here the question: in order to find out if ChatSecure stores this password in memory, how should I use volatility? A doc/tutorial link or any suggestion are more than welcome. Thanks, Massimo [1] https://github.com/504ensicsLabs/LiME [2] https://github.com/guardianproject/ChatSecureAndroid [3] https://github.com/guardianproject/cacheword

8 years, 11 months

3
4
0 0

trouble with .volatilityrc file

by James Kelly

1. I have a directory with a memory dump called memdum.bin 2. I run volatility image info against it and I get Air:ticket_number jamesk$ vol.py -f memdump.bin imageinfo Volatility Foundation Volatility Framework 2.5 INFO : volatility.debug : Determining profile based on KDBG search... Suggested Profile(s) : Win2003SP0x86, Win2003SP1x86, Win2003SP2x86 (Instantiated with Win2003SP0x86) AS Layer1 : IA32PagedMemory (Kernel AS) AS Layer2 : FileAddressSpace (/Users/jamesk/Desktop/jackcr-challenge/DC-USTXHOU/ticket_number/memdump.bin) PAE type : No PAE DTB : 0x39000L KDBG : 0x805583d0L Number of Processors : 1 Image Type (Service Pack) : 0 KPCR for CPU 0 : 0xffdff000L KUSER_SHARED_DATA : 0xffdf0000L Image date and time : 2012-11-27 02:01:57 UTC+0000 Image local date and time : 2012-11-26 20:01:57 -0600 3. I can run vol.py --profile=Win2003SP0x86 -f memdump.bin pslist and get process list just fine…but... In that same directory as the memdump.bin file I have a .volatilityrc file which contains [DEFAULT] PROFILE=Win2003SP2x86 LOCATION=file://memdump.bin <file:///memdump.bin> When I run vol.py pslist I get: No suitable address space mapping found Is my syntax incorrect somewhere? Jk

8 years, 11 months

2
1
0 0

[IMAGEINFO] Equivalent to imageinfo plugin on non-windows

by P1kachu

Hello, I was wondering if there was any plugin right now equivalent to 'imageinfo' but for Linux or Mac ? I was planning on give it a try if not, but didn't want to waste time if anybody had done it before. Thank you, -- Stanislas 'P1kachu' Lejay EPITA - LSE If you're sleeping, you're doing it wrong.

8 years, 11 months

3
3
0 0

Error extracting Truecrypt Master Keys

by Tony Balzanto

I am attempting to recover the Truecrypt Master Keys from a Win7SP1x64 memory image and getting the below errors. Using the Volatility 2.5 Windows stand-alone: C:\>vol2.5.exe -f Truecrypt_MountedContainer.bin --profile Win7SP1x64 truecryptmaster -T 7.1a Volatility Foundation Volatility Framework 2.5 Container: Hidden Volume: No Removable: No Read Only: No Disk Length: 0 (bytes) Host Length: 0 (bytes) Encryption Algorithm: - Mode: - Master Key Traceback (most recent call last): File "<string>", line 192, in <module> File "<string>", line 183, in main File "C:\Users\Jake\Documents\GitHub\volatility\build\pyinstaller\out00-PYZ.py z\volatility.commands", line 145, in execute File "C:\Users\Jake\Documents\GitHub\volatility\build\pyinstaller\out00-PYZ.py z\volatility.plugins.tcaudit", line 666, in render_text File "C:\Users\Jake\Documents\GitHub\volatility\build\pyinstaller\out00-PYZ.py z\volatility.utils", line 71, in Hexdump TypeError: object of type 'NoneType' has no len()

8 years, 11 months

2
1
0 0

Hibr2Bin Beta 1

by Matthieu Suiche

Hey guys, I'm back from the other side ! I started refreshing my tools to add Windows 8, 8.1 and 10 support. I'm looking for Beta Testers for Hibr2Bin: Here is the link: http://www.comae.io/ Thanks!

8 years, 11 months

3
2
0 0

How to access data normally exposed by plugin.calculate()?

by Bridgey theGeek

Hi all, I'm trying to access the data that's exposed by the messagehooks plugin, specifically: volatility.plugins.gui.messagehooks.MessageHooks().calculate() I want to be able to work with the window_stations and atom_tables that are yielded by the method. I tried making a new instance of the class and manually calling: mh = messagehooks.MessageHooks(atoms.Atoms, sessions.SessionsMixin) for x in mh.calculate(): print x However when run, I get an attribute error: File "plugin.py", line 81, in calculate() for x in mh.calculate(): File ".../messagehooks.py", line 68, in calculate in atoms.Atoms(self._config).calculate()) File ".../messagehooks.py", line 6, in <genexpr> atom_tables = dict((atom_table, winsta) File ".../atoms.py", line 153, in calculate for wndsta in windowstations.WndScan(self._config).calculate(): File ".../common.py", line 45, in __init__ config.add_option("VIRTUAL", short_option = "V", default = False, AttributeError: type object 'Atoms' has no attribute 'add_option' Is there a better/correct way of getting at the data normally yielded by a plugin's calculate method? Thank you, Adam

8 years, 11 months

2
2
0 0

Re: [Vol-users] Analyzing memory from a QEMU snapshot

by Thomas Hungenberg

On 04.05.2016 17:46, Torres, Geoff (Cyber Security) wrote: > When you say " Running lqs2mem on the original suspend to disk image does not work", do you mean that you're getting an error? Or that it's creating an image that doesn't work in volatility? > > I've ran lqs2mem literally on hundreds of QEMU images with no problems. > > Can you post the output of your run? > > If I recall correctly, Juerg had to pad a certain section of memory in order to get the structures to line up. It's possible that later versions of QEMU/KVM changed so that padding isn't necessary any more. Running lqs2mem on the original image returns "Invalid section type: 7" - Thomas

8 years, 11 months

1
0
0 0

segmentation fault

by Anna Giannakou

Hello, I am using volatility in order to do live introspection in a linux virtual machine (i m using libvmi and pyvmiaddresspace.py to access the vms memory). The problem that I am facing is that once i run a command for example linux_pslist I get a segmentation fault(core dumped) error with no further information about it. Some general information about the system: I have recompiled libvmi in order to work with the kvm-qemu patch and I have tried the process-list example for linux that is featured with libvmi and it works fine. I have also tried to manualy execute pyvmi.init("instance-name","partial") which is what pyvmiaddresspace.py is doing and this also works (along with all the pyvmi related commands like get_memsize(), get_vcpureg()). >From what I understand the problem should lie somewhere in volatility. Before the recompilation of libvmi everything was working fine (without the kvm patch). Any help would be greatly appreciated. Thanks Anna

8 years, 12 months

1
0
0 0

Memory Forensics Training coming to NYC, Amsterdam, and Reston

by Andrew Case

Hello All, We are excited to announce that we now have public trainings scheduled in NYC, Amsterdam, and Reston, VA! This is your chance to learn memory forensics and malware analysis directly from the Volatility developers. These three locations sell out quickly so please contact us ASAP if you wish to attend: http://volatility-labs.blogspot.com/2016/04/windows-malware-and-memory-fore… -- Thanks, Andrew (@attrc)

8 years, 12 months

1
0
0 0

Need a Redhat 7.1 profile

by Torres, Geoff (Cyber Security)

Hi, I usually roll my own profiles but I'm having a big problem getting one created for RedHat 7.1 (Linux version 3.10.0-229.el17.x86_64). I checked the github repository already and did a google search to no avail. Does anyone have one already created? Or can anyone help me figure out how to get around these compilation errors? include/linux/thread_info.h:24:4: error unknown type name 'u32' u32 __user *uaddr; ^ There are hundreds of them. As near as I've been able to determine, all the flags that would set it are 64 bit-centric so it never gets set. I have the full make output and the kernel RPMs if needed. Oh, and this is the first time I'm creating a profile using Volatility 2.5, but I'm getting the same errors on 2.4 where I've been successful in the past. Thanks, Geoff BTW - I'm a programmer by necessity, not profession. Feel free to point out the obvious.

9 years

2
2
0 0

OSDFCon CFP and Autopsy Module Competition

by Brian Carrier

It’s time to start getting ready for the 7th Annual OSDFCon by submitting your presentation idea, writing an Autopsy module, and saving the date on your calendar. OSDFCon is the 1-day event to attend each year to learn about the latest open source digital forensics and incident response tools with over 400 of your colleagues. THE ESSENTIALS Conference Date: October 26, 2016 Location: Herndon, VA CALL FOR PAPERS Each year, OSDFCon gives developers and users a platform to talk about the open source software they love. We want to hear your presentation and hands-on workshop ideas. Submissions are due by June 1. Past presentations have covered new software, new features in mature software, modules for plug-in frameworks, and use cases that integrate several pieces of software. A detailed list of topics and submission details can be found here: http://www.osdfcon.org/osdfcon-2016/2016-call-for-presentations/ AUTOPSY MODULE COMPETITION For the third year, Basis Technology is organizing an Autopsy module writing competition. The modules can be written in Python or Java and we have tutorials to help you get started. Learning to write Autopsy modules will make you more effecient because Autopsy takes care of providing access to files, user interface, and reporting. All you have to do is focus on some cool analytics. The winners will be chosen by the OSDFCon attendees and the top three will get cash prizes. If we get 12 or more submissions (the number that the Volatility project got last year), Basis Technology will double the prize amounts. Submissions are due by October 17 (6 months away!). Links to tutorials and submission details can be found here: http://www.osdfcon.org/osdfcon-2016/2016-module-development-contest/ ABOUT OSDFCON OSDFCon is the premier event focused exclusively on open source digital forensics tools, OSDFCon offers short talks over the course of a single day. These talks are packed with information and present a unique opportunity to learn about new (often free) tools and provide feedback directly to developers. Basis Technology is the organizing sponsor of the event and it is free for government employees to attend.

9 years

1
0
0 0

RE: Need a Redhat 7.1 profile

by Torres, Geoff (Cyber Security)

To answer my own question... My profile build system is Debian based. Even though I've successfully created Fedora and CentOS profiles on it, I needed to move to a Fedora system which had the proper definition files in its compiler environment. That got rid of all the 'u32' errors. But because the compiler was gcc 5.1, I needed to create a compiler-gcc5.h file in the include/Linux folder of the kernel files. I just linked to the gcc4 file and everything compiled fine. All the Linux Volatility commands appear to be working as expected. Geoff From: Torres, Geoff (Cyber Security) Sent: Thursday, April 07, 2016 11:37 AM To: 'vol-users(a)volatilityfoundation.org' <vol-users(a)volatilityfoundation.org> Subject: Need a Redhat 7.1 profile Hi, I usually roll my own profiles but I'm having a big problem getting one created for RedHat 7.1 (Linux version 3.10.0-229.el17.x86_64). I checked the github repository already and did a google search to no avail. Does anyone have one already created? Or can anyone help me figure out how to get around these compilation errors? include/linux/thread_info.h:24:4: error unknown type name 'u32' u32 __user *uaddr; ^ There are hundreds of them. As near as I've been able to determine, all the flags that would set it are 64 bit-centric so it never gets set. I have the full make output and the kernel RPMs if needed. Oh, and this is the first time I'm creating a profile using Volatility 2.5, but I'm getting the same errors on 2.4 where I've been successful in the past. Thanks, Geoff BTW - I'm a programmer by necessity, not profession. Feel free to point out the obvious.

9 years

1
0
0 0

Airbnb just donated $999 to the plugin contest!

by Andrew Case

We are very excited to announce that $999 in cash prizes was just added to the 2016 plugin contest thanks to Airbnb! The updated prize pools and full contest information can be found at the following link: http://volatility-labs.blogspot.com/2016/04/airbnb-donates-999-to-2016-vola… -- Thanks, Andrew (@attrc)

9 years

1
0
0 0

Something changed recently and now my Linux profiles don't work

by Jim Clausing

Gang, I've googled it and saw some other discussion of the dreaded ERROR : volatility.debug : Invalid profile <blah> selected error. I'm trying to figure out what changed recently so that profiles that used to work for me, no longer work. I just did a fresh Ubuntu 14.04.4 install and then installed volatility (and distorm3 via pip) from github and I'm getting the error above. Note, this is the current release version, though I also have the problem with the version from whatever repo SIFT uses. The profile actually came from SecondLook and worked just fine on a different Ubuntu system about 4 weeks ago, but today it fails (on the system where it used to run), so I decided to try on this virgin system and get the same error. I'm at a loss, since there are no other debugging messages to help me out with what might be the problem. I can provide the profile to anyone who needs it (and probably a memory image, too, but that needs to be a little more tightly controlled) if that would help. -- Jim Clausing GIAC GSE #26, CISSP GPG Fingerprint = A507 774A 39D6 A702 9F7C 8808 3D13 77B8 AACD 848D

9 years

2
6
0 0

Re: [Vol-users] Something changed recently and now my Linux profiles don't work

by Andrew Case

Ok, can you run: vol.py --info | grep Linux and see if the profile name shows up like you have it as --profile? Thanks, Andrew (@attrc) On 04/07/2016 02:26 PM, Jim Clausing wrote: > -dd doesn't give me anything more than that error. > > jac@ubuntu:~$ vol.py -dd --plugins=profiles > --profile=Linux3_13_0_79_generic__123_Ubuntu_SMP_Fri_Feb_19_14_27_58_UTC_2016_x86_64 > -m XUbuntu\ 64-bit-Snapshot3.vmem linux_pslist > Volatility Foundation Volatility Framework 2.5 > ERROR : volatility.debug : Invalid profile > Linux3_13_0_79_generic__123_Ubuntu_SMP_Fri_Feb_19_14_27_58_UTC_2016_x86_64 > selected > > -- > Jim Clausing > GIAC GSE #26, CISSP > GPG Fingerprint = A507 774A 39D6 A702 9F7C 8808 3D13 77B8 AACD 848D > > On or about Thu, 7 Apr 2016, Andrew Case pontificated thusly: > >> Hey, >> >> Can you run volatility with -dd set and send the output? If I can't >> figure out it from there I will take the memory sample and profile. Feel >> free to send debug output offline. >> >> Thanks, >> Andrew (@attrc) >> >> On 04/07/2016 12:27 PM, Jim Clausing wrote: >>> Gang, >>> I've googled it and saw some other discussion of the dreaded >>> >>> ERROR : volatility.debug : Invalid profile <blah> selected >>> >>> error. I'm trying to figure out what changed recently so that profiles >>> that used to work for me, no longer work. I just did a fresh Ubuntu >>> 14.04.4 install and then installed volatility (and distorm3 via pip) >>> from github and I'm getting the error above. Note, this is the current >>> release version, though I also have the problem with the version from >>> whatever repo SIFT uses. The profile actually came from SecondLook and >>> worked just fine on a different Ubuntu system about 4 weeks ago, but >>> today it fails (on the system where it used to run), so I decided to try >>> on this virgin system and get the same error. I'm at a loss, since >>> there are no other debugging messages to help me out with what might be >>> the problem. I can provide the profile to anyone who needs it (and >>> probably a memory image, too, but that needs to be a little more tightly >>> controlled) if that would help. >>> >>> -- >>> Jim Clausing >>> GIAC GSE #26, CISSP >>> GPG Fingerprint = A507 774A 39D6 A702 9F7C 8808 3D13 77B8 AACD 848D >>> _______________________________________________ >>> Vol-users mailing list >>> Vol-users(a)volatilityfoundation.org >>> http://lists.volatilityfoundation.org/mailman/listinfo/vol-users >>> >> >> >

9 years

1
0
0 0

The 2016 Volatility Plugin Contest is now live!

by Andrew Case

We are happy to announce that the 2016 Volatility Plugin Contest is now live: http://volatility-labs.blogspot.com/2016/04/the-2016-volatility-plugin-cont… This contest is modeled after the annual IDA Pro one, and its purpose is to encourage new research in the memory forensics field. Volatility is one of the most popular tools in digital forensics, incident response, and malware analysis, and by submitting to our contest your work will immediately gain visibility through all of these communities. Besides this recognition, we also award the top entries over $2,000 in cash prizes, swag (stickers, t-shirts, etc.), and blog entries on our Volatility Labs blog. This contest is a great opportunity to explore the open source Volatility Framework, add visibility to your career, and potentially develop a master's thesis or PhD project. -- Thanks, Andrew (@attrc)

9 years

1
0
0 0

list running process from a ram dump of MAC os x elcapitan

by Razeem Ahmad

Sir, I am doing my M.E in Cyber forensics and Information Security, currently doing my project work on MAC RAM dump analysis. I am using volafox-master for listing data from my dump collected from my lap. Can you please help me how we can find the list of running process. Currently i've found a symbol that volatility uses("_allproc") also ive found it from symutils file. But i don't know what to do with it. Thanks in advance, Razeem

9 years

1
0
0 0

Linux profile

by Carlos Angeles

Hello, I am working on a homework assignment that involves IR on a Linux system. We were only given some of the log files and a memory dump. None of the profiles on Github work so I need to build a profile. Unfortunately, the memory dump comes from a very old version of RedHat. It's RedHat 7.2 (Enigma) not RHEL7. I found the Enigma ISOs, created a VM and downloaded the source, headers, libdwarf, dwarfdump, etc, installed but when I run make from the tools/linux folder, it doesn't create the module.ko file that dwarfdump uses. I ran the make manually and it finishes without any errors but no module.ko. Any ideas what I might be doing wrong? Thanks! Carlos

9 years, 1 month

2
2
0 0

Can't detect stealth LKM rootkit

by Smith Michael

Hi, I'm trying to detect LKM rootkit (https://github.com/ivyl/rootkit) which hides module and hooks fop. I use CentOS 6.5 (2.6.32-431.el6.x86_64), LiME 1.7.2 and latest Volatility git repo (52c9c40a273595ef0b088b75b396c3487cb1b27c) for both memory dump and analyse. Many plugin works fine, but it can't be detected by below plugin (same on Volatility 2.4). * linux_hidden_modules - nothing is detected $ python vol.py -f mem.img --profile=LinuxCentOS65x64 linux_hidden_modules Volatility Foundation Volatility Framework 2.5 Offset (V) Name ------------------ ---- * linux_check_fops - outputs error (no verbose output on --debug option) $ python vol.py -f mem.img --profile=LinuxCentOS65x64 linux_check_fops Volatility Foundation Volatility Framework 2.5 ERROR : volatility.debug : You must specify something to do (try -h) I would really appreciate any advice. Regards,

9 years, 1 month

3
2
0 0

Volatile registry keys

by Thomas Chopitea

Dear vol-users, I'm trying to get data from a volatile registry key using the regapi / rawreg classes in volatility. The key I'm looking for is under HKCU\Software\Classes\, and is called CLSID vol.py --plugins='/Users/tomchop/Infosec/Forensics-RE/volatility-plugins/volatility-autoruns' -f Windows\ 7\ x64-aa76b309.vmem --profile=Win7SP1x64 printkey -K "Software\\Classes\\CLSID" Volatility Foundation Volatility Framework 2.4 Legend: (S) = Stable (V) = Volatile The requested key could not be found in the hive(s) searched So I go up one level: vol.py --plugins='/Users/tomchop/Infosec/Forensics-RE/volatility-plugins/volatility-autoruns' -f Windows\ 7\ x64-aa76b309.vmem --profile=Win7SP1x64 printkey -K "Software\\Classes" Volatility Foundation Volatility Framework 2.4 Legend: (S) = Stable (V) = Volatile ---------------------------- Registry: \??\C:\Users\admin\ntuser.dat Key name: Classes (V) Last updated: 2015-04-11 18:04:18 UTC+0000 Subkeys: Values: REG_LINK SymbolicLinkValue : (V) \Registry \User\S-1-5-21-978483858-511166411-2750856381-1000_Classes ---------------------------- Registry: \SystemRoot\System32\Config\DEFAULT Key name: Classes (S) Last updated: 2009-07-14 04:48:57 UTC+0000 Subkeys: (S) Local Settings Values: How can I query this key and keep on drilling its subkeys ? Also, my plugin is making extensive use of rawreg because I try to get each individual NTUSER.dat hive, and I don't know which hive_name to pass on to regapi. Should I use the full hive name, as in self.hive_name(obj.Object("_CMHIVE", vm = addr_space, offset = hive_offset)), or is there a better way of doing it? Any help is greatly appreciated. Have a great day! -- Thomas Chopitea

9 years, 1 month

2
2
0 0

Having Trouble Running Vol

by Jason N.

Hello, I am not sure why I am having trouble running vol against a Win7 memory image: I ran the imageinfo plugin against the image and it suggests: Win2008R2SP0x64, Win7SP1x64, Win7SP0x64, Win2008R2SP1x64: But when I select Win7S1x64 profile for other plugins I get following error: Any suggestions on what I am missing? Thanks in advance.

9 years, 1 month

2
1
0 0

Announcing BSides New Orleans 2016!

by Andrew Case

We are very excited to announce that the lineup for BSidesNOLA 2016 is out! The day will start with a keynote presentation from Darren Van Booven. He is currently the CISO of Idaho National Laboratory and was previously the CISO of the US House of Representatives. It will then continue with three tracks of talks ranging from application security to memory forensics to malware analysis to law. Full information on the conference can be found at the following page: http://www.securitybsides.com/w/page/104051753/BSidesNOLA%202016 The cost to attend is $15, and you must register through the EventBrite link ( https://www.eventbrite.com/e/bsides-nola-2016-tickets-20569894107 ). Last year was our third year and we had 200 people attend. We are expecting even more this year. For those of you who attended last year, you know that beyond just great talks and networking, we also provide very good food and drinks. The close proximity to the French Quarter (5-10 minute walk) also means that after the conference there will be plenty of fun and interesting things to do for the rest of the night. We hope to see you there and if you have any questions please reply to this thread or email bsidesnola [@@] gmail.com. -- Thanks, Andrew (@attrc)

9 years, 1 month

1
0
0 0

Problems running standalone Windows version of Volatile

by Marian Kechlibar

Hello all, I am researching the behavior of the Galileo RCS, whose source codes leaked in July 2015. I am using volatility 2.5 on Windows 7 and the instructions given in the blog of Joe Greenwood on 4armed.com. I downloaded the standalone version for Windows and I run it from the command line, but it dies immediately complaining about a missing source file. volatility-2.5.standalone.exe --profile=Win7SP1x64 -f test.raw -v psxview Volatility Foundation Volatility Framework 2.5 ERROR : volatility.debug : The requested file doesn't exist The system is Windows 7 x64 with SP1, so the profile should be correct. Python 2.7 is installed in the system, but it should not be necessary for a standalone version anyway. Thank you in advance for help! Best regards Marian Kechlibar

9 years, 1 month

3
2
0 0

Memory forensics training coming to NYC!

by Andrew Case

We are excited to announce that our memory forensics and malware analysis training will be headed back to NYC in June: http://www.memoryanalysis.net/#!memory-forensics-training/c1q3n We have sold out rather quickly for both of our previous NYC courses, so please let us know us ASAP if you are interested in attending. -- Thanks, Andrew (@attrc)

9 years, 2 months

1
0
0 0

The BSidesNOLA 2016 Call for Papers is open!

by Andrew Case

We are pleased to announce that BSidesNOLA 2016 will take place on Saturday, April 16th in the heart of downtown New Orleans. Full details can be found on the following page: http://www.securitybsides.com/w/page/104051753/BSidesNOLA%202016 Our Call for Papers is currently open, and we will be accepting submissions through February 16st. Please spend time on your CFP submission(s) as we receive a large number each year and inevitably have to reject some of them. You don't want to miss our speakers' party so send us your best stuff! To see some of the accepted talks from previous years, please see our past pages: http://www.securitybsides.com/w/page/91550808/BSidesNOLA%202015 http://www.securitybsides.com/w/page/71231585/BsidesNola2014 Please let us know if you have any questions, and if you plan to attend you must register on the Event Brite page ($15)! -- Thanks, Andrew (@attrc)

9 years, 3 months

1
0
0 0

RFI: Failed Memory Acquisitions

by AAron Walters

vol-users, As you know, one of the main goals of the Volatility Foundation is to promote the use of memory analysis within the forensics community. If you have been on this mailing list for a while or seen some of the recent court cases, you know that one of the main challenges facing investigators is the ability to reliably collect a sample of physical memory. The increasing number of acquisition tools has given people a lot of options but has also exacerbated the challenge of knowing which tool to use and under what circumstances. In order to address this and to reduce the amount of time we spend helping investigators troubleshoot bad memory samples, we are working on developing some memory acquisition guidelines for investigators. If you have had experiences where you were unable to collect a valid sample from a system, we would like to hear from you. This could mean that the system crashed during collection or the collected sample couldn’t be analyzed. In particular, we are interested in the details (hardware, software, etc) about the system the memory was being acquired from and the version of the tool you were using to perform the acquisition. If you have this type of information and are able to share, please contact me off list. Happy holidays and hope we can catch up in the New Year! AAron Walters The Volatility Foundation

9 years, 4 months

1
0
0 0

Insmod lime.lo on stock Samsung Galaxy S3 results in Exec format error

by Rob Hunter

Hello list, This is my first post to this list. My name is Rob, I'm located in the Netherlands and am looking for some help in dumping the memory of an Android phone so I can inspect it in Volatility. A bit of background as to where I'm currently at with Volatility. I've successfully compiled LiME against a standard linux kernel running on Intel, created a profile with dwarfdump etc., dumped the memory and can use the plugins successfully. I've also installed Cyanogenmod 12.1 on a GalaxyS2 and can run LiMe on it and dump the RAM. I have a problem with the profile not loading in Volatility but that's for another post :-) I can run strings on the dump and recover meaningful information though. Cutting to the chase... My target phone is a stock Samsung Galaxy S3. I've looked at the device settings and have downloaded the matching kernel source code from Samsungs opensource website, taking care to make sure the build versions string matches. The phone has developer settings and usb debugging enabled. I have also rooted the phone and the SuperSU binary is installed and configured to grant root always without prompting. I've tried using toolchain versions 4.9 and 4.8 but the Samsung source code will not compile without modifications to the makefile relating to warnings being interpreted as errors. I'm therefore using version 4.7. I've compiled the kernel modules which generated a module.symvers: *** 0x82d9772c bcmsdh_remove drivers/net/wireless/bcmdhd/dhd EXPORT_SYMBOL 0x9cad0f4b bcmsdh_probe drivers/net/wireless/bcmdhd/dhd EXPORT_SYMBOL *** I then compiled LiME with this make file... *** obj-m := lime.o lime-objs := tcp.o disk.o main.o KDIR :=~/ANDROID/S3Kernel/Kernel PWD := $(shell pwd) CROSS_COMPILE := /home/dfir/ANDROID/android-ndk-r10e/toolchains/arm-linux-androideabi-4.7/bin/arm-linux-androideabi- ARCH := arm .PHONY: modules modules_install clean distclen help default: $(MAKE) ARCH=arm SUBARCH=arm -C $(KDIR) M=$(PWD) CROSS_COMPILE=$(CROSS_COMPILE) EXTRA_CFLAGS=-fno-pic modules mv lime.ko limeS3.ko *** ...and this generates the following output *** dfir@ThinkPad-T420:~/ANDROID/S3Kernel/LiME/src$ make make ARCH=arm SUBARCH=arm -C ~/ANDROID/S3Kernel/Kernel M=/home/dfir/ANDROID/S3Kernel/LiME/src CROSS_COMPILE=/home/dfir/ANDROID/android-ndk-r10e/toolchains/arm-linux-androideabi-4.7/bin/arm-linux-androideabi- EXTRA_CFLAGS=-fno-pic modules make[1]: Entering directory `/home/dfir/ANDROID/S3Kernel/Kernel' CC [M] /home/dfir/ANDROID/S3Kernel/LiME/src/tcp.o CC [M] /home/dfir/ANDROID/S3Kernel/LiME/src/disk.o CC [M] /home/dfir/ANDROID/S3Kernel/LiME/src/main.o LD [M] /home/dfir/ANDROID/S3Kernel/LiME/src/lime.o Building modules, stage 2. MODPOST 1 modules CC /home/dfir/ANDROID/S3Kernel/LiME/src/lime.mod.o LD [M] /home/dfir/ANDROID/S3Kernel/LiME/src/lime.ko make[1]: Leaving directory `/home/dfir/ANDROID/S3Kernel/Kernel' mv lime.ko limeS3.ko *** After successfully compilation there is also a module.symvers file located in LiME directory but it is empty. I wonder if this is indicative of my problem? I then move limeS3.ko to my phone and connect to it with adb adb forward tcp:4444 tcp:4444 adb shell su this gets me to a root prompt on the device and I can move freely around the file system. I then move to the location where limeS3.ko is installed and enter the command root@m0:/storage/extSdCard # insmod ./limeS3.ko "path=tcp:4444 format=lime" which gives the following error. insmod: init_module './limeS3.ko' failed (Exec format error) I've searched for this error and ensured the kernel version is correct. Can anyone tell me what I'm doing wrong so I can get the driver loaded? I realize that this was a long first post. Thank-you for taking the time to read this far. I hope someone can point me in the right direction. regards, Rob

9 years, 4 months

2
1
0 0

Blog Post - Binary Zone Forensic Challenge #4

by Jared Greenhill

All, I recently wrote a blog post that outlines volatility usage related to an intrusion based scenario. The blog post can be found here: http://justanotherdfirblog.blogspot.com/2015/11/solving-binary-zone-forensi… The challenge can be found here: http://www.binary-zone.com/2015/09/16/digital-forensic-challenge-4/ Hopefully some of you will find it useful. Best, Jared

9 years, 4 months

1
0
0 0

Volatility 2.5 and the results of the Volatility Plugin Contest

by Andrew Case

We are excited to announce that Volatility 2.5 and the results of the 2015 Volatility Plugin Contest are both now available. Volatility 2.5 includes many new features including support for Windows 10, Mac OS X El Capitan, and Linux 4.2.3. There are also a number of new plugins, features, and bug fixes. On the contest side, we received some very strong submissions this year. These included recovery of the fully update-to-date shim cache from memory (no need to wait on a reboot), the Evole GUI, memory analysis of VMotion VM transfers, and more. Full information on the release and contest can be found at these links: http://volatility-labs.blogspot.com/2015/11/plugx-memory-forensics-lifecycl… http://volatility-labs.blogspot.com/2015/10/results-from-2015-volatility-pl… http://www.volatilityfoundation.org/#!25/c1f29 Please let us know if you have any issues or questions and enjoy the new memory forensics capabilities! -- Thanks, Andrew (@attrc)

9 years, 5 months

1
0
0 0

Searching a Process's Memory

by Bridgey theGeek

Hi all, I'm thinking I might have a fundamental misunderstanding here, so I'm hoping someone can help me out. I'm looking for remnants of a data structure in the memory of a specific process. Originally, the data would have been on a heap. I notice that in '/volatility/plugins/overlays/windows/windows.py' there is a function named: search_process_memory I thought this would do the trick, but examining the code I notice that it searches each of the VADs. Which leads me to my question: would data that was originally on a heap, but is no longer needed by the process still be in the VAD? That is, should I be able to find it using this method? If not, "where" is the data now? And is there a way of searching wherever that "where" is? I hope that makes sense! Bridgey

9 years, 6 months

3
2
0 0

Why doesn't memmap tally with vadinfo?

by Bridgey theGeek

Hi all, System is Win7SP1x86. pagefile is OFF. Consider this VAD node (from vadinfo): VAD node @ 0x85e076d0 Start 0x76440000 End 0x764dffff Tag Vad Flags: CommitCharge: 5, Protection: 7, VadType: 2 Protection: PAGE_EXECUTE_WRITECOPY Vad Type: VadImageMap ControlArea @853ab1e0 Segment 8f6eba98 NumberOfSectionReferences: 1 NumberOfPfnReferences: 120 NumberOfMappedViews: 32 NumberOfUserReferences: 33 Control Flags: Accessed: 1, File: 1, Image: 1 FileObject @853ab898, Name: \Device\HarddiskVolume1\Windows\System32\advapi32.dll First prototype PTE: 8f6ebac8 Last contiguous PTE: fffffffc Flags2: Inherit: 1 My understanding is that this VAD node is tracking the pages from 0x76440000 through to 0x764dffff. When I look at the output of memmap for this process and this range I see: --SNIP-- 0x76228000 0x1f04c000 0x1000 0x2c1000 0x76440000 0x20670000 0x1000 0x2c2000 <-- start 0x76441000 0x0b728000 0x1000 0x2c3000 0x76451000 0x233a8000 0x1000 0x2c4000 0x76454000 0x1f5ab000 0x1000 0x2c5000 0x76455000 0x2336c000 0x1000 0x2c6000 0x76456000 0x1f6ed000 0x1000 0x2c7000 0x76457000 0x1f6ae000 0x1000 0x2c8000 0x76458000 0x2346f000 0x1000 0x2c9000 0x76459000 0x1e48b000 0x1000 0x2ca000 0x7645a000 0x21fcc000 0x1000 0x2cb000 0x7645b000 0x223cd000 0x1000 0x2cc000 0x76460000 0x1e3d2000 0x1000 0x2cd000 0x76461000 0x1e103000 0x1000 0x2ce000 0x764af000 0x20636000 0x1000 0x2cf000 0x764b1000 0x23ef8000 0x1000 0x2d0000 0x764b3000 0x0bded000 0x1000 0x2d1000 0x764b7000 0x1f730000 0x1000 0x2d2000 0x764e0000 0x208e6000 0x1000 0x2d3000 <-- first byte after end --SNIP-- The file itself, advapi32.dll, is 0xa0000 bytes (well, in memory). dlllist shows: Base Size LoadCount Path ---------- ---------- ---------- ---- 0x76440000 0xa0000 0xffff C:\Windows\system32\ADVAPI32.dll 0x76440000 through to 0x764dffff is 0x9FFFF bytes long. However, memmap is only showing 0x13000 bytes. The 0x13000 isn't big enough to hold the 0xa0000 bytes of the file. My question is, why isn't the whole range (0x76440000 through to 0x764dffff) shown in memmap? Is it the case that the VAD node is responsible for the whole range, but simply not all the pages in that range are in use which is why they're missing from the memmap output? Or is there something that I'm missing? Any comments greatly appreciated! Adam

9 years, 6 months

2
1
0 0

Processes have more than one address space???

by Bridgey theGeek

Oh dear. I've just realised my mistake. The memory address is of course the memory address on my system of the object being returned. Thank goodness I have a week off coming up...

9 years, 6 months

1
0
0 0

Processes have more than one address space???

by Bridgey theGeek

Hi all, I've come across a peculiarity that I'd really like someone to shed some light on. Consider: > python vol.py --profile Win7SP1x64 -f Windows7x64.vmem volshell Volatility Foundation Volatility Framework 2.4 Current context: System @ 0xfffffa80018ae890, pid=4, ppid=0 DTB=0x187000 Welcome to volshell! Current memory image is: file:///C:/Windows7x64.vmem To get help, type 'hh()' >>> for p in getprocs(): ... my_proc = p ... break ... >>> print my_proc.UniqueProcessId, my_proc.ImageFileName 4 System >>> for i in range(10): ... my_proc.get_process_address_space() ... <volatility.plugins.addrspaces.amd64.AMD64PagedMemory object at 0x0000000008D76240> <volatility.plugins.addrspaces.amd64.AMD64PagedMemory object at 0x0000000008D76470> <volatility.plugins.addrspaces.amd64.AMD64PagedMemory object at 0x0000000008D762E8> <volatility.plugins.addrspaces.amd64.AMD64PagedMemory object at 0x0000000008D76240> <volatility.plugins.addrspaces.amd64.AMD64PagedMemory object at 0x0000000008D76470> <volatility.plugins.addrspaces.amd64.AMD64PagedMemory object at 0x0000000008D762E8> <volatility.plugins.addrspaces.amd64.AMD64PagedMemory object at 0x0000000008D76240> <volatility.plugins.addrspaces.amd64.AMD64PagedMemory object at 0x0000000008D76470> <volatility.plugins.addrspaces.amd64.AMD64PagedMemory object at 0x0000000008D762E8> <volatility.plugins.addrspaces.amd64.AMD64PagedMemory object at 0x0000000008D76240> There appears to be three different objects that are returned on a cycle. Is this normal, expected behaviour? Why are there three? Thank you!

9 years, 6 months

1
0
0 0

Open Source Digital Forensics Conference & Upcoming Trainings

by Andrew Case

Hello All, I was writing a quick email to say that the entire Volatility team will be at OSDFC in a few weeks. MHL will be showing off some of our new capabilities, along with the results of the plugin contest, in the morning. After that, we will all be hanging around throughout the day. Please come say 'hi'! http://www.osdfcon.org/2015-event/2015-program/ Also, we have two public classes currently being offered for 2016. The first is in San Diego and the second is in Reston. Our classes have been selling out pretty consistently so contact us ASAP if you are interested in a seat: http://www.memoryanalysis.net/#!memory-forensics-training/c1q3n Hope to see many of you in a few weeks! -- Thanks, Andrew (@attrc)

9 years, 6 months

1
0
0 0

Shellcode use in memory - forensic challenge related

by Jared Greenhill

All, I've been messing around with this fun challenge as of late - http://www.binary-zone.com/2015/09/16/digital-forensic-challenge-4/ and have been struggling with question #5 (using memory forensics, can you identify the shellcode used?). My initial approach was starting with malfind and dumping malfind artifacts and reviewing. I also threw some shellcode based yara sigs together, but didn't have much luck there either. Anyways, any help or direction pointing is appreciated :) Best, -Jared

9 years, 6 months

1
0
0 0

Volatility 2015 Summer Updates

by Andrew Case

We put together a quick blog post of upcoming and recent conferences, research, analysis capabilities, and news related to Volatility. It has been a pretty crazy summer, and we thank you all for the continued support of the project! http://volatility-labs.blogspot.com/2015/08/volatility-updates-summer-2015.… If you will be at HTCIA next week, be sure to stop by the Volexity booth and say 'hi' to some of our team members. You will also get a chance to win a free spot to a future training! -- Thanks, Andrew (@attrc)

9 years, 8 months

1
0
0 0

Volatility at Black Hat!

by Andrew Case

The Volatility team will be participating in a number of events at Black Hat this year, and we hope to see many of you there. This includes a book signing, arsenal demo, and even a party! Full information can be found here: http://volatility-labs.blogspot.com/2015/07/volatility-at-black-hat-usa-dfr… Please let us know if you have any questions, and we look forward to seeing many of you in Vegas! -- Thanks, Andrew (@attrc)

9 years, 9 months

1
0
0 0

Integrating the libvmi with volatility problem

by Xianchun Guan

Hi guys, who can help me to solve Volatility issues for linux(the vm is windows,it's works).as follow is the operation and running results. volatility version:2.4 libvmi version:v0.12.0-rc2 *1. kvm vm:* *--download lime resource code* root@ubuntu-gxc:/opt# git clone https://github.com/504ensicsLabs/LiME.git root@ubuntu-gxc:/opt# cd LiME root@ubuntu-gxc:/opt/LiME# git tag v1.4 root@ubuntu-gxc:/opt/LiME# git checkout -b v1.4 Switched to a new branch 'v1.4' root@ubuntu-gxc:/opt/LiME# cd src/ root@ubuntu-gxc:/opt/LiME/src# make make -C /lib/modules/2.6.32-21-generic/build M=/opt/LiME/src modules make[1]: Entering directory `/usr/src/linux-headers-2.6.32-21-generic' CC [M] /opt/LiME/src/tcp.o CC [M] /opt/LiME/src/disk.o CC [M] /opt/LiME/src/main.o LD [M] /opt/LiME/src/lime.o Building modules, stage 2. MODPOST 1 modules CC /opt/LiME/src/lime.mod.o LD [M] /opt/LiME/src/lime.ko make[1]: Leaving directory `/usr/src/linux-headers-2.6.32-21-generic' strip --strip-unneeded lime.ko mv lime.ko lime-2.6.32-21-generic.ko root@ubuntu-gxc:/opt/LiME/src# insmod lime-2.6.32-21-generic.ko "path=/opt/ubuntu.lime format=lime" root@ubuntu-gxc:/opt/LiME/src# ls -alh /opt/ubuntu.lime -r--r--r-- 1 root root 1.0G 2015-06-05 14:24 /opt/ubuntu.lime *--copy ubuntu.lime to kvm host* root@ubuntu-gxc:/opt/LiME/src# scp /opt/ubuntu.lime root(a)172.19.106.245: /mnt/sdb1/forensics/images/ *2. kvm Host:* *--Making the profile* root@ubuntu:/mnt/sdb1/git/volatility/volatility# zip volatility/plugins/overlays/linux/ubuntu1004.zip tools/linux/module.dwarf ../../../sysmaps/System.map-2.6.32-21-generic adding: tools/linux/module.dwarf (deflated 90%) adding: ../../../sysmaps/System.map-2.6.32-21-generic (deflated 74%) *--using the profile* root@ubuntu:/mnt/sdb1/git/volatility/volatility# python vol.py --info |grep Linux Volatility Foundation Volatility Framework 2.4 Linuxubuntu1004i386x86 - A Profile for Linux ubuntu1004i386 x86 Linuxubuntu1004x86 - A Profile for Linux ubuntu1004 x86 linux_banner - Prints the Linux banner information linux_yarascan - A shell in the Linux memory image --using the plugin root@ubuntu:/mnt/sdb1/git/volatility/volatility# python vol.py --debug -f /mnt/sdb1/forensics/images/ubuntu.lime --profile=Linuxubuntu1004x86 linux_pslist Volatility Foundation Volatility Framework 2.4 DEBUG : volatility.plugins.overlays.linux.linux: ubuntu1004: Found dwarf file ../../../sysmaps/System.map-2.6.32-21-generic with 658 symbols DEBUG : volatility.plugins.overlays.linux.linux: ubuntu1004: Found system file ../../../sysmaps/System.map-2.6.32-21-generic with 1 symbols DEBUG : volatility.obj : Applying modification from BashHashTypes DEBUG : volatility.obj : Applying modification from BashTypes DEBUG : volatility.obj : Applying modification from BasicObjectClasses DEBUG : volatility.obj : Applying modification from ELF32Modification DEBUG : volatility.obj : Applying modification from ELF64Modification DEBUG : volatility.obj : Applying modification from ELFModification DEBUG : volatility.obj : Applying modification from HPAKVTypes DEBUG : volatility.obj : Applying modification from LimeTypes DEBUG : volatility.obj : Applying modification from LinuxTruecryptModification DEBUG : volatility.obj : Applying modification from MachoModification DEBUG : volatility.obj : Applying modification from MachoTypes DEBUG : volatility.obj : Applying modification from MbrObjectTypes DEBUG : volatility.obj : Applying modification from VMwareVTypesModification DEBUG : volatility.obj : Applying modification from VirtualBoxModification DEBUG : volatility.obj : Applying modification from LinuxIntelOverlay DEBUG : volatility.obj : Applying modification from LinuxKmemCacheOverlay DEBUG : volatility.plugins.overlays.linux.linux: Requested symbol cache_chain not found in module kernel DEBUG : volatility.obj : Applying modification from LinuxMountOverlay DEBUG : volatility.obj : Applying modification from LinuxObjectClasses DEBUG : volatility.obj : Applying modification from LinuxOverlay DEBUG : volatility.plugins.overlays.linux.linux: ubuntu1004: Found dwarf file ../../../sysmaps/System.map-2.6.32-21-generic with 658 symbols DEBUG : volatility.plugins.overlays.linux.linux: ubuntu1004: Found system file ../../../sysmaps/System.map-2.6.32-21-generic with 1 symbols DEBUG : volatility.obj : Applying modification from BashHashTypes DEBUG : volatility.obj : Applying modification from BashTypes DEBUG : volatility.obj : Applying modification from BasicObjectClasses DEBUG : volatility.obj : Applying modification from ELF32Modification DEBUG : volatility.obj : Applying modification from ELF64Modification DEBUG : volatility.obj : Applying modification from ELFModification DEBUG : volatility.obj : Applying modification from HPAKVTypes DEBUG : volatility.obj : Applying modification from LimeTypes DEBUG : volatility.obj : Applying modification from LinuxTruecryptModification DEBUG : volatility.obj : Applying modification from MachoModification DEBUG : volatility.obj : Applying modification from MachoTypes DEBUG : volatility.obj : Applying modification from MbrObjectTypes DEBUG : volatility.obj : Applying modification from VMwareVTypesModification DEBUG : volatility.obj : Applying modification from VirtualBoxModification DEBUG : volatility.obj : Applying modification from LinuxIntelOverlay DEBUG : volatility.obj : Applying modification from LinuxKmemCacheOverlay DEBUG : volatility.plugins.overlays.linux.linux: Requested symbol cache_chain not found in module kernel DEBUG : volatility.obj : Applying modification from LinuxMountOverlay DEBUG : volatility.obj : Applying modification from LinuxObjectClasses DEBUG : volatility.obj : Applying modification from LinuxOverlay Offset Name Pid Uid Gid DTB Start Time ---------- -------------------- --------------- --------------- ------ ---------- ---------- DEBUG : volatility.utils : Voting round DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.macho.MachOAddressSpace'> DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.lime.LimeAddressSpace'> DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.hibernate.WindowsHiberFileSpace32'> DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.crashbmp.WindowsCrashDumpSpace64BitMap'> DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.crash.WindowsCrashDumpSpace64'> DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.hpak.HPAKAddressSpace'> DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.vmem.VMWareMetaAddressSpace'> DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.elfcoredump.VirtualBoxCoreDumpElf64'> DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.elfcoredump.QemuCoreDumpElf'> DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.vmware.VMWareAddressSpace'> DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.crash.WindowsCrashDumpSpace32'> DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.amd64.AMD64PagedMemory'> DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.intel.IA32PagedMemoryPae'> DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.intel.IA32PagedMemory'> DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.pyvmiaddressspace.PyVmiAddressSpace'> DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.osxpmemelf.OSXPmemELF'> DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.standard.FileAddressSpace'> DEBUG : volatility.utils : Succeeded instantiating <volatility.plugins.addrspaces.standard.FileAddressSpace object at 0x7505790> DEBUG : volatility.utils : Voting round DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.macho.MachOAddressSpace'> DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.lime.LimeAddressSpace'> DEBUG : volatility.utils : Succeeded instantiating <volatility.plugins.addrspaces.lime.LimeAddressSpace object at 0x7505750> DEBUG : volatility.utils : Voting round DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.macho.MachOAddressSpace'> DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.lime.LimeAddressSpace'> DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.hibernate.WindowsHiberFileSpace32'> DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.crashbmp.WindowsCrashDumpSpace64BitMap'> DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.crash.WindowsCrashDumpSpace64'> DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.hpak.HPAKAddressSpace'> DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.vmem.VMWareMetaAddressSpace'> DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.elfcoredump.VirtualBoxCoreDumpElf64'> DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.elfcoredump.QemuCoreDumpElf'> DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.vmware.VMWareAddressSpace'> DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.crash.WindowsCrashDumpSpace32'> DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.amd64.AMD64PagedMemory'> DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.intel.IA32PagedMemoryPae'> DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.intel.IA32PagedMemory'> DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.pyvmiaddressspace.PyVmiAddressSpace'> DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.osxpmemelf.OSXPmemELF'> DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.standard.FileAddressSpace'> DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.arm.ArmAddressSpace'> DEBUG : volatility.plugins.addrspaces.arm: get_pte: invalid pde_value e82c4c4c No suitable address space mapping found Tried to open image as: MachOAddressSpace: mac: need base LimeAddressSpace: lime: need base WindowsHiberFileSpace32: No base Address Space WindowsCrashDumpSpace64BitMap: No base Address Space WindowsCrashDumpSpace64: No base Address Space HPAKAddressSpace: No base Address Space VMWareMetaAddressSpace: No base Address Space VirtualBoxCoreDumpElf64: No base Address Space QemuCoreDumpElf: No base Address Space VMWareAddressSpace: No base Address Space WindowsCrashDumpSpace32: No base Address Space AMD64PagedMemory: No base Address Space IA32PagedMemoryPae: No base Address Space IA32PagedMemory: No base Address Space PyVmiAddressSpace: Location doesn't start with vmi:// OSXPmemELF: No base Address Space MachOAddressSpace: MachO Header signature invalid MachOAddressSpace: MachO Header signature invalid LimeAddressSpace: Invalid Lime header signature WindowsHiberFileSpace32: PO_MEMORY_IMAGE is not available in profile WindowsCrashDumpSpace64BitMap: Header signature invalid WindowsCrashDumpSpace64: Header signature invalid HPAKAddressSpace: Invalid magic found VMWareMetaAddressSpace: VMware metadata file is not available VirtualBoxCoreDumpElf64: ELF Header signature invalid QemuCoreDumpElf: ELF Header signature invalid VMWareAddressSpace: Invalid VMware signature: 0xf000ff53 WindowsCrashDumpSpace32: Header signature invalid AMD64PagedMemory: Incompatible profile Linuxubuntu1004x86 selected IA32PagedMemoryPae: Failed valid Address Space check IA32PagedMemory: Failed valid Address Space check PyVmiAddressSpace: Must be first Address Space OSXPmemELF: ELF Header signature invalid FileAddressSpace: Must be first Address Space ArmAddressSpace: Failed valid Address Space check

9 years, 9 months

2
1
0 0

testing requested on CentOS 2.6.18.x kernels

by Andrew Case

Hello All, I was writing to request testing from anyone who may be running or have access to a CentOS installation running a 2.6.18 series kernel. Even though that series of kernels is ancient, CentOS/RH backports years of patches into that series (for unknown reasons...), and then uses the kernels in production systems. I think we finally figured out the quirks related to this OS & kernel version, so if you have a system please test it. If you find bugs please either email them to me or file a bug on the Volatility tracker (https://github.com/volatilityfoundation/volatility/issues) -- Thanks, Andrew (@attrc)

9 years, 9 months

1
0
0 0

The 2015 Volatility Plugin Contest is now live!

by Andrew Case

We are happy to announce that the 2015 Volatility Plugin Contest is now live: http://www.volatilityfoundation.org/#!2015/c1qp0 This contest is modeled after the annual IDA Pro one, and its purpose is to encourage new research in the memory forensics field. Volatility is one of the most popular tools in digital forensics, incident response, and malware analysis, and by submitting to our contest your work will immediately gain visibility through all of these communities. Besides this recognition, we also award the top entries over $2,000 in cash prizes, swag (stickers, t-shirts, etc.), blog entries on our Volatility Labs blog, and an invitation to speak at our memory forensics workshop. The entries of last year's winners can be found here: http://www.volatilityfoundation.org/#!2014/cjpn This contest is a great opportunity to explore the open source Volatility Framework, add visibility to your career, and potentially develop a master's thesis or PhD project. -- Thanks, Andrew (@attrc)

9 years, 10 months

1
0
0 0

Re: [Vol-users] Sample error or real module? (and other questions)

by Gregory Pendergast

Thanks gentlemen. No worries there. I didn't take it badly. Sorry for the oversight. Correcting the command gives me output, but leaves me with a new question. The string of interest seems nowhere to be found (maybe it's unicode? I'm not sure how to tell...): >>> db(0xf9805ba44800) 0xf9805ba44800 00 00 00 00 00 00 00 00 1b 00 01 00 28 00 00 00 ............(... 0xf9805ba44810 28 00 00 00 18 00 00 00 00 00 00 00 00 00 02 00 (............... 0xf9805ba44820 00 00 00 00 00 00 00 00 48 a4 83 08 a0 f8 ff ff ........H....... 0xf9805ba44830 06 09 65 f1 02 00 00 00 00 00 00 00 00 00 00 00 ..e............. 0xf9805ba44840 00 00 00 00 00 00 00 00 a8 00 00 00 00 00 00 00 ................ 0xf9805ba44850 01 00 00 00 40 00 00 00 00 00 00 00 00 00 00 00 ....@........... 0xf9805ba44860 07 00 07 00 28 00 40 00 68 00 40 00 18 00 01 00 ....(.@.h.@..... 0xf9805ba44870 38 00 20 00 04 00 02 00 0b 9e 00 00 00 00 00 00 8............... >>> db(0xf9805ba44800,length=0xFF) 0xf9805ba44800 00 00 00 00 00 00 00 00 1b 00 01 00 28 00 00 00 ............(... 0xf9805ba44810 28 00 00 00 18 00 00 00 00 00 00 00 00 00 02 00 (............... 0xf9805ba44820 00 00 00 00 00 00 00 00 48 a4 83 08 a0 f8 ff ff ........H....... 0xf9805ba44830 06 09 65 f1 02 00 00 00 00 00 00 00 00 00 00 00 ..e............. 0xf9805ba44840 00 00 00 00 00 00 00 00 a8 00 00 00 00 00 00 00 ................ 0xf9805ba44850 01 00 00 00 40 00 00 00 00 00 00 00 00 00 00 00 ....@........... 0xf9805ba44860 07 00 07 00 28 00 40 00 68 00 40 00 18 00 01 00 ....(.@.h.@..... 0xf9805ba44870 38 00 20 00 04 00 02 00 0b 9e 00 00 00 00 00 00 8............... 0xf9805ba44880 50 14 9e 00 00 00 00 00 03 ee e4 ad 6d 83 d0 01 P...........m... 0xf9805ba44890 03 ee e4 ad 6d 83 d0 01 18 24 3a 05 d4 82 d0 01 ....m....$:..... 0xf9805ba448a0 26 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 &............... 0xf9805ba448b0 00 00 00 00 90 05 00 00 00 00 00 00 00 00 00 00 ................ 0xf9805ba448c0 a0 3f 54 90 00 00 00 00 f2 c6 e4 ad 6d 83 d0 01 .?T.........m... 0xf9805ba448d0 f2 c6 e4 ad 6d 83 d0 01 18 24 3a 05 d4 82 d0 01 ....m....$:..... Here's the string I expect to see based on the strings output: 4397692928 [kernel:f9805ba44800] Copyright (c) 1992-2004 by P.J. Plauger, licensed by Dinkumware, Ltd. ALL RIGHTS RESERVED. Thanks again for the help. Greg On Fri, May 15, 2015 at 11:30 AM, Michael Ligh <michael.ligh(a)mnin.org> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > Hey Greg....Andrew just (to my surprise) asked me why I was being > "rough" on you, so I apologize if that's how it came across...the goal > was just to point out the issue as fast as possible. > > MHL > > On 5/15/15 11:15 AM, Michael Ligh wrote: > > My command: > > > > db(0xf9805ba44800) > > > > Your command: > > > > db(f9805ba44800) > > > > The missing 0x in front makes Python think f9805ba44800 is a > > variable name rather than a number. > > > > On 5/15/15 11:05 AM, Gregory Pendergast wrote: > >> Thanks Michael. I did try that, and received an error. That's > >> why I thought I must be doing/forgetting something stupid. Now > >> that I'm back at my analysis machine, here's the output: > > > >>>>> db(f9805ba44800) > >> Traceback (most recent call last): File "<console>", line 1, in > >> <module> NameError: name 'f9805ba44800' is not defined > >>>>> addrspace() > >> <volatility.plugins.addrspaces.amd64.AMD64PagedMemory object at > >> 0xbef520c> > >>>>> > >> Note that I'm using Volatilty through the VM provided for the > >> most recent class in Reston, in case the version is in question. > >> The profile for this sample is WIn7SP1x64. > > > >> Thanks, Greg > > > > > > > >> On Fri, May 15, 2015 at 10:49 AM, Michael Ligh > >> <michael.ligh(a)mnin.org <mailto:michael.ligh@mnin.org>> wrote: > > > >> You would just type db(0xf9805ba44800) in volshell (or whatever > >> other address you want to see). > > > >> https://github.com/volatilityfoundation/volatility/wiki/Command%20Ref > e > > > >> > re > > > > > > nce#volshell > >> <https://github.com/volatilityfoundation/volatility/wiki/Command%20Re > f > > > >> > erence#volshell> > > > >> I would also search an electronic copy of the AMF book for > >> "volshell" - there are lots of examples. > > > > > >> On 5/14/15 10:52 PM, Gregory Pendergast wrote: > >>> Thanks Michael. Regarding the latter part of inspecting the > >>> data around the strings, that's where I really need the help. I > >>> know I can accomplish that with volshell, but I'm not > >>> proficient enough yet to know how to get at it. > > > >>> If you could provide the necessary commands to get at the data > >>> around this hit [kernel:f9805ba44800] as an example, that > >>> would be most helpful. > > > >>> I'm sure I was doing something n00bishly wrong, but I could > >>> never get to the point of displaying the data around that > >>> location. I'd be more specific about my attempts, but I'm not > >>> in front of my analysis machine right now and don't recall > >>> exactly what I tried. > > > >>> thanks, greg > > > >>>> On May 14, 2015, at 9:39 PM, Michael Ligh > >>>> <michael.ligh(a)mnin.org > >> <mailto:michael.ligh@mnin.org>> > >>>> wrote: > >>>> > >>> I wouldn't think the module at 0x48706657040b0003 requires > >>> investigation. Not only bc its not in the 0xfffff8 range, but > >>> you might notice legitimate modules are typically loaded at > >>> page aligned base addresses (not XXX0003). Your result looks > >>> like a false positive and given the way modscan works (pool > >>> scanning) its probably a partially overwritten structure in > >>> free/deallocated memory. We *could* put a sanity check in the > >>> code to suppress entries that aren't loaded at page aligned > >>> addresses, but there are a few exceptions where you'll have > >>> modules loaded from non-page aligned addresses. For example, > >>> we just looked at a rootkit today in class that is loaded at > >>> 0x81b91b80 (on a 32-bit system). Jared's advice is also good - > >>> if you ever suspect something like this again, you can use > >>> volshell to display the data at the alleged base address and > >>> see what's there. If its not an MZ signature, then its probably > >>> not a currently loaded module (but keep in mind you can > >>> overwrite the MZ with 00 or anything else as a trick...but in > >>> that case you'll see real executable code not too far away). > > > >>> I would suggest trying to figure out what downloaded the EXE in > >>> the first place, so that you can determine what it does after > >>> the download finishes (drop to disk and run, drop to disk and > >>> run then delete, load directly into memory without touching > >>> disk, etc). I would also inspect the data around the strings > >>> you found in kernel and free memory - is it verbatim with what > >>> you see in the pcap (i.e. just a copy of the packet) or has it > >>> been altered (i.e. unpacked, executed, expanded). > > > >>>>>> On 5/14/15 4:31 PM, Gregory Pendergast wrote: Just as a > >>>>>> follow up to my last reply, the shimcache plugin reported > >>>>>> that there was no shimcache data, and the timeliner > >>>>>> plugin didn't reveal anything apparently interesting > >>>>>> except IE history related to the download. > >>>>>> > >>>>>> Thanks, Greg > >>>>>> > >>>>>> > >>>>>> On May 14, 2015, at 12:35 PM, Jared Greenhill > >>>>>> <jared703(a)gmail.com <mailto:jared703@gmail.com> > >> <mailto:jared703@gmail.com <mailto:jared703@gmail.com>>> wrote: > >>>>>> > >>>>>>> Hey Greg, > >>>>>>> > >>>>>>> A couple thoughts/ideas: > >>>>>>> > >>>>>>> What was the initial reason for investigation- the > >>>>>>> suspect EXE? Do you have a timeframe of the suspect > >>>>>>> activity? > >>>>>>> > >>>>>>> What was the context around the suspect EXE download, > >>>>>>> just the PCAP or? If so, did the memory capture occur > >>>>>>> when there was still an active connection? Sometimes > >>>>>>> this can be a dealbreaker when the connection isn't > >>>>>>> there. > >>>>>>> > >>>>>>> Does moddump work on the module with that base > >>>>>>> address? If so, what type of strings are you seeing? > >>>>>>> > >>>>>>> As far as execution goes, does the shimcache plugin > >>>>>>> provide any results around the time of interest? > >>>>>>> Assuming you have a time of interest, you could also > >>>>>>> try the timeliner plugin to pull in other temporal > >>>>>>> artifacts to hone in around that suspect time. > >>>>>>> > >>>>>>> hope this helps, Jared - @jared703 > >>>>>>> > >>>>>>> > >>>>>>> On Tue, May 12, 2015 at 3:36 PM, Gregory Pendergast > >>>>>>> <greg.pendergast(a)gmail.com > >>>>>>> <mailto:greg.pendergast@gmail.com> > >>>>>>> <mailto:greg.pendergast@gmail.com > >> <mailto:greg.pendergast@gmail.com>>> wrote: > >>>>>>> > >>>>>>> Greeting, > >>>>>>> > >>>>>>> I'm examining a memory sample (captured locally with > >>>>>>> winpmem_1.6.2) <yeah...i know...> > >>>>>>> > >>>>>>> Modscan shows one apparently strange module that has no > >>>>>>> name and no file listed. The base address space also > >>>>>>> seems way out of whack for the rest of the sample. > >>>>>>> > >>>>>>> So all i have are offset, base, and size: > >>>>>>> 0x000000023a80b540 0x48706657040b0003 0xf3a54f0 > >>>>>>> > >>>>>>> In particular, that base address seems way out of range > >>>>>>> compared to everything else in 0xfffff8.... space > >>>>>>> > >>>>>>> How can I tell if this is an error of some kind in the > >>>>>>> captured sample versus a legitimate anomaly that bears > >>>>>>> investigation? > >>>>>>> > >>>>>>> > >>>>>>> Lastly, and pardon me if this is a n00b question, but > >>>>>>> how can I determine why specific strings appear in > >>>>>>> kernel memory (based on strings plugin output)? For > >>>>>>> context, I have a suspicious executable download, but > >>>>>>> there appears to be no evidence of the file in $MFT (I > >>>>>>> don't have access to UsnJrnl) and I'm trying to find > >>>>>>> out what happened to it and whether it ran. Strings > >>>>>>> from the executable (ontained from pcap) do appear in > >>>>>>> Free Memory and Kernel memory, but I'm not clear > >>>>>>> whether that's a symptom of the download or a sign of > >>>>>>> execution. > >>>>>>> > >>>>>>> Thanks, greg > >>>>>>> > >>>>>>> > >>>>>>>>> On May 11, 2015, at 11:30 AM, Torres, Geoff (Cyber > >>>>>>>>> Security) > >>>>>>>> <geoff.torres(a)hp.com <mailto:geoff.torres@hp.com> > >> <mailto:geoff.torres@hp.com <mailto:geoff.torres@hp.com>>> > >>>>>>>> wrote: > >>>>>>>> > >>>>>>>> Thanks Michael, > >>>>>>>> > >>>>>>>> I confirm that I now see what I was expecting. > >>>>>>>> Sorry for the > >>>>>>> rookie mistake. > >>>>>>>> > >>>>>>>> I *really* need to get to your class... > >>>>>>>> > >>>>>>>> Geoff > >>>>>>>> > >>>>>>>>> Don't be afraid to tell me I'm doing something > >>>>>>>>> stupid... :-) > >>>>>>>> > >>>>>>>> I only said that because I didn't think I was... > >>>>>>>> :-P > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> -----Original Message----- From: > >>>>>>>> vol-users-bounces(a)volatilityfoundation.org > >> <mailto:vol-users-bounces@volatilityfoundation.org> > >>>>>>> <mailto:vol-users-bounces@volatilityfoundation.org > >> <mailto:vol-users-bounces@volatilityfoundation.org>> > >>>>>>> [mailto:vol-users-bounces@volatilityfoundation.org > >> <mailto:vol-users-bounces@volatilityfoundation.org> > >>>>>>> <mailto:vol-users-bounces@volatilityfoundation.org > >> <mailto:vol-users-bounces@volatilityfoundation.org>>] On Behalf > >>>>>>> Of Michael Ligh > >>>>>>>> Sent: Saturday, May 09, 2015 9:00 AM To: > >>>>>>>> vol-users(a)volatilityfoundation.org > >> <mailto:vol-users@volatilityfoundation.org> > >>>>>>> <mailto:vol-users@volatilityfoundation.org > >> <mailto:vol-users@volatilityfoundation.org>> > >>>>>>>> Subject: Re: [Vol-users] Output of strings not found > >>>>>>>> in memdump > >>>>>>> output - QEMU/QEVM sample > >>>>>> Hi Geoff, > >>>>>> > >>>>>> The key to get strings working is to make sure you have a > >>>>>> raw > >>>>>>>> memory dump. lqs2mem *should* give you that, however > >>>>>>>> I've not personally used it before. > >>>>>> > >>>>>> One discrepancy I see with your logic is regarding this > >>>>>> line: > >>>>>> > >>>>>> memory_dump.ram.vol.strings:183190042 [3156:0189321a] > >>>>>>>> <Search_String> > >>>>>> > >>>>>> It tells you the search string is at virtual address > >>>>>> 0189321a in > >>>>>>>> pid 3156. You then dumped the *executable* for pid > >>>>>>>> 3156 which gives you memory from the base of the exe > >>>>>>>> 400000 to its base + size (nowhere near 0189321a). > >>>>>> > >>>>>> Try using the memdump or vaddump plugins on 3156 instead. > >>>>>> That > >>>>>>>> will give you ALL of the process's addressable > >>>>>>>> memory, not just the range that contains the exe. > >>>>>> > >>>>>> MHL > >>>>>> > >>>>>>>>>> On 5/7/15 3:03 PM, Torres, Geoff (Cyber Security) > >>>>>>>>>> wrote: Hi, > >>>>>>>>>> > >>>>>>>>>> Sorry for the 'me too' response, but I'm having > >>>>>>>>>> this exact same problem. However, the main > >>>>>>>>>> difference is that I'm using a 'QEMU' memory > >>>>>>>>>> image (Hex dump sig is QEVM in the first 4 bytes) > >>>>>>>>>> from a > >>>>>>>> cloud > >>>>>>>>>> instance. > >>>>>>>>>> > >>>>>>>>>> I've converted these in the past using the > >>>>>>>>>> 'lqs2mem' tool > >>>>>>>> written by > >>>>>>>>>> Juerg Haefliger and Andrew Tappert and it's > >>>>>>>>>> worked perfectly > >>>>>>>> for the > >>>>>>>>>> 'netscan' and 'ps' type plugins. However, I > >>>>>>>>>> haven't needed to dump processes before and look > >>>>>>>>>> for specific strings. I can locate the strings > >>>>>>>>>> in the converted image, but it's not translating > >>>>>>>>>> to the processes that are identified by the > >>>>>>>>>> 'strings' plugin. > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> Here's the steps I've been taking - > >>>>>>>>>> > >>>>>>>>>> ## Memory dump info > >>>>>>>>>>> ll memory_dump > >>>>>>>>>> -rw------- 1 geoff citsirt 7579914273 Apr 27 > >>>>>>>>>> 13:36 memory_dump > >>>>>>>>>> > >>>>>>>>>>> file memory_dump > >>>>>>>>>> memory_dump: QEMU suspend to disk image > >>>>>>>>>> > >>>>>>>>>>> xxd memory_dump | head -n1 > >>>>>>>>>> 0000000: 5145 564d 0000 0003 0100 0000 0105 626c > >>>>>>>>>> QEVM..........bl > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> ## Convert the dump > >>>>>>>>>>> lqs2mem -w pc.ram memory_dump memory_dump.ram > >>>>>>>>>> section = pc.ram size = > >>>>>>>>>> 8192 [MB] 8589934592 [bytes] section = pc.bios > >>>>>>>>>> size = 128 [KB] 131072 [bytes] section = > >>>>>>>>>> pc.rom size = 128 [KB] 131072 [bytes] > >>>>>>>>>> section = vga.vram size = 16 [MB] 16777216 > >>>>>>>>>> [bytes] section = 0000:00:02.0/cirrus_vga.rom > >>>>>>>>>> size = 64 [KB] 65536 [bytes] Wrote 8589934592 > >>>>>>>>>> bytes from section 'pc.ram' to file > >>>>>>>>>> memory_dump.ram > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> ## Create the strings file > >>>>>>>>>>> strings -a -t d memory_dump.ram > > >>>>>>>>>>> memory_dump.ram.strings > >>>>>>>>>> > >>>>>>>>>>> strings -a -t d -el memory_dump.ram >> > >>>>>>>>>>> memory_dump.ram.strings > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> ## Create the volatility strings file > >>>>>>>>>>> python > >>>>>>>>>>> /data/download/apps/forensic_tools/volatility/vol.py > >>>>>>>>>>> > >>>>>>>>>>> > > > >>>>>>>>>>> > - -f memory_dump.ram --profile=Win2008SP2x64 strings > >>>>>>>>>>> -s --output-file=memory_dump.ram.vol.strings > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>> ll memory_dump.ram.strings > >>>>>>>>>>> memory_dump.ram.vol.strings > >>>>>>>>>> -rw-rw-r-- 1 geoff citsirt 2914258187 May 7 > >>>>>>>>>> 08:58 memory_dump.ram.strings -rw-rw-r-- 1 geoff > >>>>>>>>>> citsirt 4292775089 May 7 12:17 > >>>>>>>>>> memory_dump.ram.vol.strings > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> ## '<Search_String>' is found in both string > >>>>>>>>>> files as expected > >>>>>>>>>>> fgrep <Search_String> memory_dump.ram.strings > >>>>>>>>>>> memory_dump.ram.vol.strings > >>>>>>>>>> memory_dump.ram.strings:183190042 <Search_String> > >>>>>>>>>> memory_dump.ram.vol.strings:183190042 > >>>>>>>>>> [3156:0189321a] > >>>>>>>> <Search_String> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> ## Dump process 3156 as identified by volatility > >>>>>>>>>>> python > >>>>>>>>>>> /data/download/apps/forensic_tools/volatility/vol.py > >>>>>>>>>>> > >>>>>>>>>>> > > > >>>>>>>>>>> > - -f memory_dump.ram --profile=Win2008SP2x64 procdump > >>>>>>>>>>> -p 3156 -D processes -m > >>>>>>>>>> Volatility Foundation Volatility Framework 2.4 > >>>>>>>>>> Process(V) ImageBase Name Result > >>>>>>>>>> ------------------ ------------------ > >>>>>>>>>> -------------------- ------ 0xfffffa800a4e6370 > >>>>>>>>>> 0x0000000000400000 iwproxy.exe OK: > >>>>>>>>>> executable.3156.exe > >>>>>>>>>> > >>>>>>>>>>> ll processes/executable.3156.exe > >>>>>>>>>> -rw-rw-r-- 1 geoff citsirt 3248128 May 7 12:35 > >>>>>>>>>> processes/executable.3156.exe > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> ## '<Search_String>' not found in the dumped > >>>>>>>>>> executable > >>>>>>>>>>> strings -a processes/executable.3156.exe | > >>>>>>>>>>> fgrep <Search_String> strings -a -el > >>>>>>>>>>> processes/executable.3156.exe | fgrep > >>>>>>>>>>> <Search_String> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> I've tried many different variations of the above > >>>>>>>>>> steps and all have the same results. > >>>>>>>>>> > >>>>>>>>>> According to what I've read in this thread is > >>>>>>>>>> that the issue is to make sure the original dump > >>>>>>>>>> is properly converted. How can I do that? > >>>>>>>>>> 'lqs2mem' has limited options. > >>>>>>>>>> > >>>>>>>>>> Any ideas on what I can do differently to get > >>>>>>>>>> this to work? > >>>>>>>>>> > >>>>>>>>>> Thanks, > >>>>>>>>>> > >>>>>>>>>> Geoff > >>>>>>>>>> > >>>>>>>>>> Don't be afraid to tell me I'm doing something > >>>>>>>>>> stupid... :-) > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> -----Original Message----- From: > >>>>>>>>>> vol-users-bounces(a)volatilityfoundation.org > >> <mailto:vol-users-bounces@volatilityfoundation.org> > >>>>>>>> <mailto:vol-users-bounces@volatilityfoundation.org > >> <mailto:vol-users-bounces@volatilityfoundation.org>> > >>>>>>>>>> [mailto:vol-users-bounces@volatilityfoundation.org > >> <mailto:vol-users-bounces@volatilityfoundation.org> > >>>>>>>> <mailto:vol-users-bounces@volatilityfoundation.org > >> <mailto:vol-users-bounces@volatilityfoundation.org>>] On Behalf > >>>>>>>> Of Michael > >>>>>>>>>> Ligh Sent: Tuesday, March 24, 2015 6:49 AM To: > >>>>>>>>>> Bridgey theGeek Cc: > >>>>>>>>>> vol-users(a)volatilityfoundation.org > >> <mailto:vol-users@volatilityfoundation.org> > >>>>>>>> <mailto:vol-users@volatilityfoundation.org > >> <mailto:vol-users@volatilityfoundation.org>> Subject: Re: > >>>>>>>> [Vol-users] Output of > >>>>>>>>>> strings not found in memdump output > >>>>>>>>>> > >>>>>>>>>> Perfect! Glad to hear all is good in the world > >>>>>>>>>> ;-) > >>>>>>>>>> > >>>>>>>>>> MHL > >>>>>>>>>> > >>>>>>>>>>> On 3/24/15 5:05 AM, Bridgey theGeek wrote: > >>>>>>>>>>> Awesome, thanks Michael. > >>>>>>>>>> > >>>>>>>>>>> I generated a raw dump as follows, with the > >>>>>>>>>>> vmsn and vmem files in the same folder: $ > >>>>>>>>>>> python vol.py -f winxp.vmem > >>>>>>>>>>> --profile=WinXPSP2x86 imagecopy -O winxp.raw > >>>>>>>>>> > >>>>>>>>>>> Then ran strings again (having generated a new > >>>>>>>>>>> input text file because of course the offsets > >>>>>>>>>>> will be different): $ python vol.py -f > >>>>>>>>>>> winxp.raw --profile=WinXPSP2x86 strings -s > >>>>>>>>>>> pk.txt > >>>>>>>>>> > >>>>>>>>>>> I was then able to find the banner at the > >>>>>>>>>>> offsets reported by strings. And all was good > >>>>>>>>>>> in the world. > >>>>>>>>>> > >>>>>>>>>>> Thank you very much for the support. > >>>>>>>>>> > >>>>>>>>>>> Adam > >>>>>>>>>> > >>>>>>>>>>> On 23 March 2015 at 19:39, Michael Ligh > >>>>>>>>>>> <michael.ligh(a)mnin.org > >>>>>>>>>>> <mailto:michael.ligh@mnin.org> > >>>>>>>> <mailto:michael.ligh@mnin.org > >>>>>>>> <mailto:michael.ligh@mnin.org>> > >>>>>>>>>>> <mailto:michael.ligh@mnin.org > >>>>>>>>>>> <mailto:michael.ligh@mnin.org> > >>>>>>>>>>> <mailto:michael.ligh@mnin.org > >> <mailto:michael.ligh@mnin.org>>>> > >>>>>>>> wrote: > >>>>>>>>>> > >>>>>>>>>>> Hey Adam, > >>>>>>>>>> > >>>>>>>>>>> A few things: > >>>>>>>>>> > >>>>>>>>>>> * Yes, vmss2core creates a windows crash dump > >>>>>>>>>>> * You can use volatility on the original > >>>>>>>>>>> vmem/vmss by doing the following: > >>>>>>>>>> > >>>>>>>>>>> * make sure both vmem and vmss files are in the > >>>>>>>>>>> same dir * make sure they have the same base > >>>>>>>>>>> name (i.e. test.vmem and test.vmss) * run your > >>>>>>>>>>> volatility plugins against the vmem > >>>>>>>>>> > >>>>>>>>>>> In this case, it would also be required to > >>>>>>>>>>> generate a raw memory dump before running > >>>>>>>>>>> strings. So you would use imagecopy on the > >>>>>>>>>>> vmem. > >>>>>>>>>> > >>>>>>>>>>> LMK if that helps! Michael > >>>>>>>>>> > >>>>>>>>>>>> On 3/23/15 10:51 AM, Bridgey theGeek wrote: > >>>>>>>>>>>> Hi Michael, > >>>>>>>>>> > >>>>>>>>>>>> *sigh* When will I learn to check the origin > >>>>>>>>>>>> of my samples?! > >>>>>>>>>> > >>>>>>>>>>>> The guy who provided me with the sample > >>>>>>>>>>>> tells me that he took a snapshot of a VMWare > >>>>>>>>>>>> machine and then used vss2core to convert it. > >>>>>>>>>>>> I BELIEVE that makes it into a Windows Memory > >>>>>>>>>>>> Core Dump..? > >>>>>>>>>> > >>>>>>>>>>>> I got hold of the original vmem and vmsn > >>>>>>>>>>>> files. Trying to use imagecopy on the vmsn > >>>>>>>>>>>> just replicated the input file. I think the > >>>>>>>>>>>> header is not what Volatility would expect: > >>>>>>>>>>>> $ xxd Windows\ XP\ Pro\ SP2\ > >>>>>>>>>>>> $32-bit$-Snapshot49.vmsn |head 0000000: > >>>>>>>>>>>> d2be d2be 0800 0000 6300 0000 4368 6563 > >>>>>>>>>>>> ........c...Chec 0000010: 6b70 6f69 6e74 0000 > >>>>>>>>>>>> 0000 0000 0000 0000 kpoint.......... > >>>>>>>>>>>> 0000020: 0000 0000 0000 0000 0000 0000 0000 > >>>>>>>>>>>> 0000 ................ 0000030: 0000 0000 0000 > >>>>>>>>>>>> 0000 0000 0000 0000 0000 ................ > >>>>>>>>>>>> 0000040: 0000 0000 0000 0000 0000 0000 fc1e > >>>>>>>>>>>> 0000 ................ 0000050: 0000 0000 ab03 > >>>>>>>>>>>> 0000 0000 0000 4775 6573 ............Gues > >>>>>>>>>>>> 0000060: 7456 6172 7300 0000 0000 0000 0000 > >>>>>>>>>>>> 0000 tVars........... 0000070: 0000 0000 0000 > >>>>>>>>>>>> 0000 0000 0000 0000 0000 ................ > >>>>>>>>>>>> 0000080: 0000 0000 0000 0000 0000 0000 0000 > >>>>>>>>>>>> 0000 ................ 0000090: 0000 0000 0000 > >>>>>>>>>>>> 0000 0000 0000 a722 0000 .............".. > >>>>>>>>>> > >>>>>>>>>>>> Does that mean I can't use this with > >>>>>>>>>>>> Volatility? > >>>>>>>>>> > >>>>>>>>>>>> Thank you, Adam > >>>>>>>>>> > >>>>>>>>>>>> On 23 March 2015 at 14:57, Michael Ligh > >>>>>>>> <michael.ligh(a)mnin.org > >>>>>>>> <mailto:michael.ligh@mnin.org> > >> <mailto:michael.ligh@mnin.org <mailto:michael.ligh@mnin.org>> > >>>>>>>>>>>> <mailto:michael.ligh@mnin.org > >>>>>>>>>>>> <mailto:michael.ligh@mnin.org> > >>>>>>>>>>>> <mailto:michael.ligh@mnin.org > >> <mailto:michael.ligh@mnin.org>>> > >>>>>>>> <mailto:michael.ligh@mnin.org > >>>>>>>> <mailto:michael.ligh@mnin.org> > >>>>>>>> <mailto:michael.ligh@mnin.org > >>>>>>>> <mailto:michael.ligh@mnin.org>> > >>>>>>>>>>>> <mailto:michael.ligh@mnin.org > >>>>>>>>>>>> <mailto:michael.ligh@mnin.org> > >>>>>>>> <mailto:michael.ligh@mnin.org > >> <mailto:michael.ligh@mnin.org>>>>> wrote: > >>>>>>>>>> > >>>>>>>>>>>> Hey Adam, > >>>>>>>>>> > >>>>>>>>>>>> We forgot to ask if the sample was a raw > >>>>>>>>>>>> memory dump. For example: > >>>>>>>>>> > >>>>>>>>>>>> $ xxd ~/Desktop/memory.dmp | less > >>>>>>>>>> > >>>>>>>>>>>> 0000000: 5041 4745 4455 4d50 0f00 0000 280a > >>>>>>>>>>>> 0000 PAGEDUMP....(... 0000010: 8001 6c07 > >>>>>>>>>>>> 00c0 e680 a031 5580 5892 5580 > >>>>>>>>>>>> ..l......1U.X.U. 0000020: 4c01 0000 0100 0000 > >>>>>>>>>>>> 8000 0000 5444 4f00 L...........TDO. 0000030: > >>>>>>>>>>>> 0000 0000 0000 0000 0000 0000 5041 4745 > >>>>>>>>>>>> ............PAGE 0000040: 5041 4745 5041 4745 > >>>>>>>>>>>> 5041 4745 5041 4745 PAGEPAGEPAGEPAGE > >>>>>>>>>> > >>>>>>>>>>>> If its something like a crash dump, > >>>>>>>>>>>> hibernation, etc then the file format > >>>>>>>>>>>> headers throw off the offsets. You can > >>>>>>>>>>>> convert those special file types into a raw > >>>>>>>>>>>> memory dump with the imagecopy plugin and > >>>>>>>>>>>> then your strings translations should be > >>>>>>>>>>>> accurate. > >>>>>>>>>> > >>>>>>>>>>>> Cheers! MHL > >>>>>>>>>> > >>>>>>>>>>>>> On 3/23/15 8:54 AM, Bridgey theGeek wrote: > >>>>>>>>>>>>> Hi Andrew, > >>>>>>>>>> > >>>>>>>>>>>>> I was certain I was running the latest > >>>>>>>>>>>>> version, but just to be sure I grabbed the > >>>>>>>>>>>>> latest version. Same result, same offsets. > >>>>>>>>>> > >>>>>>>>>>>>> I can make the sample available, but more > >>>>>>>>>>>>> than happy to do whatever debugging needs > >>>>>>>>>>>>> doing (if I can!) > >>>>>>>>>> > >>>>>>>>>>>>> Adam > >>>>>>>>>> > >>>>>>>>>>>>> On 23 March 2015 at 13:03, Andrew Case > >>>>>>>>>>>>> <atcuno(a)gmail.com > >>>>>>>>>>>>> <mailto:atcuno@gmail.com> > >>>>>>>> <mailto:atcuno@gmail.com <mailto:atcuno@gmail.com>> > >>>>>>>>>>>>> <mailto:atcuno@gmail.com > >>>>>>>>>>>>> <mailto:atcuno@gmail.com> > >>>>>>>>>>>>> <mailto:atcuno@gmail.com > >>>>>>>>>>>>> <mailto:atcuno@gmail.com>>> > >>>>>>>> <mailto:atcuno@gmail.com <mailto:atcuno@gmail.com> > >> <mailto:atcuno@gmail.com <mailto:atcuno@gmail.com>> > >>>>>>>>>>>>> <mailto:atcuno@gmail.com > >>>>>>>>>>>>> <mailto:atcuno@gmail.com> > >>>>>>>>>>>>> <mailto:atcuno@gmail.com > >>>>>>>>>>>>> <mailto:atcuno@gmail.com>>>> > >>>>>>>>>>> <mailto:atcuno@gmail.com > >>>>>>>>>>> <mailto:atcuno@gmail.com> > >> <mailto:atcuno@gmail.com <mailto:atcuno@gmail.com>> > >>>>>>>> <mailto:atcuno@gmail.com <mailto:atcuno@gmail.com> > >> <mailto:atcuno@gmail.com <mailto:atcuno@gmail.com>>> > >>>>>>>>>>>>> <mailto:atcuno@gmail.com > >>>>>>>>>>>>> <mailto:atcuno@gmail.com> > >>>>>>>>>>>>> <mailto:atcuno@gmail.com > >>>>>>>>>>>>> <mailto:atcuno@gmail.com>> > >>>>>>>> <mailto:atcuno@gmail.com <mailto:atcuno@gmail.com> > >> <mailto:atcuno@gmail.com <mailto:atcuno@gmail.com>>>>>> > >>>>>>>> wrote: > >>>>>>>>>> > >>>>>>>>>>>>> Are you using the latest git checkout of > >>>>>>>>>>>>> Volatility or the 2.4 release? Can you try > >>>>>>>>>>>>> the latest checkout and re-run Volatility > >>>>>>>>>>>>> strings (you can run it on just the > >>>>>>>>>>>>> offsets from PID 123 to make it faster). > >>>>>>>>>> > >>>>>>>>>>>>> If you are already on the latest checkout > >>>>>>>>>>>>> then we will need to debug further. > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>>>> Thanks, Andrew (@attrc) > >>>>>>>>>> > >>>>>>>>>>>>>> On 03/23/2015 04:38 AM, Bridgey theGeek > >>>>>>>>>>>>>> wrote: Thanks Andrew: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> python vol.py --profile=WinXPSP2x86 -f > >>>>>>>>>>>>>> memory.dmp volshell -p 123 Volatility > >>>>>>>>>>>>>> Foundation Volatility Framework 2.4 > >>>>>>>>>>>>>> Current context: myapp.exe @ 0x822042f8, > >>>>>>>>>>>>>> pid=123, ppid=392 > >>>>>>>>>>>>> DTB=0x76c0040 > >>>>>>>>>>>>>> Welcome to volshell! Current memory image > >>>>>>>>>>>>>> is: file:///home/memory.dmp To get > >>>>>>>>>>>>>> help, type 'hh()' > >>>>>>>>>>>>>>>>> db(0x75b6b4d8) > >>>>>>>>>>>>>> 0x75b6b4d8 c3 7c 15 c7 85 00 ff ff ff > >>>>>>>>>>>>>> 01 00 00 00 75 09 8d .|...........u.. > >>>>>>>>>>>>>> 0x75b6b4e8 85 0c ff ff ff 50 ff 17 39 9d > >>>>>>>>>>>>>> 00 ff ff ff 89 85 .....P..9....... > >>>>>>>>>>>>>> 0x75b6b4f8 30 ff ff ff 74 12 6a 0c 8d 85 > >>>>>>>>>>>>>> c4 fe ff ff 50 6a 0...t.j.......Pj > >>>>>>>>>>>>>> 0x75b6b508 07 6a fe e8 ea 92 ff ff 83 bd > >>>>>>>>>>>>>> 28 ff ff ff 0c 0f .j........(..... > >>>>>>>>>>>>>> 0x75b6b518 84 8c 59 00 00 e9 18 ff ff ff > >>>>>>>>>>>>>> 90 90 47 00 6c 00 ..Y.........G.l. > >>>>>>>>>>>>>> 0x75b6b528 6f 00 62 00 61 00 6c 00 5c 00 > >>>>>>>>>>>>>> 54 00 65 00 72 00 o.b.a.l.\.T.e.r. > >>>>>>>>>>>>>> 0x75b6b538 6d 00 53 00 72 00 76 00 52 00 > >>>>>>>>>>>>>> 65 00 61 00 64 00 m.S.r.v.R.e.a.d. > >>>>>>>>>>>>>> 0x75b6b548 79 00 45 00 76 00 65 00 6e 00 > >>>>>>>>>>>>>> 74 00 00 00 90 90 y.E.v.e.n.t..... > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Nope, still no banner. But it is > >>>>>>>>>>>>>> identical to what I find at > >>>>>>>>>>>>> 0x1a34d8 in > >>>>>>>>>>>>>> 123.dmp. (As you'd expect.) > >>>>>>>>>>>>>> Double-checked that I was searching > >>>>>>>>>>>>>> Unicode and ASCII - still no luck. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Hmmm. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Adam > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> On 23 March 2015 at 04:02, Andrew Case > >>>>>>>>>>>>>> <atcuno(a)gmail.com > >>>>>>>>>>>>>> <mailto:atcuno@gmail.com> > >>>>>>>> <mailto:atcuno@gmail.com <mailto:atcuno@gmail.com>> > >>>>>>>>>>> <mailto:atcuno@gmail.com > >>>>>>>>>>> <mailto:atcuno@gmail.com> > >>>>>>>>>>> <mailto:atcuno@gmail.com > >>>>>>>>>>> <mailto:atcuno@gmail.com>>> > >>>>>>>>>>>> <mailto:atcuno@gmail.com > >>>>>>>>>>>> <mailto:atcuno@gmail.com> > >>>>>>>>>>>> <mailto:atcuno@gmail.com > >>>>>>>>>>>> <mailto:atcuno@gmail.com>> > >>>>>>>> <mailto:atcuno@gmail.com <mailto:atcuno@gmail.com> > >> <mailto:atcuno@gmail.com <mailto:atcuno@gmail.com>>>> > >>>>>>>>>>>>> <mailto:atcuno@gmail.com > >>>>>>>>>>>>> <mailto:atcuno@gmail.com> > >>>>>>>>>>>>> <mailto:atcuno@gmail.com > >>>>>>>>>>>>> <mailto:atcuno@gmail.com>> > >>>>>>>> <mailto:atcuno@gmail.com <mailto:atcuno@gmail.com> > >> <mailto:atcuno@gmail.com <mailto:atcuno@gmail.com>>> > >>>>>>>>>>> <mailto:atcuno@gmail.com > >>>>>>>>>>> <mailto:atcuno@gmail.com> > >> <mailto:atcuno@gmail.com <mailto:atcuno@gmail.com>> > >>>>>>>> <mailto:atcuno@gmail.com <mailto:atcuno@gmail.com> > >> <mailto:atcuno@gmail.com <mailto:atcuno@gmail.com>>>>> > >>>>>>>>>>>>>> <mailto:atcuno@gmail.com > >>>>>>>>>>>>>> <mailto:atcuno@gmail.com> > >>>>>>>>>>>>>> <mailto:atcuno@gmail.com > >>>>>>>>>>>>>> <mailto:atcuno@gmail.com>> > >>>>>>>> <mailto:atcuno@gmail.com <mailto:atcuno@gmail.com> > >> <mailto:atcuno@gmail.com <mailto:atcuno@gmail.com>>> > >>>>>>>>>>> <mailto:atcuno@gmail.com > >>>>>>>>>>> <mailto:atcuno@gmail.com> > >> <mailto:atcuno@gmail.com <mailto:atcuno@gmail.com>> > >>>>>>>> <mailto:atcuno@gmail.com <mailto:atcuno@gmail.com> > >> <mailto:atcuno@gmail.com <mailto:atcuno@gmail.com>>>> > >>>>>>>>>>>> <mailto:atcuno@gmail.com > >>>>>>>>>>>> <mailto:atcuno@gmail.com> > >>>>>>>>>>>> <mailto:atcuno@gmail.com > >>>>>>>>>>>> <mailto:atcuno@gmail.com>> > >>>>>>>> <mailto:atcuno@gmail.com <mailto:atcuno@gmail.com> > >> <mailto:atcuno@gmail.com <mailto:atcuno@gmail.com>>> > >>>>>>>>>>> <mailto:atcuno@gmail.com > >>>>>>>>>>> <mailto:atcuno@gmail.com> > >> <mailto:atcuno@gmail.com <mailto:atcuno@gmail.com>> > >>>>>>>> <mailto:atcuno@gmail.com <mailto:atcuno@gmail.com> > >> <mailto:atcuno@gmail.com <mailto:atcuno@gmail.com>>>>>>> > >>>>>>>> wrote: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Can do you: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> vol.py ... volshell -p 123 > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Then in volshell do: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> db(0x75b6b4d8) > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> And see if you get the banner printed at > >>>>>>>>>>>>>> the beginning? > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Also, how are you searching 123.dmp? Did > >>>>>>>>>>>>>> you search ascii & > >>>>>>>>>>>>> unicode > >>>>>>>>>>>>>> (most common error) > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Thanks, Andrew (@attrc) > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> On 03/20/2015 03:59 PM, Bridgey theGeek > >>>>>>>>>>>>>>> wrote: Hi all, > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> I can't quite see what's wrong with my > >>>>>>>>>>>>>>> logic here, but I must be > >>>>>>>>>>>>>> missing > >>>>>>>>>>>>>>> something. Hoping someone can help me > >>>>>>>>>>>>>>> out. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> I'm looking for a private key in a > >>>>>>>>>>>>>>> memory sample (WinXPSP2x86). > >>>>>>>>>>>>>>> Specifically, to find out which > >>>>>>>>>>>>>>> process/es is/are accessing it. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> I can find the key by searching the raw > >>>>>>>>>>>>>>> memory dump > >>>>>>>>>>>>> (memory.dmp). > >>>>>>>>>>>>>>> As you might expect it's between: > >>>>>>>>>>>>>>> -----BEGIN RSA PRIVATE KEY----- > >>>>>>>>>>>>>>> -----END RSA PRIVATE KEY----- > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> I generated an offset:string file by > >>>>>>>>>>>>>>> using strings. Then, using the strings > >>>>>>>>>>>>>>> plugin I get this output: $ python > >>>>>>>>>>>>>>> vol.py -f memory.dmp > >>>>>>>>>>>>>>> --profile=WinXPSP2x86 strings > >>>>>>>>>>>>> -s pk.txt > >>>>>>>>>>>>>>> Volatility Foundation Volatility > >>>>>>>>>>>>>>> Framework 2.4 188435934 [FREE > >>>>>>>>>>>>>>> MEMORY:-1] -----BEGIN RSA PRIVATE > >>>>>>>>>>>>>>> KEY----- 188435968 [FREE MEMORY:-1] > >>>>>>>>>>>>>>> -----END RSA PRIVATE KEY----- 317375704 > >>>>>>>>>>>>>>> [kernel:d2ab24d8] -----BEGIN RSA > >>>>>>>>>>>>>>> PRIVATE KEY----- 317376575 > >>>>>>>>>>>>>>> [kernel:d2ab283f] -----END RSA PRIVATE > >>>>>>>>>>>>>>> KEY----- 417203416 [123:75b6b4d8] > >>>>>>>>>>>>>>> -----BEGIN RSA PRIVATE KEY----- > >>>>>>>>>>>>>>> 417204287 [123:75b6b83f] -----END RSA > >>>>>>>>>>>>>>> PRIVATE KEY----- 419888606 [FREE > >>>>>>>>>>>>>>> MEMORY:-1] -----BEGIN RSA PRIVATE > >>>>>>>>>>>>>>> KEY----- 419888640 [FREE MEMORY:-1] > >>>>>>>>>>>>>>> -----END RSA PRIVATE KEY----- > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Lovely. So I now do a memdump of > >>>>>>>>>>>>>>> process 123: $ python vol.py -f > >>>>>>>>>>>>>>> memory.dmp --profile=WinXPSP2x86 > >>>>>>>>>>>>>>> memdump > >>>>>>>>>>>>> --pid=123 > >>>>>>>>>>>>>>> --dump-dir=123 Volatility Foundation > >>>>>>>>>>>>>>> Volatility Framework 2.4 > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>> *************************************************************** > * > > > >>>>>>>> > * > > > >>>>>>>> > > *** > > > >>>>>>>> > >> * > >>>>>> > >>> * > >>>>>> ** > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>>>>> Writing myapp.exe [ 123] to 123.dmp > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> However, if I search 123.dmp neither > >>>>>>>>>>>>>>> the BEGIN or END > >>>>>>>>>>>>> strings are > >>>>>>>>>>>>>> present. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> So I thought I'd try and find it via > >>>>>>>>>>>>>>> the virtual address give, > >>>>>>>>>>>>>> 0x75b6b4d8: > >>>>>>>>>>>>>>> $ python vol.py -f memory.dmp > >>>>>>>>>>>>>>> --profile=WinXPSP2x86 memmap > >>>>>>>>>>>>> --pid=123 > >>>>>>>>>>>>>>> Virtual Physical Size > >>>>>>>>>>>>>>> DumpFileOffset ---------- ---------- > >>>>>>>>>>>>>>> ---------- -------------- --SNIP-- > >>>>>>>>>>>>>>> 0x75b6b000 0x18de0000 0x1000 > >>>>>>>>>>>>>>> 0x1a3000 --SNIP-- > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> The text is indeed at 0x18de04d8 in > >>>>>>>>>>>>>>> memory.dmp, but not at > >>>>>>>>>>>>> 0x1a34d8 in > >>>>>>>>>>>>>>> 123.dmp. Again, it's no where to be > >>>>>>>>>>>>>>> found in 123.dmp. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Any suggestions..?? > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Many thanks, Adam > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> _______________________________________________ > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > > Vol-users mailing list > >>>>>>>>>>>>>>> Vol-users(a)volatilityfoundation.org > >> <mailto:Vol-users@volatilityfoundation.org> > >>>>>>>> <mailto:Vol-users@volatilityfoundation.org > >> <mailto:Vol-users@volatilityfoundation.org>> > >>>>>>>>>>> <mailto:Vol-users@volatilityfoundation.org > >> <mailto:Vol-users@volatilityfoundation.org> > >>>>>>>> <mailto:Vol-users@volatilityfoundation.org > >> <mailto:Vol-users@volatilityfoundation.org>>> > >>>>>>>>>>>> <mailto:Vol-users@volatilityfoundation.org > >> <mailto:Vol-users@volatilityfoundation.org> > >>>>>>>> <mailto:Vol-users@volatilityfoundation.org > >> <mailto:Vol-users@volatilityfoundation.org>> > >>>>>>>>>>> <mailto:Vol-users@volatilityfoundation.org > >> <mailto:Vol-users@volatilityfoundation.org> > >>>>>>>> <mailto:Vol-users@volatilityfoundation.org > >> <mailto:Vol-users@volatilityfoundation.org>>>> > >>>>>>>>>>>>> <mailto:Vol-users@volatilityfoundation.org > >> <mailto:Vol-users@volatilityfoundation.org> > >>>>>>>> <mailto:Vol-users@volatilityfoundation.org > >> <mailto:Vol-users@volatilityfoundation.org>> > >>>>>>>>>>> <mailto:Vol-users@volatilityfoundation.org > >> <mailto:Vol-users@volatilityfoundation.org> > >>>>>>>> <mailto:Vol-users@volatilityfoundation.org > >> <mailto:Vol-users@volatilityfoundation.org>>> > >>>>>>>>>>>> <mailto:Vol-users@volatilityfoundation.org > >> <mailto:Vol-users@volatilityfoundation.org> > >>>>>>>> <mailto:Vol-users@volatilityfoundation.org > >> <mailto:Vol-users@volatilityfoundation.org>> > >>>>>>>>>>> <mailto:Vol-users@volatilityfoundation.org > >> <mailto:Vol-users@volatilityfoundation.org> > >>>>>>>> <mailto:Vol-users@volatilityfoundation.org > >> <mailto:Vol-users@volatilityfoundation.org>>>>> > >>>>>>>>>>>>> <mailto:Vol-users@volatilityfoundation.org > >> <mailto:Vol-users@volatilityfoundation.org> > >>>>>>>> <mailto:Vol-users@volatilityfoundation.org > >> <mailto:Vol-users@volatilityfoundation.org>> > >>>>>>>>>>> <mailto:Vol-users@volatilityfoundation.org > >> <mailto:Vol-users@volatilityfoundation.org> > >>>>>>>> <mailto:Vol-users@volatilityfoundation.org > >> <mailto:Vol-users@volatilityfoundation.org>>> > >>>>>>>>>>>> <mailto:Vol-users@volatilityfoundation.org > >> <mailto:Vol-users@volatilityfoundation.org> > >>>>>>>> <mailto:Vol-users@volatilityfoundation.org > >> <mailto:Vol-users@volatilityfoundation.org>> > >>>>>>>>>>> <mailto:Vol-users@volatilityfoundation.org > >> <mailto:Vol-users@volatilityfoundation.org> > >>>>>>>> <mailto:Vol-users@volatilityfoundation.org > >> <mailto:Vol-users@volatilityfoundation.org>>>> > >>>>>>>>>>>>> <mailto:Vol-users@volatilityfoundation.org > >> <mailto:Vol-users@volatilityfoundation.org> > >>>>>>>> <mailto:Vol-users@volatilityfoundation.org > >> <mailto:Vol-users@volatilityfoundation.org>> > >>>>>>>>>>> <mailto:Vol-users@volatilityfoundation.org > >> <mailto:Vol-users@volatilityfoundation.org> > >>>>>>>> <mailto:Vol-users@volatilityfoundation.org > >> <mailto:Vol-users@volatilityfoundation.org>>> > >>>>>>>>>>>>> <mailto:Vol-users@volatilityfoundation.org > >> <mailto:Vol-users@volatilityfoundation.org> > >>>>>>>> <mailto:Vol-users@volatilityfoundation.org > >> <mailto:Vol-users@volatilityfoundation.org>> > >>>>>>>>>>> <mailto:Vol-users@volatilityfoundation.org > >> <mailto:Vol-users@volatilityfoundation.org> > >>>>>>>> <mailto:Vol-users@volatilityfoundation.org > >> <mailto:Vol-users@volatilityfoundation.org>>>>>> > >>>>>>>>>>>>>>> http://lists.volatilityfoundation.org/mailman/listinfo/vol-us > e > > > >>>>>>>>>>>>>>> > r > > > >>>>>>>>>>>>>>> > > s > >>>>>>>> > >>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >> _______________________________________________ > >>>>>>>>>>>>> Vol-users mailing list > >>>>>>>>>>>>> Vol-users(a)volatilityfoundation.org > >> <mailto:Vol-users@volatilityfoundation.org> > >>>>>>>> <mailto:Vol-users@volatilityfoundation.org > >> <mailto:Vol-users@volatilityfoundation.org>> > >>>>>>>>>>> <mailto:Vol-users@volatilityfoundation.org > >> <mailto:Vol-users@volatilityfoundation.org> > >>>>>>>> <mailto:Vol-users@volatilityfoundation.org > >> <mailto:Vol-users@volatilityfoundation.org>>> > >>>>>>>>>>>>> <mailto:Vol-users@volatilityfoundation.org > >> <mailto:Vol-users@volatilityfoundation.org> > >>>>>>>> <mailto:Vol-users@volatilityfoundation.org > >> <mailto:Vol-users@volatilityfoundation.org>> > >>>>>>>>>>> <mailto:Vol-users@volatilityfoundation.org > >> <mailto:Vol-users@volatilityfoundation.org> > >>>>>>>> <mailto:Vol-users@volatilityfoundation.org > >> <mailto:Vol-users@volatilityfoundation.org>>>> > >>>>>>>>>>>>> http://lists.volatilityfoundation.org/mailman/listinfo/vol-user > s > >>>>>>>> > >>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>>>> > > > >>>>>>>>>>>>> > >>>>>>>>>>>>> > > _______________________________________________ Vol-users > >>>>>>>>>> mailing list Vol-users(a)volatilityfoundation.org > >> <mailto:Vol-users@volatilityfoundation.org> > >>>>>>>> <mailto:Vol-users@volatilityfoundation.org > >> <mailto:Vol-users@volatilityfoundation.org>> > >>>>>>>>>> http://lists.volatilityfoundation.org/mailman/listinfo/vol-users > >>>>>>>> > >>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > > > >>>>>>>>>> > >>>>>>>>>> > > _______________________________________________ Vol-users > >>>>>>>>>> mailing list Vol-users(a)volatilityfoundation.org > >> <mailto:Vol-users@volatilityfoundation.org> > >>>>>>>> <mailto:Vol-users@volatilityfoundation.org > >> <mailto:Vol-users@volatilityfoundation.org>> > >>>>>>>>>> http://lists.volatilityfoundation.org/mailman/listinfo/vol-users > >>>>>>> > >>>>>> > >>>>>>>>>> > > > >>>>>>>>>> > >>>>>>>>>> > > _______________________________________________ > >>>>>>>> Vol-users mailing list Vol-users(a)volatilityfoundation.org > >> <mailto:Vol-users@volatilityfoundation.org> > >>>>>>>> <mailto:Vol-users@volatilityfoundation.org > >> <mailto:Vol-users@volatilityfoundation.org>> > >>>>>>>> http://lists.volatilityfoundation.org/mailman/listinfo/vol-users > >>>>>>>> > >>>>>>>> > > > >>>>>>>> > >>>>>>>> > > _______________________________________________ Vol-users > >>>>>>>> mailing list Vol-users(a)volatilityfoundation.org > >> <mailto:Vol-users@volatilityfoundation.org> > >>>>>>>> <mailto:Vol-users@volatilityfoundation.org > >> <mailto:Vol-users@volatilityfoundation.org>> > >>>>>>>> http://lists.volatilityfoundation.org/mailman/listinfo/vol-users > >>>>>>> > >>>>>>>> > > > >>>>>>>> > >>>>>>>> > > _______________________________________________ Vol-users mailing > >>>>>>> list Vol-users(a)volatilityfoundation.org > >> <mailto:Vol-users@volatilityfoundation.org> > >>>>>>> <mailto:Vol-users@volatilityfoundation.org > >> <mailto:Vol-users@volatilityfoundation.org>> > >>>>>>> http://lists.volatilityfoundation.org/mailman/listinfo/vol-users > >>>>>> > >>>>>> > >>>>>> > >>>>>>> > > > >>>>>>> > >>>>>>> > > _______________________________________________ Vol-users mailing > >>>>>> list Vol-users(a)volatilityfoundation.org > >> <mailto:Vol-users@volatilityfoundation.org> > >>>>>> http://lists.volatilityfoundation.org/mailman/listinfo/vol-users > >>> > >>>>>> > > > >>>>>> > _______________________________________________ Vol-users mailing > >>> list Vol-users(a)volatilityfoundation.org > >> <mailto:Vol-users@volatilityfoundation.org> > >>> http://lists.volatilityfoundation.org/mailman/listinfo/vol-users > > > > > > > > > > > >> _______________________________________________ Vol-users > >> mailing list Vol-users(a)volatilityfoundation.org > >> http://lists.volatilityfoundation.org/mailman/listinfo/vol-users > > > > _______________________________________________ Vol-users mailing > > list Vol-users(a)volatilityfoundation.org > > http://lists.volatilityfoundation.org/mailman/listinfo/vol-users > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.22 (Darwin) > Comment: GPGTools - https://gpgtools.org > > iF4EAREKAAYFAlVWETEACgkQXnt9v1O0LIuYZAD/UsDyJWzldfjbqoR8/me5CI6K > Iy5l/cuykusKHuf+U7MA/2eSg10cTPB+HnPj9QO4GsFNAvUwzFo9aCh9CGudH3SK > =2Ea+ > -----END PGP SIGNATURE----- >

9 years, 10 months

3
9
0 0

OS X Yosemite profiles now in the repo, testing requested

by Andrew Case

I just pushed the profiles that we created for OS X Yosemite into the 'profiles' project: https://github.com/volatilityfoundation/profiles/tree/master/Mac/10.10/x64 They should cover every version of 10.10.x officially released by Apple. If there are any missing versions then please let me know. We are requesting testing across the different versions since the profiles are so new. If you find any issues then please report them at: https://github.com/volatilityfoundation/volatility/issues Thanks for any help! -- Thanks, Andrew (@attrc)

9 years, 11 months

1
0
0 0

Re: [Vol-users] Timeliner "-R" not parsing Registry in 2.4

by Jamie Levy

This is true. When we allowed an option to specify by types the short -R was removed. I think it was also due to a conflict in options. -- Jamie Levy (@gleeda) > On May 18, 2015, at 9:11 AM, Gregory Pendergast <greg.pendergast(a)gmail.com> wrote: > > "--type=Registry" works. -R appears to no longer be an option. > >> On May 18, 2015, at 11:30 AM, Jared Greenhill <jared703(a)gmail.com> wrote: >> >> Vol Team, >> >> II've been unable to parse the Registry of a Windows system with 2.4 like I could with 2.3 using the "-R" switch. Do you invoke Registry parsing the same with 2.4 and Timeliner? When I remove the "-R" flag timeliner runs as expected. Apologies if this has been discussed somewhere. I've tried with Vol.py (compiled from source) and the Windows binary flavor of 2.4. >> >> Here's the errors I am receiving: >> >> C:\Users\DFIR-PC\Desktop\Mem>vol.exe -f Bad.img timeliner --output=body > timeline.txt -R >> Volatility Foundation Volatility Framework 2.4 >> Usage: Volatility - A memory forensics analysis platform. >> >> vol.exe: error: no such option: -R >> >> C:\Users\DFIR-PC\Desktop\Mem>vol.exe -f Bad.img timeliner --output=body --output-file=timeline.txt -R >> Volatility Foundation Volatility Framework 2.4 >> Usage: Volatility - A memory forensics analysis platform. >> >> vol.exe: error: no such option: -R >> >> C:\Users\DFIR-PC\Desktop\Mem>c:\volatility-master\vol.py -f Bad.img timeliner --output=body --output-file=timeline.txt -R >> Volatility Foundation Volatility Framework 2.4 >> >> Usage: Volatility - A memory forensics analysis platform. >> >> vol.py: error: no such option: -R >> >> Thanks! >> Jared >> _______________________________________________ >> Vol-users mailing list >> Vol-users(a)volatilityfoundation.org >> http://lists.volatilityfoundation.org/mailman/listinfo/vol-users > _______________________________________________ > Vol-users mailing list > Vol-users(a)volatilityfoundation.org > http://lists.volatilityfoundation.org/mailman/listinfo/vol-users

9 years, 11 months

2
1
0 0

Timeliner "-R" not parsing Registry in 2.4

by Jared Greenhill

Vol Team, II've been unable to parse the Registry of a Windows system with 2.4 like I could with 2.3 using the "-R" switch. Do you invoke Registry parsing the same with 2.4 and Timeliner? When I remove the "-R" flag timeliner runs as expected. Apologies if this has been discussed somewhere. I've tried with Vol.py (compiled from source) and the Windows binary flavor of 2.4. Here's the errors I am receiving: C:\Users\DFIR-PC\Desktop\Mem>vol.exe -f Bad.img timeliner --output=body > timeline.txt -R Volatility Foundation Volatility Framework 2.4 Usage: Volatility - A memory forensics analysis platform. vol.exe: error: no such option: -R C:\Users\DFIR-PC\Desktop\Mem>vol.exe -f Bad.img timeliner --output=body --output-file=timeline.txt -R Volatility Foundation Volatility Framework 2.4 Usage: Volatility - A memory forensics analysis platform. vol.exe: error: no such option: -R C:\Users\DFIR-PC\Desktop\Mem>c:\volatility-master\vol.py -f Bad.img timeliner --output=body --output-file=timeline.txt -R Volatility Foundation Volatility Framework 2.4 Usage: Volatility - A memory forensics analysis platform. vol.py: error: no such option: -R Thanks! Jared

9 years, 11 months

3
2
0 0

RE: [Vol-users] Output of strings not found in memdump output - QEMU/QEVM sample

by Torres, Geoff (Cyber Security)

Hi, Sorry for the 'me too' response, but I'm having this exact same problem. However, the main difference is that I'm using a 'QEMU' memory image (Hex dump sig is QEVM in the first 4 bytes) from a cloud instance. I've converted these in the past using the 'lqs2mem' tool written by Juerg Haefliger and Andrew Tappert and it's worked perfectly for the 'netscan' and 'ps' type plugins. However, I haven't needed to dump processes before and look for specific strings. I can locate the strings in the converted image, but it's not translating to the processes that are identified by the 'strings' plugin. Here's the steps I've been taking - ## Memory dump info > ll memory_dump -rw------- 1 geoff citsirt 7579914273 Apr 27 13:36 memory_dump > file memory_dump memory_dump: QEMU suspend to disk image > xxd memory_dump | head -n1 0000000: 5145 564d 0000 0003 0100 0000 0105 626c QEVM..........bl ## Convert the dump > lqs2mem -w pc.ram memory_dump memory_dump.ram section = pc.ram size = 8192 [MB] 8589934592 [bytes] section = pc.bios size = 128 [KB] 131072 [bytes] section = pc.rom size = 128 [KB] 131072 [bytes] section = vga.vram size = 16 [MB] 16777216 [bytes] section = 0000:00:02.0/cirrus_vga.rom size = 64 [KB] 65536 [bytes] Wrote 8589934592 bytes from section 'pc.ram' to file memory_dump.ram ## Create the strings file > strings -a -t d memory_dump.ram > memory_dump.ram.strings > strings -a -t d -el memory_dump.ram >> memory_dump.ram.strings ## Create the volatility strings file > python /data/download/apps/forensic_tools/volatility/vol.py -f memory_dump.ram --profile=Win2008SP2x64 strings -s --output-file=memory_dump.ram.vol.strings > ll memory_dump.ram.strings memory_dump.ram.vol.strings -rw-rw-r-- 1 geoff citsirt 2914258187 May 7 08:58 memory_dump.ram.strings -rw-rw-r-- 1 geoff citsirt 4292775089 May 7 12:17 memory_dump.ram.vol.strings ## '<Search_String>' is found in both string files as expected > fgrep <Search_String> memory_dump.ram.strings memory_dump.ram.vol.strings memory_dump.ram.strings:183190042 <Search_String> memory_dump.ram.vol.strings:183190042 [3156:0189321a] <Search_String> ## Dump process 3156 as identified by volatility > python /data/download/apps/forensic_tools/volatility/vol.py -f memory_dump.ram --profile=Win2008SP2x64 procdump -p 3156 -D processes -m Volatility Foundation Volatility Framework 2.4 Process(V) ImageBase Name Result ------------------ ------------------ -------------------- ------ 0xfffffa800a4e6370 0x0000000000400000 iwproxy.exe OK: executable.3156.exe >ll processes/executable.3156.exe -rw-rw-r-- 1 geoff citsirt 3248128 May 7 12:35 processes/executable.3156.exe ## '<Search_String>' not found in the dumped executable > strings -a processes/executable.3156.exe | fgrep <Search_String> > strings -a -el processes/executable.3156.exe | fgrep <Search_String> I've tried many different variations of the above steps and all have the same results. According to what I've read in this thread is that the issue is to make sure the original dump is properly converted. How can I do that? 'lqs2mem' has limited options. Any ideas on what I can do differently to get this to work? Thanks, Geoff Don't be afraid to tell me I'm doing something stupid... :-) -----Original Message----- From: vol-users-bounces(a)volatilesystems.com [mailto:vol-users-bounces@volatilesystems.com] On Behalf Of Michael Ligh Sent: Tuesday, March 24, 2015 6:49 AM To: Bridgey theGeek Cc: vol-users(a)volatilesystems.com Subject: Re: [Vol-users] Output of strings not found in memdump output -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Perfect! Glad to hear all is good in the world ;-) MHL On 3/24/15 5:05 AM, Bridgey theGeek wrote: > Awesome, thanks Michael. > > I generated a raw dump as follows, with the vmsn and vmem files in the > same folder: $ python vol.py -f winxp.vmem > --profile=WinXPSP2x86 imagecopy -O winxp.raw > > Then ran strings again (having generated a new input text file because > of course the offsets will be different): $ python vol.py -f winxp.raw > --profile=WinXPSP2x86 strings -s pk.txt > > I was then able to find the banner at the offsets reported by strings. > And all was good in the world. > > Thank you very much for the support. > > Adam > > On 23 March 2015 at 19:39, Michael Ligh <michael.ligh(a)mnin.org > <mailto:michael.ligh@mnin.org>> wrote: > > Hey Adam, > > A few things: > > * Yes, vmss2core creates a windows crash dump * You can use volatility > on the original vmem/vmss by doing the following: > > * make sure both vmem and vmss files are in the same dir * make sure > they have the same base name (i.e. test.vmem and test.vmss) * run your > volatility plugins against the vmem > > In this case, it would also be required to generate a raw memory dump > before running strings. So you would use imagecopy on the vmem. > > LMK if that helps! Michael > > On 3/23/15 10:51 AM, Bridgey theGeek wrote: >> Hi Michael, > >> *sigh* When will I learn to check the origin of my samples?! > >> The guy who provided me with the sample tells me that he took a >> snapshot of a VMWare machine and then used vss2core to convert it. I >> BELIEVE that makes it into a Windows Memory Core Dump..? > >> I got hold of the original vmem and vmsn files. Trying to use >> imagecopy on the vmsn just replicated the input file. I think the >> header is not what Volatility would expect: $ xxd Windows\ XP\ Pro\ >> SP2\ $32-bit$-Snapshot49.vmsn |head 0000000: d2be d2be >> 0800 0000 6300 0000 4368 6563 ........c...Chec 0000010: 6b70 >> 6f69 6e74 0000 0000 0000 0000 0000 kpoint.......... 0000020: >> 0000 0000 0000 0000 0000 0000 0000 0000 ................ >> 0000030: 0000 0000 0000 0000 0000 0000 0000 0000 ................ >> 0000040: 0000 0000 0000 0000 0000 0000 fc1e 0000 ................ >> 0000050: 0000 0000 ab03 0000 0000 0000 4775 6573 ............Gues >> 0000060: 7456 6172 7300 0000 0000 0000 0000 0000 tVars........... >> 0000070: 0000 0000 0000 0000 0000 0000 0000 0000 ................ >> 0000080: 0000 0000 0000 0000 0000 0000 0000 0000 ................ >> 0000090: 0000 0000 0000 0000 0000 0000 a722 0000 .............".. > >> Does that mean I can't use this with Volatility? > >> Thank you, Adam > >> On 23 March 2015 at 14:57, Michael Ligh <michael.ligh(a)mnin.org >> <mailto:michael.ligh@mnin.org> <mailto:michael.ligh@mnin.org >> <mailto:michael.ligh@mnin.org>>> wrote: > >> Hey Adam, > >> We forgot to ask if the sample was a raw memory dump. For >> example: > >> $ xxd ~/Desktop/memory.dmp | less > >> 0000000: 5041 4745 4455 4d50 0f00 0000 280a 0000 PAGEDUMP....(... >> 0000010: 8001 6c07 00c0 e680 a031 5580 5892 5580 ..l......1U.X.U. >> 0000020: 4c01 0000 0100 0000 8000 0000 5444 4f00 L...........TDO. >> 0000030: 0000 0000 0000 0000 0000 0000 5041 4745 ............PAGE >> 0000040: 5041 4745 5041 4745 5041 4745 5041 4745 PAGEPAGEPAGEPAGE > >> If its something like a crash dump, hibernation, etc then the file >> format headers throw off the offsets. You can convert those special >> file types into a raw memory dump with the imagecopy plugin and then >> your strings translations should be accurate. > >> Cheers! MHL > >> On 3/23/15 8:54 AM, Bridgey theGeek wrote: >>> Hi Andrew, > >>> I was certain I was running the latest version, but just to be sure >>> I grabbed the latest version. Same result, same offsets. > >>> I can make the sample available, but more than happy to do whatever >>> debugging needs doing (if I can!) > >>> Adam > >>> On 23 March 2015 at 13:03, Andrew Case <atcuno(a)gmail.com >>> <mailto:atcuno@gmail.com> <mailto:atcuno@gmail.com >>> <mailto:atcuno@gmail.com>> > <mailto:atcuno@gmail.com <mailto:atcuno@gmail.com> >>> <mailto:atcuno@gmail.com <mailto:atcuno@gmail.com>>>> wrote: > >>> Are you using the latest git checkout of Volatility or the 2.4 >>> release? Can you try the latest checkout and re-run Volatility >>> strings (you can run it on just the offsets from PID 123 to make it >>> faster). > >>> If you are already on the latest checkout then we will need to debug >>> further. > > > > >>> Thanks, Andrew (@attrc) > >>> On 03/23/2015 04:38 AM, Bridgey theGeek wrote: >>>> Thanks Andrew: >>>> >>>> python vol.py --profile=WinXPSP2x86 -f memory.dmp volshell -p 123 >>>> Volatility Foundation Volatility Framework 2.4 Current context: >>>> myapp.exe @ 0x822042f8, pid=123, ppid=392 >>> DTB=0x76c0040 >>>> Welcome to volshell! Current memory image is: >>>> file:///home/memory.dmp To get help, type 'hh()' >>>>>>> db(0x75b6b4d8) >>>> 0x75b6b4d8 c3 7c 15 c7 85 00 ff ff ff 01 00 00 00 75 09 8d >>>> .|...........u.. 0x75b6b4e8 85 0c ff ff ff 50 ff 17 39 9d >>>> 00 ff ff ff 89 85 .....P..9....... 0x75b6b4f8 30 ff ff ff 74 >>>> 12 6a 0c 8d 85 c4 fe ff ff 50 6a 0...t.j.......Pj 0x75b6b508 >>>> 07 6a fe e8 ea 92 ff ff 83 bd 28 ff ff ff 0c 0f .j........(..... >>>> 0x75b6b518 84 8c 59 00 00 e9 18 ff ff ff 90 >>>> 90 47 00 6c 00 ..Y.........G.l. 0x75b6b528 6f 00 62 00 61 00 6c 00 >>>> 5c 00 54 00 65 00 72 00 o.b.a.l.\.T.e.r. 0x75b6b538 6d >>>> 00 53 00 72 00 76 00 52 00 65 00 61 00 64 00 m.S.r.v.R.e.a.d. >>>> 0x75b6b548 79 00 45 00 76 00 65 00 6e 00 74 00 00 00 90 90 >>>> y.E.v.e.n.t..... >>>> >>>> Nope, still no banner. But it is identical to what I find at >>> 0x1a34d8 in >>>> 123.dmp. (As you'd expect.) Double-checked that I was searching >>>> Unicode and ASCII - still no luck. >>>> >>>> Hmmm. >>>> >>>> Adam >>>> >>>> On 23 March 2015 at 04:02, Andrew Case <atcuno(a)gmail.com > <mailto:atcuno@gmail.com> >> <mailto:atcuno@gmail.com <mailto:atcuno@gmail.com>> >>> <mailto:atcuno@gmail.com <mailto:atcuno@gmail.com> > <mailto:atcuno@gmail.com <mailto:atcuno@gmail.com>>> >>>> <mailto:atcuno@gmail.com <mailto:atcuno@gmail.com> > <mailto:atcuno@gmail.com <mailto:atcuno@gmail.com>> >> <mailto:atcuno@gmail.com <mailto:atcuno@gmail.com> > <mailto:atcuno@gmail.com <mailto:atcuno@gmail.com>>>>> wrote: >>>> >>>> Can do you: >>>> >>>> vol.py ... volshell -p 123 >>>> >>>> Then in volshell do: >>>> >>>> db(0x75b6b4d8) >>>> >>>> And see if you get the banner printed at the beginning? >>>> >>>> Also, how are you searching 123.dmp? Did you search ascii & >>> unicode >>>> (most common error) >>>> >>>> Thanks, Andrew (@attrc) >>>> >>>> On 03/20/2015 03:59 PM, Bridgey theGeek wrote: >>>>> Hi all, >>>>> >>>>> I can't quite see what's wrong with my logic here, but I must be >>>> missing >>>>> something. Hoping someone can help me out. >>>>> >>>>> I'm looking for a private key in a memory sample (WinXPSP2x86). >>>>> Specifically, to find out which process/es is/are accessing it. >>>>> >>>>> I can find the key by searching the raw memory dump >>> (memory.dmp). >>>>> As you might expect it's between: -----BEGIN RSA PRIVATE >>>>> KEY----- -----END RSA PRIVATE KEY----- >>>>> >>>>> I generated an offset:string file by using strings. Then, using >>>>> the strings plugin I get this output: $ python vol.py -f >>>>> memory.dmp --profile=WinXPSP2x86 strings >>> -s pk.txt >>>>> Volatility Foundation Volatility Framework 2.4 188435934 [FREE >>>>> MEMORY:-1] -----BEGIN RSA PRIVATE KEY----- 188435968 [FREE >>>>> MEMORY:-1] -----END RSA PRIVATE KEY----- 317375704 >>>>> [kernel:d2ab24d8] -----BEGIN RSA PRIVATE KEY----- >>>>> 317376575 [kernel:d2ab283f] -----END RSA PRIVATE KEY----- >>>>> 417203416 [123:75b6b4d8] -----BEGIN RSA PRIVATE KEY----- >>>>> 417204287 [123:75b6b83f] -----END RSA PRIVATE KEY----- >>>>> 419888606 [FREE MEMORY:-1] -----BEGIN RSA PRIVATE KEY----- >>>>> 419888640 [FREE MEMORY:-1] -----END RSA PRIVATE KEY----- >>>>> >>>>> Lovely. So I now do a memdump of process 123: $ python vol.py -f >>>>> memory.dmp --profile=WinXPSP2x86 memdump >>> --pid=123 >>>>> --dump-dir=123 Volatility Foundation Volatility Framework >>>>> 2.4 >>>>> >>>> > > > ********************************************************************** > ** > > > > >>>> Writing myapp.exe [ 123] to 123.dmp >>>>> >>>>> However, if I search 123.dmp neither the BEGIN or END >>> strings are >>>> present. >>>>> >>>>> So I thought I'd try and find it via the virtual address give, >>>> 0x75b6b4d8: >>>>> $ python vol.py -f memory.dmp --profile=WinXPSP2x86 memmap >>> --pid=123 >>>>> Virtual Physical Size DumpFileOffset ---------- >>>>> ---------- ---------- -------------- --SNIP-- 0x75b6b000 >>>>> 0x18de0000 0x1000 0x1a3000 --SNIP-- >>>>> >>>>> The text is indeed at 0x18de04d8 in memory.dmp, but not at >>> 0x1a34d8 in >>>>> 123.dmp. Again, it's no where to be found in 123.dmp. >>>>> >>>>> Any suggestions..?? >>>>> >>>>> Many thanks, Adam >>>>> >>>>> >>>>> _______________________________________________ Vol-users mailing >>>>> list Vol-users(a)volatilesystems.com > <mailto:Vol-users@volatilesystems.com> >> <mailto:Vol-users@volatilesystems.com > <mailto:Vol-users@volatilesystems.com>> >>> <mailto:Vol-users@volatilesystems.com > <mailto:Vol-users@volatilesystems.com> >> <mailto:Vol-users@volatilesystems.com > <mailto:Vol-users@volatilesystems.com>>> >>> <mailto:Vol-users@volatilesystems.com > <mailto:Vol-users@volatilesystems.com> >> <mailto:Vol-users@volatilesystems.com > <mailto:Vol-users@volatilesystems.com>> >>> <mailto:Vol-users@volatilesystems.com > <mailto:Vol-users@volatilesystems.com> >>> <mailto:Vol-users@volatilesystems.com > <mailto:Vol-users@volatilesystems.com>>>> >>>>> http://lists.volatilesystems.com/mailman/listinfo/vol-users >>>>> >>>> >>>> > >>>>> > > > >>> _______________________________________________ Vol-users mailing >>> list Vol-users(a)volatilesystems.com > <mailto:Vol-users@volatilesystems.com> >>> <mailto:Vol-users@volatilesystems.com > <mailto:Vol-users@volatilesystems.com>> >>> http://lists.volatilesystems.com/mailman/listinfo/vol-users > > > > > -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org iF4EAREKAAYFAlURazkACgkQXnt9v1O0LItfjAD/W7UeZMNiWVRMqeeJftNRaxG2 dpi/c755Qxc6X7PUKU8A/iREkToI9Ad0/GejtG32OpZMLjk0gjhj5XoMxAWuY69D =JNEv -----END PGP SIGNATURE----- _______________________________________________ Vol-users mailing list Vol-users(a)volatilesystems.com http://lists.volatilesystems.com/mailman/listinfo/vol-users

9 years, 11 months

5
12
0 0

mac_psxview command problem on Yosemite

by Justin q. Case

Hey everyone, I recently built a 10.10.3 Yosemite profile for 10.10.3 image I have. When I try to run mac_psxview on the image, I’m getting a bunch of errors as shown below. Any ideas? bash-3.2# python /usr/local/bin/vol.py -f /users/msquire/desktop/share/macloginELF.dump --profile MacYosemite10_10_3_64bitx64 mac_psxview Volatility Foundation Volatility Framework 2.4 Traceback (most recent call last): File "/usr/local/bin/vol.py", line 5, in <module> pkg_resources.run_script('volatility==2.4', 'vol.py') File "/Library/Python/2.7/site-packages/pkg_resources/__init__.py", line 729, in run_script self.require(requires)[0].run_script(script_name, ns) File "/Library/Python/2.7/site-packages/pkg_resources/__init__.py", line 1642, in run_script exec(code, namespace, namespace) File "/Library/Python/2.7/site-packages/volatility-2.4-py2.7.egg/EGG-INFO/scripts/vol.py", line 192, in <module> main() File "/Library/Python/2.7/site-packages/volatility-2.4-py2.7.egg/EGG-INFO/scripts/vol.py", line 183, in main command.execute() File "/Library/Python/2.7/site-packages/volatility-2.4-py2.7.egg/volatility/plugins/mac/common.py", line 46, in execute commands.Command.execute(self, *args, **kwargs) File "/Library/Python/2.7/site-packages/volatility-2.4-py2.7.egg/volatility/commands.py", line 99, in execute if not self.is_valid_profile(profs[self._config.PROFILE]()): File "/Library/Python/2.7/site-packages/volatility-2.4-py2.7.egg/volatility/plugins/overlays/mac/mac.py", line 1098, in __init__ obj.Profile.__init__(self, *args, **kwargs) File "/Library/Python/2.7/site-packages/volatility-2.4-py2.7.egg/volatility/obj.py", line 858, in __init__ self.reset() File "/Library/Python/2.7/site-packages/volatility-2.4-py2.7.egg/volatility/plugins/overlays/mac/mac.py", line 1117, in reset self.load_modifications() File "/Library/Python/2.7/site-packages/volatility-2.4-py2.7.egg/volatility/obj.py", line 940, in load_modifications mod.modification(self) File "/Library/Python/2.7/site-packages/volatility-2.4-py2.7.egg/volatility/plugins/overlays/mac/mac.py", line 1367, in modification profile.merge_overlay(mac_overlay) File "/Library/Python/2.7/site-packages/volatility-2.4-py2.7.egg/volatility/obj.py", line 1031, in merge_overlay self.vtypes[k] = self._apply_overlay(self.vtypes[k], v) File "/Library/Python/2.7/site-packages/volatility-2.4-py2.7.egg/volatility/obj.py", line 1081, in _apply_overlay result.append(self._apply_overlay(type_member[i], overlay[i])) File "/Library/Python/2.7/site-packages/volatility-2.4-py2.7.egg/volatility/obj.py", line 1068, in _apply_overlay result[k] = self._apply_overlay(type_member[k], v) File "/Library/Python/2.7/site-packages/volatility-2.4-py2.7.egg/volatility/obj.py", line 1081, in _apply_overlay result.append(self._apply_overlay(type_member[i], overlay[i])) File "/Library/Python/2.7/site-packages/volatility-2.4-py2.7.egg/volatility/obj.py", line 1072, in _apply_overlay if len(overlay) != len(type_member): TypeError: object of type 'int' has no len() Using OSXPmem to acquire the images, tried with RAW, ELF (as above), and MACHO types. This has been killing me, any help would be greatly appreciated! Thank you!

9 years, 11 months

1
0
0 0

Calling memory analysis in NY, Reston, and Amsterdam

by Michael Ligh

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi folks, If you're in the NY area next week, hook up with us and some other @volatility users for a few drinks on Wednesday night (13th). Request details off list. Also just a heads up for the next Malware and Memory Forensics training classes...we'll be in Amsterdam Aug 31 - Sept 4 and then back in Reston, VA October 5 - 9. We hope to see some of you there! MHL -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org iF4EAREKAAYFAlVOL/8ACgkQXnt9v1O0LIsTOAD/RAAqA2H0UHLht6daYd1LRVSg 5Wie9xEysWHJx5o42MgBAIrHRvTvUiGXWfBW9IdrDE522taJjmoxftRc6P1OpN8a =SOEJ -----END PGP SIGNATURE-----

9 years, 11 months

1
0
0 0

BSidesNOLA is one month away!

by Andrew Case

Hello All, We are writing as BSidesNOLA is roughly one month away, and we would like to see everyone there. We have put together our best speaker lineup yet, and we want to get as big a crowd as possible for learning, networking, and a day of fun. Registration is only $10, but you must pre-register through Eventbrite: https://www.eventbrite.com/e/bsides-nola-2015-tickets-9621601469. Full information on the conference, including the keynote and 18 technical presentations, can be found here: http://www.securitybsides.com/w/page/91550808/BSidesNOLA%202015 We hope to see everyone there, and please don’t be shy of spreading the word! Thanks, The BSidesNOLA Team

9 years, 11 months

1
0
0 0

OSDFCon CFP

by Brian Carrier

Open Source Digital Forensics Conference - Call For Presentations and Workshops The 6th Annual Open Source Digital Forensics Conference (OSDFCon) will be held on October 28, 2015 in Herndon, VA. All users and developers are invited to submit a presentation or workshop topic by June 1, 2015. This is a unique opportunity to present your work and experiences to over 400 people. The conference will be attended by both digital forensic investigators and developers. This event is a great opportunity to make investigators aware of your tools, get feedback from users, meet fellow developers and users, and help direct the future of open source digital forensics software. To receive updates about the conference, sign up for e-mail updates (http://www.osdfcon.org) or watch #osdfcon on twitter. TOPICS We are looking for 35-minute talks on a variety of topics about using open source tools, including: * New tools and analysis techniques * New features to mature tools * Open, plug-in analysis framework designs and experiences * Automated analysis * Hard drive analysis and triage * Memory and network forensics * Mobile device forensics * Analyzing application-level artifacts * Cyber incident response * User experiences * Case studies We also have openings for half-day workshops on the day before the conference (October 27, 2015). The workshops should teach people how to use or develop open source tools by providing hands-on guidance. SUBMISSION INSTRUCTIONS Topics can be submitted using an online form: http://www.osdfcon.org Submissions are due June 1, 2015. Our plan this year is to do an initial pass of the submissions and then use crowd sourcing to choose the final set of topics. E-mail submissions2015 [at] osdfcon [dot] org with any questions.

10 years

1
0
0 0

Few training class updates and "night out" notice

by Michael Ligh

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi folks, There's one week left to register for the upcoming Reston class (April 13-17). If you're from Reston or will be there working during the time, drop us a note and we'll include you in the "night out" announcement so you can come have some drinks with other Volatility users. Same applies to the New York class during the week of May 11-15, UK June 1-5 and Amsterdam August 31-September 4. We hope to see some of guys there! MHL -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org iF4EAREKAAYFAlUb84YACgkQXnt9v1O0LIv08gEAlz1YdHOV2NfMQzOzDegIguFI EkVTkFR6kFSDo2z1oRgBAJWc+SJyUJ+wP93ULd8pFw9d97QqCr8y+aQnEsKlVn3A =W35+ -----END PGP SIGNATURE-----

10 years

1
0
0 0

Re: [Vol-users] Output of strings not found in memdump output

by Michael Ligh

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Perfect! Glad to hear all is good in the world ;-) MHL On 3/24/15 5:05 AM, Bridgey theGeek wrote: > Awesome, thanks Michael. > > I generated a raw dump as follows, with the vmsn and vmem files in > the same folder: $ python vol.py -f winxp.vmem > --profile=WinXPSP2x86 imagecopy -O winxp.raw > > Then ran strings again (having generated a new input text file > because of course the offsets will be different): $ python vol.py > -f winxp.raw --profile=WinXPSP2x86 strings -s pk.txt > > I was then able to find the banner at the offsets reported by > strings. And all was good in the world. > > Thank you very much for the support. > > Adam > > On 23 March 2015 at 19:39, Michael Ligh <michael.ligh(a)mnin.org > <mailto:michael.ligh@mnin.org>> wrote: > > Hey Adam, > > A few things: > > * Yes, vmss2core creates a windows crash dump * You can use > volatility on the original vmem/vmss by doing the following: > > * make sure both vmem and vmss files are in the same dir * make > sure they have the same base name (i.e. test.vmem and test.vmss) * > run your volatility plugins against the vmem > > In this case, it would also be required to generate a raw memory > dump before running strings. So you would use imagecopy on the > vmem. > > LMK if that helps! Michael > > On 3/23/15 10:51 AM, Bridgey theGeek wrote: >> Hi Michael, > >> *sigh* When will I learn to check the origin of my samples?! > >> The guy who provided me with the sample tells me that he took a >> snapshot of a VMWare machine and then used vss2core to convert >> it. I BELIEVE that makes it into a Windows Memory Core Dump..? > >> I got hold of the original vmem and vmsn files. Trying to use >> imagecopy on the vmsn just replicated the input file. I think >> the header is not what Volatility would expect: $ xxd Windows\ >> XP\ Pro\ SP2\ $32-bit$-Snapshot49.vmsn |head 0000000: d2be d2be >> 0800 0000 6300 0000 4368 6563 ........c...Chec 0000010: 6b70 >> 6f69 6e74 0000 0000 0000 0000 0000 kpoint.......... 0000020: >> 0000 0000 0000 0000 0000 0000 0000 0000 ................ >> 0000030: 0000 0000 0000 0000 0000 0000 0000 0000 >> ................ 0000040: 0000 0000 0000 0000 0000 0000 fc1e 0000 >> ................ 0000050: 0000 0000 ab03 0000 0000 0000 4775 6573 >> ............Gues 0000060: 7456 6172 7300 0000 0000 0000 0000 0000 >> tVars........... 0000070: 0000 0000 0000 0000 0000 0000 0000 0000 >> ................ 0000080: 0000 0000 0000 0000 0000 0000 0000 0000 >> ................ 0000090: 0000 0000 0000 0000 0000 0000 a722 0000 >> .............".. > >> Does that mean I can't use this with Volatility? > >> Thank you, Adam > >> On 23 March 2015 at 14:57, Michael Ligh <michael.ligh(a)mnin.org >> <mailto:michael.ligh@mnin.org> <mailto:michael.ligh@mnin.org >> <mailto:michael.ligh@mnin.org>>> wrote: > >> Hey Adam, > >> We forgot to ask if the sample was a raw memory dump. For >> example: > >> $ xxd ~/Desktop/memory.dmp | less > >> 0000000: 5041 4745 4455 4d50 0f00 0000 280a 0000 >> PAGEDUMP....(... 0000010: 8001 6c07 00c0 e680 a031 5580 5892 5580 >> ..l......1U.X.U. 0000020: 4c01 0000 0100 0000 8000 0000 5444 4f00 >> L...........TDO. 0000030: 0000 0000 0000 0000 0000 0000 5041 4745 >> ............PAGE 0000040: 5041 4745 5041 4745 5041 4745 5041 4745 >> PAGEPAGEPAGEPAGE > >> If its something like a crash dump, hibernation, etc then the >> file format headers throw off the offsets. You can convert those >> special file types into a raw memory dump with the imagecopy >> plugin and then your strings translations should be accurate. > >> Cheers! MHL > >> On 3/23/15 8:54 AM, Bridgey theGeek wrote: >>> Hi Andrew, > >>> I was certain I was running the latest version, but just to be >>> sure I grabbed the latest version. Same result, same offsets. > >>> I can make the sample available, but more than happy to do >>> whatever debugging needs doing (if I can!) > >>> Adam > >>> On 23 March 2015 at 13:03, Andrew Case <atcuno(a)gmail.com >>> <mailto:atcuno@gmail.com> <mailto:atcuno@gmail.com >>> <mailto:atcuno@gmail.com>> > <mailto:atcuno@gmail.com <mailto:atcuno@gmail.com> >>> <mailto:atcuno@gmail.com <mailto:atcuno@gmail.com>>>> wrote: > >>> Are you using the latest git checkout of Volatility or the 2.4 >>> release? Can you try the latest checkout and re-run Volatility >>> strings (you can run it on just the offsets from PID 123 to >>> make it faster). > >>> If you are already on the latest checkout then we will need to >>> debug further. > > > > >>> Thanks, Andrew (@attrc) > >>> On 03/23/2015 04:38 AM, Bridgey theGeek wrote: >>>> Thanks Andrew: >>>> >>>> python vol.py --profile=WinXPSP2x86 -f memory.dmp volshell >>>> -p 123 Volatility Foundation Volatility Framework 2.4 >>>> Current context: myapp.exe @ 0x822042f8, pid=123, ppid=392 >>> DTB=0x76c0040 >>>> Welcome to volshell! Current memory image is: >>>> file:///home/memory.dmp To get help, type 'hh()' >>>>>>> db(0x75b6b4d8) >>>> 0x75b6b4d8 c3 7c 15 c7 85 00 ff ff ff 01 00 00 00 75 09 8d >>>> .|...........u.. 0x75b6b4e8 85 0c ff ff ff 50 ff 17 39 9d >>>> 00 ff ff ff 89 85 .....P..9....... 0x75b6b4f8 30 ff ff ff 74 >>>> 12 6a 0c 8d 85 c4 fe ff ff 50 6a 0...t.j.......Pj 0x75b6b508 >>>> 07 6a fe e8 ea 92 ff ff 83 bd 28 ff ff ff 0c 0f >>>> .j........(..... 0x75b6b518 84 8c 59 00 00 e9 18 ff ff ff 90 >>>> 90 47 00 6c 00 ..Y.........G.l. 0x75b6b528 6f 00 62 00 61 00 >>>> 6c 00 5c 00 54 00 65 00 72 00 o.b.a.l.\.T.e.r. 0x75b6b538 6d >>>> 00 53 00 72 00 76 00 52 00 65 00 61 00 64 00 m.S.r.v.R.e.a.d. >>>> 0x75b6b548 79 00 45 00 76 00 65 00 6e 00 74 00 00 00 90 90 >>>> y.E.v.e.n.t..... >>>> >>>> Nope, still no banner. But it is identical to what I find at >>> 0x1a34d8 in >>>> 123.dmp. (As you'd expect.) Double-checked that I was >>>> searching Unicode and ASCII - still no luck. >>>> >>>> Hmmm. >>>> >>>> Adam >>>> >>>> On 23 March 2015 at 04:02, Andrew Case <atcuno(a)gmail.com > <mailto:atcuno@gmail.com> >> <mailto:atcuno@gmail.com <mailto:atcuno@gmail.com>> >>> <mailto:atcuno@gmail.com <mailto:atcuno@gmail.com> > <mailto:atcuno@gmail.com <mailto:atcuno@gmail.com>>> >>>> <mailto:atcuno@gmail.com <mailto:atcuno@gmail.com> > <mailto:atcuno@gmail.com <mailto:atcuno@gmail.com>> >> <mailto:atcuno@gmail.com <mailto:atcuno@gmail.com> > <mailto:atcuno@gmail.com <mailto:atcuno@gmail.com>>>>> wrote: >>>> >>>> Can do you: >>>> >>>> vol.py ... volshell -p 123 >>>> >>>> Then in volshell do: >>>> >>>> db(0x75b6b4d8) >>>> >>>> And see if you get the banner printed at the beginning? >>>> >>>> Also, how are you searching 123.dmp? Did you search ascii & >>> unicode >>>> (most common error) >>>> >>>> Thanks, Andrew (@attrc) >>>> >>>> On 03/20/2015 03:59 PM, Bridgey theGeek wrote: >>>>> Hi all, >>>>> >>>>> I can't quite see what's wrong with my logic here, but I >>>>> must be >>>> missing >>>>> something. Hoping someone can help me out. >>>>> >>>>> I'm looking for a private key in a memory sample >>>>> (WinXPSP2x86). Specifically, to find out which process/es >>>>> is/are accessing it. >>>>> >>>>> I can find the key by searching the raw memory dump >>> (memory.dmp). >>>>> As you might expect it's between: -----BEGIN RSA PRIVATE >>>>> KEY----- -----END RSA PRIVATE KEY----- >>>>> >>>>> I generated an offset:string file by using strings. Then, >>>>> using the strings plugin I get this output: $ python >>>>> vol.py -f memory.dmp --profile=WinXPSP2x86 strings >>> -s pk.txt >>>>> Volatility Foundation Volatility Framework 2.4 188435934 >>>>> [FREE MEMORY:-1] -----BEGIN RSA PRIVATE KEY----- 188435968 >>>>> [FREE MEMORY:-1] -----END RSA PRIVATE KEY----- 317375704 >>>>> [kernel:d2ab24d8] -----BEGIN RSA PRIVATE KEY----- >>>>> 317376575 [kernel:d2ab283f] -----END RSA PRIVATE KEY----- >>>>> 417203416 [123:75b6b4d8] -----BEGIN RSA PRIVATE KEY----- >>>>> 417204287 [123:75b6b83f] -----END RSA PRIVATE KEY----- >>>>> 419888606 [FREE MEMORY:-1] -----BEGIN RSA PRIVATE KEY----- >>>>> 419888640 [FREE MEMORY:-1] -----END RSA PRIVATE KEY----- >>>>> >>>>> Lovely. So I now do a memdump of process 123: $ python >>>>> vol.py -f memory.dmp --profile=WinXPSP2x86 memdump >>> --pid=123 >>>>> --dump-dir=123 Volatility Foundation Volatility Framework >>>>> 2.4 >>>>> >>>> > > > ************************************************************************ > > > > >>>> Writing myapp.exe [ 123] to 123.dmp >>>>> >>>>> However, if I search 123.dmp neither the BEGIN or END >>> strings are >>>> present. >>>>> >>>>> So I thought I'd try and find it via the virtual address >>>>> give, >>>> 0x75b6b4d8: >>>>> $ python vol.py -f memory.dmp --profile=WinXPSP2x86 memmap >>> --pid=123 >>>>> Virtual Physical Size DumpFileOffset ---------- >>>>> ---------- ---------- -------------- --SNIP-- 0x75b6b000 >>>>> 0x18de0000 0x1000 0x1a3000 --SNIP-- >>>>> >>>>> The text is indeed at 0x18de04d8 in memory.dmp, but not at >>> 0x1a34d8 in >>>>> 123.dmp. Again, it's no where to be found in 123.dmp. >>>>> >>>>> Any suggestions..?? >>>>> >>>>> Many thanks, Adam >>>>> >>>>> >>>>> _______________________________________________ Vol-users >>>>> mailing list Vol-users(a)volatilityfoundation.org > <mailto:Vol-users@volatilityfoundation.org> >> <mailto:Vol-users@volatilityfoundation.org > <mailto:Vol-users@volatilityfoundation.org>> >>> <mailto:Vol-users@volatilityfoundation.org > <mailto:Vol-users@volatilityfoundation.org> >> <mailto:Vol-users@volatilityfoundation.org > <mailto:Vol-users@volatilityfoundation.org>>> >>> <mailto:Vol-users@volatilityfoundation.org > <mailto:Vol-users@volatilityfoundation.org> >> <mailto:Vol-users@volatilityfoundation.org > <mailto:Vol-users@volatilityfoundation.org>> >>> <mailto:Vol-users@volatilityfoundation.org > <mailto:Vol-users@volatilityfoundation.org> >>> <mailto:Vol-users@volatilityfoundation.org > <mailto:Vol-users@volatilityfoundation.org>>>> >>>>> http://lists.volatilityfoundation.org/mailman/listinfo/vol-users >>>>> >>>> >>>> > >>>>> > > > >>> _______________________________________________ Vol-users >>> mailing list Vol-users(a)volatilityfoundation.org > <mailto:Vol-users@volatilityfoundation.org> >>> <mailto:Vol-users@volatilityfoundation.org > <mailto:Vol-users@volatilityfoundation.org>> >>> http://lists.volatilityfoundation.org/mailman/listinfo/vol-users > > > > > -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org iF4EAREKAAYFAlURazkACgkQXnt9v1O0LItfjAD/W7UeZMNiWVRMqeeJftNRaxG2 dpi/c755Qxc6X7PUKU8A/iREkToI9Ad0/GejtG32OpZMLjk0gjhj5XoMxAWuY69D =JNEv -----END PGP SIGNATURE-----

10 years, 1 month

1
0
0 0

Linux profile w/LiME not working

by Brian Keefer

I built LiME from the tarball on the project site (not latest svn) and was able to dump memory successfully (type=lime). After many trials and tribulations I was able to get the Volatility profile built for CentOS 5.3x64 (had to remove pmem from the Makefile). I put the profile in the correct directory, and vol.py --info lists it as expected, however when I try to use the profile with the memory image I get an error. chort@hydra:~/code/profiles-volatility/CentOS_5.3_x64$ vol.py --profile=LinuxCentOS_5_3x64 -f /fun/ir/geriatrix.lime linux_lsmod Volatile Systems Volatility Framework 2.3_alpha WARNING : volatility.obj : Overlay structure cpuinfo_x86 not present in vtypes No suitable address space mapping found Tried to open image as: MachOAddressSpace: mac: need base LimeAddressSpace: lime: need base WindowsHiberFileSpace32: No base Address Space WindowsCrashDumpSpace64: No base Address Space HPAKAddressSpace: No base Address Space VirtualBoxCoreDumpElf64: No base Address Space VMWareSnapshotFile: No base Address Space WindowsCrashDumpSpace32: No base Address Space JKIA32PagedMemoryPae: No base Address Space AMD64PagedMemory: No base Address Space JKIA32PagedMemory: No base Address Space IA32PagedMemoryPae: Module disabled IA32PagedMemory: Module disabled MachOAddressSpace: MachO Header signature invalid MachOAddressSpace: MachO Header signature invalid LimeAddressSpace: Invalid Lime header signature WindowsHiberFileSpace32: PO_MEMORY_IMAGE is not available in profile WindowsCrashDumpSpace64: Header signature invalid HPAKAddressSpace: Invalid magic found VirtualBoxCoreDumpElf64: ELF64 Header signature invalid VMWareSnapshotFile: Invalid VMware signature: 0xf000ff53 WindowsCrashDumpSpace32: Header signature invalid JKIA32PagedMemoryPae: Incompatible profile LinuxCentOS_5_3x64 selected AMD64PagedMemory: Failed valid Address Space check JKIA32PagedMemory: Incompatible profile LinuxCentOS_5_3x64 selected IA32PagedMemoryPae: Module disabled IA32PagedMemory: Module disabled FileAddressSpace: Must be first Address Space ArmAddressSpace: Incompatible profile LinuxCentOS_5_3x64 selected On a hunch I checked the directory I built the profile in (copied headers & source from the target system): chort@hydra:~/code/profiles-volatility/CentOS_5.3_x64$ grep cpuinfo * System.map-2.6.18-128.el5:ffffffff8006f328 t show_cpuinfo System.map-2.6.18-128.el5:ffffffff80103251 t cpuinfo_open System.map-2.6.18-128.el5:ffffffff8020eadb t show_cpuinfo_max_freq System.map-2.6.18-128.el5:ffffffff8020eafa t show_cpuinfo_min_freq System.map-2.6.18-128.el5:ffffffff8020f759 t show_cpuinfo_cur_freq System.map-2.6.18-128.el5:ffffffff802f0bc0 D cpuinfo_op System.map-2.6.18-128.el5:ffffffff80308420 d proc_cpuinfo_operations System.map-2.6.18-128.el5:ffffffff803319a0 d cpuinfo_cur_freq System.map-2.6.18-128.el5:ffffffff80331b20 d cpuinfo_min_freq System.map-2.6.18-128.el5:ffffffff80331b60 d cpuinfo_max_freq Platform running Volatility (2.3_alpha, latest from svn): Linux hydra 3.2.0-35-generic #55-Ubuntu SMP Wed Dec 5 17:42:16 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux Source of memory image: Linux geriatrix.smtps.net 2.6.18-128.el5 #1 SMP Wed Jan 21 10:41:14 EST 2009 x86_64 x86_64 x86_64 GNU/Linux What am I missing? -- chort

10 years, 1 month

3
6
0 0

Profile build on CentOS 5.8 fails

by Brian Keefer

I noticed there’s a special ifdef for 2.6.18 kernels, which this is. The alleged redefinitions also appear to be inside of a struct, in which case is that really an error? This compiler (gcc-4.1.2) evidently thinks it is. make -C //lib/modules/2.6.18-308.4.1.el5.P1/build CONFIG_DEBUG_INFO=y M="/root/scratch/vol-linux" modules make[1]: Entering directory `/usr/src/kernels/2.6.18-308.4.1.el5.P1-x86_64' CC [M] /root/scratch/vol-linux/module.o /root/scratch/vol-linux/module.c:204: error: redefinition of ‘struct module_sect_attr’ /root/scratch/vol-linux/module.c:211: error: redefinition of ‘struct module_sect_attrs’ /root/scratch/vol-linux/module.c:353:5: warning: "STATS" is not defined /root/scratch/vol-linux/module.c:369:5: warning: "DEBUG" is not defined make[2]: *** [/root/scratch/vol-linux/module.o] Error 1 make[1]: *** [_module_/root/scratch/vol-linux] Error 2 make[1]: Leaving directory `/usr/src/kernels/2.6.18-308.4.1.el5.P1-x86_64' make: *** [dwarf] Error 2 -- bk

10 years, 1 month

2
2
0 0

Output of strings not found in memdump output

by Bridgey theGeek

Hi all, I can't quite see what's wrong with my logic here, but I must be missing something. Hoping someone can help me out. I'm looking for a private key in a memory sample (WinXPSP2x86). Specifically, to find out which process/es is/are accessing it. I can find the key by searching the raw memory dump (memory.dmp). As you might expect it's between: -----BEGIN RSA PRIVATE KEY----- -----END RSA PRIVATE KEY----- I generated an offset:string file by using strings. Then, using the strings plugin I get this output: $ python vol.py -f memory.dmp --profile=WinXPSP2x86 strings -s pk.txt Volatility Foundation Volatility Framework 2.4 188435934 [FREE MEMORY:-1] -----BEGIN RSA PRIVATE KEY----- 188435968 [FREE MEMORY:-1] -----END RSA PRIVATE KEY----- 317375704 [kernel:d2ab24d8] -----BEGIN RSA PRIVATE KEY----- 317376575 [kernel:d2ab283f] -----END RSA PRIVATE KEY----- 417203416 [123:75b6b4d8] -----BEGIN RSA PRIVATE KEY----- 417204287 [123:75b6b83f] -----END RSA PRIVATE KEY----- 419888606 [FREE MEMORY:-1] -----BEGIN RSA PRIVATE KEY----- 419888640 [FREE MEMORY:-1] -----END RSA PRIVATE KEY----- Lovely. So I now do a memdump of process 123: $ python vol.py -f memory.dmp --profile=WinXPSP2x86 memdump --pid=123 --dump-dir=123 Volatility Foundation Volatility Framework 2.4 ************************************************************************ Writing myapp.exe [ 123] to 123.dmp However, if I search 123.dmp neither the BEGIN or END strings are present. So I thought I'd try and find it via the virtual address give, 0x75b6b4d8: $ python vol.py -f memory.dmp --profile=WinXPSP2x86 memmap --pid=123 Virtual Physical Size DumpFileOffset ---------- ---------- ---------- -------------- --SNIP-- 0x75b6b000 0x18de0000 0x1000 0x1a3000 --SNIP-- The text is indeed at 0x18de04d8 in memory.dmp, but not at 0x1a34d8 in 123.dmp. Again, it's no where to be found in 123.dmp. Any suggestions..?? Many thanks, Adam

10 years, 1 month

3
7
0 0

The 2015 BSides New Orleans speaker lineup is out!

by Andrew Case

We are very excited to announce that the lineup for BSidesNOLA 2015 is out! The day will start with a keynote presentation from Chris Rohlf of Yahoo. It will then continue with three tracks of talks ranging from application security to memory forensics to malware analysis. These talks will be given by some of the best researchers in the forensics, incident response, and security fields. Full information on the conference can be found at the following page: http://www.securitybsides.com/w/page/91550808/BSidesNOLA%202015 The cost to attend is $10, and you must register through the EventBrite link ( https://www.eventbrite.com/e/bsides-nola-2015-tickets-9621601469 ). Last year was our second year and we had over 150 people attend. We are expecting closer to 200 this year. For those of you who attended last year, you know that beyond just great talks and networking, we also provide very good food and drinks. The close proximity to the French Quarter (5-10 minute walk) also means that after the conference there will be plenty of fun and interesting things to do for the rest of the night. We hope to see you there and if you have any questions please reply to this thread or email bsidesnola [@@] gmail.com. -- Thanks, Andrew (@attrc)

10 years, 1 month

1
0
0 0

Reston and NYC Volatility classes filling fast

by Andrew Case

Our public five day Windows memory forensic classes in Reston in April and NYC in May are filling fast. If you are looking to take the course in the US before winter then please contact us ASAP: http://www.memoryanalysis.net/#!memory-forensics-training/c1q3n -- Thanks, Andrew (@attrc)

10 years, 1 month

1
0
0 0

Blog post on using Volatility to find a keylogger (again)

by Bridgey theGeek

(Argh, sorry if you just received a messed email. Darn keyboard shortcuts. Anyway...) Hi all, CORPORATE BLOG WARNING! In case you were dozing and missed it, I posted a blog entry today on using Volatility in anger. I used it to analyse a hiberfil.sys and identify a few things about a keylogger that was running on a client's system. I tried to make it as detailed as possible, specifically around the Volatility commands I was using and why I chose them. http://ctx.is/thank-malware-T Andrew Case has already been kind enough to provide me with some feedback, which I shall take the liberty of sharing below: "When you ran dlldump to grab the WinInstall.dll you could have used '-b 0x000007fef5930000' to only get the DLL you wanted instead of all of them. That address comes from dlllist output and its where the DLL is loaded into memory." "For finding the service you could have tried the 'svcscan' plugin and if you do 'svcscan -v', it will list the path of the DLL or driver used to start the service. That is easier than searching through the registry." Thanks Andrew! Regards, Adam

10 years, 1 month

1
0
0 0

Re: [Vol-users] Problems with Win7SP1x64 hiberfil.sys

by Mike Auty

Also, Imageinfo correctly identified it as IA32PagedMemoryPae, and suggested Win7SP1x86, but it's easy to miss, just like everyone reading this thread (myself included). 5:) Mike 5:)

10 years, 2 months

2
1
0 0

Problems with Win7SP1x64 hiberfil.sys

by Bridgey theGeek

Hi all, Just trying to figure out where I'm going wrong. I have a hiberfil.sys file from a Win7SP1x64 system. The first 6 pages are full of 0x00 which I believe means the hiberfil was wiped as part of a resume. Having read the AOMF, specifically p98, I expected Volatility to brute force the header and, voila, magic happens. However, Volatility just reports that it wasn't able to find a matching address space: $ python vol.py -f /tmp/hiberfil.sys imageinfo Volatility Foundation Volatility Framework 2.4 Determining profile based on KDBG search... Suggested Profile(s) : No suggestion (Instantiated with Win7SP1x86) AS Layer1 : IA32PagedMemoryPae (Kernel AS) AS Layer2 : WindowsHiberFileSpace32 (Unnamed AS) AS Layer3 : FileAddressSpace (/tmp/hiberfil.sys) PAE type : PAE DTB : 0x185000L KDBG : 0x82d3ac28 Number of Processors : 4 Image Type (Service Pack) : 1 KPCR for CPU 0 : 0x82d3bc00 KPCR for CPU 1 : 0x807c6000 KPCR for CPU 2 : 0x8d300000 KPCR for CPU 3 : 0x8d336000 KUSER_SHARED_DATA : 0xffdf0000 Image date and time : 2014-05-09 15:26:28 UTC+0000 Image local date and time : 2014-05-09 17:26:28 +0200 $ python vol.py -f /tmp/hiberfil.sys --profile=Win7SP1x64 pslist Volatility Foundation Volatility Framework 2.4 No suitable address space mapping found Tried to open image as: MachOAddressSpace: mac: need base LimeAddressSpace: lime: need base WindowsHiberFileSpace32: No base Address Space WindowsCrashDumpSpace64BitMap: No base Address Space WindowsCrashDumpSpace64: No base Address Space ... ... If I try an imagecopy, the output file is identical to the original: $ python vol.py -f /tmp/hiberfil.sys --profile=Win7SP1x64 imagecopy -O /tmp/hiberfil.bin Volatility Foundation Volatility Framework 2.4 Writing data (5.00 MB chunks): |.................................................................................................................................................................................................................................................................................................................................................................................................................................................................| bridgey@aspire:~/dev/volatility$ md5sum /tmp/hiberfil.* fee8a1c6924b871477434a678adb4483 /tmp/hiberfil.bin fee8a1c6924b871477434a678adb4483 /tmp/hiberfil.sys And finally, I couldn't find a class for 64-bit hiberfil... $ find -type f -name '*iber*' -exec grep -H ^class.WindowsHi {} \; ./volatility/plugins/addrspaces/hibernate.py:class WindowsHiberFileSpace32(addrspace.BaseAddressSpace): Am I leaping to conclusions, or is a hiberfil from a 64-bit system simply not supported? Would love any comments! Thanks, Adam

10 years, 2 months

3
3
0 0

New blog post on using bulk_extractor with memory forensics

by Andrew Case

Yesterday we published a new blog post on using bulk_extractor during memory forensics investigations. The writeup focused on the ability to create PCAP files of resident network data inside a memory capture. If you are not using this capability in your investigations then you are definitely missing out! http://volatility-labs.blogspot.com/2015/01/incorporating-disk-forensics-wi… -- Thanks, Andrew (@attrc)

10 years, 2 months

2
1
0 0

Announcing BSidesNOLA 2015!

by Andrew Case

We are pleased to announce that BSidesNOLA 2015 will take place on Saturday, May 30th in the heart of downtown New Orleans. Full details can be found on the following page: http://www.securitybsides.com/w/page/91550808/BSidesNOLA Our call for papers is currently open and we will be accepting submissions through March 1st. Please spend time on your CFP submission(s) as we receive a large number each year and inevitably have to reject some of them. If you look at our lineup from last year (http://www.securitybsides.com/w/page/71231585/BsidesNola2014) and the year before (http://www.securitybsides.com/w/page/62741761/BsidesNola) you will see that we attract some of the best speakers and researchers in the industry. You don't want to miss our speakers' party so send us your best stuff! Also, we are very excited to announce that Chris Rohlf will be keynoting this year. He has many years experience in the industry and is currently in charge of all penetration testing efforts inside of Yahoo. He will be speaking on performing offensive computer operations at scale. Please let us know if you have any questions, and if you plan to attend you must register on the Eventbrite page! -- Thanks, Andrew (@attrc)

10 years, 2 months

1
0
0 0

2015 DFRWS GPU memory challenge

by Andrew Case

Was writing to let everyone know that the DFRWS challenge is out for this year and it involves analyzing both a usual linux memory sample as well as analyzing GPU memory from a nvidia device. The challenge's creator worked with nvidia to have an acquisition tool capable of getting the memory off the devices. The latest git version of Volatility can analyze the Linux side, but the real purpose of the challenge is to encourage memory forensics research against the GPU. Hoping for some exciting results from it! http://www.cs.uno.edu/~golden/gpu-malware-research.html -- Thanks, Andrew (@attrc)

10 years, 3 months

1
0
0 0

ShmooCon

by AAron Walters

vol-users, If anyone is planning to attend ShmooCon today and wants to meet up, please send me a note offlist. We can discuss features you would like to see integrated into future releases, the benefits of Volatility training, half-baked anti-forensics schemes, why Andrew only drinks Champagne, and where we are headed with Volatility 3.0! AAron Walters The Volatility Foundation

10 years, 3 months

1
0
0 0

Memory Forensics Training in Ottawa, Canada

by Michael Ligh

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi folks, Sorry for the short notice. We have 4 seats available for our Malware and Memory Forensics Training class in Ottawa in February. Send me a note if you're interested. It will probably be the only time we're in Canada in 2015. Cheers! MHL -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org iF4EAREKAAYFAlS0MwUACgkQXnt9v1O0LItfcAD+O6PZ8v4/nowcwbW3z8SCNMf1 KUXdE4fFu5jEUivfJYIA/0DzpkzsaViQ//bwuRse3kKGnrAmTwKVFpfZMJiAWO8j =N5qi -----END PGP SIGNATURE-----

10 years, 3 months

1
0
0 0

Getting Error on Ubuntu 14.04 when I attempt Netscan

by Gibson, Ryan

WARNING : volatility.obj : NoneObject as string: Pointer Owner invalid I saw some people also having the same issues, but I am not seeing the fix anywhere. Suggestions?

10 years, 3 months

3
2
0 0

Re: Centos 6.5 2.6.32-431.17.1 64 bit linux profile?

by Jesse Bowling

Imagine my chagrin to find that the new volatility site contains exactly what I proposed below. Mea culpa for referencing old directions and code... :-/ For those that come after me, take a look at https://github.com/volatilityfoundation/volatility/wiki/Linux and specifically: "You can find a repository of pre-built profiles at the volatilityfoundation/profiles Github.” Cheers, Jesse On Dec 29, 2014, at 7:32 PM, Jesse Bowling <jessebowling(a)gmail.com> wrote: > Hello, > > Hoping someone on the list has a profile for Centos 6.5 running a 2.6.32-431.17.1.el6.x86_64 kernel they wouldn’t mind sharing...It’s a non-standard thing for my environment, so I don’t have a similar box to build from (and am hoping to save the time of building a machine just for this)... > > Tangential to this, are there any repositories of Volatility profiles for Linux? I noticed Ken Pryor’s Github repo which seems like a great idea (and platform) for this, however he only has a few Ubuntu versions and it doesn’t look like it’s been updated in a while...Any interest from the Volatility team in starting something similar (if it’s not already happening and I just don’t know about it)? > > Cheers, > > Jesse

10 years, 3 months

1
0
0 0

Re: [Vol-users] Trick to getting xlsx output

by Jamie Levy

Hi James, I have updated timeliner to work with the new OpenPyxl API. Just for reference, my install is from [1]. In addition to this, I have also added xlsx output as a renderer for the unified output [2]. So you should be able to get xlsx output from any plugin that has already been converted. You can see which plugins have this support by using the --help/-h switch. For example: $ python vol.py -f mem.img pslist --help [snip] Module Output Options: dot, html, json, quicktext, sqlite, text, xlsx [snip] $ python vol.py -f mem.img pslist --output=xlsx --output-file=pslist.xlsx All the best, -Jamie [1] https://pypi.python.org/pypi/openpyxl [2] https://github.com/volatilityfoundation/volatility/commit/c4a9a732c9411e7b0… On 12/19/14 7:40 AM, James Lay wrote: > On Fri, 2014-12-19 at 03:01 +0000, Jamie Levy wrote: >> OpenPyxl just changed their API and it is no longer compatible. I am in the process of fixing the timeliner plugin to use the new API. >> >> Also, the excel output for psxview has already been converted to the new API. >> >> All the best, >> >> -Jamie >> >> >> >> ------Original Message------ >> From: James Lay >> Sender: vol-users-bounces(a)volatilityfoundation.org <mailto:vol-users-bounces@volatilityfoundation.org> >> To: Volatility >> ReplyTo: jlay(a)slave-tothe-box.net <mailto:jlay@slave-tothe-box.net> >> Subject: [Vol-users] Trick to getting xlsx output >> Sent: Dec 18, 2014 6:27 PM >> >> Hey all, >> >> Using 2.4...not able to get xlsx output...greeted with: >> >> Volatility Foundation Volatility Framework 2.4 >> ERROR : volatility.plugins.timeliner: You must install OpenPyxl for >> xlsx format: >> https://bitbucket.org/ericgazoni/openpyxl/wiki/Home >> >> My install method for volatility was download, extract, move to >> /opt/volatility, and python vol.py from there. >> My install method for openpyxl was: >> >> hg clone https://bitbucket.org/openpyxl/openpyxl >> cd openpyxl >> python setup.py build >> sudo python setup.py install >> >> Is there anything else I need to check? I see a slew of items in: >> >> /usr/local/lib/python2.7/dist-packages/openpyxl-2.1.4-py2.7.egg/ >> >> Thank you. >> >> James >> _______________________________________________ >> Vol-users mailing list >> Vol-users(a)volatilityfoundation.org <mailto:Vol-users@volatilityfoundation.org> >> http://lists.volatilityfoundation.org/mailman/listinfo/vol-users >> > > Awesome....looking forward to it...thank you. > > James -- Jamie Levy (@gleeda) Blog: http://volatility-labs.blogspot.com/ GPG: http://pgp.mit.edu/pks/lookup?op=get&search=0x196B2AB527A4AC92 Fingerprint: 2E87 17A1 EC10 1E3E 11D3 64C2 196B 2AB5 27A4 AC92

10 years, 3 months

1
0
0 0

31C3

by Philip Huppert

Hi, are there any Volatility users attending 31C3? How about a meetup? Regards, Philip

10 years, 3 months

3
3
0 0

Re: [Vol-users] Trick to getting xlsx output

by Jamie Levy

OpenPyxl just changed their API and it is no longer compatible. I am in the process of fixing the timeliner plugin to use the new API. Also, the excel output for psxview has already been converted to the new API. All the best, -Jamie ------Original Message------ From: James Lay Sender: vol-users-bounces(a)volatilesystems.com To: Volatility ReplyTo: jlay(a)slave-tothe-box.net Subject: [Vol-users] Trick to getting xlsx output Sent: Dec 18, 2014 6:27 PM Hey all, Using 2.4...not able to get xlsx output...greeted with: Volatility Foundation Volatility Framework 2.4 ERROR : volatility.plugins.timeliner: You must install OpenPyxl for xlsx format: https://bitbucket.org/ericgazoni/openpyxl/wiki/Home My install method for volatility was download, extract, move to /opt/volatility, and python vol.py from there. My install method for openpyxl was: hg clone https://bitbucket.org/openpyxl/openpyxl cd openpyxl python setup.py build sudo python setup.py install Is there anything else I need to check? I see a slew of items in: /usr/local/lib/python2.7/dist-packages/openpyxl-2.1.4-py2.7.egg/ Thank you. James _______________________________________________ Vol-users mailing list Vol-users(a)volatilesystems.com http://lists.volatilesystems.com/mailman/listinfo/vol-users

10 years, 4 months

1
0
0 0

Trick to getting xlsx output

by James Lay

Hey all, Using 2.4...not able to get xlsx output...greeted with: Volatility Foundation Volatility Framework 2.4 ERROR : volatility.plugins.timeliner: You must install OpenPyxl for xlsx format: https://bitbucket.org/ericgazoni/openpyxl/wiki/Home My install method for volatility was download, extract, move to /opt/volatility, and python vol.py from there. My install method for openpyxl was: hg clone https://bitbucket.org/openpyxl/openpyxl cd openpyxl python setup.py build sudo python setup.py install Is there anything else I need to check? I see a slew of items in: /usr/local/lib/python2.7/dist-packages/openpyxl-2.1.4-py2.7.egg/ Thank you. James

10 years, 4 months

1
0
0 0

Process unable to be extracted

by Dave Nardoni

I have some processes listed in pslist and psscan that are unable to be dumped using procdump by either the pid or the offset. Are there other approaches that can be used to dump these processes? Not in front of computer right now but error was something like unable to parse the peb. I can get the exact error message later if it helps. All other plugins work just find so memory image is not in question. Sent from my iPhone Dnardoni(a)gmail.com

10 years, 4 months

2
1
0 0

Problem regarding running volatility

by Mohammad-Reza Memarian

Ciao Guys I want to use from volatility to analyze a linux memory data. So I created a profile of that kernel, transfered it to volatility directory on my computer, now I want to run the plugins but I can not run any of the plugins as It throughs various errors in one case pslist there is no output, other cases it says the command is not suppoerted for this profile, did anyone had the same experience? Regards Reza

10 years, 4 months

3
2
0 0

Join us on Monday for an Art of Memory Forensics Reddit AMA

by Andrew Case

We are excited to announce that on next Monday, December 15th, from 9AM-11AM PST, the Art of Memory Forensics authors will be doing an AMA (Ask Me Anything) on Reddit's netsec. This is a chance to ask us non-technical questions, comment on or ask about the book, or anything else related to Volatility and memory forensics. The last book AMA on Reddit was for the Android Hacker's Handbook and it will really well with over 300 comments ( https://www.reddit.com/r/netsec/comments/27zdxc/android_hackers_handbook_ama ) . We are hoping to have ours be big as well so please try to attend and spread the word! -- Thanks, Andrew (@attrc)

10 years, 4 months

1
0
0 0

Strange results

by James Lay

So here's what I got all...an image of a laptop running Windows 7 64 bit...image was captured using DumpIt in an admin console: Determining profile based on KDBG search... Suggested Profile(s) : Win7SP0x64, Win7SP1x64, Win2008R2SP0x64, Win2008R2SP1x64 AS Layer1 : AMD64PagedMemory (Kernel AS) AS Layer2 : FileAddressSpace (/home/jlay/Forensics/FMCCOMBS-20141203-153133.raw) PAE type : No PAE DTB : 0x187000L KDBG : 0x1b430010a0 Number of Processors : 1 Image Type (Service Pack) : 1 KPCR for CPU 0 : 0xfffff80003002d00L KUSER_SHARED_DATA : 0xfffff78000000000L Image date and time : 2014-12-03 15:31:47 UTC+0000 Image local date and time : 2014-12-03 08:31:47 -0700 Running "python vol.py -f ~/Forensics/FMCCOMBS-20141203-153133.raw --profile Win7SP1x64 pslist" gets me: Offset(V) Name PID PPID Thds Hnds Sess Wow64 Start Exit 0xfffffa800694ab30 System 4 0 141 -1 1191132111 0 2014-12-01 15:40:49 UTC+0000 0xfffffa800ae934f0 ?b?_?b?_?b?_?b?_ 1606836934 1606836934 1606836934 -1 -1 1 - And that's it. Any hints on just why this isn't showing any processes? Volatility version is 2.4 running on Ubuntu 14 64 bit. Thank you. James

10 years, 4 months

3
2
0 0

Upcoming memory forensics trainings in SF, Reston, NY, and Amsterdam

by Andrew Case

We are happy to announce that we now have several 2015 public trainings scheduled across the USA as well as in Europe. Full details can be found at the following link: http://www.memoryanalysis.net/#!memory-forensics-training/c1q3n Our schedule for next year is getting pretty full so please contact ASAP if you are interested in a private training or us hosting a public training in your area. -- Thanks, Andrew (@attrc)

10 years, 4 months

1
0
0 0

My presentation on analyzing Careto with Volatility is now online

by Andrew Case

Link: http://2014.video.sector.ca/video/110388398 In the presentation I give an introduction to memory forensics and then spend the rest of the time looking at Careto through the eyes of memory forensics. Careto went undetected for over 7 years by the AV industry, but in the talk you can see that memory forensics finds it over and over again in only a few minutes. PS: I gave a focused and more in-depth version of this talk at OMFW (without the intro and hunting parts) -- Thanks, Andrew (@attrc)

10 years, 5 months

1
0
0 0

The results of the 2014 Volatility plugin contest are now available!

by Andrew Case

We are happy to announce that the results of the 2014 Volatility plugin contest are now available: http://volatility-labs.blogspot.com/2014/10/announcing-2014-volatility-plug… Congrats to the winners and we would like to again thank Facebook for their donation that doubled the contest's prize money! -- Thanks, Andrew (@attrc)

10 years, 5 months

1
0
0 0

RE: [Detailed analysis of Kaspersky hooks including analysis....

by Michael Chaves

I've used malfind and memscan on a suspected POS infected system and I get a ton of false positive hits on AV processes. Any way to white list some of these or use --silent to filter out some of these false positives? On the other side, is it likely malware is using AV processes to do their deed? Mike Det. Michael Chaves Monroe Police Department 7 Fan Hill Road Monroe, CT 06468 203.452.2831 x1307 (desk) 203.261.3622 (w) 203.650.7997 (c) *** NOTE: If you are sending me an attachment, rename the extension to .txt or .jpg, otherwise, due to filters, I will not get it *** -----Original Message----- From: vol-users-bounces(a)volatilityfoundation.org [mailto:vol-users-bounces@volatilityfoundation.org] On Behalf Of vol-users-request(a)volatilityfoundation.org Sent: Tuesday, October 28, 2014 1:00 PM To: vol-users(a)volatilityfoundation.org Subject: [BULK] Vol-users Digest, Vol 76, Issue 6 Send Vol-users mailing list submissions to vol-users(a)volatilityfoundation.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.volatilityfoundation.org/mailman/listinfo/vol-users or, via email, send a message with subject or body 'help' to vol-users-request(a)volatilityfoundation.org You can reach the person managing the list at vol-users-owner(a)volatilityfoundation.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Vol-users digest..." Today's Topics: 1. Detailed analysis of Kaspersky hooks including analysis with Volatility (Andrew Case) ---------------------------------------------------------------------- Message: 1 Date: Tue, 28 Oct 2014 02:16:58 -0500 From: Andrew Case <atcuno(a)gmail.com> Subject: [Vol-users] Detailed analysis of Kaspersky hooks including analysis with Volatility To: "'vol-users(a)volatilityfoundation.org'" <vol-users(a)volatilityfoundation.org> Message-ID: <544F42EA.9020500(a)gmail.com> Content-Type: text/plain; charset=ISO-8859-1 A really well done writeup & analysis: https://quequero.org/2014/10/kaspersky-hooking-engine-analysis/ -- Thanks, Andrew (@attrc) ------------------------------ _______________________________________________ Vol-users mailing list Vol-users(a)volatilityfoundation.org http://lists.volatilityfoundation.org/mailman/listinfo/vol-users End of Vol-users Digest, Vol 76, Issue 6 ****************************************

10 years, 5 months

2
1
0 0

LiME and Intel Atom (x86) AVD

by masdif

Hi, I'm trying to compile LiME for a given Android Virtual Device (AVD) Platform 4.4.2 API Level 19 CPU Intel Atom (x86) I have no information about how the AVD was created. Does in this case investigation with LiME/Volatility make sense at all? Should LiME be able to handle the Atom-Processor? If yes: Should Volatility be able to handle the LiME dump? If any answer up to now was no: No further reading necessary. :-( But please enlighten me. ;-) If this in principle is not an impossible plan then how do I have to handle the following warnings/errors? (a) LiME compiles but gives me a WARNING: Symbol version dump ~/android/kernel/goldfish/Module.symvers is missing; modules will have no dependencies and modversions. (b) insmod fails insmod: init_module '/sdcard/lime.ko' failed (No such file or directory) (but of course there is a '/sdcard/lime.ko') (c) dmesg reports lime: Unknown symbol _GLOBAL_OFFSET_TABLE_ (err 0) lime: Unknown symbol kmap (err 0) lime: Unknown symbol kunmap (err 0) Is it correct to expect, that (b) and (c) are a result from (a)? What is to be done? Compiling the kernel and hope the Module.symvers fits to the AVD symbols? The LiME documentation does not mention a need for compiling the Android kernel. Or do I have to work on the kernel's .config? As always there is no /proc/config.gz on the phone/AVD. (At least I have not seen any /proc/config.gz on my devices so far.) Instead in this case I worked on the goldfish/arch/x86/configs/i386_defconfig until the AVD accepted the version magic. Just in case it is useful, here is in detail what I did so far: ________________________________________ ### the AVD ### cat /proc/version Linux version 3.4.0+ (nnk(a)nnk.mtv.corp.google.com) (gcc version 4.7 (GCC) ) #1 PREEMPT Wed Jul 10 09:55:37 PDT 2013 ________________________________________ ### Goldfish kernel 3.4.0+ for LiME compilation ### $ mkdir -p ~/android/kernel && cd $_ $ git clone https://android.googlesource.com/kernel/goldfish.git $ cd goldfish $ git branch -a $ git checkout origin/android-goldfish-3.4 -b goldfish-3.4 $ git log --pretty=oneline | grep -i 'linux 3.4$' $ git checkout 76e10d1 -b goldfish-3.4-76e10d1 $ cp arch/x86/configs/i386_defconfig .config ________________________________________ ### modify .config in order to get correct version ### ### magic: '3.4.0+ preempt mod_unload CORE2 ' ### $ diff arch/x86/configs/i386_defconfig .config 39c39,41 < CONFIG_SMP=y --- > CONFIG_SMP=n > CONFIG_MCORE2=y > CONFIG_PREEMPT=y 43c45 < CONFIG_PREEMPT_VOLUNTARY=y --- > CONFIG_PREEMPT_VOLUNTARY=n ________________________________________ ### prepare kernel for module compilation ### $ make ARCH=x86 CROSS_COMPILE=~/android/ndk/toolchains/ x86-4.9/prebuilt/linux-x86_64/bin/i686-linux-android- modules_prepare ________________________________________ ### LiME Makefile ### obj-m := lime.o lime-objs := tcp.o disk.o main.o KDIR_GOLD := ~/android/kernel/goldfish/ CCPATH := ~/android/ndk/toolchains/x86-4.9/prebuilt/linux-x86_64/bin PWD := $(shell pwd) default: # cross-compile for Android emulator $(MAKE) ARCH=x86 CROSS_COMPILE=$(CCPATH)/i686-linux-android- -C $(KDIR_GOLD) M=$(PWD) modules $(CCPATH)/i686-linux-android-strip --strip-unneeded lime.ko mv lime.ko lime-goldfish.ko $(MAKE) tidy tidy: rm -f *.o *.mod.c Module.symvers Module.markers modules.order \.*.o.cmd \.*.ko.cmd \.*.o.d rm -rf \.tmp_versions clean: $(MAKE) tidy rm -f *.ko ________________________________________ Thanks, Philipp

10 years, 5 months

1
0
0 0

Detailed analysis of Kaspersky hooks including analysis with Volatility

by Andrew Case

A really well done writeup & analysis: https://quequero.org/2014/10/kaspersky-hooking-engine-analysis/ -- Thanks, Andrew (@attrc)

10 years, 5 months

1
0
0 0

Working of ldrmodules ?

by Jamison Bosco

Hello Group, So am not sure, if I understood, the working of ldrmodules correctly, but in short, for each process, I imagine it looks at the VAD; and for each dll found there compares it with the 3 lists in the process PEB and reports back on any discrepancy. A snippet, from vadinfo for a process with pid 12128, I can see a dll mapped VAD node @ 0xfffffa80088378c0 Start 0x0000000000040000 End 0x0000000000040fff Tag Vad Flags: Protection: 7, VadType: 2 Protection: PAGE_EXECUTE_WRITECOPY Vad Type: VadImageMap ControlArea @fffffa8006a86c40 Segment fffff8a00021d4e0 Dereference list: Flink 00000000, Blink 00000000 NumberOfSectionReferences: 1 NumberOfPfnReferences: 1 NumberOfMappedViews: 119 NumberOfUserReferences: 120 WaitingForDeletion Event: 00000000 Control Flags: File: 1, Image: 1 FileObject @fffffa80069c5250, Name: \Windows\System32\apisetschema.dll First prototype PTE: fffff8a00021d5a8 Last contiguous PTE: fffffffffffffffc Flags2: Inherit: 1 But ldrmodules (or dlllist) over the image, does not show that dll. cat ldrmodules.txt | grep -i apiset cat dlllist.txt | grep -i apiset The process in question has a pid of 12128, so on a frequency count, there is a large discrepancy, that I don't understand why. cat ldrmodules.txt | grep 12128 | wc -l 54 cat vadinfo-12128.txt | grep dll | wc -l 130 Any pointers to a link I should read up on to understand the concepts here. Should not have ldrmodules, reported on all the dlls that were found as mapped files in the VAD ? Thanks, JB

10 years, 6 months

1
0
0 0

Mac sleepimage

by Jarle Thorsen

Does Volatility support the analysis of Mac /var/vm/sleepimage? I did not see it mentioned in "The Art of Memory Forensics", and I seem to have trouble even doing a simple mac_pslist against it... -- Jarle Thorsen

10 years, 6 months

1
0
0 0

Reminder: OMFW 2014 Registration Closes Oct 24

by AAron Walters

vol-users, The registration for the Open Memory Forensics Workshop (OMFW) 2014 closes on Oct 24. If you are still planning to attend, I recommend sending a request as soon as possible. There are less than 10 open seats remaining! For those who have already requested an invitation, please let us know if you have not received your registration details. Reserve your seat by sending an email to info [at] volatilityfoundation.org or using the contact form on the Foundation's website. Thanks, The Volatility Foundation www.volatilityfoundation.org

10 years, 6 months

1
0
0 0

AttributeError: 'linux_mount' object has no attribute 'parse_mnt' error when trying to list tmpfs in Linux/Windows using Volatility 2.4

by Srinivasan J

Hi, I am trying to recover tmpfs from a RAM lime dump using volatility 2.4 in Linux/Windows, but I hit the "AttributeError: 'linux_mount' object has no attribute 'parse_mnt'". Is this a known issue? Thanks, Srini [srini@localhost volatility-2.4]$ python /home/srini/vola/setup/volatility-2.4/vol.py --plugins=/mnt/data/home/srini/ovf --profile=Linuxcentos7x64 -f /mnt/data/home/srini/ovf/ramtmpfs.lime linux_tmpfs -L Volatility Foundation Volatility Framework 2.4 Traceback (most recent call last): File "/home/srini/vola/setup/volatility-2.4/vol.py", line 192, in <module> main() File "/home/srini/vola/setup/volatility-2.4/vol.py", line 183, in main command.execute() File "/home/srini/vola/setup/volatility-2.4/volatility/plugins/linux/common.py", line 62, in execute commands.Command.execute(self, *args, **kwargs) File "/home/srini/vola/setup/volatility-2.4/volatility/commands.py", line 127, in execute func(outfd, data) File "/home/srini/vola/setup/volatility-2.4/volatility/plugins/linux/tmpfs.py", line 157, in render_text for (i, path) in data: File "/home/srini/vola/setup/volatility-2.4/volatility/plugins/linux/tmpfs.py", line 148, in calculate tmpfs_sbs = self.get_tmpfs_sbs() File "/home/srini/vola/setup/volatility-2.4/volatility/plugins/linux/tmpfs.py", line 120, in get_tmpfs_sbs for (sb, _dev_name, path, fstype, _rr, _mnt_string) in linux_mount.linux_mount(self._config).parse_mnt(mnts): AttributeError: 'linux_mount' object has no attribute 'parse_mnt' C:\Users\sjayarajan\Downloads\volatility_2.4.win.standalone\volatility_2.4.win.s tandalone> C:\Users\sjayarajan\Downloads\volatility_2.4.win.standalone\volatility_2.4.win.s tandalone>volatility-2.4.standalone.exe --plugins=profile --profile=Linuxcentos7 x64 -f D:\volat\ramtmpfs.lime linux_tmpfs -L Volatility Foundation Volatility Framework 2.4 Traceback (most recent call last): File "<string>", line 192, in <module> File "<string>", line 183, in main File "C:\volatility\build\pyinstaller\out00-PYZ.pyz\volatility.plugins.linux.c ommon", line 62, in execute File "C:\volatility\build\pyinstaller\out00-PYZ.pyz\volatility.commands", line 127, in execute File "C:\volatility\build\pyinstaller\out00-PYZ.pyz\volatility.plugins.linux.t mpfs", line 157, in render_text File "C:\volatility\build\pyinstaller\out00-PYZ.pyz\volatility.plugins.linux.t mpfs", line 148, in calculate File "C:\volatility\build\pyinstaller\out00-PYZ.pyz\volatility.plugins.linux.t mpfs", line 120, in get_tmpfs_sbs AttributeError: 'linux_mount' object has no attribute 'parse_mnt' C:\Users\sjayarajan\Downloads\volatility_2.4.win.standalone\volatility_2.4.win.s tandalone>volatility-2.4.standalone.exe --plugins=profile --profile=Linuxcentos7 x64 -f D:\volat\ramtmpfs.lime linux_cpuinfo Volatility Foundation Volatility Framework 2.4 Processor Vendor Model ------------ ---------------- ----- 0 GenuineIntel Intel(R) Xeon(R) CPU E5-2609 v2 @ 2.50GHz C:\Users\sjayarajan\Downloads\volatility_2.4.win.standalone\volatility_2.4.win.s tandalone> [srini@localhost volatility-2.4]$ python /home/srini/vola/setup/volatility-2.4/vol.py --plugins=/mnt/data/home/srini/ovf --profile=Linuxcent os7x64 --info | more Volatility Foundation Volatility Framework 2.4 Profiles -------- Linuxcentos7x64 - A Profile for Linux centos7 x64 VistaSP0x64 - A Profile for Windows Vista SP0 x64 VistaSP0x86 - A Profile for Windows Vista SP0 x86 VistaSP1x64 - A Profile for Windows Vista SP1 x64 VistaSP1x86 - A Profile for Windows Vista SP1 x86 VistaSP2x64 - A Profile for Windows Vista SP2 x64 VistaSP2x86 - A Profile for Windows Vista SP2 x86 [srini@localhost volatility-2.4]$ python /home/srini/vola/setup/volatility-2.4/vol.py --plugins=/mnt/data/home/srini/ovf --profile=Linuxcentos7x64 -f /mnt/data/home/srini/ovf/ramtmpfs.lime linux_cpuinfo Volatility Foundation Volatility Framework 2.4 Processor Vendor Model ------------ ---------------- ----- 0 GenuineIntel Intel(R) Xeon(R) CPU E5-2609 v2 @ 2.50GHz [srini@localhost volatility-2.4]$ python /home/srini/vola/setup/volatility-2.4/vol.py --plugins=/mnt/data/home/srini/ovf --profile=Linuxcentos7x64 -f /mnt/data/home/srini/ovf/ramtmpfs.lime linux_mount Volatility Foundation Volatility Framework 2.4 hugetlbfs /dev/hugepages hugetlbfs rw,relatime devtmpfs /dev devtmpfs rw,nosuid tmpfs /dev/shm tmpfs rw,nosuid,nodev devpts /dev/pts devpts rw,relatime,nosuid,noexec cgroup /sys/fs/cgroup/memory cgroup rw,relatime,nosuid,nodev,noexec tmpfs /sys/fs/cgroup tmpfs rw,nosuid,nodev,noexec proc /proc proc rw,relatime,nosuid,nodev,noexec /dev/mapper/centos-root / xfs rw,relatime tmpfs /run tmpfs rw,nosuid,nodev sysfs /sys sysfs rw,relatime,nosuid,nodev,noexec sunrpc /var/lib/nfs/rpc_pipefs rpc_pipefs rw,relatime mqueue /dev/mqueue mqueue rw,relatime debugfs /sys/kernel/debug debugfs rw,relatime selinuxfs /sys/fs/selinux selinuxfs rw,relatime securityfs /sys/kernel/security securityfs rw,relatime,nosuid,nodev,noexec cgroup /sys/fs/cgroup/systemd cgroup rw,relatime,nosuid,nodev,noexec pstore /sys/fs/pstore pstore rw,relatime,nosuid,nodev,noexec cgroup /sys/fs/cgroup/cpuset cgroup rw,relatime,nosuid,nodev,noexec sunrpc /proc/fs/nfsd nfsd rw,relatime tmpfs /mnt/ramdisk tmpfs rw,relatime cgroup /sys/fs/cgroup/cpu,cpuacct cgroup rw,relatime,nosuid,nodev,noexec configfs /sys/kernel/config configfs rw,relatime cgroup /sys/fs/cgroup/devices cgroup rw,relatime,nosuid,nodev,noexec systemd-1 /proc/sys/fs/binfmt_misc autofs rw,relatime cgroup /sys/fs/cgroup/freezer cgroup rw,relatime,nosuid,nodev,noexec cgroup /sys/fs/cgroup/net_cls cgroup rw,relatime,nosuid,nodev,noexec cgroup /sys/fs/cgroup/blkio cgroup rw,relatime,nosuid,nodev,noexec /dev/sda1 /boot xfs rw,relatime cgroup /sys/fs/cgroup/perf_event cgroup rw,relatime,nosuid,nodev,noexec cgroup /sys/fs/cgroup/hugetlb cgroup rw,relatime,nosuid,nodev,noexec [srini@localhost volatility-2.4]$ python /home/srini/vola/setup/volatility-2.4/vol.py --plugins=/mnt/data/home/srini/ovf --profile=Linuxcent os7x64 -f /mnt/data/home/srini/ovf/ramtmpfs.lime linux_bash Volatility Foundation Volatility Framework 2.4 Pid Name Command Time Command -------- -------------------- ------------------------------ ------- 15151 bash 2014-10-12 01:35:58 UTC+0000 ./configure 15151 bash 2014-10-12 01:35:58 UTC+0000 yum provides tcpsic 15151 bash 2014-10-12 01:35:58 UTC+0000 ls -ltrh 15151 bash 2014-10-12 01:35:58 UTC+0000 mv lmbench3 lmbench3-3.10 15151 bash 2014-10-12 01:35:58 UTC+0000 ls 15151 bash 2014-10-12 01:35:58 UTC+0000 cd linux/ 15151 bash 2014-10-12 01:35:58 UTC+0000 yum intall isic 15151 bash 2014-10-12 01:35:58 UTC+0000 ls 15151 bash 2014-10-12 01:35:58 UTC+0000 yum provides dwarfdump 15151 bash 2014-10-12 01:35:58 UTC+0000 ls 15151 bash 2014-10-12 01:35:58 UTC+0000 ls 15151 bash 2014-10-12 01:35:58 UTC+0000 cd 3.10.0-123.el7.x86_64/ 15151 bash 2014-10-12 01:35:58 UTC+0000 uname -a 15151 bash 2014-10-12 01:35:58 UTC+0000 ls 15151 bash 2014-10-12 01:35:58 UTC+0000 yum install isic 15151 bash 2014-10-12 01:35:58 UTC+0000 cd linux/ 15151 bash 2014-10-12 01:35:58 UTC+0000 ls 15151 bash 2014-10-12 01:35:58 UTC+0000 ls 15151 bash 2014-10-12 01:35:58 UTC+0000 make 15151 bash 2014-10-12 01:35:58 UTC+0000 ifconfig 15151 bash 2014-10-12 01:35:58 UTC+0000 cd lmbench3-3.10

10 years, 6 months

2
2
0 0

New Memory Forensics & Malware Analysis trainings scheduled!

by Andrew Case

We are excited to announce that we now have public trainings scheduled through May of next year. Between now and then we will be visiting Austin (Dec.), San Francisco (Jan.), Brazil (Feb.), Reston, VA (April), and New York (May). A complete listing of course offerings and details can be found at: http://www.memoryanalysis.net/#!memory-forensics-training/c1q3n and: http://volatility-labs.blogspot.com/2014/10/windows-malware-and-memory-fore… Classes fill quickly so please contact us ASAP if you would like to attend! We offer discounts for LEO, government, and full time students as well as group rates for companies. -- Thanks, Andrew (@attrc)

10 years, 6 months

1
0
0 0

Android Analysis

by felipecboeira .

Hi all, I have acquired an android RAM image by using Lime and now I am using volatility to analyze it. I have created a profile and can now list processes, etc. What I need to do is inspect an integer array of a kernel module, which I have the address. I tried using volshell's dd() but I believe it is not showing the correct values. How can I certify that the virtual address is being calculated correctly by volatility? Thanks in advance, Felipe

10 years, 6 months

2
1
0 0

Error in mac_netstat & mac_arp

by Andre DiMino

I have a .vmem file from a Mac OS virtual machine. I'm using profile "MacMountainLion_10_8_2_AMDx64" Using Volatility 2.4, I'm able to run a few mac commands against this image, however I get traceback errors in the 'netstat' and 'arp' commands. I paste below: +++++++++++++++++++++++++++++++++++++++++ forensics@saturn:~/workspace/iworm/memory$ vol -f iworm_run1.vmem --profile=MacMountainLion_10_8_2_AMDx64 mac_ifconfig Volatility Foundation Volatility Framework 2.4 Interface Address ---------- ------- lo0 fe80:1::1 lo0 127.0.0.1 lo0 ::1 gif0 stf0 en0 00:0c:29:ea:9a:27 en0 fe80:4::20c:29ff:feea:9a27 en0 172.16.253.140 +++++++++++++++++++++++++++++++++++++++++ forensics@saturn:~/workspace/iworm/memory$ vol -f iworm_run1.vmem --profile=MacMountainLion_10_8_2_AMDx64 mac_version Volatility Foundation Volatility Framework 2.4 Darwin Kernel Version 12.2.0: Sat Aug 25 00:48:52 PDT 2012; root:xnu-2050.18.24~1/RELEASE_X86_64 +++++++++++++++++++++++++++++++++++++++++ forensics@saturn:~/workspace/iworm/memory$ vol -f iworm_run1.vmem --profile=MacMountainLion_10_8_2_AMDx64 mac_netstat Volatility Foundation Volatility Framework 2.4 Proto Local IP Local Port Remote IP Remote Port State Process ------ -------------------- ---------- -------------------- ----------- -------------------- ------------------------ UNIX - UNIX /var/tmp/launchd/sock UNIX - UNIX /var/run/com.apple.ActivityMonitor.socket UNIX /var/run/mDNSResponder UNIX /var/rpc/ncacn_np/lsarpc UNIX /var/rpc/ncalrpc/lsarpc UNIX /var/rpc/ncacn_np/mdssvc UNIX /var/rpc/ncalrpc/NETLOGON UNIX /var/rpc/ncacn_np/srvsvc UNIX /var/rpc/ncalrpc/srvsvc UNIX /var/rpc/ncacn_np/wkssvc UNIX /var/rpc/ncalrpc/wkssvc Traceback (most recent call last): File "/home/forensics/programs/volatility-2.4/vol.py", line 192, in <module> main() File "/home/forensics/programs/volatility-2.4/vol.py", line 183, in main command.execute() File "/home/forensics/programs/volatility-2.4/volatility/plugins/mac/common.py", line 46, in execute commands.Command.execute(self, *args, **kwargs) File "/home/forensics/programs/volatility-2.4/volatility/commands.py", line 127, in execute func(outfd, data) File "/home/forensics/programs/volatility-2.4/volatility/plugins/mac/netstat.py", line 58, in render_text self.table_row(outfd, proto, lip, lport, rip, rport, state, "{}/{}".format(proc.p_comm, proc.p_pid)) ValueError: zero length field name in format +++++++++++++++++++++++++++++++++++++++++ forensics@saturn:~/workspace/iworm/memory$ vol -f iworm_run1.vmem --profile=MacMountainLion_10_8_2_AMDx64 mac_arp Volatility Foundation Volatility Framework 2.4 Source IP Dest. IP Name Sent Recv Time Exp. Delta ------------------------ ------------------------ ---------- ------------------ ------------------ ------------------------------ ---------- ----- Traceback (most recent call last): File "/home/forensics/programs/volatility-2.4/vol.py", line 192, in <module> main() File "/home/forensics/programs/volatility-2.4/vol.py", line 183, in main command.execute() File "/home/forensics/programs/volatility-2.4/volatility/plugins/mac/common.py", line 46, in execute commands.Command.execute(self, *args, **kwargs) File "/home/forensics/programs/volatility-2.4/volatility/commands.py", line 127, in execute func(outfd, data) File "/home/forensics/programs/volatility-2.4/volatility/plugins/mac/route.py", line 104, in render_text rt.name, File "/home/forensics/programs/volatility-2.4/volatility/obj.py", line 537, in __getattr__ return getattr(result, attr) File "/home/forensics/programs/volatility-2.4/volatility/plugins/overlays/mac/mac.py", line 562, in name return "{}{}".format(self.rt_ifp.if_name.dereference(), self.rt_ifp.if_unit) ValueError: zero length field name in format ++++++++++++++++++++++++++++++ Any thoughts or ideas are very appreciated! -- Andre' M. DiMino DeepEnd Research http://deependresearch.org http://sempersecurus.org "Make sure that nobody pays back wrong for wrong, but always try to be kind to each other and to everyone else" - 1 Thess 5:15 (NIV)

10 years, 6 months

2
2
0 0

Error with 2.4 Debian Wheezy

by Sean McLinden

I just build a VM with Debian (I needed to install other packages) and when I run this on a memory image I get the following (after about 10 minutes). The pslist.txt file is partially populated though how far it gets differs with each run. The box is Windows 7 Enterprise SP 1. The image was acquired using FTK. The box is believed to be infected with malware. user@host:/mnt/hgfs/288A-LV-2810395/Workspace/QJK1/memory# vol.py pslist > pslist.txt Volatility Foundation Volatility Framework 2.4 Traceback (most recent call last): File "/usr/local/bin/vol.py", line 192, in <module> main() File "/usr/local/bin/vol.py", line 183, in main command.execute() File "/usr/local/lib/python2.7/dist-packages/volatility/commands.py", line 127, in execute func(outfd, data) File "/usr/local/lib/python2.7/dist-packages/volatility/plugins/taskmods.py", line 178, in render_text str(task.ExitTime or ''), File "/usr/local/lib/python2.7/dist-packages/volatility/commands.py", line 219, in table_row outfd.write(self.tablesep.join(reslist) + "\n") IOError: [Errno 22] Invalid argument Thanks for any help. Sean McLinden

10 years, 6 months

2
2
0 0

conflicting argument

by A Musavi

Hi, I think there is still conflicting problem in vol 2.4: optparse.OptionConflictError: option -F/--filter: conflicting option string(s): -F

10 years, 7 months

2
1
0 0

failing to map address space for a dump/snapshot file created by libvirt command

by 谢志宇

Hi, everybody, I'm a new comer to volatility framework. At the same time, I am getting to work with libvirt library. I created a dump file named 'vm1_snapshot' by using libvirt command like 'virsh save domain'. In the domain ran the WinXPSP3x86. However, when I used 'python vol.py -f ~/vm1_snapshot --profile=WinXPSP3x86 pslist', the result showed as 'No suitable address space mapping found‍'. How could this happen? Is there anything wrong with the way the snapshot file was created? I hope some guy can do me a favor. ‍

10 years, 7 months

1
0
0 0

zeusscan2

by Bill Moylan

Testing zeusscan against a known zeus vmem sample, I am getting a segmentation fault. Other vol commands run and return results properly, and zeuscan appears to have compiled OK. No errors output except for the segmentation fault. Host OS is CentOS Linux 2.6, Volatility is 2.4. Zeus.vmem is WinXPSP2x86 Any ideas on troubleshooting? Bill

10 years, 7 months

2
1
0 0

OMFW 2014 Update & Dr. Brendan Dolan-Gavitt

by AAron Walters

vol-users, We are excited to announce that over half the seats for the Open Memory Forensics Workshop (OMFW) 2014 have already been reserved. It’s also great to see a large number of first time attendees from across government, academic, and commercial institutions. This is your one chance a year to hear about the latest research in memory forensics from the people who are pioneering the field. If you are still planning to attend, we suggest you register as soon as possible to make sure you have a seat. We are also excited to announce that Dr. Brendan Dolan Gavitt (moyix) will be speaking at the workshop. As many of you know, Brendan has been a member of the Volatility family since the very beginning and recently earned his PhD from the Georgia Institute of Technology. If you have followed Brendan’s work throughout the years and his new research with PANDA, I’m sure you will not be disappointed. In the upcoming weeks, we will continue finalizing and announcing the exciting roster of speakers. http://volatility.tumblr.com/post/97219909222/omfw-2014-update-dr-brendan-d… AW

10 years, 7 months

1
0
0 0

Having issues with linux profile -- please help

by Josh Horowitz

Dear Vol-users: First and foremost thanks to the creators of volatility for this amazing tool. I've been struggling to create a proper linux profile to analyze a memory dump from an Ubuntu 12.04.3 LTS machine created with fmem. The dump was split into several files which I combined using cat. I don't have access to the physical machine just some snapshot info, and have been trying to gather all the information I need in order to create the proper profile as follows: I grepped through /var/log/kern.log to find the kernel version that was running and got this: Linux version 3.2.0-53-generic (buildd@allspice) (gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #81-Ubuntu SMP Thu Aug 22 21:01:03 UTC 2013 (Ubuntu 3.2.0-53.81-generic 3.2.50) Also grep through kern.log for CPU and get: CPU0: Intel(R) Core(TM) i7-2675QM CPU @ 2.20GHz stepping 07 -- which I know to utilize 64-bit architecture. So to create the profile, I've installed a virtual machine running Ubuntu 12.04.3X64 and the identical kernel version: 3.2.0-53-generic. I have a different processor core on the virtual machine Im using to build the profile (Intel i5-4288U @ 2.60 GHZ, perhaps this is part of the problem?) I followed the instructions to a T on generating modules.dwarf using the included volatility toolset, copying the Systems.map file, zipping them together, etc. Run the required python vol.py --info | grep Linux Volatility Foundation Volatility Framework 2.4 Linux3_2_0-52-genericX_64x64 - A Profile for Linux 3.2.0-52-genericX_64 x64 Linux4cpuprofilex64 - A Profile for Linux 4cpuprofile x64 LinuxUbuntu12_04_3x86 - A Profile for Linux Ubuntu12_04_3 x86 LinuxUbuntu_12_04_3_X64x64 - A Profile for Linux Ubuntu_12_04_3_X64 x64 Linuxkernel-3_2_0-52-genericx86 - A Profile for Linux kernel-3.2.0-52-generic x86 and all seems well. (The LinuxUbuntu_12_04_3_X64x64 is for kernel 3.2.0-53-generic) Now when I run the following with -dd flag for debug I get the following (Sorry for length of debug msg) python vol.py -f memdump.dd --profile=LinuxUbuntu_12_04_3_X64x64 -dd linux_pslist Volatility Foundation Volatility Framework 2.4 DEBUG : volatility.plugins.overlays.linux.linux: Ubuntu_12_04_3_X64: Found dwarf file System.map-3.2.0-53-generic with 573 symbols DEBUG : volatility.plugins.overlays.linux.linux: Ubuntu_12_04_3_X64: Found system file System.map-3.2.0-53-generic with 1 symbols DEBUG : volatility.obj : Applying modification from BashHashTypes DEBUG : volatility.obj : Applying modification from BashTypes DEBUG : volatility.obj : Applying modification from BasicObjectClasses DEBUG : volatility.obj : Applying modification from ELF32Modification DEBUG : volatility.obj : Applying modification from ELF64Modification DEBUG : volatility.obj : Applying modification from ELFModification DEBUG : volatility.obj : Applying modification from HPAKVTypes DEBUG : volatility.obj : Applying modification from LimeTypes DEBUG : volatility.obj : Applying modification from LinuxTruecryptModification DEBUG : volatility.obj : Applying modification from MachoModification DEBUG : volatility.obj : Applying modification from MachoTypes DEBUG : volatility.obj : Applying modification from MbrObjectTypes DEBUG : volatility.obj : Applying modification from VMwareVTypesModification DEBUG : volatility.obj : Applying modification from VirtualBoxModification DEBUG : volatility.obj : Applying modification from LinuxIntelOverlay DEBUG : volatility.obj : Applying modification from LinuxKmemCacheOverlay DEBUG : volatility.plugins.overlays.linux.linux: Requested symbol cache_chain not found in module kernel DEBUG : volatility.obj : Applying modification from LinuxMountOverlay DEBUG : volatility.obj : Applying modification from LinuxObjectClasses DEBUG : volatility.obj : Applying modification from LinuxOverlay DEBUG : volatility.plugins.overlays.linux.linux: Ubuntu_12_04_3_X64: Found dwarf file System.map-3.2.0-53-generic with 573 symbols DEBUG : volatility.plugins.overlays.linux.linux: Ubuntu_12_04_3_X64: Found system file System.map-3.2.0-53-generic with 1 symbols DEBUG : volatility.obj : Applying modification from BashHashTypes DEBUG : volatility.obj : Applying modification from BashTypes DEBUG : volatility.obj : Applying modification from BasicObjectClasses DEBUG : volatility.obj : Applying modification from ELF32Modification DEBUG : volatility.obj : Applying modification from ELF64Modification DEBUG : volatility.obj : Applying modification from ELFModification DEBUG : volatility.obj : Applying modification from HPAKVTypes DEBUG : volatility.obj : Applying modification from LimeTypes DEBUG : volatility.obj : Applying modification from LinuxTruecryptModification DEBUG : volatility.obj : Applying modification from MachoModification DEBUG : volatility.obj : Applying modification from MachoTypes DEBUG : volatility.obj : Applying modification from MbrObjectTypes DEBUG : volatility.obj : Applying modification from VMwareVTypesModification DEBUG : volatility.obj : Applying modification from VirtualBoxModification DEBUG : volatility.obj : Applying modification from LinuxIntelOverlay DEBUG : volatility.obj : Applying modification from LinuxKmemCacheOverlay DEBUG : volatility.plugins.overlays.linux.linux: Requested symbol cache_chain not found in module kernel DEBUG : volatility.obj : Applying modification from LinuxMountOverlay DEBUG : volatility.obj : Applying modification from LinuxObjectClasses DEBUG : volatility.obj : Applying modification from LinuxOverlay Offset Name Pid Uid Gid DTB Start Time ------------------ -------------------- --------------- --------------- ------ ------------------ ---------- DEBUG : volatility.utils : Voting round DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.macho.MachOAddressSpace'> DEBUG1 : volatility.utils : Failed instantiating MachOAddressSpace: mac: need base DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.lime.LimeAddressSpace'> DEBUG1 : volatility.utils : Failed instantiating LimeAddressSpace: lime: need base DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.hibernate.WindowsHiberFileSpace32'> DEBUG1 : volatility.utils : Failed instantiating WindowsHiberFileSpace32: No base Address Space DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.crashbmp.WindowsCrashDumpSpace64BitMap'> DEBUG1 : volatility.utils : Failed instantiating WindowsCrashDumpSpace64BitMap: No base Address Space DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.vmem.VMWareMetaAddressSpace'> DEBUG1 : volatility.utils : Failed instantiating VMWareMetaAddressSpace: No base Address Space DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.crash.WindowsCrashDumpSpace64'> DEBUG1 : volatility.utils : Failed instantiating WindowsCrashDumpSpace64: No base Address Space DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.hpak.HPAKAddressSpace'> DEBUG1 : volatility.utils : Failed instantiating HPAKAddressSpace: No base Address Space DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.elfcoredump.VirtualBoxCoreDumpElf64'> DEBUG1 : volatility.utils : Failed instantiating VirtualBoxCoreDumpElf64: No base Address Space DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.vmware.VMWareAddressSpace'> DEBUG1 : volatility.utils : Failed instantiating VMWareAddressSpace: No base Address Space DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.elfcoredump.QemuCoreDumpElf'> DEBUG1 : volatility.utils : Failed instantiating QemuCoreDumpElf: No base Address Space DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.crash.WindowsCrashDumpSpace32'> DEBUG1 : volatility.utils : Failed instantiating WindowsCrashDumpSpace32: No base Address Space DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.amd64.AMD64PagedMemory'> DEBUG1 : volatility.utils : Failed instantiating AMD64PagedMemory: No base Address Space DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.intel.IA32PagedMemoryPae'> DEBUG1 : volatility.utils : Failed instantiating IA32PagedMemoryPae: No base Address Space DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.intel.IA32PagedMemory'> DEBUG1 : volatility.utils : Failed instantiating IA32PagedMemory: No base Address Space DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.osxpmemelf.OSXPmemELF'> DEBUG1 : volatility.utils : Failed instantiating OSXPmemELF: No base Address Space DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.standard.FileAddressSpace'> DEBUG : volatility.utils : Succeeded instantiating <volatility.plugins.addrspaces.standard.FileAddressSpace object at 0x7fe1d90> DEBUG : volatility.utils : Voting round DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.macho.MachOAddressSpace'> DEBUG1 : volatility.utils : Failed instantiating MachOAddressSpace: MachO Header signature invalid DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.lime.LimeAddressSpace'> DEBUG1 : volatility.utils : Failed instantiating LimeAddressSpace: Invalid Lime header signature DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.hibernate.WindowsHiberFileSpace32'> DEBUG1 : volatility.utils : Failed instantiating WindowsHiberFileSpace32: PO_MEMORY_IMAGE is not available in profile DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.crashbmp.WindowsCrashDumpSpace64BitMap'> DEBUG1 : volatility.utils : Failed instantiating WindowsCrashDumpSpace64BitMap: Header signature invalid DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.vmem.VMWareMetaAddressSpace'> DEBUG1 : volatility.utils : Failed instantiating VMWareMetaAddressSpace: VMware metadata file is not available DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.crash.WindowsCrashDumpSpace64'> DEBUG1 : volatility.utils : Failed instantiating WindowsCrashDumpSpace64: Header signature invalid DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.hpak.HPAKAddressSpace'> DEBUG1 : volatility.utils : Failed instantiating HPAKAddressSpace: Invalid magic found DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.elfcoredump.VirtualBoxCoreDumpElf64'> DEBUG1 : volatility.utils : Failed instantiating VirtualBoxCoreDumpElf64: ELF Header signature invalid DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.vmware.VMWareAddressSpace'> DEBUG1 : volatility.utils : Failed instantiating VMWareAddressSpace: Invalid VMware signature: 0xffffffff DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.elfcoredump.QemuCoreDumpElf'> DEBUG1 : volatility.utils : Failed instantiating QemuCoreDumpElf: ELF Header signature invalid DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.crash.WindowsCrashDumpSpace32'> DEBUG1 : volatility.utils : Failed instantiating WindowsCrashDumpSpace32: Header signature invalid DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.amd64.AMD64PagedMemory'> DEBUG1 : volatility.obj : None object instantiated: Unable to read_long_long_phys at 0xfffff8104eff0L DEBUG1 : volatility.utils : Failed instantiating AMD64PagedMemory: Failed valid Address Space check DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.intel.IA32PagedMemoryPae'> DEBUG1 : volatility.utils : Failed instantiating IA32PagedMemoryPae: Incompatible profile LinuxUbuntu_12_04_3_X64x64 selected DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.intel.IA32PagedMemory'> DEBUG1 : volatility.utils : Failed instantiating IA32PagedMemory: Incompatible profile LinuxUbuntu_12_04_3_X64x64 selected DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.osxpmemelf.OSXPmemELF'> DEBUG1 : volatility.utils : Failed instantiating OSXPmemELF: ELF Header signature invalid DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.standard.FileAddressSpace'> DEBUG1 : volatility.utils : Failed instantiating FileAddressSpace: Must be first Address Space DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.arm.ArmAddressSpace'> DEBUG1 : volatility.obj : None object instantiated: Could not read_long_phys at offset 0x3ffffffff070L DEBUG1 : volatility.obj : None object instantiated: Could not read_long_phys at offset 0x3ffffffff040L DEBUG1 : volatility.obj : None object instantiated: No suggestions available DEBUG1 : volatility.utils : Failed instantiating ArmAddressSpace: Failed valid Address Space check No suitable address space mapping found Tried to open image as: MachOAddressSpace: mac: need base LimeAddressSpace: lime: need base WindowsHiberFileSpace32: No base Address Space WindowsCrashDumpSpace64BitMap: No base Address Space VMWareMetaAddressSpace: No base Address Space WindowsCrashDumpSpace64: No base Address Space HPAKAddressSpace: No base Address Space VirtualBoxCoreDumpElf64: No base Address Space VMWareAddressSpace: No base Address Space QemuCoreDumpElf: No base Address Space WindowsCrashDumpSpace32: No base Address Space AMD64PagedMemory: No base Address Space IA32PagedMemoryPae: No base Address Space IA32PagedMemory: No base Address Space OSXPmemELF: No base Address Space MachOAddressSpace: MachO Header signature invalid LimeAddressSpace: Invalid Lime header signature WindowsHiberFileSpace32: PO_MEMORY_IMAGE is not available in profile WindowsCrashDumpSpace64BitMap: Header signature invalid VMWareMetaAddressSpace: VMware metadata file is not available WindowsCrashDumpSpace64: Header signature invalid HPAKAddressSpace: Invalid magic found VirtualBoxCoreDumpElf64: ELF Header signature invalid VMWareAddressSpace: Invalid VMware signature: 0xffffffff QemuCoreDumpElf: ELF Header signature invalid WindowsCrashDumpSpace32: Header signature invalid AMD64PagedMemory: Failed valid Address Space check IA32PagedMemoryPae: Incompatible profile LinuxUbuntu_12_04_3_X64x64 selected IA32PagedMemory: Incompatible profile LinuxUbuntu_12_04_3_X64x64 selected OSXPmemELF: ELF Header signature invalid FileAddressSpace: Must be first Address Space ArmAddressSpace: Failed valid Address Space check The error must have something to do with the way that I'm generating the profile (at least I think something is off) but I can't for the life of me figure out what the problem is. I truly appreciate any light that a vol expert out there may able to shed on what I need to do differently. Thanks very much.

10 years, 7 months

2
5
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Vol-users