FREE WIRESHARK CLASS - Lecture 4 - Navigation

 To celebrate my 10th year on youtube and to thank all those who watch, like, share and subscribe i wanted to give you a gift. 2 years ago i created a Wireshark class for Udemy which was very popular.

Review: Startup Myths and Models by Rizwan Virk

 

• Type “Startup” into Amazon book search and you’ll get over 20,000 hits. In this crowded field, the path to producing a work of value is an epic journey. In Startup Myths and Models by Rizwan Virk, the author uses elements of legendary journeys to breathe life into his personal stories of building a business from the ground up. Riz has over 25 years of experience as an entrepreneur, investor and author, all of which offers clarity, insight, and in some cases personal life coaching for the nascent entrepreneur.

  The cover illustration hints at the key role of the Startup Model Lifecycle, used throughout the book to help entrepreneurs understand how their decisions are intimately connected to the phase their business is in. The text is organized according to the 6 main stages of Joseph Campbell’s Hero’s Journey, with standard business school models and common myths appearing along the way. As the title implies, it is the myths – those accepted rules of thumb that can also become a mental trap – that form the central theme distinguishing the book from others in this category.

  Myths about starting a company are gathered together in the first stage, The Call to Adventure. Here tales like Star Wars and The Hobbit illustrate some of the motives for beginning an adventure. Riz tells the story of his own personal experience while working at Lotus Development, where he recognized and took advantage of a line of business his employer was not addressing. Several common early stage myths are addressed with present-day examples. There are also early warnings that the journey may not end up as expected and yet still be worth the effort.

  There is evidence in this first section that the author is empathetic to the personal as well as the business elements of a startup. Selecting co-founders is likened to dating before getting married, but it will take a lot of self-awareness to use the book’s tools in this section effectively. Spouses and significant others are included in the discussion, emphasizing that starting a company can be an all-consuming life journey for everyone involved.

  
  

  Luke needed a lightsaber before beginning his quest, and so will the epic journey of a startup require resources – most notably money. A major pitfall for beginning entrepreneurs is a lack of awareness of the strings that are attached to most investments. In the second stage – Fuel for the Journey – the book tackles some of the different ways that founders and investors view fundability. Examples from Riz’s own experience in mobile gaming are combined with advice from well-known investor Randy Komisar. Entrepreneurs are warned that VC’s are basically just looking for reasons to say no; a good link from Sarah Downey of Accomplice further illustrates the point.

  
  

  Legendary journeys always involve memorable companions (R2D2 and C3P0 come to mind) who will accompany the hero and prove essential at the proper moment. Danger lurks with those who seem compatible in the beginning, but later turn out to have their own agenda. In this section - Travel Companions - we encounter the business model’s four quadrants of hiring, based on the range of experience and cultural fit that often vexes hiring managers. The importance of balancing micro-managing (which isn’t always bad) and leadership/mentoring is illustrated by analogy with Siddhartha’s sitar string; if strung too tight, it snaps but if too loose, it makes no music. The value of good management is illustrated by the example of Riz’s own company, Brainstorm Technologies, which did well when run haphazardly by him and his friends and then ultimately became a well-run failure when an outside CEO arrived.

  
  

  Once the management myths have been busted, the book moves on to The Road of Trials. Napoleon summarized this section best when he remarked that no battle plan survives an encounter with the enemy. Here the author warns that hyper-focus can lead one to miss an excellent opportunity that is lurking nearby. From experience, he suggests paying less attention to vision and more to serendipity. The secret to busting the “Fail Fast, Pivot Quickly” myth according to Riz is to fail slowly and pivot carefully. He illustrates this point with two examples - Gnip, which pivoted, and Life360, which did not.

  A fundamental motive for any entrepreneur is examined in Acquiring the Treasure. Luke knew right from the beginning he was going to rescue the Princess but with a startup, the treasure and how to get it often isn’t known until the journey’s end. One of the most enduring exit myths of all is that the long hard work of the startup culminates in a glorious shower of money known as the IPO. The author busts this myth, noting that only about 10% of successful tech journeys culminate in an IPO, while the remainder end with acquisition of the company. The Startup Model Lifecycle is the foundation for Riz’s secret in determining a business’s worth. This section includes a spreadsheet to help sort out the underlying reasons for the acquisition, both logical and emotional. The author’s own experience selling Gameview is a compelling example; only later did he realize he could have gotten more had he known that the buyers were not seeking revenue alone.

  
  

  One appealing element of this book is the recognition that life is in session during any startup journey. The myths arising from the personal experiences in startup land are collected in the final section, The Underworld and the Return. Riz reminds us that startups are riddled with human emotions like hope, fear and greed, and warns how the dark times can bring these out. It is important to be prepared for how the journey will change you, and to remember that what comes afterward is just as important to your well-being as the journey itself. Advice from experts like Brad Feld and Alex Haro suggests that we are not alone in this journey and we must manage expectations and explore options on a regular basis.

  Myth-busting raises tough questions, and the blunt yet unsatisfying answer is often “it depends.” Riz uses his clear writing style with numerous examples, enthusiasm for entrepreneurship, and stories invoking intuition and personal reflection to guide the reader through the journey while building interest as the book progresses. The mythological characters and themes aren’t always universal – if you are not familiar with Dungeons and Dragons or Magic the Gathering some won’t mean as much. The partially revealed Bonus Myths were a bit of a distraction at first; it seems like the universal myth of starting something you are passionate about could have received more attention in the main text. On the other hand, the myths related to valuation of a company do seem better suited to an external reference.

  Startups operate in an unpredictable environment where experience and self-reflection are essential for survival. In each stage of the journey, Riz blends his own unique style of myth-busting with classical business school models and hard-won experience to both entertain and inform the reader.

  
  

  Author Profile - Paul W. Smith - leader, educator, technologist, writer - has a lifelong interest in the countless ways that technology changes the course of our journey through life. In addition to being a regular contributor to NetworkDataPedia, he maintains the website Technology for the Journey and occasionally writes for Blogcritics. Paul has over 40 years of experience in research and advanced development for companies ranging from small startups to industry leaders.  His other passion is teaching - he is a former Adjunct Professor of Mechanical Engineering at the Colorado School of Mines. Paul holds a doctorate in Applied Mechanics from the California Institute of Technology, as well as Bachelor’s and Master’s Degrees in Mechanical Engineering from the University of California, Santa Barbara.

  
  
  

