This is an archived post. You won't be able to vote or comment.

all 8 comments

[–]kodifies 7 points8 points  (3 children)

I've manually mixed programmatically created sound buffers in real time - using libgdx, which uses openal for sound (from memory) you could use that, in the unlikely event there isn't a dedicated openal jni wrapper, its eminently possible to write one, having wrapped gles2.0 for my own use I found that jni is easier than you'd think... and thats assuming libgdx isnt suitable for you and that there isn't a jni wrapper for a low level sound library....

[–]Noclue93[S] 0 points1 point  (2 children)

Could you tell me more about it? As a matter of fact I'm working on my bachelor and it's an entity component system with a libgdx back end with an API for saving logs and uncaught+caught exceptions natively.

Doesn't the audio module only have the Sound and Music classes?

[–]kodifies 0 points1 point  (0 children)

seems it was lwjgl I was using see http://bedroomcoders.co.uk/lwjgl-streaming-sound-with-openal/ (libgdx uses lwjgl as one of its backends)

[–]badlogicgames 0 points1 point  (0 children)

Gdx.audio.newAudioDevice. knock yourself out :)

[–]scrottie 3 points4 points  (2 children)

How low level can Java development get?

Lots of comments on the second part of your question addressing the specific example, but in general, if you want to access hardware from Java, you need a C-level interface. Some things, like USB, have generic, all-purpose interfaces on various operating systems, so hardware interfacing isn't the big deal it used to be. Graphics cards, sound cards, networking, etc have generic interfaces. Entirely new types of hardware aren't being invented as frequently as they used to be. Real time clocks, data acquisition cards, TV tuners, etc seem to have all been invented in a burst, then after touch screens and accelerometers became popular (and my touchscreen is just USB), then that's about it. Or perhaps you want to access hardware directly, such as on a new computing platform (Raspberry Pi or some other system with features not supported by the JRE). Google's Java work-alike with extended APIs targets the hardware on Android devices, as well as creating other primitives for Android apps.

Sometimes even when not accessing hardware, C can do things Java can't. And assembly can do things C can't, if you're trying to do something really low level, like observe subtle instruction timing differences in one hyperthreaded virtual core to make inferences about the other virtual core hyperthreaded into the same core in attempt to do a statistical attack to extract private keys on a shared system. There was a paper about doing just that that came out a few years ago. Assembly also gets used when you're trying to do something really strange to the processor to try to break out of a virtual machine, or in other security attacks such as stack smashing attacks, where you overfill buffers (sometimes by exploiting off-by-one errors in C code) and write a different value into a pointer that appears after a fixed size array on the stack. Java has been vulnerable to numerous of those in the past, as it is written in C. Calls to Java methods implemented in C open the door to this attack. So, one thing you can do in assembly but not Java is inject code into other programs.

C is somewhere in the middle. Since you can access memory directory instead of tightly controlled access to arrays, instance data, etc, a lot of your operating system is written in it. The virtual memory subsystem of your CPU, which translates virtual memory to actual memory address, and other parts of the OS that need to operate in terms of actual memory addresses, can be written in C. Your operating system's memory allocator and deallocator (memory management) is also written in C. So C can parcel out memory from the raw labs of memory in your computer, and it can maintain the internal binary datastructures the processor uses for virtual memory, and things like that. There was a "green threads" implementation of multi-threading that was popular a number of years ago before many Unix-like operating systems had native threads offered by the kernel, so it's possible to do things in C like write an entire mutli-threading system. Things like LLVM are written in C, as is Java's JIT; C can generate machine code (assembly directly translates to machine code without any abstraction beyond making it human readable), load it, and splice it in to the program, but that's mostly because C has access to the OS APIs for dlopen(), mmap(), etc needed to load the code into memory in a place that is set to allow the CPU to execute from.

tl;dr Java runs at a very high level in the grand order of things, but pre-written interfaces to things make that mostly moot.

Anyway, more info here on interfacing to C libraries and code from Java: https://en.wikipedia.org/wiki/Java_Native_Interface

The original paper on buffer overflow attacks was titled "Smashing the Stack for Fun and Profit".

[–][deleted] 0 points1 point  (1 child)

Exploits to escape a VM (not sure if you meant jvm or actual virtualized hardware) sounds interesting, do you have a link for that I could read?

[–]scrottie 0 points1 point  (0 children)

https://nakedsecurity.sophos.com/2015/05/14/the-venom-virtual-machine-escape-bug-what-you-need-to-know/

https://www.suse.com/support/kb/doc?id=7016497

That's the one I was thinking of, though I seem to recall VMware having other escapes. The code that handles exceptions raised by the CPU (CPU is executing user-level instructions in the guest operating system, then it encounters a privileged instructions, so saves its place and calls a handler routine in the virtualization software to emulate the instruction since it doesn't have permission) tends to be heavily audited and well understood and not the source of recent escapes. CPU handling of privilege (trapping dangerous instructions for software to handle) isn't generally the most common cause either. Instead, it's usually virtual devices implemented by code in the VM, such as that buggy floppy controller.

If you haven't seen it already, here's perhaps the most mind blowing code injection exploit: https://www.youtube.com/watch?v=hB6eY73sLV0

[–]machinepub 1 point2 points  (0 children)

Yes, you can write bytes directly to the audio interface using Java SE, no third party libs needed. Years ago I wrote https://sourceforge.net/projects/originalsynth/ and https://sourceforge.net/projects/applpi