CopperD

U-Fap - UnFuddle APplication (For automating UnFuddle backups) I-MAD - Interferometric Malfunction Analysis and Detection Small Rod Inspection System

I have already begun the slide into madness. I tore into DFIR and LLVM Sunday evening and monday morning. CallVIFromDll is not used by anyone in LabVIEW dir. I checked all the imports and found no one using it. I have the function prototype figured out. (Sorry I let that info at home) Normal applications and Dlls don't use this either. This function seems to be used only by .NET Dlls. I have the crazy idea of compiling a simple VI to dll so I can easily get the executable code then searching the IDE's memory space for same code. Once found I can put some breakpoints in the debugger and work backwards. The easy solution is to use RTSetCleanupProc to call my code which will handle cleanup based on info from a cluster.

This has nothing to do with RTSetCleanupProc() directly. When you call a vi by reference how does the caller know where the executable code is? CallVIFromDll looks like an interesting function name.

Looks like both of you are correct. If this works on abort then it will save me some trouble today. It can call my code which can handle the the more complex functions and ordering. Hmm has anyone figured out how to go from a vi refnum to an entry point for the function? If this can be figured out it will make it much easier for people to modify this. I have many different angles of attack here so I am very confident something will work out.

Thank you for this it looks like some good tidbits are in there. I would say it is slathered in marketing BS. Sadly marketing has stuck its fat ugly hand into LabVIEW very deeply and we'll need some sort of proctologist to remove it.

Someone who understands! For what I want to do I need to do more then just jump to the function pointer. I need to call it with the correct calling convention and pass arguments. When abort is called we need it to call some cleanup code that may have arguments that need sent. Idea scratch pad If you do not know the function pointer to the function you want to use for clean up you can use LoadLibrary to get the handle to the library then pass that to GetProcAddress with the name of the function you want called. This can be automated and is used for the generation of the import table in my PE Loader. The code for abort will take a pointer to a cluster that contains the number of cleanup entries and an array of cleanup entries. The clean up entries contain the function pointer and arguments to pass. Call each cleanup then return to the normal abort. Cleanup entry Function pointer, calling convention, number of parameters, array of parameters. To use, place VI that will check if inside IDE then inject code to run clean up. A pointer is given where we will put the pointer to our cleanup cluster. We are free to add and remove entries from this cluster during runtime. The user will remain unaware of these pointers so it remains easy to use. Simple vi that will add or remove functions to this list and update the arguments the developers wants to pass in.

This is turning into a very useful discussing. I will focus my efforts into the abort button. I knew sooner or later my craziness would become helpful.

The easiest way (Without using a wrapper dll) right now to handle a function pointer is to use CreateThread or ThThreadCreate. This creates a thread that might not return depending on what their code does. It would be nice if the developer can hit the abort button and all such threads are killed otherwise you need to end the primary thread.This is a non-issue on the compiled code and is just need to improve the experience inside the LabVIEW IDE. I been thinking of adding code to the abort button to kill these threads.

I view that as a personal challenge. I already learned from Chris that what I want exists but is not exposed. A lack of an export entry is a minor hurdle to overcome. I can generate signatures once I find what I am looking for so the code will keep working unless a major update is done. I need to dig around and figure out how large parts of the IDE work. This is why I suggested a place so I can put this information so no one else needs to repeat what I have done and can pick up where I leave off. When the user hits the abort button in the IDE I want the threads they created to be killed. If this does not occur it will lead to many headaches. I could setup some sort of heartbeat or use what is already built into the IDE. It sounds like you have some of this inside knowledge of how LabVIEW works.

I have been waiting for this "fundamental redesign" and it doesn't look like it's coming out this year.

I am starting to dig into the undocumented LabVIEW functions. I am sure some of us have little crumbs of information from NI and other have figured things out on our own. How can we round up this information so we don't keep repeating ourselves? Currently I am working on the thread management functions and how the IDE is notified of them so they can be aborted. At some point in time I saw a wiki but that seems to no longer exist.

Its great for showing 2d Arrays. I said X-Y intensity graph it's just called intensity graph. Just feed it a 2D array and the values in the array are shown as colors based on magnitude. Look at my mandelbrot explorer for the basics. Attached is another example I wrote for my RF Explorer (Handheld Spectrum Analyzer)