How TCP Works - Bytes in Flight (Chris Greer)

 Whenever I am troubleshooting throughput problems - especially in slow file transfers - the bytes in flight measurement in Wireshark usually helps to save the day. 

This is a custom column that I have added to my TCP Troubleshooting profiles and it always comes in handy. 

But how can I leverage it in troubleshooting? What does it really mean? And on what side of the connection should I capture? 

We will answer those questions in this video:

FREE WIRESHARK CLASS - Lecture 3 - opening, saving and basic navigation

 To celebrate my 10th year on youtube and to thank all those who watch, like, share and subscribe i wanted to give you a gift. 2 years ago i created a Wireshark class for Udemy which was very popular.

Zip-It Part 2

 Part two of deciding the Correct Zip program to

use AND How to Test and verify it for Forensic usage!

Before reading this article,

please read ZIP-IT Part one.

I recently held a session on testing various software to see if it was forensically sound. The session was a success, as far as opening the attendees eyes to see that not all the software that is often recommended as being forensically sound really is. The software tests involved the attendees testing their software to see if it could pass three or four very simple but important forensic requirements. The requirements were those that I would challenge if I were in that position. The tests involved basic file hashing, forensic file copying, and zipping/unzipping in a forensic evidentiary environment. These three categories seemed to me to be the basics behind a sound forensic analysis, reporting, and evidentiary delivery of any evidence found.

