https://stackoverflow.com/questions/53733781/how-do-i-use-lldb-to-debug-c-code-on-android-on-command-line l'ultima risposta è gold

ma perchè è cosi schifosamente difficile debuggare una cazzo di app
cioè io non capisco su windows apri x32dbg e via su android devi fare ???????? cose non puoi mando avviare lldb-server a manina perchè eeh selinux eeh root
che due coglioni

x64dbg cmq fa cagare al cazzo ogni due per tre si bugga, non è resiliente come olly

che due coglioni però

ERA ORA

mi sa che ho sbagliato qualcosa.,.,,,.,.

porca troia...

si però ghidra è fr inutilizzabile su una app aarch64

è stupido in culo

ok avrà sfanculato probabilmente l'auto nalisi perchè non mi rileva una calling conv corretta, vabbe pace

che crasha il decompilatore per decompilare mi è nuovo bah

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));
    }

fa ridere ma fa anche riflettere

Questo messaggio che fa vedere il primo blocco preseudocodice e il secondo blocco codice convertito dice molto sulla nostra società e sui nostri compiler

2 balls

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)

allora

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)

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]));