The encryption routine is not likely to be in your call stack because it is not actually going to call the send function directly.
I would suggest you set a watch point inside the buffer to catch whenever the buffer is written to. Routines that write to the buffer will probably be reading from some input buffer. There could well be a few steps of adding ...
I solved this by manually fixing each missing import API.
First I did a text dump of the unpacked dll using BinText where I found a list of imported API's.
I then compared it to the list of API detected by ImpRec and I noticed that the calls are in the same order on the text dump.
So I just double clicked the line of the invalid import on ImpRec and ...
This file seems to have some kind of header followed by an array of UnityFS files.
Although I won't be writing a script for you, it should not be too difficult to write one that can at least extract all the UnityFS files contained by it.
I believe there are tools that can read UnityFS files, but I didn't test any of them.
Here's what I found out about this ...
Include the targets of the pointers into the snapshot (can be done by enabling the target segment’s loader flag in segment properties, or via “Analyze module” from the Modules context menu)
Rename the import table pointers using the pointed-to names (e.g. using renimp.idc or similar script)
Manually unpacking is an art that takes lots of practice, but you're starting off right by working on the most simple examples. You need to have a solid understanding of the tools involved in the process and the PE file format. There are quite a few resources out there, but I've had great success spinning up folks with [yates] old docs on PE files, and Lena'...
binwalk easily finds the beginning of the lzma file but not the end.
It is necessary to modify the files extracted with a Hexadecimal editor.
I don't have the same version as you but for TD-W8961ND_V3_140305.bin:
The first extracted file (in 0x14C33) contains from the offset 0x41cf many 0x00,
all the following bytes must be deleted.
In my version the file ...
I you really want to try making the unpacked executable, OllyDumpEx works in IDA too.
However, there is an alternative approach: a loader. This is a program which starts the target in paused state, puts breakpoint on OEP or some initially called APIs then lets it run. Once the breakpoint is reached, you can patch anything you need. This way you don’t need to ...
In some games I have found the encryption on, it has been before the send call e.g. a function that calls send sometimes 2-3 calls up.
For recv it is decrypting after but some first decrypted part of it for a header to look up the size/id.
Others had compressed packets (zlib) which took a little bit of figuring.
A trick to see if is possibly compressed or ...
i found a tool for unpacking UPX x64.exe it work for me.
it is called XVolkolak v0.22 i found it here: http://ntinfo.biz/index.html
its a universal tool so it can unpack other packers to.
Have a nice day.
Try using Image File Execution Options registry key to automatically run the debugger when the process starts.
Patch an infinite loop (EB FE) at the entry point, start the binary, then attach to it from a debugger started as admin.
Use kernel debugger or hypervisor-based debugger to debug the process without relying on user mode debugging ...
When debugging, IDA uses the actual content of the memory as well as the runtime memory layout and permissions. If the data you loaded into the IDB is not present at runtime, or loaded at a different address/permissions, it will be ignored.
Just because you added something to the IDB will not make it appear magically in the debugger, since the OS uses the ...
It seems that APK resources were obfuscated with AndroResGuard. ApkTool can (mostly) decompile it but compilation is performed with standard aapt2 and it does not understand 'drawable2' resource type, so it complains about invalid file path.
You can find more info on this issue here: https://github.com/iBotPeaches/Apktool/issues/1719