Database Info

[Q] is /dev/bus/usb/* Standard in Android

I have an ePad (Android 2.1) that mounts usb devices in the normal Linux way so that I can use libusb to access them, I have managed to control my usb robot arm using an NDK app. Before I move onto making it a proper app instead of a hack job I wanted to know if the usb device files are standard to Android or if it's specific to my system.
Put it this way, if I make a nice cuddly app is it going to fail on most devices or work on most devices? (ones with USB OTG interface)
Sorry, I understand this could be a 'how long is a piece of string' type of question.
Many thanks,
Richard e Collins.

After a few hours of routing about on the internet I found an article on an exploit on the init daemon, google "android-root-source-code-looking-at-the-c-skills". This gave enough insight for me to deduce that this functionality I am getting is present on at least anything running 2.1 and above and is not a customisation unique to my device.

[Q] Imaging the File System

I am working on a project at working concerning the HTC Touch Pro (Fuze) running 6.1. We are looking to take a forensic image of the device from the file system up. Our traditional software for imaging other types of drives (hard, flash, etc.) can only see the existing files on the device. We want to be able to perform a full acquisition.
I know this is possible on Android devices, I've spent a lot of time doing it. On Android devices I am able to use Android SDK/ADB to copy the mmcblk files from the device to the host computer.
I have the Windows SDK in Visual Studio. Is there something similar to ADB for Windows? I basically just need a command-line interface with which to communicate with the phone.
Any information would be appreciated!

mpercy725 said:
I am working on a project at working concerning the HTC Touch Pro (Fuze) running 6.1. We are looking to take a forensic image of the device from the file system up. Our traditional software for imaging other types of drives (hard, flash, etc.) can only see the existing files on the device. We want to be able to perform a full acquisition.
I know this is possible on Android devices, I've spent a lot of time doing it. On Android devices I am able to use Android SDK/ADB to copy the mmcblk files from the device to the host computer.
I have the Windows SDK in Visual Studio. Is there something similar to ADB for Windows? I basically just need a command-line interface with which to communicate with the phone.
Any information would be appreciated!
Click to expand...
Click to collapse
I think MobilMon can monitor file system activity and allowing them to keep a log on device

Zune Driver for ARM to allow USB phone connection

Hi Folks.
With both a Zune HD and WP7 devices not supported via USB conenction to a Surface RT, I was thinking there had to be a way to tweak/re-write the ZuneHD / Zune driver files to allow them to be installed on the Surface RT...The ZuneHD is an ARM based device running Windows Embedded - and RT is an evolution of Windows CE you might say.
If so, the earlier regedit hack to allow the WP7 (or ZuneHD) to connect as a USB mass storage device would hopefully be possible, without the full ARM recompile of the Zune software (a near impossible task).
It's ridiculous that pre WP8 devices cannot even be connected via USB to facilitate file transfers "non-cloud" way.....
I tried manually updating drivers on the Surface RT with my ZuneHD connected - pointing at the Zune 4.7 drivers, and it confirmed that they were not ARM compatible.
Cheers,
Sheeds.

...
"tweak/re-write" an x86 kernel-mode driver into an ARM kernel mode driver for installation on a platform that doesn't (currently) permit unsigned drivers at all? You act like you have some idea what an instruction set architecture is, but you say this. If I ran this entire message through a translator to Finnish and then ROT-13'd it, you'd probably have a better chance of understanding the post than of managing to get the existing x86 Zune driver working on RT without a full re-write plus an additional hack to bypass driver signing. The Zune driver isn't exactly open-source... binary emulation *might* work at some point, but it's not practical for a kernel-mode driver (signature checks or not).
There is not, and never was, a hack to allow Zune-like devices to connect using UMS. The hack you're referring to merely un-hid the MTPZ (Media Transfer Protocol, Zune) devices from Windows Explorer. MTP(Z or not) and UMS are not at all the same thing, although they can sometimes be used for some of the same purposes.
We'd have a much better chance of getting Zune to run on RT, actually. That's "just" a matter of emulating an x64 machine for it to run on and passing its system calls through to the real OS and back again. Won't do any good for this use case without the driver, of course.
What does it matter that RT and CE run on the same ISA? The driver that we need is x86/x64 only.
There is basically nothing in common between CE and NT, aside from the fact that they're both portable operating systems from Microsoft and both implement some large portion of the Win32 API. Claiming that "RT is an evolution of Windows CE" is laughably wrong. They probably have less in common than Windows 95 (9x kernel, partially based on Win16 code) and Windows 8 (NT kernel, completely different project that contains no portions of DOS/Win16 except the re-implementation of the shell in NTVDM) - at least Win8 can run (many) Win95 apps. CE is at least as different from each of those as they are from eachother.
At this point, I'd guess that the most practical way to connect Zune on Windows RT would be the following:
a) Use a full x86-machine emulator (Bochs or QEMU, for example).
b) Use one that does JIT and/or dynamic recompilation, so the performance isn't abysmal (not sure what qualifies here...)
c) Install XP on it (no point targeting something newer).
d) Install Zune on the emulated XP.
e) Forward the tablet's USB port to the emulated machine's USB port (not sure if anybody has the ability to do this... currently, we can't even get networking in the emulated machine).
Good luck with that! I actually mean that quite seriously, I have a WP7 device myself and it annoys me that my Surface and it can't communicate except over Bluetooth (and I had to hack the phone to get that much).

GoodDayToDie said:
...
"tweak/re-write" an x86 kernel-mode driver into an ARM kernel mode driver for installation on a platform that doesn't (currently) permit unsigned drivers at all?QUOTE]
LOL - Thanks for the informative reply Luckily I have no delusions of grandeur over the fact that I am A) not a Developer and B) can't code past "hello world"
I was coming from the angle of the old registry hack for WP7 which allowed your phone to work as a USB mass storage file by a simple change via regedit to one of the registry strings associated to the Zune Driver....Certainly ignorant of the finer (and even the coarser) detail of your reply...so thanks for the explanation.
I added a MS Answers post asking why Microsoft cannot provide USB device connection for legacy WP7 and ZuneHD units with Windows RT. Be interesting to see what they or their MVP's reply to this, if at all.
Cheers.
Click to expand...
Click to collapse

Yeah.. asking MS to support the devices is definitely the best approach. We might manage to make a user-mode connection to them using some third-party software talking directly to the USB port on sufficiently hacked RT devices, but that's about the best we'll get.
Also, I really with people would stop calling it a "USB Mass Storage" hack. I've posted to that effect in the relevant forums that I can find, too. This is not now, never was, and (short of custom ROMs or special bootloader modes) never will be a UMS interface to Zune-like devices. The device literally doesn't support it. Please don't confuse Media Transfer Protocol for USB Mass Storage. They are *not* the same. For example, those nicely named music files you see when using the "UMS" hack for WP7/Zune? *THEY DO NOT EXIST* anywhere on the device's filesystem. True, there are files containing the same binary data, but they have names like "2D.mp3" and are stored in a filesystem structure designed to make referencing them in a database faster. MTP exposes a hierarchical storage system (which may, coincidentally, mirror the filesystem although it does not do so on Zune-like devices), but it does *NOT* expose the filesystem/storage (which is what UMS does).

[Program] Android 4.2 To Computers

You'd like to test the new android 4.2 but is no "money" to buy a smartphone supported? Well, this will no longer be a problem if you have a computer available. Android-x 86 design is based on the source code for Android 4.2, and basically works like a normal Android, with access to the Android Market, widgets and the like. Although the system work well and be focused for net/notebooks, there are some annoying limitations: applications compiled for ARM processor devices do not run, and not even available in the Android Market. If you want you will have to recompile packages. You can run the system via usb or livecd by pendrive, run on a virtual machine using virtualbox for example, or even install it on hd. To test Android-x 86 4.2, download ISO more suitable for your computer in this url: android-x86.org/download and burn to a CD (or USB stick). The distributed version is free, meaning you can test the system straight from the CD.

Some lay man's language.
Unable to understand bro
--------------------Signature--------------------
Don't Ever Forget to Hit Thanks It Boosts Me
Do Visit My Website For More Information

Scrcpy - Android Screen - Display & Control - Windows / Linux / Mac

There's a really cool light-weight tool that was developed by ROM1V to provide display and control of Android devices connected on USB. It does not require root access and does not require an application to be installed on the device! It works on GNU/Linux, Windows and MacOS.
It runs via ADB reverse.
I haven't seen anyone share this yet, so... here goes. Full credit to the author of this tool, ROM1V.
I've used this on both Linux and Windows variants. Both work quite well! There's a pre-built Windows package with all dependencies within the README. My experience is that Linux runs very smoothly, but the Windows variant is a little buggy.
Here is the link to the Github
(Sorry, I'm still *somewhat* of a new member and can't yet post external links... [been reading for years; posting... no so much]. I apologize, but you'll have to assemble this link a bit). Perhaps an admin might clean this up a bit.
github . com / Genymobile / scrcpy

This tool is GREAT!!! Mirrors your android screen on laptop over reverse ADB and without root and without installing anything on the device.
I used it on mobile which had its display totally non-functional but touch was working. Fortunately, ADB was enabled. All I had to do was unzip scrcpy files from https://github.com/Genymobile/scrcpy and refer to the FAQ at https://github.com/Genymobile/scrcpy/blob/master/FAQ.md. I could recover all my data from the device and even use the device seeing it screen and controlling it from my laptop.
But obviously, use cases go much beyond that and this is a full fledged screen copying tool. If you use your android while at your desk and keep it connected to your laptop then this gives the comfort of using your keyboard for typing long messages as well. Videos also play smoothly on computer screen but voice comes from mobile speakers (...if there was a way to route that to the laptop speakers, that'll be great and make it almost like an HDMI connection to a laptop over USB!).
Great job done, developers @ https://www.genymobile.com/ :good::good::good::good::good:

rk2612 said:
This tool is GREAT!!! Mirrors your android screen on laptop over reverse ADB and without root and without installing anything on the device.
Click to expand...
Click to collapse
I agree.
And, in Android 12, there's no need to establish the initial connection over USB.
Android 12 has the Wi-Fi debugging option in Developer options!