In PE files, sections are generally mapped at addresses that are multiples of 4kb (this is the default value, though it can be overridden). That means that even a section that is a single physical byte long will have the entire 4kb of memory allocated for it. The first section is mapped into memory after the file header, so it will be 4kb away from the ...
xxtea encrypt with KEY: sxpDM2018
how find the KEY
IDA look at Function window
press CTRL+F and type xxtea_decrypt. double click first item and scroll up to see cocos2d::FileUtilsAndroid::getData
double click cocos2d::FileUtilsAndroid::getData and press F5 to decompiler
look at image xxtea_decrypt, you can see v34 is KEY
scroll up ...
It sounds to me like your problem is the code in VS, not what you've found through reversing. The beginning of the function there doesn't seem to matter in accordance to what you're trying to do. Correct me if I'm wrong, but it sounds to me like you're thinking you have to find your way to the beginning of the function so that you can then figure out how far ...
Nexide, wild guess but your game is complied with il2cpp.
You could use Scylla to dump GameAssembly.DLL
and you'll get a dumb folder and with that you use Il2cppDumper, drag both the Globalmeta.dat file and the GameAssembly.dll-Dumped file inside where all the il2cppdumper dlls are stored, then run Il2cppdumper then press GameAssembly.dll then Globalmeta ...
Short answer: Because your average program will never access those values.
Long answer: Peter ferrie's answer states there's usually nothing present at that offset. That is not true. The shortest possible valid header for a Portable Executable is 0xc8 long. But that's for a program with a single section, no imports (or anything else that would require a ...
There is not a single Anti Cheat(AC) I am aware of that is kernel mode without using ObRegisterCallbacks to block access to the process. In fact a good number of the AC drivers I've looked at are nothing more than these callbacks and, sometimes, kernel pattern scans. Nearly every kernel mode AC will also have an IOCTL pipe that's pretty obvious (e.g \Device\...
The files you linked, whilst all having an NSH extension actually appear to be slightly different archive formats.
Each of these archive file appears to contains a number of graphics shaders compiled to bytecode for the various architectures. The binary formats of these shaders vary significantly between architectures.
A couple have very obvious clues ...
When you want to unpack/decrypt files like this, the best idea is always to reverse the program that is able to read the file correctly. I think that in Windows operating system the most popular combo for reading files is probably CreateFile and ReadFile api calls. If you track every operation performed on the buffer filled using ReadFile ...
[RAX=0x33307EE0 + RCX=0x0 * 0x8] == [0x33307EE0+0x0] = 0x33307EE0
compare whatever is at Address 0x33307EE0 with r9 register
[RAX=0x33307EE0 + RCX=0x377F1FD0 * 0x8] == [ 0x33307EE0 + 0x1bbf8fe80] = 0x1ef297d60
mov into rcx whatever is there at 0x1ef297d60
you really need to find some reading/viewing material on assembly
it is always better to read a book on ...
By finding the constructor for the structure type that you're looking at, making note of the VTable address, and adding the indicated offsets to obtain the concrete function pointers for the calls in question.
This depends on the implementation of the game in the browser.
The API is likely a RESTful API and the format for data exchange is likely JSON.
A modern full stack web development course will often cover both of these subjects.
In terms of reverse engineering the API itself, there's not a huge challenge. Restful APIs and JSON are chosen because they're easy ...
UnityPlayer.dll is the engine itself - it doesn't contain any user-made scripts. Assembly-CSharp.dll is the main user script dll, and if, as you say, it isn't being affected, you're either modifying an unused class, or they moved to il2cpp (in which case there will be a GameAssembly.dll next to the exe) and just forgot to remove the old files.
I have no experience in writing a DLL, but what I understand is that I should be able to compile functions inside the DLL then somehow call them from the executable, and my hope would be that I don't need to modify the executable itself. Can someone confirm this?
This is correct.
Check out https://docs.microsoft.com/en-us/windows/win32/dlls/dllmain, common ...
Assuming you're trying to intercept function calls and manipulate / get the input to that function, you are going to need to hook it first.
I'd recommend reading about function hooking (there's a plenty of information out there regarding this subject).
Its basic idea is rather simple, given the start address of function to be hooked func01 you override the ...
Next time please include the original apk in your question. Luckily I'm working on the same game so I can help somewhat.
Get the old apk (yzjlzl_2.80_1_20180918_170403_83de83.apk) from bilibili (google it) and use IDA to decompile it. This is an obvious solution to JNI_Onload obfuscation if you want to do static debugging.
One of the other way to do this is ...
Maybe. If the Source File of the Classes are present you can reverse the Class names.
Unfortunatly there are no ways to retrieve Methods and Fields names. The only thing that you can do for that is renaming the fields and methods with unique names to make the code more readable.
You can use de4dot, its best to restore a packed assembly, if failed to unpack files try x64dbg and ScyllaHide plugin to dump and restore the dll.
Win32 dumper doesn't show .Net assembly and need a .Net dumper like MegaDumper OR ExtremeDumper
As you said, the Lua engine is embedded directly into the game. It's inside plugins/GameManagerVC.dll (or GameManagerVC64.dll in case of 64-bit).
So, first step will be finding out, which version of Lua it is. So put this DLL into Ghidra or IDA Pro. The most easiest way of figuring out, what version of Lua it uses, is by searching for "Lua" string ...
If you know where the data is going to be before it's written, you can set a write hardware breakpoint and it should stop whenever that memory location is populated.
Otherwise, you'll to reverse engineer where RCX comes by going up the stack frame judging by the decompiled output.
I have found temporary solution to my issue. I have enabled option "Stay on top" (CTRL+F5) in x32dbg. This way I can go back to debugger to resume execution.
It would be better to also enable window mode in game, but it is not possible in this situation.
Important note: Reverse engineering of proprietary products can be legal issue, make sure you covered on it.
Regarding your question:
Download IDA Free 7.0 https://www.hex-rays.com/products/ida/support/download_freeware.shtml
Load binary you try to debug in Olly in IDA and go to the specific address you see on the picture. [Press G and enter 0x463016 for ...
I voted to close this question because it is, unfortunately, too broad to properly answer.
One has to gain some knowledge and experience in the reverse engineering world before one can tackle some of the real-world scenarios. you may want to start with learning assembly and doing a few crackmes, which are designed to improve one's reverse engineering skills....