Saturday, February 2, 2019

I've stopped pretending...

In case it isn't obvious, I stopped pretending long ago that I have time to have a blog.  This may change.  Probably not.  If at some point the theme doesn't look like it was designed in 1994, then you'll know.

Otherwise, most other things really have changed and I'm here now if you want to catch up:  https://cct.lsu.edu/~golden

Sunday, March 15, 2015



Sign up and pass the word, please:

FREE cybersecurity training for high school teachers at the University of New Orleans this summer, funded by the National Science Foundation and NSA:

http://www.cs.uno.edu/~golden/intensive-ia-training.html

An interesting twist is that after our GenCyber training program last year was used to brief the NSA director on the concept, this year there will be a national publicity campaign with UNO as the spotlight program for delivering this training to teachers.

Space is limited, so apply early.

Thanks!

--G

Friday, April 18, 2014

Some pics from the AAFS 2014 Award Ceremony

Some pics from the AAFS 2014 Award ceremony.  In addition to being promoted to Fellow, I shared the 2013 Outstanding Research Award with Irfan Ahmed, for our presentation "Live Forensic Analysis of Kernel Code for Malware Detection in Cloud Computing Environments".




Thursday, December 26, 2013

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.

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.

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!


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.


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

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



Friday, November 29, 2013

Cajun Dirty Rice (Golden's take)

Cajun Dirty Rice (Golden's take)

Serves 6-10

Prerequisites:

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.

Wednesday, December 26, 2012

Unintended status lights and ill-advised GUIs

My Macbook Pro Retina is in the shop, after developing an "after market" power status light--namely, the right hand USB 3.0 port, which suddenly began to glow brightly.  Apparently something metallic got lodged in there and turned the port into a nightlight.  Amazingly, the machine still works fine, but the partially toasted port is a little worrisome, thus a trip for repair.  The end result is at least two weeks to go with operating systems I don't want to use and ones I do want to use that have grown bad user interfaces.

Windows 2000, XP, --> Windows 7 user interfaces are basically fine.  They're nothing special, but years of use yield a stalemate--not perfect, but it works, and what's the point of complaining, especially since I simply don't care about Windows at all, except to make money on taking it apart in forensics cases.  I'm through pretending Windows is good for simply getting work done--it isn't.  It's good for games, which I don't currently have time for, and it's good for running J River Media Center.  If there was a Mac port for J River and a rich uncle died, I'd be completely done and I can guarantee you that Windows 8 would never have gotten installed.  For getting real work done, I have Mac OS X and Linux.

The Mac OS X interface takes some getting used to, but humans are adaptable.  The fact that the interface is consistent and generally tightly integrated with applications is a good thing and most people who give it an honest try find that they're up to speed quickly and can then concentrate on getting work done, which for better or worse, is mostly what computers are for now.  The fact that the hardware is solid, even if it does come at a premium price, and the platform has great software support while providing a solid Unix backbone, is fantastic.

Unfortunately, Linux has had yet another go at becoming the widely used desktop OS it isn't ever going to be.  I love Linux for hacking and it's my first choice for programming.  But mainstream application support sucks, it's always going to, and that's that.  Linux has about as much chance as becoming the desktop OS of choice as Windows 8 phones do of mattering at all in a world of Android and iOS:  zero.  So breaking what were reasonable and simple Linux desktop GUIs in some attempt to create a bastardized Mac OS X environment was a huge mistake.  The simplicity and usability are gone, and replaced with crap like Unity, which clearly shows what Mac OS X would look like without proper application integration.  So going "back" to GNOME seems like a reasonable option, except that there's bad mojo here too.  For example, why would anything think it's a good idea to disappear the minimize and maximize buttons?  If you want to use the left click/middle click functionality to maximize and minimize, etc., fine, but were the familiar buttons for managing windows that everyone uses on every available desktop OS really so offensive that they had to go, only to force users to discover how to re-enable them?  It smacks of change for the sake of change, not improvement.

Change is good--I'm not some old curmudgeon pining for his TRS-80 with a homebrew 64K upgrade and a $600 floppy drive--although I occasionally miss it the mystery of those days.  But simply changing things to make some artistic statement, that ultimately is simply irritating to users and gets in the way of them getting work done is, well, not special, in my view.


Wednesday, September 5, 2012

Macbook Pro w/ Retina Display

My Macbook Pro recently arrived and while I'll miss the slightly smaller form factor of the Macbook Air, it essentially addresses all of my concerns with the Air (and unfortunately adds another, non-Air concern).  Not having resigned myself yet to sloth, receding hairlines, and a thickening gut (thanks, skateboarding), I can deal with a pound or so of extra weight.

Read the reviews--the machine is super fast and the display is fantastic--almost.  Having paid $1300 to upgrade the Macbook Air's SSD, the 768GB option in the Macbook Pro is fantastic, as is having 16GB of RAM and better virtualization support because of the up-to-date i7 processor.

For viewing photos, etc. the new display is absolutely spectacular.  The one issue--and my only complaint at all about this otherwise "best ever" laptop--is the glossy display.  It attracts reflections like fruit flies on day old watermelon and mars an otherwise amazing computer for people who like a shades-up lifestyle. Luckily, the keyboard is backlit--plan on working in the dark or with the windows closed when the reflections loom.

Wednesday, July 20, 2011

New Macbook Airs

The new Macbook Airs are released, along with Mac OS X Lion. If you don't already have one, my recommendation stands--it was and is a brilliant machine. But for upgrades--and I was ready to pull the trigger on a new one--FAIL. The machine needs 8GB of RAM. I burned goats, stared at the night sky, fed the hungry, but the new Air still tops out at 4GB.

Sorry, it's not enough. My road warrior machine needs to run a bunch of OS's under virtualization, sometimes at the same time. The lack of an 8GB option is a fail. Maybe next time. And since I have to wait, I also need a 512GB SSD. Thanks.

Friday, December 10, 2010

Macbook AIr




I'm not a Mac fanboy, but the Macbook Air is amazing. Because of a few projects I'm working on, I needed a new Mac and wanted something as light as possible, because I'll often have to lug it along with my daily warrior, a loaded and SSD-ed Thinkpad T400s.

First, the Air is an amazing engineering feat. You've seen the pictures, but until you hold it, it's hard to really imagine how thin this laptop is. I don't have any rigorous performance numbers, but those upset by the use of a Core2 chip instead of one of the newer i5/i7 chips can relax--for virtually anything you'll use this laptop for (barring extreme 3D games, I presume, though I haven't checked out the performance and don't intend to use it for that), it's plenty fast. Lightroom rendered images very quickly, applications open instantly, reboot is blazing, it's very responsive in every situation I've encountered.

It's not perfect, of course. Where (Apple) are the home and end keys? How about pgup and pgdn? I know--Fn-arrow. And del? Yeah, Fn-delete. I want keys. I'm not thrilled with gigabit over USB. I would love a builtin VGA port for presentations so I don't have to lug a dongle, but where would it go? There's not a single spot where the laptop is as thick as a VGA plug. I would have liked 8GB of RAM (I make heavy use of virtualization). But overall, this is one sweet laptop and highly recommended if you need a lightweight Mac solution.

Wednesday, September 29, 2010

Concert photography

I now have a website dedicated to concert photography. Have a look at http://www.highisomusic.com if you're interested.

John Cage

Somehow, I never paid attention. Now I'm listening to his "prepared piano" music, which is brilliant...and startling. A must listen if you like the tension created by silence in music (i.e., not to draw too close a comparison, but if you hate Thelonious Monk, you might not like it). The CDs are:




I came across the music while watching Shutter Island and at first thought the pieces had been composed for the movie, because they worked beautifully to create tension in some of the "scary" parts. Have a listen.

Wednesday, July 14, 2010

RECON 2010

I'm back in Montreal for a month (after disappearing from Quebec for 8, after my sabbatical ended) and the highlight so far is RECON 2010. I've tried to attend in the past, but timing never worked out. This year I made it and I offer the following comments:

The talks are outstanding. The schedule is exhausting, particularly since the talks are outstanding and it's difficult to walk away from any of the talks to rest. It's a conference for those with 20 year old stamina (I'm 45, but have 25 year old stamina--almost good enough). The beer was good. The hotel almost caught on fire while I was in the shower. Note: If you hear faint beeping sounds while in a Canadian hotel, that might be the fire alarm. I hardly noticed, and it took a call from my wife to send me rushing down the stairs, barefoot. I always wanted to walk down a main street in Montreal barefooted, so my dream was fulfilled.

Sebastian Porst talked about obfuscating malicious payloads in PDF and zynamics has a new tool that's worth checking out called PDF Dissector.

Danny Quist (founder of offensivecomputing.net) talked about some extensions to Ether (which itself is a set of patches to Xen to support malware analysis via hardware virtualization). Danny also showed off some very nice visualisation techniques for understanding execution flow during malware unpacking. His stuff is set for release in 2011(?). Check out the Ether page here. This was a great talk and will hopefully open up some avenues for collaboration, because my research group at UNO is also working on live forensics/malware detection and mitigation via VM introspection.

Ricky Lawshae (from BreakingPoint in Austin) discussed "picking" electronic locks using sequence number prediction. Yes, channelling Mitnick-style attacks into 2010. Now I'll have to stop telling my students that sequence number attacks are "so yesterday"...

There were also talks on picking (and destroying) physical locks, 8-bit/16-bit hardware hacking, reverse engineering embedded systems, deep looks at the obfuscation schemes of some recent malware (Swizzor and Mebroot), porting Syndicate (one of my favorite games in grad school) to modern architectures, building a router from scratch for SDSL service, and others. Check out everything at RECON.

RECON is moving to an annual schedule, so be sure to check it out in 2011. Attendance is limited, so register early once for 2011 that's possible.

Friday, July 31, 2009

Teaching Reverse Engineering

I'm presenting a paper at the Cyber Experimenation and Test (CSET 2009) workshop, held in conjunction with USENIX Security 2009, on teaching reverse engineering in academia. I'm also presenting a two day tutorial on reverse enegineering for USENIX Security, which is a condensation to bare essentials of the semester-long class on reverse engineering that I teach at the University of New Orleans.

There are a few very important challenges in teaching reverse engineering in an academic setting:

The first is that students will likely show up with poor assembly skills. This is because assembly language courses, if they exist at all as separate courses in a curriculum, are typically full of things that do not help students become better systems people. While High Level Assembler (which drapes assembler in macros that give it a flavor more like a high level language) might be a good idea for development of large scale applications in assembler, it hides details that students *should* be immersed in when learning assembly language. The pain, the attention to myriad minute details, complex interaction with hardware features, et al are essential. For systems research, the devil really is in the details. The punchline is that students will essentially have to be taught deep assembly skills while learning reverse engineering, all in a single semester, which creates important time constraints. More on this below.

Another challenge is not only teaching students about the potential legal ramifications of reverse engineering, but also avoiding these same legal hurdles while teaching the course. In my case, the class is focused exclusively on the analysis of malware, which relieves many of the legal issues, but adds yet another dimension, that of safety for the academic computing environment. My solution is to carefully screen the malware samples that will be analyzed by students in the lab. Since my approach to teaching this course involves detailed walkthroughs of assembler for each malware sample, I have to do exhaustive analysis of the effects of the malware, anyway. As further protection, the laboratory environment consists of an isolate-able gigabit network connecting workstations running Linux and VMWare. Preconfigured Windows XP guests under VMWare are used for most analysis and the guests typically have networking disabled as a safety precaution. The XP VMWare images contain a licensed version of IDA Pro, ollydbg, WinHex, HBGary's Responder, the sysinternals tools, as well as other tools. In the next iteration of the class, we will also use BinDiff and BinNavi.

In the reverse engineering class, I'm not interested in having students learn what reverse engineering is. I want them to be able to *do* reverse engineering. This rules out the traditional academic format of flipping Powerpoint slides and giving exams. The approach I've used for the class, to deal with the fact that students must gain good assembly skills while learning reverse engineering, all in a single semester, is to immerse them immediately in the analysis of real malware samples. The malware that we analyze in the class and in laboratory assignments increases in difficulty as the semester progresses and each sample is chosen to push the students a little harder and to force them to gain more systems knowledge in order to succeed.
An essential component of the class is reliance on a document camera for in-depth walkthroughs of every malware sample, in class. I drive the discussion, but students are expected to participate and what results is a very deep analysis of each sample, which is then distributed to all of the students.

More details on the class and my approach to teaching it can be found in my CSET paper, which is here.

Monday, July 20, 2009

Celeriac

Imagine my surprise (or don't) when I discovered that celery was once a delicacy, and special dishware was created to display your prized vegetable. While I dutifully chop celery for traditional Creole and Cajun recipes, I've never been a huge fan. Enter celeriac. It's not very popular in the US, but the corner store near my apt in Montreal sells celeriac, so I had to give it a try. I've made it several ways, including diced and quickly sauteed in olive oil with fresh sage leaves as well as in a root vegetable mash, with Yukon gold potatoes, olive oil, thyme, sea salt, freshly ground pepper, some chicken stock, and a slosh of whole milk. It's also good raw. Celeriac is yummy, very healthy, and deserves a higher profile on our tables. Here's to one of my new favorite vegetables.

Here's a photo of the celeriac mash:



Salut.

Friday, June 5, 2009

GNOCIA Approved by the Board of Regents

The Greater New Orleans Center for Information Assurance (GNOCIA), housed in the Department of Computer Science at the University of New Orleans, was just approved by the Louisiana Board of Regents! I will serve as the first director of GNOCIA. The center will focus on digital forensics, malware, and reverse engineering research and will enhance UNO's ability to partner with industry, academia, and government agencies on important projects in these areas. The University of New Orleans has offered a substantial committment to equip the center with state-of-the-art equipment.

Wednesday, May 20, 2009

Every Kitchen Needs...

o Top quality ventilation. My exhaust fan is the size of a small volkswagen.

o A long-handled whisk. OK, several of them.

o Lots of seasoned cast iron.

o A freezer full of homemade stock. Nothing else goes in the freezer except ice cubes and ice cream. Ban the nasty bouillon cubes, man.

o A terrifyingly sharp chef's knife.

o Orange extract.

o Olive oil. Lots of olive oil.

o An open bottle of Gigondas. Or, if you're buying, Chateauneuf du Pape. And a wedge of delice de bourgogne.

There are a few other requirements, but we can mostly make do if these 'ingredients' are available.