So I compiled winipt and ptdump from libipt I got a trace but ptdump prints garbage. Additionally I created a dump using MiniDumpWriteDump with MiniDumpWithIptTrace and opened it both with VS and windbg but I don't think they are recognizing the trace either.
I'm currently downloading intel studio since it has widnbg extensions for ipt support but I've heard also of REPT.
In the video it's showing some futuristic looking windbg and it's setting a hw breakpoint which then triggers on backwards execution.
You are almost there, but partly you are doing it wrong and Alex's code is not so complete.
Note that Alex's code is a POC as he says, IMHO it's not really complete to go right to a a file and decoder. Also note that ptdump is just an example. If you can find a sample trace that is just pure IPT packets then it will work as is.
Step through how ipttool outputs the data (for one thing it saves a header that you are not accounting for), vs how ptdump loads a binary.
winipt is used in this project:
https://github.com/googleprojectzero/winafl
Unfortunately as we both found there is no official support for Intel PT on Windows yet like there is on Linux which has complete support for it.
Yea apparently they added support to MiniDumpWriteDump(). You can see the support for it by symbols in dbgcore.dll. Could not find any documentation for it either. On MSDN they define the IPT type enums but then there is zero descriptions of what they do.
Parsing a normal/old mini-dump is probably a project in it's self. I bet though if you can parse a normal/default mini-dump, you will figure out how to parse the IPT section out of it too.
Anyhow depending on what you want to do, probably just a a buffer full and it want's to write to a file.
Update:
Actually it looks like PssNtCaptureSnapshot() would give us direct access to a IPT snapshot using the PSS_CAPTURE_IPT_TRACE flag, then followed by a PssQuerySnapshot() function to get the data. Still one will have to parse it considering the headers like struct IPT_TRACE_DATA.
https://learn.microsoft.com/en-us/windows/win32/api/processsnapshot/nf-processsnapshot-psscapturesnapshot
Related
I am in a process of learning things in reverse order for fun, and I have decided to dissect Windows 10, bit-by-bit, and learn what makes a great OS function. And I also suppose that my question will be geared in other ways as well.
My question is, how do I look at something like Windows bootmgr source code properly? I have opened the file - which the file type is redundantly called "File" - and even though it is in Assembly language, it is completely impossible to read. My guess is that whoever wrote the File did something to encrypt the File so that it is unreadable, and thus unchangeable/unable to be edited.
Let me be perfectly clear: my purpose is not to change the bootmgr File to change windows, but rather to get a better understanding of how an OS works via reading, and also through trial and error.
Any help that anyone can give would be greatly appreciated. I love to learn about these things, and I just have been completely unable to find the answer I am looking for on any site thus far, including this one...IDK if I need to refine my searches or what.
Thank in advanced for your help. :)
Ps. I shall include a picture of what I am seeing in Notepad++ so you can get a better understanding of what I need here .
I think you may be confusing assembly language with machine code. Machine code is the language that your computer's processor understands. Assembly language is a series of symbols that are used to represent machine code. Compiled executables are stored in machine code.
That said, the standard way to view the machine code for a compiled binary is through the use of a program called a hex editor. A hex editor will display the binary code in a numerical format, rather than attempting to interpret the binary as text, like your editor is trying to do in the screenshot you supplied. Frhed is a popular hex editor, but there are many good ones to choose from.
Does it possible debug Tcl/tk application for Windows, without the source code? The application have no support and there is no source code available. There is error shown during one of operation. Is it possible to find what cause an error and whether error can be fixed by patching code?
It's very difficult without the source code, as it is at the level of the source code where you'd need to make the patch. If the code is exposing itself via the send command mechanism (or the comm package) you can probably make a bit of progress (as there's quite good introspection capabilities in Tcl by default, so info commands, info vars and info body may help, along with many other info commands and some introspectors that are elsewhere too), but it's still really difficult, particularly if you don't understand the internal structure of the code. OTOH, I wouldn't expect a production application to expose itself this way; typically you disable that sort of thing when outside development.
A standard debugger like gdb won't help, especially with the Tcl 8.6 non-recursive runtime. (Tcl applications in that environment just tend to show up as effectively “doing stuff”; there's nothing to really indicate how it hangs together.)
But the first thing to check is whether you actually have the source code. It's possible that the code has just been packaged together as a Starpack and that you can use a tool like sdx to extract the things you need to make changes in. But you aren't guaranteed to succeed at that; if the code was compiled/obscured with a commercial tool like the TDK, you really don't have the source and can't really do much about it. (By the same general principles that mean that DRM doesn't work well, it's possible to decompile the .tbc files that the TDK produces, but that's really a last-ditch thing to do as it is technically illegal in some jurisdictions, morally rather dodgy, and inclined to produce really awful output.) Can you contact the original author(s) of the code instead? If that works, it'll be cheaper and simpler…
If you've actually got the human-readable code, even if packaged with sdx, then you can do a lot more.
All texts on how to create a compiler stop after explaining lexers and parsers. They don't explain how to create the machine code. I want to understand the end-to-end process.
Currently what I understand is that, the Windows exe file formats are called Portable Executable. I read about the headers it has and am yet to find a resource which explains this easily.
My next issue is, I don't see any resource which explains how machine code is stored in the file. Is it like 32-bit fixed length instructions stored one after another in the .text section?
Is there any place which at least explains how to create an exe file which does nothing (it has a No Op instruction). My next step then would be linking to dll files to print to console.
Nice question! I don't have much expertise on this specific question, but this is how I would start:
PE or ELF does not create pure machine code. It also contains some header info etc. Read more: Writing custom data to executable files in Windows and Linux
I assume you are looking for how does ELF/PE file hold the machine code, you can get that from this question (using objdump): How do you extract only contents of an ELF section
Now, if you want to know how the content part is generated in the first place, i.e. how is the machine code generated, then that's the task of the compiler's code generation.
Try out some resource editor like ResourceEditor to understand the exe or simply ildasm.
PS: These are mostly Unix solutions, but I am sure, PE should be doing something fundamentally similar.
I think the best way to approach it will be first try to analyze how existing PE/ELFs work, basically reverse engineering. And to do that, Unix machine will be a good point to start. And then do your magic :)
Not same but a similar question here.
Update:
I generated an object dump out of a sample c code. Now, I assume that's what you are targeting right? You need to know do you generate this file (a.out)?
https://gist.github.com/1329947
Take a look at this image, a life time of a c code.
Source
Now, just to be clear, you are looking to implement the final step, i.e. conversion of object code to executable code?
As in many of his articles, I'd say Matt Pietrek's piece about PE internals remains the best introdction to the matter more than a decade after being written.
Iv'e used "Wotsit's File Format" for years... all the way back to the days of MS-Dos :-) and back to when it was just a collection of text files you could download from most BBS systems called "The Game programmers file type encyclopaedia"
It's now owned by the people that run Gamedev.Net, and probably one of the best kept secrets on the internet.
You'll find the EXE format on this page : http://www.wotsit.org/list.asp?fc=5
Enjoy.
UPDATE June 2020 - The link above seems to be now dead, I've found the "EXE" page listed on this web archive page of the wotsit site: https://web.archive.org/web/20121019145432/http://www.wotsit.org/list.asp?al=E
UPDATE 2 - I'm keeping the edit as it was when I added the update erlier, thanks to those who wanted to edit it, but it's for a good reason I'm rejecting it:
1) Wotsit.org may at some point in the future come back online, if you actually try visiting the url, you'll find that it's not gone, it does still respond, it just responds with an error message. This tells me that someone is keeping the domain alive for whatever reason.
2) The archive links do seem to be a bit jittery, some work, some don't, sometimes they seem to work, then after a refresh they don't work, then they do work again. I remember from experience when wotsit was still online, they they had some very strange download/linking detection code in, and this probably caused archive.org to get some very wierd results, I do remember them taking this stance because of the huge number of 3rd party sites trying to cash in on their success, by pretending to be affiliate's and then direct linking to wotsit from an ad infested site.
Until the wotsit domain is removed entirely from the internet and not even the DNS responds, then would be the time to wrap everything up into single archive links, until then, this is the best way to maintain the link.
Not surprisingly the best sites for information about writing PE format files are all about creating viruses.
A search of VX Heavens for "PE" gives a whole bunch of tutorials for modifying PE files
Some information about making PE files as small as possible: Tiny PE.
The minimalistic way to mess around with code generation, if you're just looking to try a few simple things out, is to output MS-DOS .COM files, which have no header or metadata. Sadly, you'd be restricted to 16-bit code. This format is still somewhat popular for demos.
As for the instruction format, from what I recall the x86 instruction set is variable-length, including 1-byte instructions. RISC CPUs would probably have fixed-length instructions.
For Linux, one may read and run the examples from
"Programming from the Ground Up" by Jonathan Bartlett:
http://www.cs.princeton.edu/courses/archive/spr08/cos217/reading/ProgrammingGroundUp-1-0-lettersize.pdf
Then of course one may prefer to hack Windows programs. But perhaps the former
gives a better way to understand what really goes on.
Executable file format is dependent on the OS. For windows it is PE32(32 bit) or PE32+(64 bit).
The way the final executable look like depends on the ABI (application binary interface) of the OS. The ABI tells how the OS loader should load the exe and how it should relocate it, whether it is dll or plain executable etc..
Every object file(executable or dll or driver) contains a part called sections. This is where all of our code, data, jump tables etc.. are situated.
Now, to create an object file, which is what a compiler does, you should not just create the executable machine code, but also the headers, symbol table, relocation records, import/export tables etc..
The pure machine code generation part is completely dependent on how much optimized you want your code to be. But to actually run the code in the PC, you must have to create a file with all of the headers and related data(check MSDN for precise PE32+ format) and then put all of the executable machine code(which your compiler generated) into one of the sections(usually code resides in section called .text). If you have created the file conforming to the PE32+ format, then you have now successfully created an executable in windows.
OK, the Windows dev platform I have is a Windows XP box and a copy of Visual C++ 6.0. I'm trying to create or modify security descriptors for a service. My initial thought from other answers (and some reading) was that I should use ConvertStringSecurityDescriptorToSecurityDescriptor to setup my security descriptor.
Except...my install of VC++ 6.0 lacks the headers for this function (sddl.h according to MSDN).
Can anyone point me to other APIs for creating/modifying Security Descriptors? I'd be happy if I could walk through an existing one (I can QueryServiceObjectSecurity) and just eliminate certain users, but I can't figure out how to do that just looking at MSDN.
Alternately, if someone could point me in the direction of how to call this function without proper headers, that would be fine.
Obvious answer rebuttal: I can (and will) make an attempt to get IT to install a newer version of VC++ on my system, but the last time I asked IT about anything significant it took 7 weeks for them to respond. Since I'd like to get this done in the next week or two, I think IT is not going to fix this question for me in a timely manner.
In theory, you don't need a newer compiler, just an updated SDK. In reality, VC++ 6 is old enough that it may have trouble parsing the headers for a current SDK though.
As an alternative to that, you could declare pointers to the correct types of functions in your code, then use LoadLibrary and GetProcAddress to get the addresses of the correct functions, then call the functions via those pointers.
As an aside, however, I'd point out that I doubt what you've envisioned will work. I've never tried to do exactly what you're trying, so it's always possible I'm wrong, but every time I've done anything manipulating security descriptors, DACLs, SACLs, or anything similar in Windows, the code's ended up considerably longer and more complex than it initially seemed like it should. Even something extremely trivial generally requires at least a couple hundred lines of code...
You could check out the DCOMPerm sample, it has handles the DACL/ACE and other structures you are going to run into - thats where i started when i created a set of classes to handle this for our COM installations - and as #jerry coffin said it ended up being a lot of code.
You'll have to download the SDK to get the sample.
Is it possible to remotely debug a process started outside VB6?
The application is a VB6 application with quite a few dll/ocx resources. I am attempting to setup a ClickOnce deployment, using Registration-Free COM, of the VB6 app but have been getting errors when it executes.
My understanding of the way that VB6 redirects COM registerations will probably mean that this is not possible but I thought someone might have a better idea.
To support Darryl's answer suggesting Windbg - here's a 2006 blog post by a Microsoft guy about using Windbg with VB6, and 2004 blog post by another Microsoft guy with a brief introduction to Windbg.
EDIT: Just to make it totally clear. Windbg is a free standalone debugger from Microsoft. Compile your VB6 EXEs, DLLs and OCXs into native code with symbols (create PDB files) and you will be able to debug your ClickOnce application.
Key excerpt from the blog:
If you have limited access to the server machine then you can use the
remote debugging facilities of WinDbg. Attach a copy of WinDbg to the
process in the usual way and then turn it in to a debugging server
(check out .server in the WinDbg help). You can then connect to it
remotely from the File menu of WinDbg. It will be just like being
there except for the lack of noise from the server room fans. When
debugging a remote, your copy of WinDbg is just a very smart terminal
so all extensions, symbols and so on have to be on the remote server.
You set this up the exact same way for any DLL, VB6 or .NET.
The symbols for your component will not load until your component does
and so you have to let the server run at least that long. You can put
a break in early in your VB code if you want to stop the debugger at
that point but if you do, remember that it will stop there every time
through the code. Let’s assume that you let it run and then break in.
If you list the loaded symbols for your module with "x MyModule!*"
then you will see all of your functions together with a lot of symbols
bundled in there for you. VB adds interfaces and symbols quite
unashamedly but you don’t generally need to worry about those. One
thing that will probably look strange is that all class/method syntax
with the C++ double colon convention instead of the friendly little
dot. WinDbg doesn’t understand that VB is different and it is treated
just like any DLL with symbols.
From here, you can set breakpoints in the usual way (bp etc) and step
through code. You can also open up VB source code modules and set
breakpoints in them with F9 although the VB file extensions are not in
the source file type dropdown. Stepping through the code is revealing
but might be a little alarming if you have not seen the code that VB
generates for you before. You will be stepping through the assembler
and there is a lot of COM goo in there. Hresults get checked a lot.
You will probably need to refer to the source often to work out where
you are since it takes a bit of practice to be able to know what the
source code looked like. Variants are especially challenging because
VB does a lot of work for you there and what looks like a simple
equation can result in a great deal of code. Optimised code is even
harder because the order of execution is often very different from
what you might expect and it is harder than usual to see the data.
Data is not easy to get at this way. When you look at local variables
(dv is the command) then you may see that variables are simply listed
as eclipsed which means that the memory is being used for something
else as well within the function lifetime or that the name is not
unique in this context. Enums just show as integers or longs and
objects show as pointers. In fact, they always were exactly that but
the VB IDE hides that from you. VB strings are COM BSTRs (and
accordingly Unicode) under the covers and byte arrays are really char
arrays. You might be surprised to discover that VB strings are Unicode
as VB appears to have no support for anything but ANSI. That is
because the Ruby forms engine was ANSI only. The runtime converts the
Unicode strings to ANSI for Ruby and API calls although there are ways
to pass Unicode if you want.
You are not going to be able to get at the Err, App or Printer objects
since you would need to go through a lot of internal and completely
undocumented structures to get at them. Even if you could get there,
they would just be raw data without the accessor functions that you
use in VB. If you need to look at any of those fields, your best bet
is to embed debug code in the source code to copy their values to
somewhere that you can get at.
You can step in to the VB runtime if you want but it probably won’t be
very revealing if you are trying to debug your application. If you do,
you will notice that VB’s internals are very COM influenced. The
influence was actually two way since some COM ideas came from VB
originally.
You may see exceptions when running your code. Null reference
exceptions (i.e dereferencing a null pointer) are not uncommon or
anything to worry about. They will show up as first chance C000005
exceptions with a 0 or almost 0 address. The runtime will sometimes do
that if there are objects set to nothing but that is safe because the
only possible values are null or a valid value. You will also see
exceptions if your code does lookups in collections and the value is
not there. Because exceptions are now so expensive, you probably want
to avoid doing that if you can. Another exception that you will
commonly see is c000008f. If you look the number up then you will find
that it is a floating point inexact result exception. It is used in a
different meaning here – since we don’t generate real floating point
inexact result exceptions, they can safely be thrown to indicate VB
errors of the normal trappable type.
Debugging hangs and crashes in VB components is done very much in the
same way as with any other unmanaged component but it is just a little
harder because of the compilations described above. If you have to try
debugging VB code this way, I would strongly recommend that you start
on a "Hello world" application and work your way up. All the things
that may VB an easy language to code in make it a terrible language to
debug.
I believe that when debugging in VB6, it does not attach to a running binary but instead interprets the code within it's own process. This is why the Task Manager and Win32 APIs show VB6.exe as the running app when debugging.
Also as you say, VB6 sometimes short-circuits calls to COM libraries so intercepting these calls is not always possible.
You're probably going to have to resort to intelligent logging (i.e. log the values of variables around the points where the errors you are getting occur in the hope of locating the line of code it occurs on, and/or the state of relevant variables.)
Good luck
Have you tried windbg? Just make sure you have pdb files for the project.