Recent Posts

Pages: 1 ... 6 7 [8] 9 10
71
The Campus / Re: 128 bit Comparison on 32-bit CPU
« Last post by AW on November 08, 2019, 12:51:24 AM »
 :biggrin:

Before I look at the code, make sure you are using the latest releases either of VS 2017 or 2019 because there was a "while" bug only recently fixed.
Either way, what I made was just a sketch. I can't spend much more time with that. It is a good exercise for you.
72
The Campus / Re: 128 bit Comparison on 32-bit CPU
« Last post by colinr on November 08, 2019, 12:35:40 AM »
@AW

I've implemented the new code that you wrote into my project (after reversing it), and initial testing (with 1 IP) indicates that it may be working, however, there were a couple of bugs.

I you take a look at labels L0085100F and L00851050, they were originally on the next instruction down (CMP), I found that EAX was being trashed by the value written to EAX from EDI+8, thus causing the lookup to fail. I suppose I could optomise this by using EBX instead of EAX, and save some cycles instead of reading EDI+12 on each iteration that it returns here.

Other than that, thank's very much for helping me out with this, what in theory is easy to achieve proved extremely difficult.

I also don't understand what condition would cause L008510A2 to be reached.

I'll do some more testing and post back.

Code: [Select]
LookUpIPv6Country:
xor edx, edx
xor eax, eax
mov eax, dword ptr[IPv6CountryFileSize]
mov ebx, 34 ;Will be dividing by 34 bytes
div ebx

mov edx, eax
mov esi, dword ptr[IPv6CountryMem] ;Pointer to IPv6 data

lea edi, CountryFormedIpV6_1 ;The IP to find

L0085100F:
mov eax,dword ptr [edi+12]

cmp eax,dword ptr [esi+12]
  jbe short L00851019
  dec edx
  je NotAV6CountryAddress
add esi,34
jmp short L0085100F
L00851019:
jb short L00851050
mov eax,dword ptr [edi+8]
cmp eax,dword ptr [esi+8]
jbe short L00851028
dec edx
je short NotAV6CountryAddress
add esi,34
jmp short L0085100F
L00851028:
jb short L00851050
mov eax,dword ptr [edi+4]
cmp eax,dword ptr [esi+4]
jbe short L00851037
dec edx
je short NotAV6CountryAddress
add esi,34
jmp short L0085100F
L00851037:
jb short L00851050
mov eax,dword ptr [edi]
cmp eax,dword ptr [esi]
jbe short L00851043
jmp short L00851047
L00851043:
jmp short L008510A2
L00851045:
jmp short L0085100F
L00851047:
lea edi, CountryFormedIpV6_1
L00851050:
mov eax,dword ptr [edi+12]

cmp eax,dword ptr [esi+28]
jbe short L00851059
jmp short L00851093
L00851059:
cmp eax,dword ptr [esi+28]
jae short L00851060
jmp short L008510A3
L00851060:
mov eax,dword ptr [edi+8]
cmp eax,dword ptr [esi+24]
jbe short L0085106C
jmp short L00851093
L0085106C:
cmp eax,dword ptr [esi+24]
jae short L00851073
jmp short L008510A3
L00851073:
mov eax,dword ptr [edi+4]
cmp eax,dword ptr [esi+20]
jbe short L0085107F
jmp short L00851093
L0085107F:
cmp eax,dword ptr [esi+20]
jae short L00851086
jmp short L008510A3
L00851086:
mov eax,dword ptr [edi]
cmp eax,dword ptr [esi+16]
jbe short L00851091
jmp short L00851093
L00851091:
jmp short L008510A3
L00851093:
dec edx
je short NotAV6CountryAddress
add esi,34
  jmp L0085100F

L008510A2:
nop
retn
L008510A3:
nop
sub esi,34

retn

NotAV6CountryAddress:
lea eax, IPv6CountryISOCode
mov byte ptr[eax], "Z"
mov byte ptr[eax+1], "Z"
ret
73
The Campus / Re: 128 bit Comparison on 32-bit CPU
« Last post by TimoVJL on November 07, 2019, 10:59:07 PM »
just for fun for x64 :smiley:
if main symbol exists, link.exe wants mainCRTStartup as entry point
so just give it
Code: [Select]
; ml64.exe hello64m.asm
includelib msvcrt
extern printf : proc
extern exit : proc

