| Author | Message | ||
     Ross@WinPro.net |
The message "Important: Is this an image with a master boot record ..." can pause an unattended script. Is there a command or a switch to either bypass or make a choice? Perhaps for InterpretImageAsDisk or UesLogFile? Thank you, Ross@WinPro.net | ||
| Stefan Fleischmann (Admin) |
Two possible solutions I can think of: 1) Have the script interpret image files at the beginning of script execution, so that if the image's nature cannot be easily identified, you see the message box and can react immediately. 2) Work with evidence files instead of raw images. | ||
| Ross@WinPro.net |
> 1) Have the script interpret image files at the beginning of script execution, so that if the image's nature cannot be easily identified, you see the message box and can react immediately. Soultion 1) is my current method, but I would also like to open an image file set (xxx.001, xxx.002 etc) using 'InterpretImageAsDisk' later in the script. > 2) Work with evidence files instead of raw images If I understand, the evidence file will have already been 'identified' when added to the case and therefore, upon subsequent acccess (even with a script), WinHex will no longer prompt for "Important: Is this an image with a master boot record ..."? If correct, then I should probably have the case open for this to work with a script? Thank you Ross@WinPro.net | ||
| Stefan Fleischmann (Admin) |
2) You don't need a case for that. Evidence files have their own proprietary format with additional information attached to it (unlike raw images), including information on what type of image they are, that's how WinHex knows when opening them. 3) Another solution would be to alter the first sector in the raw image such that WinHex has no doubts about the nature of the image. E.g. if the first sector is a boot sector of a FAT32 partition, make sure it says "FAT32" at offset 0x52. | ||
| Ross@WinPro.net |
Thank you, Great ideas, thank you. I suppose I could also image directly back to a physical HD, then use this HD to avoid this message? If so, Would reading from such a physical HD dramatically speed up a script vs. reading from the image file set? The script uses loops with 'nextobject' and 'move'; which the 'Turbo On' description implies can be slow. Based on testing with the image sets, I am looking at a 50 hour run time estimate and I would like to cut it down. Thank you, Ross@WinPro.net | ||
| Stefan Fleischmann (Admin) |
> use this HD to avoid this message? Yes, you could. > Would reading from such a physical HD dramatically speed up No, it wouldn't. I recommend you use Turbo On, then. | ||
| Ross@WinPro.net |
Even with the best settings (e.g. Turbo On) is it possible that larger loops will bog down as they progress? Timing tests seem to indicate a loss of speed as the loop count increases. Some larger loop count tests went way beyond their calculated end times (based on the results of the shorter tests). This is just an FYI, it will (obviously) take more 'time' to test (haha). Thank you, Ross@WinPro.net | ||
| Ross@WinPro.net |
SetVarSize questions: once set, does it stay set or will it be disabled if the variable value/content changes? What is the proper syntax (usage)? Thank you, Ross@WinPro.net | ||
| Stefan Fleischmann (Admin) |
The time spent should increase proportionally with the number of loops. -- SetVarSize defines the allocated memory size of a variable at a given time. May be changed by any later assignments (Assign or Read). Use it like SetVarSize MyVarName Size where MyVarName is the name of an existing variable and Size is the intended size in bytes. | ||
| Ross@WinPro.net |
Thank you, How large (in byte length) are variables allowed to be? When using all 32 allowed variables, is there a global total size limit to be aware of? Thank you again, Ross@WinPro.net | ||
| Stefan Fleischmann (Admin) |
Only limited by available main memory. | ||
| Ross@WinPro.net |
Script wish: UseLogFile and "Scripting.log" to include the ending value of all variables and keywords. Thank you, Ross@WinPro.net | ||
| Ross@WinPro.net |
Script wish: An 'End' command to abort script execution without closing winHex (similar to 'Exit'). Thank you, Ross@WinPro.net | ||
| Stefan Fleischmann (Admin) |
As of v12.1: Terminate Aborts script execution. | ||
| Ross@WinPro.net |
In the example below "aaa", "zzz" etc. are used as spacers in the output file to help see where other writes truly begin and end and is not part of the question. script segment: the 'read' is correctly reading the text "35558" from a cluster list --------------------------------- read clstrnmbr write clstrnmbr // writes the ASCII version to file write (clstrnmbr*32) // writes Hex but not the value I need write "aaa" assign clstrnmbr 35558 write clstrnmbr // writes the Hex version to file write "bbb" inttostr test1 (clstrnmbr*32) //writes ASCII that I would like from the 'read' write test1 write "yyy" write (35558*32) //writes Hex write "zzz" inttostr test2 (35558*32) write test2 // writes ASCII as I would like it from the 'read' ---------------------------- All results are probably as expected, but how do I convert the 'read' clstrnmbr so that it can be used in calculations? Thank you, Ross@WinPro.net | ||
| Ross@WinPro.net |
Sorry for the confusion above, a little too much midnight oil made me slip (haha). I am sure I understand what I need now. (deleting previous msg is OK by me) Is there a reverse command for IntToStr or currently some way to perform such action? That is what I need and cannot see. (thank you) If not, how about adding StrToInt to the script wish list? Clarification: when I 'read' the numbers from a cluster list they are stored in the variable as a string but I need to convert the variable to integer so that I can do 'math'. After the math is done I can use IntToStr and write to a file for use by Replica. Example: (again, the write "aaa" is just to spot write boundaries) -------------------- readln clstrnmbr // reads numbers from cluster list as a string and cannot perform integer math with this variable. // here is where I would like to use StrToInt ... then do the integer math ... then use IntToStr ... then write to file for Replica ... write clstrnmbr // writes the string version to file (then usable by Replica) write "aaa" //------------------- // BTW, the line below writes the string version but pads 3 hex 0's at the end just by using parenthesis, is there a reason for the padding? write (clstrnmbr) write "bbb --------------------------------------- Thank you, Ross@WinPro.net | ||
| Ross@WinPro.net |
script wish list: IntToHex HexToInt 'Int' being a decimal integer. Therefore if I use "Read MyVariable 1" on a byte that I know is Hex (e.g. 0x20) and I need to use it as an integer (e.g. 32), the above commands would convert both ways. Unless there is already a way to do this? I have looked at 'Convert', perhaps I could use it instead? If so, it looks complicated (e.g. read source, write it to a new file, 'Convert param1 param2', read again as converted? If yes, then use ANSI ASCII and HexASCII? -------- I cannot find StrCat in new help (sorry if I missed it) I assume it will concatenate two strings? Perhaps like this: StrCat MyVariable "testing" "123" resulting in "testing123" in MyVariable? Thank you again, Ross@WinPro.net | ||
| Stefan Fleischmann (Admin) |
Documentation of the new script commands is still missing. StrCat MyString MyString2 StrCat MyString ".txt" Appends one string to another. The second parameter may be a variable or a constant string. The first parameter must be a variable. The result will be saved in the variable specified by the first parameter and must not be longer than 255 characters. | ||
| Stefan Fleischmann (Admin) |
> If not, how about adding StrToInt to the script wish list? The following will be available in the next release: StrToInt MyInt MyStr Stores the binary representation of the integer number specified as a decimal ASCII string in the second parameter in a variable specified as the first parameter. | ||
| Ross@WinPro.net |
I have a short script that finds small blocks to "copyintnewfile". Loops=unlimited destination for new files is NTFS Script has worked well until I applied to a 27GB free space object. After about an hour, and 12,635 blocks have been copied to files (in a single directory), WinHex gives errors regarding: 1. not being able to write the current object to disk. 2. not being able to save the case, including a reference to Quota. Sorry I do not have all details recorded. It happened twice. When I restart Winhex the case is not usable (it is now 0KB in size). After the first time I was able to rename the case backup file and get back to work, after the second time there was no case back up to recover from. I am guessing that the case back up is made on a successful exit from WinHex? So that when I renamed the backup and restarted WinHex a new backup would not be created until I exit AOK again? 12,634 files all look good, total 133MB, plenty of space left on destination. The last file written is 0KB (just like the case file). Is this simply an NTFS limit on files per folder? Has WinHex reached a limit in variable usage? The output filenames were just the offset numbers in decimal (prepended with placeholders) and had not become excessive as far as NTFS is concerened. The last name was "1000002674169454.fil" Any thoughts appreciated. Thank you, Ross@WinPro.net | ||
| Stefan Fleischmann (Admin) |
> I am guessing that the case back up is made on a > successful exit from WinHex? When a case is saved (it is saved automatically when it is closed and there were changes to it, e.g. when existing WinHex/XWF), the existing case is renamed to .xfc.bak. If there was a reference to quota, I suspect it is the operating system that prevents WinHex/XWF from writing more files to the disk, for some reason. > Is this simply an NTFS limit on files per folder? I don't think there is such a limit. > Has WinHex reached a limit in variable usage? I don't think so either. | ||
| Ross@WinPro.net |
I have a script loop that selects blocks of data that I then "CopyIntoNewFile" AOK until the loop is done. I now want to modify this script. For each block that I "CopyIntoNewFile", I would like to prefix the same two specific bytes to the block (or to the destination file). What would be the best script method (i.e. commands) to achieve this? I have been looking at the script commands for a way to, perhaps, concatenate a two byte variable (hex values) and the selected block and save the combination into a new file. Anyone have any ideas? Sorry if it is obvious, I can envision some complicated routines, I just am not seeing a simple way. Thank you very much. Ross@WinPro.net | ||
| Ross@WinPro.net |
Is there an optional way to supress the message generated by "WriteClipboard" that warns that writing the clipboard data will increase the file size? Thank you Ross@WinPro.net | ||
| Ross@WinPro.net |
12.95 preview 20 script WriteClipboard vs. Paste Using selected Blocks that do not have a zero as the final byte ... trying to get this data into a created file ... Paste is adding a zero at the end of the file, WriteClipboard is not. WriteClipboard creates the file I need (i.e. without the zero at the end) but always prompts with the "increase in file size" warning. Paste, by adding the zero, is making the file unusable. Thank you Ross@WinPro.net | ||
| Ross@WinPro.net |
Sorry, that was 12.9 SR-13 (I forgot that I had to switch because the 12.95 preview-20 is Forensic only and would not allow scripting to create/save files.) Ross@WinPro.net | ||
| Stefan Fleischmann (Admin) |
> What would be the best script method (i.e. commands) to achieve this? Maybe simply "Write 0x1122". > supress the message generated by "WriteClipboard" Will be removed with v13.0 Beta 3. There will be a WinHex version of v13.0 Beta. > Paste is adding a zero at the end of the file No, it doesn't. If there is already a zero at the end of the file, it will persist of course. Whenever you insert data before other data, in a script or not, that other data is not lost, but merely pushed forward. Completely normal, and anything else would be obviously wrong. |