28 replies to this topic

[misty]

After stumbling across a number of references to DMDE on this forum (the majority of which appear to have been made by Wonko - if it wasn't free I'd suspect he was on commission  ) I thought I'd try it out. DMDE appears to be a powerful disk editor - even in form of the slightly limited Free Edition. Description from the DMDE Website -
 

DMDE is a powerful software for data searching, editing, and recovery on disks. It may recover directory structure and files in some complicated cases through the use of special algorithms when other software can't help.

DMDE has a number of freeware features such as disk editor, simple partition manager (e.g. allows undelete a partition), a tool to create disk images and clones, RAID constructor, file recovery from the current panel. Paid editions support file and directory recovery without restrictions, DMDE Professional Edition has additional features to recover data for clients (compare editions)......

DMDE supports FAT12/16, FAT32, NTFS, Ext2/3/4, and works under Windows 98/ME/2K/XP/Vista/7/8 (GUI and Console), DOS (Console), Linux (Terminal)......

Disk imaging includes creating, writing images back to disk, disk cloning, and supports handling of I/O errors (bad sectors)......

DMDE does not require installation and runs just after extracting.

I have barely scratched the surface of this tool, however I did complete a couple of quick disk imaging tests that I thought I'd share here. The test system was a Lenovo Thinkpad T400 laptop with a 5400 RPM SATA-II HDD. I copied a 8GB USB Flash Drive (SanDisk Facet - appears as a Fixed Type Disk) to the internal HDD. I've not had the USB drive for long, so it's not accumulated too much cr@p (in terms of disk content and deleted files). At the time of testing it had 0.99 GB of used space.

The first test was a straightforward disk image. This took approximately 5 minutes and 52 seconds - the program doesn't give any feedback in terms of time taken to complete an operation so I used a stopwatch.

No compression options were available so I did a second test - this time saving the image to a NTFS compressed folder. This test took approximately 6 minutes and 42 seconds. The Size on disk: of the resulting image file was 2GB.

I then did a few quick tests in WinHex for comparison. Quick note - WinHex requires a licence in order to create a RAW type disk image, as the Free version will only capture in the propriatory .whx format.

I tested WinHex using three different compression settings available for RAW type images -

• No compression - took 6 minutes 32 seconds, Size on disk: 7.45 GB.
• NTFS compression - took 9 minutes 48 seconds, Size on disk: 2 GB.
• NTFS Sparse - took 6 minutes 34 seconds, Size on disk:2.12 GB.

It's worth mentioning that I tested this twice. On both occasions I ran WinHex and DMDE in Windows PE and used the same HDD and USB drives.

The DMDE results were almost identical in terms of the time taken to capture the image. The WinHex results varied by up to 37 seconds - on the first run the NTFS sparse compression took 5 minutes 57 seconds, following a reboot and retest it took the 6 minutes 34 seconds referred to above.

WinHex is a fantastic piece of software and results are likely to vary significantly depending on the content and type of disk being imaged - I am not implying in any way that DMDE is superior to (or inferior to) WinHex! These result are for comparison purposes only.

Regards,

Misty

[Wonko the Sane]

Well, you really just scratched (and only lightly) the surface.

DMDE is a data recovery tool, it's imaging capabilities are only a "side effect".

 

Try corrupting (on purpose) a MBR partition table and/or a NTFS filesystem.

Then try using DMDE to recover the data on the disk/image.

 

WinHex as well is probably (in the "high level" "WinHEx Specialist" and "X-Ways forensics" editions) the best program ever made to deal with disks and filesystems (and sold at what I consider a "fair" price for the capabilities it has), and of course also in the case of Winhex, the imaging part is a "marginal" side effect.

 

But you cannot beat the feature/price ratio of DMDE, no way, the free for personal use version has only a very small set of limitations and even the "top" version is sold at an extremely (still IMHO) fair price, and it has the advantage of having both a Linux and a Dos version (AND it can run on win9x/Me).

 

Both, however, are not "for the newbie", you need a more than average knowledge on disks and filesystem to use them successfully.

 

Imaging a device is the simplest and most straightforward thing to make with *any* imaging tool or "dd-like" programs.

 

