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. Je kunt ook een cookievrije versie van de website bezoeken met minder functionaliteit. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , reacties: 1, views: 2.063 •
Bron: X-Ways Software Technology

WinHex logo (60 pix)X-Ways Software Technology heeft versie 17.1 van WinHex uitgebracht. WinHex is niet alleen een universele hex-editor, maar het 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 tot over de duizend euro voor de meest uitgebreide versie. In deze release zijn de volgende veranderingen en verbeteringen doorgevoerd:

What's new?
  • Extracts much more nicely formatted data from Skype main.db database files than before, such as phone calls, sent text messages (SMS) and chats.
  • Improved file type verification of encrypted MS Office 2007/2010 documents.
  • Better support for unusually deep subdirectory nestings in Ext file systems.
  • Previously, it was possible to open VMKDs only if their name was recorded correctly in the VMDK descriptor. For self-contained VMKDs, this requirement led to the effect that VMDKs would no longer be opened if renamed without updating their internal descriptor. While this requirement continues to stand for VMDKs consisting of multiple parts (the names of the remaining parts must be recorded correctly), this is no longer required for VMKDs consisting of only one part or in the case of multi-part VMKDs, it is no longer required for the first part.
  • Now supports non-standard (non-Adaptec/JetStor typical) parity start components for RAID level 6 with backward parity when internally reconstructing RAIDs, as seen in Synology hardware.
  • Now supports backward parity dynamic for RAID level 6, with standard or non-standard parity start components.
  • Ability to turn on or off usage of the copy log file and configure the copy log right in the Recover/Copy dialog window. That the copy log is written to the _log subdirectory of the case is now optional. It can now also be written to the selected output folder along with the copied files. This is more convenient if you wish to pass the copy log on to others.
  • For reasons of convenience, after exploring an object from a recursive list, the .. item is now marked with a "Back" arrow and allows to return to the previous recursive list, just like the Back button in the toolbar, and does not navigate to the parent directory of the explored object. If in some rare situations you do want to navigate to the parent directory of the explored object, just use the Navigation submenu of the directory browser context menu or press the Backspace key on your keyboard.
  • When restoring the last window arrangement upon start-up, X-Ways Forensics now also restores search hit list and event list mode if applicable and reselects the last search hit or event that was selected, so that you can resume even review work in search hits and event lists right where you left it, even in the case root window.
  • Ability to highlight search hits for GREP expressions in documents in Preview mode just like ordinary search hits, as long as the viewer component can find it (not if the search hit is located for example in the document metadata which the viewer component does not represent in Preview mode).
  • Russian translation of the user interface.
  • Extracts much more nicely formatted data from Skype main.db database files than before, such as phone calls, sent text messages (SMS) and chats.
  • Improved file type verification of encrypted MS Office 2007/2010 documents.
  • Better support for unusually deep subdirectory nestings in Ext file systems.
  • Previously, it was possible to open VMKDs only if their name was recorded correctly in the VMDK descriptor. For self-contained VMKDs, this requirement led to the effect that VMDKs would no longer be opened if renamed without updating their internal descriptor. While this requirement continues to stand for VMDKs consisting of multiple parts (the names of the remaining parts must be recorded correctly), this is no longer required for VMKDs consisting of only one part or in the case of multi-part VMKDs, it is no longer required for the first part.
  • Now supports non-standard (non-Adaptec/JetStor typical) parity start components for RAID level 6 with backward parity when internally reconstructing RAIDs, as seen in Synology hardware.
  • Now supports backward parity dynamic for RAID level 6, with standard or non-standard parity start components.
  • Ability to turn on or off usage of the copy log file and configure the copy log right in the Recover/Copy dialog window. That the copy log is written to the _log subdirectory of the case is now optional. It can now also be written to the selected output folder along with the copied files. This is more convenient if you wish to pass the copy log on to others.
  • For reasons of convenience, after exploring an object from a recursive list, the .. item is now marked with a "Back" arrow and allows to return to the previous recursive list, just like the Back button in the toolbar, and does not navigate to the parent directory of the explored object. If in some rare situations you do want to navigate to the parent directory of the explored object, just use the Navigation submenu of the directory browser context menu or press the Backspace key on your keyboard.
  • When restoring the last window arrangement upon start-up, X-Ways Forensics now also restores search hit list and event list mode if applicable and reselects the last search hit or event that was selected, so that you can resume even review work in search hits and event lists right where you left it, even in the case root window.
  • Ability to highlight search hits for GREP expressions in documents in Preview mode just like ordinary search hits, as long as the viewer component can find it (not if the search hit is located for example in the document metadata which the viewer component does not represent in Preview mode).
  • Russian translation of the user interface.
  • Ability to create forensic physical skeleton disk images
    Another typical X-Ways feature that cements X-Ways Forensics' position as the tool that gives its users the greatest amount of control when selecting/targeting/filtering data at any conceivable level: The ability to create forensic physical skeleton disk images that contain only those sectors that are needed for certain purposes, while maintaining compatibility with other tools. Forensic license only. These can be sectors with partition tables, file system data structures, their neighboring sectors as well as sectors with file contents or any sectors in unpartitioned no man's land. A skeleton image is typically sparsely populated with data, with vast areas in between remaining undefined, so that it makes sense to utilize NTFS sparse file technology for it. Unwritten areas in the skeleton image will act as if zeroed out when read later.
    You start skeleton imaging by invoking the File | Create Skeleton Image menu command. Which sectors from then now will be copied into the image is defined indirectly, by making X-Ways Forensics read those sectors from the source disk that are needed for a certain purpose. When the target image is open in the background, next you typically open the disk or partition or open and interpret the image that you wish to acquire partially. That way it will be automatically defined as the source, and that way even read operations during the important opening or interpretation step are triggered already, when partition tables and boot sectors have to be parsed, so that these essential data structures that define partitions and identify file systems are included in the skeleton image.
    So after opening a partitioned physical disk, you have a "basic skeleton" in your target image: Partition tables pointing to partition boot sectors or nested partition tables, whose function is to support all the other data in between (file system data and user data). If you also wish to ensure that from the skeleton image it is possible to take a volume snapshot of a certain partition, i.e. get a listing of all files and directories referenced by the file system in that partition, then you open that partition from the source hard disk so that a volume snapshot is actually taken. Again, all the sectors read from the source hard disk in the process are simultaneously copied to the image, and that is the file system data structures, e.g. $MFT in NTFS, all directory clusters in FAT, and the catalog file in HFS+. That adds considerably more administrative data and also metadata to your skeleton image, but still no or almost no user contents. Unrelated sectors that are not used by the file system, are not read and therefore not copied. That also means that the ability to find previously existing files in the skeleton image will be limited.
    If you wish to include an arbitrary range of sectors in the image, you only need to find a way to make X-Ways Forensics read those sectors. For example, to include sectors from number 1,000,000 to 1,000,999, define those 1,000 sectors as a block and hash that block (in Disk mode) using the Tools | Compute Hash command, or run a physical search in that block only. Or, to acquire an unusually large partition gap between partition 1 and 2, you could hash the virtual file representing that gap. You can also manually navigate to any single sector of interest that you want to be included (e.g. Navigation | Go To Sector) or use any of the file system navigation menu commands. All of that works because reading sectors triggers their acquisition.
    However, if you wish to specifically acquire selected files, that is easier, and it might be a good idea to turn off the indirect acquisition of any sectors that are read for whatever purpose along the way, so that for example file A that you preview is not acquired by the preview action already although it turns out to be irrelevant. For that, you can change the state of the skeleton image that is open in the background to "idle", using the State command in the File menu. In "idle" mode, only the "Add to [name of the skeleton image]" command in the directory browser context menu allows to acquire selected files (by temporarily activating the image and triggering read operations), .
    If you wish to include some operating system files, for example, such as Windows registry hives, explore the partition recursively from the root directory, filter for those files and invoke the "Add to" command in the directory browser context menu. (Only available if no evidence file container is open in the background for filling at that time.) The examiner who only has the resulting skeleton image will consequently be able to view the hives and create a registry report about them, assuming you had already copied the file system data structures which are required to find out which sectors contain the data of the file.
    The dialog window to change the state of the target image also allows you to close it, i.e. stop the acquisition for the moment or finalize the image. The same skeleton image can be further completed at any later time by selecting it again with the "Create Skeleton Image" command, but then you choose to not overwrite, but to update it.
    As you see, you have full control over what data will make it into the image. The methology just assumes that you have some understanding of what data you want/need and, should that data not be stored in ordinary easy-to-select files, where to find it/how to get it physically. The sectors can be targeted in any order. Multiple reads of the same sectors don't change anything in the skeleton image and have no negative effect, except they may cause unnecessary duplicate lines in the optional log file that X-Ways Forensics can produce. Such a log file is created in the same directory as the skeleton image and will list all sector ranges that were copied, optionally along with the hash value of each sector range, which allows to manually verify the data in certain areas should there ever be doubt about it. If you use the "Add to" command to copy files to a skeleton image, the name of each such file will also be output in the log, followed by the sector ranges that correspond to to it (more than one if the file is fragmented or if X-Ways Forensics simply chooses to copy sectors in multiple chunks).
    You may want to convert the resulting raw skeleton image into a compressed and/or encrypted .e01 evidence file and hash it or compress it with WinRAR or 7Zip etc. before passing it on to other users. The compression rate will be unusually high if the skeleton image is only sparsely populated, and the speed of reading extremely high because undefined/unallocated areas do not have to be read from the disk. For your own use, you can just keep it as is since it does not use as much drive space as the nominal file size suggests thanks to NTFS sparse storage. If you wish to copy the raw skeleton image, be sure to copy it as a sparse file (can be done in X-Ways Forensics using the Tools | File Tools | Copy Sparse command) so that the copy will also be a sparse file and only takes as much drive space as the original file. A conventional copy command would copy even the vast unused and unallocated areas within the sparse file as binary zeroes.
    To verify that the data transferred to a skeleton image has not changed, such an image can be hashed entirely, just like an ordinary image. Alternatively, it is sufficient to hash the sector ranges again that were actually transferred, according to the .log file and compare the hash values to those according to the .log file. An automated function for that might be introduced in a future release. To verify whether the .log file is unchanged, it will hashed itself when closed, and the resulting valuable all encompassing hash value is stored in a .log.log file. It might be desirable to also verify that all unused areas in a skeleton image are still unallocated/filled with binary zeroes.
    Benefits of skeleton images:
    • Partial image, saves drive space.
    • Quick to create, especially when acquiring remote hard disks through a slow network connection using F-Response.
    • Transports/reveals only specifically targeted data, excludes unrelated data, as may be required by law, common sense, time pressure or the customer.
    • Ideally suitable for technical data structures (partition tables, file systems) and files in a file system as well.
    • Ability to acquire all essential file system data without knowing anything about the file system and in which sectors its data structures are stored.
    • Result works exactly like a conventional raw image of the disk for all the intended purposes if adequately prepared, with original offsets and relative distances between data structures preserved (unlike in an evidence file container).
    • The file format is universal, and all forensic tools that support raw images have a chance to understand the data, unless they need more data than was included or already don't understand the partitioning method or file system etc. of the original complete disk/image.
    Caveats:
    • Note that a search hit list on the screen with context previews around the search hits for example will cause a lot of read activity, so you may want to change the state of the skeleton image to idle mode when it is open in the background in certain situations.
    • To avoid that the start sectors of files or directories that you merely click in the directory browser in Partition/Volume mode are copied to the skeleton image (because such a click automatically jumps to the respective 1st sector), you can navigate the directory browser in Legend mode instead, or have to change the status of the image to "idle".
    • Reading data from most extracted files such as e-mail messages, attachments, files in zip archives, video stills, pictures embedded in MS Excel spreadsheets etc. do not trigger corresponding read operations at the disk level, so they cannot be copied. Skeleton images are suitable only for files at the file system level, not at any other level seen in volume snapshots. Use evidence file containers instead for such purposes.
    • Note that to an unsuspecting examiner a skeleton image may look very much like an ordinary complete image. Such an examiner must be made aware of the incomplete, sparsely populated nature of the image. Unlike in a logical evidence file container, files whose contents are not contained in the image are not specially marked as such in a volume snapshot taken of an incomplete physical image. X-Ways Forensics v17.1 and later informs the examiner of the nature of an image when it's added to a case, if it detects a skeleton image.
  • A comparison of evidence file containers and skeleton images can be found here.
  • Program help updated.
  • New menu command Tools | File Tools | Copy Sparse introduced, which can copy any selected file, but preserves the sparse nature of an NTFS sparse file in the destination file. That means for example when copying a 1 TB skeleton disk image that only has 100 MB of data allocated, the copy process will finish almost instantly because only 100 MB out of 1 TB of data has to be copied. Conventional copy functions do not preserve the sparse nature of a file and copy the entire nominal file size.
  • Slightly improved treatment of remote network drives, network shares, and F-Response connector volumes.
  • Ability to automatically verify skeleton images immediately after creation or at any later time. This is a special verification option that checks all the individual hashes for copied sector ranges according to the .log file, and also verifies that the .log file itself is still authentic by checking that file's hash values and comparing it to the one in the .log.log file (the log file about the log file, if such a secondary log file was created). Compared to ordinary hash computation and verification, this method can save a lot of time. It just depends on the amount of actually acquired data (e.g. 100 MB), not the total size of the source disk / nominal size of the image (e.g. 1 TB).
  • Option to prevent unencrypted copies of AES-encrypted .e01 evidence files. Can be useful if you are afraid that recipients of an encrypted image handle it without care and for reasons of convenience convert it to an unencrypted image.
  • Ability to uncover JPEG 2000 pictures in PDF documents.
  • Provides timestamps from Internet browser SQLite databases as events.
  • New extraction methods for MBOX and DBX updated to also produce slim .eml files without embedded attachments.
  • When printing files with a cover page, the header line that specifies which user and which program and version created the print job is now optional. Useful if you wish to show the cover page to witnesses or the suspect who should not know the username of the examiner.
  • More information about exception errors in error.log files.
  • Ability to change the detected sector size of a physical hard disk that WinHex works with, via Tools | Disk Tools | Set Disk Parameters. Remember you should also adjust the sector count accordingly. For example, if you change the detected sector size from 512 bytes to 4 KB (i.e. you multiply it by 8), then you also need to divide the total number of sectors by 8 to keep the same total detected disk capacity (assuming the capacity was detected correctly).
  • PDF metadata extraction further revised.
  • Option to add more Windows registry events to the event list, when generating registry reports. These events depend on the selected report definitions and are much more specific than the generic registry hive events (which are mostly "Key changed").

WinHex screenshot (620 pix)

Versienummer:17.1
Releasestatus:Final
Besturingssystemen:Windows 8, Windows Server 2012, Windows Server 2008, Windows Vista, Windows Server 2003, Windows XP, Windows 7
Website:X-Ways Software Technology
Download:http://www.winhex.com/winhex.zip
Bestandsgrootte:1,96MB
Licentietype:Shareware

Reacties (1)

Ooit een keer gebruikt om een applicatie te 'tweaken'. Maar zeker een handig programma!

Op dit item kan niet meer gereageerd worden.



Populair:Apple iPhone 6DestinyAssassin's Creed UnityFIFA 15Nexus 6Call of Duty: Advanced WarfareApple WatchWorld of Warcraft: Warlords of Draenor, PC (Windows)Microsoft Xbox OneApple iOS 8

© 1998 - 2014 Tweakers.net B.V. Tweakers is onderdeel van De Persgroep en partner van Computable, Autotrack en Carsom.nl Hosting door True

Beste nieuwssite en prijsvergelijker van het jaar 2013