AutoIt Machine Code Algorithm Collection

[trancexx]

That beta version included some undocumented changes to the COM code which were later reverted because they were bad. Maybe there were similar type of changes (dumb type) for DllCall or structs too, maybe for some String functions too. Check contents of $_B64E_Init, $_B64E_EncodeData and $_B64E_EncodeEnd structures and see if you get any differences with betas that crash and AutoIt that works.

Ward uses extended nop instructions to locate opcodes chunks. That means you can change that part of his code to this:

$_B64E_Init = (StringInStr($Opcode, "89C0") + 1) / 2
$_B64E_EncodeData = (StringInStr($Opcode, "89DB") + 1) / 2
$_B64E_EncodeEnd = (StringInStr($Opcode, "89C9") + 1) / 2

...which would eliminate those nop-s. Maybe some AutoIt compile options changed too, maybe it's some undocumented standard UDF change like those that were done for number of standard structures and that are script breaking as well as undocumented.

Check MVP forum, in beta threads it can be seen that some non-developers influence development a lot, for bad really but still.

Only Jon can give you answers to most of those questions. What's really weird is that it works for me.

Edited September 20, 2013 by trancexx

[Beege]

This is working for me as well with Win 7 x64 3.3.9.19. I wonder if this is something to do with windows 8. 

[JScript]

@Ward

Hello friend!

Do I have any chance of having access to the source code of the following items:?

Checksum
  CRC32
  ADLER32

Compression
  LZMA

If not possible, no problem!

Thank you,

JS

[Ward]

CRC32:

unsigned long crc32(unsigned char* data, unsigned long len, unsigned long crc32, unsigned long poly)
{
    unsigned long table[256], crc;
    int i, j;

    for(i = 0; i < 256; i++)
    {
        crc = i;
        for (j = 8; j > 0; j--)
        {
            if (crc & 1)
                crc = (crc >> 1) ^ poly;
            else
                crc >>= 1;
        }
        table[i] = crc;
    }

    for(i = 0; i < len; i++)
    {
        crc32 = (crc32 >> 8) ^ table[(crc32 ^ data[i]) & 0xFF];
    }

    return crc32 ^ 0xFFFFFFFF;
}

ADLER32:

#define MOD_ADLER 65521

int adler32(unsigned char* data, int len, unsigned int sum)
{
    unsigned int tlen, a, b;
    a = sum & 0xffff; b = sum >> 16;

    while (len > 0)
    {
        tlen = len > 5552 ? 5552 : len;
        len -= tlen;
        do
        {
            a += *data++;
            b += a;
        } while (--tlen);

        a %= MOD_ADLER;
        b %= MOD_ADLER;
    }

    return (b << 16) | a;
}

LZMA: http://www.7-zip.org/sdk.html

[JScript]

Thank you my friend!

JS

[wraithdu]

trancexxx's suggestion to change the '-3' to '+1' fixed the base64end crash I was experiencing on x64.

However after looking through UEZ's base64 to string compression app and the LZMAT UDF here, there are some problems. I realize at the time that CallWindowProc was the hack used to make this kind of thing possible, however it's not necessary anymore since we have DllCallAddress. Under most circumstances the simple change is fine. However the case with LZMAT is troublesome. In that particular UDF (and perhaps others) the CallWindowProc parameters are being abused and this is leading to crashes on either x86 or x64 depending how it is modified.

A good example of this is the _LZMAT_CodeDecompress function. The 3rd parameter to CallWindowProc is a UINT. This function's call to 'DllStructGetPtr($CodeBuffer) + $AP_Decompress' is passing a pointer in its place. On a x64 system this is a problem. It will work with DllCallAddress on x64 and CallWindowProc on x86, but not vice versa. I don't know why x86 doesn't work with DllCallAddress.

I know it's been ages since you've updated these UDFs, but any chance you can redo them using DllCallAddress and sanity check the parameter passing?

[KaFu]

I know it's not what you're asking for, but wouldn't some @AutoItX64 switches at the rights places do it in the meantime?

[wraithdu]

