I just followed the steps from Forging WiFi Beacon, but my output is strange, it added 'c2' byte between '0f' and 'ac' byte, Why this happened? How do I solve this problem?
Please look at the image
It seems that you're on Python 3 (as IPython > 5 requires Python > 3)
In that case, you should remember to append a b in front of bytes strings: b"\x01\x02..." as it is required on Python 3+
I'm having problem to form the field section's structure into xfd files after analyse by issuing commnad "vutil32.exe -i -kx pogl.dad". I hope somebody could help me out how to form out field structure as highlighted in below. I've uploaded sample of my file known as "pglc.dad" i hope soneone could guide me how to form .xfd file from his expert skills and guide me.Thanks
Result from vutil32.exe
file size: 250880
record size (min/max): 121/1024 compressed(80%)
# of keys: 4
key size: 16:02 31:03 56:03 15
key offset: 0 0 0 1
duplicates okay: N N N N
block size: 512
blocks per granule: 1
tree height: 4/2/2.7
# of nodes: 200
# of deleted nodes: 1
total node space: 101800
node space used: 67463 (66%)
user count: 0
Key Dups Seg-1 Seg-2 Seg-3 Seg-4 Seg-5 Seg-6
(sz/of) (sz/of) (sz/of) (sz/of) (sz/of) (sz/of)
0 N 1/0 15/1
1 N 1/0 15/66 15/1
2 N 1/0 40/81 15/1
3 N 15/1
Here is my further construction of .xfd file.
XFD,02,PGLC,PGLC
00300,00041,004
1,0,013,00000
01
PGSTAT
3,0,004,00004,020,00021,004,00000
3
PGSTAT
PGDESC
PGLINE
3,0,004,00004,008,00013,004,00000
03
PGSTAT
PGDESC
PGLINE
1,0,012,00021
01
PGSTAT
000
0150,00150,00003 =================>> How can i form this field section.
00000,00013,16,00016,+00,000,000,PGSTAT
00000,00001,16,00001,+00,000,000,PGDESC
00001,00015,16,00015,+00,000,000,PGLINE
here is the link for my pglc.dad : http://files.engineering.com/getfile.aspx?folder=080fdad6-b1d5-4a37-8dd0-b89f9a985c69&file=PGLC.DAD
Thanks appopriate to someone could helps.
I know the XFD format intimately as I have written a couple of parsers of this file format in both Perl and Cobol.
Having said that, I would strongly recommend that you do not try to hand craft an XFD file from scratch.
If you have an AcuCobol (MicroFocus) compiler, and the source of the file's SELECT and FD definitions, then you can create a very small Cobol program that has just the SELECT and FD definitions and then compile the program using:
ccbl32.exe -Fx <program>
That will create an XFD file for the indexed file definition. Note, you can specify a directory for the created XFD file using the -Fo <directory> option.
If you don't have the source of the file definitions, then you are just going to be guessing what and where the fields are. The indexed file by itself will not tell you that information. I can see from extracting the data in your file (using the vutil -e option) that the file contains binary data as well as text, so without knowing exactly what PICture those fields are (COMP-?) you will be struggling to figure out the structure of those fields.
I am using IAR 5.40 and xlink to generate the checksum. The generated checksum and calculated checksum don't match. Here is how my memory map looks like:
Symbol Checksum Memory Start End Initial value
------ -------- ------ ----- --- -------------
__checksum 0xd973 CODE 4400 - FF7D 0x0000 (#0x0000)
CODE FF80 - 243FF
The __checksum is located at FF7E - FF7F
I am using IAR provided checksum calculator:
sum = fast_crc16(0, (unsigned char *)0x4400, (0xff7d - 0x4400 + 1));
The sum and __checksum don't match. Looks like I am missing something. Need Help!!
I've just ran
$ sha1sum myfile
out of boredom.
myfile is an empty file which I created with
$ touch myfile
I was surprised that sha1sum actually returned a checksum. Aren't these checksums supposed to be computed from some non-empty content? Is the checksum for an empty file just a hardcoded "magic" constant?
There's nothing fundamentally different with an empty message from a message with say a byte of data. The algorithm is described here http://en.wikipedia.org/wiki/SHA-1#Examples_and_pseudocode and it's fine with zero data.
Eg.
Pre-processing:
append the bit '1' to the message append 0 ≤ k < 512 bits '0', so that the resulting message length (in bits) is
congruent to 448 (mod 512)
I've tried the following code after reading the docs:
create buff 128 allot
buff 128 stdin read-line throw
I was hoping that this would get me a char for each successive address of buff, but I'm getting this weird number in there:
buff # ok
. 3689349013085184353 ok
What am I missing here?
buff put the address of your buff variable on the (data) stack. The memory by that address contained the input received from stdin, something like this:
Address Value
------- -----
N+0 0x61
N+1 0x61
N+2 0x61
N+3 0x61
N+4 0x61
N+5 0x33
N+6 0x33
N+7 0x33
... ...
The # word transformed the address left by buff into an integer value by that address. But since you've (apparently) got a 64-bit gforth version, # returned a 64-bit, i.e. 8-byte, value starting at the given address, i.e. 0x3333336161616161, which is 3689349013085184353 in decimal. The . word just showed you that number.
If you want to fetch a particular byte, use c# instead of #:
buff c# .
That'll give you the code of the first character in the buffer (0x61 or 97). If you want to get the second item, increment the address before executing c#, like this:
buff 1+ c# .
Similarly, this will get you the sixth character's code:
buff 5 + c# .