Hello all, I am currently trying to reverse engineer an obscure Chinese app. When it sends a request, it packages the data into three fields: timestamp, data, and sign. I believe the sign is a md5 hash of the raw data. The data field is what I am posting about, it has only upper case letters and numbers.
According to https://hashes.com/en/tools/hash_identifier, it is using Android FDE (Samsung DEK). Does anyone know how I can unpack this data?
One thing I have tried is to look for some sort of key string after unpacking the apk, however, I could not find any. I'm new to reverse engineering Android applications, anyone have any tips in this department?
Related
Hey guys:
Quick question. I've got a bunch of apps registered on my phone. Every time I flash a new ROM I need to reenter all of those serial numbers. I was looking at the UC customization threads to see if maybe I could just create a provisioning XML to create the appropriate registry entries automatically. Problem is don't think all the apps store their registration information in the registry.
So a couple questions:
1. I've found a good way to see registry changes (and thus figure out which keys I need to update), but I can't find the equivalent for the file system. Is there a tool that can take a snapshot of the file system on the phone, and then show diffs of the current file system with that snapshot? (That way I could figure out the additional files I'd need to copy over to make apps think they're registered.)
2. Is there another mechanism, other than registry and file system, that apps use to set themselves as registered? I couldn't think of anything... but then I'm hardly a hacker. (Even though... and correct me if I'm wrong... this is not technically hacking -- the serials are valid, I just don't want to reenter 10 of them every time I flash)
3. (And this probably belongs more in the UC thread): for some reason my provisionining file has no effect whatsoever. I've verified syntactical correctness of the file, and that cabarc can successfully create a CAB out of it. I've verified that the file is "installed" during the customization step. Yet, after a reset I see none of the changes specified in the provisionining xml. Any idea how I can debug this? Is there a log file that the config program leaves somewhere?
Thanks!
Hi everyone,
I have searched far and wide regarding this matter, and I have not found anything useful regarding the Vibrant. I'm relatively new to Android's internals, I've only started messing around with my Vibrant 5 days ago.
What I'm trying to do is write AT commands to my modem and read the response. I found that apparently many Android devices (mostly HTC from what I've read) have a serial port called /dev/smd0 which can write and receive information from the GSM modem. I've been trying to search for the equivalent /dev/smd0 in the Samsung Vibrant (at least in my device there is no /dev/smd0).
I'm running the stock version of Android (2.1 update 1; Eclair). Baseband version T959UVKA2; kernel version 2.6.29.
So far I've created multiple programs to help me log information and pinpoint the device used to communicate with the GSM modem. I've been using an arm compiler and statically binding resources to my programs (C code).
So far I have attempted to log communication through different devices and serial ports that are owned by the radio group. The only device that I was able to successfully read traffic from was /dev/dpram0. I created a program that acts as a proxy between communication from and to this device (is this a serial port?). All the communication is encoded, which is the main problem I've faced to determine if this is actually the channel to send and receive AT commands. I've time-stamped my log and checked it against logs from logcat -b radio, and I believe I have found encoded AT data... but I cannot verify this.
I have tried writing to /dev/dpram0, but I receive no response. I'm guessing that because I'm using plain text AT commands, the modem does not parse the data. I would expect some kind of response that indicates an error code, but nothing has been received so far.
I have confirmed, however, that data regarding my contacts saved to the SIM card is transferred through this device. Logcat's output is nicely decoded, while the raw data is encoded (I can see plain text strings though!).
Because the data is encoded and I have no idea if there is any kind of sensitive data in the streams received, therefore I'm can't post my whole logs... However, I'll be posting examples that I believe contain nothing sensitive or personal. If anyone is able to decode the data, and find sensitive data, please let me know!
logcat -b radio: excerpt
Code:
...
E/RIL ( 3181): ril.sw_ver=T959UVKA2
E/RIL ( 3181): ril.hw_ver=REV0.3
E/RIL ( 3181): ril.rfcal_date=2010.7.5
E/RIL ( 3181): ril.product_code=SGH-T959ZKBTMB
...
my program's captured stream: Please see uploaded file.
The file contains what seems to be some type of encoded code.
Nutshell: Where are AT commands written to so the GSM modem can read them?
If anyone is willing to point me in the right direction, I would greatly appreciate it!
Thanks in advance!
- Ewido
If you can't handle my level at autism, excuse my disturbing. I just want to obfuscate and shrink dex files on my android phone. I have googled it many times but what I have found was string, variable name encryptors and anti-RE tools. I have looked for a tool which does what I want as proguard does at this site, 4pda, alphagamers and various sites but I got nothing until now. Please help.
Hi,
I'm currently trying to understand how pattern is stored in Android 6 compared to 5, where there was a simple "gesture.key" file, containing an unsalted hash of the pattern. The best explaination I've found so far is by Nikolay Elenkov, who has posted the "Password storage in Android M" on his blogspot.
I'm just looking for some clarification about the process involving the gatekeeper. I've already quickly read some stuff about the Gatekeeper on AOSP site.
If I understood it right, the method to compute the hash from the pattern is implementation-dependent. Does this mean that the android source code doesn't contain any, even a default one? It seems to be the case, given what I've read from source.android.com. So, who is in charge to implement it? Each phone manufacturer?
According to Nikolay's explanation, and a physical dump of a Wiko Lenny 3 phone, I've extracted device_policies.xml to get the pattern length, and gatekeeper.pattern.key file, which should contains the hash. However, using the python code snippet didn't allow me to compute the hash from the pattern. Well, I'm not really surprised if this implementation can be overridden...
If anyone has additionnal informations to share, I'll be pleased!
PS: Sorry, I can't post links for the moment!
I'm building an application that requires the use of the depth sensor on my Samsung Galaxy A80. However it seems like it's impossible to access it through Camera2 and ARCore. I asked Samsung directly and the tech support guys best guess was that Samsung has locked it from being used by third parties.
I rooted my phone and started digging through the file system and eventually found a file called 'com.samsung.sensor.imx316.so' located in /vendor/lib/camera (imx316 is the depth sensor). There are also some similar files that ends in '.bin', but .so files seems to be runnable code if I understood the google results correctly.
That file has the same name as the sensor I can't seem to access. Can this file be used somehow? Can I run it in my own app to get access to the depth data? And if not, there should be a way of getting that data right? I mean, it obviously exists somewhere in the phone since pre-installed apps are using it, and a rooted phone has access to everything?
Did you check REQUEST_AVAILABLE_CAPABILITIES_DEPTH_OUTPUT? How do you know it's impossible?
Most likely you need to reverse engineer the Camera app from your phone.
Your app can call com.samsung.sensor.imx316.so , it's really "just" a linux elf library.
The problem you face is the exported routines from the library, you won't really know
1) the parameters to the functions inside the library
2) any specific order to call functions inside the library i.e. like an init function first , release memory last...
You need to disassemble / reverse engineer the library to make some sense of it (see ghidra / radare2/ ida pro etc ).
Use strace on the current process/app which uses the library to make some sense of the order of calls into the library.
The depth data will be coming from a kernel level driver, you can likely obtain the Samsung kernel source and the driver source should be there. Then it's up to you whether you can make user space library/code to read what the driver exposes. The kernel driver source code will have an uapi header file to investigate.
idk if it helps but i used for a Huawei P30 Pro this https://github.com/Nufflee/tof-camera