wireless debugging android 11 android studio

 The Android 11 developer preview introduced a slew of new and exciting features, including 5G support, scoped storage, enhanced privacy and security, and more. Wireless debugging is one of my favorite features. It's a new way to deploy and debug your app without leaving your computer.



Requirements :

  • The device running with Android 11 or above
  • SDK platform-tools with version ≥ 30.0.0.
  • Same Wi-Fi network for Android device and your PC\Laptop

Wireless debugging



Wireless debugging : 

So it requires Two steps - 
  1. Pair your Device
  2. Connect your device

Android Debug Bridge allows you to deploy and debug your app wirelessly from your workstation (adb). You can, for example, deploy your debuggable programme to several remote devices without having to physically connect your device via USB and deal with complications like driver installation.
To use wireless debugging, you must use a pairing code to connect your device to your desktop. Your device and workstation must both be connected to the same wireless network. Follow these steps to connect to your device: Pairing Instructions:

-Go to the device Settings > Developer Options > Enable Wireless debugging

-Select Pair device with pairing code. (Currently, there are two options to pair it with your computer. Using a QR code or pairing a device using a six-digit code.), here talking about with code only.

Pairing Device



  1. On your workstation, update to the latest version of the SDK Platform-Tools.
  2. On the device, enable developer options.
  3. Enable the Wireless debugging option.
  4. On the dialog that asks Allow wireless debugging on this network?, click Allow.
  5. Select Pair device with pairing code. Take note of the pairing code, IP address, and port number displayed on the device (see the above image).
  6. On your workstation, open a terminal and navigate to android_sdk/platform-tools.
  7. Run adb pair ipaddr:port. Use the IP address and port number from step 5.
  8. When prompted, enter the pairing code that you received in step 5. A message should indicate that your device has been successfully paired.
   Enter pairing code: 482924
Successfully paired to 192.168.1.130:37099 [guid=adb-235XY]
  1. (For Linux or Microsoft Windows only) Run adb connect ipaddr:port. Use the IP address and port under Wireless debugging (see image below).

Wireless debugging




And Finally, if all is good you will see your device in your android studio.

You can also connect the android device with android studio with the help of a plugin check the below link -👇👇👇

That's all about this post.
Thanks for being here.

**************************************
****************************
*****************

How to retrieve specific node from firebase database in android based on value

 Sometimes it is needed to retrieve the node based on a value, not the child.

Android+Firebase


you may get some solution like - to get all the nodes first and after that iterate it locally.

Explaining below - 

Let's assume the requirement is to retrieve all the node that has been mobile number = 9999999999.

Structure of the node - 

Firebase Node

The first approach (Not Recommended) - 


In this approach, you will get all the nodes and then you have to iterate to get the required record.

inline number 15-17 i'm iterating all the nodes and removing  the nodes from the list which has the different mobile number

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
private void readAllRequestedFormFromFirebaseDb(){
        final FirebaseDatabase database = FirebaseDatabase.getInstance();
        DatabaseReference ref = database.getReference("App_DB");
        DatabaseReference childRef = ref.child("AllRequest");
        childRef.addListenerForSingleValueEvent(new ValueEventListener() {
            @Override
            public void onDataChange(@NonNull DataSnapshot snapshot) {

                // getting list 
                for(DataSnapshot dataSnapshot: snapshot.getChildren()){
                    QueryFormModel post = dataSnapshot.getValue(QueryFormModel.class);
                    queryFormModelArrayList.add(post);

                }
                for(int i=0;i<queryFormModelArrayList.size();i++){
                    if(!queryFormModelArrayList.get(i).getMobileNumber().equalsIgnoreCase("9999999999"))
                        queryFormModelArrayList.remove(i);
                }
            }
            @Override
            public void onCancelled(@NonNull DatabaseError databaseError) {
                Log.e("DetailsActivity", "onCancelled:readAllSubmittedRequestFromFirebaseDb:  "+databaseError );
            }
        });
    }
   

Why this approach is not recommended -?

Just assume if you have 1000 records so in this case, you are getting all the nodes first and after that iterating all the nodes to get what exactly the requirement is.
so in short you are doing irrelevant effort and unnecessary extending the network call.
even though it's correct but it will put a question mark on your programming skills.

