[Q] Custom encoder?

[UnKn0wnBooof]

Another question! I pretty much hate the idea of using Java to use the encoder, sure it's multi platform but it doesn't support many platforms. I think it would be better if the encoder was written in C so that it can be compiled for pretty much any OS and architecture. I want to be able to compile it to run on android via the Terminal Emulator application.

The only way to accomplish this (at least in my opinion) is to have the encoder as a single standalone binary that doesn't need 3rd party requirements.

So, is this possible? Does anyone have the knowledge to pull this off? Or does anyone have any better ideas to make this dream become a reality?

Thanks.

Edited September 7, 2014 by Lavanoid

[MB60893]

OK. Firstly for you to be able to run the encoder on an Android device, you would need to modify the code to comply with the Android Architecture. By default android is actually Java-based, so you can develop the encoder in a similar way, only you would need to modify the application to work with Android.

As for multiple platforms, well, I think Java is closest to C in the respect that it is supported by so many operating systems. I know what you mean, though. Java is tragically slow in comparison, as it is partially interpreted as well as compiled. If it was compiled, it would be much quicker (while the notice to us mere mortals would be very small) and I believe a C compiled version would be much better as well. I don't do C code specifically, but I know it would be much better.

Good Luck.

[UnKn0wnBooof]

OK. Firstly for you to be able to run the encoder on an Android device, you would need to modify the code to comply with the Android Architecture. By default android is actually Java-based, so you can develop the encoder in a similar way, only you would need to modify the application to work with Android.

As for multiple platforms, well, I think Java is closest to C in the respect that it is supported by so many operating systems. I know what you mean, though. Java is tragically slow in comparison, as it is partially interpreted as well as compiled. If it was compiled, it would be much quicker (while the notice to us mere mortals would be very small) and I believe a C compiled version would be much better as well. I don't do C code specifically, but I know it would be much better.

Good Luck.

Actually, think about it a little more deeply. Yes - Android is mostly Java, but don't forget that it's also Linux. If your device is rooted, you can place a binary in /system/xbin then just chmod it. This will allow you to run it from the Terminal Emulator. Look at Busybox for Android, I highly doupt it's written in Java. I think that to compile a binary for Android, you will need the NDK (or was it the ADK?) since it provides the ability to compile binaries for a device.

On the other hand, as long as a compiler knows what architecture to compile for (such as Arm 7 Neon, for example), it should work.

I don't want a program written in Java. If a duck encoder was written as a Java app for Android, you'd have a activity, a GUI etc. A CLI is most preferred. The dsploit team have managed to get the metasploit framework (msf) running on Android, which is mostly written in Ruby.

I agree with you about the "Java vs C", Java's speed is noticeable in some cases, such as the fact that Java isn't quick enough to relay high volume's of traffic so it tends to drop packets. If you haven't checked out dsploits github repository, I highly recommend that you do. The issue in the repository named "Dsploit Core?" goes into detail about this stuff.

Back on topic however, still would be great if someone ports the encoder to C. I think Androids fastboot utility is written in C and someone on xda developer's managed to compile it for Android so we were able to use fastboot in conjunction with USB OTG to flash other devices through the terminal emulator program.

I do think it is possible to compile C as a binary for Android.

Thank you for the response :)

Edited September 7, 2014 by Lavanoid

[MB60893]

Actually, think about it a little more deeply. Yes - Android is mostly Java, but don't forget that it's also Linux. If your device is rooted, you can place a binary in /system/xbin then just chmod it. This will allow you to run it from the Terminal Emulator. Look at Busybox for Android, I highly doupt it's written in Java. I think that to compile a binary for Android, you will need the NDK (or was it the ADK?) since it provides the ability to compile binaries for a device.

On the other hand, as long as a compiler knows what architecture to compile for (such as Arm 7 Neon, for example), it should work.

I don't want a program written in Java. If a duck encoder was written as a Java app for Android, you'd have a activity, a GUI etc. A CLI is most preferred. The dsploit team have managed to get the metasploit framework (msf) running on Android, which is mostly written in Ruby.

I agree with you about the "Java vs C", Java's speed is noticeable in some cases, such as the fact that Java isn't quick enough to relay high volume's of traffic so it tends to drop packets. If you haven't checked out dsploits github repository, I highly recommend that you do. The issue in the repository named "Dsploit Core?" goes into detail about this stuff.

Back on topic however, still would be great if someone ports the encoder to C. I think Androids fastboot utility is written in C and someone on xda developer's managed to compile it for Android so we were able to use fastboot in conjunction with USB OTG to flash other devices through the terminal emulator program.

I do think it is possible to compile C as a binary for Android.

Thank you for the response :)

No problems. I see what you mean about Android, and I wasn't aware about Metasploit being on Android. I guess because of this there should be a way to port the duckencoder. I don't know much C, but if I was to go and create a duckencoder, I'd want to make sure I could first write to the SD card, maybe using an SD card adapter with the OTG adapter... I don't know otherwise. Play around and you will eventually get something I'm sure!

All the best, Lavanoid.

MB60893.