Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Software-update: WinHex 18.4

WinHex logo (60 pix) X-Ways Software Technology heeft versie 18.4 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 XP en is verkrijgbaar in verschillende versies, met prijzen vanaf ongeveer veertig euro tot over de duizend euro voor de meest uitgebreide versie. In deze release zijn de volgende veranderingen en verbeteringen doorgevoerd:

What's new?
  • A new technology was implemented that can help you to identify known documents (word processing documents, presentations, spreadsheets, e-mails, plain text files, ...) with a much more robust approach than conventional hash values. Even if a document was stored in a different file format (e.g. first PPT, then PPTX, then PDF), it can still be recognized. Internal metadata changes, e.g. after a "Save as" or or after printing (which may update a "last printed" timestamp), do not prevent identification either. Very often even if text was inserted/removed/reordered/revised, a document can still be recognized. This is achieved by using fuzzy hashes. The technology is called FuzZyDoc.
    FuzZyDoc hash values are stored in yet another hash database in X-Ways Forensics. So there are now 5 hash databases available in total, and counting. Hash sets based on selected documents can be added to the FuzZyDoc database exactly like hash sets can be created in ordinary hash databases, and the FuzZyDoc hash database can also be managed in the same dialog window as the other hash databases, so existing users will have no trouble locating and using the new functionality. For each selected document you can create 1 separate hash set, or you can create 1 hash set for all selected documents. Up to 65,535 hash sets are supported in a FuzZyDoc hash database.
    FuzZyDoc is available to all users of X-Ways Forensics and X-Ways Investigator (i.e. not only law enforcement). FuzZyDoc should work well with documents in practically all Western and Eastern European languages, many Asian languages (e.g. Chinese, Japanese, Korean, Indonesian, Malay, Tamil, Tagalog, ..., but not Thai, Divehi, Tibetan, Punjabi, ...), and Middle Eastern languages (e.g. Arabic, Hebrew, ..., but not Pashto, ...). Note that numbers in spreadsheet cells are not exploited by the algorithm, only text. Note that only files with a confirmed or newly identified type will be matched against the FuzZyDoc hash database. For that reason, file type verification is applied automatically when FuzZyDoc matching is requested.
    Documents whose contents are largely identical (e.g. invoices created by the same company with the same letterhead) are considered similar by the algorithm even if important details change (billing address, price), depending on the amount of identical text. That means that if you have 1 copy of an invoice of a company, matching against unknown documents will easily identify other invoices of the same company. For every document that is matched against the database, up to 4 matching hash sets are returned, and the 4 best matching hash sets are picked for that if more than 4 match. For every matching hash set, X-Ways Forensics also presents a percentage that roughly indicates to what degree the contents of the document match the hash set. For example, 100% means that all the textual contents that X-Ways Forensics deemed relevant in the given document can also be found in the hash set, 50% means half of the contents. 100% does not rule out the possibility that the document(s) that the hash set is based on contain(s) much more (other) text. The matching percentage does not count characters one by one, and it works only on documents that actually make sense, not on small test files that only contain a few words.
    Before matching files against the FuzZyDoc hash database (a new operation of Specialist | Refine Volume Snapshot), you can specify which types of files you would like to analyze, and you can unselect hash sets in the database that you are temporarily not interested in. Note that processing less files (e.g. by specifying less file types in the mask) of course will require less time, proportionally, but selecting less hash sets for matching as such does not save time. You may specify a certain minimum percentage that you require for matches (15% by default) to ignore insignificant minor similarities. That option is not meant to save time either.
    In order to re-match all documents in the volume snapshot against the FuzZyDoc hash database, please remove the checkmark in the "Already done" box first. Otherwise the same files will not be matched again, for performance reasons. Re-matching the same files may become necessary not only if you add additional hash sets to your FuzZyDoc database, but also if you delete hash sets, as that invalidates some internal links (if that happens, it will be shown in the cells of the result column).
    FuzZyDoc should prove very useful for many kinds of white collar crime cases, most obviously (but not limited to) those involving stolen intellectual property (e.g. software source code) or leakage of classified documents. The technology is still in a testing stage.
  • Matches with the FuzZyDoc database are presented in the same column as PhotoDNA matches and skin color percentages. That combined column is now more generically named "Analysis". A filter for FuzZyDoc matches is available. Sorting by the Analysis column in descending order now lists files with FuzZyDoc matches first (those files with the most confident matches for any hash set near the top, with lower percentages following), followed by PhotoDNA matches, if any, followed by pictures with no PhotoDNA matches (in descending order of their skin tone percentage). After that, irrelevant pictures are listed (picture with very small dimensions), and then files that are not pictures, and near the bottom black & white and gray scale pictures. Text color coding in that column now makes it easier to distinguish between different kinds of categorizations.
  • The web history extracted from Internet Explorer (Webcache* files) is now added to the event list.
  • Fixed possible errors when parsing UDF file systems.
  • Export List command: Option to copy files off the disk/image and link them from the HTML output. The links can be found in the Name column. The behavior is affected by two case report options: "Name output files after unique ID" and "Embed attachments in parent .eml file". An interesting layout alternative to the regular output of report tables.
  • File header signature searches at the byte level within pagefile.sys files are now conducted by default, to find e-mail fragments, .lnk shortcut files, pictures, etc.
  • Supports double-digit Windows disk numbers in disk imaging command line syntax.
  • Some minor changes about how colors are applied in the directory browser, especially if the directory browser does not have the input focus.
  • Automatically discards byte-level file carving hits in NTFS $MFT FILE records, as those records are already exploited when parsing the file system.
  • Automatically discards byte-level file carving hits for loose e-mails and Base64-encoded attachments as well as individual zip records if contained in known e-mail archives / zip archives (respectively), to avoid unnecessary duplication.
  • Now two different percentage types are available for output when matching documents against a FuzZyDoc hash database. A percentage based on the total text in the processed document gives you an idea of how much of the text in the document is known/was recognized, whereas a percentage based on the text represented by the hash set gives you an idea of how closely a document resembles the original document that the hash set is based on.
  • Since the days of Windows 95 (or perhaps even Windows 3.1?) users can press Ctrl+C to produce a plain-text representation of standard Windows message boxes in the clipboard. With message boxes in WinHex and X-Ways Forensics it works the same. Although this is an elementary feature in Windows for more than 20 years already and should be known to any experienced Windows user and although WinHex and X-Ways Forensics make users aware of that ("Did you know? ..."), the great majority of users for some reason still take graphical screenshots of message boxes and paste them into HTML e-mails, for example when they report error messages, although that is more work than simply pressing Ctrl+C and Ctrl+V and although it inflates the size of the e-mail unnecessarily, as a few ASCII characters need much less space them thousands of pixel values. That also means the screenshot will get lost if the e-mail is converted to plain text when being replied on, and of course the error message text will not be searchable in a graphical screenshot and cannot be conveniently selected and copied to the clipboard as text by the recipient, and the recipient cannot be sure of the exact Unicode value of certain characters for which multiple variants exist.
    Now in v18.4 it is even possible to copy a rudimentary ASCII representation of dialog boxes and almost all their control items (static text, push buttons, checkboxes, radio buttons, list boxes, and comboboxes) including their states (unchecked, checked, half checked) by pressing Ctrl+C with an active dialog box on the screen (not if an edit box with a selection has the input focus). Thus, Ctrl+C is now a very efficient way to share your settings in a certain dialog box with other users and let them copy strings for use in their own edit boxes, so that they don't have to type them, avoiding typos. The text representation is even more powerful than a screenshot because it shows the contents of edit boxes and list boxes completely, even if these controls have scrollbars and the contents exceed the physical boundaries of the controls on the screen. Unicode characters are supported. We suggest that users take screenshots of message boxes and dialog boxes only if absolutely necessary, for example if they wish to graphically highlight certain control items in a Photoshop or similar programs to get the message across.
  • The ASCII representation of dialog boxes can now also be used as a substitute for actual screenshots in the activity log of the case. If "Include screenshots in log" in the case properties is half-checked, that means that no actual screenshots of dialog windows will be taken, just the ASCII representation will be stored in the log. These details are included in a special way in the HTML output, so that they do not detract too much from the main log entries. Either they are output in a smaller font and gray color (if "Include screenshots in log" is fully checked) or simply as a pop-up when hovering with the mouse cursor over a space-saving placeholder rectangle, as known from Windows registry reports in X-Ways Forensics (if half checked) or not at all (if not checked). The placeholder rectangle and pop-up work best when viewed in Google Chrome, as that browser does not truncate the text if lengthy and even shows a preview of the first line in the placeholder rectangle.
  • In the conventional real screenshots of dialog boxes in the log as known from previous versions, pixels with the gray background color can be changed to pure white, to save toner/ink in case you are going to print your log at some time (anyway, please think twice and save paper).
  • Tentative support for 64-bit block numbers in Ext4.
  • Support for another variant of MOV files during caring and file type verification.
  • Fixed a bug in the HBIN file carving algorithm.
  • New flag "S" for file type signature definitions, which marks signatures that are good enough for the file header signature search (probably in conjunction with a carving algorithm), but not for file type verification because of occasional misidentifications. This flag should be very rarely needed.
  • Ability to change the nature of an image (disk or volume) and its sector size when creating the image. This is possible not only for .e01 evidence files, where both is explicitly defined in the internal metadata (compatible with other tools), but also for raw images (via external metadata, compatible only with X-Ways Forensics/Image v18.4 and later, lost if the image leaves the realm of NTFS file systems). Useful whenever the source of the data is not an ideal interpretation. For example if a reconstructed RAID actually represents a volume, not a physical disk, then you can already adjust the nature of the image accordingly. Or if the sector size of the reconstructed RAID or a disk in an enclosure does not match the sector size of the file system in a partition, you can adjust the sector size of the image accordingly. All of this will allow for smoother and more successful usage of the image later, in particular by users who do not know or care much about details such as image type and sector size. With the additional metadata present for a raw image, X-Ways Forensics does not need to prompt users for the nature of the image and its sector size even if under normal circumstances it would (for example because the image does not start with an easily identifiable partitioning method or volume boot sector).
  • Support for several thumbs.db variants improved.
  • Processes certain PST e-mail archives despite invalid internal checksums.
  • Italian translation of the user interface revised.
  • Settings in practically all dialog windows can now be conveniently saved to and loaded from files as needed, via the system menu. The system menu (also known as the window menu or control menu) is the menu that you get when right-clicking the caption of a window. This function can remember the selection states of the most important control types: check boxes, radio buttons, list boxes, combo boxes, and tree view controls. This works even if the controls are currently invisible. The settings are stored in files with the .dlg extension (for "dialog"), in the same directory as templates and scripts.
    The contents of edit boxes are also remembered. However, this function does not remember the contents/text labels of check boxes, list boxes, combo boxes, and tree view controls, e.g. which code page a check box represents in the Simultaneous Search dialog, which report tables exist in the Report Table filter list box, which external programs are listed in the Viewer Programs dialog window, which file types are listed in a tree view control etc. It also does not remember the order of controls or list items. It also does not remember settings in a dependent dialog window (which opens e.g. when clicking a "..." button). The functionality is not available for the Directory Browser Options dialog window. For those please continue to save and load .settings files by clicking the icons in the directory browser caption line.
    This new functionality is useful for example for the Export List command, where some users repeatedly need different settings for different purposes, and where the items in the list box are always the same (just the available columns), except after changing the language of the user interface.
  • Ctrl+C applied to dialog boxes now also represents selections in tree view controls in the copied text.
  • New Recover/Copy option to use the alternative names of files, if available, for the output. The alternative name, if one exists, can be seen in the directory browser in square brackets. For example, when parsing iPhone backups, X-Ways Forensics automatically changes artificial generic filenames back to what they were originally. Or, when parsing $I files from the Windows recycle bin, the corresponding $R files are given their original names. If for some reason you prefer the untranslated filenames when copying such files off the image to your own hard disk, for example because you wish to process these files with some external tool that expects the artificial filenames, then you can now use this option.
  • Improved support for Windows.edb of Windows 8 or newer. The snippets are added to the volume snapshot using the original filename when available (previously in a few cases only). The path of the original file is now always shown in the Metadata column (previously in a few cases only).
  • E-mails extracted from LiveComm.edb get an entry in the event list and receive an improved reconstructed header.
  • Prevented some illegal characters in XML tags of the Export List command.
  • It is now possible to more conveniently match pictures against the PhotoDNA hash database again, for example after having added some hash values to the database or after having assigned hash values to different categories, thanks to a new check box simply labelled "Again". You can still uncheck the "Already done?" check box for the whole picture analysis and processing operation to also discard the results of the skin color computation and precomputed thumbnails and regenerate both plus the PhotoDNA matches from scratch.
  • Matching pictures against the PhotoDNA hash database again is now much faster if during a previous run you have X-Ways Forensics store the computed PhotoDNA hashes in the volume snapshot. This is a new option. Saves the time to read the files from the disk/image again and to decode/decompress the JPEG data or other formats again (time-consuming for high-resolution photos) and to recompute the hash values. Please note that PhotoDNA hashes require considerably more drive space than ordinary hashes. Also, more than one PhotoDNA hash may be required for just one picture. It is recommended to store the hash values in the volume snapshot for future fast re-matching only if you expect your PhotoDNA hash database to change during processing of a case, for example if it is likely that you or your colleagues discover further relevant pictures in that case, forcing you to search for other copies of these pictures.
    Please note that with the "Again" option when re-using previously computed hashes, changes to the state of the check box "Recognize pictures even if mirrored" have no effect. That means if previously unchecked when hash values were computed for the first and stored in the volume snapshot, checking it later when re-using the stored hash values won't do any good.
    To discard stored hash values you can either take a new volume snapshot, or alternatively you may delete the file "PDNA" in the "_" subdirectory of the evidence object, where the volume snapshot is internally stored.
  • The X-Tension API has been further completed and now allows the development and use of so-called Disk I/O X-Tensions. These are snap-ins that sit between all analysis functionality and the user interface of X-Ways Forensics on the one hand and a disk/image/RAID/partition/volume from which sectors are read on the other hand. They can for example deal with full disk encryption and decrypt the data in all sectors read by X-Ways Forensics on the fly when needed, so that all relevant functions only get to see the decrypted data and can deal with it as if it was a normal disk/volume.
    The user may open a selected evidence object through such a Disk I/O X-Tension using a new command in the context menu of the Case Data window. After selecting the intended X-Tension DLL, if the DLL signals that it can successfully deal with the data in that evidence object, the case will remember which DLL that was chosen and automatically apply it next time when opening the same evidence object. Note that as always partitions count as evidence objects themselves. That way full disk encryption can be tackled as well as volume level encryption.
    For more information, developers and other interested parties please see this page. The demo X-Tension for Delphi has been updated and can now also serve as a Disk I/O X-Tension (just doing some nonsense stuff as proof of concept). This API addition shall encourage other developers to come up with decryption solutions for this interface. X-Ways will consider to do the same. As always, X-Tensions may be provided to the public as open or closed source, for free or for a charge, through our web site or any other channel.
  • Ability to delete all indexes for an evidence object by removing the "Already done" check mark. This will also clear the "i" flag from all indexed files in the volume snapshot.
  • Fixed a rare case where relevant (i.e. not duplicate/redundant) events in $UsnJrnl:$J were not output.
  • The Technical Details Report now shows the physical sector size of Advanced Format hard disks (4 KB) if they emulate a conventional 512-byte sector size logically.
  • Compensation for NTFS compression during the file header signature search now also works when carving at the byte level (completely or partially via flags).
  • Accelerated resolving of symlinks when taking a snapshot of volumes that contain many of the same.
  • More reliable hard-link counts in newly taken volume snapshots of Windows 8.1 installations, where the official hard-link counts in the FILE record headers often seem to be bogus.
  • Conditional cell coloring now allows the use of * as a wildcard, to color cells or entire lines if the target cell contains any text at all.
  • Ability to adjust size, timestamps and attributes of a file with the File | Properties dialog box also in X-Ways Forensics, not only in WinHex. Among other things, this allows to mark a file as sparse and artificially increase the size of a file instantly to sizes in the GB or TB range without writing data to it (valid data length remains the same). For example this can be used to manually prepare a skeleton raw image file, before sparsely filling it with data using copy & paste.
  • File type verification improved. File carving algorithm for .emlx.
  • Fixed an exception error that could occur when taking a snapshot of malformed FAT16 volumes.
  • User manual and program help were updated for v18.4.
  • Search in the registry viewer: Improved display of hits in the data of values.
  • A rare exception error was fixed that could occur when extracting metadata from corrupt DBX e-mail archives.
  • A rare exception error was fixed that could occur when carving individual e-mail messages (.eml files).
  • A rare exception error was fixed that could occur when carving .dxf files.
  • Fixed sender and recipients filter for processed original .eml and other single-mail files. These filters did not work in v18.2 and v18.3.
  • Some inconsistencies within the inclusion of previously existing files and directories into snapshots of Ext3/Ext4 volumes in v18.3 were fixed.
  • Ability to decompress files in 7z archives whose compression ratio is enhanced by a BCJ pre-processing filter.

WinHex screenshot (620 pix)

Versienummer 18.4
Releasestatus Final
Besturingssystemen Windows 7, Windows XP, Windows Server 2003, Windows Vista, Windows Server 2008, Windows Server 2012, Windows 8, Windows 10
Website X-Ways Software Technology
Bestandsgrootte 2,31MB
Licentietype Shareware

Door Bart van Klaveren

Downloads en Best Buy Guide


Meer historie

Reacties (1)

Wijzig sortering
Gebruik hem best veel, lekker overzichtelijk. En een van de weinige of enige die SD kaarten met bestandssysteem en al kan openen.

Op dit item kan niet meer gereageerd worden.

Apple iPhone XS Red Dead Redemption 2 LG W7 Google Pixel 3 XL OnePlus 6T (6GB ram) FIFA 19 Samsung Galaxy S10 Google Pixel 3

Tweakers vormt samen met Tweakers Elect, Hardware.Info, Autotrack, Nationale Vacaturebank, Intermediair en Independer de Persgroep Online Services B.V.
Alle rechten voorbehouden © 1998 - 2019 Hosting door True