I'm the technical editor for an awesome book that will be coming out in 2014, entitled "The Art of Memory Forensics: Detecting Malware and Threats in Windows, Linux, and Mac Memory". Authors are Michael Hale Ligh, Andrew Case, Jamie Levy, and AAron Walters. The book covers both basic and advanced memory analysis using the Volatility framework and from what I've seen so far, will be a thriller for anyone interested in deep memory analysis, live forensics, and malware analysis.
Pre-order is available on Amazon now--watch for it and be sure to pick up a copy if you're interested in memory forensics, operating systems internals, reverse engineering and/or malware analysis (or, if you just want to plop it on your coffee table and impress your friends).
Link: Amazon.
Digital forensics, reverse engineering, malware, benevolent hacking, cooking, photography, gardening, and life in New Orleans.
Monday, December 23, 2013
Analyzing Compressed RAM in Mac OS X (and Linux)
The compressed RAM facility in Mac OS X Mavericks places a RAM compressor inline and in front of page swapping in the virtual memory implementation, favoring compressing pages of RAM over swapping them to disk. In Mac OS X, page compression/decompression are handled by a custom, hand-optimized 64-bit assembler version of WKdm.
My Mavericks-compatible Python port of WKdm is done and I'm busy building the plugins to allow analysis of compressed RAM from Mac OS X memory dumps in Volatility.
+Andrew Case is helping with the Volatility integration, since we want support for decompressing pages to be as transparent as possible across various operating systems that implement compression. He's also tackling the Linux side, which uses a different set of compression algorithms.
I'll be releasing everything and talking about this project at the American Academy of Forensic Sciences (AAFS) meeting in Seattle in Feb 2014. Hope to see you there.
Update (12/26/2013):
The Volatility plugins are now decompressing compressed RAM pages properly--currently, we're just dumping all the pages, but Andrew and I will integrate the decompression more tightly soon so that, e.g., process memory dumps for Mac OS X will also dump available compressed pages.
Update (12/27/2013):
I was curious if Apple's choice to do a custom assembler version of WKdm compression/decompression was worth it. It definitely was--the hand-optimized assembler version, which eliminates all function calls and takes the WKdm stuff down to its bare essentials, smokes the original C version. On a Core i7, with gcc and -O3:
Assembler timing: 268317 compression / decompression pairs per second.
C timing: 142150 compression / decompression pairs per second.
And, of course, there's the Python version we'll be using in the Volatility plugins:
Python timing: 391 compression / decompression pairs per second.
My Mavericks-compatible Python port of WKdm is done and I'm busy building the plugins to allow analysis of compressed RAM from Mac OS X memory dumps in Volatility.
+Andrew Case is helping with the Volatility integration, since we want support for decompressing pages to be as transparent as possible across various operating systems that implement compression. He's also tackling the Linux side, which uses a different set of compression algorithms.
I'll be releasing everything and talking about this project at the American Academy of Forensic Sciences (AAFS) meeting in Seattle in Feb 2014. Hope to see you there.
Update (12/26/2013):
The Volatility plugins are now decompressing compressed RAM pages properly--currently, we're just dumping all the pages, but Andrew and I will integrate the decompression more tightly soon so that, e.g., process memory dumps for Mac OS X will also dump available compressed pages.
Update (12/27/2013):
I was curious if Apple's choice to do a custom assembler version of WKdm compression/decompression was worth it. It definitely was--the hand-optimized assembler version, which eliminates all function calls and takes the WKdm stuff down to its bare essentials, smokes the original C version. On a Core i7, with gcc and -O3:
Assembler timing: 268317 compression / decompression pairs per second.
C timing: 142150 compression / decompression pairs per second.
And, of course, there's the Python version we'll be using in the Volatility plugins:
Python timing: 391 compression / decompression pairs per second.
Sigh.
Update (1/2/2014):
Just for fun, I ported the Python version to go--in about an hour.
Go timing: 59880 compression / decompression pairs per second. Basically, go rocks, and is my new language of choice. If you haven't checked it out, do.
Update (1/23/2014):
Getting the Volatility plugins to handle decompression of pages for address spaces of individual processes took some effort, but that stuff is now working. More detail on everything coming soon once I do some cleanup.
Update (4/19/2014):
Our paper describing this work, entitled "In Lieu of Swap: Analyzing Compressed RAM in Mac OS X and Linux" was accepted for publication at DFRWS 2014 in Denver. See you in August!
Update (1/2/2014):
Just for fun, I ported the Python version to go--in about an hour.
Go timing: 59880 compression / decompression pairs per second. Basically, go rocks, and is my new language of choice. If you haven't checked it out, do.
Update (1/23/2014):
Getting the Volatility plugins to handle decompression of pages for address spaces of individual processes took some effort, but that stuff is now working. More detail on everything coming soon once I do some cleanup.
Update (4/19/2014):
Our paper describing this work, entitled "In Lieu of Swap: Analyzing Compressed RAM in Mac OS X and Linux" was accepted for publication at DFRWS 2014 in Denver. See you in August!
Thursday, December 19, 2013
Python: Yes, that indentation thing again
No, I'm not going to get over it.
These: { }
rock.
And Python clearly rocks, too--because if you accidentally hit tab a few times, or your cat dances on your keyboard, or you fall asleep and your forehead starts typing, why wouldn't you want to have to carefully read the code again to fix it, instead of just re-indenting the code automatically (possible in sane languages, because, surprise! That's what explicit bracketing allows!)
Please don't suggest that it's always an awesome idea to re-understand code to fix indentation. I'm porting some complicated compression code from C, and frankly, once it works, I don't want to have to understand it again if I paste it, or forehead it. Or whatever.
The "white space is significant" thing was tried in the past, and failed. It's a stupid idea. COBOL had an excuse, but we're not using punchcards anymore.
COBOL whitespace: fail.
SNOBOL whitespace: fail.
Python significant whitespace and no bracketing for code blocks: huge fail, because it's 2013, not 1950.
It's an awesome language in terms of expressiveness, but the lack of bracketing is 100% fail. Fine, it's 90% fail. That combined with slow and broken threading means it's a huge missed opportunity.
Will I write Python to contribute to projects that use it? Of course.
Will I voluntarily use Python for other projects? Maybe. Not if I can help it. OK, I'm not sure. Obviously I'm torn. But are there really great alternatives? Perl is a broken mess. Ruby's threading needs help, too. I love C and in some sense its my "native language", but can you really imagine writing a framework like Volatility in C?
These: { }
are awesome.
Proper threading:
is essential. Modern hardware insists. And we should listen.
And yes, I know about Whython. But it's just a toy and it's really too late, right? Because portability for security tools is essential.
Maybe I just need a glass of wine.
These: { }
rock.
And Python clearly rocks, too--because if you accidentally hit tab a few times, or your cat dances on your keyboard, or you fall asleep and your forehead starts typing, why wouldn't you want to have to carefully read the code again to fix it, instead of just re-indenting the code automatically (possible in sane languages, because, surprise! That's what explicit bracketing allows!)
Please don't suggest that it's always an awesome idea to re-understand code to fix indentation. I'm porting some complicated compression code from C, and frankly, once it works, I don't want to have to understand it again if I paste it, or forehead it. Or whatever.
The "white space is significant" thing was tried in the past, and failed. It's a stupid idea. COBOL had an excuse, but we're not using punchcards anymore.
COBOL whitespace: fail.
SNOBOL whitespace: fail.
Python significant whitespace and no bracketing for code blocks: huge fail, because it's 2013, not 1950.
It's an awesome language in terms of expressiveness, but the lack of bracketing is 100% fail. Fine, it's 90% fail. That combined with slow and broken threading means it's a huge missed opportunity.
Will I write Python to contribute to projects that use it? Of course.
Will I voluntarily use Python for other projects? Maybe. Not if I can help it. OK, I'm not sure. Obviously I'm torn. But are there really great alternatives? Perl is a broken mess. Ruby's threading needs help, too. I love C and in some sense its my "native language", but can you really imagine writing a framework like Volatility in C?
These: { }
are awesome.
Proper threading:
is essential. Modern hardware insists. And we should listen.
And yes, I know about Whython. But it's just a toy and it's really too late, right? Because portability for security tools is essential.
Maybe I just need a glass of wine.
Labels:
bracketing,
cobol,
moving on,
python,
snobol,
whitespace
Tuesday, December 10, 2013
New website
I completely redesigned my website, which is one of the oldest in New Orleans, coming up in 1994, when people were asking WW-what? Unfortunately, the previous design looked about that old, too.
So here's to something fresher.
http://www.cs.uno.edu/~golden
Cheers,
--Golden
So here's to something fresher.
http://www.cs.uno.edu/~golden
Cheers,
--Golden
Thursday, December 5, 2013
Upcoming talks and tutorials
I'm giving a talk on Friday, December 6th at Tulane University on digital forensics research, practice, and privacy in Stanley-Thomas Room 302 at 3pm.
On Monday, December 9th I'll give a tutorial on introductory malware reverse engineering at ACSAC 2013 in New Orleans. My tutorial is M3.
Hope to see some of you there.
Cheers,
--Golden
On Monday, December 9th I'll give a tutorial on introductory malware reverse engineering at ACSAC 2013 in New Orleans. My tutorial is M3.
Hope to see some of you there.
Cheers,
--Golden
Labels:
ACSAC,
new orleans,
reverse engineering,
talk,
tutorial
Friday, November 29, 2013
Cajun Dirty Rice (Golden's take)
Cajun Dirty Rice (Golden's take)
Serves 6-10Prerequisites:
o Heavy cast iron skillet: If you don't have this, cook something
else. Everything will stick, you'll be unhappy, and my car tires are
at stake, right?
o Homemade stock: You can either make it in conjunction with the dirty
rice, particularly if you're serving with, e.g., a whole duck, because
you can steal the wings and neck, or use previously prepared stock.
You'll need at least a quart.
o Patience: Drink a glass of wine or two while you make it. It takes
time and your attention. Not suitable for "occasionally check on it
while I catch up on Green Acres episodes."
CAYENNE NOTES:
I start with 2t if there are guests that just really can't enjoy spicy
food. 3t (as specified) will light you up a bit, but not kill anyone.
4t is better, but then things get seriously spicy and you may
"disable" spice-wimp guests.
STOCK NOTE:
If you don't have any stock, and are also cooking, e.g., a duck, make
stock using carrots, celery, onions, garlic, duck wings and neck, and
use about double the amount of gizzards below (i.e., 1 lb of gizzards)
for the stock. No duck? Use chicken wings, necks, etc. Remove 1/2
pound of the gizzards after 20 mins and set these aside for use in the
dirty rice. Leave the rest in and simmer your stock for two hours or
more, then strain and keep heated.
Seasoning mix:
3 teaspoons ground red pepper (cayenne)
3 teaspoons salt (more to taste at the end)
3 teaspoons freshly ground black pepper
1 teaspoon dried thyme
1 teaspoon dried oregano
3 teaspoons paprika
2 teaspoons dry mustard
2 teaspoons ground cumin
Put all spices into a bowl and mash and mix with a spoon until
thoroughly combined.
Other ingredients:
1 pound ground pork
6 bay leaves
0.5 pounds chicken gizzards, simmered for 20 minutes, then
ground in food processor (SEE NOTE ABOVE ON STOCK!)
2 bunches green onions, chopped fine
6 stalks celery, chopped fine
1 large bell pepper, chopped fine
6 cloves garlic, chopped fine
0.5 sticks unsalted butter
1 quart chicken or duck stock, kept just below a boil
1.5 cups rice (basmati, Jazzmen, or other long grain rice)
0.5 pounds chicken livers, liquified in food processor
In a large cast iron skillet over high heat, cook ground pork and bay
leaves until some fat is released, then add gizzards and cook until
pork is browned, stirring to avoid burning. Stir in seasoning mix, mix
throughly and cook for a few minutes until aromas are released, then
add butter, green onions, celery, bell peppers, and garlic. Cook over
medium heat until vegetables are soft and beginning to caramelize.
Add the rice and mix well.
The rest is finished very much like risotto. Heat should be medium.
Add a small quantity of stock (a cup or so at first, with the amount
reducing as you repeat) and stir (keep stirring!) until almost
completely absorbed. Stir in the chicken livers when you get about
1/2 through the quart of stock. Repeat, until rice is cooked but
still firm. Mushy dirty rice is death.
Remove from heat, allow to rest so the temperature reduces a bit and
everything "gels", stir a few times, and serve.
Labels:
cajun cooking,
dirty rice,
Louisiana
Subscribe to:
Posts (Atom)