| Author | Message | ||
     Corrie Theron Username: corrie Registered: N/A |
Hi Stephan and co.  Using Forensic license v.15.6 SR-5 I have a CF Card that is used with a Yamaha Music keybord. I have identified the headers of the files (it uses 2 different file types per song stored), but the files end very randomly thus my problem is I cannot create a new entry in the "file type signature" database, because I cannot identify a common footer for the files and they all differ in size so I can't define a fixed size (block) The next file (of the pair) starts immediately after the previous one with a different signature, so I was thinking of using that as a way to define the end of the block and having the script just jump back one byte when it finds the next (different) signature - define the end of block - and copy into new file. Then repeating for the other file type later. So far as I can see, the files are not fragmented and the ones I have carved manually works on the client's keyboard Does this line of thinking make sense and is it possible?? My script looks like this: Find 0x413037343520414C4C IfFound Block1 Find 0x41303734352053414D504C45 IfFound Move -1 Block2 CopyIntoNewFile "C:\Jobnumber\Song1.W8A" But says: "unknown expression encountered line 4...." Have not worked with scripts this complicated before but have had great success removing Headers from files with scripts Much appreciated and keep up the good work ;) | ||
| Björn Ganster Username: admin4 Registered: 3-2004 |
As your script stores both file parts in a single file, you seem to be dealing with two parts of a single file. There may be a pointer in the first header pointing to the second header in the file. A pointer to the end of file may be located in either of the headers, and most likely is relative to either the start of the file or relative to the second header. Another possibility is that the blocks are made up of tags, which usually have an identifier, tag size and data. While this type of file is usually concluded by a footer, finding a different tag identifier would also signal end-of-file in your case. If the keyboard can work with carved files that contain excess bytes at the end, it may still suffice to carve the files with excess bytes. Regarding the script, it may be that the search string in line 4 is too long. | ||
| Douglas S. Lacey Username: thx99 Registered: 11-2005 |
First of all, "If" loops cannot be nested; that is, an "If" statement cannot appear inside of another "If" statement. Second, I believe that "Block1" needs a value or variable following it. This may be the cause of your error, since the program is trying to assign the following line ("Find 0x41303734352053414D504C45") as the second part of the "Block1" command. What you want here is to assign the current position as the start of the block. This can be done by the command "Block1 CurrentPos" ("CurrentPos" is a built-in variable which represents the current offset). Lastly, it appears that the two headers you've given have the first 12 bytes in common. Is that true for other headers as well? If so, then that is useful information as you can create a loop to process each file that is on the CF card. Assuming that each header begins with the same 12-byte sequence, try this on an IMAGE FILE of the CF card: Assign FileNumber 1 Goto 0x0 { Find 0x413037343520 Down IfFound Block1 CurrentPos Move 1 Find 0x413037343520 Down Move -1 Block2 CurrentPos CopyIntoNewFile "C:\Jobnumber\Song+FileNumber+.W8A" Inc FileNumber Else ExitLoop EndIf }[Unlimited] This script will NOT extract the last file on the card, because it will not be followed by another header; the second search for the header will result in an error. You will need to manually extract the last file, assuming you will be able to determine its length. The change I made to your "CopyIntoNewFile" command enables you to save files with incrementing numbers assigned to them (Song1, Song2, Song3, ...). Let me know if you have any questions. Doug | ||
| Douglas S. Lacey Username: thx99 Registered: 11-2005 |
Ooops, I meant to say "it appears that the two headers you've given have the first 6 bytes in common", not "12". |