At the end of the session I realized that because of time constraints, the attendees did not complete the file zip/unzip portion of the software testing. As a result I decided to do two things. First, I solicited a number of colleagues and asked them to continue with and finish the software testing of the zip products. To date, none of the testers have reported any zip program capable of passing all the tests I have set up. But I have.

Second, I decided to continue with the tests myself. I must admit, I had already tested the items before the session, and knew how the software performed, or where it was failing my test requirements. However I decided to continue and redo the tests again for this article. The tests I designed and performed were totally non-scientific. But were in my opinion realistic. Meaning the processes I tested were those which you might find everyday in the file systems you are processing in your forensic analysis and those which you might commonly forget to check for.

This short article was written as a result of my performing tests on some of the recognized file zipping software programs. They include programs that are routinely recommended and used by most people processing evidence for retention, attorney discovery, or court adjudication. So as not to point fingers at those failing my tests, I am not going to mention their names here.

The basic parameters were set up as follows. All these parameters and assumptions were designed around a Windows Operating System environment. Other OS's such as Linux and the various MAC systems would not have similar requirements. A majority of business operations and forensic analysis is done on Windows platforms, making it an ideal platform for these tests.

First, because I personally think that if you are running a secure shop, your operating system should have the last access update of files turned on. (This is done via a registry key). In most Windows environments, it is off by default. When you are working for a large organization, and are concerned that someone might copy and walk off with the keys to the kingdom, or any other operation that may involve who or how they accessed sensitive files, this last access date may come into play. In my prior life, I often used last access to see when a file was accessed, which might point to the time it was copied/moved, printed, or stolen. That being said, lets set last access update of files to ON. This was requirement number one.

Second parameter was that some of the test data files being used were located in paths made up of Long Filenames (LFN). For those not recognizing this term, it means path/filenames greater than 255 characters. For this reason, the test file system was mandated to be an NTFS file system. For those of you who routinely use many of the forensic suites out there, you know that when exporting files from images, or otherwise, the suites have absolutely no problem exporting long filenames. However, Windows Explorer has its own problems with LFN'S. Often when exporting evidence files you end up with an evidentiary folder length rivaling the length of War and Peace. So long filename processing ability was another requirement.

Third and final major parameter requirement was that the process (program) be able to handle Alternate Data Streams (ADS). Quite simply, this is a file that is attached to a primary file in the file structure. I call the primary file the parent, which is what you see when you look at the files in explorer or other general file listing process. The ADS is effectively (for lack of a better, non-technical term) a child or hitchhiker. It is attached to the parent, but very few processes display the occurrence of an ADS. However, Alternate Data Streams can be made up of any kind of file. They can be executable programs, virus programs, key logger programs, and they can even hold the original URL of downloaded images. Bet you didn't know that. Great for an investigator of porn sites. So lets consider retention of ADS's also important.

Each of these three requirements seem simple, and in most cases are completely unnecessary in most evidentiary situations, but would you want to be the one explaining to the attorneys why your software missed one or all of the requirements set above. Or why, a few years down the road, you unzipped the evidence folder, and realized that some key evidence relating to one or all of the above parameters was now missing? I know I wouldn't.

Now the tests begin. First I designed a simple set of about 150 test files. Nothing large or complicated. Just spread out among about 20 directories of both long filenames and regular (less than 255 character filenames). Some of the files in both the LFN set, and normal set had one or more ADS associated with them. ALL the files had the MAC dates set to: 01/01/2019    12:34:56:789c    01/01/2019 12:34:56:789w    01/01/2019 12:34:56:789a Just for fun, I managed to set the times to 12:34:56:789.

Now I took the recognized file zip/unzip programs and tested against the following parameters as mentioned before. Determine if it: 1:    Altered/updated last access date of the source during the operation. This would be a major problem. Why did you alter the original evidence date? 2:    Restored all the original three MAC dates to the destination upon unzipping. Do the restored dates reflect original values? Hope so. 3:    Could find and properly zip/unzip all the LFN (Long Filename) files. 4:    Could find and include all the ADS along with their parent files

