위 형식에 맞춰서 작성하면 된다.
3번 Root Cause에 대해 5회차에 했던 것을 작성해보면,
The vulnerability stems from improper integer type handling in the image row processing loop. The code uses a 16-bit signed integer (__int16 v14) as a row index that gets initialized based on image processing direction
sub_1(...) {
__int16 v13; // init idx
__int16 v14; // idx
__int16 v25;
unsigned __int16 v26; // loop counter
unsigned __int16 v30; // image height
...
if ( (v38 & 0x20) == 32 || (v38 & 0x10) == 16 )
{
...
}
else
{
v13 = v30 - 1; // v13 could be assigned negative value
v25 = -1;
}
v14 = v13;
v26 = 0;
...
do
{
sub_2(&savedregs);
sub_3(&savedregs);
v16 = (**(int (***)(void))v31)(); // v14 passed as int parameter
sub_4(v33, v16); // memory access
++v26;
v14 += v25;
}
while ( v26 < v30 && **(_BYTE **)(a7 + 40) != 1 );
...
}
The critical flaw occurs when v30 (image height) is a large unsigned 16-bit value (e.g., 0xFD4F=64847). In the reverse processing path, the calculation v30 - 1 produces a value
that exceeds the maximum positive range of a signed 16-bit integer (32767). This causes integer overflow, resulting in v14 being assigned a large negative value due to wraparound.
During the processing loop, v14 is implicitly promoted to a 32-bit signed integer when passed as a parameter to (**(int (***)(void))v31)() . Due to sign extension, the negative 16-bit value becomes a large negative 32-bit integer, which when used in subsequent pointer arithmetic calculations, wraps around to a large positive offset, causing out-of-bounds memory access beyond the allocated image buffer boundaries.
와 같이 했다.