By this screenshot it's not really clear if it's MFC or not, due to MFC can be linked statically. And when MFC is linked statically you won't see any MFC function name in the imports window. Nevertheless, if IDA detects static MFC library it tries to apply MFC signatures msmfc*.sig So you should check the signatures window in IDA too and see if it found ...
In order to easily import the information into IDA it's possible to:
Download Visual C++ and MFC (ideally the same version)
Make a very small C++ file which contains the definition of the type, for example:
(you can verify that afxwin.h header indeed contains the definition of the class) Assume the file is saved as a.cpp
You might have a look here, line number 456.
The method you are looking for seems to be the OnIdle function.
Remark: In 2018, the link is not active any more. However, the sources might be found in a Visual Studio Community edition (I am using VS2015), directory
"C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\atlmfc\src\mfc".
The CWinThread ...
All statically linked MFC binaries I've seen always include strings for some internal classes. The naming convention can be found in afximpl.h:
#define AFX_WNDCLASS(s) \
_T("Afx") _T(s) _T(_MFC_FILENAME_VER) _STATIC_SUFFIX _UNICODE_SUFFIX _DEBUG_SUFFIX
#define AFX_WND AFX_WNDCLASS("Wnd")
#define AFX_WNDCONTROLBAR ...
If it's challenging or not depends entirely on what you do to make it challenging and the skill level of the attacker. For some it's already enough if you make the decompiler in some old leaked IDA version fail, others read the pure assembly and know exactly what's going on not needing the decompiler at all.
The best way to prevent tampering is having ...
These are functions exported by ordinal rather than by name.
This being a C++ library the actual (mangled) function names are long (up to 200 characters with an average of over 50.) Dynamic linking using names in this case would involve lots of long string comparisons that would slow down the loading of applications using this library.
The main problem is: /Zi is required. Including just /debug is not enough. That's because the type information is stored in the compiler .pdb file. See also Compiler PDB file and the Linker PDB file - Stack Overflow.
The command line can looks like this:
cl.exe /Zi a.cpp /EHsc /link /subsystem:windows
Note that /Zi implies /debug (therefore it's not ...
What is "*(_DWORD *)(a1 - 12) - v3 - 1" doing?
this is probably undocumented or poorly documented i don't know
these are from memory of my fiddling with this Cstring (be aware for misinterpretation from my part too )
it is trying to return you the substring after *\*
the Cstring when initialized is normally a part of a bigger structure or class or ...
to know that, it's better to look at assembler, not pseudocode. If there's an argument passed to sub_428258 through ECX, most likely yes, this should be a method of some class.
maybe error code, which should be returned by the function. I.e. current function definition might be wrong. Can't tell without seeing the assembler.
seems like it's accessing to some ...
You just have to attach to the desired process with ollydbg or something similar and breakpoint ReadFile,WriteFile and CreateFile. (If you also need the information about the connection itself like baudrate or stuff like that you will have to set a breakpoint at SetCommState too.)
After hitting a breakpoint you just have to follow the pointer on top of the ...
I ended up using the tool API Monitor. It took a ton of filtering, but I eventually found a reference to CreateFileA. Odd, because Ida Pro does not reference CreateFileA anywhere. Either way, it works! Thank you!