.data
msg   db "Hello world!",0

.code
public main
main: ; just tells to link.exe of console program
mainCRTStartup proc ; for link.exe if main defined
sub rsp, 28h
mov rcx, offset msg
call printf
call exit
main endp
end
EDIT: ip list:
ip2location.com/lite/
IP to Country Lite
74
The Campus / Re: 128 bit Comparison on 32-bit CPU
« Last post by colinr on November 07, 2019, 10:06:01 PM »
Spot on! I didn't realise the Start: label was missing.

Thanks for that
75
The Campus / Re: 128 bit Comparison on 32-bit CPU
« Last post by hutch-- on November 07, 2019, 09:48:14 PM »
It means you have not specified an entry point so the linker wants the C entry point code instead.
76
The Campus / Re: 128 bit Comparison on 32-bit CPU
« Last post by colinr on November 07, 2019, 08:54:06 PM »
@AW Back again!

I've tried to assemble the code above with WinAsm and the method that you described before, both report the following error:

LNK1120: 1 unresolved externals

LINK : error LNK2001: unresolved external symbol _WinMainCRTStartup

I have no clue what this means


77
The Campus / Re: Color Buttons
« Last post by guga on November 07, 2019, 11:43:48 AM »
Btw....PEB64 is given like this (Updated to the last Windows 10 version

Code: [Select]
[PEB64:
 PEB64.InheritedAddressSpace: B$ 0
 PEB64.ReadImageFileExecOptions: B$ 0
 PEB64.BeingDebugged: B$ 0
 PEB64.SpareBool: B$ 0
 PEB64.Padding1: D$ 0
 PEB64.Mutant: Q$ 0
 PEB64.ImageBaseAddress: Q$ 0
 PEB64.LdrData: Q$ 0
 PEB64.ProcessParameters: Q$ 0
 PEB64.SubSystemData: Q$ 0
 PEB64.ProcessHeap: Q$ 0
 PEB64.FastPebLock: Q$ 0
 PEB64.FastPebLockRoutine: Q$ 0
 PEB64.FastPebUnlockRoutine: Q$ 0
 PEB64.EnvironmentUpdateCount: Q$ 0
 PEB64.KernelCallbackTable: Q$ 0
 PEB64.EventLogSection: D$ 0
 PEB64.EventLog: D$ 0
 PEB64.FreeList: Q$ 0
 PEB64.TlsExpansionCounter: Q$ 0
 PEB64.TlsBitmap: Q$ 0
 PEB64.TlsBitmapBits: D$ 0 #2
 PEB64.ReadOnlySharedMemoryBase: Q$ 0
 PEB64.ReadOnlySharedMemoryHeap: Q$ 0
 PEB64.ReadOnlyStaticServerData: Q$ 0
 PEB64.AnsiCodePageData: Q$ 0
 PEB64.OemCodePageData: Q$ 0
 PEB64.UnicodeCaseTableData: Q$ 0
 PEB64.NumberOfProcessors: D$ 0
 PEB64.NtGlobalFlag: D$ 0
 PEB64.CriticalSectionTimeout: Q$ 0
 PEB64.HeapSegmentReserve: Q$ 0
 PEB64.HeapSegmentCommit: Q$ 0
 PEB64.HeapDeCommitTotalFreeThreshold: Q$ 0
 PEB64.HeapDeCommitFreeBlockThreshold: Q$ 0
 PEB64.NumberOfHeaps: D$ 0
 PEB64.MaximumNumberOfHeaps: D$ 0
 PEB64.ProcessHeaps: Q$ 0
 PEB64.GdiSharedHandleTable: Q$ 0
 PEB64.ProcessStarterHelper: Q$ 0
 PEB64.GdiDCAttributeList: Q$ 0
 PEB64.LoaderLock: Q$ 0
 PEB64.OSMajorVersion: D$ 0
 PEB64.OSMinorVersion: D$ 0
 PEB64.OSBuildNumber: W$ 0
 PEB64.OSCSDVersion: W$ 0
 PEB64.OSPlatformId: D$ 0
 PEB64.ImageSubSystem: D$ 0
 PEB64.ImageSubSystemMajorVersion: D$ 0
 PEB64.ImageSubSystemMinorVersion: D$ 0
 PEB64.Padding2: D$ 0
 PEB64.ImageProcessAffinityMask: Q$ 0
 PEB64.GdiHandleBuffer: Q$ 0 #30
 PEB64.PostProcessInitRoutine: Q$ 0
 PEB64.TlsExpansionBitmap: Q$ 0
 PEB64.TlsExpansionBitmapBits: D$ 0 #32
 PEB64.SessionId: D$ 0
 PEB64.Padding3: D$ 0
 PEB64.AppCompatFlags: Q$ 0
 PEB64.AppCompatFlagsUser: Q$ 0
 PEB64.pShimData: Q$ 0
 PEB64.AppCompatInfo: Q$ 0
 PEB64.CSDVersion.UnicodeStr64.Length: D$ 0
 PEB64.CSDVersion.UnicodeStr64MaximumLength: D$ 0
 PEB64.CSDVersion.UnicodeStr64Buffer: Q$ 0
 PEB64.ActivationContextData: Q$ 0 ; Points to ACTIVATION_CONTEXT_DATA structure
 PEB64.ProcessAssemblyStorageMap: Q$ 0
 PEB64.SystemDefaultActivationContextData: Q$ 0 ; Points to ACTIVATION_CONTEXT_DATA structure
 PEB64.SystemAssemblyStorageMap: Q$ 0
 PEB64.MinimumStackCommit: Q$ 0
 PEB64.FlsCallback: Q$ 0
 PEB64.FlsListHead.Flink: Q$ 0
 PEB64.FlsListHead.Blink: Q$ 0
 PEB64.FlsBitmap: Q$ 0
 PEB64.FlsBitmapBits: D$ 0 #4
 PEB64.FlsHighIndex: Q$ 0
 PEB64.WerRegistrationData: Q$ 0
 PEB64.WerShipAssertPtr: Q$ 0
 PEB64.pContextData: Q$ 0
 PEB64.pImageHeaderHash: Q$ 0
 PEB64.TracingFlags: D$ 0
 PEB64.Padding4: D$ 0
 PEB64.CsrServerReadOnlySharedMemoryBase: Q$ 0
 PEB64.TppWorkerpListLock: Q$ 0
 PEB64.TppWorkerpList.Flink: Q$ 0
 PEB64.TppWorkerpList.Blink: Q$ 0
 PEB64.WaitOnAddressHashTable: Q$ 0 #128]

and PEB (PEB32) is like:

Code: [Select]
[PEB:
 PEB.InheritedAddressSpace: B$ 0
 PEB.ReadImageFileExecOptions: B$ 0
 PEB.BeingDebugged: B$ 0
 PEB.SpareBool: B$ 0
 PEB.Mutant: D$ 0
 PEB.ImageBaseAddress: D$ 0
 PEB.LdrData: D$ 0
 PEB.ProcessParameters: D$ 0
 PEB.SubSystemData: D$ 0
 PEB.ProcessHeap: D$ 0
 PEB.FastPebLock: D$ 0
 PEB.FastPebLockRoutine: D$ 0
 PEB.FastPebUnlockRoutine: D$ 0
 PEB.EnvironmentUpdateCount: D$ 0
 PEB.KernelCallbackTable: D$ 0
 PEB.EventLogSection: D$ 0
 PEB.EventLog: D$ 0
 PEB.FreeList: D$ 0
 PEB.TlsExpansionCounter: D$ 0
 PEB.TlsBitmap: D$ 0
 PEB.TlsBitmapBits: D$ 0 #2
 PEB.ReadOnlySharedMemoryBase: D$ 0
 PEB.ReadOnlySharedMemoryHeap: D$ 0
 PEB.ReadOnlyStaticServerData: D$ 0
 PEB.AnsiCodePageData: D$ 0
 PEB.OemCodePageData: D$ 0
 PEB.UnicodeCaseTableData: D$ 0
 PEB.NumberOfProcessors: D$ 0
 PEB.NtGlobalFlag: D$ 0
 PEB.Spare2: B$ 0 #4
 PEB.CriticalSectionTimeout: Q$ 0
 PEB.HeapSegmentReserve: D$ 0
 PEB.HeapSegmentCommit: D$ 0
 PEB.HeapDeCommitTotalFreeThreshold: D$ 0
 PEB.HeapDeCommitFreeBlockThreshold: D$ 0
 PEB.NumberOfHeaps: D$ 0
 PEB.MaximumNumberOfHeaps: D$ 0
 PEB.ProcessHeaps: D$ 0
 PEB.GdiSharedHandleTable: D$ 0
 PEB.ProcessStarterHelper: D$ 0
 PEB.GdiDCAttributeList: D$ 0
 PEB.LoaderLock: D$ 0
 PEB.OSMajorVersion: D$ 0
 PEB.OSMinorVersion: D$ 0
 PEB.OSBuildNumber: W$ 0
 PEB.OSCSDVersion: W$ 0
 PEB.OSPlatformId: D$ 0
 PEB.ImageSubSystem: D$ 0
 PEB.ImageSubSystemMajorVersion: D$ 0
 PEB.ImageSubSystemMinorVersion: D$ 0
 PEB.ImageProcessAffinityMask: D$ 0
 PEB.GdiDBuffer: D$ 0 #34
 PEB.PostProcessInitRoutine: D$ 0
 PEB.TlsExpansionBitmap: D$ 0
 PEB.TlsExpansionBitmapBits: D$ 0 #32
 PEB.SessionId: D$ 0
 PEB.AppCompatFlags: Q$ 0
 PEB.AppCompatFlagsUser: Q$ 0
 PEB.pShimData: D$ 0
 PEB.AppCompatInfo: D$ 0
 PEB.CSDVersion.UnicodeStr64.Length: W$ 0
 PEB.CSDVersion.UnicodeStr64MaximumLength: W$ 0
 PEB.CSDVersion.UnicodeStr64Buffer: D$ 0
 PEB.ActivationContextData: D$ 0
 PEB.ProcessAssemblyStorageMap: D$ 0
 PEB.SystemDefaultActivationContextData: D$ 0
 PEB.SystemAssemblyStorageMap: D$ 0
 PEB.MinimumStackCommit: D$ 0
 PEB.FlsCallback: D$ 0
 PEB.FlsListHead.Flink: D$ 0
 PEB.FlsListHead.Blink: D$ 0
 PEB.FlsBitmap: D$ 0
 PEB.FlsBitmapBits: D$ 0 #4
 PEB.FlsHighIndex: D$ 0
 PEB.WerRegistrationData: D$ 0
 PEB.WerShipAssertPtr: D$ 0
 PEB.pContextData: D$ 0
 PEB.pImageHeaderHash: D$ 0
 PEB.TracingFlags: D$ 0
 PEB.Padding4: D$ 0
 PEB.CsrServerReadOnlySharedMemoryBase: Q$ 0
 PEB.TppWorkerpListLock: D$ 0
 PEB.TppWorkerpList.Flink: D$ 0
 PEB.TppWorkerpList.Blink: D$ 0
 PEB.WaitOnAddressHashTable: D$ 0 #128]

78
The Campus / Re: Color Buttons
« Last post by guga on November 07, 2019, 10:49:10 AM »
Oki, guys...

I´m still struggling to understand why it is leaking. I´ll have to do it on the way Steve said, but still it is leaking somewhere.

In the meanwhile i made a routine onto RosAsm debugger to make easier to see those issues and alsso find the exact routine responsible for the leaking or the creation of the object (in RosAsm it should be easier to retrieve the correct label and address of the loaded object, but i didn´t implemented it yet).



It works the same as in GDiView (for 64 Bits, currently . Later i´ll adapt it to make it works on Win32 OS as well. Here i have AMD 64 Bits, so i cannot tests it on my old OS :( )...But...i have a small question concerning this GDIView and the way it get´s the type of objects

I grabbed all the necessary data to see the GDI objects through PE64, reaching the values on NtWow64QueryInformationProcess64 Api inside NTDLL (after adapted RosAsm debugger to work on it). Once i retrieved the PROCESS_BASIC_INFORMATION data, i then passed it through ReadProcessMemory using PEB64 as the parameter of lpBaseAddress member of this Api.

So far, so good. It read the GDITable of PEB64 at PEB64.GdiSharedHandleTable (I updated PEB structure for RosAsm, btw) and i succeeded to get the GDICELL Structure which is formed as:
Code: [Select]
[GDICELL_WOW64:
 GDICELL_WOW64.pKernelAddress: Q$ 0
 GDICELL_WOW64.wProcessId: W$ 0
 GDICELL_WOW64.wCount: W$ 0
 GDICELL_WOW64.wUpper: W$ 0
 GDICELL_WOW64.wType: W$ 0
 GDICELL_WOW64.pUserAddress: Q$ 0]

And the displacement (equates) of the above structure, is:
Code: [Select]
[GDICELL_WOW64.pKernelAddressDis 0
 GDICELL_WOW64.wProcessIdDis 8
 GDICELL_WOW64.wCountDis 10
 GDICELL_WOW64.wUpperDis 12
 GDICELL_WOW64.wTypeDis 14
 GDICELL_WOW64.pUserAddressDis 16]

[Size_Of_GDICELL_WOW64 24]

To retrieve the handle of the GDI Object and the Type of object all is needed is:

Code: [Select]
            movzx eax W$esi+GDICELL_WOW64.wUpperDis | shl eax 16 | add eax D@iCounter | mov D@GDIHandle eax
            movzx eax W$esi+GDICELL_WOW64.wTypeDis | and eax 07F | mov D@GDIType eax

So, once i succeeded to get the Type, i then created more then 30 different types of GDI Objects to be analyzed, since Brushes, Bitmaps, Fonts (Logical or smaller fonbts etc etc), Colorspaces, directdraw, enhanced metafile, region, clip object, palette, etc etc etc

The problem is.....

On GDIView it displays sometimes extended information of certain types of Objects. For example, when analyzing some Bitmaps it sometimes display it like: "Width: %d, Height: %d, Bits/Pixel: %d"...BUT...it don´t collect the data of all objects that do exists...why is that ???? I mean, once GDIView (and mine) knows that there is a Bitmap object, why it collects info of some of them and other cases it fails miserably ?

I mean, to retrieve the "extended" information GDIView (and mine version) passes the GDiHandle to GetObject Api. So, Once we know the type of object i wrote a function like this:

Code: [Select]

[Size_Of_BITMAP 24]

Proc GDIViewGetBitMapInfo:
    Arguments @GDIHandle, @pOutput
;    Local @NewDC, @NewObject <--- Tried also to create a new DC and select the object trough it, but....nothing happened. Still returning 0
    Structure @BITMAP 24, @BITMAP.bmTypeDis 0, @BITMAP.bmWidthDis 4, @BITMAP.bmHeightDis 8, @BITMAP.bmWidthBytesDis 12, @BITMAP.bmPlanesDis 16, @BITMAP.bmBitsPixelDis 18, @BITMAP.bmBitsDis 20
    Uses edi, ecx, edx

    call 'RosMem.ZeroMemory' D@BITMAP, Size_Of_BITMAP

    call 'GDI32.GetObjectA' D@GDIHandle, Size_Of_BITMAP, D@BITMAP
    On eax = 0, ExitP

    mov edi D@pOutput
    movzx eax W@BITMAP.bmBitsPixelDis
    movzx ecx W@BITMAP.bmPlanesDis
    imul eax ecx
    If eax = 1
        mov eax 1
    Else_If eax <= 4
        mov eax 4
    Else_If eax <= 8
        mov eax 8
    Else_If eax <= 16
        mov eax 16
    Else_If eax <= 24
        mov eax 24
    Else
        mov eax 32
    End_If
    C_call FormatStr edi, {'Width: %d, Height: %d, Bits/Pixel: %d, Format: %d bits', 0}, D@BITMAP.bmWidthDis, D@BITMAP.bmHeightDis, D@BITMAP.bmBitsPixelDis, eax
    add edi eax
    mov B$edi 0

EndP

The main problem is that GetObject constantly returns 0 . In mine version and also in GDIView one. But..why it is returning 0, if we retrieved the GDI Handle of the object ????

Also....is there another way to collect the "extra' info of certain objects directly through one of the PEB structures, rather then using GetObject Api ???


Another question...What is this pUserAddress in GDICELL all about ? It does not seems the same address as it was stored the object inside the App. Someone knows what exactly is this member of the GDICELL structure ?

Note: Later i´ll implement the counter of objects to try seeking for leaking as it have in GDIview, but, i´ll try to see if i can collect the extra info 1st.




Reference of updated PEB/TEB structures in:
http://terminus.rewolf.pl/terminus

Also, more references i used are:

https://codeday.me/es/qa/20190409/458369.html
http://www.siddim.com/archives/7296.html
https://docs.microsoft.com/en-us/previous-versions/bb985767(v=msdn.10)?redirectedfrom=MSDN
http://www.verysource.com/code/5942649_1/PogyGDI.cpp.html
https://docs.microsoft.com/en-us/previous-versions/bb985767(v=msdn.10)?redirectedfrom=MSDN
https://reactos.org/wiki/Techwiki:Win32k/gdiobjects
extended info: https://reactos.org/wiki/Techwiki:Win32k/gdiobjects
https://www.yumpu.com/en/document/read/58026165/lpe-vulnerabilities-exploitation-on-windows-10-anniversary-update/3
https://chromium.googlesource.com/external/github.com/giampaolo/psutil/+/master/psutil/arch/windows/process_info.c
https://wj32.org/processhacker/forums/viewtopic.php?t=181
https://gist.github.com/hasherezade/87158b926e33418f5d3b0a0026d0ccc2
https://chromium.googlesource.com/external/github.com/giampaolo/psutil/+/master/psutil/arch/windows/process_info.c
https://github.com/w4kfu/whook/blob/master/src/include/pestuff.h <-----
from reactOS https://doxygen.reactos.org/df/ddf/ntgdihdl_8h_source.html
https://github.com/sam-b/windows_kernel_address_leaks <----- (GdiSharedHandleTable)
http://bytepointer.com/resources/tebpeb64.htm
http://terminus.rewolf.pl/terminus/structures/ntdll/_PEB_x64.html
https://github.com/securesean/Shim-Process-Scanner/tree/master/Shim-Process-Scanner
http://blog.rewolf.pl/blog/?p=1438#more-1438
https://labs.f-secure.com/archive/a-tale-of-bitmaps/
https://aloiskraus.wordpress.com/2016/06/25/show-gdi-handles-by-type-in-windbg/
https://stackoverflow.com/questions/13905661/how-to-get-list-of-gdi-handles
79
The Soap Box / Re: New 12 volt power supply.
« Last post by hutch-- on November 07, 2019, 10:35:44 AM »
The stuff from China is a funny mix, I just received 5 x 12 - 24 volt 10 amp speed controllers at $5.00 each and on test, they are far quieter than the $35.00 one I bought locally. Has a decent heat sink clamped on 2 flat pack items that I can't identify and a knob that has an off position and variation up to full power. The 5 amp switch mode power supplies appear to deliver 5 amps but cut out with startup transient spikes where a transformer/recitifier/capacitor will routinely handle massive transient spikes.

I used to build audio power supplies and for big power amps I was using 300 - 500VA torroids with split 50+0+50 volt and similar and you used big rectifiers and usually 2 x 10000 mf capacitors and they performed really well, massive reserve and very quiet. I used to test power supplies on an oscilloscope and these were very good. At one stage I built a number of replacement amplifiers for musicians and the first thing you did was test the original amplifier with a square wave on an oscilloscope and you would have died laughing at how bad they were, usually a single sided supply with one 3055 to3 can transistor and some rediculous amount of cabling complete with earth loops.

Removed them with a pair of side cutters and replaced them with a 100 watt RMS amp that was dead flat up to the 113 watt output then they would clip the tops off wave profiles. Many musicians were tuned to these old crapheaps and used to turn the volume up until they heard the clipping.
80
ASMC Development / Re: @CStr producing syntax error
« Last post by nidud on November 07, 2019, 09:04:32 AM »
The invoke directive (the foo(...) version) has a more sophisticated string handling than the @CStr() macro so it's not needed here:

    MessageBox(0, "test", "test", MB_OK)

It does work but it is case sensitive here (hence the error) and return a byte/word label.

    MessageBox(0, &@CStr("test"), &@CStr("test"), MB_OK)

    * .data
    * DS0000 sbyte "test",0
    * .code
    * MessageBoxA(0, &DS0000, &DS0000, MB_OK)
    * invoke MessageBoxA, 0, addr DS0000, addr DS0000, MB_OK
    *    push MB_OK
    *    push offset DS0000
    *    push offset DS0000
    *    push 0
    *    call MessageBoxA
Pages: 1 ... 6 7 [8] 9 10