Have you every tried to decrypt "MCPFunctionManager.dll" ? I know that inside we would find the security algorithm for UDS 0x27 (SecurityAccess). I could already get the "keybag" from "AlgData.dll", but it's worthless without the algo.
Currently i don't really know where to start. Tried to load the DLL into IDA but it won't show up much in the "Exports" section, so i assume the DLL is somewhat packed/encrypted.
As always, a base understanding, knowledge and analysing tools are required to start such a journey. I found a neat tool called "DIE - Detect It Easy" here
https://github.com/horsicq/Detect-It-Easy (https://github.com/horsicq/DIE-engine/r ... 09_x64.zip) which give some insights of a file loaded.
A "DLL" is somewhat similar to an "EXE", it could contain data, resources and code. DIE tells this about the file:
Looks pretty handsome and not crypted in first, but why does IDA complain about the file and could not get the functions inside?
Compared with loading "forscan.exe" for example, you see DIE finds the protection:
So this is something "special" inside MCP*.dll. DIE has a entropy-graph tool. You can detect enrcyptions with it. Don't know how that works, but the higher the value the more likely the content is crypted somehow. The graph is clear about what is in the ".text" part of the PE:
Reverse engineer Ford IDS (find SecurityAccess algo)
Reverse engineer Ford IDS (find SecurityAccess algo)
You do not have the required permissions to view the files attached to this post.
Re: Reverse engineer Ford IDS (find SecurityAccess algo)
I know try to start reversing it like malware analysts do, but hope you can help me with that!
Think it can't be simply "decoded" offline, it needs to run some code at the entry-point of the DLL which then decrypts the contents before exporting the functions. Malware analysts and hackers use debuggers for this task. I picked "x32dbg" (which is part of "x64dbg" package) from here: https://x64dbg.com/ (but some also uses OllyDbg https://www.ollydbg.de/).
Of course the packers may took some care to prevent the code from being run in debuggers
but let's see.
The key here is to set breakpoints to let code run in a controlled way until it has unpackt itself and then may store a dump of it to disk for further examination. I've also seen some connecting IDA with a debugger to have both at the same time.
As i am new in this kind of business, don't blame me if my assumptions where all wrong, but correct me![Smile :-)](./images/smilies/icon_e_smile.gif)
Think it can't be simply "decoded" offline, it needs to run some code at the entry-point of the DLL which then decrypts the contents before exporting the functions. Malware analysts and hackers use debuggers for this task. I picked "x32dbg" (which is part of "x64dbg" package) from here: https://x64dbg.com/ (but some also uses OllyDbg https://www.ollydbg.de/).
Of course the packers may took some care to prevent the code from being run in debuggers
![Wink ;-)](./images/smilies/icon_e_wink.gif)
The key here is to set breakpoints to let code run in a controlled way until it has unpackt itself and then may store a dump of it to disk for further examination. I've also seen some connecting IDA with a debugger to have both at the same time.
As i am new in this kind of business, don't blame me if my assumptions where all wrong, but correct me
![Smile :-)](./images/smilies/icon_e_smile.gif)