Ethereum/smart contracts enthusiasts,
I want to execute some code which does not modify the state variables on my own Geth ETH-Node without deploying a contract. Is that somehow possible?
My current thoughts:
I have debugged the geth a little bit. I found by executing a view function the StaticCall is executed from the evm class. It seems at this point I can also inject some bytecode of my own view functions, without deploying it. From my understanding, a view function does not edit some state variables it only reads and returns them. This would mean I can technically do that, without destroying the chain. But this way of changing the code seems to be a little bit oversized, is there a simpler way?
Thanks.
It is not possible. You need EVM to execute the code. The EVM is an entirely isolated and sandboxed runtime environment. There are some key elements that are required by the execution environment to execute the code.
Deploying a contract is creating an instance of a contract. Then you interact with the contract instance
Related
I was looking at saving some data to my Room database and was reevaluating as there are some places in my repositories where I am extending AsyncTask (I'm still using Java) and wanted to check on the state of things to see if it was a good time to swap them out. I saw this reference in the Android developer site on Approaches to background work.
All persistent work: You should use WorkManager for all forms of
persistent work. Immediate impersistent work: You should use Kotlin
coroutines for immediate impersistent work. For Java programming
language users, see Threading on Android for recommended options.
Long-running and deferrable impersistent work: You should not use
long-running and deferrable impersistent work. You should instead
complete such tasks through persistent work using WorkManager.
I started using WorkManager for an API which needed to be called, but for which I could not rely on network connectivity. Because I'm using Room, which is persistent, it seems like I should be using WorkManager.
It defines persistent work as:
Persistent work: Remains scheduled through app restarts and device reboots.
A database insert/update/delete is persistent by this definition. Scheduled throws me off a little, as I want it to be immediate, but according to this chart that would still apply.
Is anybody using WorkManager as the mechanism for CUD operations in their repositories and if so, do they have an example?
It would be great to see how this all works in an update fragment. If a single item is selected and I am viewing it in a fragment, when changes are made I would need to update the database using a Worker class and view the data using a LiveData object, correct?
Inserts and returning the id (or object) would be interesting to see as well.
I read here that the inverse is possible, but how does one achieve such a thing? I'd hope there's a simple way, similar to calling from a loaded DLL, but my google research comes up with nothing. My only other thought is that one could pass some predefined constants through WriteFile or DeviceIoControl that the driver parses like a switch statement to execute the relevant function; does a more direct method exist?
The question is why would you want to do it? Generally if you have to rely on some mechanism like this, you need to revisit the design of the application/driver that you are writing.
The correct way to do something in context of your user mode application is exactly what you described. You can do a DeviceIoControl call to your driver and the driver validates all the parameters that you have passed, then carries out the operation on behalf of the user mode call.
If for some reason, you need to call into kernel directly, you will have to resort to undocumented methods. There are ways to hook into kernel dispatch table and overwrite one of the dispatch handler to redirect the call to your function. But I hope you never ever ship anything like this to your customer. This is good for learning how the dispatch table works, etc but introduces several security nightmares. Ultimately your software should not be responsible for someone's machine getting hacked.
I've been asking myself whether there is an easy way of debugging the JavaScript code of the transactions. JS already has mature debuggers, it is only a question of how to easily bind it to the code running in the container. Does anyone have a clue? -- Thx.
One of the easiest ways to debug your transaction code is to deploy your business network into an embedded fabric which basically means that your code is run as any other NodeJS app is and you can use the node debugger to step through your code or even simple console.log statements if that suffices.
To get an insight into how to achieve this, have a look at the code here: UPDATED LINK
https://github.com/hyperledger/composer-sample-networks/blob/master/packages/carauction-network/test/CarAuction.js#L31-L49
This is the beforeEach method of a unit test for the sample network and as you'll see, it deploys the network to the 'embedded' fabric.
The code then goes on to perform tests that include calling the submitTransaction API on the embedded businessNetworkConnection which then causes the Transaction script code to be eval'ed by the embedded fabric.
So it's all happening within a single Node app and is much easier to debug.
HTH
I am trying to override the singe instance limit of an application for which I don't have the source. I know that the app is using the good ol' trick of using CreateMutex to determine whether there is another instance running. (If the mutex is created successfully it proceeds, if getlasterror says that the mutex has been created it quits immediately). I found that through sniffing the Win32 api calls.
I thought using Detours would do the trick, but it doesn't quite work out. I am intercepting CreateMutexW, but for some reason, it doesn't catch the first four calls to it. (Again I know what these calls are by sniffing win32 calls and looking at the name of the mutexes). I do get the fifth one intercepted, but the one I actually want to intercept is the first one.
I am using detours through the sample application withdll. I wonder if the problem is that detours is kicking in too late or because of some kind of protection these calls may have. Is detours the best approach? Perhaps using something else may be a better idea?
There might be several reasons for the situation you describe. Here are the most probable of them:
The CreateMutexW call you need to catch occurs within the DllMain
method of one of the DLLs that are imported by the process, and you
are using the DetoursCreateProcessWithDll() function to inject your
code. Detours injects your DLL by placing it at the end of the
process executable import list, and hence all the DLLs that are
imported by the process would be loaded and initialized within the
process prior to yours. In order to overcome this, try using
CreateProcess(CREATE_SUSPENDED) and CreateRemoteThread()-based
injection, although this method raises its own challenges.
The API that is used in the first call is different. Have you tried
overriding CreateMutexExW? Are you sure ANSI methods call Unicode
ones?
Hope this helps.
I've been using RhinoMocks lately but I keep running into an issue. If I break into the debugger and step over code while a mock is in Record mode, I end up getting an exception along the lines of:
System.InvalidOperationException: Previous method 'SuchAndSuch.ToString();'
requires a return value or an exception to throw.
But if I execute the same code without breaking into the debugger it will execute successfully and create the mock.
I'm pretty sure that the reason for this is that the debugger calls ToString() on objects to display them in the Locals and other Watch windows. But since the mock is in record mode RhinoMocks considers a call to ToString() to be a setup of expectations which then isn't completely correctly. Obviously this only happens with partial mocks on concrete classes. Mocks against interfaces do not exhibit this behavior.
Have other people run into this issue? Is there any simple remedy? Do other frameworks such as moq or TypeMock have this issue?
Thanks,
~ Justin
I can remember having a similar issue with NMock many years ago. Basically, this problem occurs exactly because the debugger invokes and displays properties using the ToString method (unless you use DebuggerDisplayAttribute or similar).
This can be particularly problematic if you use strict mocks because they only allow you to invoke a member the specified number of times, and the debugger interferes with this. Using loose mocks addresses this (and many other) problems.
You may also want to move away from the record/playback mechanism of Rhino Mocks and begin using the newer and much better lambda syntax.
Moq uses lamda syntax (almost) exclusively, and I've never had such issues with it - but then again, I don't debug much these days, as unit tests have become a substitute to debugging.
Yet another remedy is simply to hide the Autos and Locals debugger windows.
As Mark suggested, this problem should go away if you stop using the record-replay-verify approach and start using stubs with the recommended AAA approach (arrange, act, assert) instead.
I've tried to explain the difference and how to do both with Rhino Mocks in this blog post.