Self-Checks making AIMSICD tamperproof about android-imsi-catcher-detector HOT 12 CLOSED

Hi, you think too complicated. You just need to host your apk here on Github (or another trusted host) where the files are served securely over HTTPS. You can also write here the checksums if someone downloads the apk from an insecure source and wants to verify if the file is legit. Of course the checksums should also be hosted on a secure site (just add them here to README or somewhere), otherwise the attacker could replace the checksums with checksums of tampered apk when they are transmitted. Everything else is not needed. You can't let an app to "self-verify" itself. If someone can tamper the apk he can also tamper the checkroutine.

from android-imsi-catcher-detector.

@andr3jx, thanks for your input on my idea. I will add SHA-1 Checksums to every previous as well as upcoming WIP-Release TODAY. Nevertheless, I would like to hear the opinion of @xLaMbChOpSx and @E3V3A to ensure we really cannot accomplish some sort of self-check for AIMSICD.

from android-imsi-catcher-detector.

@SecUpwN I think SHA-1 is good enough for now, I don't see a reason to get overly paranoid about this, at this time. It only distracts @xLaMbChOpSx from getting more important things done.

from android-imsi-catcher-detector.

@E3V3A, do you think we should include self-checks at a later stage or shall we close this for good?

from android-imsi-catcher-detector.

@SecUpwN It's a great idea, but with low priority. I primarily need a working AT injector to be of any further assistance in this project.

from android-imsi-catcher-detector.

@E3V3A, leave this open, please. Hope @xLaMbChOpSx tells us how we can help to make the AT Command Injector work (on the plate for version 0.1.20-alpha as you know). Looking forward to help.

from android-imsi-catcher-detector.

@SecUpwN @E3V3A Sorry I can't provide a quick answer to the AT Command injection it is unfortunately something that although simple in principle is not so easily achieved within our application, I have spent a significant amount of time attempting to extend upon the MultiRil work we are using for the Samsung Service Mode OEM_RAW requests and have had varying degrees of success but still not been able to receive any form of response.

Even if I do successfully implement this it will unfortunately be specific to Samsung devices, I would love to be able to spend time on trying to get some form of root terminal responses instead of the MultiRil method but really don't even know where to start I can go back over the xda threads about this and devote my time to trying to receive a response through the terminal on the device.

I am totally committed to doing whatever it takes to try and achieve the goals of this project but my experience is mainly in Windows application development and enterprise database management so unfortunately I am very much out of my depth when it comes to low level radio manipulations (Android/Java also to some degree) although I am steadily increasing my knowledge, I hope you can understand that the failure to have this up and running is in no way a reflection of my commitment and willingness to contribute to this.

Let me know what you think would be the best way forward and I will focus on that.

from android-imsi-catcher-detector.

@xLaMbChOpSx, thank you for your summary on the current situation. I fully agree with your statements and I also think that you shouldn't spend more time to extend on the MultiRil work for the Samsung Service Mode OEM_RAW requests, rather we should all now search for Experts on low level radio manipulations to get root terminal responses universal for all Android devices. I'll be heading to the threads and try to recruit people. Please don't give up, I'm sure we'll find a way!

from android-imsi-catcher-detector.

@xLaMbChOpSx Hi! Thanks for update. I truly appreciate you reaffirming your commitment.
See my new response in #23.

@SecUpwN That is a bad suggestion, at this time, as it seems that OEM_RAW stuff is the only way to have a somewhat device independent AT injector, whereas a root terminal response, is even more phone and /dev dependent, although being an easier choice to deal with, once located.

Also let's leave this thread for now. No need to close, but the discussion above is OT. GOTO #23.

from android-imsi-catcher-detector.

I've just noticed, that if we want to "try" to have our app tamper proof, we need to use one of the SHA hashes, like SHA512. This is how Cygwin does it. Apparently MD5 is broken as mentioned in this post, but still good to verify download integrity. (Who does that anyway?)

Currently (as of 2015-03-08) Cygwin uses MD5 cryptographic hashes. As long as MD5 is accepted then Cygwin is vulnerable to MITM, because MD5 is a totally broken algorithm. E.g., in 2012 the Flame malware exploited MD5 to fake a Microsoft digital signature.

from android-imsi-catcher-detector.

The best way to guarantee, that the APK hasn't been tempered is to compile it from source on open-source hardware with an fully open-source and self-compiled OS and toolchain, after auditing the code. I support the idea of publishing checksums - in addition to that the project maintainer could sign the releases with GPG, which is a stronger proof than checksums, since one might be able to verify the integrity of the file using one's web of trust. The disadvantages of that concept is the central point of failure - no one should trust anyone but himself.

Regarding the self-check functionality: such a function might be useful to verify, whether the device/chipset/baseband is supported.

from android-imsi-catcher-detector.

Thanks for chiming in, @scento. To clarify: This Issue was meant to make AIMSICD check itself against a hardcoded checksum which I initially thought could be generated for each release. Revisiting this Issue now makes me wonder if my thoughts are even helpful to secure our app.

About the checksums of the releases: We have been posting the MD5 checksum of each released APK from the very start of this project and tested the creation and usage of SHA-1 in between. We have not noticed people making any use of SHA-1 (thus I removed them again) or complaining that MD5 is broken (which I am well aware of). Posting the SHA512 makes less sense since the strings are not just very long (6d989d0630f93a6b026c04d32983aaa075f2a11f2d3bf7cc3418fe8971b1176834eabae0d8217f613af58e595a73a235da4daa2693553691c256a46d23594aad is one of them), but also because people might lack programs to quickly check if the checksum matches. Thus, it seems that MD5 should be perfectly good for our releases. Cuttiing it down: People shall either make sure that checksums match, or just compile from source - that is the real purpose of open source. Issue seems solved to me, feel free to re-open.

from android-imsi-catcher-detector.