News:

MASM32 SDK Description, downloads and other helpful links
MASM32.com New Forum Link
masmforum WebSite

Lab Subforums proposal

Started by fearless, May 15, 2009, 09:57:57 PM

Previous topic - Next topic

dedndave

(pssst  FFFF is -1  shhhhhhh)
negative zero is someone who washes out of a police academy

FORTRANS

Quote from: dedndave on May 29, 2009, 09:27:32 PM
(pssst  FFFF is -1  shhhhhhh)
negative zero is someone who washes out of a police academy

  2's complement 0FFFFH = -1
  1's complement 0FFFFH = -0
   Loads of fun.  Reminds me of the old CDC Cyber days.

   Anyway checking the code showed no bug.  In typical M$
speak, "ones complement (inverse)" is a bitwise not.  Any
value added to its bitwise not/complement/inverse will have all
its bits set.

Cheers,

Steve N.

dedndave

ahhhh - missed that one - lol
glad it wasn't on a test or something

i don't know of any OS that actually checks that value
i have modified plenty of EXE's without diddling the checksum

jj2007

Quote from: dedndave on May 29, 2009, 09:27:32 PM
(pssst  FFFF is -1  shhhhhhh)
negative zero is someone who washes out of a police academy


include \masm32\include\masm32rt.inc

.code

start: int 3 ; let Olly show you what a negative zero is ;-)
push -1
fild dword ptr [esp]
push 0
fild dword ptr [esp]
fdiv st, st(1) ; THERE IT IS!
pop eax
pop eax
exit

end start


:bg

FORTRANS

Hi,

   Well, the EXE's coming out now don't even follow that rule anymore.
So there would not be any reason to test it!

DELTTSUL.EXE 26 Jul 00  7:00   5392  18439  AB019F8A
DISCOVER.EXE 26 Jul 00  7:00  41744  53791  8F489C29
DRIVER~1     14 Dec 00  6:04  <DIR>
EXPLORER.EXE 19 Jun 03 14:05  243e3  16025  DA96361B


Steve N.

dedndave

oh - i knew they had em in float world - lol - hundreds of em, actually (some of em may be NANs - i dunno)
they also have a half-dozen opposing theories on how to handle infinity all on the same chip ! - lol

on some of the EXE's ive looked at lately, that field is 0 (positive 0)

PBrennick

Steve,

Okay, so now I feel stupid. Don't know about Base 85 and would like to know. Do you have an algo. By the way, the purpose of the hex encoding is because the output from the xor encryptor can have control values which would or could cause the 81 byte stream to become mult-lined. The hex encoding fixes that.

P
The GeneSys Project is available from:
The Repository or My crappy website


dedndave

#38
wow - i didn't know they tried to make data bigger

i used the opposite technique a few times.........

Base 65
first, i carefully selected 65 ASCII characters for the text file (it was a config/help file)
that gives you 0-9, a-z, A-Z, space, carriage return, line feed
i had to remove a few capital letters to allow for punctuation characters - i just won't start any sentances with Z, Q, etc

then create a XLAT table so that the selected ASCII characters are assigned values 0 to 64

now, a 40-bit binary number (5 bytes) may be used to represent 6 unique characters...
let's call them Char1 - Char6
65^5 * Char6 + 65^4 * Char5 + 65^3 * Char4 + 65^2 * Char3 + 65 * Char2 + Char1

to unpack them, use modulo division
then translate them back to ASCII using the XLAT table

the resultant data looks like complete garbage
i got a little bit of compression out of it
plus i assured that the help/config file generated by my program would not be tampered with and redistributed

here is the old program...
http://www.masm32.com/board/index.php?action=dlattach;topic=11493.0;id=6257

notice that the zip file is 21 KB - and the config file generated by the 30 KB program is 17 KB
the program without the packed data is about 14 KB

FORTRANS

#39
Hi Paul,

   Hexadecimal converts a 4 bit value i(that holds one of sixteen values)
