Jump to content

Mefistotelis

Members
  • Content Count

    75
  • Joined

  • Last visited

  • Days Won

    2

Mefistotelis last won the day on May 31

Mefistotelis had the most liked content!

Community Reputation

11

About Mefistotelis

  • Rank
    Very Active

LabVIEW Information

  • Version
    LabVIEW 7.0
  • Since
    1986

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Yes. "&lt;" and "&gt;" are just symbols used to allow storage in XML; these are so-called HTML Entities. So this string really is "<vilib>". No idea. There are more tags which can be used, but I never cared for listing them, or checking whether they're all hard-coded. EDIT: Reading @Rolf Kalbermatter answer above, I see he already answered this.
  2. Yes. Extract your file, and paths will be in XML. "LVPath" is actually a class, which is instantiated for many things. So all paths basically have the same structure. I export it to XML as list of strings - this is how it is really stored. Elements in the list are either normal strings, or tags which LV replaces with value from current config. Example: <LIvi> <!-- LinkObj Refs for VI --> <Section Index="0" Format="inline"> <LVIN Unk1="NI_InternetTK_Common_VIs.lvlib:Close Calling VI's Windows.vi" Unk2=""> <!-- VI To Lib Object Ref --> <VILB LinkSaveFlag="2"> <LinkSaveQualName /> <LinkSavePathRef Ident="PTH0" TpVal="0"> <String>&lt;vilib&gt;</String> <String>addons</String> <String>internet</String> <String>NI_InternetTK_Common_VIs.lvlib</String> </LinkSavePathRef> </VILB> </LVIN> </Section> </LIvi>
  3. Thanks @Rolf Kalbermatter, did proper update. Watcom actually had Windows extender, separate to the DOS extender. Also, interesting prediction. Personally, I think Apple overestimates scalability of their phone silicon. But we'll see.
  4. What you want is to flush your output file occasionally. File writes are buffered, and performed only when enough data has gathered, or the file is being closed. In C, flushing is done by fflush(); for LV - someone else will have to answer.
  5. Thank you! That added some important info to my list: https://github.com/mefistotelis/pylabview/blob/master/LVcode.py#L224 A little below the arch list, there's getVICodeProcName() function where I added mangled names for the dispatch table items which I got from LV for MacOS. Pylabview will now, upon extraction of a VI file, create a MAP file with offsets and names of known symbols within the executable bytecode.
  6. Do we have a full list of these architectures somewhere? I've seen: 'i386', 'wx64', 'ux86', 'ux64', 'm386', 'mx64', 'PWNT', 'axwn', 'axlx', 'axdu', 'ARM ' (those are all little endians) I'm not exactly sure what each of these means. Are different OSes counted as separate architectures?
  7. I just did. Wow. Now I know I was missing a lot by ignoring Apple. At least from this perspective. Not a single function name is missing, and all names are decorated with types.
  8. Yes, that's the table. Surprisingly, it's not just written directly as an array, but instead there's an init function which fills it. Sounds a bit unnecessary. And introduces possible security issues. I hope the function is verified before execution, and executed later than when the VI is opened. Otherwise the ease of modification might be an issue. Besides modifying it, you may just want to look at it, to either debug an issue within LV, or just check how the code works. With the declarations and all structs defined, you could also turn the VI code into COFF; that would make it easier to disasseble, or write a wrapper which executes it. That's the same code you can look at in "Heap Peek", but there you get symbols and labels instead of specific offsets. CINs - I don't know much about these ATM, didn't looked into LabWindows at all. Interesting hint. Thanks.
  9. Do we have declarations of these callbacks? Ie. here's one: void __cdecl _InitCodePtrsProc(struct VICodePtrsRec **viCodePtrs); Just to explain what I'm talking about: * VI files and other RSRC files, can contain compiled code stored in VICD resource * VICD consists of the actual assembly, and list of 'patches'; these patches combine function of imports table and relocation table * The actual assembly always has a InitCodePtrsProc() function, which sole purpose is to fill an array of code pointers which it receives as parameter * The code pointers are just references to other functions which exist in the assembly; there are up to 30 such callbacks * executing a VI file means just calling these callbacks, in proper order It's not that hard to figure out the parameters of these callbacks, I'm just wondering if we already have that information. Here's example init function for a very simple VI: void __cdecl _InitCodePtrsProc(struct VICodePtrsRec **viCodePtrs) { struct VICodePtrsRec *ptr; _VINormalInitCProcsHelper(viCodePtrs); // Imported routine, pointed in list of patches ptr = *viCodePtrs; *((_DWORD *)ptr + 5) = _InitProc; *((_DWORD *)ptr + 25) = _CodeDebugProc; *((_DWORD *)ptr + 26) = _CodeErrHandlingProc; *((_DWORD *)ptr + 30) = _RunProc; *((_DWORD *)ptr + 28) = _InitCodePtrsProc; }
  10. The options are actually in two places: some are in the LV executable, but most are in RSC files within LV folder. The executable you can open with any RE tool, like Ghidra, or Ida Pro. You could also use 'strings' command to list all text chunks from executable, and guess which of these are ini options. The RSC file you can extract using pylabview, and then you get a list of tokens in XML form, ie. there's part of lvapp.xml: <Section Index="11400" Name="ConfigTokenStrings" Int5="0x00000000" Format="inline"> <String>tmpdir</String> <String>defaultdir</String> <String>viSearchPath</String> <String>panel.background</String> <String>diagram.background</String> <String>diagram.primColor</String> <String>menubar.foreground</String> <String>menubar.background</String> <String>menu.foreground</String> <String>menu.background</String> <String>execPalette.foreground</String> <String>execPalette.background</String> <String>cursor.foreground</String> <String>cursor.background</String> <String>appFont</String> <String>systemFont</String> <String>trackTimeout</String> <String>defPrecision</String> <String>flushDrawing</String> <String>formulaBoxPrecision</String> <String>sparcV8</String> <String>windowSize</String> <String>LVdebugKeys</String> <String>useDebugOutput</String> ... In case of the specific key discussed in this thread: # strings LabVIEW.exe | grep SuperSecretListboxStuff SuperSecretListboxStuff Btw, I remember someone from NI suggesting that there is a hidden option, not visible in the simple strings list. That is not true, at least in LV14. Yes, I checked.
  11. The worst, but really really rare case, would be for the tool to create damaged binary. But I'm doing a lot of checks to avoid that. And you already stumbled upon some of the checks: The tool does a lot of checks and raises exceptions if anything looks out of the ordinary. The exceptions are then captured and the block which raised them is exported as a binary file, without trying to make it XML. In case of VICD you'll actually always see this, as I didn't published parsing of the data. This means the VICD will just always stay as binary. If you want to be sure the data is identical to source, just go with: ./readRSRC.py -vv -x -i ./lv10/vi.lib/dex/DexPropertyNode.vi ./readRSRC.py -vv -c -m ./DexPropertyNode.xml cmp -l ./lv10/vi.lib/dex/DexPropertyNode.vi ./DexPropertyNode.vi In other words - export the file, then re-create the binary without changes, and compare both binaries. The tool checks whether it can re-create the checksum from your file - after all, it always tries to re-create identical data after export and import. Brute-force scan will happen only on damaged files - where the checksum doesn't match using the usual algorithm. The tool then assumes the issue is in salt. If the tool can't figure out how to re-create the salt used for password, it will export the salt into XML, and won't re-compute it when re-creating binary (unless you modify the XML to re-enable auto-computation). The tool will re-create everything correctly, if only you will modify it in exported form. I could add an option which would make it assume the input file is damaged, and skip that scan. Well, you could use the same code which handles "change password", only replace password work with your fun. But the way to rename blocks using my work model is: 1. Export VI to XML 2. Change the tag name in XML, for example replace "<CLIv>" and "</CLIv>" with "<LIvi>" and "</LIvi>". 3. Re-build the VI from XML Yes, block idents are just the tag names; they are only a bit modified to meet XML standard, ie. "#" are replaced by "sh" and "\0" codes are just skipped; but the tool will re-create the 4-char ident from tag name during import. I see. Yeah, there's no way around that.
  12. Well, that's really against what I want to achieve.. my idea is to extract everything to XML and allow users to do all the modifications in XML form. Then you can easily re-create the VI. Note that the re-created VI will, in most cases, be identical to the original (there are few exceptions, as LV uses multiple threads to save the file and is generating names section in pseudo-random order as a result, and in older versions of LV even the section data is ordered randomly). The password option is the only exception to that rule, and I'm thinking about removing it completely. It's untested anyway, so I'm not even sure if it works. For the in-place modifications, you'd have to modify the tool, and make the modifications you want through Python code. All the known checksums are re-calculated when importing from XML. These checksums are not even put into XML, as they're just derivative values which can be re-created. The XML import of a single file takes seconds. Currently I'm testing everything on _all_ RSRC files from 4 versions of LV (6.0, 7.0 10.0 and 14.0), that's over 41 000 of files. Exporting and then importing all of these files takes less than 24 hours. That means export+import of one file takes on average 2 seconds. Did you tried 'Cheat Engine'? It's a tool for cheating in games, which basically means - a tool to edit memory of application. Exactly what you want. And it has a great ability to "find pointer chain" - it allows locating pointers to dynamically allocated memory. If the issue you have is dynamic allocations, and not variable shift within allocated blocks, that might be useful.
  13. @dadreamer if you're often looking at the binary data, you might have some use of "print-map" function of my readRSRC script: ./readRSRC.py --print-map=RSRC -x -i 'test_out/lv10/vi.lib/Utility/Convert RTD Reading (waveform).vi' test_out/lv10/vi.lib/Utility/Convert RTD Reading (waveform).vi: Warning: Block b'PRT ' section 0 size is 152 and does not match parsed size 128 test_out/lv10/vi.lib/Utility/Convert RTD Reading (waveform).vi: Warning: Block b'VICD' section 0 XML export exception: The block is only partially exported as XML. 00000000: RSRCHeader[0] (size:32) 00000020: BlockData (size:13559) 00000020: BlockSectionData[LVSR,0] (size:140) 000000AC: BlockSectionData[RTSG,0] (size:20) 000000C0: BlockSectionData[OBSG,0] (size:20) 000000D4: BlockSectionData[CCSG,0] (size:20) 000000E8: BlockSectionData[LIvi,0] (size:52) 000000EC: Block[LIvi,0].LinkObject[0].NextLinkInfo (size:2) 000000EE: Block[LIvi,0].LinkObject[0].Ident (size:4) 000000F2: Block[LIvi,0].LinkObject[0].Unk1 (size:34) 00000114: Block[LIvi,0].LinkObject[0].Unk2 (size:2) 0000011A: Block[LIvi,0].LinkObject[1].NextLinkInfo (size:2) 0000011C: BlockSectionData[CONP,0] (size:6) 00000124: BlockSectionData[TM80,0] (size:64) 00000164: BlockSectionData[DFDS,0] (size:388) 000002E8: BlockSectionData[LIds,0] (size:52) [...] 00003A44: BlockSectionStart[VCTP,0] (size:20) 00003A58: BlockSectionStart[FTAB,128] (size:20) 00003A6C: NameStrings (size:34) 00003A6C: NameOfSection[LVSR,0] (size:34) When you use "--print-map=RSRC" it prints what is stored at which offset of the RSRC file. Obviously it can't print compressed data this way, so for compressed sections you can map the specific section, ie. "--print-map=DFDS". And to get BIN file which matches this mapping, you can extract the VI with "-d" instead of "-x" - then you will get uncompressed BIN files for all sections, instead of some being converted to XML.
  14. You can edit that wiki if you have more info. or write your comments in "Discussion" page if you're unsure about editing it directly. I created a whole category of articles there: https://labviewwiki.org/wiki/Category:LabVIEW_internals
  15. Well, looks like it's something more than graphics switch. New bugs! I wonder how many "expected" errors happened in the meantime.
×
×
  • Create New...

Important Information

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