If it failed any or all of the above four tests, I considered it unworthy to be called a forensically sound zipping program.

Some could zip LFNs but couldn't unzip them. Beats the #$%* out of me, how it could zip it, and fail to unzip it. Others worked fine on finding ADS files in the short files, but failed on the LFN's. Others failed to "reset" the original last access date of the source file, and allowed for the last access of the restored destination to be set to the current date. This means they allowed the operating system to alter their original evidence. Replacing or maintaining original last access of the source would be a primary concern. Especially when zipping original data from say, a live server. One had an interface so cumbersome and messed up, I could hardly conduct the tests in an efficient manner. Needless to say I was very disappointed with all but one of the programs tested. For that reason, I am now going to reveal the name of the program I tested which passed all the tests I have set up.

The program which passed all the tests was WINRAR, and more specifically the command line version called RAR. The command line version is more verbose, batch capable, and easy to set up. After all, if you use it in a batch file, even if you are doing something wrong (and we hope you don't), at least you can testify, that you always do it this way. HA HA!

There were some initial stumbling blocks when dealing with the RAR program. Initially it failed to maintain the original last access date of the files. But after a short email exchange with the programmers, and explaining the evidentiary reason for needing last access date maintenance, within two days an updated beta version was out. The current version of WINRAR/RAR now has that option available. Along with dozens of other options, which I will not even attempt to list or mention. I learned which options I need, and routinely use those in a "standard" command line located in (guess what) a batch file, and a comment.txt file (explained below). As it turns out, only about four options are routinely needed to ensure compliance with my test requirements. Your needs may be different. So review, practice and use whatever options you find useful.

An item which is currently implemented is the capability of setting default options both in an INI file, and a file called comment.txt. A "very" few forensic options are capable of residing in the comment.txt file which will take effect upon extraction. This means, that not all of my forensic options are available in the comment.txt. Thus, the command line of the executable may require additional options to extract all the data perfectly. With a little practice, a suitable extraction command line is possible. Where all Paths, MAC dates, LFN's, and ADS are properly restored. Personally, I formulate the command line, then provide it in a batch script, or provide it to the recipient in an email. That way the recipient has all the information to properly extract a good forensic file structure.

Developing a suitable command line for the executable is advisable in order to allow the recipient to properly extract the data. Sending the .exe out of your control with a correct command line will hopefully ensure correct extraction options. An executable sent for remote extraction with proper command line options is, in my opinion the best way to go.

I have also come to use the ability to create encrypted self-extracting files. The self-extraction process makes it not only self contained, but the recipient doesn't need the WINRAR/RAR program to extract the data. The encryption capability (available in most zipping products nowadays) is an added security step, and benefit.

Remember, don't take my word for it. Regardless of which product you use, obtain, test, and retest every program and set up a routine process that ensures consistency. Know which options work, and don't work. Because the other side knows how to challenge your process. (Why did you perform this xxx process on my clients data, and not on other persons data? Are you prejudiced against my client?)

Again, in my testing of the recognized zip/unzip software out there, I found only the WINRAR/RAR to pass all my forensic evidentiary requirements. My requirements may be more strict for testing purposes, and may not be the same requirements you have. But do you want to leave yourself open to evidentiary challenges? It is possible that RAR may fail when performing in a way that you may need it, however, it passed my test requirements.

Bottom Line: Test your zip/unzip software and make sure it meets or exceeds all your evidentiary and storage requirements. Dont' take anyones word (not even mine) that it works. Test it yourself so you can answer questions about its operations when you are on the witness stand.

Associated articles and programs of interest: hash  program to calculate hash values. HASH_IT_OUT  an article discussing forensic hashing of evidence. COPY_THAT  an article discussing forensic copying of evidence. ZIP_IT  an article regarding use of zipping software for forensics.