Skip to content
KitploitKITPLOIT
StrumentiExploitsBlog
Log in
Invia
StrumentiExploitsBlog
Invia

Strumenti di Hacking, PenTest e Cybersecurity per il tuo Arsenale di Sicurezza!

Kitploit è una directory di strumenti di hacking, cybersecurity e pentesting. Scopri gli ultimi aggiornamenti dei progetti per trovare vulnerabilità, analizzare sistemi, automatizzare i test e rafforzare la tua sicurezza.

··Feed·Contatto·Privacy·© 2026 Kitploit

Directory degli strumenti

Categorie

Vedi tutte le categorie
Loading categories
cabir_analysis — Analisi parziale di cabin | Kitploit
Strumenti/GitHubGitHub/spiralbl0ck/cabir_analysis
Sicurezza Sistemi EmbeddedAnalisi StaticaSicurezza BluetoothReverse EngineeringAnalisi MalwareSicurezza MobileAnalisi di BinariApprendimento e FormazioneLab e Pratica
GitHubspiralbl0ck/cabir_analysis

cabir_analysis

Analisi parziale di cabin

11173 anni faNon ancora revisionato

Più Popolari

Vedi tutti →

Scopri gli strumenti più utilizzati dalla nostra community.

Esplora tutti gli strumenti

Sfoglia la nostra collezione di strumenti

Vedi tutti gli strumenti →
Condividi
Vedi Repository

description: Analisi di Bluetooth-Worm:SymbOS/Cabir

Analisi di Bluetooth-Worm:SymbOS/Cabir

Prima che inizi a leggere, devo fare questo annuncio: PER FAVORE PRENDI TUTTO QUELLO CHE LEGGI CON LE PINZE, PERCHÉ NON SONO AFFATTO UNO SVILUPPATORE SymbianOS né ho familiarità con l'ambiente SymbianOS

Ma perché analizzare qualcosa di così vecchio? Beh, perché è il modo più semplice per avvicinarsi all'hacking remoto, visto che al giorno d'oggi questo tipo di roba si fa con nday/0day che valgono 1 milione 🤑🤑🤑. E perché non ho ancora le competenze per fare quel tipo di cose.

