x1sec

Could you describe the smell?

By "extensibility" does this mean the ability to write your own extensions? Being able to develop and contribute plugins back to the community (similar to Burp's BApp store) could really accelerate the competitiveness of Caido up against Burp.

Caido[1] a interception proxy written in Rust, is positioning itself as a "lightweight" alternative to Burp. It can't compete yet with Burp in terms of functionality, although the product is certainly looking promising.

Perhaps the only contender to Burp in respect to functionality/features is ZAP[2].

EDIT: You can run your own collaborator type setup with Project discovery's interactsh[3].

Further EDIT: A downvote might be because of the mention of Rust / closed source - this is explicitly mentioned because a large pain point for Burp is it's a Java memory hog. If Caido was written in C++ with Qt, this fact would be notable for the exact same reason.

[1] https://caido.io/

[2] https://www.zaproxy.org/

[3] https://github.com/projectdiscovery/interactsh

This is not a new plugin; it (and similar extensions) have been available for Burp and a staple for testers for a few years now.

Automating authorisation checks has less to do with novelty seeking and more to do with the practicalities of ensuring adequate coverage within the assigned engagement time frame.

In the Q&A section, the speaker remarks:

"There is a part of the talk where I am trying to perform a little bit.. the thing that I'm also talking about. My background is in art .. and we always try to think about form and content being kind of the same thing.."

Thoroughly entertaining, well executed.

Perhaps a physical switch that connects or disconnects the electrical signal from the microphone to the handset could be a more convenient approach.

There is a photo of Mark Zuckerberg with a cut off 3.5mm jack plugged into his laptop - likely to achieve a similar outcome.

How frequent?

In a week, a lot of data can be exfiltrated. Then after you have rebooted, the threat actor reinfects your device.

Frequently rebooting the device can’t hurt but it likely isn’t going to prevent a threat actor from achieving their objectives.

The best mitigation we have is to enable lockdown mode.

A port of the tutorial's Pascal code to C which emits x86 assembly:

https://github.com/lotabout/Let-s-build-a-compiler

> Of course it is quite common to need to read it

This is a notable differentiation - Writing assembly is a different skill to reading it from a disassembly. Reverse engineering, malware analysis etc. does not inherently require you to be able to write asm, although it certainly would help.

SSID / BSSID is often enough to pinpoint the location. Recently someone debated this with me, so I asked him what his wifi AP name was, then proceeded to provide their home address.

How? By searching it in https://wigle.net.

That ended the debate quite swiftly.

Recently having stumbled across the VSCode shellcheck plugin[1] - it's been particularly educational as it provides not only corrections but improvement tips. For example the common practice of:

if [ $? -ne 0 ]; then

Will get flagged and an improvement will be suggested with an explanation on why [2]

[1] https://marketplace.visualstudio.com/items?itemName=timonwon...

[2] https://www.shellcheck.net/wiki/SC2181

Cal Newport, the author of 'Deep Work'[1] releases frequent content on Youtube [2] that attempts to address the kind of challenges expressed by the author.

[1] https://www.goodreads.com/en/book/show/25744928

[2] https://www.youtube.com/@CalNewportMedia

Pikuma has a 25 hour “NES Programming with 6502 Assembly” that is both accessible to beginners with little to no prior knowledge and being packed with content. [1]

He also has other interesting courses which touch upon “retro” programming in a very accessible manner. [2]

[1] https://pikuma.com/courses/nes-game-programming-tutorial

[2] https://pikuma.com/courses

I'm not sure if either of you will read this message - I kept my word and looked into the app

https://twitter.com/haxrob/status/1673874637632196608

I'm confused by what you mean here, could you elaborate?

For clarification - you purchase the hardware then you are required to download the phone application. You find this app by scanning the QR code printed on the physical device's box. This app is free. It does not link to a premium version.

> The article seems to be suggesting the device itself is gathering data and reporting back covertly ... but I believe it's just the AMap library included by the app developer doing its thing.

If this is the take away, then I need to think about how I have phrased things. The GPS co-ordinates are sent two separate companies:

1) The Bluetooth device developer (bm2.quicklynks.com)

2) AMap (dualstack-cgicol.amap.com)

Looking at the decomplication and HTTP REST messages, it is very clear the app developer is deliberately sending GPS to their servers. They send a JSON object with the battery voltages, bluetooth device address and lat/lng in the same request.

The cell data, wifi beacon data - this is exclusively collected by AMap services and is not apparent without investing significant time reverse engineering their SDK.

