I have an old help file project, but the original project was lost in a hard drive crash. The original was created using HelpScribble, but now I've decompiled it into WinCHM. I have recreated the help file after decompiling the original compiled CHM file. However, to my knowledge, there is no way to identify the mappings to direct an application to certain Context ID's.
What I'm wondering is if there's a way to read the compiled CHM file and extract the Context ID of each topic in the help file? I would hate to have to iterate through individual numbers from 0 to 5,000 from what I've seen in the original software source. This is a large system, and has a corresponding large help file for every possible scenario in the software.
You can use the chmls tool from the FreePascal project. Invoke it like this:
chmls extractalias MyHelpFile.chm
The output are files named MyHelpFile.ali and MyHelpFile.h containing the IDs and targets of your aliases.
Related
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 2 years ago.
Improve this question
I have several malware repositories however I am unable to get bin files to execute or files as windows classifies them. I have included some file names so you can see what I'm working with. I have been trying to mount some of the files which are Bin files with no luck.
Tank_3d.jar
b0ffb939b3df60f8561fadf2cbfa1733_WEXTRACT.EXE_
userinit.exe with a desktop.BIN
why the extra file with the executable?
13ce4cd747e450a129d900e842315328 and windows says type of file is file?
Any help you can provide would be greatly appreciated I have searched the web but I haven't found any sites that tell you how to execute these files for obvious reasons. I have changed some of the file extensions to .exe and some of them will execute in this manner. However, a lot of them still will not. I have conducted static analysis of these files prior to trying to do dynamic analysis. Also I forgot to add I'm doing this research for a university thank you
The question is not completely clear to me but as I understood from what you said, you have some files (probably related to some malware/ransomware) that you don't know how to execute them.
Before just starting to execute a malware or whatever suspicious file, you need to collect as much information as possible about your files. This step is called information gathering. So this is what you need to do:
(these are optional steps and can be changed based on your experience)
Calculate the MD5 hash of the file then search the MD5 value in VirusTotal or Hybrid-Analysis to check if these engines already analyzed this sample or not.
(or you can directly upload your sample to these engines without calculating the MD5 value)
Search on Google for whatever information you have about your file (even you can search the file name itself). You don't want to re-analyze the sample if someone already did that for you unless you are looking for some variants or some specific features. Even in that case, reading other related analysis report can help you do it faster.
Get the type of the file using whatever tool to extract the magic header (signature) of the file. I would say use Linux file command but you can use other tools as well.
Try to open the file in a hex editor/display software (you can find lots of them if you search), to see if there is anything interesting in the file.
use Linux Strings or Windows Strings commands to extract human-readable strings from the file to see what you can find.
Doing all the above mentioned steps, you will have the idea how you should deal with the file.
Use Peid or Die (Detect it easy) to extract the programming language and possible packer name/entropy of the file.
and finally, to execute different file formats:
If it's a .jar file: java -jar sample.jar
If it's a .dll file: use rundll32 or OllyDBG.
If you have an .exe file: just run it.
People who start learning malware analysis, they just try to execute the file or start with dynamic analysis but one needs to know that these steps are very helpful before executing the sample since most of the time you will get what you want from information gathering and static analysis.
If you explain better the problem, maybe people can help you better!
Edit:
I am going to add this part to the answer to cover the comments.
why are there additional files in the malware folder like an executable with a bin file?
This is a simple trick which has been used by malware writers for several years. For example, in one scenario, the main file of the malware can be an executable file (.exe) but it's actually not harmful at all!!!. All it is doing is to download another file (e.g., .dll file) which is the real malicious code (you can call it the payload). However, sending and receiving .dll files is also suspicious, so malware authors use other file extensions or whatever to hide the malicious content (like .bin file or even .png file in one of the variants of Emotet). The problem is that you CAN NOT execute these files just like that! since sometimes there are encrypted/encoded.
You need to know the procedure of executing them which is only possible to know if you reverse engineer the sample.
for example:
13ce4cd747e450a129d900e842315328 -> .DLL file
This means you may be able to analyze it using Ollydbg or any debugger + rundll32 but there is no guarantee!! it may be encrypted or encoded and only the parent file (.exe sample for example) can decrypt/decode it!
I am now interested in performing memory analysis of the malware which I possess. however the problem I encountered was how to execute a lot of the ransomware files I have to examine
I would say it would be nice to execute all of them using Win10 VM + cuckoo sandbox and dump the memory for further analysis. It's all automatic job and can be done nicely.
I've been reading on the compilation process, I understand some of the earlier concepts like parsing but I stop short of understanding how the executable file is created at the end.
In the examples I've seen around the "compiler" takes input in the form of a lang defined by BNF and then upon parsing it outputs assembly.
Is the executable file literally just that assembly in binary form? I feel like this can't be the case given that there are applications for making executables from assembly?
If this isn't answerable (ie it's too complex for the stack overflow format) I'd totally be happy with links/books so I can educate myself.
The compiler (or more specifically, the linker) creates the executable.
The format of the file generally vary depending on the operating system.
There are currently two main formats ELF and COFF
http://en.wikipedia.org/wiki/Executable_and_Linkable_Format
http://en.wikipedia.org/wiki/COFF
If you understand the concept of a structure, this is the same, only within a file. Each file has a first structure called a header, and from there you can access the other structures as required.
In most cases, only the resulting binary code is saved in these files, although you often find debug information. Some formats could save the source along the code, but now a day it only saves the necessary references to the source.
With dynamic linking, you also find symbol tables that include the actual symbol name. Otherwise, only relocation tables would be required.
Under the Amiga we also had the possibility to define code in a "segment". Only one segment could be loaded at a time. Once you were done with the segment, you could unload it and load another. Yet, in the end the concepts were similar. Structures in a file.
Microsoft offers a PDF about the COFF format. I could not find it on their website just now, but it looks like others have it. ELF has many links in the Wikipedia page so you should be able to find a PDF to get started.
Not all but some (gcc, etc) compilers go from the high level language to assembly language then spawn the assembler. The assembler reads the assembly language and generates machine code and generates an object file which as you have guessed contains more than just the machine code bits. If you think of it for second you may realize that a variable or function that is defined in another source file which means its code lives in another object file, until link time one object doesnt know how to get at that external function, so 1) the machine code is not finished, patching up external addresses is not done until link time 2) there needs to be some information in the object file that defines what public items are in this object file and what external items are missing, names of functions for example which are obviously not embedded in the machine code. So the objects have machine code in various states of completion as well as other data needed by the linker. the linker then...links...the objects together into one program with everything resolved, it basically completes all the machine code and puts the fragments of machine code (in separate objects) into one place. Then it has to save all that on the disk in some format and typically that format is not just raw machine code. It has extra stuff in the file, starting with a header and the a way to define each binary blob and where it needs to live in memory before executing. When you run a program on the command line of your operating system or double clicking or whatever in a file manager gui, the operating system knows how to read that file format, extract the blobs of binary, place those blobs of binary in ram defined by this file format and then start executing at the place defined by this file format.
aout, elf, coff, intel hex, motorola s-record are all popular formats as well as raw binary which some toolchains can produce. the gnu tools will default to one (coff or elf or exe or aout) and then objcopy is used to convert from one to another or at least the default one to the others and there is help to show what your possible choices are. then simply google those or wikipedia them and find the definitions of the file formats. Intel hex or motorola srecord are good ones to start with at wikipedia then elf perhaps.
if you want to produce native executable file you have 2 options. you can assembly the binary form yourself or you can transalte your program to another language and use its compiler to producte the executable
i got a customer who wants to migrate from an old Fujitsu COBOL based system to our system, said that, he wants his old data to be kept in the new system, like products,manufacters, etc.I dont have the COBOL source file, i have: .DAT files, .RDD files and .FDD files.
Apparently the .DAT files are in the INDEXED organization, a sample file output bellow:
FDD output:http://textuploader.com/kxdv
RDD output:http://textuploader.com/kxdw
I can't simple read the .DAT file in notepad, i've tried the SiberDataViewer but unsuccesfull, also it gets paid to export the data.
If there's a way, can i write a program to export all these files to csv,dbf,postgres format? If you are still reading, thank you.
I do not know Fujitsu COBOL but as I see it there are a few ways you might be able to get at the data:
0) Have your customer (or someone with a compatible Fujitsu COBOL compiler) write a COBOL program to read the INDEXED file and output a SEQUENTIAL file.
1) Find a Fujitsu COBOL utility to do the same.
2) Find a product that can read the INDEXED file and export it into something you can use. I'm thinking of products like Cyberquery or Crystal Reports, etc. Or, after I saw that the FDD/RDD files were produced by Siber Systems, a quick search helped me find their "Cobol DataViewer" product; use that to output it to a "more common and usable format" ;-)
I could convert it using the Siber DataViewer, but, its full version is paid.
I have a .po file where most translated strings are identical to original ones. However, few are different. How do I quickly find the ones that differ from original?
use podiff
I used it, an it workd for me. Its in C, so you have to compile it. make is your friend
I would suggest using one of the many web-based localization management platforms. To name a few:
Amanuens (disclaimer: my company builds this product)
Web Translate It
Transifex
GetLocalization
This kind of platforms allows you to keep your resource files in sync, edit them in a web-based editor (useful for no-technical translators) and most importantly to highlight/see only the changed/untranslated strings.
We develop a database application. The user asks for a new feature: Copy blobs into the clipboard such that Windows Explorer can paste them as new files. One solution is to save the blobs into a temporary folder and add these temporary files to the clipboard.
But I'm looking for a better solution. Is it possible to hook the paste action in Windows Explorer and save the blobs to the destination path by myself?
I've never tried it but I think it is indeed possible. Please take a look at the MSDN Documentation for Shell Clipboard Formats. CFSTR_FILECONTENTS and CFSTR_FILEDESCRIPTOR are the formats you are likely supposed to handle.
Additionally, I found an article at Code Project which provides a demo program: How to drag a virtual file from your app into Windows Explorer.
Update: An example written in .NET:
Creating something from nothing
Creating something from nothing, asynchronously
From the MSDN article Handling Shell Data Transfer Scenarios
Existing files should be offered with the CF_HDROP format.
Offer file-like data with CFSTR_FILECONTENTS/CFSTR_FILEDESCRIPTOR
formats. This approach allows the
target to create a file from a data
object without needing to know
anything about the underlying data
storage. You should normally present
the data as an IStream interface. This
data transfer mechanism is more
flexible than a global memory object
and uses much less memory.
Two other good articles to read from MSDN are:
Shell Data Object
Shell Clipboard Formats
When I first started working on using the clipboard to transfer files I printed off all three articles and read them several times.
Dealing with the interfaces can be quite involved. I have found two good libraries out there to help with this.
The The Drag and Drop Component Suite for Delphi. If you scroll down on the home page you will see some FAQs are good reading. There are also a lot of sample applications with the download. I think the AsyncSource demos should be helpful for what you are looking for. The suite is freeware with source. The code seems to be well commented.
I am currently using the Transfer#Once component from Quasidata. It is not free but is very inexpensive. I initially used Transfer#Once because at the time it was better supported than the Drag and Drop component suite. However, that situation has reversed itself. Transfer#Once does not yet support Delphi 2009. When I get around to moving my application I will probably switch components. The Transfer#Once code is included with purchase. Personally I found the Drag and Drop code to be much easier to read and follow.
I'd say that explorer does the copying to the destination files itself, so there's no way to directly write the destination files. This makes sense, because the names of the source files can only come from the application that copied the data to the clipboard, which need not be explorer. OTOH the names of the destination files may actually differ, because files of the same name could already exist in the destination folder, and only explorer can create the modified names for the destination files (like by prepending "Copy of " or by appending " (2)" to the base file name).
You will need to provide the clipboard format for the Windows Explorer so that it can paste the files. The documentation of standard clipboard formats suggests that CF_HDROP is the right one. With this clipboard format you would provide a list of source file names, but the files do need to exist of course, so you will need to save them to disc.
You could try to make the process as light-weight as possible, though. Usually when a user copies data to the clipboard it is put there immediately, whether or not it will be used for a paste operation. For your application that would mean that you would need to create the files and put the list of file names into the clipboard, every time. However, Windows does support a mode called Delayed Rendering, which is used exactly for such cases. Basically you put only an empty stub of the data onto the clipboard, and only when another application tries to access the data it will be requested from your app. So you could implement this in a way that only when the user tries to paste the files into explorer you would save them to disc and return the list of file names.
It's been a while since I toyed with copy/paste, but I'm pretty sure you can do what you're suggesting (insert the blob as a new file into the clipboard).
I seem to remember that depending on how you add to the clipboard you can specify what sort of data you're copying. I think if you get that data type right, you'll be able to paste as though you'd copied from windows explorer.
I'll try and dig out some more details this evening if I have a chance (I don't have all my bookmarks here at work)...
[Edit] Have a look at the wxWidgets documentation on drag and drop. That was what I'd been working with and it gives some hints about data types.
What are you writing in? Delphi?
[Edit2] I think this may actually be a limitation of Windows(?). It might just be the wxWidgets documentation, but there's a suggestion that you only copy filenames rather than the files themselves. If that's the case, you're going to have to ue your original suggestion of creating a temp file first :-(