The second approach (Recommended) - 

In this approach instead of getting all the nodes, you will get only the nodes that have been the mobile number that you passed.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
private void readAllRequestedFormFromFirebaseDb(){
        final FirebaseDatabase database = FirebaseDatabase.getInstance();
        DatabaseReference ref = database.getReference("App_DB");
        DatabaseReference childRef = ref.child("AllRequest");
        Query queryRef = childRef.orderByChild("mobileNumber").equalTo("9999999999");
        queryRef.addListenerForSingleValueEvent(new ValueEventListener() {
            @Override
            public void onDataChange(@NonNull DataSnapshot snapshot) {

                // getting list
                for(DataSnapshot dataSnapshot: snapshot.getChildren()){
                    QueryFormModel post = dataSnapshot.getValue(QueryFormModel.class);
                    queryFormModelArrayList.add(post);
                    /*the above list will have record only
                     with the provided mobile number*/

                }

            }
            @Override
            public void onCancelled(@NonNull DatabaseError databaseError) {
                Log.e("DetailsActivity", "onCancelled:readAllSubmittedRequestFromFirebaseDb:  "+databaseError );
            }
        });
    }
   


That all about this post.👍👍👍

Happy Coding.😍
**********************************************
*************************************************
****************************************************

Log4j Vulnerability

Summary of the Vulnerability


On Dec. 9, 2021, a remote code execution (RCE) vulnerability in Apache log4j 2 was recognized as being taken advantage of in nature. Public proof of concept (PoC) code was delivered and the resulting examination uncovered that double-dealing was unbelievably simple to perform. By presenting a uniquely created solicitation to a weak framework, contingent upon how the framework is designed, an aggressor can teach that framework to download and consequently execute a malicious payload. Because of the disclosure of this adventure being so later, there are as yet numerous servers, both on-premises and inside cloud conditions, that presently can't seem to be fixed. In the same way, as other high seriousness RCE takes advantage of, hitherto, enormous checking movement for CVE-2021-44228 has started on the web with the aim of searching out and taking advantage of unpatched frameworks. We enthusiastically prescribe that associations move up to the most recent rendition (2.16.0) of Apache log4j 2 for all frameworks. This form additionally fixes the less extreme vulnerability CVE-2021-45046, found on Dec. 14.




Log4j vulnerability

Vulnerability Known As Log4j vulnerability, Log4Shell
CVEs Discussed CVE-2021-44228, CVE-2021-45046, CVE-2017-5645, CVE-2019-17571
Types of Vulnerabilities Remote code execution, denial of service

Affected Version

Apache Log4j 2.x <= 2.15.0-rc1

Affected Major Software 

Countless Java-based applications are utilizing log4j as their logging utility and are powerless against this CVE. As far as we could possibly know, essentially the following software might be affected:

  • Apache Struts
  • Apache Solr
  • Apache Druid
  • Apache Flink
  • ElasticSearch
  • Flume
  • Apache Dubbo
  • Logstash
  • Kafka

Background of Apache log4j2

Apache log4j 2 is an open-source Java-based logging system, which is utilized inside various Java applications all over the planet. Contrasted and the first log4j 1.X delivery, log4j 2 resolved issues with the past discharge and offered a module design for clients. On Aug. 5, 2015, log4j 2 turned into the standard rendition, and all of the past form log4j clients were prescribed to move up to log4j 2. Apache log4j 2 is broadly utilized in numerous well-known programming applications, like Apache Struts, ElasticSearch, Redis, Kafka, and others.

While providing a simple and adaptable client experience, Apache log4j 2 has generally been defenseless against the process and deserialize client inputs. Two past deserialization weaknesses, CVE-2017-5645 and CVE-2019-17571, were recently found, bringing about code infusion and further RCE because of an absence of essential handling against gave client input information.
Spring-Boot-starter-log4j2.

  • CVE-2017-5645: For Apache log4j 2.x before 2.8.2, the log4j servers will deserialize any log events received from other applications through TCP or UDP socket servers. If a crafted binary payload is being sent using this vulnerability, it can lead to arbitrary code execution.
  • CVE-2019-17571: For Apache log4j versions from 1.2 (up to 1.2.17), the SocketServer class is vulnerable to deserialization of untrusted data, which leads to remote code execution if combined with a deserialization gadget.