into one of 16 printable characters.  An eight bit code is broken into two
four bit values that can be converted.

   Base 64 encoding uses 64 characters to encode a 6 bit value to printable
characters.  UUEncode and XXEcode do this.  Four six bit values equal three
eight bit values..

   Base 85 is used by Mime, PostScript, and the (mostly Mac) BtoA
encodings.  There is a penalty for any of these encodings in that the
number of characters expand.  Hexadecimal is twice binary for instance.
To minimize the increase, base 85 uses five characters to encode four
bytes.

   The idea is to take a 32 bit value, divide it repeatedly by 85, and use
one of 85 printable characters to represent the remainders.  I use XLAT
to do the translations from binary to printable.  The reverse is: take a
character, convert it into a number from 0 to 84, and accumulate by
multiplying by 85.

HTH,

Steve N.

;4 PostScript ASCII85 decoder
;4 use !=0 to u=84 and z as 5 zeroes ~> = EOD
;4 ! = 021H, u = 075H, z = 07AH, ~ = 07E
; -1 special indicator, -2 error
;               0   1   2   3   4   5   6   7   8   9   A   B   C   D   E   F
XLATTBL DB     -2, -2, -2, -2, -2, -2, -2, -2, -2, -2, -1, -2, -2, -1, -2, -2
        DB     -2, -2, -2, -2, -2, -2, -2, -2, -2, -2, -1, -2, -2, -2, -2, -2
        DB     -2,  0,  1,  2,  3,  4,  5,  6,  7,  8,  9, 10, 11, 12, 13, 14
        DB     15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30
        DB     31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46
        DB     47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62
        DB     63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78
        DB     79, 80, 81, 82, 83, 84, -2, -2, -2, -2, -1, -2, -2, -2, -1, -2
        DB    128 DUP(-2)

FORTRANS

Hi Paul,

   An elaboration to {hopefully} clarify and expand on my previous
post.  Plus the usual dumb excursion {sorry}.

   From the PostScript Language Reference Manual: {paraphased}
Quote
Binary data bytes are encoded in 4-tuples (groups of 4).  Each 4-tuple
is used to produce a 5-tuple of ASCII characters.  If the binary 4-tuple
is (b1 b2 b3 b3) and the encoded 5-tuple is (c1 c2 c3 c4 c5), then the
relation between them is:

   (b1 x 256^3) + (b2 x 256^2) + (b3 x 256) + b4 =

   (c1 x 85^4) + (c2 x 85^3) + (c3 x 85^2) + (c4 x 85) + c5

In other words, four bytes of binary data are interpreted as a base-256
number and then convereted into a base-85 number. The five "digits" of
this number, (c1 c2 c3 c4 c5) are then converted into ASCII characters
by adding 33, which is the ASCII code for !, to each.  ASCII characters
in the range ! to u are used, where ! represents the value 0 and u
represents the value 84.  As a special case, if all five digits are
zero, they are represented by a single character z instead of by !!!!!.

   And so on, and so forth. with the End-of-Data marker ~> explained.
Clear as fish right?  Flounder anyone?

   You can and add and subtract to do the conversions, but for the
decoder, I like the XLAT table, as it can reduce testing for the special
cases.  Not much point for the encoder though.  Except!

   Now for the evil thought.  As you are only creating this for your
own use, you need not follow the standard too closely.  First, use a
non-standard number for the conversion.  As 89 will not break anything,
and is prime (prime numbers are always fun by definition) you could
use that.  It is a bit inefficient, so the Vulcan Science Council
will frown at you, so watch out.  Then, using a lookup table, rather
than adding and subtracing, you can use a random sequence, rather than
the boring monotonic ordering.  If it confuses your tamperers more than
it confuses you, it should help.  Base-85 (or base-64 for that manner)
looks fairly random to begin with.  A scrambled base-89 won't look much
different, but it will send Alice down a different rabbit hole.

   Actually sounds like a fun little project.

Cheers,

Steve N.