It's definitely not invertible.
To see this you only need to consider the contents of tmp1 after 2 iterations of the first loop.
Let's unroll these 2 iterations (and, for simplicity of exposition only, assume tmp1 was zero on entry to the loop.) This gives -
tmp1 = _array_1[ 0 ] * 64 + _array_1[ 1 ];
The values of the first two input ...
It's probably AES. I saw config files at HG8245Hv5 and HG8245H5 and passwords are looking similar. A bit (just a bit:D) more info is here: https://the-infosec.com/2017/03/20/huawei-hg8245h-router-privilege-escalatio/
You can use the zcu module to do this.
python examples/encode.py config.bin.xml out.bin --key 'GrWM2Hz<vz&f^5' --signature 'ZXHN H108N V2.5'
Full disclosure: I wrote the zcu module. It's based off of this pastebin.
During my analysis I use Floss!, it is an excellent tool and super simple to use, on several occasions I can find the strings I am looking for, you used PEID to check for packers please use a more up-to-date tool like DIE (Detect it Easy), if it is an .EXE file consider analyzing with a professional and updated debbuger like x96DBG(x64dbg/x32dbg), I believe ...
Post the data as hex. 100 messages would be great.
Are you using ANSI encoding to make patterns in the data easier to see?
My guess is there's something like ROT or an xor going on here with messages [monitor] recv() buf: ï|W,7¼≤╛ and [monitor] recv() buf: ïxS*4¬≤╗ being the key the server wants the client to use as that's the first place they change between ...
For static analysis, you can use VMAttack plugin for IDA pro. Or if you wanna find how the buffer is built before it's sent you can try ScyllaHide plugin for x64dbg to debug the VmProtected executable. This plugin will help you overcome VMprotect's anti-debug and anti-vm protections. After that simply put a breakpoint on those calls that you hooked and ...
Assuming this is a firmware file, a good first step would be to identify where execution starts. You could do this by:
finding the type of processor / microcontroller / system-on-chip and checking for the reset vector (try searching for product approvals, e.g. from the FCC, which might contain interior images).
scanning the file for known byte sequences ...
This format looks like little endian 32bit ints starting at Byte 12.
The data shows low entropy so it's unlikely to be encrypted, as well as having consistent 0 valued MSB's in consistent positions across both messages.