De "java codes" zitten niet in de app en kan je er ook niet meer uit krijgen. Android apps zijn in principe in .dex-formaat met bytecode (smali volgens mij, het is voor mij ook weer een paar jaar geleden dat ik hiermee bezig was). Die kan je wel behoorlijk goed omzetten naar java-bytecode, en van daaruit is het gokwerk. Zo te zien is dat wat je nu hebt, .class-files zijn bytecode, niet source. Er zijn programma's waarmee je dat kan "omzetten naar source code" maar dat is eigenlijk schromelijk overdreven. Bij het compilen wordt eigenlijk standaard optimalisatie toegepast, waardoor de source code op bepaalde manieren verandert wordt zodat nog steeds hetzelfde gebeurt, maar de VM het op een voor de VM logischere manier kan uitvoeren. Daarbij gaat ook heel veel informatie van de code-structuur verloren. Het enige wat zulke apps doen is aan de hand van de bytecode gokken wat de source geweest zou kunnen zijn, en dan lukt maar bij een zeer beperkte subset van de code, en vaak komen er stukken code uit die onmogelijk kunnen werken (gewoon fout zijn dus), o.a. vanwege de optimalisatie. Je moet op veel plekken nog bytecode (een soort assembly) lezen en begrijpen om er chocola van te kunnen maken, en dat is ontzettend tijdrovend. Als je het vaker hebt gedaan kan je wel makkelijker in de juiste richting zoeken. Omdat dit nog relatief "makkelijk" is voor een geoefend persoon, gebruiken ze vaak nog obfuscators. Als ze een goede obfuscator hebben gebruikt is het ook vrijwel onmogelijk om dat te reversen, je zal ook veel werk zelf/handmatig moeten doen zoals strings decrypten/decoden, wat het zoeken op URLs enorm veel meer moeite maakt.
Anyway, je zou eens kunnen kijken naar jd-gui, een java "decompiler". Die probeert er dus java-source van te maken en laat je anders in ieder geval annotated bytecode (human-readable dus) zien. Dat is al wat leesbaarder dan de .class-files.
Soms is een andere aanpak ook makkelijker. Heb je bijvoorbeeld al geprobeerd om het wifi-verkeer te sniffen met een geschikte wifi-adapter, of over een kabel tussen twee AP's bijvoorbeeld? Als het niet versleuteld is kan je daar direct mee uit de voeten.
cowandchicken schreef op vrijdag 1 november 2019 @ 09:39:
als ze het zo simpel gemaakt zouden hebben zou dat wel erg kwetsbaar zijn. Ik zie in je code classes als cipher, challenge en authentication.
Als ze al gebruik maken van een rest API dan zal deze authenticatie verwachten ben ik bang.
Ik ben verder niet thuis in java en betwijfel of decompiled code nog even leesbaar is als het zou moeten zijn
Je hebt wel de hele source, waarmee het mogelijk is om te verbinden naar die service. Dat betekent dus dat je het zelf na kan maken. Die classes die jij noemt zijn niet zo heel spannend en zijn in vrijwel elke app wel aanwezig, de gebruikte libraries worden namelijk voor een behoorlijk deel meegepackaged met de app. Ik ken de details verder niet helemaal, ik heb namelijk nog nooit een android-app gemaakt, ik heb ze alleen maar deels gereversed
maar dat is wat ik heb gezien.
Voor een wifi-ventilator kan je je ook afvragen hoe belangrijk de "veiligheid" is en ingeschat is door de maker van de app. Het zou zomaar kunnen dat die classes die je noemt alleen maar gebruikt worden voor contact met een webservice, of om ads in te laden ofzo, en helemaal niet voor de fan zelf.
[
Voor 10% gewijzigd door
DataGhost op 01-11-2019 10:05
]
:strip_icc():strip_exif()/u/893633/crop5a27cbe193428_cropped.jpeg?f=community)
:strip_icc():strip_exif()/u/1117723/crop5e3d03b4214c0_cropped.jpeg?f=community)
:strip_icc():strip_exif()/u/91018/dgtw.jpg?f=community)
/u/13460/JUN982.GIF?f=community)
/u/34186/crop62e07d174532d_cropped.png?f=community)
:strip_icc():strip_exif()/u/146731/crop562615a0aa64c.jpeg?f=community)