c++
v67 = "lKuj3Ier";
if (strcmp(key, "lKuj3Ier"))
goto LABEL_118;
memset(&v101, 0, sizeof(v101));
v68 = strlen(value);
if (v68 >= 0xFFFFFFFFFFFFFFF0LL)
goto LABEL_162;
v69 = (std::string*)v68;
if (v68 >= 0x17)
{
v71 = (v68 + 16) & 0xFFFFFFFFFFFFFFF0LL;
v70 = (std::string*)operator new(v71);
v101.begin = v70;
v101.container = (std::string*)(v71 | 1);
v101.end = v69;
}
else
{
LOBYTE(v101.container) = 2 * v68;
v70 = (std::string*)((char*)&v101.container + 1);
if (!v68)
goto LABEL_115;
}
v67 = value;
memcpy(v70, value, (size_t)v69);
LABEL_115:
*((_BYTE*)&v69->len + (_QWORD)v70) = 0;
if (((__int64)v101.container & 1) == 0)
{
if (!((unsigned __int64)LOBYTE(v101.container) >> 1))
goto LABEL_118;
goto LABEL_117;
}
end = v101.end;
operator delete(v101.begin);
if (end)
{
LABEL_117:
v72 = CommonUtils::StrToInt((CommonUtils*)value, v67);
info->setColosseumTicket(v7, v72);
}
->
else if (!strcmp(key, USERTEAMINFO_COLOSSEUMTICKET))
{
info->setColosseumTicket(CommonUtils::StrToInt(value));
}
La pizzeria di Christian
c++ v67 = "lKuj3Ier"; if (strcmp(key, "lKuj3Ier")) goto LABEL_118; memset(&v101, 0, sizeof(v101)); v68 = strlen(value); if (v68 >= 0xFFFFFFFFFFFFFFF0LL) goto LABEL_162; v69 = (std::string*)v68; if (v68 >= 0x17)…
Questo messaggio che fa vedere il primo blocco preseudocodice e il secondo blocco codice convertito dice molto sulla nostra società e sui nostri compiler
arves ma com u cazzo leggi ste robe zio pera leggiamo un po' di decompilato assieme ok?
queste prime righe sono cacate varie, come si può vedere da v97.len, v97.capacity qui stiamo facendo questa istruzione
Tutto queste garbage è un allocazione di std::string, il value lo sappiamo perchè v74 = strlen(value)
si traduce in questo:
std::string q = value;
Solitamente si nota perchè è un behavour, ma possiamo trovare v97 (la nostra stringa) anche come un array di __int128 (su 64-bit è 0x18 la grandezza)
Tutto queste garbage è un allocazione di std::string, il value lo sappiamo perchè v74 = strlen(value)
si traduce in questo:
std::string q = value;
Solitamente si nota perchè è un behavour, ma possiamo trovare v97 (la nostra stringa) anche come un array di __int128 (su 64-bit è 0x18 la grandezza)
allora
CommonUtils::parseList
come precedemente investigato sappiamo è uguale a
quindi sappiamo che sta sucedendo questo:
v101 = CommonUtils::parseList(v97, v96);
v97 è "value" la std::string di prima, mentre v96 ha un assegnazione 11266 al len LOWORD in che senso??
v101 sarà perforza std::vector perchè molto spesso __cdecl/il decompilto ci mette gli argomenti di ritorno all'interno della funzione
CommonUtils::parseList
come precedemente investigato sappiamo è uguale a
static std::vector<std::string> parseList(const std::string& list, const std::string& delim);quindi sappiamo che sta sucedendo questo:
v101 = CommonUtils::parseList(v97, v96);
v97 è "value" la std::string di prima, mentre v96 ha un assegnazione 11266 al len LOWORD in che senso??
v101 sarà perforza std::vector perchè molto spesso __cdecl/il decompilto ci mette gli argomenti di ritorno all'interno della funzione
sappiamo che tutto quel colabrodo di BYTE2 e LOWORD è uguale a
std::string v96 = ",";
ma perchè c'è ',\x02'?
perchè la mia struttura std::string è decompilata male (mi interessava della grandezza alla fine) e ho invertito dei membri, in realtà quel \x02 è la lunghezza della stringa (da notare l'extra 1 perchè c'è il null terminator)
std::string v96 = ",";
ma perchè c'è ',\x02'?
perchè la mia struttura std::string è decompilata male (mi interessava della grandezza alla fine) e ho invertito dei membri, in realtà quel \x02 è la lunghezza della stringa (da notare l'extra 1 perchè c'è il null terminator)
qui abbiamo un paio di delete, quindi stiamo chiamando
std::string::~string();
il decostruttore
v101.container sicuramente sinigifica l'inizio del dati quindi v101.begin() (anche qui la struttura v101 non è perfetta)
queste righe le traduciamo con
info->setReinforcementDeckNum(CommonUtils::StrToInt(v101[0]));
std::string::~string();
il decostruttore
v101.container sicuramente sinigifica l'inizio del dati quindi v101.begin() (anche qui la struttura v101 non è perfetta)
queste righe le traduciamo con
info->setReinforcementDeckNum(CommonUtils::StrToInt(v101[0]));
molto divertente il fatto che non ci siano checks per la grandezza di v101
che ci sono dopo però volgiamo l'attenzione a questa riga
end - container è una sottrazione di puntatori AAAAAAAABLL e >>3 schifta per la grandezza bla bla ottimizzazioni del compilatori
in realtà questa riga sarebbe uguale a
v101.size() >= 2
if (0xAAAAAAAAAAAAAAABLL * (((char*)v101.end - (char*)v101.container) >> 3) >= 2)end - container è una sottrazione di puntatori AAAAAAAABLL e >>3 schifta per la grandezza bla bla ottimizzazioni del compilatori
in realtà questa riga sarebbe uguale a
v101.size() >= 2
tutto questo schifo è riassumibile cosi:
c++
auto v = CommonUtils::parseList(value, ",");
info->setReinforcementDeckNum(CommonUtils::StrToInt(v[0]));
if (v.size() > 2)
{
info->setReinforcementDeckEx1Num(CommonUtils::StrToInt(v[1]));
info->setReinforcementDeckEx2Num(CommonUtils::StrToInt(v[2]));
}
spero non vi sia piaciuta questa lezione di lettura di pseudo-codice non richiesta
👍2
a volte si diffonde anche delle informazioni tra la merda...
https://github.com/RibShark/SafeDiscShim HEY BABE NEW DRIVER DROPPED
GitHub
GitHub - RibShark/SafeDiscShim: SafeDiscShim is a compatibility tool that allows for SafeDisc protected games which utilize the…
SafeDiscShim is a compatibility tool that allows for SafeDisc protected games which utilize the insecure Macrovision Security Driver ("secdrv.sys") to run on modern versions of Wi...
❤1