I'm searching in web for magic numbers for Paradox DB files (.db), but there are no results.
What binary signature for these files?
I hate to answer this question because identifying the type of a file by its contents is inherently unreliable -- a binary signature tells you only that the file MAY be of a certain type, but there's no guarantee that another file won't happen to contain that string.
Also, binary signature recognition of *.DB files is weak because almost all the bytes carry highly variable information, and most of the constant bytes are zero:
byte constant
offset value
-- --
2 00
3 08
E 00
F 01
14 00
2A 00
2B 00
2C 00
(all values in this answer are given in hexidecimal)
There's probably lots of non *.DB files that will accidentally match this pattern.
A couple more bytes are easily interpreted and provide additional information:
byte offset 4:
00 = indexed .DB data file
01 = primary index .PX file
02 = non-indexed .DB data file
03 = non-incrementing secondary index .Xnn file
04 = secondary index .Ynn file (inc or non-inc)
05 = incrementing secondary index .Xnn file
06 = non-incrementing secondary index .XGn file
07 = secondary index .YGn file (inc or non inc)
08 = incrementing secondary index .XGn file
byte offset 39:
03 version 3.0
04 version 3.5
05..09 version 4.x
0A..0B version 5.x
0C version 7.x
Borland never published the internal format of its data base files. I think that to reliably identify a *.DB file by its contents you would have to try to open it with Borland's data base engine.
-Al.
Related
Currently trying to essentially reverse engineer a file format that is produced by a CNC machine when backing up programs on the machine so that i can read the programs on a standard PC. Have opened a few of the backup files created and can clearly see patterns of data such as the program name etc. which can be clearly seen in plaintext form. One thing i am struggling with is how numbers are represented in this.
for Example: the number '20' is represented in this file in hex form as '40 0D 03 00'.
More examples:
"-213.6287": "21 67 DF FF"
"-500.3366": "9A A7 B3 FF"
Any help with trying to figure out how these hex values make up those numbers?
Thanks
These numbers are stored as little-endian signed integers, as a count of ten-thousandths.
for Example: the number '20' is represented in this file in hex form as '40 0D 03 00'.
0x00030d40 = 200000.
"-213.6287": "21 67 DF FF"
0xffdf6721 = -2136287.
"-500.3366": "9A A7 B3 FF"
0xffb3a79a = -5003366.
I'm developing an interface to a VeriFone VX terminal. Although, this is really a general EMV question. Our processor has a zero floor limit, so it will always be sent online. However, in case it ever changes, how do you know (what tags) if the transaction was approved or declined offline? Or, in other words, how do you know to go online or not?
how do you know (what tags) if the transaction was approved or declined offline? Or, in other words, how do you know to go online or not?
The terminal has to decides either to proceed the transaction offline, to go online or to reject the transaction. Here terminal send a command (AC) to the card and response of this command helps terminal to decide the action next followed.
Decision making is depend on three fields -
1) - Issuer Action Code
2) - Terminal Action Code
3) - TVR
IAC, TAC and TVR have the same structure. For more to know this data you can see EMV BOOK 3
IAC Usage Example-
suppose IAC-ONLINE (TAG - 9F0F) = 08 00 00 00 00 ,
here byte 1 bit 4 is on i.e. offline DDA Failed ,
Here Issuer want to go online if offline DDA Failed.
when terminal perform DDA and it fails, it set corresponding bit in TVR
that means TVR says- offline DDA is failed for this card.
now terminal check IAC online and found DDA_Failed bit is on and same on in TVR, here terminal decision would be to go online and then it send a Gen AC command to card with p1 = 80 ( ARQC - Online authorisation requested).
Coding of P1 as below
Ex- Gen AC command
C: 80 AE 80 00 other data
R: SW1/SW2=9000 (Normal processing: No error) Lr=32
77 1E 9F 27 01 80 9F 36 02 02 13 9F 26 08 2D F3
83 3C 61 85 5B EA 9F 10 07 06 84 23 00 31 02 08
.
Now decision is made by card, Terminal get card decision in the response of Gen AC command. Card return tag 9F27 - Cryptogram Information Data. here card return 80 i.e. cards wants transaction to go Online.
Really your question is important and you need to read more spec for clarity on this topic. Please checks EMV BOOKs, for more in this topic. also can read - Terminal action analysis or Card Action analysis
Assuming you're using VeriFone's VIPA API, then the first 'Continue Transaction' command (GenAC1) returns tags wrapped in a TLV template (or 'constructed' TLV tag). The value of this template determines the result:
E3: Locally authorized
E4: Requires online authorization
AFAIK (in vanilla EMV) the tag Cryptogram Information Data ('9F27') returned during 1st GENERATE AC should serve this purpose.
See EMV Book 3, Table 14.
Beware, that this tag contains the decision of the card, so you won't see the cryptogram type the kernel required.
I'm using the crypto module to create salts and hashes for storage in my database. I'm using SHA-512, if that's relevant.
What I have is a 64 byte salt, presently in the form of a "SlowBuffer", created by crypto.randomBytes(64, . . .). Example:
<SlowBuffer 91 0d e9 23 c0 8e 8c 32 5c d6 0b 1e 2c f0 30 0c 17 95 5c c3 95 41 fd 1e e7 6f 6e f0 19 b6 34 1a d0 51 d3 b2 8d 32 2d b8 cd be c8 92 e3 e5 48 93 f6 a7 81 ...>
I also have a 64-byte hash that is currently a string. Example:
'de4c2ff99fb34242646a324885db79ca9ef82a5f4b36c657b83ecf6931c008de87b6daf99a1c46336f36687d0ab1fc9b91f5bc07e7c3913bec3844993fd2fbad'
In my database, I have two fields, called passhash and passsalt, which are binary(64)s.
I'm using the mysql module (require('mysql')) to add the row. How can I include the binaries for insertion?
First of all, I'm no longer using the mysql module, but the mysql2 module (because it supports prepared statements). This changes roughly nothing about the question, but I'd like to mention that those reading this who are using 'mysql' should probably use 'mysql2'.
Second, both of these modules can take Buffers as parameters for these fields. This works perfectly. To do what I was originally attempting to do, I have it like this:
var hash; //Pretend initialized as a 64-bit buffer
var salt; //" "
connection.query('insert into users set?', {..., passhash: hash, passsalt: salt,..., callback});
Additionally, I didn't realize that the crypto "digest" function had a default behavior with no parameter, which is to return as a Buffer.
This is not the best worded answer, but that's because no one seems to be paying much attention to this question, and it was my question. :) If you would like more clarification, feel free to comment.
We have an old application in Turbo Pascal which can save its internal state into a file, and we need to be able to read/write this file in a C# application.
The old application generates the file by dumping various in-memory data structures. In one place, the application just dumps a range of memory, and this memory range contains some arrays. I am trying to noodle out the purpose of the bytes immediately preceding the actual array elements. In particular, the first two items in the block can be represented as:
type
string2 = string[2];
stringarr2 = array[0..64] of string2;
string4 = string[4];
stringarr4 = array[0..64] of string4;
In the data file, I see the following byte sequence:
25 00 02 02 41 42 02 43 44 ...
The 25 is the number of elements in the array. The 02 41 42 is the first string element, "AB"; the 02 43 44 is the second string element, "CD", and so on. I don't know what the 00 02 between the array element count and the first array element refers to. It's possible the array element count is 25 00 and the element size is 02, but each array element is actually 3 bytes in size.
In the place in the file where the array of 4-character strings starts, I see the following:
25 00 04 00 00 04 41 42 43 44 04 45 46 47 48
Again, there's the 25 which is the number of elements in the array; 04 41 42 43 44 is the first element in the array, "ABCD", and so on. In between there are the bytes 00 04 00 00. Maybe they are flags. Maybe they are some kind of indication of the shape of the array (but I don't see how 02 and 04 both indicate a one-dimensional array).
I don't have access to Turbo Pascal to try writing different kinds of arrays to a file, and don't have authorization to install something like Free Pascal, so my opportunities for experimentation along those lines are very limited.
These arrays are not dynamic, since Turbo Pascal didn't have them.
Thanks in advance for any dusty memories.
Pascal arrays have no bookkeeping data. You have an array of five-byte data structures (string[4]), so an array of 65 of them occupies 65*5=325 bytes. If the program wrote more than that, then it's because the program took special measures to write more. The "extra" values weren't just sitting in memory that the program happened to write to disk when it naively wrote the whole data structure with SizeOf. Thus, the only way to know what those bytes mean is to find the source code or the documentation. Merely knowing that it's Turbo Pascal is no help.
It's possible that the first section of the file is intentionally the same size as all the other array elements. For the two-character strings, the "header" is three bytes, and for the four-character strings, the "header" is five bytes, the same as the size of the strings. That would have allowed the program to use a file of string4 data type for the file, and then just skip the file's first record. The zero between the file length and the string length in the header might belong to either of those fields, and the remaining two zero bytes might just be filler.
Besides the layout of the individual strings of characters in the file, you will also need to consider what code page those single-byte characters are from. C# chars are unicode 2 byte chars.
If you're lucky, the original file data contains only ASCII 7 bit characters, which covers characters of the English alphabet. If the original data contains "European" letters such as umlauts or accented characters, these will be "high ascii" char values in the range 128..255. You'll need to perform an encoding conversion to see these characters correctly in C#. Code page 1252 Windows Latin 1 would be a good starting point.
If the original file data contains Japanese, Chinese, Korean, Thai, or characters from other "Eastern" scripts, you have a lot of work ahead of you.
Turbo Pascal strings are prefixed with a length byte. So a string[2] is actually 3 bytes: length, char1 and char2. An array of string[2] will hold all the strings one by one directly after each other in memory. If you do a blockwrite with the array as a parameter it will immediately start with the first string, it will not write any headers etc. So if you have the source you should be able to see what it writes before the array.
I am attempting to write a small utility to produce a binary file that will mimic the one produced by another closed application. I've used hex editors to decrypt the format by I'm stuck trying to understand what the format/encoding is so that I can produce it using C++ or C#.
The file starts with the first four bytes: 01 00 followed by FF FE. My understanding is that the file begins with SOH followed by the byte order mark for little endian. After these four bytes, the program appears to write BSTR's for each of the string fields from the app's GUI.
Using C#, I have produced a unicode file that starts with FF FE, but I'm not sure how to insert the SOH character first.
I would be forever grateful if someone could offer insight to the file format or encoding and why the file starts with the SOH character.
Thank you in advance.
Reverse engineering a binary file format can be a challenging task. On the surface, I don't recognize this as an obvious, well-known file format ... but there are thousands out there, so who knows.
Legal issues aside, I would suggest you look at some of the following resources that talk about approaches to such an endeavor:
How To Crack a Binary File Format
Tools to Reverse Engineer Binary Files
Basics of Reverse Engineering File Formats
File Format Reverse Engineering
If you are just having trouble writing out the first four bytes this will do it for you.
using (var stream = new FileStream("myfile.bin", FileMode.Create))
{
using (var binaryWriter = new BinaryWriter(stream))
{
binaryWriter.Write((byte)1);
binaryWriter.Write((byte)0);
binaryWriter.Write((byte)0xFF);
binaryWriter.Write((byte)0xFE);
binaryWriter.Write(Encoding.Unicode.GetBytes("string"));
}
}
This will output the following file
01 00 FF FE 73 00 74 00 72 00 69 00 6e 00 67 00 ....s.t.r.i.n.g.
Edit: Added Mark H's suggestion for writing out a string.