All reviews of published articles are made public. This includes manuscript files, peer review comments, author rebuttals and revised materials. Note: This was optional for articles submitted before 13 February 2023.
Peer reviewers are encouraged (but not required) to provide their names to the authors when submitting their peer review. If they agree to provide their name, then their personal profile page will reflect a public acknowledgment that they performed a review (even if the article is rejected). If the article is accepted, then reviewers who provided their name will be associated with the article itself.
All the details have been corrected in the current version of the manuscript.
[# PeerJ Staff Note - this decision was reviewed and approved by Sedat Akleylek, a PeerJ Section Editor covering this Section #]
Thank you very much for all the information on the answer document. Nevertheless, the train/test split (70/30) that is mentioned there is not properly explained in the manuscript.
Please, take into account that the experimental setup of the paper must be as accurate as possible and in the current version does not fit with the explanation of the answer document.
There are inconsistencies between the source code, the README file and the description on the paper. Please, check carefully whether CV or train/split is used, hyperparameter tuning, etc.
Moreover, the upload of the source code to a public repository is advisable.
Dear authors,
The manuscript has improved significantly since the first version, nevertheless there are still a couple of problems related with the experimentation:
- It is neither complete nor well-presented: the source code must be uploaded to a public repository (Github for example) with a README that contains all the instructions to be reproducible.
- The source code uploaded to the platform is not enough for running the experiments.
Take this into account, science must be public and reproducible.
Moreover, read again the manuscript since there are still some minor typos in it.
Regards,
Clear and unambiguous contents and grammar is used throughout the manuscript.
Yes
All underlying data have been provided; they are robust, statistically sound and controlled.
Recheck on flow and English grammar mistakes.
The authors have adequately addressed my concerns. The manuscript is suitable for publication pending minor polishing of the writing.
No further comments
No further comments
Please take carefully into account the reviewers comments before the next submission. In case the reviewers consider major decision after the next round of revision, the paper could be rejected.
The paper "JDroid: Android Malware Detection Using Hybrid Opcode Feature Vector" discusses an interesting and relevant topic in Android security. The proposed hybrid feature vector approach is novel and addresses key challenges in malware detection. However, the paper requires some improvements before being considered for publication.
Main Concerns:
Computational Cost Analysis – While the hybrid feature vector improves accuracy, it may also increase computational complexity. A runtime analysis comparing JDroid with traditional methods (e.g., N-gram, API-call-based detection) would be beneficial to assess its efficiency.
Related Work Expansion – The related work section is comprehensive but could benefit from more discussion on recent advancements in malware detection methods. The authors are encouraged to consider and discuss the following relevant studies:
DOI: 10.1016/j.asoc.2022.109756
DOI: 10.1109/ACCESS.2023.3296789
DOI: 10.1109/ACCESS.2024.3354699
Practical Deployment Considerations – It is recommended to discuss how JDroid could be deployed in real-world malware detection systems. Addressing integration challenges, real-time detection feasibility, and potential deployment strategies would enhance the practical impact of the study.
Comparison with Deep Learning Models – The study lacks a direct comparison with deep learning-based malware detection methods (e.g., CNN-based classifiers). Including such a benchmark would provide a more comprehensive evaluation of JDroid’s performance against state-of-the-art methods.
Feature Selection Justification – The authors use ExtraTree for feature selection but do not justify why it was preferred over other methods like mutual information or LASSO regression. A brief comparison of feature selection techniques would improve clarity.
Dataset Bias and Cross-Validation – The paper should explicitly state if stratified sampling was used to balance malware families. Additionally, clarification is needed on whether cross-validation was performed across datasets or within each dataset separately to ensure fairness and avoid data leakage.
Language and Clarity – The manuscript is generally well-written but contains minor grammatical errors and awkward sentence structures. A thorough language revision is recommended to improve readability and clarity.
Please take into account carefully the reviewers' suggestions, specially those related to the experimentation and the explanation of the proposed method.
[# PeerJ Staff Note: It is PeerJ policy that additional references suggested during the peer-review process should *only* be included if the authors are in agreement that they are relevant and useful #]
No comment
The experimental scenario are very nicely articulaed.
Good work
**PeerJ Staff Note:** It is PeerJ policy that additional references suggested during the peer-review process should only be included if the authors are in agreement that they are relevant and useful.
Lack of clarity in sentences and most of the manuscript is written ambiguously. Authors are suggested to use clear and unambiguous, professional english in their manuscript.
Authors have not clearly explained thier methodology and feature engineering in Section 3.
The proposed methodology itself more ambiguous. So the results cannot be assessed.
Authors have addressed clear contributioons in introduction section. Literature review effectively conducted and given a good summary of related works. But authors have failed to explain the proposed method, feature engineering and feature selection in their work.
The authors developed JDroid, an Android malware detection approach using a hybrid opcode feature vector. The work is promising but requires some revisions:
1- The introduction section needs to be improved, particularly by emphasizing the motivation and novelty of the study. The current introduction does not clearly highlight why this research is important or how it advances the field of Android malware detection.
2- The related work section can be extended to include recent techniques for malware detection.
3- The paper does not sufficiently elaborate on how the combination of Dalvik opcode and Java Byte code in the hybrid feature vector improves detection performance, particularly in handling obfuscated or polymorphic malware.
4- The results section would benefit from the addition of statistical analysis to demonstrate the significance of the findings. Currently, the results are presented without sufficient statistical validation.
5- The conclusion section should be revised to better summarize the key contributions of the study and highlight its potential impact.
Overall okay. 3- The paper does not sufficiently elaborate on how the combination of Dalvik opcode and Java Byte code in the hybrid feature vector improves detection performance, particularly in handling obfuscated or polymorphic malware.
The results section would benefit from the addition of statistical analysis to demonstrate the significance of the findings. Currently, the results are presented without sufficient statistical validation
All text and materials provided via this peer-review history page are made available under a Creative Commons Attribution License, which permits unrestricted use, distribution, and reproduction in any medium, provided the original author and source are credited.