Bryan Geraghty

Hey, have you opened a .sql file in vim and realized with great irritation that you cannot use the left and right arrow keys to navigate in insert mode? Well, here is how you fix it.

Add the following to your ~/.vimrc or ~/.vim/ftplugin/sql.vim file:

let g:omni_sql_no_default_maps = 1

Congratulations to Sebastian Vettel and Red Bull. Well done. Playing fair always pays off.

This is not good.

Unspecified vulnerability in Mozilla Firefox 3.5.x through 3.5.14 and 3.6.x through 3.6.11, when JavaScript is enabled, allows remote attackers to execute arbitrary code via unknown vectors, as exploited in the wild in October 2010 by the Belmoo malware.

National Vulnerability Database

via CVE-2010-3765.

The recent prevalence of this sort of browser bug is really disconcerting. I didn’t realize the severity of the problem until I recently investigated how one of these exploits work; and let me tell you, it’s not pretty. If the browser is hi-jacked, the web developer has essentially no control over what is happening after the page is loaded. For instance, you could visit your bank’s website and receive the actual web page served over SSL/TLS with a valid certificate. Then, the exploit steps in and over-loads (or creates) the JavaScript form handling function. From that point on, anything you enter in the form is known to the operator of the exploit.

With AJAX functionality becoming the norm, it’s also becoming more difficult to disable JavaScript in the browser and still enjoy your web browsing experience. On top of that, who knows whether JavaScript is actually disabled if the browser has been compromised?

Unfortunately, Mozilla is not the only one to blame here. Microsoft’s Internet Explorer, Google’s Chrome, and Apple’s Safari browsers have all had this type of vulnerability reported within the last few months. The other vulnerabilities may not have been exploitable by a “remote attacker”, but the exploit I mentioned was very successful as a local exploit. How many of you are certain you will be protected by a 0-Day exploit which then hi-jacks your browser? Remember, this is a user-space vulnerability; no root required here.

So this is a revelation for me. I’ve been a web-developer for 10 years and I always considered web applications relatively safe and secure when written and implemented properly. Unfortunately, the old axiom, “Nothing is secure”, remains true. The fact that a web site may be completely free of bugs and vulnerabilities (however unlikely that may seem) is completely negated by the fact that a web browser is required to interact with the application. And due to the nature of the Internet, the browser in use is mostly controlled by the user. I say mostly because web developers have some remedial tricks for detecting browsers but they can all be circumvented if the user has the technical prowess. Also, because they may be using a computer controlled by their employer where they may or may not have permission to use their browser of choice.

So ultimately, the security of the data passing between the user and the web application rests in the hands of the browser developer. We can do everything possible to “secure” the client machine and the web site, but if the browser is flawed, all is for naught.

Happy days.

A few weeks ago, I participated as a Red Team member in Cyber-Raid 0; a mock hack/defend event held in Kansas City. It was a fun event even if there were a few issues with how the rules were defined and enforced.

Teams

There were 4 teams of defenders (Blue Teams) which represented companies, and one big team of attackers (Red Team) continually attacking the Blue Teams.

Setup

Six networks were accessible by the Red Team, all connected by one Cisco ASA: one for the Red Team, one for each of the four Blue Teams, and one for the scoring server. The Red Team was responsible for providing all of their own equipment. Blue team members were responsible for providing a windows laptop with which they would manage their VSX servers. The infrastructure was provided by White Wolf Security and the entire game network was completely isolated from the internet… sort of ;)

Scoring

Blue Team scoring was handled by the score-bot connecting to services and verifying that they were running. If a service could not be contacted, points were added to the Blue Team responsible for that server. The objective of the Blue Teams was to keep their respective scores as low as possible. Red Team members scored points by executing the provided Phone-Home program on one of the Blue Team servers. The more points the Red Team scored, the better.

Rules

There were essentially no rules but to keep the game fun, a few simple rules were laid out: 1) No “layer-two shenanigans”. 2) Traffic cannot be blocked from the “WAN” based on source IP. 3) No communication between Red and Blue team members.

