Jump to content

All Activity

This stream auto-updates     

  1. Today
  2. I have done this for VIP, and Zip packages for an installer I've had on the back burner for a while.
  3. How about creating the initial handle in LabVIEW (e.g. an empty string), passing it into the DLL as a handle, then calling DSSetHandleSize()?
  4. The reverse engineering isn’t the driver of trustzone and similar. The driver is the threat of untrustworthy code being distributed by malicious authors. We need a chain of trust back to the original code author in all cases.
  5. Speaking as a 19-year dev in LabVIEW R&D, Hooovaaah is pretty much right. NI wouldn’t do anything to change our EXE format because of this work. None of the current design is viewed as a security layer. We’ve talked about secure computing initiatives in R&D. NI will probably lag the curve there (NI tends to adopt tech when it is already commodity), but I suspect it’ll happen this decade. I very much hope the world gets there soon. Unsigned EXEs are a major threat vector, and the IOT threat just keeps increasing. The world can’t afford to keep running arbitrary code much longer, in my opinion.
  6. Yesterday
  7. I already have that superpower I once used lots of letters so that if you read the for loops top to bottom the letters spelt out my name and a message. I also once heard that wether you use "a" or "i" depends on if you came from a mathematical or engineering background. What's really stange (for me) is in C and PHP; I use "i". But in Pascal, and Python ; I use "a". I know that to a certain extent it is muscle memory since if I use "i" in Pascal, I nearly always leave out the colon before the equal sign. Maybe it's a coping mechanism because I switch between languages so much.
  8. That's probably why I gave up on C++ years ago already. If I have to program something that requires anything on low level, I prefer simple old standard C. Sure nobody will build a software like LabVIEW in C anymore but that is not my target anyways.
  9. I wonder if someone had an opportunity to extract points of interest from randomly scattered laser data available as 3d point cloud? I have plotted it successfully using scatter plot. But I want to take measurements on curvature. For instance, for a 3d point cloud data for 'Human Arm', I wish to be able to measure distance between finger tips and elbow. When posing to measure biceps size, I need to measure angle between elbow and shoulder. I have read we could create mathematical model for one axis in terms of other two axis i.e. Z = a + bx + cy + dx2 .... But model might not define angles, slopes, height that I want to analyse on Arm. Random scatteredness of data provides limited options to use standard slope equations to achieve these measurements. Data is scattered everywhere on arrays. I have managed to achieve some measurements but it was after fully sorting the 3 million point array ( for each axis - x,y,z) and then just treating whole sets of data as arrays and using standard arrays functions i.e. max/min, mean etc. I am not sure if I am heading in the right direction with taking measurements from 3d point cloud data. So I wanted to find how experts here at LAVA would do. Any ideas?
  10. I see that ambiguous wording got a strong reaction. Yes, the format is not broken/cracked currently. I actually only found two readers for VIs, both quite rudimentary: one in Python, other in PHP. I am typically sharing everything I can share. For the specific subject discussed in this thread, see here: https://github.com/mefistotelis/pylabview/commit/867dac8e2f249978defa380110efb744ff52c650 Currently, yes. Though we already have certificates fused into out CPUs, ie. for Protected Audio Video Playback. And there is a lot more of them. On ARM, we recently see explosion of TrustZone use. Same principle - protect the code but allow its execution. I do hope the world will not go this way; but currently, as tools for reversing get better, the push towards protecting them by hardware also increases.
  11. Sounds like a good idea if your goal is to get other programmers to hate you.
  12. The application in question - would it otherwise behave smoothly with the 900 MB file, if it was able to load it, or would it become so sluggish that it would not make any sense to load that much data anyhow (i.e. the technical issue might just be of technical interest...)? Why do you not just put a limit on the file size you will load? You can always get a handle on how much a file of x megabytes typically takes when loaded, and calculate your suggested limit based on that -. either alone or combined with a reading of the available memory. If the file is above the limit and the processing permits it, you could offer the user to decimate the data or extract a subsection of it. You can also allow the user to proceed with the full file, but at least you have given him a warning.. If a crash will erase previous work the user might opt out...and if not, it will not look as bad when it does crash.
  13. It is not. They will not. As stated this is how all programs work. You cannot keep the executable safe, while also having it be open enough to execute it. I do hope you share anything you discover with the community, I just expect what you will discover is that reversing a binary of any kind to its source will take forever, be error prone, will be incomplete, and won't be very useful. This will especially be true for LabVIEW as the tools for this disassembly are less mature than other languages.
  14. That was my first thought too 😆. But!!!! The Call Library Node only allows for Void, Numeric and String return types and the String is restricted to C String Pointer and Pascal String Pointer. The String Handle type is not selectable. -> Bummer! And the logic with the two MoveBlock functions to tell the array in the handle what size it actually has, needs to be done anyway. Otherways the handle might be resized automatically by LabVIEW at various places when passing through Array nodes for instance, such as the Replace Array Subset node. Also Replace Array Subset would not copy data into an array beyond the indicated array size too. Handle size and array size are not strictly coupled beyond the obvious requirement handle size >= dimensions * sizeof(int32) + array size * array element size
  15. Been there. Done that. Wouldn't a DSNewHandle suffice?
  16. Nope, sorry. Still, trying to get information if a memory allocation might succeed by looking at whatever memory statistics might be available can never be a foolproof approach. It has the classical race that between checking if you can and doing it, the statistics might be not actual anymore and you still fail. The only fool proof approach is to actually do the allocation and deal with the failure of it. Of course for memory allocations that is always tricky as seen here. We want to read in a 900MB file and want to be sure we can read it in. Checking if we can and then trying can still fail. We have to allocate the entire buffer beforehand and then copy piece by piece the file into this buffer. Another approach might be a memory mapped file but trying to trick LabVIEW build in functions to use such a beast is an entire exercise in its own. You basically invert the complete execution flow from calling a function that returns some data, to first preparing a buffer and hand it to a function to use it to eventually return that data. If you ever have dealt with streams (in Java, or .Net which has not only taken the whole stream concept verbatim from Java) you will know this problem. It's super handy and normally quite easy but internally quite complex. And you always end up with two distinct types that can't be easily connected without some intermediate proxy, Input Streams and Output Streams. And such a proxy will always involve copying data from one stream to the other, adding significant overhead to the originally very simple and seemingly beautiful idea. Now, one solution in hindsight that would be beneficial in the OPs case would be if those LabVIEW low level functions would return an error 2 or so in these cases rather than throw up a dialog that gives you only the option to quit, crash or puke. With the current almost everywhere present error cluster and its consisten handling throughout LabVIEW, this would seem the logical choice. Back when LabVIEW was invented however, error clusters were not even thought of yet and error handling from things like out of memory conditions was anyhow an end of story condition in almost all cases, since once that happened LabVIEW would almost surely run into other out of memory conditions when trying to handle the previous error conditions. When LabVIEW for Windows came out, most users found 8MB of memory an outragous expensive requirement and were insisting that LabVIEW should be able to fly to the moon and back with the 4MB it was claiming to work with in the marketing material.
  17. There is DSMaxMem and DSMemStats which aren't much use. Do you have any info on DSMemStatsSlow and DSMemStats2?
  18. There is nothing broken! It's the nature of the beast that the CPU needs to be able to read the machine instructions in order to execute them. If the CPU can anyone else can too unless you execute on special security enhanced CPU engines where the code is encrypted and only decypted inside the CPU itself with no external access to that decrypted code. Such hardware is however VERY specialized and VERY expensive and VERY unusual. Good luck in your attempts but there are a lot more intersting and beneficial things to do with your time than "breaking" LabVIEW VIs. Especially since it is not breaking but simply piecing together all kinds of information that has to be present in various ways in order to be even functional. If LabVIEW VIs were broken in that context, every single Windows, Linux, Mac and whatever executable and shared library would be broken too. And especially the much loved .Net assemblies! Reverse engineering them is even with obfuscation a piece of cake. Stil tedious, sure, but much easier than trying to reverse engineer a LabVIEW executable from getting all the VIs out and disassembling every machine code stream for each VI and figuring out the linker information to piece those disassembly streams correctly together.
  19. It depends what you want to do with the memory and how but in principle it is pretty easy. This function will simply return error 2 when the allocation was not successful. The challenge is to use this allocated buffer with built in LabVIEW functions. Depending on what functions you may want to use this with, you could for instance pass in the buffer in a VI in which you read the binary file in chunks and copy each chunck into this buffer with the Array Replace Subset function. Memory management is a bitch and you have to often choose between preallocating memory and passing it all the way down a call chain hierarchy to use it there or to let the low level functions attempt to do it and pass the result up through the Call Chain. LabVIEW chooses for the latter and that has good reasons. The first is a lot more complicated to implement and use and has generally less performance since you tend to copy data twice or more (when using streams for instance which at each data direction inversion will usually involve a data copy). Allocate Array Buffer.vi
  20. I contributed a GZIP compress/decompress function on the NI forums many years ago. That function used a MemoryStream instead of a file. I added the .NET reflection functionality from above to the original decompress VI based on a MemoryStream. https://forums.ni.com/t5/Example-Programs/GZIP-compress-uncompress-of-string-using-NET/ta-p/3507908
  21. Yes, you might be right @Rolf Kalbermatter. As long as the whole work can be divided into steps, this might be doable though. For example - there is probably a way to tell labview to compile the assembly. So only disassembling the code, still puts us one step closer, and allows us to create buildable project. Right now, I already can replace single VIs and re-build the project. Having ASM blocks would allow me to replace only single blocks inside VIs. For the people who fear for their code being stolen - if the current solution is broken, NI will put resources into making "real" security in next version - so such reversing effort actually makes the tool more secure, and forces it to move to modern standards. I'd have to learn about LabView in general to go any deeper; last time I made a project with it was circa 20 years ago. Not sure if I have enough time to go that way.
  22. The special math functions like "Create Special Matrix" can do it; they return an error code -20001 ("Analysis: (Hex 0xFFFFB1DF) There is not enough memory to perform the specified routine.") if you try and create a too-large matrix. They do their work in a dll, and this might be the way I would have to go.
  23. I have not. Last I faced a similar case a few years ago (on a 32-bit Windows), after some discussion with the users we agreed to check the file size before loading it and if it was larger than 400Mb the soft would reject the load request with a nice message telling the user to use another soft that would split the large file in several 400Mb files.
  24. I have application where the User provides files from another program, which are typically 10 Mb, but with no real limit on their size. One User managed to generate a 900+ Mb file and caused an out-of-memory condition which caused my app to fail. Rather than the annoying "Out of memory" dialog that pops up, I would much rather get a standard error that I can handle (by telling the User that file is too big to load and then returning to normal operation). So I have been trying to think of a way to attempt to allocate a very large string with a graceful way to fail if there is not enough memory. Has anyone else found a way to do this?
  25. Did this today (and any other day I write C). for (int i=0; i < len; i++){ The big question is .. should it have been "a" instead of "i"?
  26. That brings me back to my time learning BASIC programming on my VIC-20 (in the early 80s).
  27. Last week
  28. I think you answered your own question there and used the two term method that I described. This is exactly why I said:
  1. Load more activity
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.