Watch me go out of my comfort zone approaching strangers and interviewing them. The answers were very interesting and as a security consultant their point of view is important to me.
Where can I get started with Android Security? I was a flutter developer and I'm currently learning Jetpack Compose, but I want to see both sides of the coin (developing and hacking).
I can tell you something about security measures in banking apps I used. They have no problem with running on an old android version with known vulnerabilities. But they can detect rooted androids or even androids with unlocked bootloader and lock the user out. At the same time there is no problem with using their banking website.
@@alang.2054 If I rooted my phone, I know what I'm doing. No need to "protect" me by not allowing me to use the app(unless the app stores security info in plain text in app's private data)...
Hi @LiveOverflow. Love the vids. Just had one small comment. I noticed you put notes in your videos in different parts of the screen, including the bottom part. Since my native language is not english, some times I use subtitles to understand better. Unfortunately the subtitles cover your notes if they are at the bottom, so I'm left to either pause the video continuously, or watch without subtitles. if you could leave a little space for the subtitles at the bottom, or use other parts of the screen, it would help people that need subtitles. Thanks for the content!
Honestly, the mobile apps ecosystem has become quite a nightmare nowadays. It wasn't surprising to me that most devs consider reverse engineering their greatest enemy. But it is a problem and I just cannot complain about it enough. In Asia especially, it's not uncommon to see apps packed with commercial "protectors" that literally behave like advanced malware packers. Such things are just horrible to end users in terms of security. They are so ubiquitous that it's not ideal to ban them on the app store, while no effective method is available to determine whether an app packed with such a "protector" is benign or not. And I do feel the devs' frustration, too. You can not just blame users for being muggles who cannot distinguish the original app from all those cash-grabbing copycats. After all, they are just users, and users bare absolutely no responsibility to serve the devs. As for the copycats, there is no way to detect them, either. The whole situation is just awful, with no obvious solution in sight. Sigh...
The original concept of "protecting client side code" seems deprecated to me, most tech managers don't even understand why they are doing that anymore. While working for banks i often saw that, principles that used to be true but not true anymore due to more advanced algorithms practices that don't get updated. If you are not protecting your JS or wasm in web but you want to protect your android, ios client side code mostly interacting with your backend. Most well designed apps in React native or Flutter don't make critical storage or config mistakes anymore. So you are "protecting your code against what" attackers don't find client side bugs ?
I think those developers dont really know that much about security based on the interviews. They worry about reverse engeneering because of someone stealing their assets. Thats not really application security. Its more like business security in case any competitor gets a benefit. The backend is what gets hacked and where the data is leaked in most cases. Saying that a registration of a username called "root" is forbidden shows me that their backend is most likely not really that robust if it cannot handle that.
Yeah, although it might be defense in depth, it raises a red flag if someone wants to validate something like this in the frontend or even feels that much of a need to validate this at all ...
Yeah, if you are worried about reverse engineering to prevent others making a better app than your own.... maybe you should spend that reverse engineering prevention time into actually making the app good enough to where an alternative won't have many benefits compared to your own (thus making the alternatives less appealing
I really like this type of content! It's a pity that you got those camera issues but thank you for sharing that. The fact that you shared that and told us about it made you even more wholesome and relatable :) One thing that triggered me a bit was that you didn't resolve what movie played at day 2 but maybe you dont know about it either. All in all a great video with nice insights!:)
The anti-reversing protections, at least to me, seem to be very similar to web application firewalls and their bot JS challenges. Many people are discouraged by it, but somebody with motivation and resources will not be stopped by it.
Still gutted we didn't cross paths - thanks so much for all you have done to promote security! You were one of my many inspirations to speak and discuss mobilesec. Hope to thank you in person next year 😅
As someone working for one of the App Security companies at that conference (not shown in the video); it's not so much that these companies care so much about obfuscation, but many of our customers think obfuscation is the important part. I get what you mean when you call it snakeoil, and I agree to an extent, but it is usually just a smaller part of the bigger picture. Unfortunately many developers and especially regulators think obfuscation is very important.
Yes yes yes! Most of regular apps don't need anything like that but obfuscation and malicious environment detection is critical for finance apps and the game industry. I think people might get a wrong idea from this video
@@Zappexe Why would obfuscation be critical in a finance app? If you need to obfuscate the frontend of a finance app for it to be secure you are probably already in deep shit security-wise. The only apps that might profit from obfuscation are those that have a majority of their actual business logic on the client side. This should never be the case for finance apps.
@@aseidma3576Also, I don't understand why the App platforms aren't developing some kind of "trusted computing", offloading encryption and challenge response based tasks onto a dedicated chip like with WebAuthn for example? Also, isn't 2FA supposed to solve the problem of signing transactions even without such advanced techniques?
@@aseidma3576 The argument is that if the protocol can be reverse-engineered, then attackers can try to attack the backend directly. If you can steal credentials but you can't spoof requests then it's harder to scale up an attack. And if you're phishing, the more you can do to replicate the real behavior of the app, the more likely it is that you can trick users into thinking nothing is wrong. And if it's harder to analyze the behavior of the app, it's harder to use it for something like a confused deputy attack. Yes, of course it doesn't actually STOP anything. Backend security and fraud detection is way more important. But that doesn't mean front end security doesn't matter.
At one point I become so frustrated that "everything is app" in my smartphone that I just switched to web where I could and other junk just dumped and started using my laptop more. I hope that one day smartphones will stop being frontshop for corporates to sell their products and start being what they really are - computers in our pockets.
it's so frustrating how bad it is and how stupid people most people are to just let it happen. Phones in the last five years have regressed in usability while getting absolutely minimal / mediocre feature improvements. There's a reason apps force updating now.. if they didn't a good chunk of people wouldn't update, because updates degrade the product now. It's like we started out with houses, and naturally people wanted better houses. So someone came along and says hey we upgraded your house to this hotel room! The TV is 4" larger than the old one! And no you don't have a choice, either you move into the hotel now or be homeless. And everyone just blindly jumped on board... then the next they start charging you to turn on the TV and opening the minibar... and idiots are shocked. Like yeah geniuses, that is why some of us tried to push back on making everything a f'ing hotel.
I did find it funny, but props on you for owning it in camera and then asking for help on the twitterverse. Thanks for making the video and bringing forward the insights from your perspective.
It's obvously nice to have a good camera for an interview but you really shouldn't be ashamed to just record it with a phone. That isn't nearly as unprofessional nowadays as you might think. Especially on an android developer conference! It's too late now, but maybe for next time. Just using your phone as a backup is acceptable.
lmao the day 2 and day 3 camera issues had me actually laughing out loud. Great video edit: I dont know how feasible it is, but a liveoverflow font that supports nerdfont style icons that I could use as a terminal font would be awesome.
Decompiling an APK is incredibly easy. When that's the only thing keeping a stranger from what is more or less a copy of your source code, I can see why that would be worrying for a closed source app, unless you go the extra mile to run everything on the server side or require an always-online app (with the new worry of that being patched out), neither of which is a good user experience. So the stopgap for many people is obfuscation, and plenty of companies are happy to oblige. Data security isn't the priority for most local apps, IP security is.
Friendly reminder to double check ai generated captions. I assume you wouldn’t have transcribed “root” as “roots”. Thanks for the fantastic video as always :)
There are typical mobile security topics (beside insecure backends M1,M2), especially unsafe credential storage (M5 not using proper Api, M9 not proteting local data), exposing insecure interfaces (share handlers, url handlers), app secrets and a lot of Trojan/malicious dependencies (M3)
Not an android developer, but im pretty sure the disproportional concern about reverse engineering is due to java and other languages with runtime such as C# It is quite trivial to de-compile a java app, and i suspect its much easier to get insights into the architecture compared to revere engineering a c++ program. Obfuscating is a pain in my ass in my experience, especially if the system surrounding the software wasn't built for it. Kinda makes you wonder why projects like GCJ aren't more used, especially considering that (no matter what oracle says) you can never assume that your target machine has the JRE you need.
most dev's only gives a little care security of the users, obfuscation is done just people don't steal code for their app... :) you know, making android apps are hard and expensive....
@@ES-cf4ph but the manager who pays for the employees doesn't know app is a amalgamation of some random github repo and a 1000 stackoverflow answers..... :)
I had a very similar fackup with my rocket computer recently, when I firstly forgotten to change the batteries and the forgotten the SD and then batteries again
Lol we can see these guys never tried to reverse engineer their own app, probably easier to just re-code their empty frontend app in most cases.. Maybe they're just super proud of their responsive design and think it's something others could want to steal😂?
I hate security by obsecurity bullshit. That makes so much harder for new hackers to enter the field. I understand it when you make something like malware that is supposed to harm and be secret about its functionality. But banks/productivity apps? Most of their functionality is based on server side! Also game anti cheats are now obsolete. Nowadays everything goes into server side!
As a developer, I never understood those either. Also arguments made from some developers on the interview like "Oh they could reverse engineer und could see how our API works." And? What's the problem with that? If I wanted to intercept API calls I would rather install a self signed certificate on my device and intercept the traffic with a proxy ... I would agree if people would argue with defense in depth, but just saying "I need to obfuscate" is just fishy
I mean these days you're using a framework for almost everything. So if they are safe, then you're safe (if you dont fuck up things like CSRF, XSS, SQL-Injections etc.). The people on the conference are probably mostly app developers and not framework developers.
@@TheVertical92no framework can protect against bad security, that's not a thing. Any tool that doesn't allow a developer to do something stupid probably just isn't a very capable tool.
@@kneesnap1041 That was not my point. The devs on the conference probably build just frontends to a service API. So if they dont fuck up some common security practices on the frontend, they should be fine if the tools (frameworks) are secure. Ofc a framework cant protect your user data from being stolen if you built your authorization wrong.
To the people in the comments saying that the backend devs are the ones that do the heavy lifting for the security - a LOT of Android specific bug classes are front-end based. Here is a full chain, zero click exploit to get RCE based only on front-end bugs: th-cam.com/video/-eAR6qduVWY/w-d-xo.html
I think the sentence is mostly targeted to the impression, that the whole team including backend does not seem to prioritize security really high and just wants to offload their work to a "magical solution" and security through obscurity. Still, a fully client side RCE sounds very interesting :)
I was there for the whole duration, and I cannot believe I missed you. I'd loved to at least say hi :( Anyway, my takes on the topics you mentioned: Repackaging: you already mentioned that you can understand why is it bad for games with in-app purchase, but other apps can also have in-app purchases, or they can even be paid apps, and removing the purchase check and re-uploading the apk is a real issue. Comparing this to being afraid of someone creating a crack for your app/game on desktop is a fair comparison in my opinion. Obfuscation: In my opinion it serves two purposes. The first one is connected to repackaging, the better the obfuscation your app has, the smaller the chance that someone will take the effort to reverse it and repackage it. The other one is security related: we want to authenticate our app towards the backend. A lot of the times we need an API key to access a service, but we have to store it somehow. There are multiple options, but they all have compromises, and we have to find the one that's the best for both security and the user. Let's have an example: you're working on a weather app, and you're using an external API where you have to pay by the number of requests. Naturally, you want to protect the API key (who wants to pay for someone else's requests?), so you have a few options: - get the key after app install and store it somehow - you can try your app's private folder, but that can be accessed by anyone with a rooted phone, so that's not good enough - most phones nowadays have some kind of secure storage. you can store the key there, but it's a lot of work, and it might require the user to authenticate themselves to access it. most users wouldn't understand why would they need to use their fingerprint to see the weather - bundle your key with the app somehow Whichever option you choose, a malicious actor will be able to get the key. The best you can do is making it as hard as possible for them, in the hope that they'll decide it doesn't worth the trouble and give up. This is where obfuscation comes into the picture. On an other topic: the recordings from the conference were released today, and even though most security talks were basically ads for their company, there was one that was really interesting, you can watch it here: www.droidcon.com/2023/07/31/how-to-attack-and-secure-an-android-app-an-introduction/
The answer seems pretty obvious to me: Only give the API access to the backend, and user app talks to the service via your backend. Not only do you circumvent the need to hide the API key, but you can now manage how many times it's used entirely on your own. Like in your Weather app example, you can cache the weather data regionwise so you don't need to access it again for another user of same area.
You're right about the backend, but not every app developer is capable of creating one, and even if you have one, you might want to authenticate your app towards your own backend, then you have the same issue. The example might not have been the best, but I can easily think of other cases, when this is a real issue. For example: you're making a third party app for an existing service (maybe Reddit or Twitter). In that case you probably wouldn't want to create a separate backend, since it would be a lot of work and money to keep it running. Asking for a few $ for the app would probably not be enough to cover the costs.
you know that obfuscation and repackage protection is not actually solving the problem. It might raise the bar, but if you worry about yoru API key getting stolen, how is that actually preventing it? You cannot, it will always be possible. Thus I think effort and worries are spent on the wrong thing. Imo it's wasting money on these kind of "solutions" (which are not solutions because they are not able to solve the problem). It's also the perfect product to sell, because your product is selling a feeling of safety, but the problem wont ever be solved ;) Also I would like to see actual data of money "saved" through these methods. Because I doubt that a kid downloading your cracked mobile game would ever have been a paying customer. It's the whole desktop game cracking discussion all over again. In my opinion, the money would be better spent on developing new features, updates or marketing. Also one more anecdote. Many mobile games are inherently flawed when changing the mobile phones time (see my video "dont trust time". You can skip stuff in almost every game with in-app purchases! This is a much bigger issue because it's easy to do and doesn't even require untrostworthy app stores and side-loading. Just change your time and easily cheat. And has there been a single talk at droidcon about game developers being aware of system time manipulation? No, of course not. because there is no product to sell for it.
@@psheggerIf not all developers capable of doing this, then they are not capable enough to create such app in the first place. And why do you need to authenticate app towards your backend?
Stealing intellectual property (code); Finding vulnerabilities in the (for instance, bad usage of intents) to abuse it later from malware; Cheating in mobile games; Repackaging applications; I can go on, but too lazy
@@ZappexeI could maybe understand the stealing intellectual property argument for some code that does something innovative, and frontend code is usually anything but innovative or worth protecting tbh, i mean it just connects to the backend then draws a ui. Cheating in mobile games eehh if its an online game then protections should be in the backend, since any kind of client side anti cheat can be circumvented, and if its single player then nobody cares. Also the trying to hide vulnerabilities part is not good either, if they have a vulnerability with some intent, then they should fix that since obfuscation won't fix the problem lol. The reason obfuscation really pisses me off when it's unnecessary(which most of the time it is) is that, i feel like it would deter a lot of people from being interested in cyber security, cuz when a kid just starts out discovering that they can decompile apps etc and modify them in some ways, when it works it gives them a huge push to keep them interested in the field, if everything is obfuscated people just getting into the field would mostly just quit out of frustration.
@@Zappexe This is just the security-by-obscurity argument. "Finding bad usage of intents or vulnerabilties to abuse later" basically means instead of trying to vet their app properly, they're trying to hide the mistakes by putting a drape over it. This never works out. I totally get the "stealing UI/UX IP and the general look-and-feel of an app to create a very convincing fake" argument. They may get their reputation damaged by proxy of what the fake app does, or worse be a vector for phishing attacks.
@@y_arml I get you, but you kinda proved his point with the "frustrating lower level thugs enough that they move on or quit" 💀. Most people's threat model is satisfied by warding away curious eyes and script kiddies.
Fearing reverse engineering is a learned fear. People are told to fear it and they just start to. Reverse engineering is not a security concern. Simple solution, just Open Source your code. People will have no reason to go to someone else for you program if they can get the best copy from you. If someone improves it, and you use a good license(GPL), then the improvements can be pushed back to your code. Both programs will only get better and not one will need to go to shady sources to get your APP. Problem solved.
Orrr… they can just copy your code, repackage it with their name on top, and sell it for profit with fancy marketing you can’t afford because your code is free and open source… which is what actually ends up happening in this world.
@@elon6131 It does not lol. Look at recent Kick website thing. They literally copied whole UI/UX lmao, still it was not security issue, since UI is not property of the website. Everyone can use this, and it literally happens in web development
Why didn't you use yout phone to record it? Mic doesn't work on phone? Also I'm pretty sure when they were saying obfuscation, they were thinking security for them as the developer, not for the users. The intent thing is just dangerous for the user, cause it can potentially access user data and things its not supposed to.
Though it may look like it is just the front end of the app, as the app will be installed on the user's phone, it really concerns us if the code gets stolen, modified, or monetization gets removed. We really do small things in the backend or use Firebase as a backend service.
@@LiveOverflow my head cannon is that mobile engineers are more like designers, and dislike when other apps look similar (or the idea they can just steal the whole thing!) Also, messy code getting out there can be embarrassing haha
@@LiveOverflow In the case of the web, not the complete code is delivered to the user; only the requested part is delivered. Often, websites do server-side rendering (SSR), and the requested part of the page is delivered.
Just like security in layers, and data redundancy, you seem to need recording equipment redundancy. :p Take this as a practice run and learn from it, be glad it wasn't a major security conference you needed to record it or something.
Not everything revolves around the backend. For instance, bad usage of the platform (e.g. intents, storage, etc.) in the banking app could lead to unauthorized transaction. That's just one thing of many you can do or application can be vulnerable too.
Let's be real, backend devs often don't care that much about security either. I had enough discussions with coworkers writing functions which for example just accepts a name and injects it into an SQL query without validation and/or escaping and not documenting this behaviour.
I see lots of parallels to game cracking on desktop. And there we have seen that all the anti-cracking and obfuscation has never stopped cracks. And most anti-cheat methods also get bypassed. I always feel like those companies spend more on these technologies, than it safes in revenue - but obviously I have no data. It's just my guess, though would love to see proper research on the topic.
I really don't see the point of attending these conferences in person. All these talks should be recorded and published to the Internet afterward. If they are not, then the conference sucks. ;) It's never worth it anyway.
The "meet others and chat" opportunistically is the main point of conferences in my view - and also to accidentally wander into a session and pick up something by chance.
Watch me go out of my comfort zone approaching strangers and interviewing them.
The answers were very interesting and as a security consultant their point of view is important to me.
relatable
relatable
Imo it was really cool
Where can I get started with Android Security? I was a flutter developer and I'm currently learning Jetpack Compose, but I want to see both sides of the coin (developing and hacking).
I love how that one app dev said repackaging an app to remove monetization is an improvement
Make slogan "Defective by Design" go to a new level
Chances of this being in direct reference to ReVanced?
I can tell you something about security measures in banking apps I used. They have no problem with running on an old android version with known vulnerabilities. But they can detect rooted androids or even androids with unlocked bootloader and lock the user out. At the same time there is no problem with using their banking website.
That's afaik a Android built-in API called CST attestation, that gives the apps hints if it's running on a rooted device or not.
thankfully, that is bypassable with some magisk trickery
@@inertia_daggerwhy thankfully? No one wants to get their bank get hacked. I don't understand you
@@alang.2054no root detection is ever going to prevent a bank from getting hacked.
@@alang.2054 If I rooted my phone, I know what I'm doing. No need to "protect" me by not allowing me to use the app(unless the app stores security info in plain text in app's private data)...
Hi @LiveOverflow. Love the vids. Just had one small comment. I noticed you put notes in your videos in different parts of the screen, including the bottom part. Since my native language is not english, some times I use subtitles to understand better. Unfortunately the subtitles cover your notes if they are at the bottom, so I'm left to either pause the video continuously, or watch without subtitles. if you could leave a little space for the subtitles at the bottom, or use other parts of the screen, it would help people that need subtitles. Thanks for the content!
Honestly, the mobile apps ecosystem has become quite a nightmare nowadays. It wasn't surprising to me that most devs consider reverse engineering their greatest enemy. But it is a problem and I just cannot complain about it enough. In Asia especially, it's not uncommon to see apps packed with commercial "protectors" that literally behave like advanced malware packers. Such things are just horrible to end users in terms of security. They are so ubiquitous that it's not ideal to ban them on the app store, while no effective method is available to determine whether an app packed with such a "protector" is benign or not. And I do feel the devs' frustration, too. You can not just blame users for being muggles who cannot distinguish the original app from all those cash-grabbing copycats. After all, they are just users, and users bare absolutely no responsibility to serve the devs. As for the copycats, there is no way to detect them, either. The whole situation is just awful, with no obvious solution in sight. Sigh...
The original concept of "protecting client side code" seems deprecated to me, most tech managers don't even understand why they are doing that anymore. While working for banks i often saw that, principles that used to be true but not true anymore due to more advanced algorithms practices that don't get updated. If you are not protecting your JS or wasm in web but you want to protect your android, ios client side code mostly interacting with your backend. Most well designed apps in React native or Flutter don't make critical storage or config mistakes anymore. So you are "protecting your code against what" attackers don't find client side bugs ?
Keep in mind that apps have to work offline
I think those developers dont really know that much about security based on the interviews. They worry about reverse engeneering because of someone stealing their assets. Thats not really application security. Its more like business security in case any competitor gets a benefit. The backend is what gets hacked and where the data is leaked in most cases. Saying that a registration of a username called "root" is forbidden shows me that their backend is most likely not really that robust if it cannot handle that.
Yeah, although it might be defense in depth, it raises a red flag if someone wants to validate something like this in the frontend or even feels that much of a need to validate this at all ...
Yeah, if you are worried about reverse engineering to prevent others making a better app than your own.... maybe you should spend that reverse engineering prevention time into actually making the app good enough to where an alternative won't have many benefits compared to your own (thus making the alternatives less appealing
@@w花byeah, if you use obfuscation to ignore fixing issues with your app, imo you are doing it wrong
I really like this type of content! It's a pity that you got those camera issues but thank you for sharing that. The fact that you shared that and told us about it made you even more wholesome and relatable :) One thing that triggered me a bit was that you didn't resolve what movie played at day 2 but maybe you dont know about it either. All in all a great video with nice insights!:)
not loving where their heads are at re: blocking access to codebasses, obfuscating, this is how you get closed source security theatre
The anti-reversing protections, at least to me, seem to be very similar to web application firewalls and their bot JS challenges. Many people are discouraged by it, but somebody with motivation and resources will not be stopped by it.
Yeah obfuscation and security through obscurity often gives a false sense of security.
Still gutted we didn't cross paths - thanks so much for all you have done to promote security!
You were one of my many inspirations to speak and discuss mobilesec. Hope to thank you in person next year 😅
As someone working for one of the App Security companies at that conference (not shown in the video); it's not so much that these companies care so much about obfuscation, but many of our customers think obfuscation is the important part. I get what you mean when you call it snakeoil, and I agree to an extent, but it is usually just a smaller part of the bigger picture. Unfortunately many developers and especially regulators think obfuscation is very important.
Yes yes yes! Most of regular apps don't need anything like that but obfuscation and malicious environment detection is critical for finance apps and the game industry. I think people might get a wrong idea from this video
@@Zappexe Why would obfuscation be critical in a finance app? If you need to obfuscate the frontend of a finance app for it to be secure you are probably already in deep shit security-wise. The only apps that might profit from obfuscation are those that have a majority of their actual business logic on the client side. This should never be the case for finance apps.
@@aseidma3576Also, I don't understand why the App platforms aren't developing some kind of "trusted computing", offloading encryption and challenge response based tasks onto a dedicated chip like with WebAuthn for example? Also, isn't 2FA supposed to solve the problem of signing transactions even without such advanced techniques?
@@aseidma3576 The argument is that if the protocol can be reverse-engineered, then attackers can try to attack the backend directly. If you can steal credentials but you can't spoof requests then it's harder to scale up an attack. And if you're phishing, the more you can do to replicate the real behavior of the app, the more likely it is that you can trick users into thinking nothing is wrong. And if it's harder to analyze the behavior of the app, it's harder to use it for something like a confused deputy attack.
Yes, of course it doesn't actually STOP anything. Backend security and fraud detection is way more important. But that doesn't mean front end security doesn't matter.
@@Zappexe obfuscation only gives you time, it doesn't prevent something from being reverse engineered
Obfuscation is just another way of saying security through obscurity
Hey! Your videos have taught me so much. Thank you!
At one point I become so frustrated that "everything is app" in my smartphone that I just switched to web where I could and other junk just dumped and started using my laptop more. I hope that one day smartphones will stop being frontshop for corporates to sell their products and start being what they really are - computers in our pockets.
Nowadays devs are lazy and apps are more and more just packaged web apps, lol
Yea same, I simply stopped using services that require a mobile app and do as many things as reasonable on my laptop or desktop instead of my phone
it's so frustrating how bad it is and how stupid people most people are to just let it happen.
Phones in the last five years have regressed in usability while getting absolutely minimal / mediocre feature improvements. There's a reason apps force updating now.. if they didn't a good chunk of people wouldn't update, because updates degrade the product now.
It's like we started out with houses, and naturally people wanted better houses. So someone came along and says hey we upgraded your house to this hotel room! The TV is 4" larger than the old one! And no you don't have a choice, either you move into the hotel now or be homeless.
And everyone just blindly jumped on board... then the next they start charging you to turn on the TV and opening the minibar... and idiots are shocked. Like yeah geniuses, that is why some of us tried to push back on making everything a f'ing hotel.
I did find it funny, but props on you for owning it in camera and then asking for help on the twitterverse. Thanks for making the video and bringing forward the insights from your perspective.
It's obvously nice to have a good camera for an interview but you really shouldn't be ashamed to just record it with a phone. That isn't nearly as unprofessional nowadays as you might think. Especially on an android developer conference!
It's too late now, but maybe for next time. Just using your phone as a backup is acceptable.
imagine pulling out an iPhone at an Android development conference :P
lmao the day 2 and day 3 camera issues had me actually laughing out loud. Great video
edit: I dont know how feasible it is, but a liveoverflow font that supports nerdfont style icons that I could use as a terminal font would be awesome.
Client side obfuscation seems insane to me
Decompiling an APK is incredibly easy. When that's the only thing keeping a stranger from what is more or less a copy of your source code, I can see why that would be worrying for a closed source app, unless you go the extra mile to run everything on the server side or require an always-online app (with the new worry of that being patched out), neither of which is a good user experience. So the stopgap for many people is obfuscation, and plenty of companies are happy to oblige. Data security isn't the priority for most local apps, IP security is.
lol you rock with the camera stuff indeed!
Friendly reminder to double check ai generated captions. I assume you wouldn’t have transcribed “root” as “roots”. Thanks for the fantastic video as always :)
So what was the movie?
There are typical mobile security topics (beside insecure backends M1,M2), especially unsafe credential storage (M5 not using proper Api, M9 not proteting local data), exposing insecure interfaces (share handlers, url handlers), app secrets and a lot of Trojan/malicious dependencies (M3)
I hear a lot of examples of security through obscurity here
congratz for new format. I like this a lot
So? Which movie was it?
Which movie was in the end? Hackers? The Net?
Not an android developer, but im pretty sure the disproportional concern about reverse engineering is due to java and other languages with runtime such as C#
It is quite trivial to de-compile a java app, and i suspect its much easier to get insights into the architecture compared to revere engineering a c++ program.
Obfuscating is a pain in my ass in my experience, especially if the system surrounding the software wasn't built for it. Kinda makes you wonder why projects like GCJ aren't more used, especially considering that (no matter what oracle says) you can never assume that your target machine has the JRE you need.
Isn't hiding the source code pretty infective in trying to get better security?
it's often also to prevent modifications of the app to remove the ads, etc.
most dev's only gives a little care security of the users, obfuscation is done just people don't steal code for their app... :) you know, making android apps are hard and expensive....
@vaisakhkm783 Yeah and we all know apps are always so innovative and are never just trashy copycats of each other ...
@@ES-cf4ph but the manager who pays for the employees doesn't know app is a amalgamation of some random github repo and a 1000 stackoverflow answers..... :)
@@vaisakh_km loool
I had a very similar fackup with my rocket computer recently, when I firstly forgotten to change the batteries and the forgotten the SD and then batteries again
superb! hope, I'll be there with you one day
its okk we dont want anything just the content that you create that enough for making our day wonderfull :))
Lol we can see these guys never tried to reverse engineer their own app, probably easier to just re-code their empty frontend app in most cases.. Maybe they're just super proud of their responsive design and think it's something others could want to steal😂?
I hate security by obsecurity bullshit. That makes so much harder for new hackers to enter the field. I understand it when you make something like malware that is supposed to harm and be secret about its functionality. But banks/productivity apps?
Most of their functionality is based on server side! Also game anti cheats are now obsolete. Nowadays everything goes into server side!
As a developer, I never understood those either. Also arguments made from some developers on the interview like "Oh they could reverse engineer und could see how our API works." And? What's the problem with that? If I wanted to intercept API calls I would rather install a self signed certificate on my device and intercept the traffic with a proxy ... I would agree if people would argue with defense in depth, but just saying "I need to obfuscate" is just fishy
So do you or do you not want to be approached ? oh and what movie was it ?
I like to be approached. I don’t like to approach;)
@@LiveOverflow Noted :D
So...was the movie Hackers?
Can you create a short video on Active Directory?
i know nothing about AD
what was the movie though?
is smali reveresing, frida still possible? if no then what developers security developers use to prevent those?
can u plz do more such videos as they really feel refreshing
Great video as always, it was funny how unlucky you were haha there is always next con
Conference Day 3's audio is so messed up, surely a camera man would've been helpful 😅
Lmao, that video was comedy gold, exactly my kind of humor! :D
As a developer, I think you can be a hacker without knowing how to code, but, if you want to be a really badass motherfucker hacker, it's a must!
🤣 good to know that there is next to no effort put into protecting users 😡
I mean these days you're using a framework for almost everything. So if they are safe, then you're safe (if you dont fuck up things like CSRF, XSS, SQL-Injections etc.).
The people on the conference are probably mostly app developers and not framework developers.
@@TheVertical92 🤔, thanks
@@TheVertical92no framework can protect against bad security, that's not a thing. Any tool that doesn't allow a developer to do something stupid probably just isn't a very capable tool.
@@kneesnap1041 That was not my point. The devs on the conference probably build just frontends to a service API. So if they dont fuck up some common security practices on the frontend, they should be fine if the tools (frameworks) are secure. Ofc a framework cant protect your user data from being stolen if you built your authorization wrong.
To the people in the comments saying that the backend devs are the ones that do the heavy lifting for the security - a LOT of Android specific bug classes are front-end based. Here is a full chain, zero click exploit to get RCE based only on front-end bugs: th-cam.com/video/-eAR6qduVWY/w-d-xo.html
I think the sentence is mostly targeted to the impression, that the whole team including backend does not seem to prioritize security really high and just wants to offload their work to a "magical solution" and security through obscurity. Still, a fully client side RCE sounds very interesting :)
I was there for the whole duration, and I cannot believe I missed you. I'd loved to at least say hi :(
Anyway, my takes on the topics you mentioned:
Repackaging: you already mentioned that you can understand why is it bad for games with in-app purchase, but other apps can also have in-app purchases, or they can even be paid apps, and removing the purchase check and re-uploading the apk is a real issue. Comparing this to being afraid of someone creating a crack for your app/game on desktop is a fair comparison in my opinion.
Obfuscation: In my opinion it serves two purposes. The first one is connected to repackaging, the better the obfuscation your app has, the smaller the chance that someone will take the effort to reverse it and repackage it. The other one is security related: we want to authenticate our app towards the backend. A lot of the times we need an API key to access a service, but we have to store it somehow. There are multiple options, but they all have compromises, and we have to find the one that's the best for both security and the user.
Let's have an example: you're working on a weather app, and you're using an external API where you have to pay by the number of requests. Naturally, you want to protect the API key (who wants to pay for someone else's requests?), so you have a few options:
- get the key after app install and store it somehow
- you can try your app's private folder, but that can be accessed by anyone with a rooted phone, so that's not good enough
- most phones nowadays have some kind of secure storage. you can store the key there, but it's a lot of work, and it might require the user to authenticate themselves to access it. most users wouldn't understand why would they need to use their fingerprint to see the weather
- bundle your key with the app somehow
Whichever option you choose, a malicious actor will be able to get the key. The best you can do is making it as hard as possible for them, in the hope that they'll decide it doesn't worth the trouble and give up. This is where obfuscation comes into the picture.
On an other topic: the recordings from the conference were released today, and even though most security talks were basically ads for their company, there was one that was really interesting, you can watch it here: www.droidcon.com/2023/07/31/how-to-attack-and-secure-an-android-app-an-introduction/
The answer seems pretty obvious to me: Only give the API access to the backend, and user app talks to the service via your backend. Not only do you circumvent the need to hide the API key, but you can now manage how many times it's used entirely on your own. Like in your Weather app example, you can cache the weather data regionwise so you don't need to access it again for another user of same area.
I'm surprised people keep secrets on client-side. I think you chose a bad/contrived example.
You're right about the backend, but not every app developer is capable of creating one, and even if you have one, you might want to authenticate your app towards your own backend, then you have the same issue.
The example might not have been the best, but I can easily think of other cases, when this is a real issue. For example: you're making a third party app for an existing service (maybe Reddit or Twitter). In that case you probably wouldn't want to create a separate backend, since it would be a lot of work and money to keep it running. Asking for a few $ for the app would probably not be enough to cover the costs.
you know that obfuscation and repackage protection is not actually solving the problem. It might raise the bar, but if you worry about yoru API key getting stolen, how is that actually preventing it? You cannot, it will always be possible.
Thus I think effort and worries are spent on the wrong thing. Imo it's wasting money on these kind of "solutions" (which are not solutions because they are not able to solve the problem). It's also the perfect product to sell, because your product is selling a feeling of safety, but the problem wont ever be solved ;)
Also I would like to see actual data of money "saved" through these methods. Because I doubt that a kid downloading your cracked mobile game would ever have been a paying customer. It's the whole desktop game cracking discussion all over again. In my opinion, the money would be better spent on developing new features, updates or marketing.
Also one more anecdote. Many mobile games are inherently flawed when changing the mobile phones time (see my video "dont trust time". You can skip stuff in almost every game with in-app purchases! This is a much bigger issue because it's easy to do and doesn't even require untrostworthy app stores and side-loading. Just change your time and easily cheat. And has there been a single talk at droidcon about game developers being aware of system time manipulation? No, of course not. because there is no product to sell for it.
@@psheggerIf not all developers capable of doing this, then they are not capable enough to create such app in the first place. And why do you need to authenticate app towards your backend?
what's the deal with reverse engineering the app lol do they keep private keys in the frontend???
Their "security" concern around that seems only to be regarding around ensuring that their code can't be so accessible to their competitors, it seems.
Stealing intellectual property (code); Finding vulnerabilities in the (for instance, bad usage of intents) to abuse it later from malware; Cheating in mobile games; Repackaging applications;
I can go on, but too lazy
@@ZappexeI could maybe understand the stealing intellectual property argument for some code that does something innovative, and frontend code is usually anything but innovative or worth protecting tbh, i mean it just connects to the backend then draws a ui. Cheating in mobile games eehh if its an online game then protections should be in the backend, since any kind of client side anti cheat can be circumvented, and if its single player then nobody cares. Also the trying to hide vulnerabilities part is not good either, if they have a vulnerability with some intent, then they should fix that since obfuscation won't fix the problem lol.
The reason obfuscation really pisses me off when it's unnecessary(which most of the time it is) is that, i feel like it would deter a lot of people from being interested in cyber security, cuz when a kid just starts out discovering that they can decompile apps etc and modify them in some ways, when it works it gives them a huge push to keep them interested in the field, if everything is obfuscated people just getting into the field would mostly just quit out of frustration.
@@Zappexe This is just the security-by-obscurity argument. "Finding bad usage of intents or vulnerabilties to abuse later" basically means instead of trying to vet their app properly, they're trying to hide the mistakes by putting a drape over it. This never works out.
I totally get the "stealing UI/UX IP and the general look-and-feel of an app to create a very convincing fake" argument. They may get their reputation damaged by proxy of what the fake app does, or worse be a vector for phishing attacks.
@@y_arml I get you, but you kinda proved his point with the "frustrating lower level thugs enough that they move on or quit" 💀. Most people's threat model is satisfied by warding away curious eyes and script kiddies.
Fearing reverse engineering is a learned fear. People are told to fear it and they just start to. Reverse engineering is not a security concern. Simple solution, just Open Source your code. People will have no reason to go to someone else for you program if they can get the best copy from you. If someone improves it, and you use a good license(GPL), then the improvements can be pushed back to your code. Both programs will only get better and not one will need to go to shady sources to get your APP. Problem solved.
Orrr… they can just copy your code, repackage it with their name on top, and sell it for profit with fancy marketing you can’t afford because your code is free and open source… which is what actually ends up happening in this world.
@@elon6131 It does not lol. Look at recent Kick website thing. They literally copied whole UI/UX lmao, still it was not security issue, since UI is not property of the website. Everyone can use this, and it literally happens in web development
@@elon6131 there are repackaged VLC media player apps but have you heard of it, or even know what they are?
Why didn't you use yout phone to record it? Mic doesn't work on phone?
Also I'm pretty sure when they were saying obfuscation, they were thinking security for them as the developer, not for the users.
The intent thing is just dangerous for the user, cause it can potentially access user data and things its not supposed to.
"Hello im outside" - Local Hacker touches grass
12:20 From behind you look basically identical to Tomary...
you're a professional youtuber in my heart ❤❤
Setting the username to a root or to a dot can give high privileges, never thought about that 🤔
i like this guy man
thank you for the video :-)
"let me tell you what i fkd up today" :D
Though it may look like it is just the front end of the app, as the app will be installed on the user's phone, it really concerns us if the code gets stolen, modified, or monetization gets removed. We really do small things in the backend or use Firebase as a backend service.
How is that different from the HTML and JS of a website? The complete code bundle typically gets downloaded on the web as well ;)
@@LiveOverflow my head cannon is that mobile engineers are more like designers, and dislike when other apps look similar (or the idea they can just steal the whole thing!)
Also, messy code getting out there can be embarrassing haha
@@LiveOverflow In the case of the web, not the complete code is delivered to the user; only the requested part is delivered. Often, websites do server-side rendering (SSR), and the requested part of the page is delivered.
@@RuleBreakersCreatorsMany websites often do more and more client side rendering, too.
Just like security in layers, and data redundancy, you seem to need recording equipment redundancy. :p
Take this as a practice run and learn from it, be glad it wasn't a major security conference you needed to record it or something.
Although, It's a good point that we can download mod apps anytime.
7:40 you are at an android development conf, usually the real security conserns are in the backend; those people are not at the conf.
that's why it's interesting to hear what they know ;)
Not everything revolves around the backend. For instance, bad usage of the platform (e.g. intents, storage, etc.) in the banking app could lead to unauthorized transaction. That's just one thing of many you can do or application can be vulnerable too.
I digress, a unsafe front end can be exploited by a savvy exploiter through an internal middleman.
Let's be real, backend devs often don't care that much about security either. I had enough discussions with coworkers writing functions which for example just accepts a name and injects it into an SQL query without validation and/or escaping and not documenting this behaviour.
Camera vulnerabilities? 👀👀
13:36 - 13:48 was the funniest section 😆 I literally pooped my pants on that one
Im outside... but not for long. hahah
They are like it's not our job 😅
I will watch this video when I screw something up!
Well this is scary
First time watching you outside home😆😅
It's ok everybody make mistake, I also forget my sd card from time to time. Video still interesting.
You can never pack enough un... SD-cards.
Why not just interview with your, phone..? Bad audio?
0:02 story of my life.
Security conferences are usually small, you say? Ever been to Blackhat USA? 😅 Defcon? 😂
lol D2 and D3 are soo funny XD
Also at security conferences filming is sometimes discouraged to protect peoples' identity/privacy
If a CPU can decode your application, than human can do it too (with sufficient skills & tools)
make more minecraft videos
This video reminds me of my life 🤣
Plot twist: he intentionally fucked up to not get out of his comfort zone lol jk
Hi
Hello
ahh android the spyware of google.
:)
ha ha funny :D
Blackhat hackers are crying at the corner 😂😂😂.
this episode was way below your standart
I talked to people for this video!!!! This is a huge deal :P
Mobile security?
You’re joking right?
There’s no such thing. Even if you did have it they could just take the phone from you.
Lol, we all know OSI layer 8 is always the heighest security risk
First
Pinnnn
deobfuscation, modifying and then reuploading is a real issue, there are whole platforms for them which ruins a great part of revenue
I see lots of parallels to game cracking on desktop. And there we have seen that all the anti-cracking and obfuscation has never stopped cracks. And most anti-cheat methods also get bypassed. I always feel like those companies spend more on these technologies, than it safes in revenue - but obviously I have no data. It's just my guess, though would love to see proper research on the topic.
Meh ...
Disliking all videos on multiple accounts until minecraft hacked comes back!!!
More Minecraft hacking or riot!
I really don't see the point of attending these conferences in person.
All these talks should be recorded and published to the Internet afterward.
If they are not, then the conference sucks. ;)
It's never worth it anyway.
Think it's mostly a network thing
The "meet others and chat" opportunistically is the main point of conferences in my view - and also to accidentally wander into a session and pick up something by chance.