Replay

We were notified that some people who took part in this event did not want that information shared, so I will not include any identifying information in my recounting of events.

First thing in the morning was breakfast followed by a “Briefing” where the rules and concept of the game were laid out, followed by by questions. After that, the teams split into their respective rooms isolated from one another. The Blue Teams were given an hour to become familiar with their systems and we were given the addresses of our network, the Blue Teams’ class C networks, and the scoring server. We were given no other information about the target systems.

The first hiccup in the game came here: the Red Team could not connect to the scoring server because of a routing problem. Once the router was working as it was supposed to, each us registered our “Hacker Handle” and received an account on the scoring server from which we could download the Phone Home program.

Before we get to the action, I’ll start off by saying that the Red Team room was not very organized. A few teams showed up together and tended to work together but there were quite a few of us who arrived alone and sort of teamed-up based on who we were sitting near. This disorganization ultimately proved to be a extremely counterproductive in the long-run because we ended up working against each other.

Once everything was connected, I think everyone on the Red Team fired off a network scan. Me and the guys I was working with separated the networks up and started doing SYN scans with decoys which ended up working pretty well. We Identified a mix of about a dozen Windows and Debian servers on each of the networks. After we collected all of the host info, I started poking around with telnet on Blue Team 1′s network and… “WTF, I can’t connect to any of those services”. We tried talking with the organizers and explaining that the servers were inaccessible, but one of the helpers replied with some BS about clever techniques. Well, we would later find out that they added a blanket deny firewall policy to all traffic coming from the Red Team’s network. (Did you see rules #2?) If the Red Team had been more organized, we would have collaborated and realized that nobody could connect to the services and raised more of a fuss. So that was the state of the game for about half of the day. We sat around trying to hack the ASA server between us and them; ultimately getting nowhere.

Apparently, one of the groups on the Red Team had taken the more aggressive approach of just telling Metasploit to attack whatever it could find and got a phone-home script running in the moments before the Great Wall came down. Unfortunately, the scoring server was not working at the time, so no points were credited to them.

After the lunch break, things were looking brighter; Apparently, the game organizers had caught on to the shenanigans and told them to open up specific services; as would be the case in a real-world network. Well, it turns out that even though the incoming policies were opened up, outgoing traffic was still denied, so even when someone found a vulnerability, they couldn’t connect back and get a shell. In my opinion, that approach is perfectly reasonable. I highly recommend egress filtering of all but the necessary ports specifically for this reason. It is especially effective when you do filtering on either a VLAN or a host-by-host basis.

Finally, Some Progress

The first thing we managed to leverage was an “Open Source Application For Disaster Management”. When we first stumbled upon it, all of the security was disabled and we could plainly see the application’s configuration; including the database login credentials. Unfortunately, the Database server was not accessible from the “WAN”, so that didn’t go anywhere right away.

I continued exploring the application and found a few input sanitation vulnerabilities which occupied me until the end of day one. Ultimately, I was able to get a compressed malicious file uploaded to the server but couldn’t find the means to decompress it. I also wasted more time after I found a list of “flags” on the scoring server which you could use to earn points by acquiring key bits of sensitive information. What the organizers didn’t announce officially was that these flags were not working. So after trying a few with no success, I asked, and they confirmed that they were in fact, not working.

In the mean-time, some of the other Red Team groups discovered PHPMyAdmin running on a few of the servers. So that, combined with the login credentials from the “Open Source Application For Disaster Management”, the they had access to the MySQL database; including the ability to browse the local file system of the database server.

Lesson 1) Don’t run PHPMyAdmin on a server accessible via HTTP from a lower security zone than the DB server. (in case you didn’t already know)

