I'm not 100% this is meant to go in stackoverflow but I'm sure it'll be moved if necessary.
I have a hex header file I just screen grabbed and would like to know what extension the file really is. The file was originally an exe but didn't seem to work, but looking at the hex information showed that it was an mzp, I just need it to be confirmed.
Thanks.
It is an executable file created with Delphi. The first 3 bytes 0x4D 0x5A 0x50 are decoded as 'MZP' in ASCII. The "P" stands for Pascal.
This does look like an exe file.
MZ - First two bytes indicate dos executable. Not sure what third byte P is for. Might be actually more than one byte and part of program identifier?
http://www.fileformat.info/format/exe/corion-mz.htm
Related
When am trying to open any .EXE file am getting information in encoded form. Any idea how to see the content of an .EXE file ????
I need to know what Database tables are used in the particular .EXE.
Ah, now we are getting closer to the real question.
It is probably much more productive to ask the targeted databases about the SQL queries being execute during the run, or a top-ten shortly afterwards.
The table-names might not be hard-coded recognizably as such in the executable.
They might be obtained by a lookup, and some fun pre-fixing or other transformation might be in place.
Admittedly they like are clear text.
Easiest is probably to just transfer to a Unix server and use STRINGS on the image.
I want to include the source here with but that failed, and I cannot find how to attach a file. Below you'll find a link OpenVMS macro program source for a STRINGS like tool. Not sure how long the link will survive.
Just read for instructions, save (strings.mar), compile ($ MACRO strings), link ($link strings), and activate ($ mcr sys$login:strings image_to_test.exe)
OpenVMS Macro String program text
Good luck!
Hein
Use analyze/image to view the contents of an executable image file.
I'm guessing you are trying to look in the EXE because you do not have access to the source. I do something like this:
$ dump/record/byte/hex/out=a.a myexe.exe
Then look at a.a with any text editor (132 columns). The linker groups string literals together, and they are mostly near the beginning of the EXE, so you don't have to look to far into the file. Of course this only helps if the database references are string literals.
The string literal might be broken across a block (512 byte) boundary, so if you use search in your editor, try looking for substrings.
Aksh - you are chasing your tail on this one. Its a false dawn. Even if you could (and you can't) find the database tables, you will need the source of the .exe to do anything sensible with it, or the problem you are trying to solve. Its possible to write a program which just lists all the tables in a database without reading any of 'em. So you could spend and awful lot of effort and get nowhere. Hope this helps
I am new to GNU Radio, so I am learning through simple projects. I have a .txt file that I want to receive in another .txt file by sending and receiving the file through PSK Mod and Demod modules (no SDR yet).Therefor I made the following flow graph:
File Source ----> PSK Mod ----> PSK Demod ----> Throttle ----> File Sink
I chose Num._of_Const. to be 4, and chose the path for the source file and sink file. I also set the output type of the source file (and the input type of the sink file) to be 'bytes'. When I run the grc file, something is being stored in the sink file. However, when I read it, the sink file seems to contain some random symbols and numbers that completely do not match the text that was supposedly sent from the source file.
I have read online that some people use the block Unpacked_to_packed but that did not work for me either. I am trying to begin with simple projects, but I feel I am missing on something, so your help would be much appreciated.
as the PSK demod contains some control loops to synchronize to a frequency/timing offset, it might just be missing the first few bits, even if you parameterized the blocks completely correctly. That will lead to your output bitstream being shifted by a few bits, and then the byte boundaries do no longer match, and you're getting garbled data. You should still be seeing the right sequence of bits, if you looked at your RX file in binary, instead of as text.
You will need to correct that offset by finding a "known" bit sequency. Essentially, you need any kind of "framer", so that you know when a byte boundary happens.
Also, PSK demod has documentation that clearly states it gives you unpacked data, i.e. one bit per output byte; you will need a unpacked_to_packed to get your original bytes.
PS: please don't use "random" unrelated tags. You're not using an USRP here, neither are you using LISP nor is this related to the GNU "overproject". All tags (should) have descriptions, and you should only use a tag if you're sure it applies to your problem
I want to create a hex dump of a binary file in Mac OS X.
In all apps in Mac OS, when you navigate to /Contents/Resources/, there is a file (or more) with the same name as the app.
I want to write an application in Objective-C that can read that file and convert it to some kind of a hex dump, like terminal's hexdump.
Does anybody know a way to create such a hex dump using Objective-C? (or perhaps an open source hex editor, written in objective-c?)
Thanks in advance.
Hex Fiend is embeddable, if it's an editor that you're after.
Use NSData to read the file as raw data, then display the bytes however you want (for example, using a format string).
Is there any way to (easily) modify a string in a Mach-O binary? I want to extend the length of a pre-existing string.
https://sourceforge.net/projects/machoview
Extending the string will not be an easy task with manual editing, but at least you can get a picture about the Mach-O file structure.
This will not be an easy procedure, you cannot just go and change a string in textedit and hope it works because mach-o binaries work with encoded bytes and if 1 byte is out of order, the binary will not be executed properly. If you really wish to modify a string inside a fully assembled mach-o binary file without disrupting its delicate code you will need lots of knowledge and understanding of how mach binaries work. You will need to be able to modify it in single bytes and replacing its encoded numbers and offsets. Hopper for Mac might be able to help you understand the architecture of a mach-o binary. but if you need to replace a string with a different string with the exact same length, you might be able to simply replace its bytes so that the binary still reads it at the same length. but you will need a hexadecimal modifying application to do that.
I am looking at some files generated in the early 90s. One of them seems to hold references to data packed in some binary format in a number of large files.
The first six bytes of the file are 0x42 0x4f 0x53 0x53 0x20 0x37 which spells BOSS 7.
My searches of various sources of file type information, including /usr/share/file/magic have not turned up anything. Does anyone know what software might have been used to generate files that start with these bytes? Any information on file layout would be great.
It looks like the file might have been generated by VisualWorks Smalltalk:
[BOSS 7.5]
Contains the Binary Object Streaming Service, which supports efficient storage and
retrieval of objects, including code, to and from files.
Note that for code storage, the parcel system now supercedes BOSS.
I tried to load the file using the IDE provided at http://www.cincomsmalltalk.com/ and it generated a meaningful exception:
The identifier MediaCollectionDictionary has no binding
The file does contain:
MediaCollectionDictionary
MediaCollection*
CallMediaVehDict2
etc which means, if I could now figure out what the rest of the files do and learn enough SmallTalk, I could disentangle this mess.
Of course, I am not sure if this analysis is correct. So, please if you have any other ideas, let me know. Thank you.
Much later: So, my initial assessment seems to be correct. I got some useful tips on comp.lang.smalltalk: http://groups.google.com/group/comp.lang.smalltalk/browse_thread/thread/5d55d857e2f80158#
Ask on comp.lang.smalltalk
Ask on the vwnc mailing list