addhaloka
Gold Member | Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
What's new?
* Ability to unlock X-Ways Forensics 17.0 and later with network dongles. Network dongles are available as a substitute for regular dongles probably from March 2013. A single network dongle can represent x licenses and substitute x regular dongles and allow the users to run X-Ways Forensics on x machines on the same network at the same time. The network dongle is attached any of the computers on the network and made available to the clients by a dongle server program or service. If multiple network dongles are found by a client, the user may choose one of them when starting up X-Ways Forensics. If one of these dongles is already fully in use, according to the number of licenses that it represents, the user will see that and can choose another dongle. Conveniently, a network dongle can also be used locally just like a regular dongle or multi-user dongle when needed!
When purchasing new licenses, you will have the option to order them with a network dongle instead of regular dongles, depending on the number of licenses either for free or at a surcharge. If you own many licenses already, we can probably offer you to test the network dongle and to swap many or all of your existing regular dongles for a single network dongle, on a case-by-case basis. For more information on the dongles in general and network dongles in particular please see http://www.x-ways.net/forensics/dongle.html#types.
* Ability to rank file types by importance/relevance and filter by the rank using the Type Status filter. For example, filtering out those file types ranked #0 will exclude font files, cursors, icons, themes, skins, clip arts, etc. Files with a low rank are of importance just in very specific investigations, for example source code, in which you would not be interested when looking for office documents or pictures for example, but definitely when hunting a virus programmer. Higher ranked file types are relevant in more cases. Generally the rank is useful in simple cases where you can expect to find what you are looking for in file types that are fairly well known. As another idea, you could make it a habit to only index files with higher ranks.
* Ability to assign file types to a so-called group, a new concept, which is not identical to a file type category. Useful for example if your standard procedure is to let examiner A check out pictures and videos, examiner B documents, e-mail, and other Internet activity, and examiner C operating system files of various kinds, because of their specializations. You can give these groups meaningful names and filter for them, also using the Type Status dialog window. The groups are displayed in the Type filter.
* The new definitions are all made in the "File Type Categories.txt" file. Existing files of that kind will continue to work as before. Suggestions for ranks are already predefined in the new standard file. Both ranks (from 0 to 9, where missing means 0) and groups (letters from A to Z) can be optionally specified following a tab at the end of a line, in any order, for example as "2P" or "DI3". So up to 10 rank levels are possible (but it is not necessary to fully utilize this range), and up to 26 groups (and you do not have to start alphabetically, the case of the letters is ignored). You can also define ranks and groups for an entire category, following a tab in a category line. To give a group a more descriptive name than just a single letter, insert group definition lines at the end of the text file that start with a equal sign, e.g.
=P=Photos and videos for image group
=D=Docs, e-mails and Internet
=I=File types to index
* Logical searches now also specifically cover the transition area from uninitialized (but physically allocated) areas of files to immediately following free space, if the option to cover the transition from slack space to free space is in use.
* Ability to run a logical search in selected files via the directory browser context menu from the case root window.
* Memory requirements for search hits reduced by 17%. Old versions cannot load search hit lists saved by v17.0 and later.
* Ability to refine the volume snapshot for selected files only, via the directory browser context menu.
* Ability to store most filter and all sort settings in the active case and load them again automatically when a case is opened. See Options | Directory Browser.
* If the option to Recover/Copy child objects of selected files is half selected, that now means that the only child objects that will be copied are e-mail attachments.
* Many more events are now output based on timestamps in internal metadata of many different file types.
* Several events now have an individual description, for example events in the Windows registry and in Internet Explorer index.dat files.
* The option to list items in registry hives recursively has been removed.
* Ability to extract video stills reliably using recent MPlayer releases. MPlayer 1.1 for use with v17 is now provided as a download.
* The resolution of videos is now displayed roughly in the Pixels column after at least one video still has been exported.
* Special support to carve thumbcache fragments (CMMM records) at the byte level.
* Since v16.3 it is possible to reconstruct RAID level 5EE. Now it is also possible to reconstruct RAID 5EE systems if one component disk is missing. RAID 5EE with forward and backward parity are supported.
* Directory browser option to display tag marks as check marks.
* Support for binary PLists has been improved to include the undocumented CF$UID data type.
* The Technical Details Report now checks for certain read inconsistencies that can occur with flash media (for example certain USB stick brands/models, but not others) in data areas that have never been written/used, where the data is undefined. The data that is read in such areas, for example when imaging the media, may depend on the amount of data that is read at a time with a single internal read command. The result is mentioned in the report. If inconsistencies are detected ("Inconsistent read results!" in the report), you will see a message box, which offers to read sectors in smaller chunks from that device as long as it is open, which likely yields the expected zero value bytes instead of some random looking non-zero pattern data when reading such areas. Use of this option does not give you data that is somehow more accurate or original (undefined is undefined and does not mean zeroed out) or contains more or less evidence, it can just have a big impact on compression ratio achieved and reproducibility of hash values with other tools, which may use different chunk sizes for reading and thus produce different data and hash values. Note that it is possible that read inconsistencies occur that are not detected by X-Ways Forensics, because a complete check would be very slow. Again, these inconsistencies are not fatal and not the fault of the software, and they can be explained. Does it mean that you should invoke the Specialist | Technical Details Report command prior to imaging? No, the report is routinely created already when imaging starts.
* Ability to specify how many extra threads to use when creating .e01 evidence files, when clicking the tiny little button in the lower right corner of the Create Disk Image dialog window. By default X-Ways Forensics will use no more than 4, and it depends on how many processor cores your system has, but you could try to increase it to up to 8 or even 16 on very powerful systems with even more cores usually without problems, for a chance to further increase the speed.
* The option "Display file sizes always in bytes" can now be found in Options | General | Notation. The alternative .eml preview option can now be found in Options | Viewer Programs.
* Size of the 64-bit executable files noticeably reduced.
* Several minor improvements.
|