What most of the Red Team didn’t know was that one of the smaller groups had managed to leverage the PHPMyAdmin avenue to get access to most of the servers on all of the networks and started racking up points. The first thing they did once they gained access to the MySQL server was to grab the /etc/passwd file, as most of the other groups did. Where they went one step further was, instead of discarding the file because shadow passwords were enabled, they scanned the list of user names looking for services. One of these user names stood out: nagios. Well, they found the Nagios server and tried the default password: nagios; Success! This proved to be the only successful avenue of scoring for the remainder of the game.

Lesson 2) Nagios needs an account for every service which needs to be checked and those user names/passwords are stored in plain-text. If someone gets into it, they get into everything. (in case you didn’t already know)

Day 2

Well, day two was a bit of a disappointment because a lot of the Blue Team members didn’t show up and two of the networks were completely down. This meant that there were only two instances of any given service running; including the one I was investigating. Remember the “Open Source Application For Disaster Management”? Well, I had download the source code and was looking for vulnerabilities. Unfortunately, one of Blue Teams realized that the MySQL service had been compromised and they changed the password which left the application crippled in a “Can’t connect to the database” state. I still don’t know if they had point scored against them for this because the score-bot would just be checking whether it could connect to the service or not. So this left one more instance of the “Open Source Application For Disaster Management” running. And just as I was about to test a vulnerability that I found, the database for that service disappeared; someone had inadvertently deleted it; another case of disorganization. From then on, with about 3 hours left in the game, we were just kinda poking and prodding but nothing came to fruition.

Conclusion

Overall, it was a fun experience; It gave me a chance to sit in the attacker’s seat and focus all of my attention on gaining access. I also got to meet and work with a lot of talented people; it sure is a small world. At the end of the day, all of the Red Team agreed that we should have started sharing information at the beginning of the game and organized ourselves. Ultimately, the only significant scores posted were leveraged via the Nagios server. If we had been sharing information, maybe we would have made good use of the lost time and found another avenue of attack. I guess we’ll never know.

I look forward to participating again next year.

If you are a PHP developer, you may or may not know that it is becoming popular to omit the closing PHP tag in class files as it’s not necessary and it avoids the possibility of a space at the end of the file causing frustration in various situations. If you’ve ever had to remove these tags from a large number of files, you know how tedious it can be. Well, no more; here is a script to do just that. Just change into the directory containing the files to be stripped, and run ‘php-remove-closing-tag’.

The script makes use of the awk, pcregrep, sed, and wc utilities to get the job done. You may need to install some or all of them to make the script work. If you are a developer, you will probably have all of them installed anyway.

Download Source

Source Code:

#!/bin/bash
# vim:ft=sh:ts=3:sts=3:sw=3:et:
 
###
# Strips the closing php tag `?>` and any following blank lines from the 
# end of any PHP file in the current working directory and sub-directories. Files
# with non-whitespace characters following the closing tag will not be affected.
#
# Author: Bryan C. Geraghty <bryan@ravensight.org>
# Date: 2009-10-28
##
 
FILES=$(pcregrep -rnM --include='^.*\.php$' '^\?\>(?=([\s\n]+)?$(?!\n))' .);
 
for MATCH in $FILES;
do
   FILE=`echo $MATCH | awk -F ':' '{print $1}'`;
   TARGET=`echo $MATCH | awk -F ':' '{print $2}'`;
   LINE_COUNT=`wc -l $FILE | awk -F " " '{print $1}'`;
   echo "Removing lines ${TARGET} through ${LINE_COUNT} from file $FILE...";
   sed -i "${TARGET},${LINE_COUNT}d" $FILE;
done;

UPDATE:

I discovered a bug in the previous version of the script. I was performing a `head -n 1` on the result of the expression to handle the output of multiple lines from the pcregrep but this was limiting the entire search to one file… doh! I fixed this problem by making the extra space search a positive-lookahead. I have tested the new version thoroughly and assure you that it will work as intended.

Traditional file system permissions management in Linux leaves most users wanting. Fortunately, there’s a feature that most linux users don’t even know about called ACLs and it’s most likely already available on your system. All you have to do to enable it is add the `acl` option to your volume in `/etc/fstab` and re-mount the volume.

