Py injection exploit

[Woops 10]

What is the exploit?

In CPythonLauncher::RunMemoryTextFile a string is used to compile c_pcFileData, so the exploit starts here:
"exec(compile(" 
Hackers can easily search for the string in memory & compile scripts using the memory adress of c_pcFileData
This looks like an intentional backdoor left by one of the game devs or maybe even the leaker of the files "Rain"

Why?

It's hard to believe anyone would trouble to concatenate so many strings instead of just using Py_CompileString
If you pay attention the rest of the code is fine and uses the python api instead of some weird shells

Seems like there are still many exploits in m2
Hope you learned something new today, now here is the fix you paid for:

ScriptLib/PythonLauncher.cpp search for:

bool CPythonLauncher::RunMemoryTextFile(const char* c_szFileName, UINT uFileSize, const VOID* c_pvFileData)

replace with this:

bool CPythonLauncher::RunMemoryTextFile(const char* c_szFileName, UINT uFileSize, const VOID* c_pvFileData)
{
    const CHAR* c_pcFileData = (const CHAR*)c_pvFileData;
    std::string stConvFileData;
    stConvFileData.reserve(uFileSize);

    for (UINT i = 0; i < uFileSize; ++i)
    {
        if (c_pcFileData[i] != 13)
            stConvFileData += c_pcFileData[i];
    }

    const CHAR* c_pcConvFileData = stConvFileData.c_str();
    PyObject* pCompiledCode = Py_CompileString(c_pcConvFileData, c_szFileName, Py_file_input);//fix
    if (!pCompiledCode)
        return false;
    PyObject* pResult = PyEval_EvalCode((PyCodeObject*)pCompiledCode, m_poDic, m_poDic);
    Py_DECREF(pCompiledCode);//ref c
    if (!pResult)
        return false;

    Py_DECREF(pResult);
    if (Py_FlushLine())
        PyErr_Clear();

    return true;
}

 

[Woops 10]

bool CPythonLauncher::RunMemoryTextFile(const char* c_szFileName, UINT uFileSize, const VOID* c_pvFileData)
{
    const CHAR* c_pcFileData = (const CHAR*)c_pvFileData;
    std::string stConvFileData;
    stConvFileData.reserve(uFileSize);

    for (UINT i = 0; i < uFileSize; ++i)
    {
        if (c_pcFileData[i] != 13)
            stConvFileData += c_pcFileData[i];
    }

    const CHAR* c_pcConvFileData = stConvFileData.c_str();
    return RunLine(c_pcConvFileData); 
}

Here is the original fix that uses RunLine for the PyObject

[ValkeryE 123]

Can you tell me more about this exploit?

Edited September 30, 2024 by ValkeryE

[martysama0134 10748]

If you're using cython, you can directly remove that function. RunFile isn't used elsewhere except for calling system.py.

#ifdef __USE_CYTHON__
		if (!pyLauncher.RunLine("import rootlib\nrootlib.moduleImport('system')"))
#else
		if (!pyLauncher.RunFile("system.py"))
#endif

 

Just wrap the two functions like this:

  

 

 

 

 

18 hours ago, Woops said:

It's hard to believe

Why not?
They are using c string allocation instead of std::string in the function calling it. It's not that hard to understand they were as dumb as monkeys.

bool CPythonLauncher::RunFile(const char* c_szFileName) const
{
	char* acBufData= nullptr;
	DWORD dwBufSize=0;

	{
		CMappedFile file;
		const VOID* pvData;
		CEterPackManager::Instance().Get(file, c_szFileName, &pvData);

		dwBufSize=file.Size();
		if (dwBufSize==0)
			return false;

		acBufData=new char[dwBufSize];
		memcpy(acBufData, pvData, dwBufSize);
	}

	bool ret=false;

	ret=RunMemoryTextFile(c_szFileName, dwBufSize, acBufData);

	delete [] acBufData;

	return ret;
}

Re-written:

bool CPythonLauncher::RunFile(const char* c_szFileName) const
{
	std::string acBufData;

	{
		CMappedFile file;
		const VOID* pvData;
		CEterPackManager::Instance().Get(file, c_szFileName, &pvData);

		if (file.Size() == 0)
			return false;

		acBufData.resize(file.Size());
		memcpy(acBufData.data(), pvData, acBufData.size());
	}

	return RunMemoryTextFile(c_szFileName, acBufData.size(), acBufData.data());
}

 

Edited October 1, 2024 by Metin2 Dev International
Core X - External 2 Internal