There are tens of "dd-like" tools for windows, including our friend's erwan.l's Clonedisk (which has an awful number of added useful utilities ), a number of them are listed here:

http://www.911cd.net...showtopic=16534

http://www.msfn.org/...aging-software/

http://reboot.pro/to...est-for-ddexe/ 

 

I mean, it is like using MS Word to replace spaces with Tabs in a .txt file (which BTW it is something that I actually do, sometimes ).

 

Wonko

[misty]

Try corrupting (on purpose) a MBR partition table and/or a NTFS filesystem.
Then try using DMDE to recover the data on the disk/image.

Will try this later. Sounds fun - I clearly need ot get out more!

BTW, I agree that the price of both WinHex (+ X-Ways Forensics) and DMDE seems fair - you get what you pay for. I was however very pleasantly surprised by the Free Edition of DMDE. My experiments with the Windows Forensic Environment have mainly been (so far) for acquisition purposes and I've therefore focused on the disk image side effect capabilities.

• In addition to disk imaging, it's also possible to view an existing disk image partition structure and partition file systems (if supported - and several are) - using a folder tree and various other views.
• Based on the documentation it looks like Ext 2/3/4 file system support is included - making it possible to recover files from Linux systems under Windows.
• DMDE is also capable of browsing hidden partitions and extracting any required content.
• It looks like it will prove very useful for general recovery purposes, for backing up partition tables, volume boot records, as a hex editor, the list goes on.

@Wonko
Thanks for the links to the disk imaging software - all threads that I have viewed in the past, however it won't hurt to re-read them - particularly as I'm getting better at knowing where my towell is - I may get something more out of the links this time around!
 

I mean, it is like using MS Word to replace spaces with Tabs in a .txt file (which BTW it is something that I actually do, sometimes ).

You're weird

Regards,

Misty

[Wonko the Sane]

You're weird 
 

Sure I am , but actually not as much as you may think.

What not many people know is that Word (unlike a number of word processors/text tools) have handy "special characters" aliases.

I.e. ^t =Tab ^p=Paragraph ^l="soft" line break, etc.

and it is actually pretty fastish in character substitutions.

 

Wonko

[erwan.l]

Very interesting thread : did not know about DMDE nor about Winhex forensics features.

 

I'll be playing with DMDE soon.

 

Another recovry tool I have been using a few times with success : UFS Explorer .

 

/Erwan

[bshavers]

 My experiments with the Windows Forensic Environment have mainly been (so far) for acquisition purposes and I've therefore focused on the disk image side effect capabilities.

 

That is actually the original intent of WinFE, a disk acquisition platform.  It is also probably the best use of WinFE as well.  But with the input and further development from many (Colin Ramsden, yourself, RoyM, and quite a few others), it is now a platform that can conduct a full forensic analysis.

 

I find it amazing that not that many years ago, us forensic guys would spend time to make a bootable floppy (hahaha) and squeeze one or two really small DOS imaging programs on it.  Now, in only a few minutes longer than making a forensic boot floppy, a complete forensic operating system with full-fledged forensic applications  can be made.  That is serious progress.

[Wonko the Sane]

I find it amazing that not that many years ago, us forensic guys would spend time to make a bootable floppy (hahaha) and squeeze one or two really small DOS imaging programs on it.  Now, in only a few minutes longer than making a forensic boot floppy, a complete forensic operating system with full-fledged forensic applications  can be made.  That is serious progress.

Yes, and no. (about progress)

 

The "old" paradigm was:

• you only "touch" the "evidence" hard disk to make an image (or a clone) of it, making d@mn sure that while doing this you did not alter the evidence in any way.

(also because you were running a very limited environment from the floppy)

 

The "new" (nice) tools allow to:

• you only "touch" the "evidence" hard disk to make an image (or a clone) of it, making d@mn sure that while doing this you did not alter the evidence in any way.
• AND you can now do more things (or you may be tempted to do more things) because you have a more friendly or more featured environment

or, in other words, there are more possibilities to do something *wrong* (remember that with WinFE booted one has avoided automagic "logical" mounting, but direct access to disk is still possible)

 

So, IMHO there is still space for the "most minimal" WinFE build that can do ONLY the imaging (in a safe way) and that can do that in the least possible time.

 