Once that is done, here are some functions that I wrote to help manage these ACLs.

Here is an example of a command that grants apache permission to read a directory with these functions:

$ source aclfunctions.bash; grantUserRead 'apache' /var/www '*';

aclfunctions.bash:

# Author :: Bryan Geraghty
# Date :: 2009-10-28
# Notes :: ACL management functions
 
##
# Resets permissions on all files and directories in the specified path and removes
# and ACL entries
#
# @param string $2 Base path Path in which all operations will take place
#
function resetAll
{
   echo "Resetting permissions on all files in directory $1";
 
   echo "Removing ACLs...";
   setfacl -Rb $1;
 
   echo "Resetting directories...";
   find $1 -type d -exec chmod 770 {} \;
 
   echo "Resetting files...";
   find $1 -type f -exec chmod 660 {} \;
}
 
## 
# Grants read permissions to all files/folders with names matching $3, which reside
# inside of directory $2, to user $1.
#
# @param string $1 Username The user to whom read permissions will be granted
# @param string $2 Base path Path in which all operations will take place
# @param string $3 Target Name of the file/directory on which to set the permissions
#
function grantUserRead
{
   echo "Granting read permission to user $1 on files/folders named $3 in directory $2";
 
   ## Set the default permissions for new files on the specified directory
   echo "Setting defaults...";
   find $2 -name "$3" -type d -exec setfacl -d -m u:$1:rx {} \;
 
   ## Recusively set the permissions on all existing directories and files within the
   ## specified directory
   echo "Setting directory permissions...";
   find $2 -name "$3" -type d -exec setfacl -R -m u:$1:rx {} \;
 
   ## Grant permissions to any files with the specified name
   echo "Setting file permissions...";
   find $2 -name "$3" -type f -exec setfacl -m u:$1:r {} \;
}
 
## 
# Grants write permissions to all files/folders with names matching $3, which reside
# inside of directory $2, to user $1.
#
# @param string $1 Username The user to whom read permissions will be granted
# @param string $2 Base path Path in which all operations will take place
# @param string $3 Target Name of the file/directory on which to set the permissions
#
function grantUserWrite
{
   echo "Granting write permission to user $1 on files/folders named $3 in directory $2";
 
   ## Set the default permissions for new files on the specified directory
   echo "Setting defaults...";
   find $2 -name "$3" -type d -exec setfacl -d -m u:$1:rwx {} \;
 
   ## Recusively set the permissions on all existing directories and files within the
   ## specified directory
   echo "Setting directory permissions...";
   find $2 -name "$3" -type d -exec setfacl -R -m u:$1:rwx {} \;
 
   ## Grant permissions to any files with the specified name
   echo "Setting file permissions...";
   find $2 -name "$3" -type f -exec setfacl -m u:$1:rw {} \;
}
 
## 
# Grants read permissions to all files/folders with names matching $3, which reside
# inside of directory $2, to group $1.
#
# @param string $1 Group The user to whom read permissions will be granted
# @param string $2 Base path Path in which all operations will take place
# @param string $3 Target Name of the file/directory on which to set the permissions
#
function grantGroupRead
{
   echo "Granting read permission to group $1 on files/folders named $3 in directory $2";
 
   ## Set the default permissions for new files on the specified directory
   echo "Setting defaults...";
   find $2 -name "$3" -type d -exec setfacl -d -m g:$1:rx {} \;
 
   ## Recusively set the permissions on all existing directories and files within the
   ## specified directory
   echo "Setting directory permissions...";
   find $2 -name "$3" -type d -exec setfacl -R -m g:$1:rx {} \;
 
   ## Grant permissions to any files with the specified name
   echo "Setting file permissions...";
   find $2  -name "$3" -type f -exec setfacl -m g:$1:r {} \;
}
 