Description of the Vulnerability (CVE-2021-44228)

The Apache log4j library takes into account engineers to log different information inside their applications. In specific conditions, the information being logged starts from client input. Should this client input contain unique characters and be consequently logged inside the setting of log4j, the Java strategy query will, at last, be called to execute the client characterized far off Java class in the LDAP server. This will thus prompt RCE on the casualty server that utilizes the helpless log4j 2 examples.

Underlying Case Analysis

Assuming we investigate, we find that log4j 2.x backings a mechanism called lookups, which is generally used to set up the log4j config deftly for clients. The authority presentation about Lookups is as per the following:

Queries give a method for adding qualities to the log4j setup at self-assertive spots. They are a specific sort of Plugin that carries out the StrLookup interface.

The ordinary client can advantageously and deftly add esteems to the setup at discretionary spots with the predesigned design by utilizing this element. Exhaustively, when calling the log strategy in the application, log4j 2.x will call the configuration technique to really look at the particular characters ${ in each log.

Should these characters be available, the Java technique query will be called to track down strings later the characters ${ and afterward supplant the articulation later the characters ${ with the genuine worth found previously. For instance, when calling the log work in the application to log the substance displayed in Figure 1, the strings java:runtime, java:vm, and java:os later the characters ${ will be considered as the boundary of the query strategy lastly supplanted with the comparing esteems, like Java(TM) SE Runtime Environment (assemble 1.7.0_67-b01) from Oracle Corporation, Java HotSpot(TM) 64-Bit Server VM (fabricate 24.65-b04, blended mode, and Windows 7 6.1 Service Pack 1, design: amd64-64.

1 -Java lookup example


There are several types of lookup upheld by the feature lookups, like Jndi Lookup, JVM Input Arguments Lookup (JMX), and Web Lookup. The Jndi query permits factors to be recovered by JNDI. In the Jndi Lookup, a few conventions are upheld to make the distant query, like LDAP and RMI. Assuming the log incorporates the strings displayed in Figure 2, the Java strategy query will be called to find the string jndi:logging/setting name.

2 -Legitimate JNDI lookup string


By considering the log content is usually exposed to users and can be easily controlled by the attacker in many applications very easily, once the attacker controls the string as shown in Figure 3 and sets a malicious Java class on an attacker-controlled LDAP server, the lookup method will be used to execute the malicious Java class on the remote LDAP server.

3 -Malicious JNDI lookup string with LDAP



The log4j library is a powerfully strong and trusted log framework with very flexible features supported. However, convenient features often involve potential security issues at the same time. Without careful user input filtering and strict input data sanitization, blind trust in user input may lead to severe security issues.

Exploit Analysis

Exploit Code for the CVE-2021-44228 vulnerability has been made publicly available in no time. Any user input or logs hosted by a Java application using the vulnerable version of log4j 2.x may be exposed to this attack very easily, depending on how logging is implemented within the Java application.


Fix and Bypass: Fix Added for CVE-2021-45046

With the authority Apache fix being delivered, 2.15.0-rc1 was at first answered to have fixed the CVE-2021-44228 vulnerability. In any case, an ensuing detour was found. A recently delivered 2.15.0-rc2 adaptation was thus delivered, which secures clients against this vulnerability.

On Dec. 14, it was found that the fix delivered in Log4j 2.15.0 was inadequate. CVE-2021-45046 was doled out for the new weakness found. Per our fundamental investigation, the impact of this vulnerability is the denial of service (DoS) however not full remote code execution. This vulnerability is less serious than CVE-2021-44228, yet clients should refresh Log4j to variant 2.16.0 to fix this vulnerability.

What Next - 

The CVE-2021-44228 vulnerability is as yet being effectively researched to appropriately recognize the full scope severity. Given the data as of now accessible, this vulnerability might have a high effect as of now and later on. Most of the applications being affected are widely used in corporate networks as well as home networks. Clients are urged to do whatever it may take to guarantee they are ensured against this vulnerability, as illustrated underneath.