They are already there. But there has to be something up with the parameters the machine code is expecting. Without the function prototypes however, tough to know.

[kara2004]

Hello Ward,

thank you for your excellent work.

The UDF's work fine on Windows 7 (x64), but using them on Windows 8 causes some problems in x64-Applications (x86 works fine,too).

For example in MD5.au3 I located the problem at the end of function "_MD5_CodeDecompress($Code)":

Func _MD5_CodeDecompress($Code)
...
Local $ResultLen = DllStructGetData(DllStructCreate("uint", DllStructGetPtr($Output)), 1)
    Local $Result = DllStructCreate("byte[" & ($ResultLen + 16) & "]")
    msgbox(0,"Trace","1")
    Local $Ret = DllCall("user32.dll", "uint", "CallWindowProc", "ptr", DllStructGetPtr($CodeBuffer) + $AP_Decompress, _
                                                    "ptr", DllStructGetPtr($Output) + 4, _
                                                    "ptr", DllStructGetPtr($Result), _
                                                    "int", 0, _
                                                    "int", 0)

    msgbox(0,"Trace","2")

    _MemVirtualFree($CodeBufferMemory, 0, $MEM_RELEASE)
    Return BinaryMid(DllStructGetData($Result, 1), 1, $Ret[0])
EndFunc

Message "1" is shown, but then the app crashes:

Problemsignatur:
  Problemereignisname:    APPCRASH
  Anwendungsname:    autoit3_x64.exe
  Anwendungsversion:    3.3.12.0
  Anwendungszeitstempel:    538b66a5
  Fehlermodulname:    StackHash_76a1
  Fehlermodulversion:    0.0.0.0
  Fehlermodulzeitstempel:    00000000
  Ausnahmecode:    c0000005
  Ausnahmeoffset:    PCH_21
  Betriebsystemversion:    6.2.9200.2.0.0.768.101
  Gebietsschema-ID:    1031
  Zusatzinformation 1:    76a1
  Zusatzinformation 2:    76a173c26a6dc2e3cd83ac8fd9f8bdb9
  Zusatzinformation 3:    7b3f
  Zusatzinformation 4:    7b3f634c955ac91fe3f1e745337a968a

What's the problem ??

Thanks

kara

Edited August 3, 2014 by kara2004

[Ward]

This is an old project...

I will update these codes by using my new >BinaryCall UDF in someday.

[wraithdu]

I actually just saw that project and have been playing around with it. Very cool!

Do you have the source code for these libraries published anywhere that we could take a hand at updating them?

[prazetto]

Hi Ward,

There is AP_Decompress machine code in every this Machine Code Algorithm Collection UDF

to decompress  that right called after base64 decoding every machine code embedded in UDF script.

Mind you share the compressor itself. Or by the way what is algorithm name?

 

[Lucid]

Ward,

Is there any chance you could take a look into your AES.au3 code and see what it would take to get it to work when compiling to an x64 executable? I ran into an issue when using RTFC's CodeCryptor (https://www.autoitscript.com/forum/topic/155538-codecrypter-encrypt-your-script/). Everything works just fine when compiling to x86. It's just x64 that's causing me an issue (and of course, the bit of code I'm working on HAS to be x64).

Thanks for all the hard work you did on everything! It's helped a TON!

[Biatu]

Can someone post latest zip? Ward's files are MIA, and i use them all the time  Thanks.

[argumentum]

On 5/27/2016 at 1:44 AM, Biatu said:

Can someone post latest zip? Ward's files are MIA, and i use them all the time  Thanks.

ok, attached below.

AutoIt Machine Code Algorithm Collection ( in the file downloads section )

Edited August 6, 2018 by argumentum
moved file to downloads

[tubaba]

On 2016/5/28 at 7:23 PM, argumentum said:

ok, attached below.

AutoIt Machine Code Algorithm Collection.zip

Thanks a lot, I've been looking for it for a long time. All links are invalid.

[Hawlong]

❤️❤️

[Jaycee1030]

On 11/11/2010 at 3:03 PM, Ward said:

CRC16

Hi i would to know if the udf for crc is still avaialble