## 
# Grants write permissions to all files/folders with names matching $3, which reside
# inside of directory $2, to group $1.
#
# @param string $1 Group The user to whom read permissions will be granted
# @param string $2 Base path Path in which all operations will take place
# @param string $3 Target Name of the file/directory on which to set the permissions
#
function grantGroupWrite 
{
   echo "Granting write permission to group $1 on files/folders named $3 in directory $2";
 
   ## Set the default permissions for new files on the specified directory
   echo "Setting defaults...";
   find $2 -name "$3" -type d -exec setfacl -d -m g:$1:rwx {} \;
 
   ## Recusively set the permissions on all existing directories and files within the
   ## specified directory
   echo "Setting directory permissions...";
   find $2 -name "$3" -type d -exec setfacl -R -m g:$1:rwx {} \;
 
   ## Grant permissions to any files with the specified name
   echo "Setting file permissions...";
   find $2 -name "$3" -type f -exec setfacl -m g:$1:rw {} \; 
}
 
## 
# Grants execute permissions to all files/folders with names matching $3, which reside
# inside of directory $2, to user $1.
#
# @param string $1 Username The user to whom read permissions will be granted
# @param string $2 Base path Path in which all operations will take place
# @param string $3 Target Name of the file/directory on which to set the permissions
#
function grantUserExec
{
   echo "Granting execute permission to user $1 on files/folders named $3 in directory $2";
 
   ## Set the default permissions for new files on the specified directory
   echo "Setting defaults...";
   find $2 -name "$3" -type d -exec setfacl -d -m u:$1:rwx {} \;
 
   ## Recusively set the permissions on all existing directories and files within the
   ## specified directory. One command will siffice for files and directories when
   ## setting execute permissions 
   echo "Setting directory and file permissions...";
   find $2 -name "$3" -exec setfacl -R -m u:$1:rwx {} \;
}
 
## 
# Grants execute permissions to all files/folders with names matching $3, which reside
# inside of directory $2, to group $1.
#
# @param string $1 Group The user to whom read permissions will be granted
# @param string $2 Base path Path in which all operations will take place
# @param string $3 Target Name of the file/directory on which to set the permissions
#
function grantGroupExec
{
   echo "Granting execute permission to group $1 on files/folders named $3 in directory $2";
 
   ## Set the default permissions for new files on the specified directory
   echo "Setting defaults...";
   find $2 -name "$3" -type d -exec setfacl -d -m g:$1:rwx {} \;
 
   ## Recusively set the permissions on all existing directories and files within the
   ## specified directory. One command will siffice for files and directories when
   ## setting execute permissions 
   echo "Setting directory and file permissions...";
   find $2 -name "$3" -exec setfacl -R -m g:$1:rwx {} \;
}

I’ve been a software developer for 10 years and since I can remember, I’ve heard this term being passed around as if it were the bane of any software project: over-engineering. In the early years, I was a novice in a shop full of seasoned developers, so I absorbed every bit of sage advice like a sponge. This idea that you shouldn’t over-think things because you’ll end up with a system that is far more complex than it needs to be made sense. Unfortunately, it seems as though the original intent of this phrase has been lost to the current generation of programmers. From my experience, it seems that far too many developers have interpreted this phrase to mean “do no engineering at all”. Complex systems are created one line at a time by trial and error. Let me point out right away that this article is by no means an attack on people developing software this way. This is my attempt to reach out and help improve the state of the industry. Hopefully, it will make all of our lives a little easier.

When I re-examine the phrase now, the entire concept of over-engineering seems laughable. The purpose of engineering is to design an optimal solution to a practical problem. How can you make a system worse by thinking more about how it can be improved? I think this oxymoron of a concept has stemmed from two possibilities. This first is that these developers don’t understand the role of engineering and the second is that they don’t understand the project requirements.

I’ve experienced the first condition firsthand. When I was a pup, I thought software engineering was creating software from scratch. I created every bit of it, so I must have been the engineer! Unfortunately, it turns out that those projects simply had no engineer at all. There weren’t even specific requirements of the system before I started writing code. I had a rough idea of what it needed to do, so I created it the best way I knew how: by trial and error. This was a gross misunderstanding of the role engineering on my part. I’ve since learned that software engineering is much like any other type of engineering.

