X-Ways Software Technology heeft versie 17.0 van WinHex uitgebracht. WinHex is niet alleen een universele hex-editor, maar is ook in staat om low-level-dataprocessing toe te passen via een gemakkelijke interface. Het programma beschikt onder meer over een ram-editor, een data-interpreter en een disk-editor, en kan bijvoorbeeld worden gebruikt om verwijderde informatie terug te halen of om bestanden te inspecteren. WinHex werkt op alle Windows-versies vanaf Windows 2000 en is verkrijgbaar in verschillende versies, met prijzen vanaf ongeveer veertig euro. In deze release zijn de volgende veranderingen en verbeteringen doorgevoerd:
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.
- User-specific configurations are now stored in the Windows user profile, in a subdirectory of \AppData\Local\X-Ways. The configuration now becomes user-specific automatically when running X-Ways Forensics not as administrator from a directory on the C: drive where a user does not have write access, such as C:\Program Files. Otherwise by default X-Ways Forensics still runs with a non user-specific configuration so that it remains a portable program and does not unnecessarily alter live systems that you wish to preview/triage. For details please see http://www.x-ways.net/winhex/setup.html. Whether a user-specific configuration is active or not (and if active, for what reason and where it is stored) can be seen in the Help | About box. The reason can be "necessarily" if no write access to the installation directory or "forced" a file named winhex.user is found in the installation directory or "for this user" if the user has an individual configuration already from previous executions for either of the other reasons. The inconsistent use of Virtual Store subdirectories is now avoided.
- In newly taken volume snapshots of NTFS volumes, hard-linked files now get a special treatment. An additional hard link just to provide a short filename that satisfies the 8.3 requirements of old Microsoft DOS/Windows versions is not counted any more as a hard link. Instead, such files get their hard link count marked with a ° in the Links column of the directory browser. That way, the hard link count more accurately reflects the hard links actually present in the volume snapshot of X-Ways Forensics, and normal files always have a count of 1, whereas 2 or more means something more special.
- In newly taken volume snapshots of NTFS volumes, all "real" hard links (i.e. hard links other than SFN) except for one can be conveniently excluded from logical searches and indexing by enabling the so-called recommended data reduction. Nowadays on Windows installations often between 10,000 and 100,000 hard links of system files exist, for example 27 links to a file like "Ph3xIB64MV.dll" in directories such as
By searching only in one hard link of a file, you can typically exclude several GB of duplicate data and yet don't miss anything if you search all other files. Those additional hard links that are excluded by the recommended data reduction get their hard link count marked with an asterisk (*). Search hits in the only hard link that does get searched are marked with the hint "-> Links!" in the Descr. column to remind you of the other hard links of the same file in case those search hits are relevant.
- \Windows\System32\DriverStore\FileRepository\ph3xibc9.inf_amd64_neutral_ff3a566e4b6ba035
- \Windows\System32\DriverStore\FileRepository\ph3xibc2.inf_amd64_neutral_7621f5d62d77f42e
- \Windows\System32\DriverStore\FileRepository\ph3xibc5.inf_amd64_neutral_2270382453de2dbb
- \Windows\winsxs\amd64_ph3xibc9.inf_31bf3856ad364e35_6.1.7600.16385_none_a0a14b454657e48e
- \Windows\winsxs\amd64_ph3xibc5.inf_31bf3856ad364e35_6.1.7600.16385_none_9e7d0270e1def2ea
- \Windows\winsxs\amd64_ph3xibc12.inf_31bf3856ad364e35_6.1.7600.16385_none_64d7af985f2a04e4
- etc.
- A filter is now available for the ID column, which makes it more convenient to find other hard links of a given file.
- When viewing a hard-linked file, the other hard links of the same file are now optionally marked as already viewed as well at the same time, just as known in previous versions for duplicates based on hash values.
- When creating report table associations optionally for duplicates of the selected files at the same time, this now includes other hard links of the same file.
- Support for another artifically defined code page, which allows to search for and read UTF-16 text encoded by the MS Outlook cipher called compressible encryption.
- It is now possible to search and index in up to 6 code pages at the same time.
- The already previously supported non-Unicode artificial code page for MS Outlook compressible encryption now works based on a user-defined code page (by default equal to the code page active in your Windows system for non-Unicode programs), not just Latin 1. Potentially important for languages other than Western European languages. Outlook uses the Windows system code page in its old non-Unicode capable variant of PST.
- PST and OST files are now no longer omitted by logical searches and indexing if the recommended data reduction is active and e-mail and other Outlook data has been extracted from them.
- Search hits in all variants of UTF-16 that are not aligned at even offsets are now marked in the Descr. column as "unaligned", as a small hint and explanation why you can read the text only in the alignment-aware context preview of the Search hits column, and not in the text column.
- Tools | File Tools | Delete Recursively can now automatically delete files for which you do not currently have the right to delete (for example because "Trusted Installer" is the owner), but for which you can get all rights (if you are running WinHex with administrator rights).
- Minimum memory requirements for loaded volume snapshots reduced. More data of volume snapshots can now be kept in memory optionally for higher performance.
- More compact internal organization of certain files in volume snapshots (extracted e-mails, video stills, virtual attached files).
- Volume snapshots from v16.3 (released in October 2011) and later can be imported, from v15.8 (October 2010) to v16.2 as well if no e-mail was extracted by those versions. Incompatible volume snapshot will be identified and not converted.
- Ctrl+A now works in all edit boxes and all multi-selection list windows in all dialog windows.
- Exploring the contents of 5 more usually irrelevant Zip subtypes is now optional when refining the volume snapshot, compared to just JAR in previous versions.
- The check for updates can now be found in the Help | Online menu.
- Program help updated.
- Carving support for "Gatherer Transaction Log". Event extraction from carved fragments of this log (.gthr2) and existing .NTfy.gthr files.
- Preliminary event extraction from Firefox cache fragment files (.firefox).
- Avoids more irrelevant identical traces of files found in volume shadow copies.
- The "Uncover embedded data" function uses some special algorithms for certain file types (Windows.edb, thumbs.db, PLists) and byte-level carving for all other host file types. This carving was limited to embedded JPEG and PNG files in previous versions (+EMF in multi-page printer spool .spl files). Now embedded files of any type whose definition in the File Type Signatures Search.txt file comes with a tilde (~) algorithm and is marked with a new flag "e" (for "embedded") will be carved. As a very good example of this new flexibility, .lnk shortcut files are now carved within customdestinations-ms jumplists.
- If you choose to not sort the directory browser initially after start-up, there will now also be no sorting when turning off all filters with a single mouse click, to avoid longer delays when suddenly all files are listed again recursively.
- When copying files or alternate data streams or other objects that do not have any or all timestamps with the Recover/Copy command, X-Ways Forensics now approximates the fact that a timestamp is not available by setting the corresponding timestamps of the output files to ~0 (Jan 1, 1601 in NTFS). This behavior was already active in versions before April 2012. It can be avoided by holding the Shift key when clicking OK in the dialog box, for example if you wish to use some other programs with these files that do not want to open files with such timestamps (it has been reported for VLC).
- Ability to save filter and sort settings to a separate file and load them again at any time, by clicking on the Open/Save icons on the right-hand side of the caption line of the directory browser. Such files are given the extension ".settings".
- The selected file types of the Type filter are now also optionally stored in cases, like other filter settings. Note that collisions among file type designations become apparent when selections for the file type filter are loaded. For example if you had originally selected "mmf" = "MailMessage File" (category e-mail), then you will find that "mmf" is also selected as "Yamaha SMAF" (category Sound/Music). This is normal and does not change what the Type filter does. When in doubt, the Type filter also includes other types with the same designation, to avoid that anything is overlooked.
- Includes the contents of the Pixels column in evidence file containers of the new type.
- Exploring zip-based Office document files such as those of MS Office 2007/2010, LibreOffice, OpenOffice, iWork is now optional when refining the volume snapshot. Useful if you or the recipients of evidence file containers that you create only wish to see the documents as a whole, no embedded pictures or XML files separately, and don't need to extract metadata from these XML files and can recognize nested documents (documents embedded in other documents) themselves if necessary.
- A filter for the event type column is now available.
- Ability to filter for "unequal to" in the ID and internal ID filters. Useful should the volume snapshot refinement crash with a file that was not part of the volume snapshot when it was last saved during the refinement. In that case you can filter out and omit the offending file with the future assigned internal ID in advance when you try again.
- Activating Sync mode now automatically deactivates all filters if filters keep the directory browser from listing the file that the current cursor position in Partition/Volume mode is contained in. As always you can click the Back button to return to the previous listing in the directory browser, but remember that this works only if the directory browser has the input focus, not the lower half of the data window where you navigated in Partition/Volume mode, where jumps from one offset to the other can be undone or redone with the Back & Forward functionality.
- In newly taken snapshots of HFS+ volumes with hard links, you can now view hard-linked files directory and do not have to look up the corresponding so-called indirect node file manually (the one whose name contains the inode number, which is specified in the Comments column).
- Newly taken volume snapshots now support a concept of "related" files, related in ways other than a parent-child or sibling relationship. For example, the related file for hard links in HFS+ is the corresponding indirect node file. The related file for files that were found volume shadow copies in NTFS is the volume shadow copy host file. The related file for a volume shadow copy host file is the corresponding snapshot properties file (called "snapprop" in the Type column). More kinds of n:1 relationships are conceivable in future versions. Files that have related files get their icon marked with a small blue downward pointing arrow on the left-hand side of their icon.
- A new command in the directory browser context menu (Navigation submenu) allows to conveniently find the related file if one exists for the selected file. You may also press Shift+Backspace to navigate to the related file. This is similar to just hitting the Backspace key, which navigates to the parent file or directory.
- For files found by v17.0 and later in volume shadow copies, the Attr. column now points out the sequential number of the snapshot in which they were found, as indicated by the snapshot properties file.
- Special extraction of objects (pictures and others) embedded in MS Word .doc and MS PowerPoint .ppt OLE2 compound files, in which previously only JPEG and PNG were found and only through ordinary carving. Embedded pictures are now often output with their original name or designation in the document and are extracted correctly even if fragmented within the OLE2 compound file.
:fill(white):strip_exif()/i/2000568959.jpeg?f=thumbmedium)
/u/395016/waiting.png?f=community){kind=small}