This is normally not possible. The icon is part of the resource section (.rsrc) which is covered by the signature so any modification will invalidate it and the binary needs to be re-signed.
There may be some parts of the executable you can change without invalidating the signature, but the resource section is not one of them.
There are many steps to patch an executable, but here is I think the easiest one. The highlighted one is the EntryPoint, you can patch the highlighted one and redirect it to your control, in my sample, I added a new executable section but remember, you have to return the control to the original program, or else it will not run properly.
Although this question is a bit broad, I feel that I can provide an acceptable answer by at least explaining some ways that I've used file format structures in reversing.
First of all, a reverse engineer "in the workforce" always has some goal. For example, a malware analyst working at an antivirus company may analyze a sample to:
Learn how the same works
You understanding is correct:
PE's IAT is resolved by the system loader and can be made read-only afterwards.
ELF's GOT entries initially point to PLT stubs and are overwritten with the final address on the first call.. meaning GOT needs to remain writable.
Writable GOT is indeed a known source of vulnerabilities which is why mitigations like RELRO have ...
IDA is displaying the Relative Virtual Address based on the base address of the binary (or on that you supply before loading the binary). The reason this is different from the actual address is because it is mapped into memory. The Relative Virtual Address (RVA) is BaseAddress + Offset, if you find the offset address and add it to your at rest binary base ...
If you don't have the GetProcAddress() function, you have to iterate entire export table, here a example how i made it in the past...
NTSTATUS GetRemoteProcAddressArch(HANDLE hProcess, HMODULE ModuleHandle, LPCSTR RoutineName, PULONG_PTR hRoutine)
HMODULE hModule = GetModuleHandleA("Ntdll.dll");
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 ...
Yes, you can (assuming the info is not faked). I made a script which includes some of the common compiler/linker identifiers, and evening for missing ones you still have the build number from which you should be able to track down the specific Visual Studio version.
Script in case if it is lost
# based on code from http://trendystephen.blogspot.be/2008/01/...
Size Of Heap by Default is 1MB Reserve and 1KB commit
these can be changed by using linker option /HEAP:<reserve>,commit
During Initialization of Process system/loader/os Creates a Process Heap for Each Process
Changing the SizeOfHeapCommit and Reserve Changes the Size of this ProcessHeap
the Address Heap Thus Allocated During Process ...
Windows Loader Knows the import is bound because bind process also writes a timestamp of the bounded module
suppose x.exe is bound to y.dll
y.dll has a TimeDateStamp in it peheader
when bound it writes the TimeDateStamp of y.dll in the
0:000> dt ole32!_IMAGE_BOUND_IMPORT_DESCRIPTOR
+0x000 TimeDateStamp : ...
When analyzing software suspected to have been designed for criminal purposes, uploading the file to VirusTotal seems to be a good first step. In this case, when this file is uploaded to VirusTotal and we click on the "Behavior" tab, there is a ...
You can extract some file from .exe using pyi-archive_viewer, modify them and put back. But be attention, all files in .exe are compressed using DEFLATE (zlib.compress() - you can watch this in source code of PyInstaller). So, when putting back you need compress file to the exact size, that was when you extracted it.
Most of the time it is just a benign side effect of linking in code that exposes their APIs as DLL exports. It is fairly common for 3rd party middleware/libraries to do this so that their code will work in both DLLs and EXEs without modification.
For boost, any of their methods that are marked with BOOST_SYMBOL_EXPORT will get tagged for DLL export:
push 402010 is broken down like
402010 - base_address - virtual_address_of_section + file_ptr_to_rawdata
your data has some inconsistencies it must be a counted string or pascal string etc there is a 4 byte mismatch between the addresses 0xc/0x8
disassembly of a string push
0:000> u . l4
002c1000 55 push ebp
You are right, this is because of alignment.
There are 2 types of section alignment. Alignment on disk, and alignment in memory. They usually equal 0x400 and 0x1000 respectively. When you open exe in hexeditor, you should notice that your .text section starts at 0x400, but Ghidra shows you exe as it would be in memory, so .text now starts at 401000 (...
I tried to replicate to hijack the entrypoint, but in this example, the first instruct is not jump, so I have to find another instruction with size of 5 which call 0x449674.
I appended another section text.
I generated a simple shellcode with this command.
msfvenom -p windows/exec CMD=calc.exe EXITFUNC=none -f hex
What I had to do is write the shellcode ...
I actually think this is a good and valid question.
And I think the answer here is - it is because it is. What I mean is that they analyzed a bunch of samples, separated them into malicious/benign, and then found out that when these flags are set it's almost always malware, so it makes a good indicator because they observed it to be a good one.
I can't ...
The other two answers are wrong.
I reversed link.exe and the way it works is that if the “function” points into the export directory (NTHeaders.OptionalHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_EXPORT].VirtualAddress <= func_ptr < NTHeaders.OptionalHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_EXPORT].VirtualAddress + NTHeaders.OptionalHeader....