The point is now (or should be) over which program can make a dd-like, optionally compressed and/or other *as plain as possible* or *commonly used image format* in the least possible time, then, once found it, remove form the WInFE *everything* that is not strictly needed for running that program.

 

If you prefer, I would see as a nice thing to have a "limited" edition for the good guys that only collect the evidence, and/or a multiboot option between "Image only WinFE" and "Full Featured WinFE".

 

Wonko

[bshavers]

I think you just solved the issue with a multi-boot WinFE; Imaging-Only WinFE and All-Out-Forensic-Platform WinFE.  A basic image-only WinFE is faster to load up anyway, risks fewer issues with running non-necessary programs, and can be restricted to image with any number of imaging apps (FTK Imager, dd this-that-and-the-other apps).  That cuts the operator error rate down to about 10%...

 

Mini-WinFE is that middle ground, although with just XWF, you have a full-fledged forensic suite of ability to do an entire exam (and image...).  What has made WinFE versatile has been the modifications to make it dummy proof, such as with Colin Ramsden's write protect app and building with Winbuilder.

[misty]

...in other words, there are more possibilities to do something *wrong* (remember that with WinFE booted one has avoided automagic "logical" mounting, but direct access to disk is still possible)...

@Wonko
This very much depends on the WinFE base - if it's built upon WinPE 4.0 or 5.0, then the disk can also be write protected - preventing direct disk access. This write portection is not that easy to remove - in my tests Diskpart failed to execute commands documented elsewhere as working. Colin Ramsden's write protect tool (and I believe erwan.l's Clonedisk) can remove this write protection.

If an x86 WinPE 2.* or 3.* is used as a base then the disk can be write protected fairly early on in the boot process by using Mr Ramsden's WProtect tool with the relevent switch - in winpeshl.ini.

If an x64 WinPE 2.* or 3.* is used then you are in trouble! Not you personally, as I suspect that hell might freeze over before you use a 64-bit WinPE

Regards,

Misty

[misty]

I think you just solved the issue with a multi-boot WinFE; Imaging-Only WinFE and All-Out-Forensic-Platform WinFE...

How about both on the same device? It's very easy to create a multiboot WinFE UFD device and the possibilities are endless. How about -

• WinFE 5.0 (x86)
• WinFE 5.0 (x64)
• WinFE 3.1 (x86)
• WinFE 5.0 (x86) - with .NET Framework and HTA support
• WinFE 3.0 (x64) - with programs not in the wim file
• WinFE 5.0 (x86) - Special edition - Disk imaging only
• WinFE 3.1 (x86) - For use on Low Memory
• Etc...

All bootable from the standard BCD menu! Not that easy to script in MistyPE, but very easy to provide instructions for the end user. In regards to cutting down on operator error - that's a question of the skills and training of the end user - I just do my best to provide an easy build method in my projects. It's pretty easy for anyone to mess up a system if they don't know what they're doing - even with a very basic WinFE.

 

Regards,

 

Misty
 

[Wonko the Sane]

Yep , in the immortal words of Douglas Adams:

A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools.

As you know, I am very partial to a particular approach, have the least possible amount of things and add (later) ONLY what is actually needed, IF needed at all.
This is traditionally the opposite of the approach most the good guys that develop PE builds have (common to the one which the good guys that develop Linux distro's have) which is usually something like:

Let me see how I can jam into this build 6 different text editors, 4 partitioning tools, 11 archive managers, 3 browsers, 5 completely unneeded tools to change the looks of the UI and 4 other programs that noone will ever need/use. Since one of the 7 (lousy) text editors needs a large subsystem (let's say Cygwin or .NET) let me integrate this into the build)

The result is a largish thingy that takes forever to load and that is used - maybe - only up to 47.8% of it's capabilities.
Though the multi-boot (several builds with different "levels" of completeness)is easier to put together, I still believe that - particularly in a "vertical" kind of PE as a forensic one should be - the "ideal" solution would be a very minimal "core" (small, fast loading) with ONLY one scope/capability (that of making an image) and being d@mn good/fast at it.
Then you can have a separate image (or more than one) that, thanks to mountpoints/junctions/symlink capabilities of modern NT based systems can be added/integrated into the core filesystem only on request or "when needed".

The point that needs to be checked/verified is the hardware compatibility of the various PE releases, I have no idea if PE 4.0/5.0/5.1 have some (or none) of the (IMHO senseless) architecture/hardware limitations of the corresponding "main OS", i.e. PAE, NX and SSE2:
http://windows.micro...-is-pae-nx-sse2
If there are no such requirements, it would make sense to make only one "version" of PE, let's say a 4.x, that can have the benefits of the improvements with regards to SanPolicy (or *whatever*) and being compatible with the most hardware, or even a 5.x one.
Otherwise one would need to make two base versions, a 3.x one to be used on older hardware and - at this point - a 5.x one for the newer one.

As it is/was demonstrated in the XPCLI experiments, there is actually no real need - at least for the very vertical "just image" version - for a shell at all, cmd.exe is good enough and graphical imaging tools can be started from it alright.

What I am dreaming of (a man can dream, can't he? ) is something *loosely* similar to the partition logic build:
http://partitionlogic.org.uk/
you boot it and manage partitions with it (and nothing else).

Still there is a lot of work to create the most minimal build that can run a disk imaging program (and nothing else, and I mean *nothing else*) and to benchmark various imaging programs until we can find the faster one.



Wonko

[bshavers]

I was imaging two versions of WinFE, maybe three, on one multi-boot device.  (1) Bare bones imaging WinFE for when it will only be an imaging use, (2) Mini-WinFE when there may be some light work to do while/before imaging such as triage or copying specific files, and (3) a big fat WinFE for those rare times where the computer can't leave the premise and as much as a forensic as possible needs to be done on the spot. 

 

The only bells and whistles needed is wallpaper just in case the client happens to be looking over your shoulder, it looks professional to have your logo for wallpaper.  Everything else, not needed.

[Wonko the Sane]

It is not that much different, and surely "your" way would be much easier to build (but possibly more difficult to maintain/distribute).

What I had in mind was something that booted (NO multiboot option) to your #1, that, by supplying a command (password protected with password of "intermediate" level), would become #2 and, by supplying another command (password protected with password of "advanced" level), would become #3.

Still, and independently from the "multi-boot" approach, the main issues are deciding which PE version(s) to use as "base" and find the faster/more convenient imaging tool.


Wonko

[misty]

Hi Wonko

Opinions on what is required in a minimum, imaging only, WinFE will vary from one person to the next. In an ideal world we would have one program that -

• can be executed as the shell
• that can't be accidentally closed down (as this would end the WinFE session)
• that is able to toggle the read/write flag on a disk (in WinFE 4.0/5.0 - and can set all disks as read only during the boot process in WinPE 2.*/3.*)
• can mount a disk if required
• can also image - quickly, with compression, in a standard format.

I haven't actually tested clonedisk's imaging capabilities, however I suspect that erwan.l could modify it to meet many of these requirements - if he were willing to do so - removing a lot of the options from the current UI to make it harder for the End User to do any damage.

In the meantime, I'd suggest the following -

• bblean shell with a minimal set of menu options
• WProtect.exe - to set all disks as readonly during boot and to remove the readonly flag on the disk the image is being saved to.
• A basic file manager - just because it's bloody useful to have one.
• An imaging program.

Not quite as minimal as your pipe dream, but not far off. And WProtect can also be used to add drivers for those people that don't like the command line. Now I know that cmd.exe can be used as a shell, however it's very easy to accidentally close it and end the session (possibly mid image capture). Also there are an increasing number of people that are uncomfortable using a command line interface. In fact a limited bblean menu would cause less damage - cmd could wreak havoc in the wrong hands.

In regards to the base - WinFE 3.* is lean and I suspect it runs on more hardware than more recent versions. The only downside is that it will write a disk signature if one is not already present - a fairly well documented fact. As you once pointed out to me, this doesn't in itself prohibit it's usage in digital forensics. I'm sure it is possible to further slim down all versions of WinFE as there's an awful lot of cr@p in the registry. Based on my own tests WinFE 4.0/5.0 appears safer to use as it (in my tests) was able to write protect the disk much earlier in the boot process - preventing any disk signature from being written.

Now which imaging program? In an ideal world we would have x number of testers using a large range of hardware all following the exact same proceedures/software/settings in order to benchmark the various options. E.g.

• Use same build of WinFE
• Hash the evidence disk before first run.
• Image a disk and record the time taken, compression ratio, integretity, etc
• Reboot and hash the evidence disk after a capture
• Start again and test a different software.
• Make sure that for each test the evidence disk remains the same.
• After each test the device used to capture the image to should be zero'd so that evidence and capture disks are in the same state for each software being tested.

Perhaps run the tests again with a different version of WinFE - as long as each tester is using the exact same WinFE 3.1, WinFE 4.0, etc, and recording their result accurately.

Now in terms of booting the evidence PC - how about connecting this via a crossover cable to another system (a laptop for portability?) then -

• PXE boot WinFE
• start the network
• connect to a share on the laptop
• write to the share

I could be wrong however I suspect that PXE booting is better suppported that USB booting on older hardware. It's also usually a lot faster to write to a networked drive that USB attached storage. It's pretty easy to set up a laptop as a PXE server. If PXE boot is not supported on the evidence system then fall back to CD/DVD or USB.

Just some thoughts.

Regards,

Misty

[Wonko the Sane]

As I see it, the Disk Signature can be worked around by pre-booting to grub4dos and check it (and image the MBR if needed).
I really have no idea if the mentioned "Windows 8 requirements" would apply also to a minimal or not-so-minimal PE.

About the testing, I would, as a pre-test, forget about both the WinFE environment and the forensic soundness (via hashing) .
I mean when tasks of this kind are to be taken into account, it is easier to use "differential benchmarking".

As an example, take the (RAW or VHD) image creation procedure I just posted (for a completely different reason/need) here:
http://www.msfn.org/...ions/?p=1076215
we could put together something like that, of - say - 2 Gb and "populate" it "locally" with - still say - one of the available WAIK .iso's from MS, let's say the KB3AIK_EN.iso, around 1.8 Gb, something that *anyone* playing with PE's has (or should have).
Then we choose a Virtual Disk driver that works (with RAW images) on *any* Windows NT, let say Total Mounter or Arsenal image mounter and we mount the image.
Then each tester runs two tests, one using the simplest (and slowest) tool one can find, I would of course suggest dsfo (which would also calculate the MD5 while imaging, besides giving the time it takes, and in old tests it was on the "slowish side") to set the "reference", and one using the tool at hand.
Let's say that on my system (under XP and underpowered for today "standards") the dsfo takes 101.515s.
Clonedisk takes 101.531s
DMDE takes around 108s
FTKimager Lite 85s
(just tested )
Of course this is "plain" dd-like images.
Roughly I would say that FTKImager (even if it is a mass of bloat, around 75 Mb vs. dsfo 6.637 bytes) passes to next level, level1, while both Clonedisk and DMDE remain, together with the dsfo, within the "plain, slow" realm, on "level 0".
It should not be that difficult/long to divide a number of tools between "level 0" and "level1", and then one might do some comparative tests among those fewer ones that managed to get to level1 and get still fewer onto level2.
Of course given that I can count all the people, including Colin, Brett and you (and myself for the little I did), that actually contributed *something* to WinFE without needing to take my shoes off , it might take forever to have a bunch of these tests/results.


Wonko

[bshavers]

Eric Zimmerman has done some great test with imaging here: https://docs.google....rowsperpage=250

[erwan.l]

Hi Gents,

Regarding CloneDisk as an imaging tool but also a disk utilities tool :
-i am sure i can make it faster (imaging) : i like challenges
-the UI has defo lots of room for improvement : most of the improvements came from useful feedback from this community already.

Regards.
Erwan

[Wonko the Sane]

Regarding CloneDisk as an imaging tool but also a disk utilities tool :
-i am sure i can make it faster (imaging) : i like challenges
-the UI has defo lots of room for improvement : most of the improvements came from useful feedback from this community already.

Yep , and if I can find an issue with Clonedisk it is that it actually shows how you have been affected by featuritis

Seriously, I am pretty sure that you could easily "strip" out of Clonedisk just the code used for making an image, add a couple of formats for the image and a couple compressing libraries, the option to create the image in chunks, and have a simpler, more "vertical" tool, let's call it hypothetically ImageDisk that then you can "tune" for faster performance (and later even backport to Clonedisk).

 

Wonko

[erwan.l]

Aggreed, featuritis is a common virus for dev guys like us on forums/internet : one user ask for A, another one ask for B, etc etc.

When the request comes in, it makes sense, but later on you take a few steps back and realise you software became some sort of monster

 

What I tried to do (but I partly failed so far) is to hide advanded features and leave only a vertical GUI split into 4 categories : Clone (the origin of CloneDisk), Volume, Disk , VirtualDisk.

 

To stick with the topic, "what level of details/complexity would we like into WinFE (or any forensic and/or imaging WinPE)" : I like the approach of one single tool but with different levels of use : from a simple GUI (couple of buttons) to a more advanced one.

Thus a program like CloneDisk does not pretend to be as vertical as the excellent Rufus for example : I like the way Akeo sticks to his strategy.

 

The other approach indeed, which is not incompatible with the above, would be to split one big/fat tool into small pieces.

Thats basically what I am doing with CloneDisk & vMount or with ImgMount & ImgMountCMD, or more confidential IpTools & Tiny PXE Server : these share the same source code / core units  : when I modify one unit, all program depending on it will benefit from it.

 

My 2 cents on possible approaches to verticaly vs horizontality...

 

/Erwan

[Wonko the Sane]

Yep, I have seen the "changes" (to call them "improvements" is a bit hard for me , no offence whatever intended ) in Clonedisk.

 

I would call them a "great improvement" (when compared with the release with the "dancing tabs" ), but still (and of course IMHO) I personally prefer more "vertical" tools.

 

Mind you I do appreciate the way you managed to "fit" *everything* in the new GUI, but still it is the base idea of wanting to fit *everything*, and particularly wanting to fit *everything* in such a small rectangle that is "wrong" and cannot possibly succeed .

 

Also (and again, with no offence intended ) there is not *any* logical workflow analysis in the way the tools/option/command are listed.

 

If you want we could make a different new thread about the current issues in Clonedisk interface (and possible future/development).

 

Wonko

[erwan.l]

No offence intended

This is why I come here from : learn and get feedback!

Else, where would I get it?

 

Indeed, discussion around possible improvements could/should be a separate thread.

 

Side note and last one about CloneDisk : the last version (just uploaded it) should be around 30% faster (according to my tests) when backuping/dumping a disk to an image.

 

About DMDE, it has been said before, not only is it a nice tool for imaging but I personally believe its added value is around recovering and NTFS tools.

[misty]

As I see it, the Disk Signature can be worked around by pre-booting to grub4dos and check it (and image the MBR if needed).

Easy enough for us, but how easy for the target audience in general? I love Grub4dos and it's one of my favourite, must have, tools. It's become so feature rich it's bordering on being an operating system in it's own right. Unfortunatly it's not that easy to use - particularly for the commandline averse users out there.
 

Of course given that I can count all the people, including Colin, Brett and you (and myself for the little I did), that actually contributed *something* to WinFE without needing to take my shoes off , it might take forever to have a bunch of these tests/results.

A sad but true fact. We could always put this request out to the reboot community. Disk imaging is of much wider interest than just WinFE usage and there might be more volunteers than you think. Also the forensic principles have real merit in data recovery situations, so again there could be wider interest.

Your suggestions, as usual, are well thought out. On this occasion however I disagree with the use of virtual setups. There is, in my opinion, no substitute for testing on real hardware. Sadly I don't have access to the required equipment or I'd be starting tests now.

In regards to running a pre-test and ignoring the forensic soundness, I think this would be a missed opportunity for collecting invaluable data. Publically available research into WinFE usage is something I can only describe as p!ss-poor - hence my own efforts elsewhere to better understand the different versions.

Regards,

Misty

[RoyM]

On 4/28/2014 Wonko the Sane

Said. -->Of course given that I can count all the people, including 

Colin, Brett and you (and myself for the little I did), 

that actually contributed *something* to WinFE without needing to take my shoes off

 

I thought that I had contributed a little?, "Heck I wrote the thing."

I'll be content to be counted on your left pinky toe. 

 

On a side note, to completeley not adhere to the 'Topic Tile', "I couldn't resist"...

I do like the idea of different levels of WinFE's, for different levels of users.

 

 

My idea would go something like this.

 

Basic build:

Should automagically, and forensicaly image suspect hardware to 'somewhere?',

on first run, it should initiate communications/networking, and then securely

transmit all evidence, so as to preserve evidence untouched and pristine.

whether it be wireless/network, local media, etc.

This build needs to be solid, verifiably controllable, well documented for court purposes,

and short of using a hardware write-blocker, the next best thing.

 

 

Intermediate build:  "For users that know where their towel is".

An Intermediate build might be a fully booted PE or even Portable OS, preferably Forensicaly sound.

Intended for users that know their way around a PC, and their software.

realizing that in this mode, a booted WinFE has all the abilities above,

but you can also modify/access suspect information with minimal impact to evidence.

So that Investigators may poke around a bit, reasonably secure in preserving evidence.

Idealy, Basic Build would be run, and then Intermediate build.

 

 

Advanced build:

This is an Intermediate build with .NET and other enhancements.

 

Advanced build: "For advanced investigators"

This will be intended to be loaded on suspect hardware, whether on or off.

This build is not intended to be forensicaly sound, but as close as possible.

The Advanced build will be intended for immediate evidence extraction,

such as kidnapping cases, terrorists, or homeland security concerns.

 

Also, it would be nice to keep in mind that some of the suspect hardware 

will already be fully booted, and the privision to insert forensic media

would be extremely helpful to capture things suchs as memory, etc

 

 

As a savy PC user myself, one thing I see missing from the new 

and upcoming forensic software is linux file support.

There are some very good scripts out there for linux support, as well as linux FE's.

But I want my cake and to be able to eat it too. (preferably chocolate).

 

 

The Forensic Frontier is changing ladies and gentlemen.

let's explore that frontier together.

 

Regard

RoyM

[Wonko the Sane]

@RoyM
Actually you are on my left thumb finger.   

RT: Troy Larsson
RI : Brett Shavers
RM: Colin Ramsden
RR: yours truly
RL: Misty
LT: RoyM
...


@erwan.l
Good.


@Misty
It is perfectly possible to have some grub4dos batches (similar to the ones I posted here:
http://reboot.pro/to...sound/?p=177728

into menu.lst entries.
It is also perfectly possible to automate a sequence of commands when the menu.lst is loaded.
Really no technical issues here.

The idea of these simulated, simpler and that *anyone* can do using a "virtual disk driver", on the same common hardware each of us has, is not that of doing an actual benchmark, it is only that of preliminarly :
http://idioms.thefre... from the chaff

in order to have a reduced number of tools to be actually "properly" benchmarked.
I won't buy today, nor ever, that something that is particularly lousy on a small image, by sheer magic becomes the eighth marvel of the world when fed with -say - a 1.5 Tb disk drive.


Wonko

[misty]

@Misty
It is perfectly possible to have some grub4dos batches (similar to the ones I posted here:
http://reboot.pro/to...sound/?p=177728 into menu.lst entries. It is also perfectly possible to automate a sequence of commands when the menu.lst is loaded. Really no technical issues here.

Other than needing to install grub4dos and adding another level of complexity
 

The idea of these simulated, simpler and that *anyone* can do using a "virtual disk driver", on the same common hardware each of us has, is not that of doing an actual benchmark, it is only that of preliminarly :
http://idioms.thefre... from the chaff

in order to have a reduced number of tools to be actually "properly" benchmarked.

Normally I would agree. I am just concerned that things run very differently in WinPE compared to a full OS. And running virtual tests in WinPE is not a great idea.
 

I won't buy today, nor ever, that something that is particularly lousy on a small image, by sheer magic becomes the eighth marvel of the world when fed with -say - a 1.5 Tb disk drive.

Imagine how long the tests would take if capturing a monstrosity of a disk that size? And repeating them nth amount of times - I'd probably loose the will to live. I was thinking more of a small drive - around 60GB. Something that's been in actual use and contains a working OS. In fact I have a suitable SSD that size that I could use - I just don't have anything large enough to image it to at the moment.

Regards,

Misty