У нас есть хидер от цэ. Две структуры нужно переделать на фасм. Код (Text): typedef struct _PEB // 65 elements, 0x210 bytes (sizeof) { /*0x000*/ UINT8 InheritedAddressSpace; /*0x001*/ UINT8 ReadImageFileExecOptions; /*0x002*/ UINT8 BeingDebugged; /*0x003*/ UINT8 SpareBool; /*0x004*/ ULONG32 Mutant; // VOID* /*0x008*/ ULONG32 ImageBaseAddress; // VOID* /*0x00C*/ ULONG32 Ldr; // struct _PEB_LDR_DATA* /*0x010*/ ULONG32 ProcessParameters; // struct _RTL_USER_PROCESS_PARAMETERS* /*0x014*/ ULONG32 SubSystemData; // VOID* /*0x018*/ ULONG32 ProcessHeap; // VOID* /*0x01C*/ ULONG32 FastPebLock; // struct _RTL_CRITICAL_SECTION* /*0x020*/ ULONG32 FastPebLockRoutine; // VOID* /*0x024*/ ULONG32 FastPebUnlockRoutine; // VOID* /*0x028*/ ULONG32 EnvironmentUpdateCount; /*0x02C*/ ULONG32 KernelCallbackTable; // VOID* /*0x030*/ ULONG32 SystemReserved[1]; /*0x034*/ ULONG32 AtlThunkSListPtr32; /*0x038*/ ULONG32 FreeList; // struct _PEB_FREE_BLOCK* /*0x03C*/ ULONG32 TlsExpansionCounter; /*0x040*/ ULONG32 TlsBitmap; // VOID* /*0x044*/ ULONG32 TlsBitmapBits[2]; /*0x04C*/ ULONG32 ReadOnlySharedMemoryBase; // VOID* /*0x050*/ ULONG32 ReadOnlySharedMemoryHeap; // VOID* /*0x054*/ ULONG32 ReadOnlyStaticServerData; // VOID** /*0x058*/ ULONG32 AnsiCodePageData; // VOID* /*0x05C*/ ULONG32 OemCodePageData; // VOID* /*0x060*/ ULONG32 UnicodeCaseTableData; // VOID* /*0x064*/ ULONG32 NumberOfProcessors; /*0x068*/ ULONG32 NtGlobalFlag; /*0x06C*/ UINT8 _PADDING0_[0x4]; /*0x070*/ union _LARGE_INTEGER CriticalSectionTimeout; // 4 elements, 0x8 bytes (sizeof) /*0x078*/ ULONG32 HeapSegmentReserve; /*0x07C*/ ULONG32 HeapSegmentCommit; /*0x080*/ ULONG32 HeapDeCommitTotalFreeThreshold; /*0x084*/ ULONG32 HeapDeCommitFreeBlockThreshold; /*0x088*/ ULONG32 NumberOfHeaps; /*0x08C*/ ULONG32 MaximumNumberOfHeaps; /*0x090*/ ULONG32 ProcessHeaps; // VOID** /*0x094*/ ULONG32 GdiSharedHandleTable; // VOID* /*0x098*/ ULONG32 ProcessStarterHelper; // VOID* /*0x09C*/ ULONG32 GdiDCAttributeList; /*0x0A0*/ ULONG32 LoaderLock; // VOID* /*0x0A4*/ ULONG32 OSMajorVersion; /*0x0A8*/ ULONG32 OSMinorVersion; /*0x0AC*/ UINT16 OSBuildNumber; /*0x0AE*/ UINT16 OSCSDVersion; /*0x0B0*/ ULONG32 OSPlatformId; /*0x0B4*/ ULONG32 ImageSubsystem; /*0x0B8*/ ULONG32 ImageSubsystemMajorVersion; /*0x0BC*/ ULONG32 ImageSubsystemMinorVersion; /*0x0C0*/ ULONG32 ImageProcessAffinityMask; /*0x0C4*/ ULONG32 GdiHandleBuffer[34]; /*0x14C*/ ULONG32 PostProcessInitRoutine; // FUNCT_00BC_062E_PostProcessInitRoutine* /*0x150*/ ULONG32 TlsExpansionBitmap; // VOID* /*0x154*/ ULONG32 TlsExpansionBitmapBits[32]; /*0x1D4*/ ULONG32 SessionId; /*0x1D8*/ union _ULARGE_INTEGER AppCompatFlags; // 4 elements, 0x8 bytes (sizeof) /*0x1E0*/ union _ULARGE_INTEGER AppCompatFlagsUser; // 4 elements, 0x8 bytes (sizeof) /*0x1E8*/ ULONG32 pShimData; // VOID* /*0x1EC*/ ULONG32 AppCompatInfo; // VOID* /*0x1F0*/ struct _UNICODE_STRING CSDVersion; // 3 elements, 0x8 bytes (sizeof) /*0x1F8*/ ULONG32 ActivationContextData; // VOID* /*0x1FC*/ ULONG32 ProcessAssemblyStorageMap; // VOID* /*0x200*/ ULONG32 SystemDefaultActivationContextData; // VOID* /*0x204*/ ULONG32 SystemAssemblyStorageMap; // VOID* /*0x208*/ ULONG32 MinimumStackCommit; /*0x20C*/ UINT8 _PADDING1_[0x4]; }PEB, *PPEB; Код (Text): typedef struct _PEB_LDR_DATA // 7 elements, 0x28 bytes (sizeof) { /*0x000*/ ULONG32 Length; /*0x004*/ UINT8 Initialized; /*0x005*/ UINT8 _PADDING0_[0x3]; /*0x008*/ ULONG32 SsHandle; // VOID* /*0x00C*/ struct _LIST_ENTRY InLoadOrderModuleList; // 2 elements, 0x8 bytes (sizeof) /*0x014*/ struct _LIST_ENTRY InMemoryOrderModuleList; // 2 elements, 0x8 bytes (sizeof) /*0x01C*/ struct _LIST_ENTRY InInitializationOrderModuleList; // 2 elements, 0x8 bytes (sizeof) /*0x024*/ ULONG32 EntryInProgress; // VOID* }PEB_LDR_DATA, *PPEB_LDR_DATA; Раз и на всегда хочу решить этот вопрос для себя(а возможно кому-то будет так же полезно) UINT8 InheritedAddressSpace; = InheritedAddressSpace db ? UINT16 OSBuildNumber; = OSBuildNumber dw ? ULONG32 UnicodeCaseTableData; = UnicodeCaseTableData dd ? А вот тут небольшие вопросы: 1)struct _UNICODE_STRING CSDVersion; // 3 elements, 0x8 bytes (sizeof) 1) на фасме получается: label .CSDVersion qword .Все верно или нет ? 2)union _ULARGE_INTEGER AppCompatFlagsUser; 2)на фасме получается AppCompatFlagsUser dq ? В общем давайте все возникающие вопросы относительно хидеров с цэ на фасм скидывать сюда. PS: Кстати у кого какие есть хидеры ? Не отказался бы от любых хидеров. Можно в ПМ Забыл: Код (Text): ;*********************************************PEB************************************************************************************************************ struct PEB ; 65 elements, 0x210 bytes (sizeof) InheritedAddressSpace db ? ReadImageFileExecOptions db ? BeingDebugged db ? SpareBool db ? Mutant dd ? ; VOID* ImageBaseAddress dd ? ; VOID* Ldr dd ? ; struct _PEB_LDR_DATA* ProcessParameters dd ? ; struct _RTL_USER_PROCESS_PARAMETERS* SubSystemData dd ? ; VOID* ProcessHeap dd ? ; VOID* FastPebLock dd ? ; struct _RTL_CRITICAL_SECTION* FastPebLockRoutine dd ? ; VOID* FastPebUnlockRoutine dd ? ; VOID* EnvironmentUpdateCount dd ? KernelCallbackTable dd ? ; VOID* SystemReserved dd ? AtlThunkSListPtr32 dd ? FreeList dd ? ; struct _PEB_FREE_BLOCK* TlsExpansionCounter dd ? TlsBitmap dd ? ; VOID* TlsBitmapBits dd ? ReadOnlySharedMemoryBase dd ? ; VOID* ReadOnlySharedMemoryHeap dd ? ; VOID* ReadOnlyStaticServerData dd ? ; VOID** AnsiCodePageData dd ? ; VOID* OemCodePageData dd ? ; VOID* UnicodeCaseTableData dd ? ; VOID* NumberOfProcessors dd ? NtGlobalFlag dd ? _PADDING0_ db ? CriticalSectionTimeout dq ? ; 4 elements, 0x8 bytes (sizeof) HeapSegmentReserve dd ? HeapSegmentCommit dd ? HeapDeCommitTotalFreeThreshold dd ? HeapDeCommitFreeBlockThreshold dd ? NumberOfHeaps dd ? MaximumNumberOfHeaps dd ? ProcessHeaps dd ? ; VOID** GdiSharedHandleTable dd ? ; VOID* ProcessStarterHelper dd ? ; VOID* GdiDCAttributeList dd ? LoaderLock dd ? ; VOID* OSMajorVersion dd ? OSMinorVersion dd ? OSBuildNumber dw ? OSCSDVersion dw ? OSPlatformId dd ? ImageSubsystem dd ? ImageSubsystemMajorVersion dd ? ImageSubsystemMinorVersion dd ? ImageProcessAffinityMask dd ? GdiHandleBuffer dd ? PostProcessInitRoutine dd ? ; FUNCT_00BC_062E_PostProcessInitRoutine* TlsExpansionBitmap dd ? ; VOID* TlsExpansionBitmapBits dd ? SessionId dd ? AppCompatFlags dq ? ; 4 elements, 0x8 bytes (sizeof) AppCompatFlagsUser dq ? ; 4 elements, 0x8 bytes (sizeof) pShimData dd ? ; VOID* AppCompatInfo dd ? ; VOID* label .CSDVersion qword ; 3 elements, 0x8 bytes (sizeof) ActivationContextData dd ? ; VOID* ProcessAssemblyStorageMap dd ? ; VOID* SystemDefaultActivationContextData dd ? ; VOID* SystemAssemblyStorageMap dd ? ; VOID* MinimumStackCommit dd ? _PADDING1_ db ? ends ;********************************************END PEB********************************************************************************************************* ;********************************************PEB_LDR_DATA**************************************************************************************************** struct PEB_LDR_DATA Length dd ? Initialized db ? _PADDING0_ db ? SsHandle dd ? ; VOID* label .InLoadOrderModuleList qword ; 2 elements, 0x8 bytes (sizeof) label .InMemoryOrderModuleList qword ; 2 elements, 0x8 bytes (sizeof) label .InInitializationOrderModuleList qword ; 2 elements, 0x8 bytes (sizeof) EntryInProgress dd ? ends ;******************************************* END PEB_LDR_DATA************************************************************************************************ укажите на ошибки=)
лучше один раз научиться перерабатывать сишные хидеры(коих заметь чуть по-более, чем в масме), чем перерабатывать масмовские
common_up Можно определить смещения, как например тут http://files.virustech.org/indy/Code/XcptIp/ks386.inc.
выглядит не особо презентабельно. Вообще принципиальной разницы нет как делать. Всеравно при обращении к структуре допустим IMAGE_OPTIONAL_HEADER.blablabla в листиге получаем смещение eax+0xXX. Вообще Ваш вариант тут вообще не по теме. Я немного о другом спрашивал
common_up При обращении к структуре через имена её полей нужно описание этой структуры. При обращении через смещения полей описание структуры не нужно, так поступают если описывать всю структуру желания нет. Вобще следует вначале описать необходимые типы, как например тотже ULONG32 и пр. Тогда не нужно будет определять размер типов. Так следует поступать всегда.
Ладно, давайте не терять чувство реальности. Я с чего начал ? Я начал с того, что нужно сделать некоторые манипуляции, чтобы из цэшных хидеров делать фасм хидеры для работы. Предлагать присваивать членам структур смещения - это совсем не с той оперы. Давайте кто-то подчистит все посты, кроме первого и начнем конструктивный диалог ?
common_up Давайте смотреть на вещи реально. Вы не знаете стандартных типов си и пытаетесь транслировать хидер. Ну что тут можно сказать - изучать си. И незачем писать модерам, ведь сообщение я тоже вижу ваше. Если в ручную не хотите - использовать конверторы, на сколько помню здесь их описывали, поиск используйте. Не знаете типов - какие есчо вопросы вы можите тут задавать. Трудно вбить в поисковик "UINT8" ?
а зачем писать на MASM? зачем пользоваться label есть чудесная дирректива virtual at. А чтобы не париться про размер структур, лучше объявлять эту структуру. если она состоит в "юнионе" то указать её через virtual at намного проще. при объявлении Посмотри как я объявил структуру IRP на FASM, сишное объявление найдёшь в инете Код (Text): struc __TAIL { .__tail db 47 dup (?) virtual at .__tail .Overlay.DriverContext dd 4 dup (?) ;16 virtual at .Overlay.DriverContext .Overlay.DeviceQueueEntry KDEVICE_QUEUE_ENTRY end virtual .Overlay.Thread dd ? ; 4 .Overlay.AuxiliaryBuffer dd ? ; 4 .___ db 12 dup (?) virtual at .___ .Overlay.ListEntry LIST_ENTRY ; 8 .Overlay.CurrentStackLocation dd ? ; 4 label .Overlay.PacketType dword at .Overlay.CurrentStackLocation end virtual .OriginalFileObject dd ? end virtual virtual at .__tail .Apc KAPC ;47 end virtual virtual at .__tail .CompletionKey dd ? ; 4 end virtual } struc IRP { .Type dw ? .Size dw ? .MdlAddress dd ? .Flags dd ? .AssociatedIrp.MasterIrp dd ? label .AssociatedIrp.IrpCount dword at .AssociatedIrp.MasterIrp label .AssociatedIrp.SystemBuffer dword at .AssociatedIrp.MasterIrp .ThreadListEntry LIST_ENTRY .IoStatus IO_STATUS_BLOCK .RequestorMode db ? .PendingReturned db ? .StackCount db ? .CurrentLocation db ? .Cancel db ? .CancelIrql db ? .ApcEnvironment db ? .AllocationFlags db ? .UserIosb dd ? .UserEvent dd ? .Overlay dq ? virtual at .Overlay .Overlay.AllocationSize LARGE_INTEGER end virtual virtual at .Overlay .Overlay.AsynchronousParameters.UserApcRoutine dd ? .Overlay.AsynchronousParameters.UserApcContext dd ? end virtual .CancelRoutine dd ? .UserBuffer dd ? ;union .Tail __TAIL } ; IRP
2rpy3uH: Везде использовать точки - становится нечитабельно. по крайней мере там где они крайне не необходимы Все, вроде разобрался. Топик не закрывайте, мб еще вопросы появятся
корректна ли такая интерпритация сишного хидера ? Код (Text): ;typedef struct _IMAGE_THUNK_DATA32 { ; union { ; PBYTE ForwarderString; ; PDWORD Function; ; DWORD Ordinal; ; PIMAGE_IMPORT_BY_NAME AddressOfData; ; } u1; ;} ;IMAGE_THUNK_DATA32 equ _IMAGE_THUNK_DATA32 struct IMAGE_IMPORT_BY_NAME Hint dw ? Name rb 01 ends PIMAGE_IMPORT_BY_NAME equ IMAGE_IMPORT_BY_NAME struct _IMAGE_THUNK_DATA32 label .u1 dword union ForwarderString db ? Function dw ? Ordinal dw ? AddressOfData IMAGE_IMPORT_BY_NAME ends IMAGE_THUNK_DATA32 equ _IMAGE_THUNK_DATA32 ends
common_up, Естественно, нет. PBYTE <> db, PDWORD <> dw, DWORD <> dw, PIMAGE_IMPORT_BY_NAME <> IMAGE_IMPORT_BY_NAME. «Любите книгу — источник знания.» — А. М. Горький