I display internally using the X-Y intensity graph (Limited to a 8-bit palette) Once I get what I like I apply filters and render to a png. I did these before I started using the vision toolkit for my job. Vision Toolkit makes angry Fred. Someone at NI decided when you create image spaces to give them string names to mask the pointers but let's still treat them as pointers. This part isn't bad until you realize any time you use an imaq image it does a linear search using string compare. This easily adds milliseconds to any vision function you wish to use. F&$(ING LAZY M$TH&R F%%#ERS! It's just one of many bugs you learn to work around with the Vision Toolkit.

My best friend runs the Large Scale Systems Museum in New Kensington, PA. I should have posted this last week when I received it but better late then never. If your in the area feel free to stop by. Most of you have heard of the Large Scale Systems Museum, a public museum in the Pittsburgh area that is focused on minicomputers, mainframes, and supercomputers. LSSM opened its doors to the public for the first time in October of 2015, coinciding with a city-wide festival. We have been doing tours by appointment since then, averaging 3-4 tours per month. On April 30th, there will be another such festival here in town, called "New Kensington Better Block". It's a large block party that will encompass much of the downtown area. There will be more than sixty street vendors offering food, handmade crafts from local artists, and just about everything else you can think of. There will be two stages' worth of live music, games, a beer garden featuring great brews from the historic Penn Brewery, lots of kids' activities like face-painting and caricature artists, drawings and raffles, the grand openings of three new businesses, and lots of other great stuff. Another star of the show, Pittsburgh-based C/PMuseum, as a guest of LSSM, will also be returning to Better Block with a special exhibit this time covering the history of the world's largest technology company, Apple Computer. From the humble beginnings of two friends named Steve, through today, Apple's 40th anniversary. See running examples of the actual machines that launched Apple in the 1970s and 1980s. In addition, the gaming wing of C/PMuseum will feature a display with running examples of game consoles from the earliest generations through the most modern 3D immersive virtual reality. Where else can you start out playing on a Magnavox Odyssey, and end up inside the VR world of an HTC Vive? The C/PMuseum pop-up at New Kensington Better Block, that's where! The LSSM will be participating in that event just as we did last October, by being open to the public all day. (I'm aware that this is very short notice; for that I apologize) Many of the Very Large Computers here will be running and demonstrated on a rotation throughout the day. Come and hack on DEC PDP-8, PDP-11, and VAX systems, IBM System/36s, and everything in between. See Cray supercomputers, DECsystem-20s, IBM System/370 and System/390 mainframes, and real rarities such as a Symbolics Lisp Machine, and minicomputers from the 1960s such as an HP 2116B (one of their first!) and a Varian 620-L. See a Heath H-1, a tube-based analog computer from 1956. See nearly all of the IBM "midrange" line. See how SSP, the operating system from the IBM System/36, can run in a virtual environment on an AS/400. See what an 800-pound hard drive looks like. All are invited! The LSSM is located at 924 4th Avenue, New Kensington, PA 15068, right in the middle of the block party area. New Kensington is about ten minutes' drive from the Allegheny Valley exit of the Pennsylvania Turnpike, Exit 48. It's a very easy area to reach, and there are a number of decent and inexpensive hotels nearby. I hope you can make it. Once again I apologize for the short notice. And of course if you cannot make it, feel free to contact the LSSM via email to info@lssmuseum.org or on Facebook (search for "Large Scale Systems Museum") to set up a visit at your leisure. You can also see some photos of our first big public opening on that page. Please feel free to forward this message to anyone whom you think might be interested. Thanks, -Dave McGuire President/Curator, LSSM

I don't know where else to hang out at. The NI forms feel uninviting. According to the April 2016 TIOBE index LabVIEW is in slot 37 just under RPG and up from 42 in July 2015.

These attractors show sensitive dependence on initial conditions so it shouldn't be to far of a stretch to call it inadvertently generated. Part of my collection of computer generated art I have done in LabVIEW.

I have been mostly away on vacation and loaded with work for the last month and a half. However some progress has been made. An update showing off some of this will be put up in the next week or two. PE Loader Progress Load and execute exe from memory if ImageBase does not conflict- 95% (FInishing up some debugging on the Import Directory) Load and execute exe from memory with conflicted ImageBase but has Relocation Table - (75% ) Load DLL from memory and call functions - (65% need to finish work with Relocation Table and add code to call DLL Entry Point) Load and execute exe from memory with conflicted ImageBase but has no Relocation Table - (20% I have only generated a Relocation Table by hand with the help of a disassembler) May need to attach the Titan or Bea Engine for disassembly. Load and inject exe from memory regardless of ImageBase as a new process - (60% This might raise some red flags - more of an experiment) Dynamic Function Calls Support for __stdcall __fastcall __cdecl (40% Little bit of bytecode that uses a pointer to cluster of the function prototype passed in from createThead to launch your function) Function Pointers Windows API createThread (100% IDE not aware of new threads - Wrapped so you can wait for thread to return or continue without waiting) LabVIEW API THThreadCreate (70% Decoded function prototype and can use it to call function pointers - Need to figure out how this is being used internally so IDE can be aware of the new threads) SmashCall (90% Works but needs some bytecode added to clean up the mess it creates - Another experiment) The above items are being used to support code generated by LibTCC and the embedding of LibTCC and its supporting files. I promise this all ties together and goes somewhere.

Don't forget the LabVIEW Home license and that targets the hacker crowd. I have reported the buffer overflow to NI. It is fairly minor so I don't think they will care but let's see. It is more of a neat trick for me. I'll guess I'll need to find a new way to load the EIP once they patch it. It's like eating my own foot. Maybe I'll get some commendation if I find enough exploits.

Academic license what makes you think that?

The function can be any executable code in program memory. To my knowledge this is the first buffer overflow attack against LabVIEW. It could be abused to run unauthorized code but I see this as rather unlikely. I did find several other buffer overflows that evening but none as easy to exploit for my purpose. (Not all buffer overflows lead to changing EIP) I just wanted a way to call a function pointer natively but now my curiosity has been peaked. A video would be a good idea. I do agree that this is useless for > 99.9% of LabVIEW developers. That why I posted it under the lounge. Yes you could call this a zero day exploit. If it was a RCE (Remote code Execution) I would have checked if NI actually monitors the security inbox. CERT only has 4 vulnerabilities listed for NI. It might be a good idea for the community to look into the security of LabVIEW. The part that is worrisome is that I only spend a few hours looking for this Sunday evening.

I have had no issues installing NI software back to 2012 on Win10. This includes vision and PXI. You dont normally need the pxi service. So far all the times I have seen a Win10 machine freeze has been due to bad hardware or drivers.

Now that I am no longer crazy busy at work I created my dream LabVIEW function. Call function pointer using no external libraries. I call this function smash call as it smashes the stack using a buffer overflow I found in VISA open. It currently is a one way trip as I didn't do anything to fix the stack. Attached are some pictures. It's going to be a part of the DCG library so I'll include it in my next update. I have the example calling command line but you can make it do whatever you want. If you want to use compiled code loaded from a string you will need to use VirtualProtect to set the page executable or disable DEP Data Execution Prevention.

I always copy and paste my vi descriptions into google and see what it thinks. This with a non-modal description editor would save a lot of time. Who would've thought that someone would like to look at the code while documenting it.

I really want this to turn your code from a nice solid block of steel into something with the constancy of runny applesauce. Feature Creep! PE32/+ Analysis Emulated PE32/+ loader (Why limit yourself to code you have source for?)​Performs memory allocations and base relocation Run exe applications internally Call dll functions internally I'll be posting this update sometime this week.

You'll never get a silky smooth pan once you start to zoom in so I didn't use the mouse drag. I was planning on having the scroll wheel for zoom but didn't put it in. If you're saving large images it takes much less overhead to use bmp. I was using the netpbm format internally for drawing gigapixel images. A nice popup box for saving so you can select the format and size would be a great addition. The other feature I removed was creating frames from a starting point to an ending point so you can create a movie. Optimizations Don't redraw known points Cardioid and Bulb Checking - Manly only good for low zoom. * In Buddhabrot generator Divergence check - Is a point a repeating pattern. *In Buddhabrot generator Border Tracing - If you can enclose an area with one color along the edge then the area insize must be the same color. Other Use BC or other arbitrary precision library once zoom reaches a certain level The Buddhabrot generator is distributed across several 64 core machines. I'll clean up the code and produce a standalone one for release.