So let me start of by saying I am new to Objective-C and pretty much all of my experience has been in very high-level languages like javascript and ruby so learning it has been tough and I know there are a lot of concepts I don't have a good grasp on.
I am currently building a cordova plugin to be able to integrate the MagTek eDynamo reader into cordova IOS apps. My plugin is based largely off of this plugin and I have been using the existing code along with the Magtek SDK Documentation/(the sample code in the SDK) to work my way through updating the plugin.
Now to my problem: Every time I call the openDevice function I am getting the error in the title. [corebluetooth] XPC connection invalid. I have looked this up and have gotten pretty confused by other answers on stack overflow and some blogs I found discussing the error. From what I understand it is thrown when there are multiple instances of CBCentralManager, or when it is referenced as a local variable instead of a strong reference to the class. To be honest I think this is where my lack of experience with objective-c and mid/lower level languages in general is really hurting me because I don't really understand these answers and from what I thought the SDK files and functions were taking care of the interaction with core bluetooth so I'm not really sure what I am doing to cause problems with core bluetooth at all.
I have been stuck on this for over a week now and I really don't know what to try next.
Thank you in advance for any insight and I am willing to provide any more code or logs that might be helpful although all of the code for the plugin is in this Github repo.
In https://github.com/kevinjung2/CardReaderPlugin/tree/ios-branch there is not a single reference to "XPC connection invalid".
In foundation there is a XPC connection invalid error from Cocoa framework.
https://developer.apple.com/documentation/foundation/cocoaerror/2293178-xpcconnectioninvalid/
In the lack of more information I'm guessing that your driver are not updated to what the Cocoa framework are expecting for open a connection.
MAYBE, and this is just a guess... Apple changed something in their API that needs to be updated in the driver.
On the repository provided there is a https://github.com/eGood/CardReaderPlugin/blob/master/src/ios/libMTSCRA.a file that is not open for change and further investigation with easy. Pehaps the needed-to-update-function that provides metadata to open a connection to bluetooth are created there. And, in this case, there is nothing to do unless ask for the Magtek to update their driver.
EDIT: Have you tried what the manufacturer said in section 3.3.2... they have a test app. Try to connect with theirs... if it works, then you know is something wrong in your app, but if theirs didn't work either. Is most likely my hypothesis above.
Working from the tutorials I wanted to try PID-controlling a second order linear system. I'm running into segfaults when simulating the closed loop. I've put my code over on Gist. It is mostly identical to the example in the dynamical systems tutorial.
Here's what works
Simulating a diagram containing only the second order system
Dropping in PendulumPlant for the second order system and using the controller
Every step up to simulator.AdvanceTo - that's where the segfault occurs
I'm sure I am missing something obvious here. Does anyone with more experience see what's wrong?
Thanks for reporting this. I didn't see anything on quick inspection. I ran your code (both on linux and mac) and was able to reproduce. Absolutely you should never see a silent segfault, so this is a real issue.
I've escalated it here: https://github.com/RobotLocomotion/drake/issues/12497
FTR - I've also opened a PR to improve the PidController documentation. https://github.com/robotlocomotion/drake/pull/12496
I'm investigating this now -- I've also successfully reproduced the bug locally using the provided python, but I've also reproduced it directly in C++. [Reproduced in now defunct branch]
I'll update when I have something concrete.
Update 1: You've got an algebraic loop in these two systems (one that does not exist for the PendulumPlant as its derivatives and output are expressed in terms of its state and not its inputs). In this case, both systems' outputs depend directly on their inputs so, kablooie! The bug, in this case, is figuring out why that isn't communicated to you right up front.
Presumably, you'd also like to know what the right version of this program is that doesn't have an algebraic loop. Stay tuned.
Final update
A patch has gone through to correct the underlying bug. Depending on how you're accessing Drake, it's immediately available in master, or you can wait for the next binary (as to your taste).
Thanks for bringing this issue to our attention.
from one of the stackexchange questions Here,its proved that we can decompile the iphone application to its source,Now here comes the question how can we protect the ipa file/iphone application from cracking to its source?i have already verified this answers
here 1
method 2
but sad thing is it fails to protect the code,any updates to prevent app to source code
You can't really.
The iOS runtime on the device needs to be able to interpret the binary, so the binary has to be there, unencrypted and ready to run.
You could obfuscate it, by running it through a tool that scrambles method names, property names and so on. .NET and Java have tools that do this but I'm not aware of any for Objective-C, so I think you're on your own.
(Tools like anticrack, the one you linked to, will work for a short time until someone comes up with a way to reverse what anticrack does - but because your app eventually has to be there in a format the runtime is ready to run, all you can do is make it more difficult. It's like the age-old arms race of pirates vs protection mechanism in desktop applications).
This has been much discussed. Generally, you make more money spending time improving or promoting your app, then spending time trying to prevent it from being cracked in any way.
This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
Delphi 64-bit Preview Compiler available?
Hello!
I know this message will annoy some people, but anyway...
Does anybody know if something is going on with 64bit Delphi?
Does Embarcadero or anybody else developing compiler for 64 bit computers?
Can we expect something in near future?
I looked arround and found very different information, but it would be good to know
to be prepared when everybody will start using 64 bit computers.
Any information will be much appreciated.
Petra.
If you're willing to give up dependence on the VCL, FPC and Lazarus can build 64-bit code.
The official statement for 64-Bit is here: http://edn.embarcadero.com/article/39174
In short: 64-Bit requires many changes to the compiler and they are working on it.
Officially, information about future editions of Delphi and C++ Builder is presented in "Roadmaps". The latest Roadmap can be found here:
http://edn.embarcadero.com/article/39934
This is a slide from the presentation:
(source: embarcadero.com)
"64 bit computers" run current 32bit Delphi executables just fine.
Some people need 64bit executables to access more memory and/or to write drivers, but in my opinion most people don't need 64bit Delphi.
As Andreas pointed out, the most recent word is that they're planning on having a 64-bit compiler in the next preview. With so much to be done, I wouldn't be surprised if the beta cycle for it started real soon, maybe even before the new year.
Keep checking the forums and the Embarcadero blogs (DelphiFeeds.com is a good place to keep abreast of all the news) and you'll probably hear about it starting soon enough. Sign up for the beta and you'll get a chance to test out the 64-bit Delphi system and provide feedback that may even shape the development of the product.
I've seen it happen reasonably often: I write an application in Delphi and when I compile it, the virus-scanner tells me that I've created a virus and then immediately deletes the executable again. It's annoying but reasonable easy to fix by doing a full rebuild, deleting the *.dcu files first and sometimes by simply waiting.
It happens with Delphi 6, 7, 2005 and 2007, as far as I know. And Symantec, Kaspersky, McAfee and NOD32 have all been guilty of reporting these false positives. I know it's because Delphi adds timestamps to its DCU files and these timestamps end up in the final executable and apparently appear to be part of some random virus signature.
I don't want to disable the virus-scanner, not even for a single folder or file. And I'm not really for a solution, but am wondering about the following:
Do these false positives also occur with other compilers?
Does it also happen with .NET executables?
Do others also notice similar problems with Delphi?
Do these false positives also occur
with other compilers?
Yes, this is has been a common problem in the past for AutoIt as addressed in this forum post "Are my AutoIt EXEs really infected?". In most cases including AutoIt it stems from poor heuristic practices. Since AutoIt uses the free and open UPX compressor, it is often mistaken for malicious code that also uses UPX.
The best (and possibly only) thing you can do is report these mistakes, so they can refine their heuristics or at least white list your app.
Below is a list of contact information for some popular anti-virus companies. They all claim to appreciate submissions as it helps them make their product better.
AntiVir - Contact
A2 (A-Squared) - Contact (email address)
Avast! - Contact
AVG - Contact
BitDefender - Contact
BullGuard - Contact
CA Anti-Virus - Contact
ClamAV - Contact
ClamWin - Contact
Comodo - Contact
ESET's Nod32 - Contact
eSafe - Contact (login required)
Fortinet - Contact
F-PROT - Contact
F-Secure - Contact
G-Data - Contact
Kaspersky - Contact
McAfee - Contact (email address)
Norman - Contact (email address)
Panda Anti-Virus - Contact
Sophos - Contact
Symantec (Norton) - Contact
Vipre - Contact
Windows Live OneCare - Contact
ZoneLabs - Contact
Turns out there is a great list of AV software on wikipedia, called 'List of antivirus software'. It is more complete than my list above.
A member of the Autoit Forums made a great script to e-mail a false positive to a huge list of AV vendors to automate this process a bit.
Sounds more like a heuristic screw-up to me. Do you have heuristics turned on (some scanners may refer to it as "virus-like code")? The chances that time stamps would equate to "a portion of some virus signature" seems too small to be happening all the time.
When I used to run a virus scanner, I never saw this problem with D6 or D7.
There is indeed Delphi virus in the wild, see http://www.sophos.com/blogs/sophoslabs/?p=6117
Yes, my team has experienced this maybe half a dozen times in 2-3 years with Sophos in a corporate environment. So, very rarely, but it does happen.
Our IT cretin started off demanding I review all the 1.5M lines of code in our app to "make it go away", but he didn't get too far pursuing that line...
To be fair, he was initially concerned that our clients might also receive such a warning, but we've only ever seen it triggered when building an exe from the IDE on a developer's PC, never on a release build exe on a test box or elsewhere.
Personally, it happens so rarely we don't worry about it.
I've had it happen to me with deployed code. The next update to the scanner solved the problem. Some cretin wrote a virus using the same compiler and the signature was part of the runtime library, not actually in the hostile code.
This is not that uncommon when using non-standard compilers or when doing fancy low-level stuff: I remember creating false positives when I dabbled in OS-development: AntiVir didn't like some of my flat binaries.
Recently, there's been a post about such a problem at the tinyCC mailing list regading AVG.
I've never seen this, having done lots of C++ and .NET development with Visual Studio (from version 1.5 to 2010).
I've only seen this happen with assemblers. For example, MASM32 actually warns people that it might trigger virus scanners since the EXEs are so small (and/or some viruses are written in assembly). My McAfee scanner flagged some of the example programs as viruses.
This should only happen for virus scanners that have a "looks suspicious" analysis mode.
In some apps, if I use RtlVclOptimize.pas, the Avira antivirus tell that I have created a virus.
plus to what others'v said, modern anti-virus programs rise virus-alert if your programs uses some "suspicious" APIs too ( like URLdownloadFile or other API hooking related ones).
if you google "delphi RAT FUD API undetectable" you'll find many interesting topics .
Some antivirus programs even flag a batch file as a virus and can't be convinced that it isn't. Quite annoying, if that file is part of a third party library and the virus warning is triggered every time TortoiseSVN checks it out. I ended up disabling the virus scanner, deleting the file and doing a commit. (Without disabling the scanner, I could not even do that :-( )
If you have problems with false positives, there is VirusTotal online service that can help you check your file against number of antivirus engines.
It's free service and currently it can run antivirus check with almost 40 antivirus engines.
A couple of years back, everytime we updated the GNU Linker from mingw sources and started distributing it with our compiler, we got some reports that virusscanners classified ld.exe as virus. (.exes writing .exes ...)
I would not call it a "false positive", because, strictly speaking, it is not false and the antivirus software is not "guilty" of anything in any way.
I am 99% sure, that this is the heuristic analysis acting up (I bet it detects your executable as something along the lines of win32.virus.generic - note the generic, this is a sign, that this is not in its signature db, but rather was detected by the heuristics) and, with being heuristic and all, it does not give you any kind of guarantee, that whatever it finds is malicious, it just kind of makes it known to you, that the executable is suspicious from its point of view.
The easiest solution to this would be just adding an exception for your file by name (it is always the same name, correct?). If you are uncomfortable with this, you should, probably, make your antivirus software prompt you before taking action so you can make it skip your file manually.
In general, I've found coding in windows with antivirus software somewhat irritating (don't do it much nowadays, but still), especially if the said software is in "paranoid mode". Irritating as it is, though, it is unavoidable (IMO).
I remember another weird one:
A file was being flagged as suspect. The only thing is the file was an .OBJ! An .EXE that contained the code the .OBJ contained wasn't considered a problem.
It happened to me too. Hooking keyboard will trigger almost any heuristic scanning AV software to report a key logger. There are probably many other system calls which will trigger it too.
Solution - try to redesign your code or contact the AV manufacturer to include your software into exception list.
VS Platform toolset 2010 renders my simple program to be detected as virus.
Changing the toolset to VS 2013 solves it.
It just creates a HttpWebRequest and writes the result to a file.