Hey thanks, Daneel - A bit of accountability always helps!

Google do offer Android app developers guidance in this regard:

https://developer.android.com/guide/topics/connectivity/blue...

> They will kick you out the store if they detect you're lying about the permission

You have to wonder how long this app never got taken down. Permissions declared in the manifest do not always equate to them being used.

Google could cross reference the privacy statement that the developer published against the manifest. That would have got it flagged.

The actual code that calls android.content.Context.checkCallingOrSelfPermission() obfuscates the permission strings in many places - bypassing static code analysis checks.

Thanks for this: I've updated the post with a note on 'if your app uses Bluetooth scan results to derive physical location'. I highly doubt this is why they use ACCESS_FINE_LOCATION for this purpose. Rather it's an opportunistic way to get users to accept the permission - they tell users to accept it to get Bluetooth working when the app is first installed.

I wonder how many other apps on the Google Play store do this.

We can't expect the every day user to read and comprehend Google's developer documentation.

Here I am specifically referring to the behavior of the app in question. As pointed out elsewhere, Android 12+ offers flexibility here. That said, it could be argued that there is too much trust for developers doing the right thing when Bluetooth and other location permissions can be mixed under ACCESS_FINE_LOCATION as we witness here.

https://developer.android.com/guide/topics/connectivity/blue...

Update here is that the developers of this app have now updated the Apple and Google store pages disclosing that they do collect location data. So now it's up to the retailers/resellers to comply with local privacy laws and regulations.

If you haven't used it before, Timesketch [1] is excellent indexing and searching timeline data for forensics analysis.

MVT takes a (MACB) timeline of your phone backup file changes and other events - including your text message history.

Here is a simple script that I wrote converts it into a format compatible with Timesketch [2] so it's trivial to explore events from the phone, indexed and searchable by time, kind of what you would see in Kibana.

[1] https://timesketch.org/

[2] https://github.com/x1sec/mvt2timesketch

I do note that BLUETOOTH_SCAN could be used for versions 12+. The link you provided is good, I'll also reference that as it also has details on strong assertion (android:usesPermissionFlags - neverForLocation).

> I suspect what's actually going on is that they're requesting that permission just so they can show your location inside an embedded map view.

Does the embedded map do some processing in the cloud first? Because the lat/lng is sent over the same API request that includes the battery voltages as well as the BLE address of your handset. I really think none of this is essential to a simple app that reads a battery voltage on your screen.

Thank you for the keen eye, fixed.

Hey OP here - I mostly agree with your points in respect to AMap. It's a legitimate mapping service and location SDK.

> Why not mention it's AMap in the tl;dr summary?

The GPS data is being sent to two different companies - the battery monitor developer and AMap. I could make this clearer in the tl;dr.

The cell phone tower data (MNC,MCC,LAC,Cell ID) and Wifi BSSID collection is AMap only.

That said, none of the AMap behavior is disclosed by the application developer. Literally apps that use the AMap SDK in this way turns the user's handset into a continuous scanner. This impacts user experience - just check all the complaints on the 1.75k reviews on the Play store [1].

I doubt many devs are aware of this - It took me countless hours to figure the AMap side of things due to obfuscation techniques in the AMAp code. (See part 2 on the blog post series).

The primary issue is that all this data is collected, sent to multiple 3rd parties (AMap being one of them) and none of this was disclosed to consumers when they download the applications.

[1] https://play.google.com/store/apps/details?id=com.dc.battery...

I've written a basic Python script [1] to read the battery voltage from this device. More details here [2].

Could easily integrate with Home Assistant. Might give it a go actually.

It reads the real time voltages, not voltages stored in the embedded device's memory (for when there is no BLE connectivity while it's running). If there is interest, I can work out this part too.

[1] https://gist.github.com/x1sec/3af7efdcd3465aac09093081c32ba3...

[2] https://doubleagent.net/hardware/ble/bluetooth/2023/05/23/a-...

Great, will take a look and will post on Twitter if there is anything notable found. Twitter handle in my HN profile.

This is exactly what what they did here.

That said, the attention of the blog post seems to have triggered them to disclose now on the Apple [1] and Google Play [2] store that they are indeed collecting your location data. They got away with lying for quite some time, over 100k downloads on Play store and 1.57k reviews.

[1] https://apps.apple.com/au/app/battery-monitor-bm2/id11154920...

[2] https://play.google.com/store/apps/datasafety?id=com.dc.batt...