One major qualification required of an engineer is a deep understanding of all of the available materials. If an electrical engineer doesn’t understand the difference between paper and plastic capacitors, their circuit may not hold up under certain conditions. If a mechanical engineer doesn’t understand the tensile strength of iron vs aluminum, they may not make the best decision when deciding which to use. In either case, it’s possible that the person in question could design a solution to the problem; it may even turn out to be a good one. But a true engineer would understand all of the costs, strengths, and weaknesses of all of the available materials. They would be able to make a scientific decision about which should be implemented. This same principle is applied to software engineering. If you don’t understand the costs, strengths, and weaknesses of the available technologies, how can you make an informed decision about which to implement?

Another major qualification of an engineer is to understand the problem in its entirety. If an architect is asked to design a home but does not consider whether it will be built on an island where little electricity is available, in a desert, or in the middle of a metropolitan city, it’s likely that something won’t work out. This is an extremely obvious example, but the point I want to illustrate is that the person who wants the house built may not understand all of the issues that need to be considered. It is the job of the engineer to be able to see these issues in the design stage and raise the appropriate questions when necessary. Otherwise, you may end up with a very expensive sculpture. In the realm of software, a client may ask for a custom CRM package but doesn’t mention that they want it to be usable offline. A software engineer needs to be able to foresee this type of issue and raise questions. I’ve seen too many systems built where nobody stepped back to look at the big picture. There would be an immense focus on getting a small task done and when it was finished, it turned out that it couldn’t be implemented as needed or someone on the next team had already solved the problem.

The final qualification I’ll highlight is the ability to create documentation. You could engineer the perfect system but if it’s not spelled out specifically, details get lost. By the time a project enters the development stage, all of the questions need to be answered in writing. Nobody would expect a contractor to build a structure without a blueprint. Neither would you build a complex circuit without a schematic. The same should go for software. Every detail should be spelled out on paper before anyone even starts dreaming of code. There will be plenty of revisions, for sure. But the problems found at this stage will take far less time to correct than in the development stage.

The qualifications I’ve mentioned are things that we need to start seeing more of in software development. It’s a cop-out to say, “It’s my code, nobody else will ever touch it.” or, “I don’t have time to create documentation.”. I’ve inherited too many extremely complex projects left behind by people who said these very things. I’ve even been guilty of doing those things in the past. It’s time to evolve. To me, the fact that the National Vulnerability Database posts 20+ new vulnerabilities a day illustrates that we’re doing something wrong.

Lets make a change.

For Christmas this year, I received a Dell XPS M1730 Laptop to help facilitate my home studio recordings. This laptop will happily handle anything you can throw at it but it has one undesirable trait: its size. What Dell fails to advertise is the fact that this is largest 17″ laptop on the market and it won’t fit into most 17 inch laptop bags because its dimensions are 16″x12″x2″. It’s a monster when you compare it to a 17-inch MacBook Pro at 15.4″x10.4″x1″. Dell does offer a very nice back-pack case designed specifically for this laptop. The problem with it is the fact that it was specifically designed for this laptop. There is not much room left for anything else and the bag itself is huge which makes for quite cumbersome travel.

The real problem I have, is that I take my SLR camera and some extra lenses with me everywhere I go. Anytime I travel, I also take my laptop. So far, this has meant carrying either more bags than I’d like, or over-stuffing one. As we all know, over-stuffing isn’t a great option for delicate equipment.

Dell XPS M1730, meet the Tenba Shootout Photo/Laptop Courier bag

The internal dimensions of this bag are a perfect fit at 16.5″x12″x7″. The icing on the cake is that Tenba is a renowned manufacturer of camera cases and they seemingly had my struggle in mind when they made this one. So far, I have loaded my laptop, the power supply, mouse, memory card reader, and my SLR in the bag. Everything is neatly divided and there is still tons of space; but most importantly, everything is well-protected.

