You can use PDB downloader which doesn’t require any installation https://docs.microsoft.com/en-us/archive/blogs/webtopics/pdb-downloader. Or you could use its source below to see how you could recreate with PowerShell or some other method.
You can also just copy the WinDBg files from a machine where it’s ...
In the Loaded Type Libraries window (View->Open subviews->Type libraries), load ntddk_win10 (or whatever Windows version you want, back to Windows XP and Windows Server 2003).
In the Structures window (View->Open subviews->Structures), import KUSER_SHARED_DATA. You can simply write the name of the type in the dialog box and ...
At a guess (since you don't provide much detail), the binaries you're looking at were compiled using a recent version of Microsoft Visual C++. The listed APIs are used by its CRT (C runtime) library in functions referenced by the startup or essential runtime code which is linked into every executable by default. You can find (most of) the CRT sources ...
those are pointer arithmetics
marks is an <<<;ADDRESS;>>>>> assume 0x10000000
it points to an integer whose size is 4 in 32 bit machine
so the next integer will be at 0x10000004 ,
and the next will be at 0x10000008 and so on
&marks = 0x10000000
&marks = 0x10000004
&marks = 0x10000008,c,10,14,18,.....nn
each of ...
I've just received from a friend a *.idb file concerning the pe file i'd like to disassemble in IDA.
a IDB file is IDAs primary project/database format
its the result of an IDA exe load + analyze run
What the file is and how can i load/use it with the exe linked with it in IDA?
just open it with IDA
I'm starting in RE too (since beggining of 2020), and I thought I could put here what I've learned so far. Maybe it might be of help.
So first of all, you need Assembly knowledges. You asked if it's still worth to learn x86 because there is x64 now. Well, that's a thing I learned too. x64 is just an extension of x86. The real name for x64 is actually x86_64. ...
Executable relocations, whether performed for optimization or security, will only relocate the image (executable, shared object) as a whole.
For that reason, to bypass ASLR for example, any single address within a chosen shared object is sufficient. Given, of course, you know the precise version and build of the shared object. Knowing the specific build ...
It all depend of what you plan to reverse and how.
For purely static analysis, your operating system don't really matter, since there are great tools for both Windows and Linux systems(and nowadays you can even run Linux tools in the Windows linux subsystem, or use wine to emulate Windows utils on a Linux native system).
But if you have to run what your are ...
The Current ebp points to the previous ebp
and by inference the call that setup the previous ebp
in windbg with a 32 bit binary this script will walk the stack you can use follow in dump in ollydbg to do the same
r $t0 = @eip
r $t1 = @ebp
.while (@$t1 !=0)
.printf "eip = %08x\tebp = %08x\t callee = %y\n" , @$t0 ,@$t1,poi(@$t1+4)
r $t0 = ...
The PE import thunks do not work the same way as ELF PLT. There is no dynamic resolver invoked on the first call but all import pointers are resolved at the process startup ahead of time (similar to LD_BIND_NOW). The pointers are grouped in a GOT-like Import Address Table (IAT) and the metadata with the details about the DLLs and symbols imported is ...
No it does not all pe files do not start at the same address 0x401000
historically 0x400000 is the ImageBaseAddress Header is 0x1000 bytes
so .code section starts at 0x401000 for a normal exe
since the Exe's module is the first to be loaded it normally gets its Preferred ImageBase Address
but a relocation table is a part of exe in case there is a conflict ...
first of all you have a 32bit binary and you are debugging it on a 64 bit system
see the wow64 symbol
it means you are looking at some kind of in-between
it means the far jump is pointing to a different code segment (see the present code segment 0x43 versus the codes segment of 0x33
please get yourself familiarised with code segments and privilege levels
Yes, mov DWORD PTR 40[rsp], 6 is the same as mov DWORD PTR [rsp + 40], 6. The first syntax makes a lot more sense in cases where the constant is the base address of an array, and the register contains a byte offset into that array. That's the use case the syntax was designed for.
Yes, this is possible with some cooperation from the debugger. The OllyMigrate plugin supports migration between following debuggers:
It seems Visual Studio is not supported but you can always do it the manual way:
Patch an infinite loop (EB FE) at the current EIP/RIP;
Detach the current debugger. ...
CreateRemoteThread takes 7 arguments and the 4th of them is called lpStartAddress.
Now, from MSDN docs:
A pointer to the application-defined function of type LPTHREAD_START_ROUTINE to be executed by the thread and represents the starting address of the thread in the remote process. The function must exist in the remote process. For more ...
If all you're trying to do is replicate what the SysInternals project does, the strings2 project you linked does that and should suit your purposes. The x86/x64 thing is only for a special extraction mode they added, which is separate from the functionality of SysInternals Strings.
On the other hand, if you do need to extract strings stored more sneakily (...
Linux kernel can boot mostly on its own by probing the hardware and using the linked-in drivers. The NT kernel requires an environment such as UEFI or legacy BIOS and relies on it, for example, to load additional drivers. It also expects to be loaded in a certain manner by the pre-loader (winload.efi) while Linux has less strict requirements.
This is why ...
EPROCESS does not represent OBJECT_HEADER
!process 0 0 notepad.exe provides you an EPROCESS
I think object_header is not documented
on x86 (win7 sp2) it was 0x18 bytes before the OBJECT
the Typeindex field also has been repurposed if i am not mistaken in newer OS
the following display is from a win7sp2 32bit vm
kd> dt nt!_OBJECT_HEADER TypeIndex @$proc-...
as i commented in latest windows type index has been randomised
it is a xor of the index with nt!obHeaderCookie and the second byte of OBJECT_HEADER Address
0: kd> ?? (char *)@$proc->ImageFileName
char * 0xffffa083`398ab4d0
0: kd> ?? ((nt!_object_header *) @@masm( @$proc - @@c++(#FIELD_OFFSET(nt!_OBJECT_HEADER , ...
procmon can help in locating an entry point or a point of ingress
remove all filters
try typing something like "turbox the t" in the start menu
go to tools->file summary->extension tab and expand the wildcard (*) entry
you may notice this file has been searched on the PATH paths
click one entry ...
I can't make comments yet, so will try to submit this as an answer, hopefully that helps:
You can try to pass that exception to the application and see if it is capable of dealing with it.
To do this you go to Debugger -> Debugger Options -> Edit exceptions... (button on the bottom of the Options dialog).
Then select your exception, RMC on it and ...
Loading and successfully running code associated with an arbitrary PE may require some additional steps e.g. relocation. Consider converting the EXE into a DLL like this or this so that you can use Windows APIs to load the code for you.
For .NET assemblies there's a .NET MetaData Directory that can be found in the Data Directories. From that you can get access to MetaData Header and MetaData Streams that holds all the info for you to extract and located the code.
A good start (or maybe even a complete guide) into this topic would be the "Anatomy of a .NET Assembly" by Simon Cooper....
Simple, it's a section that will supposedly be mapped as paged memory. This can contain code or data and is governed by the PAGED_CODE macro, among others, at source code level.
That is, whatever gets stored in that section cannot be accessed at arbitrary IRQLs. Quote:
If the IRQL > APC_LEVEL, the PAGED_CODE macro causes the system to ASSERT.
Also see ...
Default VS compilation options do not enable debugging information generation so all function names are removed from the final executable (they're not required for execution). You need to build with debug info on and ensure that the PDB file is available when you open the exe in IDA.
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 ...