The Intel and AMD instruction sets are similar but not identical.
There are many examples of that: FMA3/FMA4, AMD-V and VT-x (and their extensions), etc.
The fast system call interface is yet another difference.
Intel supports SYSENTER in all modes1 - Legacy Mode (or, on the few 32-bit only Intel CPUs, simply Protected Mode), Long Mode and Compatibility ...
In gdb you can set a syscall breakpoint with catch syscall.
If this is in 32-bit x86 (IA-32), check the syscall number in your_linux_source_dir/usr/include/asm/unistd_32.h. There is no syscall called socket in 32-bit x86, do you mean socketcall? Its number is 102.
If this is in x86-64 (AMD64), check the syscall number in your_linux_kernel_source_dir/usr/...
I don't think I disassembled any microkernels, but "message passing" is common in at least two categories of programs: Win32 GUI (both raw Win32 and MFC-based), and Objective-C executables.
In both cases you have some kind of a central dispatcher routine (or routines) that accept messages and forward them to some recipients, which may be inside or outside ...
Libraries like STL or Boost are tricky. Because they're heavily template-based and most of their code is generated at compile time, it's pretty difficult to make FLIRT-style signatures for them. Too much depends on the specific compiler, build options, optimization settings and so on, so unless you match them pretty closely when generating signatures, you're ...
2) The system call is ptrace. That call has lots of functionality, including "copy a section of the tracee's memory into a local buffer in my address space" and the reverse "copy my buffer to the tracee's memory". These are quite similar to windows' ReadProcessMemory and WriteProcessMemory. The tracing program needs to use these to access memory in the ...
Most RTOS code is usually a single monolithic binary and is not split into separate binaries like a high-level OS. Usually there is some startup code, some library routines and user-provided code in forms of tasks which are nothing more than simple functions performing the necessary work in a simple infinite loop. The “main function” called by the RTOS ...
I think there's a couple of approaches to get where you want. Given your scenario where you have the KB patch on your fully updated system. To get back to the previous version, uninstall that patch.
The Metasploit Unleashed class used (still does?) has this command for XP that uninstalls all the patches:
C:\>dir /a /b c:\windows\$ntuninstallkb* > ...
I'm not 100% sure I understand your question but I'll try to answer it.
First I would prepare VMs for the Windows versions you want to target. Every day you could create a snapshot which means that you can go back to that point in time at any future date. Snapshotting is something most VMs support. Then I would run Windows update on the VMs. This means ...
VMWare offers a very useful snapshot functionality which makes it extremely simple to switch beween different states of the same VM. You can automate the process with VIX.
I assume other VM solutions have something similar as well.
You seem to have a misunderstanding of the relationship between the hardware of a computer and the operating system. I suggest you start reading http://en.wikipedia.org/wiki/Operating_system
The operating system lives on top of the hardware. There's no need to look at any electrical signals to alter OSX or Windows, you can do this on a far higher level ...
alt + f1 d fs: ollydbg 1.10 raw peb
with stolly plugin for 1.10 select the first byte in dump->right click->sructure
select _peb from drop down box for decoded peb .
al+g fs: in ollydbg 2.01 fully decoded _peb in dump / disasm window
Open the Memory Map window in OllyDbg/ImmunityDbg, scroll down to the bottom, and double click on the entry that contains Process Environment Block. This will open a dump of the PEB in OllyDbg/ImmunityDbg:
The call instruction is nothing but a fancy jump to a location in the code. Usually, it's a basic block ending with a ret instruction, namely a function. So at the address 0x00408b6d, you'll find a function.
The lea instruction has nothing to do with the leave instruction. lea stands for 'load from effective address' meaning that the eax register will ...
Bachelor's project is supposed to be a showcase of a person's
strengths in computer science
I don't have any first hand experience of [reverse engineering]
Given your two statements above, I would posit that you should not do your bachelor's project on reverse engineering :(
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 ...
PIN_AddSyscallEntryFunction and PIN_AddSyscallExitFunction should do the trick. Link to the Documentation.
Snippet using theses APIs : (credits to Jurriaan Bremer)
void syscall_entry(THREADID thread_id, CONTEXT *ctx,
SYSCALL_STANDARD std, void *v)
printf("system-call: %d, arguments:",
Yes, you would need to patch ci.dll (which contains the list of hardcoded Root CAs) and winload.exe (which validates the integrity of ci.dll).
You can find this discussed in http://www.programdevelop.com/4608016/.
Your files aren't plain disk images, they are using the Encase File Format. Your repetitive bytes seem to be artifacts of that file format.
There's a newer specification of the file format as well, but it requires registration.
Autopsy probably recognizes the file format, so it removes the parts of the file that belong to the file format, not the sector ...
Pintools on Windows can also aid you in instrumenting system calls. Also, if its discovered that the cpu supports sysenter/syscall, those are used in place of int 2e. However, this has no bearing on whether or not instrumentation can take place.
To answer your second question, yes, NtReadFile, NtWriteFile and NtDeviceIoControlFile are the *nix equivalent of ...
Yes it's very possible to understand the workings of systems without access to the source code. One of the problems is that the transformation of source code to the binaries which run on the platform is rarely without information loss. This means that it's usually impossible to reconstruct the source code from the binaries. Also you can't really redistribute ...
Generally a reverse engineer translates assembly code to a higher level language, for that reason it is quite a necessity to be familiar with that language (or at least a similar language), usually understanding the intrinsics of those languages and how common language constructs are translated to the lower level is very helpful.
Understanding system level ...
FireEye's FLARE VM
FLARE VM is a freely available and open sourced Windows-based security
distribution designed for reverse engineers, malware analysts,
incident responders, forensicators, and penetration testers. Inspired
by open-source Linux-based security distributions like Kali Linux,
REMnux and others, FLARE VM delivers a fully configured ...
The Intel processors still support 16-bit real mode so the latest manuals do describe it as well, although not as prominently as protected or long mode. Look for mentions of “Real-Address or Virtual-8086 Mode”.
Sections are always mapped to the same location relative to each other (the section table in the file describes the layout, via the VirtualAddress field). Only the starting address for the entire module can change. The relocation table is generally(*) used to update absolute values according to the difference between the starting address that was specified ...
It is a bit of a chicken and egg issue here. While it may be possible that there is some custom USB command to dump the firmware, you’re unlikely to discover it by chance without analyzing actually running firmware.
About the only possibility I can think of is DFU (Device Firmware Update) which is a semi-standard protocol for updating firmware of USB ...
Generally system programming is not required, but recommended...
It is also important to understand the application flow, the CPU architecture (stack, heap, exceptions), file format (PE, ELF).
I suggest two good resource:
Reverse engineering for beginners - https://beginners.re/RE4B-EN.pdf
tuts4you - https://tuts4you.com/download.php?list.17
I would like to see the actually files that were patched ...
New-school: Attack Surface Analyzer
... and see what in the code might have been changed and see what the problem was.
As @Neitsa said, see how can I diff two x86 binaries at assembly code level?
Visit a site with legal reverse engineering challenges like e.g. crackmes.de, solve at least five challenges up to a level of three (level one being the easiest, 5 and up are difficult even for the experienced), and then start with your thesis. Your background in cryptology will help you on the higher levels.
Be warned - you will need patience and must not ...