Ok, ora che abbiamo tolto di mezzo questa roba, andiamo al sodo. WTF è Cabir? È un worm Bluetooth che gira sui telefoni Symbian. Per quelli che si chiedono che cavolo è un telefono Symbian e tutta quella roba. Beh, fondamentalmente è un telefono che gira su ARM, quindi niente di nuovo sotto il sole :) Info più concise (https://en.wikipedia.org/wiki/S60_(software_platform))

Ora siamo stati abbastanza fortunati che il codice sorgente di questo fosse online (per gentile concessione di vxug) (SymbianOS.Cabir.7z). Ora lo useremo come riferimento ma, onestamente, fanculo. Uno degli altri motivi per cui lo faccio è perché voglio dilettarmi con ARM. Quindi vedremo tutto da una prospettiva source/assembly/emulatore/debugging/sniffing.

Ok, quindi #1 Come cazzo si compila il codice sorgente?

Beh, non è poi così complicato...

Prima installa carbide ++(http://www.mediafire.com/file/6z54qrceef73x9s/Carbide_cpp_v2_7_en.exe/file)(da https://gist.github.com/artem78/cb2b9650af186844f7b5654964676284)

poi installa un qualsiasi motore Perl

poi installa nokia pc suite(https://www.usitility.com/nokia-pc-suite/)

installa SDK(http://www.mediafire.com/file/9uc7fjb2ynmxlud/s60v3.1_SDK.zip/file )

installa il plugin c/c++ (https://ia800905.us.archive.org/7/items/nokia_sdks_n_dev_tools/s60_open_c_cpp_plug_in_v1_7_en.zip)

E voilà, abbiamo l'ambiente :)

Ps meglio usare Windows 7 perché a quanto pare su Windows 10 le cose si rompono e non funzionano correttamente

Infezione dell'ambiente live

TBD

Per questa parte sappi che devi fare il jailbreak (sì, hai sentito bene, jailbreak) del tuo telefono. Come si fa?

Analisi di reverse engineering

Ok, quindi come cazzo si compila questa roba? Bella domanda. Quello che ho fatto è stato avviare prima ABLT.BAT dalla cartella caribe\group, in questo modo

Ok, il passo successivo è andare dove è installato il nostro SDK, identificare la cartella della piattaforma (S60_3rd_fp1) nel mio caso, trovare la cartella epoc32, andare alla cartella build, scegliere la cartella user, la cartella con il nome utente e poi altre due o tre directory, e dovresti ritrovarti in una cartella che assomiglia a questa

Questo è il percorso attuale, che dovrebbe essere più o meno simile a quello in cui dovresti trovarti (C:\Symbian\9.2\S60_3rd_FP1\Epoc32\BUILD\Users\pwn\Desktop\CabirSourceCodes\caribe\group)

Ok, poi dobbiamo entrare nella cartella caribe (o comunque hai chiamato il codice sorgente) e troverai una cartella con nomi diversi, come si vede qui

A cosa serve? Beh, fondamentalmente la prima volta che eseguiamo ablt.bat (ancora oggi non so a cosa serva, ma vabbè) otteniamo diverse opzioni di piattaforma per compilare il nostro file pkg, da cui genereremo il nostro file sis. Nel caso specifico vediamo GCCE e WINSCW. Se esegui di default il comando ablt.bat build, compilerà per WINSCW (che è il nome in codice della piattaforma dell'emulatore). Ai fini di imparare a compilare il codice sorgente, per ora useremo GCCE, ma il processo è lo stesso se scegli di farlo per, non so, la piattaforma ARM, così puoi caricarlo sul telefono. Quindi in pratica ablt build arm_whatever e poi fai gli stessi identici passaggi fino a qui. Ok, ora andiamo nella cartella GCCE

vai nella cartella urel e dovrebbe esserci un file chiamato caribe.app. Da lì vuoi aprire una riga di comando ed eseguire

Quindi cosa fa questo? Beh, fondamentalmente abbiamo eseguito makesis, che genera un file sis così possiamo installarlo sul telefono, e perché siamo in un file sis dal codice sorgente di caribe? Beh, fondamentalmente dovevamo specificare caribe.pkg a makesis. Ok, allora perché tutto quel casino per arrivare alla cartella build blah blah? Beh, perché devi specificarlo nel parametro -d così può generare il file .sis

Ok, questo metodo funziona solo su SDK v3, come indicato in questo write-up. A quanto pare, mentre stavo sperimentando, ho incontrato uno sviluppatore da un server Discord dedicato a Symbian che ha sottolineato che Cabir è codificato per SDK v2, e quindi quello che ho presentato qui sarà inutile..... è TBD quando riuscirò a contattarlo... visto che in questi giorni è abbastanza offline su Discord...

Ok, quindi come si fa il reverse engineering di un file .sis?

SEMPLICEMENTE: un file .sis è un archivio. Quindi... usiamo l'applicazione siscontents per decomprimerlo e poi buttiamo il file .app in IDA.

Prospettiva assembly

Quindi l'intero processo è così

Ora entriamo in quella cartella e subito dopo otteniamo il file app.app

Ok, se lo butti in IDA.

Ok, quindi fondamentalmente un exe ARM. CHE FIGATA PAZZESCA! IL PROSSIMO, PER FAVORE! HMM SÌ, PER FAVORE ~~~

CI SONO simboli nel file, sì!!! beh, sì, visto che per qualche strana ragione abbiamo compilato il binario con i simboli di debug, siamo stati fortunati!

E quindi, visto che abbiamo praticamente il codice e via dicendo, il processo di reverse engineering è più o meno lo stesso di quello descritto nel capitolo sull'analisi del codice sorgente :)

Prospettiva sniffing

Scarica lo strumento