Well done, Tenba.

About a month ago, I purchased a Subway Rocket and said I would put some sound clips up. It’s taken a while, but I’ve finally gotten around to it. Well, I got around to making one :)

Sound Clips:

Mesa Boogie Subway Rocket Tone – Contour Mode

I’ll post the others soon, I promise!

The Mesa/Boogie Subway Rocket is the newest addition to my recording studio; it’s a 22 Watt vacuum-tube guitar amplifier.

Specs

• 2 Channels: Rhythm and Lead+Switchable Contour
• 3 Band Shared EQ
• 22 Watts: 4x12AX7 Preamp Tubes & 2xEL84 Power Tubes
• Parallel Effects Loop with Mix Control
• 8-4-4 OHM Outputs
• Eminence 10″ 50 Watt 8 OHM Speaker (Labeled as Vintage Black Shadow)

On to the details

I have been considering making the jump to a tube amp for a while but the cost has always put me off. I have a collection of solid state amps that have given me great tone and I could never find a tube amp for less than $1000 that sounded significantly better than the amps I already had. Nevertheless, any time a new reasonably-priced tube amp shows up in my GC (Guitar Center) catalog, I have to go try it out. It was on one of these treks where I encountered the Subway Rocket.

I went into GC specifically to try out a second-hand Crate V33 they had priced to move. After ten minutes of tinkering, I was completely turned off. But I figured while I was there, I’d have some fun. So I grabbed a nice Strat and plugged into the ol’ standby: the Fender Blues Junior. The Blues Junior has always held a certain quality that attracts me. Set the gain at 7, roll back the volume on a neck-position single coil, and let the tubes sing. I’ve always loved the sound, but I could never justify spending $600 on an amp when I have an old $200 Fender Automatic that cries quite beautifully in it’s own (albiet, solid state) right. Well, while I was enjoying the tone pouring from the Junior, I glanced over and spotted a small combo amp with the logo which has become sort of a holy grail for me: Mesa/Boogie.

I think the main reason Mesa/Boogie has reached holy grail status for me is that I never thought I would be able to afford one. I’ve been a fan of John Petrucci (of Dream Theater) for a long time and his guitar tone is what set the bar for me. Any time he plays you’re sure to see a wall of Mesa/Boogie cabinets and his trusty Mark IIC+ amp heads. Those heads alone sell for $2500+, and since I’m not making a living off of my guitar playing, I could never justify spending anywhere near that amount of money on an amp. But man, is the tone incredible.

Now, my first thought as I looked at this unassuming combo amp was, “That has to be some kind of marketing gimmick”. I thought that there was no way Mesa could get the wall of tone that they’re famous for into a 10″ combo. But just for fun, I decided to plug in a see how it sounded. After five minutes, I was completely sold; this amp is amazing.

I’ve now had it for a week, I’ve put it through it’s paces, and I have to say, I’m still completely sold. The rhythm channel on this amp at half gain is the silkiest, smoothest blues grit I’ve ever heard. Flip it into the lead channel with the gain at 8 and you’re in metal land. Step on the contour switch and stand back! Even though it’s a 10″ combo, this thing will make your ears bleed. I set the lead channel volume at 2 in my recording room (a huge open room with vaulted ceilings) and I couldn’t take it for more than a couple of minutes; I had to turn it down. My final test was to throw an SM57 in front of it to see how it would track to “tape” without too much fuss and I wasn’t disapointed. That magical thing about microphones is that they don’t care how big the speaker is; it sounds monstrous. I’ll have some clips of the recording up here shortly.

In a final word, this amp is the perfect studio guitarist/owner’s friend. It’s extremely versatile and because it was built by Mesa/Boogie, it is truly a professional piece of equipment. Just by looking at it, you get the impression that it was built to last. If you’re a guitarist in the market for your first tube amp, I HIGHLY recommend seeking out one of these amps. This is one piece of gear I will never sell.

More Photos

Thanks for stopping by!